On Tuesday, January 31, 2012 at 9:39 AM, Nick wrote:
On 31/01/12 13:06, Michael DeHaan wrote:
> This already exists, but you're kinda trying to do it backwards :)
Hm, I'm starting to think I must have contrarian tendancies...
> Provisioning happens well before configuration, and Puppet is very much about
> things that already exist -- so it makes sense for Cobbler to lead at first and
> then get out of the way.
>
I think I get that, but from my point of view, I don't want have two tools
(Cobbler and Puppet) managed independently.
Proverbially, I don't think you want to replace all of your tools with a hammer.
I'm far beyond the point of caring about which tools people use, it just
makes it really *weird* do to so.
A Puppet define for each, in particularly, would be horribly slow.
JSON files for each ignore cobbler's own validation and side effects, which
were put there for a reason.
Lots of reasons to use separate tools, you would be shooting yourself in the foot.
Instead, I was hoping to have just *one* definition of how the whole site is set
up, in version control. Puppet seems potentially capable of defining Cobbler's
configuration in entirety, but Cobbler's scope is more limited: the
data-structures describing profiles, systems, etc. are inaccessible to Puppet,
and Cobbler can only pass a list of class names to Puppet via an external node
classifier.
It's not that simple. There's a reason we didn't implement this when I worked
at Puppet
Labs :)
So it seems to make sense to have Puppet configure Cobbler rather than vice
versa. Then there is just one point of control: the central Puppet repository in
a Git repo. Unified, with no duplication (I hope).
This is also the main issue I have with Foreman: I can't put all my config in
one version controlled repository.
The main issue I have with Foreman is the parasitic way users were recruited
from this project and the aggressive self promotion :)
Would rather not discuss it's name here.
> While, in provisioning, we talk about profiles that haven't been installed yet,
> and we can actually decide what the hostnames for given MAC addresses are going
> to be. You may very well want to say when AA:BB:CC:DD:EE:FF mac address comes
> up, install base CentOS 6 and give it Puppet classes A and B, and variables x=2 and
> y=3. We can do that.
>
Yep, and I think I read enough of the docs to see how to do that. It's neat, yes.
As I said, what I don't quite like about it this way is that part of the
site-wide configuration is then embedded in Cobbler's internal configs, and
divorced from the rest of it in Puppet.
Using an external-nodes-tool in pretty a much a best practice from the other side
of the house. Though I can understand the desire to see the changes in a git RSS
feed or something, you would still see that if you used the scm_track module.
I know the Cobbler configuration can be snapshotted into git using a hook - I'm
currently doing it - but it does not integrate easily into my Puppet repository.
It wants to be in its own branch/own repository, and commit changes using the
rather meaningless description "API update" whenever I do a "cobbler
sync".
True, you'd have to look at the diffs to understand what was done.
The main point was rollback.
I also looked at Cobbler's node classifier, but yet again, to use it assumes
Cobbler is driving things, and then Cobbler's (perfectly reasonable) limitations
force a configuration split across Puppet and Cobbler.
Right, deploy the OS and your configuration separately.
Not to mention that as I am using a "masterless" mode, I need more than just a
map of node names to classes, I need a way to emulate external resource
definitions. (I'm using a variation of that described here [1], which needs
exported declarations to go outside the nodes.)
Point, ext-nodes don't work for you. I wish it did work that way, actually.
Ah well.
> We can also do very clever things about saying that all
> RHEL distros get additional classes and variables, and different profiles also
> assign certain classes and variables. See the kickstart snippets which we have
> here for trivial bootstrapping:
>
>
https://github.com/cobbler/cobbler/blob/master/snippets/puppet_install_if...
>
>
https://github.com/cobbler/cobbler/blob/master/snippets/puppet_register_i...
Yes, I've seen those. Those snippets assume there's a Puppet master. But
that's ok, I've adapted them for my own purposes. Well, good enough for now,
anyway.
> Information about using Cobbler as an external nodes resource is also here,
> where you can say, "when this system comes online, give them
> these Puppet classes":
>
>
https://github.com/cobbler/cobbler/wiki/Using%20Cobbler%20With%20A%20Conf...
>
> You could also backup your /var/lib/cobbler configuration files in git if you so
> desired. There's actually a cobbler trigger for this already that will auto
> commit changes:
>
>
https://github.com/cobbler/cobbler/blob/master/cobbler/modules/scm_track.py
Yes, I've also studied those, see above.
It's certainly useful and interesting to learn that I seem to be doing something
different to everyone else. Maybe that's enough to make me reverse direction.
However, arguably I could say doing it "backward" is the way forward, if it
means I can define my systems/profiles in one place, have that information
available to Puppet, and configure my provisioning server with Puppet too. No
need for a hook then, and my changes to Cobbler can be sensibly documented with
the rest of my site-wide changes.
If you did it, you should write set of Ruby types/provider.
The provider must speak Cobbler XMLRPC, not JSON.
The provider will need to notify a cobbler sync if anything changes.
Make sure you don't leak the cobbler username/password to your nodes.
Still, I think that's a lot of work and a confusing way to do it. There are
basically four pieces to systems management
- provisioning
- package management / updates
- config
- monitoring
You pick what tools you want for each. I think having config drive provisioning makes
about as much sense
as having monitoring drive package updates.
But that's just me.
Cheers,
N
1. Puppet Without Masters:
In the section "Backup and Nagios monitoring without storeconfigs"
http://current.workingdirectory.net/posts/2011/puppet-without-masters/
_______________________________________________
cobbler mailing list
cobbler(a)lists.fedorahosted.org (mailto:cobbler@lists.fedorahosted.org)
https://fedorahosted.org/mailman/listinfo/cobbler