What to do when there is a hostgroup / host environment mismatch

ohadlevy · January 23, 2013, 9:08am

Hi,

One of the last remaining issues for 1.1 release is how to handle puppet
class assignment mismatch between environments, best by example:

Hostgroup
name: Web Servers
Env: Production-V1
Classes: apache, apache-monitor

Host:
Name: A web server
Env: QA
Classes: apache, apache-monitor (inherited from hostgroup).

What should foreman do if the QA env has no apache-monitor class?
so far, we always added it, and puppet silently ignored it (with the
traditional non parameterized format), however, starting with the new enc
format, puppet now fails on non existing classes.

we already have a ticket [1] and a fix [2], however I'm not sure that's the
right way to solve the problem.

while I understand this can cause upset users, i do believe that if
a certain setup was not tested, it does makes sense to raise an error.

however, from past discussions (mostly from CERN guys), I got the
understanding that this is not ideal, so my question breaks into two:

are there other usage cases that this model breaks that
I didn't consider here?
what do you guys want to see happening:
a. puppet raise an error (e.g. missing class)
b. foreman removes all classes which are not in the env transparently
c. each hostgroup can assign classes to different environments
d. something else?

Thanks,
Ohad

[1] Bug #2124: dont include missing hostgroup classes when host is not in the same environment - Foreman
[2] https://github.com/theforeman/foreman/pull/382

Charlie_Derwent · January 24, 2013, 1:49am

Hi Ohad,

It's a difficult one, as you know I support the "dont include missing
hostgroup classes" stance in order to aid a logical development workflow in
moving new classes from a Local Dev Env to a Shared Dev/Continous
Integration Env to QA to Production. (i.e. manually add a class to a host
for work on one sever, then when rolling out to multiple servers add the
class to the appropriate hostgroup and update the next environment, test,
update the next environment, test and so on…) as described by the CERN
guys.

However, I can see where you/abenari are coming from in if someone didn't
know the class wasn't in that env the error you plan to remove would
have pointed it out to them.

1 - I can't think of any use case the change would break other than the one
above.

2 - I would prefer 'b', we already have the behaviour described in 'a' and
'c' would potentially lead to more confusion if foreman wasn't consistant
in defining the classes that belonged to a hostgroup.

I think the pull request is fine as you have it, but if you still want to
warn people is there anywhere you can create a non-fatal warning maybe?
foreman gui or in the puppet run? Or if you still wanted the puppet run to
error could make the behaviour in your pull request an option you need to
enable in somewhere like settings.yaml :ignore_missing_classes: false/true ?

Regards,
Charlie

···

On Wed, Jan 23, 2013 at 9:08 AM, Ohad Levy wrote:

Hi,

One of the last remaining issues for 1.1 release is how to handle puppet
class assignment mismatch between environments, best by example:

Hostgroup
name: Web Servers
Env: Production-V1
Classes: apache, apache-monitor

Host:
Name: A web server
Env: QA
Classes: apache, apache-monitor (inherited from hostgroup).

What should foreman do if the QA env has no apache-monitor class?
so far, we always added it, and puppet silently ignored it (with the
traditional non parameterized format), however, starting with the new enc
format, puppet now fails on non existing classes.

we already have a ticket [1] and a fix [2], however I’m not sure that’s
the right way to solve the problem.

while I understand this can cause upset users, i do believe that if
a certain setup was not tested, it does makes sense to raise an error.

however, from past discussions (mostly from CERN guys), I got the
understanding that this is not ideal, so my question breaks into two:

are there other usage cases that this model breaks that
I didn’t consider here?

what do you guys want to see happening:
a. puppet raise an error (e.g. missing class)
b. foreman removes all classes which are not in the env transparently
c. each hostgroup can assign classes to different environments
d. something else?

Thanks,
Ohad

[1] Bug #2124: dont include missing hostgroup classes when host is not in the same environment - Foreman
[2] https://github.com/theforeman/foreman/pull/382

–
You received this message because you are subscribed to the Google Groups
"Foreman users" group.
To post to this group, send email to foreman-users@googlegroups.com.
To unsubscribe from this group, send email to
foreman-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/foreman-users?hl=en.

Andrei_Burd · April 7, 2013, 7:27am

Hi Ohad,
As i Understood, the Option B is now common Foreman behavior,
i found an option in settings named "remove_classes_not_in_environment" and
marked it as false, so if i rename a class or delete it i hope it to still
be there and I'll receive Puppet error.
But on the other hand description is saying: When Host and Hostgroup have
different environments should all classes be included (regardless if they
exists or not in the other environment)
So I'm a bit confused.
Could you please advice on what option is right to receive a puppet error
in my case?

Thank you in advance.

···

On Wednesday, January 23, 2013 11:08:58 AM UTC+2, ohad wrote: > > Hi, > > One of the last remaining issues for 1.1 release is how to handle puppet > class assignment mismatch between environments, best by example: > > Hostgroup > name: Web Servers > Env: Production-V1 > Classes: apache, apache-monitor > > Host: > Name: A web server > Env: QA > Classes: apache, apache-monitor (inherited from hostgroup). > > What should foreman do if the QA env has no apache-monitor class? > so far, we always added it, and puppet silently ignored it (with the > traditional non parameterized format), however, starting with the new enc > format, puppet now fails on non existing classes. > > we already have a ticket [1] and a fix [2], however I'm not sure that's > the right way to solve the problem. > > while I understand this can cause upset users, i do believe that if > a certain setup was not tested, it does makes sense to raise an error. > > however, from past discussions (mostly from CERN guys), I got the > understanding that this is not ideal, so my question breaks into two: > > 1. are there other usage cases that this model breaks that > I didn't consider here? > 2. what do you guys want to see happening: > a. puppet raise an error (e.g. missing class) > b. foreman removes all classes which are not in the env transparently > c. each hostgroup can assign classes to different environments > d. something else? > > > Thanks, > Ohad > > [1] http://projects.theforeman.org/issues/2124 > [2] https://github.com/theforeman/foreman/pull/382 > > > >

ohadlevy · January 24, 2013, 7:30am

> Hi Ohad,
>
> It's a difficult one, as you know I support the "dont include missing
> hostgroup classes" stance in order to aid a logical development workflow in
> moving new classes from a Local Dev Env to a Shared Dev/Continous
> Integration Env to QA to Production. (i.e. manually add a class to a host
> for work on one sever, then when rolling out to multiple servers add the
> class to the appropriate hostgroup and update the next environment, test,
> update the next environment, test and so on…) as described by the CERN
> guys.
>
> However, I can see where you/abenari are coming from in if someone didn't
> know the class wasn't in that env the error you plan to remove would
> have pointed it out to them.
>
> 1 - I can't think of any use case the change would break other than the
> one above.
>
> 2 - I would prefer 'b', we already have the behaviour described in 'a' and
> 'c' would potentially lead to more confusion if foreman wasn't consistant
> in defining the classes that belonged to a hostgroup.
>
> I think the pull request is fine as you have it, but if you still want to
> warn people is there anywhere you can create a non-fatal warning maybe?
> foreman gui or in the puppet run? Or if you still wanted the puppet run to
> error could make the behaviour in your pull request an option you need to
> enable in somewhere like settings.yaml :ignore_missing_classes: false/true ?
>

I tend to agree, maybe extracting it as a settings is best…

What do you guys think?

Ohad

···

On Thu, Jan 24, 2013 at 3:49 AM, Charlie Derwent < shelltoesuperstar@gmail.com> wrote:

Regards,
Charlie

On Wed, Jan 23, 2013 at 9:08 AM, Ohad Levy ohadlevy@gmail.com wrote:

Hi,

One of the last remaining issues for 1.1 release is how to handle puppet
class assignment mismatch between environments, best by example:

Hostgroup
name: Web Servers
Env: Production-V1
Classes: apache, apache-monitor

Host:
Name: A web server
Env: QA
Classes: apache, apache-monitor (inherited from hostgroup).

What should foreman do if the QA env has no apache-monitor class?
so far, we always added it, and puppet silently ignored it (with the
traditional non parameterized format), however, starting with the new enc
format, puppet now fails on non existing classes.

we already have a ticket [1] and a fix [2], however I’m not sure that’s
the right way to solve the problem.

while I understand this can cause upset users, i do believe that if
a certain setup was not tested, it does makes sense to raise an error.

however, from past discussions (mostly from CERN guys), I got the
understanding that this is not ideal, so my question breaks into two:

are there other usage cases that this model breaks that
I didn’t consider here?

what do you guys want to see happening:
a. puppet raise an error (e.g. missing class)
b. foreman removes all classes which are not in the env transparently
c. each hostgroup can assign classes to different environments
d. something else?

Thanks,
Ohad

[1] Bug #2124: dont include missing hostgroup classes when host is not in the same environment - Foreman
[2] https://github.com/theforeman/foreman/pull/382

–
You received this message because you are subscribed to the Google Groups
"Foreman users" group.
To post to this group, send email to foreman-users@googlegroups.com.
To unsubscribe from this group, send email to
foreman-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/foreman-users?hl=en.

–
You received this message because you are subscribed to the Google Groups
"Foreman users" group.
To post to this group, send email to foreman-users@googlegroups.com.
To unsubscribe from this group, send email to
foreman-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/foreman-users?hl=en.

ohadlevy · April 10, 2013, 2:02pm

> Hi Ohad,
> As i Understood, the Option B is now common Foreman behavior,
> i found an option in settings named "remove_classes_not_in_environment" and
> marked it as false, so if i rename a class or delete it i hope it to still
> be there and I'll receive Puppet error.
> But on the other hand description is saying: When Host and Hostgroup have
> different environments should all classes be included (regardless if they
> exists or not in the other environment)
> So I'm a bit confused.
> Could you please advice on what option is right to receive a puppet error in
> my case?
>

The option is something else if i understand your usage case correctly…
sometimes the classes under hostgroup are classes from env X
and you can select a host in foreman which is env Y but with that same
hostgroup, you would get classes from env X (which do not exists in
the host env Y).

so that option simply removes those classes that do not belong to the
current host running env.

Ohad

···

On Sun, Apr 7, 2013 at 10:27 AM, Andrei Burd wrote: > Thank you in advance. > > > On Wednesday, January 23, 2013 11:08:58 AM UTC+2, ohad wrote: >> >> Hi, >> >> One of the last remaining issues for 1.1 release is how to handle puppet >> class assignment mismatch between environments, best by example: >> >> Hostgroup >> name: Web Servers >> Env: Production-V1 >> Classes: apache, apache-monitor >> >> Host: >> Name: A web server >> Env: QA >> Classes: apache, apache-monitor (inherited from hostgroup). >> >> What should foreman do if the QA env has no apache-monitor class? >> so far, we always added it, and puppet silently ignored it (with the >> traditional non parameterized format), however, starting with the new enc >> format, puppet now fails on non existing classes. >> >> we already have a ticket [1] and a fix [2], however I'm not sure that's >> the right way to solve the problem. >> >> while I understand this can cause upset users, i do believe that if a >> certain setup was not tested, it does makes sense to raise an error. >> >> however, from past discussions (mostly from CERN guys), I got the >> understanding that this is not ideal, so my question breaks into two: >> >> 1. are there other usage cases that this model breaks that I didn't >> consider here? >> 2. what do you guys want to see happening: >> a. puppet raise an error (e.g. missing class) >> b. foreman removes all classes which are not in the env transparently >> c. each hostgroup can assign classes to different environments >> d. something else? >> >> >> Thanks, >> Ohad >> >> [1] http://projects.theforeman.org/issues/2124 >> [2] https://github.com/theforeman/foreman/pull/382 >> >> >> > > -- > You received this message because you are subscribed to the Google Groups > "Foreman users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to foreman-users+unsubscribe@googlegroups.com. > > To post to this group, send email to foreman-users@googlegroups.com. > Visit this group at http://groups.google.com/group/foreman-users?hl=en. > For more options, visit https://groups.google.com/groups/opt_out. > >

Brian_Gupta · January 24, 2013, 9:09am

>
>
>
>> Hi Ohad,
>>
>> It's a difficult one, as you know I support the "dont include missing
>> hostgroup classes" stance in order to aid a logical development workflow in
>> moving new classes from a Local Dev Env to a Shared Dev/Continous
>> Integration Env to QA to Production. (i.e. manually add a class to a host
>> for work on one sever, then when rolling out to multiple servers add the
>> class to the appropriate hostgroup and update the next environment, test,
>> update the next environment, test and so on…) as described by the CERN
>> guys.
>>
>> However, I can see where you/abenari are coming from in if someone didn't
>> know the class wasn't in that env the error you plan to remove would
>> have pointed it out to them.
>>
>> 1 - I can't think of any use case the change would break other than the
>> one above.
>>
>> 2 - I would prefer 'b', we already have the behaviour described in 'a'
>> and 'c' would potentially lead to more confusion if foreman wasn't
>> consistant in defining the classes that belonged to a hostgroup.
>>
>> I think the pull request is fine as you have it, but if you still want to
>> warn people is there anywhere you can create a non-fatal warning maybe?
>> foreman gui or in the puppet run? Or if you still wanted the puppet run to
>> error could make the behaviour in your pull request an option you need to
>> enable in somewhere like settings.yaml :ignore_missing_classes: false/true ?
>>
>
> I tend to agree, maybe extracting it as a settings is best…
>

This doesn't impact us, but I agree that a setting is probably best, with
the default set to legacy behavior.

What do you guys think?

···

On Thu, Jan 24, 2013 at 2:30 AM, Ohad Levy wrote: > On Thu, Jan 24, 2013 at 3:49 AM, Charlie Derwent < > shelltoesuperstar@gmail.com> wrote: > > Ohad > >> >> Regards, >> Charlie >> >> >> >> On Wed, Jan 23, 2013 at 9:08 AM, Ohad Levy wrote: >> >>> Hi, >>> >>> One of the last remaining issues for 1.1 release is how to handle puppet >>> class assignment mismatch between environments, best by example: >>> >>> Hostgroup >>> name: Web Servers >>> Env: Production-V1 >>> Classes: apache, apache-monitor >>> >>> Host: >>> Name: A web server >>> Env: QA >>> Classes: apache, apache-monitor (inherited from hostgroup). >>> >>> What should foreman do if the QA env has no apache-monitor class? >>> so far, we always added it, and puppet silently ignored it (with the >>> traditional non parameterized format), however, starting with the new enc >>> format, puppet now fails on non existing classes. >>> >>> we already have a ticket [1] and a fix [2], however I'm not sure that's >>> the right way to solve the problem. >>> >>> while I understand this can cause upset users, i do believe that if >>> a certain setup was not tested, it does makes sense to raise an error. >>> >>> however, from past discussions (mostly from CERN guys), I got the >>> understanding that this is not ideal, so my question breaks into two: >>> >>> 1. are there other usage cases that this model breaks that >>> I didn't consider here? >>> 2. what do you guys want to see happening: >>> a. puppet raise an error (e.g. missing class) >>> b. foreman removes all classes which are not in the env transparently >>> c. each hostgroup can assign classes to different environments >>> d. something else? >>> >>> >>> Thanks, >>> Ohad >>> >>> [1] http://projects.theforeman.org/issues/2124 >>> [2] https://github.com/theforeman/foreman/pull/382 >>> >>> >>> >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Foreman users" group. >>> To post to this group, send email to foreman-users@googlegroups.com. >>> To unsubscribe from this group, send email to >>> foreman-users+unsubscribe@googlegroups.com. >>> For more options, visit this group at >>> http://groups.google.com/group/foreman-users?hl=en. >>> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Foreman users" group. >> To post to this group, send email to foreman-users@googlegroups.com. >> To unsubscribe from this group, send email to >> foreman-users+unsubscribe@googlegroups.com. >> For more options, visit this group at >> http://groups.google.com/group/foreman-users?hl=en. >> > > -- > You received this message because you are subscribed to the Google Groups > "Foreman users" group. > To post to this group, send email to foreman-users@googlegroups.com. > To unsubscribe from this group, send email to > foreman-users+unsubscribe@googlegroups.com. > Visit this group at http://groups.google.com/group/foreman-users?hl=en. > For more options, visit https://groups.google.com/groups/opt_out. > > >

–
http://aws.amazon.com/solutions/solution-providers/brandorr/

Romain_Vrignaud · January 24, 2013, 9:15am

I'm not sure to answer directly to the question but the following is quite
related:

I think behavior of puppet error or silent foreman removing should be up
to the user with a constant behavior during upgrade.
On top of that it would be really great if it was possible to define
hostgroup with different behavior per env. What I mean is that ideally
hostgroup should not be bound to
a specific env.

We would create just an hostgroup. All object defined into that hostgroup
(classes, parameters, networking) are common by default for all environments
but it should be possible to add specific behavior by env.

It would allow me to just define the hostgroup webserver. A large amount of
'webserver' configuration is common between all my env but there are small
differences
(more parameters, or somes additional classes on a particular env).

This would prevent to create an hostgroup by env (in my case I have 4 env
and 26 hostgroup by env … )
I understand that's a big change and don't solve the 1.1 release problem.

Thoughts ?

Romain

···

2013/1/24 Ohad Levy

On Thu, Jan 24, 2013 at 3:49 AM, Charlie Derwent < > shelltoesuperstar@gmail.com> wrote:

Hi Ohad,

It’s a difficult one, as you know I support the “dont include missing
hostgroup classes” stance in order to aid a logical development workflow in
moving new classes from a Local Dev Env to a Shared Dev/Continous
Integration Env to QA to Production. (i.e. manually add a class to a host
for work on one sever, then when rolling out to multiple servers add the
class to the appropriate hostgroup and update the next environment, test,
update the next environment, test and so on…) as described by the CERN
guys.

However, I can see where you/abenari are coming from in if someone didn’t
know the class wasn’t in that env the error you plan to remove would
have pointed it out to them.

1 - I can’t think of any use case the change would break other than the
one above.

2 - I would prefer ‘b’, we already have the behaviour described in 'a’
and ‘c’ would potentially lead to more confusion if foreman wasn’t
consistant in defining the classes that belonged to a hostgroup.

I think the pull request is fine as you have it, but if you still want to
warn people is there anywhere you can create a non-fatal warning maybe?
foreman gui or in the puppet run? Or if you still wanted the puppet run to
error could make the behaviour in your pull request an option you need to
enable in somewhere like settings.yaml :ignore_missing_classes: false/true ?

I tend to agree, maybe extracting it as a settings is best…

What do you guys think?

Ohad

Regards,
Charlie

On Wed, Jan 23, 2013 at 9:08 AM, Ohad Levy ohadlevy@gmail.com wrote:

Hi,

One of the last remaining issues for 1.1 release is how to handle puppet
class assignment mismatch between environments, best by example:

Hostgroup
name: Web Servers
Env: Production-V1
Classes: apache, apache-monitor

Host:
Name: A web server
Env: QA
Classes: apache, apache-monitor (inherited from hostgroup).

What should foreman do if the QA env has no apache-monitor class?
so far, we always added it, and puppet silently ignored it (with the
traditional non parameterized format), however, starting with the new enc
format, puppet now fails on non existing classes.

we already have a ticket [1] and a fix [2], however I’m not sure that’s
the right way to solve the problem.

while I understand this can cause upset users, i do believe that if
a certain setup was not tested, it does makes sense to raise an error.

however, from past discussions (mostly from CERN guys), I got the
understanding that this is not ideal, so my question breaks into two:

are there other usage cases that this model breaks that
I didn’t consider here?

what do you guys want to see happening:
a. puppet raise an error (e.g. missing class)
b. foreman removes all classes which are not in the env transparently
c. each hostgroup can assign classes to different environments
d. something else?

Thanks,
Ohad

[1] Bug #2124: dont include missing hostgroup classes when host is not in the same environment - Foreman
[2] https://github.com/theforeman/foreman/pull/382

–
You received this message because you are subscribed to the Google
Groups “Foreman users” group.
To post to this group, send email to foreman-users@googlegroups.com.
To unsubscribe from this group, send email to
foreman-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/foreman-users?hl=en.

–
You received this message because you are subscribed to the Google Groups
"Foreman users" group.
To post to this group, send email to foreman-users@googlegroups.com.
To unsubscribe from this group, send email to
foreman-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/foreman-users?hl=en.

–
You received this message because you are subscribed to the Google Groups
"Foreman users" group.
To post to this group, send email to foreman-users@googlegroups.com.
To unsubscribe from this group, send email to
foreman-users+unsubscribe@googlegroups.com.
Visit this group at http://groups.google.com/group/foreman-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Andrei_Burd · April 10, 2013, 7:19pm

I got your call,
just was so desperate that replied in this thread.
"remove_classes_not_in_environment" is great option especially when using
Location, organisations, and all the fancy Staff from foreman 1.1
Great work!

···

On Wednesday, April 10, 2013 5:02:56 PM UTC+3, ohad wrote: > > On Sun, Apr 7, 2013 at 10:27 AM, Andrei Burd <burda...@gmail.com> > wrote: > > Hi Ohad, > > As i Understood, the Option B is now common Foreman behavior, > > i found an option in settings named "remove_classes_not_in_environment" > and > > marked it as false, so if i rename a class or delete it i hope it to > still > > be there and I'll receive Puppet error. > > But on the other hand description is saying: When Host and Hostgroup > have > > different environments should all classes be included (regardless if > they > > exists or not in the other environment) > > So I'm a bit confused. > > Could you please advice on what option is right to receive a puppet > error in > > my case? > > > > The option is something else if i understand your usage case correctly... > sometimes the classes under hostgroup are classes from env X > and you can select a host in foreman which is env Y but with that same > hostgroup, you would get classes from env X (which do not exists in > the host env Y). > > so that option simply removes those classes that do not belong to the > current host running env. > > Ohad > > Thank you in advance. > > > > > > On Wednesday, January 23, 2013 11:08:58 AM UTC+2, ohad wrote: > >> > >> Hi, > >> > >> One of the last remaining issues for 1.1 release is how to handle > puppet > >> class assignment mismatch between environments, best by example: > >> > >> Hostgroup > >> name: Web Servers > >> Env: Production-V1 > >> Classes: apache, apache-monitor > >> > >> Host: > >> Name: A web server > >> Env: QA > >> Classes: apache, apache-monitor (inherited from hostgroup). > >> > >> What should foreman do if the QA env has no apache-monitor class? > >> so far, we always added it, and puppet silently ignored it (with the > >> traditional non parameterized format), however, starting with the new > enc > >> format, puppet now fails on non existing classes. > >> > >> we already have a ticket [1] and a fix [2], however I'm not sure that's > >> the right way to solve the problem. > >> > >> while I understand this can cause upset users, i do believe that if a > >> certain setup was not tested, it does makes sense to raise an error. > >> > >> however, from past discussions (mostly from CERN guys), I got the > >> understanding that this is not ideal, so my question breaks into two: > >> > >> 1. are there other usage cases that this model breaks that I didn't > >> consider here? > >> 2. what do you guys want to see happening: > >> a. puppet raise an error (e.g. missing class) > >> b. foreman removes all classes which are not in the env transparently > >> c. each hostgroup can assign classes to different environments > >> d. something else? > >> > >> > >> Thanks, > >> Ohad > >> > >> [1] http://projects.theforeman.org/issues/2124 > >> [2] https://github.com/theforeman/foreman/pull/382 > >> > >> > >> > > > > -- > > You received this message because you are subscribed to the Google > Groups > > "Foreman users" group. > > To unsubscribe from this group and stop receiving emails from it, send > an > > email to foreman-user...@googlegroups.com . > > > > To post to this group, send email to forema...@googlegroups.com. > > > Visit this group at http://groups.google.com/group/foreman-users?hl=en. > > For more options, visit https://groups.google.com/groups/opt_out. > > > > >

Sam_Kottler1 · January 24, 2013, 2:44pm

I also favor option B. I'm not necessarily opposed to A, but I think C would be very confusing because existing users that expect Foreman to be relatively strict about restraining classes inside environments for deployment and promotion purposes would be frustrated by the sudden change in validation behavior.

···

----- Original Message ----- From: "Brian Gupta" To: foreman-users@googlegroups.com Sent: Thursday, January 24, 2013 4:09:41 AM Subject: Re: [foreman-users] What to do when there is a hostgroup / host environment mismatch

On Thu, Jan 24, 2013 at 2:30 AM, Ohad Levy < ohadlevy@gmail.com > wrote:

On Thu, Jan 24, 2013 at 3:49 AM, Charlie Derwent < shelltoesuperstar@gmail.com > wrote:

Hi Ohad,

It’s a difficult one, as you know I support the “dont include missing hostgroup classes” stance in order to aid a logical development workflow in moving new classes from a Local Dev Env to a Shared Dev/Continous Integration Env to QA to Production. (i.e. manually add a class to a host for work on one sever, then when rolling out to multiple servers add the class to the appropriate hostgroup and update the next environment, test, update the next environment, test and so on…) as described by the CERN guys.

However, I can see where you/abenari are coming from in if someone didn’t know the class wasn’t in that env the error you plan to remove would have pointed it out to them.

1 - I can’t think of any use case the change would break other than the one above.

2 - I would prefer ‘b’, we already have the behaviour described in ‘a’ and ‘c’ would potentially lead to more confusion if foreman wasn’t consistant in defining the classes that belonged to a hostgroup.

I think the pull request is fine as you have it, but if you still want to warn people is there anywhere you can create a non-fatal warning maybe? foreman gui or in the puppet run? Or if you still wanted the puppet run to error could make the behaviour in your pull request an option you need to enable in somewhere like settings.yaml :ignore_missing_classes: false/true ?

I tend to agree, maybe extracting it as a settings is best…

This doesn’t impact us, but I agree that a setting is probably best, with the default set to legacy behavior.

What do you guys think?

Ohad

Regards,
Charlie

On Wed, Jan 23, 2013 at 9:08 AM, Ohad Levy < ohadlevy@gmail.com > wrote:

Hi,

One of the last remaining issues for 1.1 release is how to handle puppet class assignment mismatch between environments, best by example:

Hostgroup
name: Web Servers
Env: Production-V1
Classes: apache, apache-monitor

Host:
Name: A web server
Env: QA
Classes: apache, apache-monitor (inherited from hostgroup).

What should foreman do if the QA env has no apache-monitor class?
so far, we always added it, and puppet silently ignored it (with the traditional non parameterized format), however, starting with the new enc format, puppet now fails on non existing classes.

we already have a ticket [1] and a fix [2], however I’m not sure that’s the right way to solve the problem.

while I understand this can cause upset users, i do believe that if a certain setup was not tested, it does makes sense to raise an error.

however, from past discussions (mostly from CERN guys), I got the understanding that this is not ideal, so my question breaks into two:

are there other usage cases that this model breaks that I didn’t consider here?
what do you guys want to see happening:
a. puppet raise an error (e.g. missing class)
b. foreman removes all classes which are not in the env transparently
c. each hostgroup can assign classes to different environments
d. something else?

Thanks,
Ohad

[1] Bug #2124: dont include missing hostgroup classes when host is not in the same environment - Foreman
[2] https://github.com/theforeman/foreman/pull/382

–
You received this message because you are subscribed to the Google Groups “Foreman users” group.
To post to this group, send email to foreman-users@googlegroups.com .
To unsubscribe from this group, send email to foreman-users+unsubscribe@googlegroups.com .
For more options, visit this group at http://groups.google.com/group/foreman-users?hl=en .

–
You received this message because you are subscribed to the Google Groups “Foreman users” group.
To post to this group, send email to foreman-users@googlegroups.com .
To unsubscribe from this group, send email to foreman-users+unsubscribe@googlegroups.com .
Visit this group at http://groups.google.com/group/foreman-users?hl=en .
For more options, visit https://groups.google.com/groups/opt_out .

–

–
You received this message because you are subscribed to the Google Groups “Foreman users” group.
To post to this group, send email to foreman-users@googlegroups.com.
To unsubscribe from this group, send email to foreman-users+unsubscribe@googlegroups.com.
Visit this group at http://groups.google.com/group/foreman-users?hl=en .
For more options, visit https://groups.google.com/groups/opt_out .