Yeah, that could work, but it's kind of ironic too -- Many people consider Cobbler to
be a lightweight CMDB.
It used to have a YAML data store, but we moved away from that due to YAML being annoying
for humans to edit (and also for some performance reasons), with all of the line endings
and making it easy to get an error in it. JSON is more or less the same thing.
While you don't have all of your nodes in one file, you have them in multiple files,
which is more or less the same thing.
On Tuesday, January 31, 2012 at 11:11 AM, Gerhardus Geldenhuis wrote:
Hi
I have not read all of the posts in minute detail but I have seen some similarities with
issues we are experiencing and thought I would share our view on the world.
We have all our server config in yaml and use a custom script using xmlrpc to connect to
cobbler and populate it. To get a working cobbler server we run puppet on a box which will
pull down the repositories and copy all the nessecary configs over. Some of the config
files is using environment variables to set things like dhcp. The idea we are having is
that the yaml files becomes a cmdb in a way which can be read by our script that populates
cobbler and can be read by puppet as well to get data using via hiera. Its not brilliant
but it works. I am also likely to be lambasted for the yaml thing since it could be viewed
as a duplication of the json files in cobbler... especially because I have templated my
yaml files so I have a basic level of inheritance in the config files. (I am in a way
duplicating cobbler functionality) The script is very rudementary at this stage but I
would happy to share it with anyone interested. Having the yaml files does allow us to
keep system config in s
vn and have control over it and you could easily adjust the
script to repopulate cobbler everytime someone commits a change to the config.
Regards
On 31 January 2012 14:54, Michael DeHaan <michael.dehaan(a)gmail.com
(mailto:michael.dehaan@gmail.com)> wrote:
>
>
> 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
> >
> >
> >
>
>
>
> _______________________________________________
> cobbler mailing list
> cobbler(a)lists.fedorahosted.org (mailto:cobbler@lists.fedorahosted.org)
>
https://fedorahosted.org/mailman/listinfo/cobbler
>
--
Gerhardus Geldenhuis
_______________________________________________
cobbler mailing list
cobbler(a)lists.fedorahosted.org (mailto:cobbler@lists.fedorahosted.org)
https://fedorahosted.org/mailman/listinfo/cobbler