Interesting little bug I came across today using 1.5.1. So the setup, I was provisioning a replacement puppet master to replace an old one. Nested host groups were set up to inherit master and CA from the root node. I adjusted said root to point at the new master smart proxy, but alas this was not reflected in the ENC YAML. After some digging I noted the host table referenced the hostgroup, which indeed had the master I desired, but I also noted that the smart proxy ID was replicated locally in the host table. This second source of truth had, surprise surprise, not been updated with the hostgroup.
2 things.
- anyone aware of this already?
- if not I can open a defect. I reckon the right thing to do is normalize away the duplication as it leads to bugs like this, but obviously I open the floor to the community borg collective! Ugh, that database course in uni was relevant
···
--
DataCentred Limited registered in England and Wales no. 05611763
Yeah, this behaviour is expected. If you think of the host group as a
set of defaults that are used for host creation, it makes a bit more
sense. Once a host is created, it inherits the current value of these
attributes and they're copied as you say.
The only exception to this school of thought is Puppet class
associations, which continue to be inherited through the host group
throughout the host's life.
Of course, this makes bulk-changing attributes on hosts difficult in
Foreman, which is a common problem.
···
On 19/06/14 18:22, Simon Murray wrote:
> Interesting little bug I came across today using 1.5.1. So the setup, I was provisioning a replacement puppet master to replace an old one. Nested host groups were set up to inherit master and CA from the root node. I adjusted said root to point at the new master smart proxy, but alas this was not reflected in the ENC YAML. After some digging I noted the host table referenced the hostgroup, which indeed had the master I desired, but I also noted that the smart proxy ID was replicated locally in the host table. This second source of truth had, surprise surprise, not been updated with the hostgroup.
>
> 2 things.
>
> 1) anyone aware of this already?
> 2) if not I can open a defect. I reckon the right thing to do is normalize away the duplication as it leads to bugs like this, but obviously I open the floor to the community borg collective! Ugh, that database course in uni was relevant :-)
–
Dominic Cleal
Red Hat Engineering
Cheers Dom. Noting a well crafted SQL UPDATE can't solve 
Naughty as it
makes me feel deep inside
So, I got to thinking a little bit more. I can see the logic in allowing
overrides at the host level, which supports the current thinking. Makes
sense if you want to explicitly assign a master/ca for whatever nefarious
purpose. What do we reckon to supporting the notion of if field X is NULL
then follow the indirection through to the host group (if there is one
assigned for the case where discovered hosts haven't been provisioned) and
get your values from there? Inheritance works better for how my mind
works, but perhaps as you say a bulk update with filter thingy would
suffice. Either or
···
On 23 June 2014 08:26, Dominic Cleal wrote:
On 19/06/14 18:22, Simon Murray wrote:
Interesting little bug I came across today using 1.5.1. So the setup, I
was provisioning a replacement puppet master to replace an old one. Nested
host groups were set up to inherit master and CA from the root node. I
adjusted said root to point at the new master smart proxy, but alas this
was not reflected in the ENC YAML. After some digging I noted the host
table referenced the hostgroup, which indeed had the master I desired, but
I also noted that the smart proxy ID was replicated locally in the host
table. This second source of truth had, surprise surprise, not been updated
with the hostgroup.
2 things.
- anyone aware of this already?
- if not I can open a defect. I reckon the right thing to do is
normalize away the duplication as it leads to bugs like this, but obviously
I open the floor to the community borg collective! Ugh, that database
course in uni was relevant
Yeah, this behaviour is expected. If you think of the host group as a
set of defaults that are used for host creation, it makes a bit more
sense. Once a host is created, it inherits the current value of these
attributes and they’re copied as you say.
The only exception to this school of thought is Puppet class
associations, which continue to be inherited through the host group
throughout the host’s life.
Of course, this makes bulk-changing attributes on hosts difficult in
Foreman, which is a common problem.
–
Dominic Cleal
Red Hat Engineering
–
You received this message because you are subscribed to a topic in the
Google Groups “Foreman users” group.
To unsubscribe from this topic, visit
https://groups.google.com/d/topic/foreman-users/NzqBScCBGN8/unsubscribe.
To unsubscribe from this group and all its topics, 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.
For more options, visit https://groups.google.com/d/optout.
–
DataCentred Limited registered in England and Wales no. 05611763
+1 for a way to support Puppetmaster and Puppet CA being optionally only
defined at the hostgroup level or a way to change them in bulk. Ran into
this issue today when moving to a separate Puppet CA.
Modifying them in Rails console works too and feels less wrong.
SmartProxy ID for old Puppetmaster - 1
SmartProxy ID for new Puppetmaster - 1
Host.where(:puppet_proxy_id => 1).update_all(:puppet_proxy_id => 5)
Same type of idea can be applied to Hostgroup class and then manually set
the desired master / ca in UI for "base" hostgroup.
···
On Monday, June 23, 2014 3:03:45 AM UTC-5, Simon Murray wrote:
>
> Cheers Dom. Noting a well crafted SQL UPDATE can't solve :) Naughty as it
> makes me feel deep inside
>
> So, I got to thinking a little bit more. I can see the logic in allowing
> overrides at the host level, which supports the current thinking. Makes
> sense if you want to explicitly assign a master/ca for whatever nefarious
> purpose. What do we reckon to supporting the notion of if field X is NULL
> then follow the indirection through to the host group (if there is one
> assigned for the case where discovered hosts haven't been provisioned) and
> get your values from there? Inheritance works better for how my mind
> works, but perhaps as you say a bulk update with filter thingy would
> suffice. Either or
>
>
> On 23 June 2014 08:26, Dominic Cleal <dcle...@redhat.com > > wrote:
>
>> On 19/06/14 18:22, Simon Murray wrote:
>> > Interesting little bug I came across today using 1.5.1. So the setup, I
>> was provisioning a replacement puppet master to replace an old one. Nested
>> host groups were set up to inherit master and CA from the root node. I
>> adjusted said root to point at the new master smart proxy, but alas this
>> was not reflected in the ENC YAML. After some digging I noted the host
>> table referenced the hostgroup, which indeed had the master I desired, but
>> I also noted that the smart proxy ID was replicated locally in the host
>> table. This second source of truth had, surprise surprise, not been updated
>> with the hostgroup.
>> >
>> > 2 things.
>> >
>> > 1) anyone aware of this already?
>> > 2) if not I can open a defect. I reckon the right thing to do is
>> normalize away the duplication as it leads to bugs like this, but obviously
>> I open the floor to the community borg collective! Ugh, that database
>> course in uni was relevant :-)
>>
>> Yeah, this behaviour is expected. If you think of the host group as a
>> set of defaults that are used for host creation, it makes a bit more
>> sense. Once a host is created, it inherits the current value of these
>> attributes and they're copied as you say.
>>
>> The only exception to this school of thought is Puppet class
>> associations, which continue to be inherited through the host group
>> throughout the host's life.
>>
>> Of course, this makes bulk-changing attributes on hosts difficult in
>> Foreman, which is a common problem.
>>
>> --
>> Dominic Cleal
>> Red Hat Engineering
>>
>> --
>> You received this message because you are subscribed to a topic in the
>> Google Groups "Foreman users" group.
>> To unsubscribe from this topic, visit
>> https://groups.google.com/d/topic/foreman-users/NzqBScCBGN8/unsubscribe.
>> To unsubscribe from this group and all its topics, 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.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
> DataCentred Limited registered in England and Wales no. 05611763
