Audrey RFC: Non-editable "launch-time" parameters

Greg Blomquist gblomqui at redhat.com
Wed Feb 8 15:22:16 UTC 2012


On 02/08/2012 08:25 AM, Tomas Sedovic wrote:
> Hello there,
> 
> I came across this bug/RFE:
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=751037
> 
> They want us to add another parameter type to the deployable definition. 
> The parameter would have a fixed value that could not be changed via the 
> UI. Other than that, it would behave like any other param: it could be 
> referenced by other services, config server would be aware of it, agents 
> could request it, etc.

This is similar to https://bugzilla.redhat.com/show_bug.cgi?id=785782,
but definitely not a dup.

> 
> It is possible to get the same behaviour by taking advantage of the 
> scripts that the Audrey agent downloads and runs -- any static 
> configuration may be entered there.
> 
> I see two possible scenarios where the requested feature may still be 
> useful:
> 
> 1. All deployment configuration is in one place
> 
>     Having to maintain the configuration in two places (the scripts for 
> the fixed stuff, deployable XML with launch-time params for variables) 
> may cause hassle.
> 
> 2. Inter-service dependencies
> 
>     Imagine we have a common set of assemblies or configuration scripts 
> that are reused across multiple deployments. Then a service depending 
> on, say, an IP address of sorts, may be used in a deployable that sets 
> it at launch-time and in another deployable that requires a fixed value.

We are actually exploring the idea of "reusable services" that could
introduce a type of pluggable architecture for services (i.e., define a
service for connecting to Katello, reuse that service in several--or
all--of your deployables).

> 
> In this case, the value should probably be set via the deployable XML
> so that the in-guest agent can request the value from the config server 
> regardless of how it was set (launch-time or fixed).
> 
> 
> I can see how this feature would be useful in situations above, but I 
> have no idea how common this would be in a real use.
> 
> The change doesn't seem too complicated, but it would affect both Audrey 
> and Conductor and as far as I can tell, you can work around not having 
> it. Thus, I'm hesitant to move forward with this unless actually it is 
> of value to our users.

I don't think it has much impact to Audrey at all, actually.  I think,
as long as conductor only uses the "read-only" aspect of the parameter
only to drive how the UI treats the params (and processes them
identically to normal params when feeding the data to the config
server), then there's virtually no impact to config server.

> 
> What do you all think?

My initial gut feeling is that this is low risk and possibly low reward
for 1.0.

It feels like it's better to glom this type of feature on with other
service/assembly features in 1.1.

> 
> Thomas




More information about the aeolus-devel mailing list