Possible API bug with inheritable values, second set of eyes?

In Foreman 1.7, if I PUT to /api/hosts/:id with the following body, it set
the "nil" values to inherit from their hostgroup. As of Foreman 1.10, the
values are actually set to nil, which causes provisioning to fail. Shall I
file a bug, or am I doing this wrong:

body = {
:name => new_name,
:owner_id => nil,
:environment_id => nil,
:puppet_proxy_id => nil,
:puppet_ca_proxy_id => nil,
:overwrite => true,
}
result = @client.put(:path => "/api/hosts/#{host_id}", :body => {:host =>
body}.to_json)

Thanks,
Aaron

Uh, so in the web UI, now there is an Inherit button for those items
(Environment, Puppet CA, Puppet Master, etc.) and if you click Inherit it
actually explicitly enters the Hostgroup's value in the Host.

This is not OK, because now if I change that value at the Hostgroup level,
it will fail to propagate to the Hosts because they have an explicit value,
when I was expected them to inherit the value, including inherit a new
value if I change it in the only one place where I want that value set, at
the Hostgroup.

Am I stumbling over Bug #12936: Hostgroup environment isn't inherited by Host via model API - Foreman ?

··· On Wed, Jan 6, 2016 at 4:04 PM, Aaron Stone wrote:

In Foreman 1.7, if I PUT to /api/hosts/:id with the following body, it set
the “nil” values to inherit from their hostgroup. As of Foreman 1.10, the
values are actually set to nil, which causes provisioning to fail. Shall I
file a bug, or am I doing this wrong:

body = {
:name => new_name,
:owner_id => nil,
:environment_id => nil,
:puppet_proxy_id => nil,
:puppet_ca_proxy_id => nil,
:overwrite => true,
}
result = @client.put(:path => “/api/hosts/#{host_id}”, :body => {:host
=> body}.to_json)

Thanks,
Aaron

To be clear on what it means that provisioning fails for me, I mean that if
the value of environment_id is NULL for a Host, then using
@host.environment in a Template is nil.

What I expect is that if the Host's environment_id is NULL, then
@host.environment will return the value from @host.hostgroup.environment.

··· On Wed, Jan 6, 2016 at 4:08 PM, Aaron Stone wrote:

Uh, so in the web UI, now there is an Inherit button for those items
(Environment, Puppet CA, Puppet Master, etc.) and if you click Inherit it
actually explicitly enters the Hostgroup’s value in the Host.

This is not OK, because now if I change that value at the Hostgroup level,
it will fail to propagate to the Hosts because they have an explicit value,
when I was expected them to inherit the value, including inherit a new
value if I change it in the only one place where I want that value set, at
the Hostgroup.

Am I stumbling over Bug #12936: Hostgroup environment isn't inherited by Host via model API - Foreman ?

On Wed, Jan 6, 2016 at 4:04 PM, Aaron Stone sodabrew@gmail.com wrote:

In Foreman 1.7, if I PUT to /api/hosts/:id with the following body, it
set the “nil” values to inherit from their hostgroup. As of Foreman 1.10,
the values are actually set to nil, which causes provisioning to fail.
Shall I file a bug, or am I doing this wrong:

body = {
:name => new_name,
:owner_id => nil,
:environment_id => nil,
:puppet_proxy_id => nil,
:puppet_ca_proxy_id => nil,
:overwrite => true,
}
result = @client.put(:path => “/api/hosts/#{host_id}”, :body => {:host
=> body}.to_json)

Thanks,
Aaron

> To be clear on what it means that provisioning fails for me, I mean that
> if the value of environment_id is NULL for a Host, then using
> @host.environment in a Template is nil.
>
> What I expect is that if the Host's environment_id is NULL, then
> @host.environment will return the value from @host.hostgroup.environment.
>
>
> Uh, so in the web UI, now there is an Inherit button for those items
> (Environment, Puppet CA, Puppet Master, etc.) and if you click
> Inherit it actually explicitly enters the Hostgroup's value in the Host.
>
> This is not OK, because now if I change that value at the Hostgroup
> level, it will fail to propagate to the Hosts because they have an
> explicit value, when I was expected them to inherit the value,
> including inherit a new value if I change it in the only one place
> where I want that value set, at the Hostgroup.

I didn't think this had ever been the behaviour. Host creation has
always worked by copying attributes from the host group to the host, and
only Puppet classes etc. are inherited on the fly. Everything else,
such as environment, masters, OSes was copied.

I wouldn't expect (though it'd be a nice possibility, I'm certain) for
an attribute to be set to nil on the host and it continually inherit the
value from the group. Even in 1.7, I'd expect it to fill in the
environment_id on the host when saved from the group.

> Am I stumbling over Bug #12936: Hostgroup environment isn't inherited by Host via model API - Foreman ?

I don't think so, this is specifically when creating a host with the
'environment' and not 'environment_id' attribute, seems to be different.

··· On 07/01/16 00:24, Aaron Stone wrote: > On Wed, Jan 6, 2016 at 4:08 PM, Aaron Stone > wrote:


Dominic Cleal
dominic@cleal.org

> > To be clear on what it means that provisioning fails for me, I mean that
> > if the value of environment_id is NULL for a Host, then using
> > @host.environment in a Template is nil.
> >
> > What I expect is that if the Host's environment_id is NULL, then
> > @host.environment will return the value from @host.hostgroup.environment.
> >
> >
> > Uh, so in the web UI, now there is an Inherit button for those items
> > (Environment, Puppet CA, Puppet Master, etc.) and if you click
> > Inherit it actually explicitly enters the Hostgroup's value in the
> Host.
> >
> > This is not OK, because now if I change that value at the Hostgroup
> > level, it will fail to propagate to the Hosts because they have an
> > explicit value, when I was expected them to inherit the value,
> > including inherit a new value if I change it in the only one place
> > where I want that value set, at the Hostgroup.
>
> I didn't think this had ever been the behaviour. Host creation has
> always worked by copying attributes from the host group to the host, and
> only Puppet classes etc. are inherited on the fly. Everything else,
> such as environment, masters, OSes was copied.
>
> I wouldn't expect (though it'd be a nice possibility, I'm certain) for
> an attribute to be set to nil on the host and it continually inherit the
> value from the group. Even in 1.7, I'd expect it to fill in the
> environment_id on the host when saved from the group.
>

I double checked my data, and you're right - the value is copied from the
Hostgroup at the time that the Host is saved with an Inherit for those
values.

So the bug is more narrow: a null value for those keys to the API used to
mean "replace with the inherited value" and now it means "actually set to
null".

If it actually makes sense to allow null values, and so the current
behavior is actually a fix from the old behavior, then I'll need to adjust
my client code to do its own host -> hostgroup lookup and copy over the
values on the client side :confused:

> > Am I stumbling over Bug #12936: Hostgroup environment isn't inherited by Host via model API - Foreman ?
>
> I don't think so, this is specifically when creating a host with the
> 'environment' and not 'environment_id' attribute, seems to be different.
>

I re-read the bug, and it is indeed totally different.

Thanks,
Aaron

··· On Thu, Jan 7, 2016 at 12:14 AM, Dominic Cleal wrote: > On 07/01/16 00:24, Aaron Stone wrote: > > On Wed, Jan 6, 2016 at 4:08 PM, Aaron Stone > > wrote:

>
> > To be clear on what it means that provisioning fails for me, I mean that
> > if the value of environment_id is NULL for a Host, then using
> > @host.environment in a Template is nil.
> >
> > What I expect is that if the Host's environment_id is NULL, then
> > @host.environment will return the value from @host.hostgroup.environment.
> >
> >
> > Uh, so in the web UI, now there is an Inherit button for those items
> > (Environment, Puppet CA, Puppet Master, etc.) and if you click
> > Inherit it actually explicitly enters the Hostgroup's value in the Host.
> >
> > This is not OK, because now if I change that value at the Hostgroup
> > level, it will fail to propagate to the Hosts because they have an
> > explicit value, when I was expected them to inherit the value,
> > including inherit a new value if I change it in the only one place
> > where I want that value set, at the Hostgroup.
>
> I didn't think this had ever been the behaviour. Host creation has
> always worked by copying attributes from the host group to the host, and
> only Puppet classes etc. are inherited on the fly. Everything else,
> such as environment, masters, OSes was copied.
>
> I wouldn't expect (though it'd be a nice possibility, I'm certain) for
> an attribute to be set to nil on the host and it continually inherit the
> value from the group. Even in 1.7, I'd expect it to fill in the
> environment_id on the host when saved from the group.
>
>
> I double checked my data, and you're right - the value is copied from
> the Hostgroup at the time that the Host is saved with an Inherit for
> those values.
>
> So the bug is more narrow: a null value for those keys to the API used
> to mean "replace with the inherited value" and now it means "actually
> set to null".

Yes, I think that's true. It became possible to leave those attributes
unset instead of them being unilaterally copied from the host group.

> If it actually makes sense to allow null values, and so the current
> behavior is actually a fix from the old behavior, then I'll need to
> adjust my client code to do its own host -> hostgroup lookup and copy
> over the values on the client side :confused:

Or leave the keys out of the API call entirely and it should copy any
attributes that aren't explicitly set by default.

··· On 07/01/16 09:35, Aaron Stone wrote: > On Thu, Jan 7, 2016 at 12:14 AM, Dominic Cleal > wrote: > On 07/01/16 00:24, Aaron Stone wrote: > > On Wed, Jan 6, 2016 at 4:08 PM, Aaron Stone <sodabrew@gmail.com > > <mailto:sodabrew@gmail.com >> wrote:


Dominic Cleal
dominic@cleal.org