> > Hello,
> >
> > i want to know about how effectively i can organize hostgroups.
> >
> > we have 3 ENVs Dev->Stage->Production , and we have 3 locations UK, US, TK,
> > now for example i want to deploy RHEL6 operating system and i am creating
> > hostgroups for that.
> >
> > so i need to create 3 host groups for my ENVs, i named them
> >
> > rhel6_base_dev, rhel6_base_stage, rhel6_base_production ( i have selected
> > LifeCycle env, Puppet Env, content source, added puppet classes as per dev,
> > stage and prod env, selected OS media's and templates as per ENV ).
> >
> > now i hav 3 locations where some puppet modules params are different ( ntp
> > severs are diff, DNS servers are diff), so may be I need to change my
> > hostgroups and create like [rhel6_base_dev_uk, rhel6_base_stage_uk,
> > rhel6_base_production_uk], [rhel6_base_dev_us, rhel6_base_stage_us,
> > rhel6_base_production_us], [rhel6_base_dev_tk, rhel6_base_stage_tk,
> > rhel6_base_production_tk]
> >
> > is this correct understanding ? i think i am creating too many hostgroups
> > for single OS deployment, is there better way to do this ?
>
> I'd reccomend using nested host groups, (click on the down arrow and
> 'Nest' on a host group).
>
> So you'd have something more structured like:
>
> RHEL6
> - Base
> - Dev
> - Stage
> - Production
That's what I was doing as well. Also, when using composed content views
(combination of base os and app sepcific CVs), I had the the hostgroup
for the compose to inherit from the hostgroup that represents the
base os CV.
>
> You can also make use of Foreman locations to store location-specific
> parameters like NTP servers and such there, to maybe not have host
> groups per location as well, depends what works best for you.
>
> Nested hostgroups make management slightly easier as you inherit from
> the parent, but at the end of the day, you're just going to have a ton
> of them. Ideally we'd like to somehow manage host groups through
> a lifecycle, but we haven't quite figured out how to do this yet.
We definitely need to spend more time on this. Ideally also versioning
the hostgroups similarly as we do with content views, and making them
part of the promotion process. We could either enhance the functionality
on the existing hostgroups (but might be not the easiest thing, as
many people already rely on some behaviours that are there) and do
additional layer on top of that (similarly as we do for Pulp repositories:
the pulp itself also has no notion of versioning: but that's for different
discussion probably)
– Ivan
···
----- Original Message -----
> On Fri, Feb 13, 2015 at 01:46:52AM -0800, Unix SA wrote:
also if my NTP servers deffer from DC to DC, how to accommodate that? so
DC1 in tk gets diff NTP servers and DC2 in tk gets diff NTP servers ?
Regards,
D
–
You received this message because you are subscribed to the Google Groups
"foreman-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to foreman-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
–
Best Regards,
Stephen Benjamin
Red Hat Engineering
–
You received this message because you are subscribed to the Google Groups
"foreman-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to foreman-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
