Hello,
I've run into an issue with foreman.yaml file. The current behavior is
that Foreman uses the value from that file only for settings that were
initialized for the first time. Any other change for the key in
foreman.yaml is ignored (this is not true for the login setting, because
its value is accessed through SETTINGS constant). There is also issue
with cache, causing not default value to be used, but that's different
story (before I start fixing it I want to make sure the behavior is
correct).
I would expect that the value for foreman.yaml will be used as a default
and could be overridden through UI. But when it's not touched through
UI, the change in foreman.yaml should still be applied. What do you
thing about this? Otherwise it's quite non-standard behavior for file in
/etc directory.
Thanks
– Ivan
I don't think it's non-standard - I can find plenty of examples of
things that fit either model. For example:
Puppet - re-reads /etc/puppet/puppet.conf if it is changed
Apache - does not, needs a reload after config changes.
Both behaviours are acceptable, from an LSB standpoint. So I guess the
question is, what is the current behaviour breaking for you? (FTR, I
have no objection to changing it, just curious)
Greg
···
On 25 September 2012 14:24, Ivan Nečas wrote:
> Hello,
>
> I've run into an issue with foreman.yaml file. The current behavior is that
> Foreman uses the value from that file only for settings that were
> initialized for the first time. Any other change for the key in foreman.yaml
> is ignored (this is not true for the login setting, because its value is
> accessed through SETTINGS constant). There is also issue with cache, causing
> not default value to be used, but that's different story (before I start
> fixing it I want to make sure the behavior is correct).
>
> I would expect that the value for foreman.yaml will be used as a default and
> could be overridden through UI. But when it's not touched through UI, the
> change in foreman.yaml should still be applied. What do you thing about
> this? Otherwise it's quite non-standard behavior for file in /etc directory.
> Hello,
>
> I've run into an issue with foreman.yaml file. The current behavior is
> that Foreman uses the value from that file only for settings that were
> initialized for the first time. Any other change for the key in
> foreman.yaml is ignored (this is not true for the login setting, because
> its value is accessed through SETTINGS constant). There is also issue with
> cache, causing not default value to be used, but that's different story
> (before I start fixing it I want to make sure the behavior is correct).
>
You are right, this is a bug i've introduced after 1.0.x and thanks for
fixing it 
>
> I would expect that the value for foreman.yaml will be used as a default
> and could be overridden through UI. But when it's not touched through UI,
> the change in foreman.yaml should still be applied. What do you thing about
> this? Otherwise it's quite non-standard behavior for file in /etc directory.
>
Foreman settings breaks into two:
- core settings which effect the entire application
use authentication, provisioning is enabled or disabled, ssl is mandatory
etc.
- settings which can change while the application is running.
where 1 is config/settings.yaml file and 2. is the settings options under
more.
in the past, we only had option 1, ever since we moved into a db table,
however in order to provide an easy migration from one to another, when
generating the default value for a given setting, we might try to see if
there was a older value in the yaml file.
imho, the right way to update a setting is via the api, that should ensure
that the cache is updated correctly as well.
Ohad
···
On Tue, Sep 25, 2012 at 9:24 AM, Ivan Nečas wrote:
Thanks
– Ivan
>> Hello,
>>
>> I've run into an issue with foreman.yaml file. The current behavior is that
>> Foreman uses the value from that file only for settings that were
>> initialized for the first time. Any other change for the key in foreman.yaml
>> is ignored (this is not true for the login setting, because its value is
>> accessed through SETTINGS constant). There is also issue with cache, causing
>> not default value to be used, but that's different story (before I start
>> fixing it I want to make sure the behavior is correct).
>>
>> I would expect that the value for foreman.yaml will be used as a default and
>> could be overridden through UI. But when it's not touched through UI, the
>> change in foreman.yaml should still be applied. What do you thing about
>> this? Otherwise it's quite non-standard behavior for file in /etc directory.
> I don't think it's non-standard - I can find plenty of examples of
> things that fit either model. For example:
>
> Puppet - re-reads /etc/puppet/puppet.conf if it is changed
>
> Apache - does not, needs a reload after config changes.
The problem is it doesn't reload even on restart (stopping and starting
thin process). To be more specific, there is an option to set oauth
secret for Foreman (oauth_active, oauth_consumer_key,
oauth_consumer_secret, oauth_map_users). If you don't specify the values
before the first start, there is no way it would be loaded or changed
through the settings.yaml file.
– Ivan
···
On 09/25/2012 04:27 PM, Greg Sutcliffe wrote:
> On 25 September 2012 14:24, Ivan Nečas wrote:
>
> Both behaviours are acceptable, from an LSB standpoint. So I guess the
> question is, what is the current behaviour breaking for you? (FTR, I
> have no objection to changing it, just curious)
>
> Greg
–
Ivan
>
>
>
> Hello,
>
> I've run into an issue with foreman.yaml file. The current
> behavior is that Foreman uses the value from that file only for
> settings that were initialized for the first time. Any other
> change for the key in foreman.yaml is ignored (this is not true
> for the login setting, because its value is accessed through
> SETTINGS constant). There is also issue with cache, causing not
> default value to be used, but that's different story (before I
> start fixing it I want to make sure the behavior is correct).
>
>
> You are right, this is a bug i've introduced after 1.0.x and thanks
> for fixing it
>
>
> I would expect that the value for foreman.yaml will be used as a
> default and could be overridden through UI. But when it's not
> touched through UI, the change in foreman.yaml should still be
> applied. What do you thing about this? Otherwise it's quite
> non-standard behavior for file in /etc directory.
>
>
> Foreman settings breaks into two:
>
> 1. core settings which effect the entire application
> use authentication, provisioning is enabled or disabled, ssl is
> mandatory etc.
> 2. settings which can change while the application is running.
>
> where 1 is config/settings.yaml file and 2. is the settings options
> under more.
>
> in the past, we only had option 1, ever since we moved into a db
> table, however in order to provide an easy migration from one to
> another, when generating the default value for a given setting, we
> might try to see if there was a older value in the yaml file.
>
> imho, the right way to update a setting is via the api, that should
> ensure that the cache is updated correctly as well.
That's sounds right except one case: oauth settings. If you want to set
it up through API and want use oauth as the auth method, you have a
chick and egg problem. Which is exactly what i'm dealing with right now.
I will try to came up with the script and send it with pull request soon
– Ivan
···
On 09/26/2012 01:26 AM, Ohad Levy wrote:
> On Tue, Sep 25, 2012 at 9:24 AM, Ivan Nečas > <necasik@gmail.com > wrote:
>
> Ohad
>
> Thanks
>
> -- Ivan
>
>
Just to sum our findings from IRC:
Changing settings.yaml works fine after a restart of the service, as expected.
However, if you change the Settings table in the DB (using an SQL
console), the cache prevents Foreman from noticing the change. Te
easiest way to reproduce this is to play with the enc_environment
setting:
- Open up the YAML for a host - see that the "environment" key is present.
- Use the DB console to change "enc_environment" to "— false"
- Reload the YAML - "environment" is still present
The cache even survives a complete restart (stop ; start) of Foreman.
The cleanest solution seems to be to write a script to alter the
Settings on the commandline, by hooking into the Settings model and
using the correct setter which will handle both the DB and the cache.
Greg
>>
>>
>>
>> Hello,
>>
>> I've run into an issue with foreman.yaml file. The current
>> behavior is that Foreman uses the value from that file only for
>> settings that were initialized for the first time. Any other
>> change for the key in foreman.yaml is ignored (this is not true
>> for the login setting, because its value is accessed through
>> SETTINGS constant). There is also issue with cache, causing not
>> default value to be used, but that's different story (before I
>> start fixing it I want to make sure the behavior is correct).
>>
>>
>> You are right, this is a bug i've introduced after 1.0.x and thanks
>> for fixing it 
>>
>>
>> I would expect that the value for foreman.yaml will be used as a
>> default and could be overridden through UI. But when it's not
>> touched through UI, the change in foreman.yaml should still be
>> applied. What do you thing about this? Otherwise it's quite
>> non-standard behavior for file in /etc directory.
>>
>>
>> Foreman settings breaks into two:
>>
>> 1. core settings which effect the entire application
>> use authentication, provisioning is enabled or disabled, ssl is
>> mandatory etc.
>> 2. settings which can change while the application is running.
>>
>> where 1 is config/settings.yaml file and 2. is the settings options
>> under more.
>>
>> in the past, we only had option 1, ever since we moved into a db
>> table, however in order to provide an easy migration from one to
>> another, when generating the default value for a given setting, we
>> might try to see if there was a older value in the yaml file.
>>
>> imho, the right way to update a setting is via the api, that should
>> ensure that the cache is updated correctly as well.
> That's sounds right except one case: oauth settings. If you want to
> set it up through API and want use oauth as the auth method, you have
> a chick and egg problem. Which is exactly what i'm dealing with right
> now. I will try to came up with the script and send it with pull
> request soon
as promised, the PR landed to repo yesterday
https://github.com/theforeman/foreman/pull/161
– Ivan
···
On 09/26/2012 11:26 AM, Ivan Nečas wrote:
> On 09/26/2012 01:26 AM, Ohad Levy wrote:
>> On Tue, Sep 25, 2012 at 9:24 AM, Ivan Nečas >> <necasik@gmail.com > wrote:
>
> -- Ivan
>>
>> Ohad
>>
>> Thanks
>>
>> -- Ivan
>>
>>
>
