For those that are interested in helping with docs, manage docs are now ported over to the Wiki, in a few parts. https://github.com/cobbler/cobbler/wiki/Start%20Here This is pretty much most of the manage, which I think should stay more or less together. If you split things into too many Wiki pages, it's hard to absorb things via osmosis. I would like to mix the examples in closer to the job though and incorporate more examples throughout, so if you're a new user you don't get bored/confused and wonder what commands you actually care about running. [...]

Thanks, totally agree. I was thinking of breaking things up into subpages. We might as well just make all these pages link directly from User Docs and Start Here may eventually go away or just become a subhead. The Wiki does document cobbler import … and there are examples at the bottom in the workflow/example section that can be merged. Since there's a Wiki page on that though, we can just link to it. Since the workflow for new users is… 1) edit settings 2) cobbler check … and loop until it's mostly clean ... 3) cobbler import if at all possible 4) now run commands like add/edit/etc That to me seems to imply pages on the following should exist: 0) how we model things (already exists, probably needs cleanup) 1) cobbler settings (what's important? how do I change things?) 2) running cobbler check (just mentioning the important ones, and there are comments in the file, what to do after editing them) 3) cobbler import (already exists) 4) editing objects 5) repository mirroring Basically makings things more or less task oriented, routing folks through reading pages on each of the above in order. "I know what I want to accomplish, now how do I do it, and in what order?" Rather than burying folks under a lot of commands and hoping they run across something they'll learn from. Then there are a few things that probably don't have pages on them, where we could take them off the main page too. * power management * PXE (boot loop prevention, menu generation, etc) * configuration management (section exists already about puppet, but should merge in the built-in config stuff and make easier to understand) And some pages I think are a bit confusing already exist, but prob need cleanup to make more sense: * /etc/cobbler/modules.conf * DHCP management * DNS management (particularly hard) * web app security choices * triggers * XMLRPC API (needs lots of examples, probably) Then there are various things that don't really get documented * what snippets ship with cobbler and why should you use them * etc Not all stuff we have to do now, of course, but that's sort of my take on it. --Michael On Thursday, December 22, 2011 at 10:00 AM, David Lee wrote: Michael DeHaaan wrote: For those that are interested in helping with docs, manage docs are now ported over to the Wiki, in a few parts. https://github.com/cobbler/cobbler/wiki/Start%20Here This is pretty much most of the manage, which I think should stay more or less together. If you split things into too many Wiki pages, it's hard to absorb things via osmosis. I would like to mix the examples in closer to the job though and incorporate more examples throughout, so if you're a new user you don't get bored/confused and wonder what commands you actually care about running. [...] Great! Thanks, Michael. As this is a "Start here" document, it should be simple and clear, and avoid unnecessary detail, particular in its opening stages. I began editing it... ...but ended up almost completely rewriting the opening sections, through to and including the opening paragraphs of "adding distributions". The emphasis is on getting a complete beginner started with something, anything, and avoiding unnecessary detail. I haven't really addressed the remainder of the document; my changes in the remainder are mostly cosmetic, improving heading/subheading structure, etc. Returning to "adding distributions". While the original man page had thoroughly documented "cobbler distro ...", it hadn't (by contrast) got a section on "cobbler import ..." at all. So I have begun to structure this "adding distributions" sections to cover these related topics. But I strongly suspect that most of the options for "distro" also apply to "import", so it probably needs further restructuring to clarify this. (By the way, more generally, I'm not yet convinced that every last detail of every last option for every last command belongs in a "Start here" document...) -- David Lee _______________________________________________ cobbler mailing list cobbler(a)lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/cobbler _______________________________________________ cobbler mailing list cobbler(a)lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/cobbler

On Thu, Dec 22, 2011 at 9:26 AM, Greg Swift <gregswift(a)gmail.com (mailto:gregswift@gmail.com)> wrote: > So... when I was redoing the web interface one of the things I had in my > mind was that it would be nice if there was more on the "welcome" page than > just a welcome. My thought was to have a generic description of the left > hand menu items, but since you are working on this document, it might be > kind of kewl if the simple start here was replicated in the web ui. Even if > the links just point back to the online documentation? > > just a thought. I had always thought of making a "stats" page, to show you the number of systems you have, ones that are in the process of building, etc. Alternatively, you do bring up a good point. Why don't we just bundle the documentation with the web app? It would make people's lives easier I think, and since it's all going on github anyway I don't think it would be that difficult. The version of the docs that came with the code would always be the most up to date version. _______________________________________________ cobbler mailing list cobbler(a)lists.fedorahosted.org (mailto:cobbler@lists.fedorahosted.org) https://fedorahosted.org/mailman/listinfo/cobbler

On Thu, Dec 22, 2011 at 09:43, Michael DeHaan <michael.dehaan(a)gmail.com&gt;wrote: > Re: the idea of a better welcome page, the cobbler.github.com site is > also at http://github.com/cobbler and can also take pull requests, if > someone with web-design chops wants to add some better links to the docs > and more impressive blingy-ness. That would be awesome. It's about > time we had a really good logo too :) > Actually we got with the Fedora Design team, and despite lots of conflict (dear lord) we did come out with a logo. http://lists.fedoraproject.org/pipermail/design-team/2011-July/004611.html I haven't gotten commit set rebased on new github setup https://github.com/gregswift/cobbler/commit/70f2c08c7beb89a35e364eeefd167... logo specifically: https://github.com/gregswift/cobbler/blob/70f2c08c7beb89a35e364eeefd1678b... favicon: https://github.com/gregswift/cobbler/blob/70f2c08c7beb89a35e364eeefd1678b... -greg

Yeah, not a fan :) Maybe it's a boot, but if it's a boot, it needs to be a cool mascot-calibre boot, not a dusty 1890's model boot. And hand crafted? I think doing things by hand is what we avoid :) Or maybe there's something about connecting things together that's more appropriate. I always kind of thought this should be a competition among people on the list -- at least for a basic idea. Many of us can draw. mspaint level ideas are ok :) On Thursday, December 22, 2011 at 10:53 AM, Greg Swift wrote: On Thu, Dec 22, 2011 at 09:43, Michael DeHaan <michael.dehaan(a)gmail.com&gt;wrote: Re: the idea of a better welcome page, the cobbler.github.com site is also at http://github.com/cobbler and can also take pull requests, if someone with web-design chops wants to add some better links to the docs and more impressive blingy-ness. That would be awesome. It's about time we had a really good logo too :) Actually we got with the Fedora Design team, and despite lots of conflict (dear lord) we did come out with a logo. http://lists.fedoraproject.org/pipermail/design-team/2011-July/004611.html I haven't gotten commit set rebased on new github setup https://github.com/gregswift/cobbler/commit/70f2c08c7beb89a35e364eeefd167... logo specifically: https://github.com/gregswift/cobbler/blob/70f2c08c7beb89a35e364eeefd1678b... favicon: https://github.com/gregswift/cobbler/blob/70f2c08c7beb89a35e364eeefd1678b... -greg _______________________________________________ cobbler mailing list cobbler(a)lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/cobbler _______________________________________________ cobbler mailing list cobbler(a)lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/cobbler

On Thu, Dec 22, 2011 at 09:43, Michael DeHaan <michael.dehaan(a)gmail.com <mailto:michael.dehaan@gmail.com>> wrote: Re: the idea of a better welcome page, the cobbler.github.com <http://cobbler.github.com> site is also at http://github.com/cobbler and can also take pull requests, if someone with web-design chops wants to add some better links to the docs and more impressive blingy-ness. That would be awesome. It's about time we had a really good logo too :) Actually we got with the Fedora Design team, and despite lots of conflict (dear lord) we did come out with a logo. http://lists.fedoraproject.org/pipermail/design-team/2011-July/004611.html I haven't gotten commit set rebased on new github setup https://github.com/gregswift/cobbler/commit/70f2c08c7beb89a35e364eeefd167... logo specifically: https://github.com/gregswift/cobbler/blob/70f2c08c7beb89a35e364eeefd1678b... favicon: https://github.com/gregswift/cobbler/blob/70f2c08c7beb89a35e364eeefd1678b... [...]

> "Hand crafted"? With an old-style boot? But in my view the whole point of > cobbler installation is the opposite. Isn't it to have a high-quality, > reliable, automated production line for multiple instances of machines? The > last thing we want is old-style, geek-in-a-garage sys.admins. spending their > lives hand-crafting every detail on every box and inevitably getting > something, somewhere wrong. That's completely unscalable: the very opposite > of what cobbler is about, isn't it? > > I'm no artist. But something like a a shelf of computer icons (possibly two > or three instances of two or three different types. And to the lower left, > a shiny, fashionable streamlined boot in mid-swing, and some curvy lines to > suggest that this boot has just deposited those computers on that shelf. Or > something like that. And pie.

Yes, I've been slack and didn't draw anything up, but I'm vetoing the boot favicon. Boot gravely offends me :)

temporary measure. Almost anything.

I just don't like work boots? :)

works4me. send a pull request. On Tuesday, February 14, 2012 at 5:09 PM, Greg Swift wrote: On Tue, Feb 14, 2012 at 16:05, Michael DeHaan <michael.dehaan(a)gmail.com&gt;wrote: I just don't like work boots? :) okay. you didn't comment on the 'c' favicon. _______________________________________________ cobbler mailing list cobbler(a)lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/cobbler _______________________________________________ cobbler mailing list cobbler(a)lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/cobbler

Greg Swift wrote: > > So... when I was redoing the web interface one of the things I had in my > mind was that it would be nice if there was more on the "welcome" page than > just a welcome.  My thought was to have a generic description of the left > hand menu items, but since you are working on this document, it might be > kind of kewl if the simple start here was replicated in the web ui.  Even if > the links just point back to the online documentation? > [...] Regarding: "Even if the links just point back to the online documentation?" It's probably not that simple.  At many sites the cobbler (web) server may be firewalled off from the Internet.  So the documentation would need to be locally available. Given that (in the Redhat world, at least), we already have RPMs for "cobbler" and "cobbler-web", perhaps there should also be an RPM "cobbler-docs".  The source of its data would include pages (or transformed pages) from the wiki; the installed destination of its data would be appropriate points in the system's own man pages, info pages, and website.  (That, of course, is a very high-level, blue-sky, hand-wavy, sketchy overview, deliberately avoiding fine detail at this stage.)

Thanks, totally agree. [...]

[...] Then there are a few things that probably don't have pages on them, where we could take them off the main page too. * power management * PXE (boot loop prevention, menu generation, etc) * configuration management (section exists already about puppet, but should merge in the built-in config stuff and make easier to understand) [...]

No, there's no reason to limit it, nor any reason to assume the status quo must hold. There's nothing saying koan can't gain more support for more idempotent configuration runs and couldn't be put on a crontab. This is probably an area where it will only grow. Most of the complexity in configuration management tools is not needed when the packages do most of the work. What's left is mostly around blasting out templates, and if you need a more complex system, it can integrate with those. Is Cobbler just a provisioning app when it also does repo mirroring and updates, and can reboot your machines for you? Not really. I actually like what's been added to Cobbler to support better files/package integration a good amount. Incredibly lightweight, super simple, and doesn't require you to learn a programming language. Plus I really like that you can use the same templates for kickstart that you use post-kickstart. Now imagine using Func or another tool to trigger koan runs, and you have a full system. (But we'll leave choosing that up to you, crontab would be fine). Writing a configuration management system into Cobbler (well, Func) was always something I wanted to do, it was always not organizationally compatible. To be clear, I have no interest in competing with full-on management stacks -- there's nothing to win -- but for people who still want to manage their systems simply without learning a modeling language I think we can do that very very well. And, in accordance with Cobbler philosophy, we'll not force you to go either way. Configuration is largely about files. We help you manage those things at runtime. Nothing wrong with using the word. Many folks who are pushing out hosted apps with different deployment models (even Capistrano, etc), just don't need something that heavy. --Michael On Thursday, December 22, 2011 at 11:57 AM, David Lee wrote: > Michael DeHaan wrote: >> Thanks, totally agree. >> [...] > > Thanks. Glad to that, as a newbie to cobbler, I'm getting this > more-or-less right. > >> [...] >> Then there are a few things that probably don't have pages on them, >> where we could take them off the main page too. >> >> * power management >> * PXE (boot loop prevention, menu generation, etc) >> * configuration management (section exists already about puppet, but >> should merge in the built-in config stuff and make easier to understand) >> [...] > > I've always been uneasy about the way cobbler talks about "configuration > management". > > Installed machines can have a life-cycle of several years. It is in > this long-term, ongoing maintenance context that products such as > cfengine and puppet use the term "configuration management". > > But when cobbler documentation uses this same term, it isn't talking > about long-term maintenance at all. Rather it is talking about > "configuration initialisation": getting some sort of initial > configuration onto the machine that will probably do for the moment, > where "for the moment" means "while my mind is on the business of > getting this machine started; probably less than a day; probably less > than an hour; probably less than even 15 minutes". > > > So I would suggest that we give care to our use of terminology and > intention. I suggest we reserve the term "configuration management" for > its generally understood long-term maintenance purpose (cfengine, > puppet, etc.), and introduce a term such as "configuration > initialisation" to discuss our activities of doing the initial > tailoring. This initial tailoring might include hooks to install > cfengine/puppet and just enough to get them started; it might include > the material (hitherto called "config management", such as "management > classes" etc.). > > > > -- David Lee > _______________________________________________ > cobbler mailing list > cobbler(a)lists.fedorahosted.org <mailto:cobbler@lists.fedorahosted.org> > https://fedorahosted.org/mailman/listinfo/cobbler