Re: [Puppet Users] Puppet, ENC, Foreman, Hiera. Best way for coexistence?
Thanks, it seems trickier than I expected. There's a bunch of modules for network configuration but I'd rather avoid to duplicate the network settings in Foreman and in Hiera. It would heavily affect the scalability of my setup :( There's some interesting work being done on a module able to fetch infrastructure data from the Foreman-generated YAML: https://groups.google.com/d/topic/foreman-users/G6XXgYNbY44/discussion I hope this can progress. On Wednesday, July 1, 2015 at 11:23:52 AM UTC+2, Angel L. Mateo wrote: > > El 01/07/15 a las 11:20, Nicola V escribió: > > On Wednesday, July 1, 2015 at 8:20:00 AM UTC+2, Angel L. Mateo wrote: > > > > We are using what you called option 3. The main reason to > > use option 3 > > instead of 1 was that this way we can have our "truth" under version > > control. > > > > > > Thanks Angel, good to know it's a valid option. > > On a side note: how do you manage changes in the networking interfaces > > AFTER the machine has been installed? Say you want to change an ip. > > Would it be managed by some puppet module? > > > No. We are not managing ip interfaces from puppet. It's on my todo > list, but... > > -- > Angel L. Mateo Martínez > Sección de Telemática > Área de Tecnologías de la Información > y las Comunicaciones Aplicadas (ATICA) > http://www.um.es/atica > Tfo: 868887590 > Fax: 86337 > -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/61929896-6329-47fc-82a0-a61031c8e983%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [Puppet Users] Puppet, ENC, Foreman, Hiera. Best way for coexistence?
On Wednesday, July 1, 2015 at 8:20:00 AM UTC+2, Angel L. Mateo wrote: > > We are using what you called option 3. The main reason to use > option 3 > instead of 1 was that this way we can have our "truth" under version > control. > Thanks Angel, good to know it's a valid option. On a side note: how do you manage changes in the networking interfaces AFTER the machine has been installed? Say you want to change an ip. Would it be managed by some puppet module? -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/daeeac71-67ac-45e0-b804-f6c3d704401f%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[Puppet Users] Puppet, ENC, Foreman, Hiera. Best way for coexistence?
Hello, We're considering to migrate away from node definitions to something more future proof, with the idea to introduce an ENC into our infrastructure. I found some discussions loosely touching the topic from a few years back, and I'd love to hear what would be the "way to go" now, in 2015. Foreman is the tool that impressed us the most for the abundance of features, especially the inventory tracking and host deployment capabilities (the Discovery plugin is powerful). At the same time Hiera seems to be gaining a lot of traction, being able to provide ENC capabilities and hierarchical parameters assignment, but obviously none of the asset tracking and deployment feats of Foreman. The two can interoperate, from what I see, being different tools for different jobs. Yet, they seem to overlap a bit in their scope. Here's how I see them fit in the picture: 1. Foreman for host deployment, asset tracking, reporting, node classification (ENC) and parameter assignment. No Hiera 2. Foreman for host deployment, asset tracking, reporting, node classification (ENC). Hiera for parameter assignment. The popular roles/profiles paradigm would be implemented via Foreman's Config Groups (profiles) and Host Groups (roles). Hiera provides the parameters to the classes. 3. Foreman for host deployment, asset tracking and reporting. Hiera acts as an ENC and assigns roles and profiles via include. Parameters are provided by Hiera, too Let's see the situation: Option 1 is good for centralization: in essence, Foreman would be the only "data store" or "source of truth" about the infrastructure. I don't find the smart parameters/smart classes feature intuitive enough. I'm afraid it might prove non-scalable in the long run, and not so clear to debug, considering smart-matchers at class level have to be used (unless I got it completely wrong). Also, it's not immediately versionable. Option 2 is a good trade off, but there would be two different places where to store information about nodes (roles/profiles in Foreman, params in Hiera). This might confuse people. Option 3 might be the best: Foreman would complement Hiera and the infrastructure would be almost entirely versionable in case YAML or JSON files are used as a Hiera backend. Any opinion in regard from the Foreman/Puppet community? It seems like there's many way to approach this and I'm quite confused. Thanks Nicola -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/09e80665-22dd-43ba-87d5-3aaeec7041fe%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
