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:



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":


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:


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@lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/cobbler