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

Tomas Sedovic tsedovic at redhat.com
Wed Feb 8 13:25:53 UTC 2012


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.

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.

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.

What do you all think?

Thomas
-- 
No trees were killed to send this message, but a large number of 
electrons were terribly inconvenienced.



More information about the aeolus-devel mailing list