Default values in the model

classic Classic list List threaded Threaded
19 messages Options
Reply | Threaded
Open this post in threaded view
|

Default values in the model

Brian Stansberry
Emanuel,

Or chat yesterday about the downsides of storing default values in the
in-memory management model got me thinking a bit.

Downsides:

1) The in-memory model no longer represents the user configuration
values; it also stores defaults. This is an issue when marshalling back
to xml; you either have to make the xml verbose by writing back all the
defaults, or you don't write back defaults and lose the fact the user
included the value in the original.

2) Possible versioning issues in a domain where different hosts run
different versions; i.e. if the version on the domain controller host
stores and pushes to servers a default value that a server running an
earlier version doesn't understand.  This would really be a bug, since a
change in a default value should spur an increment in the subsystem's
schema and appropriate handling by the parser. But still, storing
defaults increases the chances of this kind of bug cropping up.

Possible solution:

What's been requested previously is that management clients be able to
see the default values, without having to go read the resource
description metadata to find them. That request can be satisfied via the
read-resource and read-attribute handlers. There is no need to store the
default in the model; those handlers can read the resource description
metadata to find the default if the model doesn't have a value stored.

That will slow those handlers down a little bit since the description
has to be generated and read, but those handlers aren't called as part
of our internal operations (e.g. boot) so doing it that way won't slow
down boot, deployment etc.

An issue that doing it this way raises is a client calling read-resource
or read-attribute doesn't know if the returned value is the actual user
config or is a default. A solution to that is to have those operations
accept a new parameter "defaults" which if false does not include the
defaults.

I'm not sure what the best default value for that "default" param would
be. My instinct is "true".

WDYT?

--
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Default values in the model

David Bosschaert
On 29/07/2011 01:31, Brian Stansberry wrote:

> Emanuel,
>
> Or chat yesterday about the downsides of storing default values in the
> in-memory management model got me thinking a bit.
>
> Downsides:
>
> 1) The in-memory model no longer represents the user configuration
> values; it also stores defaults. This is an issue when marshalling back
> to xml; you either have to make the xml verbose by writing back all the
> defaults, or you don't write back defaults and lose the fact the user
> included the value in the original.
>
> 2) Possible versioning issues in a domain where different hosts run
> different versions; i.e. if the version on the domain controller host
> stores and pushes to servers a default value that a server running an
> earlier version doesn't understand.  This would really be a bug, since a
> change in a default value should spur an increment in the subsystem's
> schema and appropriate handling by the parser. But still, storing
> defaults increases the chances of this kind of bug cropping up.
>
> Possible solution:
>
> What's been requested previously is that management clients be able to
> see the default values, without having to go read the resource
> description metadata to find them. That request can be satisfied via the
> read-resource and read-attribute handlers. There is no need to store the
> default in the model; those handlers can read the resource description
> metadata to find the default if the model doesn't have a value stored.
>
> That will slow those handlers down a little bit since the description
> has to be generated and read, but those handlers aren't called as part
> of our internal operations (e.g. boot) so doing it that way won't slow
> down boot, deployment etc.
>
> An issue that doing it this way raises is a client calling read-resource
> or read-attribute doesn't know if the returned value is the actual user
> config or is a default. A solution to that is to have those operations
> accept a new parameter "defaults" which if false does not include the
> defaults.
>
> I'm not sure what the best default value for that "default" param would
> be. My instinct is "true".
>
> WDYT?
>

I personally wouldn't do this. I would leave the default out of the
read-resource etc result. That would keep things clear. When you obtain
the model you'll see that the value isn't specified. A management client
can easily also obtain the default from the description and nicely
present this to the user. The management client may actually want to
mark the default value as such for the users in a slightly different way
so having it come in somewhat separate can actually be helpful I think.

My 2c,

David

_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Default values in the model

Heiko W.Rupp

Am 29.07.2011 um 09:43 schrieb David Bosschaert:
> the model you'll see that the value isn't specified. A management client
> can easily also obtain the default from the description and nicely

Sorry, to be sarcastic here, but it can't, as most of the subsystem do not
provide that info correctly or at all.

And even if the model provides a default value of '3' for e.g. a timeout,
no one knows e.g. the unit here.

Also if :read-resource or :read-attribute returns "undefined" for an attribute and
then next to it, it provides the default value, why couldn't it then just return the
default instead of "unknown"?

  Heiko



_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Default values in the model

David Bosschaert
On 29/07/2011 08:52, Heiko W.Rupp wrote:
> Am 29.07.2011 um 09:43 schrieb David Bosschaert:
>> the model you'll see that the value isn't specified. A management client
>> can easily also obtain the default from the description and nicely
> Sorry, to be sarcastic here, but it can't, as most of the subsystem do not
> provide that info correctly or at all.

So that should obviously be fixed.

> And even if the model provides a default value of '3' for e.g. a timeout,
> no one knows e.g. the unit here.

I actually wondered about this too. Why don't we add a unit descriptor
in there as well?
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Default values in the model

Brian Stansberry
In reply to this post by David Bosschaert
On 7/29/11 3:43 PM, David Bosschaert wrote:

> On 29/07/2011 01:31, Brian Stansberry wrote:
>> Emanuel,
>>
>> Or chat yesterday about the downsides of storing default values in the
>> in-memory management model got me thinking a bit.
>>
>> Downsides:
>>
>> 1) The in-memory model no longer represents the user configuration
>> values; it also stores defaults. This is an issue when marshalling back
>> to xml; you either have to make the xml verbose by writing back all the
>> defaults, or you don't write back defaults and lose the fact the user
>> included the value in the original.
>>
>> 2) Possible versioning issues in a domain where different hosts run
>> different versions; i.e. if the version on the domain controller host
>> stores and pushes to servers a default value that a server running an
>> earlier version doesn't understand. This would really be a bug, since a
>> change in a default value should spur an increment in the subsystem's
>> schema and appropriate handling by the parser. But still, storing
>> defaults increases the chances of this kind of bug cropping up.
>>
>> Possible solution:
>>
>> What's been requested previously is that management clients be able to
>> see the default values, without having to go read the resource
>> description metadata to find them. That request can be satisfied via the
>> read-resource and read-attribute handlers. There is no need to store the
>> default in the model; those handlers can read the resource description
>> metadata to find the default if the model doesn't have a value stored.
>>
>> That will slow those handlers down a little bit since the description
>> has to be generated and read, but those handlers aren't called as part
>> of our internal operations (e.g. boot) so doing it that way won't slow
>> down boot, deployment etc.
>>
>> An issue that doing it this way raises is a client calling read-resource
>> or read-attribute doesn't know if the returned value is the actual user
>> config or is a default. A solution to that is to have those operations
>> accept a new parameter "defaults" which if false does not include the
>> defaults.
>>
>> I'm not sure what the best default value for that "default" param would
>> be. My instinct is "true".
>>
>> WDYT?
>>
>
> I personally wouldn't do this. I would leave the default out of the
> read-resource etc result.  That would keep things clear. When you obtain
> the model you'll see that the value isn't specified. A management client
> can easily also obtain the default from the description and nicely
> present this to the user. The management client may actually want to
> mark the default value as such for the users in a slightly different way
> so having it come in somewhat separate can actually be helpful I think.
>

Thanks for the input. This was the original design, but there was a
discussion of that a few months back, I believe on this list, and what
came out of it was a desire, I believe by the console guys, to have the
data available from :read-resource with no extra operation required.
This is inconsistently implemented now and I'm adding some support code
to make dealing with defaults and other aspects of attribute handling
easier, so it has come up again.

Either way, if defaults exist, their value (and units) should be in the
description metadata; see
http://community.jboss.org/wiki/DetypedDescriptionOfTheAS7ManagementModel "Arbitrary
Descriptors".

> My 2c,
>
> David
>


--
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Default values in the model

Emanuel Muckenhuber
In reply to this post by Brian Stansberry
Yes, not storing any defaults in the model sounds better and rather have
the read-resource and read-attribute handler expose this.

What about the write-attribute operation? I would assume that the
console(s) usually don't differentiate whether a values was really
changed in the UI and just write all attributes. So we would need to
check the defaults there as well?

On 07/29/2011 02:31 AM, Brian Stansberry wrote:

> Emanuel,
>
> Or chat yesterday about the downsides of storing default values in the
> in-memory management model got me thinking a bit.
>
> Downsides:
>
> 1) The in-memory model no longer represents the user configuration
> values; it also stores defaults. This is an issue when marshalling back
> to xml; you either have to make the xml verbose by writing back all the
> defaults, or you don't write back defaults and lose the fact the user
> included the value in the original.
>
> 2) Possible versioning issues in a domain where different hosts run
> different versions; i.e. if the version on the domain controller host
> stores and pushes to servers a default value that a server running an
> earlier version doesn't understand. This would really be a bug, since a
> change in a default value should spur an increment in the subsystem's
> schema and appropriate handling by the parser. But still, storing
> defaults increases the chances of this kind of bug cropping up.
>
> Possible solution:
>
> What's been requested previously is that management clients be able to
> see the default values, without having to go read the resource
> description metadata to find them. That request can be satisfied via the
> read-resource and read-attribute handlers. There is no need to store the
> default in the model; those handlers can read the resource description
> metadata to find the default if the model doesn't have a value stored.
>
> That will slow those handlers down a little bit since the description
> has to be generated and read, but those handlers aren't called as part
> of our internal operations (e.g. boot) so doing it that way won't slow
> down boot, deployment etc.
>
> An issue that doing it this way raises is a client calling read-resource
> or read-attribute doesn't know if the returned value is the actual user
> config or is a default. A solution to that is to have those operations
> accept a new parameter "defaults" which if false does not include the
> defaults.
>
> I'm not sure what the best default value for that "default" param would
> be. My instinct is "true".
>
> WDYT?
>

_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Default values in the model

Heiko W.Rupp

Am 29.07.2011 um 11:24 schrieb Emanuel Muckenhuber:
> What about the write-attribute operation? I would assume that the
> console(s) usually don't differentiate whether a values was really
> changed in the UI and just write all attributes. So we would need to
> check the defaults there as well?

RHQ writes values if they are present (i.e. not what we call "unset", which corresponds to "undefined").
In this case it writes them all no matter if they have been changed or not.

All decisions should also be taken with other clients in mind. Users that use the API
via shell script will not want to e.g. supply all attributes if only one has changed.

  Heiko


_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Default values in the model

Emanuel Muckenhuber
On 07/29/2011 11:28 AM, Heiko W.Rupp wrote:
> RHQ writes values if they are present (i.e. not what we call "unset", which corresponds to "undefined").
> In this case it writes them all no matter if they have been changed or not.

Yes, this is the case i mean. If you you do a
read-resource(defaults=true) - you get a model with all the default
values. If you then just write all attribute we would have to add some
sort of check not that we end up storing a default value in the model again.
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Default values in the model

Heiko W.Rupp

Am 29.07.2011 um 11:34 schrieb Emanuel Muckenhuber:
> Yes, this is the case i mean. If you you do a
> read-resource(defaults=true) - you get a model with all the default
> values. If you then just write all attribute we would have to add some
> sort of check not that we end up storing a default value in the model again.

Until today I was thinking the defaults in :read-resource-description would be
enough ("descriptive") and more or less serve for clients to look up what the default
would be. I am for example using that information to populate our metadata (plugin-descriptor).
I would have thought, those values correspond to constants in the code for the defaults.

Having those defaults in read-resource and read-attribute suggests that they are not constant?

But then for us it is a minor difference if we get the metadata from read-resource-description or
read-resource.

For a user that is not using a console to talk to AS, but e.g. curl, it may feel strange that if e.g.
the default value for an attribute is 2, that if he stores '3', read-attribute will return 3, but if he then
stores '2' again, he will get "undefined", which means "default is used".

Of course the storage internally in AS7 can be whatever you like.


We also had a discussion in the past about reading "effective configurations" - meaning that
for e.g. jvm info there could be domain/profile/sg wide settings, then per host and then per managed
server - it should be possible to go to a managed server and say "give me your effective config" and this
would grab all the values from domain/profile/...  and show them explicitly instead of returning "undefined",
which means "go to the higher level entity to find out what this may be".
In this case it would be good not to fall back to any "undefined" / "default" values, but rather to explicitly return
the values -- even if they turn out to be the default.


   Heiko




_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Default values in the model

Heiko W.Rupp
In reply to this post by Brian Stansberry

Am 29.07.2011 um 11:16 schrieb Brian Stansberry:
> Thanks for the input. This was the original design, but there was a
> discussion of that a few months back, I believe on this list, and what
> came out of it was a desire, I believe by the console guys, to have the
> data available from :read-resource with no extra operation required.

In RHQ, we populate the metadata (= plugin descriptor) once at compile time
from the output of read-resource-description and read-operation-description

So for this process it does not matter if the default comes from read-resource
or read-resource-description

   Heiko



_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Default values in the model

Heiko Braun
In reply to this post by Brian Stansberry

IMO point 2 can be neglected. It's an edge case, if you ask me.

The first point is no big deal. Verbosity or not. It's always better to strive for 
a simple, easy to grasp solution. I believe (as a consumer of that API) that it should reflect the effective runtime model, no matter what. Including the defaults. Going through additional hoops & loops to figure out the effective runtime configuration is counter productive (curl,bash, etc) and will not be used.

Further more, consumer do not care if the attribute derives from a default value or not.
And why should they? 

The fact that it's written back to xml, is an implementation detail to me. 
But it should not mandate how the actually API works.

Ike

On Jul 29, 2011, at 2:31 AM, Brian Stansberry wrote:

1) The in-memory model no longer represents the user configuration 
values; it also stores defaults. This is an issue when marshalling back 
to xml; you either have to make the xml verbose by writing back all the 
defaults, or you don't write back defaults and lose the fact the user 
included the value in the original.

2) Possible versioning issues in a domain where different hosts run 
different versions; i.e. if the version on the domain controller host 
stores and pushes to servers a default value that a server running an 
earlier version doesn't understand.  This would really be a bug, since a 
change in a default value should spur an increment in the subsystem's 
schema and appropriate handling by the parser. But still, storing 
defaults increases the chances of this kind of bug cropping up.


_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Default values in the model

Heiko W.Rupp

Am 29.07.2011 um 13:42 schrieb Heiko Braun:

> The first point is no big deal. Verbosity or not. It's always better to strive for
> a simple, easy to grasp solution. I believe (as a consumer of that API) that it should reflect the effective runtime model, no matter what. Including the defaults. Going through additional hoops & loops to figure out the effective runtime configuration is counter productive (curl,bash, etc) and will not be used.
Yep.

> Further more, consumer do not care if the attribute derives from a default value or not.
Very well said - I was looking for that wording all morning :)

  Heiko


_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Default values in the model

David Bosschaert
In reply to this post by Heiko Braun
On 29/07/2011 12:42, Heiko Braun wrote:
> The fact that it's written back to xml, is an implementation detail to
> me.
> But it should not mandate how the actually API works.
>
Well it could be an issue if we decide to change the default in a
subsequent release. In that case subsystems might be stuck with the old
value even though the admin never specified it.

Cheers,

David
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Default values in the model

jtgreene
Administrator
In reply to this post by Heiko Braun
On 7/29/11 6:42 AM, Heiko Braun wrote:
>
> IMO point 2 can be neglected. It's an edge case, if you ask me.
>
> The first point is no big deal. Verbosity or not. It's always better to
> strive for
> a simple, easy to grasp solution. I believe (as a consumer of that API)
> that it should reflect the effective runtime model, no matter what.

This is essentially unachievable when you have runtime properties
evaluated on the server level. You would have to hit the server
everytime which does not scale.


> Including the defaults. Going through additional hoops & loops to figure
> out the effective runtime configuration is counter productive
> (curl,bash, etc) and will not be used.
>
> Further more, consumer do not care if the attribute derives from a
> default value or not.
> And why should they?

They care if they specified or they did not.

> The fact that it's written back to xml, is an implementation detail to me.
> But it should not mandate how the actually API works.

It's simply wrong to store values the user did not specify, since the
config represents their specification.

--
Jason T. Greene
JBoss, a division of Red Hat
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Default values in the model

David Bosschaert
On 01/08/2011 14:12, Jason T. Greene wrote:

> On 7/29/11 6:42 AM, Heiko Braun wrote:
>> Including the defaults. Going through additional hoops&  loops to figure
>> out the effective runtime configuration is counter productive
>> (curl,bash, etc) and will not be used.
>>
>> Further more, consumer do not care if the attribute derives from a
>> default value or not.
>> And why should they?
> They care if they specified or they did not.
>
I agree, people will want to see whether they specified a particular
value or not. But in either case they probably want to see what the
effective value is, so if the value isn't specified they will want to
see what the default is that is currently being used as long as it's
clear that this is the default. In past systems that I worked on this
was reflected in the GUI somehow by making the default appear grey and
have a 'default' icon beside it... How the GUI obtains that information
is an implementation detail.

Cheers,

David
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Default values in the model

jtgreene
Administrator
In reply to this post by Brian Stansberry
On 7/29/11 4:16 AM, Brian Stansberry wrote:
> ither way, if defaults exist, their value (and units) should be in the
> description metadata; see
> http://community.jboss.org/wiki/DetypedDescriptionOfTheAS7ManagementModel "Arbitrary
> Descriptors".

Totally agree. Can we please stop using minor bugs to justify throwing
out a design?


--
Jason T. Greene
JBoss, a division of Red Hat
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Default values in the model

Emanuel Muckenhuber
In reply to this post by jtgreene
We also seem to be talking about three different things.

- storing default values in the internal configuration model really does
not add any value in the end. Nothing on the server side needs this as
part of the model and can be easily added based on the description for
the client. This is what Brian was referring to.

- exposing defaults in the read-resource operation - i personally would
be more interested in what i configured, rather than static defaults. I
do see why Ike wants the defaults in the result for the console - i'm
just not sure if that should be the default view?

- A effective runtime model view sounds more like a completely separate
topic/discussion.

On 08/01/2011 03:12 PM, Jason T. Greene wrote:

> On 7/29/11 6:42 AM, Heiko Braun wrote:
>>
>> IMO point 2 can be neglected. It's an edge case, if you ask me.
>>
>> The first point is no big deal. Verbosity or not. It's always better to
>> strive for
>> a simple, easy to grasp solution. I believe (as a consumer of that API)
>> that it should reflect the effective runtime model, no matter what.
>
> This is essentially unachievable when you have runtime properties
> evaluated on the server level. You would have to hit the server
> everytime which does not scale.
>
>
>> Including the defaults. Going through additional hoops&  loops to figure
>> out the effective runtime configuration is counter productive
>> (curl,bash, etc) and will not be used.
>>
>> Further more, consumer do not care if the attribute derives from a
>> default value or not.
>> And why should they?
>
> They care if they specified or they did not.
>
>> The fact that it's written back to xml, is an implementation detail to me.
>> But it should not mandate how the actually API works.
>
> It's simply wrong to store values the user did not specify, since the
> config represents their specification.
>

_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Default values in the model

Stefano Maestri
In reply to this post by David Bosschaert
On 08/01/2011 03:20 PM, David Bosschaert wrote:
>
> I agree, people will want to see whether they specified a particular
> value or not. But in either case they probably want to see what the
> effective value is, so if the value isn't specified they will want to
> see what the default is that is currently being used as long as it's
> clear that this is the default. In past systems that I worked on this
> was reflected in the GUI somehow by making the default appear grey and
> have a 'default' icon beside it... How the GUI obtains that information
> is an implementation detail.
+1

S.
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Default values in the model

Stefano Maestri
In reply to this post by Emanuel Muckenhuber
On 08/02/2011 02:29 PM, Emanuel Muckenhuber wrote:
> We also seem to be talking about three different things.
+1
> - storing default values in the internal configuration model really does
> not add any value in the end. Nothing on the server side needs this as
> part of the model and can be easily added based on the description for
> the client. This is what Brian was referring to.
>
> - exposing defaults in the read-resource operation - i personally would
> be more interested in what i configured, rather than static defaults. I
> do see why Ike wants the defaults in the result for the console - i'm
> just not sure if that should be the default view?
Yup. Either it isn't the default view or this view outline in some way
they are defaults. To achive this second goal maybe better to provide in
the resulting model of read-attribute and read-resource an informations
on each attribute saying if it comes from user config or from default.
Of course it will be present only in these 2 operations result, and not
on runtime model where we will store only user modified attribute as
Brian proposed.

S.
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev