cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Huang <Alex.Hu...@citrix.com>
Subject RE: ConfigDepot and null values and defaults
Date Fri, 13 Sep 2013 20:04:20 GMT


> -----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

Mime
View raw message