[jboss-as7-dev] Passing Cloud Configuration.

[Brian Stansberry]

Short response:

To handle externalized configuration requirements like this, we added 
expression support to the core AS management layer. My expectation was 
custom scripts that launch the AS would read some external configuration 
like your user-data and would set system properties.

But the core support that's there is a necessary but insufficient piece 
to allowing a particular configuration attribute accept an expression. 
Doing the other bits will require a fair amount of work (see below), 
work that should be prioritized. So it would be helpful to know what 
specific things are most critical for you -- at a finer grained level 
than "datasources", "clustering".

The rest of this is to organize a discussion about moving forward on 
making more config attributes support expressions.

Long response:

The jboss-dmr library that we use to store configuration information in 
the AS and for creating operation requests and responses supports an 
expression notion. That is, a configuration attribute that normally 
stores some primitive type can also store an expression

"max-threads" -> 10
"max-threads" -> expression ${pool.max.threads}

The expression can be resolved at runtime; the jboss-dmr class will 
attempt to resolve it by doing a system property lookup.

This basic support doesn't do much for you though; it just *makes it 
possible* to support an expression in a config attribute. It's necessary 
but insufficient. And we haven't really done the necessary other steps 
for many attrbutes.

To actually make the expression useful, a subsystem would need to:

1) Properly parse the expression from xml. Don't barf when you see <pool 
max-threads="${pool.max.threads}"/> because you're expecting an int.
2) Similarly, don't barf if an operation request passes an expression as 
the param value.
2) Store the expression in the runtime configuration model. Don't lose 
the fact it's an expression by resolving it and storing 10.
3) Resolve the expression and validate that the resolved value is valid 
before passing the resolved value into any runtime services. That is, 
don't try and pass ${pool.max.threads} to your thread pool impl.
4) Properly marshal the expression back to xml. Don't write <pool 
max-threads="10"/> and lose the expression if the server is restarted.

I wrote a class (AttributeDefinition) a month back that makes all of the 
above much easier; it's used heavily in the messaging subsystem now.

5) Add metadata to the attribute's description indicating that an 
expression is a legal value. This allows tools like the console to 
understand that they need to account for ${pool.max.threads} instead of 
an int in their UI.

I propose a simple bit of metadata "allow-expressions" -> true|false for 
this. It's one line of code to the AttributeDefinition class to add this.

More problematic, on the console side the console UI will need to 
recognize expressions and deal with them. Properly display the 
expression to the user, allow the user to type in a expression, provide 
some UI for letting the user find out what the expression resolves to 
any given server.


On 8/23/11 9:42 AM, Robb Greathouse wrote:
> Hi,
>
> We are putting JBoss 5.1.1 into the Amazon EC2 cloud.  There are some peculiarities of how EC2 wants to configure instances that we are running into.
>
> EC2 wants to use a standard AMI - basically a standard image that anyone wanting to use JBoss would use.  They would then customize this image by passing parameters via a single user-data file.
>
> While the user could ssh into the instance once it is started and manually change the settings; this is not considered user friendly.
>
> Ideally, we would like to be able to pass any configuration variable via user-data.  These would include database settings, clustering settings, etc.
>
>


-- 
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat