You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cloudstack.apache.org by Darren Shepherd <da...@gmail.com> on 2013/09/13 10:10:29 UTC
ConfigDepot and null values and defaults
If you have a configuration that the value is null and not dynamic, it
still hits the database on every read. I'm thinking that's really not
intentional.
Additionally, if I have a key that is default value is 5, then I later
change the default to 10. If the user never changed or set the value, I
still get 5. So this is where I kind of disagree with the implementation.
What I'd ideally like to see is that only when a value is explicitly
changed do we ever persist an entry to the configuration table. Now I
know that doesn't work with the current code as everything just hits the
ConfigurationDao, but ideally I'd like to see it that way. With the
current implementation we have no way of really knowing of the field
which were changed by somebody.
What I'd like to get to is that we can have a config page sort of like
about:config in firefox. In firefox there is a "status" column that is
"default" or "user set". So as a user I know all the crap I changed,
and easily I can revert to the defaults.
So if we stick with the current implementation where we throw everything
in the DB (which I assume we will), then maybe we should have a column
for "user set."
And also randomly, why is updated column == null mean that its obsolete?
I don't see any code to handle that, just the column description.
Darren
Re: ConfigDepot and null values and defaults
Posted by Darren Shepherd <da...@gmail.com>.
Honestly, doesn't really matter that much. Just as long as I understand the intended behavior.
Darren
On Sep 13, 2013, at 5:41 PM, Darren Shepherd <da...@gmail.com> wrote:
> Alex,
>
> Here's my general problem. I like to make just about everything configurable, but the reality is that only about 5% of setting will ever matter to people. So these are really internal flags to tweak things. So for stuff like that I don't want the first ever default I chose to be saved forever. Or even the persisted to the DB really. So it's like the difference between the preferences dialog in Firefox and about:config. Where can I put my "this may void your warranty" settings?
>
> Darren
>
> On Sep 13, 2013, at 1:04 PM, Alex Huang <Al...@citrix.com> wrote:
>
>>
>>
>>> -----Original Message-----
>>> From: Darren Shepherd [mailto:darren.s.shepherd@gmail.com]
>>> Sent: Friday, September 13, 2013 1:10 AM
>>> To: dev@cloudstack.apache.org; Alex Huang
>>> Subject: ConfigDepot and null values and defaults
>>>
>>> If you have a configuration that the value is null and not dynamic, it still hits
>>> the database on every read. I'm thinking that's really not intentional.
>>
>> I'll have to look at that when I come back from vacation. I see a check in the code for dynamic before rereading from the dao. Not sure why it's hitting the db on every read.
>>
>>>
>>> Additionally, if I have a key that is default value is 5, then I later change the
>>> default to 10. If the user never changed or set the value, I still get 5. So this
>>> is where I kind of disagree with the implementation.
>>
>> That's intentional. Think of an user who already deployed CloudStack and then he upgrades. The default has changed in the next version but it doesn't make sense for us to automatically adjust the value that the user was using before. It can significantly change their system's behavior. I've talked about this in the wiki. We do update the default value but not the value but we change the update column with a timestamp. They can use that to figure out whether a config parameter's default value has changed from the value that they were using before.
>>
>> Now, there's a difference in changing default values and a feature really need the value to be changed to the new default value in order for it to be useful. If a feature really needs the value to be now set to the new standard or else it has problems, that's an upgrade problem and should be handled in the upgrade portion of the feature.
>>
>>>
>>> What I'd ideally like to see is that only when a value is explicitly changed do
>>> we ever persist an entry to the configuration table. Now I know that doesn't
>>> work with the current code as everything just hits the ConfigurationDao, but
>>> ideally I'd like to see it that way. With the current implementation we have
>>> no way of really knowing of the field which were changed by somebody.
>>
>> I think persisting everything to the configuration table does have its advantages. For one thing, it becomes a central place for everyone to look for config parameters. To achieve what you want, you can persist the row but always leave the value field empty to mean it was not edited by the sysadmin. Of course, I generally don't believe that should be the case due to what I said above. I think someone using a previous version can get a rude awakening if they just update and suddenly things changed on them.
>>
>>>
>>> What I'd like to get to is that we can have a config page sort of like
>>> about:config in firefox. In firefox there is a "status" column that is "default"
>>> or "user set". So as a user I know all the crap I changed, and easily I can
>>> revert to the defaults.
>>>
>>> So if we stick with the current implementation where we throw everything in
>>> the DB (which I assume we will), then maybe we should have a column for
>>> "user set."
>>>
>>> And also randomly, why is updated column == null mean that its obsolete?
>>> I don't see any code to handle that, just the column description.
>> This is documented as one of the todos. The code hasn't been added yet.
>>
>> --Alex
Re: ConfigDepot and null values and defaults
Posted by Darren Shepherd <da...@gmail.com>.
Alex,
Here's my general problem. I like to make just about everything configurable, but the reality is that only about 5% of setting will ever matter to people. So these are really internal flags to tweak things. So for stuff like that I don't want the first ever default I chose to be saved forever. Or even the persisted to the DB really. So it's like the difference between the preferences dialog in Firefox and about:config. Where can I put my "this may void your warranty" settings?
Darren
On Sep 13, 2013, at 1:04 PM, Alex Huang <Al...@citrix.com> wrote:
>
>
>> -----Original Message-----
>> From: Darren Shepherd [mailto:darren.s.shepherd@gmail.com]
>> Sent: Friday, September 13, 2013 1:10 AM
>> To: dev@cloudstack.apache.org; Alex Huang
>> Subject: ConfigDepot and null values and defaults
>>
>> If you have a configuration that the value is null and not dynamic, it still hits
>> the database on every read. I'm thinking that's really not intentional.
>
> I'll have to look at that when I come back from vacation. I see a check in the code for dynamic before rereading from the dao. Not sure why it's hitting the db on every read.
>
>>
>> Additionally, if I have a key that is default value is 5, then I later change the
>> default to 10. If the user never changed or set the value, I still get 5. So this
>> is where I kind of disagree with the implementation.
>
> That's intentional. Think of an user who already deployed CloudStack and then he upgrades. The default has changed in the next version but it doesn't make sense for us to automatically adjust the value that the user was using before. It can significantly change their system's behavior. I've talked about this in the wiki. We do update the default value but not the value but we change the update column with a timestamp. They can use that to figure out whether a config parameter's default value has changed from the value that they were using before.
>
> Now, there's a difference in changing default values and a feature really need the value to be changed to the new default value in order for it to be useful. If a feature really needs the value to be now set to the new standard or else it has problems, that's an upgrade problem and should be handled in the upgrade portion of the feature.
>
>>
>> What I'd ideally like to see is that only when a value is explicitly changed do
>> we ever persist an entry to the configuration table. Now I know that doesn't
>> work with the current code as everything just hits the ConfigurationDao, but
>> ideally I'd like to see it that way. With the current implementation we have
>> no way of really knowing of the field which were changed by somebody.
>
> I think persisting everything to the configuration table does have its advantages. For one thing, it becomes a central place for everyone to look for config parameters. To achieve what you want, you can persist the row but always leave the value field empty to mean it was not edited by the sysadmin. Of course, I generally don't believe that should be the case due to what I said above. I think someone using a previous version can get a rude awakening if they just update and suddenly things changed on them.
>
>>
>> What I'd like to get to is that we can have a config page sort of like
>> about:config in firefox. In firefox there is a "status" column that is "default"
>> or "user set". So as a user I know all the crap I changed, and easily I can
>> revert to the defaults.
>>
>> So if we stick with the current implementation where we throw everything in
>> the DB (which I assume we will), then maybe we should have a column for
>> "user set."
>>
>> And also randomly, why is updated column == null mean that its obsolete?
>> I don't see any code to handle that, just the column description.
> This is documented as one of the todos. The code hasn't been added yet.
>
> --Alex
RE: ConfigDepot and null values and defaults
Posted by Alex Huang <Al...@citrix.com>.
> -----Original Message-----
> From: Darren Shepherd [mailto:darren.s.shepherd@gmail.com]
> Sent: Friday, September 13, 2013 1:10 AM
> To: dev@cloudstack.apache.org; Alex Huang
> Subject: ConfigDepot and null values and defaults
>
> If you have a configuration that the value is null and not dynamic, it still hits
> the database on every read. I'm thinking that's really not intentional.
I'll have to look at that when I come back from vacation. I see a check in the code for dynamic before rereading from the dao. Not sure why it's hitting the db on every read.
>
> Additionally, if I have a key that is default value is 5, then I later change the
> default to 10. If the user never changed or set the value, I still get 5. So this
> is where I kind of disagree with the implementation.
That's intentional. Think of an user who already deployed CloudStack and then he upgrades. The default has changed in the next version but it doesn't make sense for us to automatically adjust the value that the user was using before. It can significantly change their system's behavior. I've talked about this in the wiki. We do update the default value but not the value but we change the update column with a timestamp. They can use that to figure out whether a config parameter's default value has changed from the value that they were using before.
Now, there's a difference in changing default values and a feature really need the value to be changed to the new default value in order for it to be useful. If a feature really needs the value to be now set to the new standard or else it has problems, that's an upgrade problem and should be handled in the upgrade portion of the feature.
>
> What I'd ideally like to see is that only when a value is explicitly changed do
> we ever persist an entry to the configuration table. Now I know that doesn't
> work with the current code as everything just hits the ConfigurationDao, but
> ideally I'd like to see it that way. With the current implementation we have
> no way of really knowing of the field which were changed by somebody.
I think persisting everything to the configuration table does have its advantages. For one thing, it becomes a central place for everyone to look for config parameters. To achieve what you want, you can persist the row but always leave the value field empty to mean it was not edited by the sysadmin. Of course, I generally don't believe that should be the case due to what I said above. I think someone using a previous version can get a rude awakening if they just update and suddenly things changed on them.
>
> What I'd like to get to is that we can have a config page sort of like
> about:config in firefox. In firefox there is a "status" column that is "default"
> or "user set". So as a user I know all the crap I changed, and easily I can
> revert to the defaults.
>
> So if we stick with the current implementation where we throw everything in
> the DB (which I assume we will), then maybe we should have a column for
> "user set."
>
> And also randomly, why is updated column == null mean that its obsolete?
> I don't see any code to handle that, just the column description.
This is documented as one of the todos. The code hasn't been added yet.
--Alex