Re: [higgins-dev] run-time configuration changes

[David Kuehr-McLaren <dkuehrmc@xxxxxxxxxx>]

Thanks for the input. Comments in line
as well. 


David 

David Kuehr-McLaren 
IBM Tivoli Security 
919.224.1960 


higgins-dev-bounces@xxxxxxxxxxx wrote on 07/15/2008
05:15:04 PM:

> Comments inline.
> 
> ...Greg
> 
> 
> Markus Sabadello wrote:
> > Hi,
> > 
> > Here are some thoughts:
> > 
> > 1) Instead of introducing the new method setConfigurationHandler(),
> > wouldn't it be better to pass the IConfigurationHandler as an
additional 
> > parameter to the configure() method?
> 
> IMO, we should keep configure() simple.  It may be that you want
to 
> just create 
> a simple map to configure a component, if you know what you're doing.
 No 
> configuration handler needed.  Though I suppose you could pass
null 
> in that case.
> 
> Keeping them separate would allow changing the IConfigurationHandler
> dynamically.  Suppose you read configuration in from an XML file,
> but decide you 
> want to save the settings as an XRDS file (e.g., because you want
to migrate 
> from one server to another).  By setting the IConfigurationHandler
before 
> applying updates, you control how the configuration data gets 
> written.  I'm not 
> sure how easy this is in practice, but theoretically the 
> configuration data is 
> independent of its storage format.
> 
> > 
> > 2) Is there really a namespace "com.ibm.higgins.configuration.api",
or 
> > is that a mistake? :)

Mistake.  I wil update the page with org.eclipse.higgins.*

> > 
> > 3) So the applyUpdates() method would basically write the whole
> > "mapGlobalSettings" back to a file, right? In theory
I guess it would be 
> > nice to be able to write only a part of the configuration back
(i.e. 
> > just the part that concerns your own IConfigurableComponent).
E.g. have 
> > a method 
> > applyUpdates(...something-here-that-identifies-a-part-of-the-
> configuration...). 
> > In cases where writing parts of the configuration is the same
effort as 
> > writing the whole thing (e.g. in the case of the XML 
> > ConfigurationHandler), that method could simply call the "main"
> > applyUpdates().
> > 
> 
> Agreed.  It would be nice to allow updating parts of a 
> configuration.  I'm not 
> sure how much of the global vs. component settings is truly general,
> as opposed 
> to driven by the initial STS configuration requirements.  Who's
to say that 
> there is a global map at all?  And maybe its configuration spec
is in a 
> different file from the component specs?
> 

Would it be possible to leave this up to the handler
to determine if a partial write can be done or would be the best way to
apply the update? 

> 
> > 4) Shouldn't the ISetting.addChildSetting() method return the
new 
> > ISetting? Then you wouldn't have to search for it afterwards
with a for 
> > loop.
> > 
> > 5) I like the idea that you don't HAVE to provide an ISettingDescriptor,
> > i.e. it can be built automatically when the configuration is
read.
> 
> You would likely use the constraints and display string that would
> be useful for 
> a management UI, since these are not necessarily present in the configuration
> file itself.  But I think it's a good approach for the current
requirements.
> 

This is good for the component developer, but will
limit the robustness of the UI, if more detail is not provided in form
of constraints and display meta data. OK as a start. Also, end customer
needs to be able to over ride the defaults of the SettingDescriptor defualt
config for a component to modify labels and customize constraints. Display
data will need to be internationalized. 

> > 
> > 6) If you want to implement an ISettingDescriptor, how would
you do 
> > that? Would IConfigurableComponent have a method getSettingDescriptor()
?
> 
> Yes, every configurable component would have a getSettingDescriptor
method.
> > 
> > 7) I don't really understand the difference between Option 1
and Option 3.
> >

Option three added the values to the SettingDescriptor
to remove the need to merge the Map and the SettingDescriptor when persisting
the file. This would separate the run time configuration (the Map) from
the management using ISettingDescriptor.  However, on further consideration,
this option is not as elegant as combining the Map for values with the
SettingDescriptor for meta data. 
 
> > 8) I do like the ISettingDescriptor idea slightly better than
the 
> > ISetting idea, but both are great ways of solving the problem
I think.
> 
> My concern about the ISetting solution is that it might require 
> significant code 
> changes for components that already consume Maps for configuration.
> 

Agree. 

> > 
> > BTW if you're interested, Dmitry made a configuration frontend
for the 
> > SAML2 IdP:
> > http://graceland.parityinc.net/saml2idp-server-config
> > 
> > But it's a very specific solution and probably not too useful
as a basis 
> > for a "general purpose" configuration frontend.

Thanks

> > 
> > Markus
> > 
> > On Tue, Jul 15, 2008 at 8:39 PM, David Kuehr-McLaren 
> > <dkuehrmc@xxxxxxxxxx <mailto:dkuehrmc@xxxxxxxxxx>>
wrote:
> > 
> > 
> >     I apologize if I sent this twice to the list. My
email program says
> >     I never sent it.
> > 
> >     With much help from Greg Byrd and Rajalakshmi Iyer
I have collected
> >     the discussions on Configuration Management and
created a proposal
> >     page on the Wiki
> > 
> >     http://wiki.eclipse.org/Higgins_Configuration_Management
> > 
> >     It contains the general proposal and three options
to consider. I am
> >     leaning toward option 3, which is a hybrid of the
first two options.
> >     Please let us know you comments.
> > 
> >     Thanks,
> > 
> >     David
> > 
> >     David Kuehr-McLaren
> >     IBM Tivoli Security
> >     919.224.1960
> > 
> > 
> > 
> >     *David Kuehr-McLaren/Raleigh/IBM@IBMUS*
> >     Sent by: higgins-dev-bounces@xxxxxxxxxxx
> >     <mailto:higgins-dev-bounces@xxxxxxxxxxx>
> > 
> >     07/07/2008 03:55 PM
> > 
> >     Please respond to
> >     "Higgins \(Trust Framework\) Project developer
discussions"      
> >      <higgins-dev@xxxxxxxxxxx <mailto:higgins-dev@xxxxxxxxxxx>>
> > 
> > 
> >        
> >     To
> >        
> >     "Higgins \(Trust Framework\) Project developer
discussions"
> >     <higgins-dev@xxxxxxxxxxx <mailto:higgins-dev@xxxxxxxxxxx>>
> >     cc
> >        "Higgins (Trust Framework) Project
developer discussions"
> >     <higgins-dev@xxxxxxxxxxx <mailto:higgins-dev@xxxxxxxxxxx>>,
> >     higgins-dev-bounces@xxxxxxxxxxx <mailto:higgins-dev-bounces@xxxxxxxxxxx>
> >     Subject
> >        Re: [higgins-dev] run-time configuration
changes
> > 
> > 
> >        
> > 
> > 
> > 
> > 
> > 
> > 
> >     To put the need for the "constraints"
in to context of a use case:
> >      Application owner uses a UI (CLI and/or GIU)
to configure an
> >     instance of a context provider. With the UI, and
application owner
> >     can the context provider for the parameters it
needs to configure an
> >     instance of the provider. The UI  will present
a form to collect the
> >     configuration data, and be able to persist the
new configuration.
> >      The UI will also be able to display existing
configurations and
> >     allow the user to update and delete CP configurations.
 
> > 
> >     The UI application needs away to understand the
model of the
> >     configuration data needed by a context provider.
> > 
> > 
> >     David
> > 
> >     David Kuehr-McLaren
> > 
> > 
> > 
> >     *Greg Byrd <gbyrd@xxxxxxxx <mailto:gbyrd@xxxxxxxx>>*
> >     Sent by: higgins-dev-bounces@xxxxxxxxxxx
> >     <mailto:higgins-dev-bounces@xxxxxxxxxxx>
> > 
> >     07/07/2008 03:30 PM
> > 
> >     Please respond to
> >     "Higgins \(Trust Framework\) Project developer
discussions"      
> >      <higgins-dev@xxxxxxxxxxx <mailto:higgins-dev@xxxxxxxxxxx>>
> > 
> >        
> >     To
> >        "Higgins (Trust Framework) Project
developer discussions"
> >     <higgins-dev@xxxxxxxxxxx <mailto:higgins-dev@xxxxxxxxxxx>>
> >     cc
> >        higgins-dev-bounces@xxxxxxxxxxx
> >     <mailto:higgins-dev-bounces@xxxxxxxxxxx>
> >     Subject
> >        Re: [higgins-dev] run-time configuration
changes
> > 
> > 
> > 
> >        
> > 
> > 
> > 
> > 
> > 
> > 
> >     Constraints are extra information about the setting
that limit the
> >     potential
> >     values for that setting.  Could be min/max,
could be a set of legal
> >     values, etc.
> >     It's basically a "punt" to avoid over-specifying
what can be
> >     represented by a
> >     descriptor.  Constraints are somewhat component-specific,
though I
> >     can imagine
> >     there are a significant set of common constraints
that can be
> >     captured in a base
> >     class.
> > 
> >     I have not figured out how and when constraints
are enforced.  The
> >     idea is to
> >     provide a management client some hints about how
to construct a
> >     proper value for
> >     a setting.
> > 
> >     The setXXX and addXXX methods are intended for
building up the
> >     SettingDescriptor.  I don't intend that you
get a component's
> >     SettingDescriptor
> >     and then start making changes to it.  But
someone's got to create
> >     the descriptor
> >     in the first place. Is there a better way to specify
this -- in some
> >     other
> >     interface, for example?
> > 
> >     ...Greg
> > 
> > 
> >     Michael McIntosh wrote:
> >      > Greg,
> >      >
> >      > Can you provide more information about
the "Constraints" in the
> >      > ISettingDescriptor?
> >      > Can you explain why there is code to
dynamically change the
> >      > ISettingDescriptor? (seems like when
a component changes what
> >     settings it
> >      > expects it justifies a restart)
> >      >
> >      > Regards,
> >      > Mike
> >      >
> >      > higgins-dev-bounces@xxxxxxxxxxx
> >     <mailto:higgins-dev-bounces@xxxxxxxxxxx>
wrote on 07/07/2008
> >     12:54:48 PM:
> >      >
> >      >> [image removed]
> >      >>
> >      >> [higgins-dev] run-time configuration
changes
> >      >>
> >      >> Greg Byrd
> >      >>
> >      >> to:
> >      >>
> >      >> Higgins (Trust Framework) Project
developer discussions
> >      >>
> >      >> 07/07/2008 12:57 PM
> >      >>
> >      >> Sent by:
> >      >>
> >      >> higgins-dev-bounces@xxxxxxxxxxx
> >     <mailto:higgins-dev-bounces@xxxxxxxxxxx>
> >      >>
> >      >> Please respond to "Higgins
\(Trust Framework\) Project developer
> >      > discussions"
> >      >>
> >      >> As discussed in our last phone meeting,
a group at IBM hasa need to
> >      >> instantiate
> >      >> configurable components, and to
make their configurations
> >     persistent.  I
> >      >> promised that I would send some
mail to the dev list to (hopefully)
> >      >> kick off a
> >      >> conversation.
> >      >>
> >      >> This particular requirement raises
at least two issues:
> >      >>
> >      >> (1) Asking a configurable component
about its configuration
> >     settings.
> >      > The
> >      >> ISettingDescriptor interface was
a first effort at this capability,
> >      >> but it never
> >      >> got further than that.  Assuming
that ISettingDescriptor is
> >      >> descriptive enough,
> >      >> there needs to be some mechanism
to describe the settings and
> >      >> constraints for a
> >      >> particular component type.
> >      >>
> >      >> That's what this discussion was
about:
> >      >> http://dev.eclipse.org/mhonarc/lists/higgins-dev/msg04721.html
> >      >>
> >      >>
> >      >> (2) Once we create the setting for
a component, how do we write the
> >      >> settings to
> >      >> the configuration file?  This
is complicated by the fact that there
> >      >> are multiple
> >      >> formats for configuration files,
each with its own
> >      >> ConfigurationHandler.  When
a
> >      >> component is configured, all it
sees is a Map that contains
> >     settings-- it
> >      > has
> >      >> no idea what sort of file (if any)
these settings came from.
> >      >>
> >      >> One idea that came up during a discussion
with the IBM folks was to
> >      > somehow
> >      >> connect a component to the ConfigurationHandler
that was
> >     responsible for
> >      > its
> >      >> settings -- then we can pass off
the responsibility for storing
> >      >> those settings
> >      >> to that handler.
> >      >>
> >      >> -----
> >      >>
> >      >> A third issue, which is not necessarily
required for the current
> >      > scenario, is
> >      >> how to change a configured components
settings at run-time, and
> >     savethose
> >      > new
> >      >> settings for later use.
> >      >>
> >      >> Could call getSettings(), change
map, and call configure() again
> >     with the
> >      > new
> >      >> settings.  Or could be a separate
method for changing (e.g.,
> >      >> setSettings()), so
> >      >> that the component can distinguish
a full configuration from an
> >     update.
> >      >>
> >      >>
> >      >> Comments on any and all of these
issues are welcomed.
> >      >>
> >      >> ...Greg
> >      >>
> >      >>
> >      >>
> >      >>
> >      >> _______________________________________________
> >      >> higgins-dev mailing list
> >      >> higgins-dev@xxxxxxxxxxx <mailto:higgins-dev@xxxxxxxxxxx>
> >      >> https://dev.eclipse.org/mailman/listinfo/higgins-dev
> >      >
> >      > _______________________________________________
> >      > higgins-dev mailing list
> >      > higgins-dev@xxxxxxxxxxx <mailto:higgins-dev@xxxxxxxxxxx>
> >      > https://dev.eclipse.org/mailman/listinfo/higgins-dev
> > 
> > 
> >     _______________________________________________
> >     higgins-dev mailing list
> >     higgins-dev@xxxxxxxxxxx <mailto:higgins-dev@xxxxxxxxxxx>
> >     https://dev.eclipse.org/mailman/listinfo/higgins-dev
> >     _______________________________________________
> >     higgins-dev mailing list
> >     higgins-dev@xxxxxxxxxxx <mailto:higgins-dev@xxxxxxxxxxx>
> >     https://dev.eclipse.org/mailman/listinfo/higgins-dev
> > 
> > 
> >     _______________________________________________
> >     higgins-dev mailing list
> >     higgins-dev@xxxxxxxxxxx <mailto:higgins-dev@xxxxxxxxxxx>
> >     https://dev.eclipse.org/mailman/listinfo/higgins-dev
> > 
> > 
> > 
> > ------------------------------------------------------------------------
> > 
> > _______________________________________________
> > higgins-dev mailing list
> > higgins-dev@xxxxxxxxxxx
> > https://dev.eclipse.org/mailman/listinfo/higgins-dev
> 
> 
> _______________________________________________
> higgins-dev mailing list
> higgins-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/higgins-dev