Start operation semantics for AS - Request for Feedback

Lukas Krejci lkrejci at redhat.com
Fri May 4 08:05:04 UTC 2012


The RFE has been around for some while:

https://bugzilla.redhat.com/show_bug.cgi?id=749470

----- Original Message -----
> From: "Ian Springer" <ian.springer at redhat.com>
> To: rhq-devel at lists.fedorahosted.org
> Sent: Thursday, May 3, 2012 4:44:24 PM
> Subject: Re: Start operation semantics for AS - Request for Feedback
> 
> +1 to adding plugin config upgrade support after 3.1 goes out the
> door.
> Lukas, is there a BZ for this? If not, can you create one, so we
> don't
> forget about it?
> 
> On 05/03/2012 09:09 AM, Jay Shaughnessy wrote:
> >
> >
> > On 5/3/2012 5:20 AM, Lukas Krejci wrote:
> >> This is slightly off-topic, but I couldn't help myself :)
> >>
> >> ----- Original Message -----
> >>> From: "Jay Shaughnessy"<jshaughn at redhat.com>
> >>> To: "RHQ devel"<rhq-devel at lists.fedorahosted.org>
> >>> Sent: Wednesday, May 2, 2012 6:43:31 PM
> >>> Subject: Start operation semantics for AS - Request for Feedback
> >>>
> >> <snip>
> >>
> >>> One question is whether the current behavior is correct when and
> >>> if
> >>> the
> >>> Configuration or Bind Address connection properties are edited
> >>> or,
> >>> for
> >>> any other reason, don't match the settings in startScriptArgs.
> >>>  As
> >>> stated above, those property values are ignored of
> >>> startScriptArgs is
> >>> set.  Meaning, the value in startScriptArgs will supersede any
> >>> setting
> >>> for the individual properties.
> >>>
> >>> My feeling is that this is OK, it's possible those script args
> >>> will
> >>> even
> >>> apply if the customer is using a custom script.  The property
> >>> descriptions could be updated to make clear that the value is
> >>> overridden
> >>> if startScriptArgs is set. Additionally, the behavior can be
> >>> formally
> >>> documented and referenced in the release notes.
> >>>
> >>> If you have an opinion on any of the above semantics please let
> >>> us
> >>> know
> >>> so the new feature can be finalized.  Thanks, Jay and Ian.
> >>>
> >> I find this confusing. Why would we want to have two mutually
> >> exclusive ways of doing one thing?
> >>
> >> But I guess I know the reason why you chose to leave the legacy
> >> impl
> >> in place - the upgrade. If the user installs a new version of the
> >> plugin, the startScriptEnv and startScriptArgs will remain blank
> >> and
> >> we have to have a way of keeping things working.
> >>
> >> I think we really should think about enhancing the resource
> >> upgrade
> >> logic to include updates to plugin configs (btw. this WAS in my
> >> original proposal, but we dropped it, because there was no
> >> use-case
> >> for it at the time - well, now there is ;) ). If we could update
> >> the
> >> plugin config at upgrade time, we could simply use the legacy code
> >> to
> >> fill in the startScriptEnv and startScriptArgs and make the legacy
> >> config options read-only or even drop them altogether.
> > Lukas, you are right, we should support plugin config upgrade and
> > then
> > we could make the changes as you suggest as well as handle future
> > situations like this one.  I wonder if there is an RFE BZ for this?
> > At the moment, though, I think it will suffice to proceed as
> > described.  For AS7 plugin I think the relevant props should be
> > read-only already, I'll have to check on that.
> 
> _______________________________________________
> rhq-devel mailing list
> rhq-devel at lists.fedorahosted.org
> https://fedorahosted.org/mailman/listinfo/rhq-devel
> 


More information about the rhq-devel mailing list