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.
https://github.com/cobbler/cobbler/wiki/Advanced%20Topics
For topics in Advanced Topics that already had a Wiki page, we should make sure any info there is mentioned in those pages and then just link to them, so Advanced Topics can eventually go away as a catch all. For instance, all the info about DHCP management should already be covered elsewhere, but the stuff about PXE boot loop prevention does not, so that deserves it's own page.
https://github.com/cobbler/cobbler/wiki/Koan
Koan's docs -- notice to understand the configuration management features that Kelsey Hightower wrote, you have to skip between the two manages, so there are probably some implied topics that could be created, and the existing configuration management section could probably mention it there. That's just one of many though.
Once these get hammered out a bit I'll replace the .pod files in the docs tree to more or less just link to the Wiki.
Thanks!
--Michael
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
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@lists.fedorahosted.org (mailto:cobbler@lists.fedorahosted.org) https://fedorahosted.org/mailman/listinfo/cobbler
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.
On Thu, Dec 22, 2011 at 09:18, Michael DeHaan michael.dehaan@gmail.comwrote:
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…
- edit settings
- cobbler check … and loop until it's mostly clean ...
- cobbler import if at all possible
- now run commands like add/edit/etc
That to me seems to imply pages on the following should exist:
- how we model things (already exists, probably needs cleanup)
- cobbler settings (what's important? how do I change things?)
- 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@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/cobbler
cobbler mailing list cobbler@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/cobbler
On Thu, Dec 22, 2011 at 9:26 AM, Greg Swift 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.
Write a simple scraper? Yeah, if it had a link back to the Wiki at the bottom of each page or something, that would rock. I don't want to source the Wiki source in the git repo though, because the Wiki is much easier for people to edit on the fly.
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 :)
On Thursday, December 22, 2011 at 10:32 AM, James Cammarata wrote:
On Thu, Dec 22, 2011 at 9:26 AM, Greg Swift <gregswift@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@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@gmail.comwrote:
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/70f2c08c7beb89a35e364eeefd1678b8...
logo specifically:
https://github.com/gregswift/cobbler/blob/70f2c08c7beb89a35e364eeefd1678b84b...
favicon:
https://github.com/gregswift/cobbler/blob/70f2c08c7beb89a35e364eeefd1678b84b...
-greg
On Thu, Dec 22, 2011 at 09:53, Greg Swift gregswift@gmail.com wrote:
On Thu, Dec 22, 2011 at 09:43, Michael DeHaan michael.dehaan@gmail.comwrote:
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/70f2c08c7beb89a35e364eeefd1678b8...
logo specifically:
https://github.com/gregswift/cobbler/blob/70f2c08c7beb89a35e364eeefd1678b84b...
favicon:
https://github.com/gregswift/cobbler/blob/70f2c08c7beb89a35e364eeefd1678b84b...
-greg
the only problem was we never got the license issue clarified, which is also why i haven't put the effort into re-basing.
The creator has sent me an e-mail stating that we have full rights and that its ours, but i could never get an official word on how that was supposed to work.
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@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/70f2c08c7beb89a35e364eeefd1678b8...
logo specifically:
https://github.com/gregswift/cobbler/blob/70f2c08c7beb89a35e364eeefd1678b84b...
favicon:
https://github.com/gregswift/cobbler/blob/70f2c08c7beb89a35e364eeefd1678b84b...
-greg _______________________________________________ cobbler mailing list cobbler@lists.fedorahosted.org (mailto:cobbler@lists.fedorahosted.org) https://fedorahosted.org/mailman/listinfo/cobbler
The handcrafted was a bit tongue in cheek in reference to the quality that handcrafted provides.
I'm down with a competition, but i had a hard enough time getting interest in the process the first time around. Maybe a second try will be better?
-greg
On Thu, Dec 22, 2011 at 10:03, Michael DeHaan michael.dehaan@gmail.comwrote:
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@gmail.comwrote:
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/70f2c08c7beb89a35e364eeefd1678b8...
logo specifically:
https://github.com/gregswift/cobbler/blob/70f2c08c7beb89a35e364eeefd1678b84b...
favicon:
https://github.com/gregswift/cobbler/blob/70f2c08c7beb89a35e364eeefd1678b84b...
-greg _______________________________________________ cobbler mailing list cobbler@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/cobbler
cobbler mailing list cobbler@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/cobbler
Sure, let's go for it. All it takes is a pen and a camera or scanner. Look how far XKCD gets with just stick figures.
On Thursday, December 22, 2011 at 11:21 AM, Greg Swift wrote:
The handcrafted was a bit tongue in cheek in reference to the quality that handcrafted provides.
I'm down with a competition, but i had a hard enough time getting interest in the process the first time around. Maybe a second try will be better?
-greg
On Thu, Dec 22, 2011 at 10:03, Michael DeHaan <michael.dehaan@gmail.com (mailto:michael.dehaan@gmail.com)> wrote:
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@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/70f2c08c7beb89a35e364eeefd1678b8...
logo specifically:
https://github.com/gregswift/cobbler/blob/70f2c08c7beb89a35e364eeefd1678b84b...
favicon:
https://github.com/gregswift/cobbler/blob/70f2c08c7beb89a35e364eeefd1678b84b...
-greg _______________________________________________ cobbler mailing list cobbler@lists.fedorahosted.org (mailto:cobbler@lists.fedorahosted.org) https://fedorahosted.org/mailman/listinfo/cobbler
cobbler mailing list cobbler@lists.fedorahosted.org (mailto:cobbler@lists.fedorahosted.org) https://fedorahosted.org/mailman/listinfo/cobbler
cobbler mailing list cobbler@lists.fedorahosted.org (mailto:cobbler@lists.fedorahosted.org) https://fedorahosted.org/mailman/listinfo/cobbler
Greg Swift wrote:
On Thu, Dec 22, 2011 at 09:43, Michael DeHaan <michael.dehaan@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/70f2c08c7beb89a35e364eeefd1678b8...
logo specifically:
https://github.com/gregswift/cobbler/blob/70f2c08c7beb89a35e364eeefd1678b84b...
favicon:
https://github.com/gregswift/cobbler/blob/70f2c08c7beb89a35e364eeefd1678b84b...
[...]
"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.
-- David Lee
"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.
On Thu, Dec 22, 2011 at 11:08, James Cammarata jimi@sngx.net wrote:
"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.
So since this hasn't gotten anywhere I do propose that we at least utilize the boot favicon until someone gets this figured out? I'm all for a fancy new logo, but the whole reason I started down the path in the first place was because I was tired of not having a favicon when I pinned cobbler as an app tab. It doesn't have the medallion look to it or the tongue-in-cheek caption, its just a fairly quality looking leather boot (not modern per se, but not a simple work boot either).
Note, I'm not suggesting this as the official cobbler logo, just a stand in favicon until the logo creation occurs. Which considering the interest that was put into it both the first and second time it was brought up in the last 12m I don't necessarily see being fast tracked any time soon. (just being realistic... most of us are admins/developers not artists)
just a thought/suggestion.
-greg
Yes, I've been slack and didn't draw anything up, but I'm vetoing the boot favicon. Boot gravely offends me :)
Just a letter C or generic free gear icon or something would be better as a temporary measure. Almost anything.
On Tuesday, February 14, 2012 at 4:37 PM, Greg Swift wrote:
On Thu, Dec 22, 2011 at 11:08, James Cammarata <jimi@sngx.net (mailto:jimi@sngx.net)> wrote:
"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.
So since this hasn't gotten anywhere I do propose that we at least utilize the boot favicon until someone gets this figured out? I'm all for a fancy new logo, but the whole reason I started down the path in the first place was because I was tired of not having a favicon when I pinned cobbler as an app tab. It doesn't have the medallion look to it or the tongue-in-cheek caption, its just a fairly quality looking leather boot (not modern per se, but not a simple work boot either).
Note, I'm not suggesting this as the official cobbler logo, just a stand in favicon until the logo creation occurs. Which considering the interest that was put into it both the first and second time it was brought up in the last 12m I don't necessarily see being fast tracked any time soon. (just being realistic... most of us are admins/developers not artists)
just a thought/suggestion.
-greg _______________________________________________ cobbler mailing list cobbler@lists.fedorahosted.org (mailto:cobbler@lists.fedorahosted.org) https://fedorahosted.org/mailman/listinfo/cobbler
Attachments:
- favicon.png
On Tue, Feb 14, 2012 at 15:44, Michael DeHaan michael.dehaan@gmail.comwrote:
Yes, I've been slack and didn't draw anything up, but I'm vetoing the boot favicon. Boot gravely offends me :)
why? you did name the application, did you not?
*cob·bler*/ˈkäblər/Noun:
1. A person who mends shoes as a job. 2. An iced drink made with wine or sherry, sugar, and lemon.
Synonyms: shoemaker
(I was actually surprised by 2.. i was expecting come kind of fruit based baked good...)
Just a letter C or generic free gear icon or something would be better as a
temporary measure. Almost anything.
okay... so.. from teh current 'logo' see attached.... it looks okay, but doesn't really do much, but its better than blank.
-greg
I just don't like work boots? :)
On Tuesday, February 14, 2012 at 5:00 PM, Greg Swift wrote:
On Tue, Feb 14, 2012 at 15:44, Michael DeHaan <michael.dehaan@gmail.com (mailto:michael.dehaan@gmail.com)> wrote:
Yes, I've been slack and didn't draw anything up, but I'm vetoing the boot favicon. Boot gravely offends me :)
why? you did name the application, did you not?
cob·bler/ˈkäblər/ Noun: A person who mends shoes as a job. An iced drink made with wine or sherry, sugar, and lemon.
Synonyms: shoemaker
(I was actually surprised by 2.. i was expecting come kind of fruit based baked good...)
Just a letter C or generic free gear icon or something would be better as a temporary measure. Almost anything.
okay... so.. from teh current 'logo' see attached.... it looks okay, but doesn't really do much, but its better than blank.
-greg _______________________________________________ cobbler mailing list cobbler@lists.fedorahosted.org (mailto:cobbler@lists.fedorahosted.org) https://fedorahosted.org/mailman/listinfo/cobbler
Attachments:
- classic-c-favicon.png
On Tue, Feb 14, 2012 at 16:05, Michael DeHaan michael.dehaan@gmail.comwrote:
I just don't like work boots? :)
okay.
you didn't comment on the 'c' favicon.
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@gmail.com (mailto:michael.dehaan@gmail.com)> wrote:
I just don't like work boots? :)
okay.
you didn't comment on the 'c' favicon. _______________________________________________ cobbler mailing list cobbler@lists.fedorahosted.org (mailto:cobbler@lists.fedorahosted.org) https://fedorahosted.org/mailman/listinfo/cobbler
so.. my lab got blown away and i've got other stuph i'm trying to finish at the moment so I didn't give this a full bore test... but it looks right... pull request sent.
On Tue, Feb 14, 2012 at 16:13, Michael DeHaan michael.dehaan@gmail.comwrote:
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@gmail.comwrote:
I just don't like work boots? :)
okay.
you didn't comment on the 'c' favicon. _______________________________________________ cobbler mailing list cobbler@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/cobbler
cobbler mailing list cobbler@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.)
-- David Lee
On Thu, Dec 22, 2011 at 9:49 AM, David Lee David.Lee@ecmwf.int wrote:
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.)
+1
On Thu, Dec 22, 2011 at 09:50, James Cammarata jimi@sngx.net wrote:
On Thu, Dec 22, 2011 at 9:49 AM, David Lee David.Lee@ecmwf.int wrote:
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.)
+1
i thought about that after i sent it, you idea is a good path. +1
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
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@lists.fedorahosted.org (mailto:cobbler@lists.fedorahosted.org) https://fedorahosted.org/mailman/listinfo/cobbler
Thanks, Michael. Looks like my mistake: in trawling through the wiki, I had overlooked the section in "Built in configuration management" which is titled "Keeping Things Updated". That addresses my terminological timescale question, and the implementation question (via koan, which I had previously thought, from its man page, was purely for installation). Thanks.
-- David Lee
Michael DeHaan wrote:
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@lists.fedorahosted.org mailto:cobbler@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/cobbler
cobbler@lists.fedorahosted.org