Passing Cloud Configuration.

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Passing Cloud Configuration.

Robb Greathouse
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.

Robb,
--

--

_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: 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
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Passing Cloud Configuration.

jtgreene
Administrator
On 8/23/11 1:41 PM, Brian Stansberry wrote:

> 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.

6. Figure out how/if you can validate any of this in schema.


--
Jason T. Greene
JBoss AS Lead / EAP Platform Architect
JBoss, a division of Red Hat
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Passing Cloud Configuration.

Brian Stansberry
On 8/23/11 3:27 PM, Jason T. Greene wrote:

> On 8/23/11 1:41 PM, Brian Stansberry wrote:
>> 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.
>
> 6. Figure out how/if you can validate any of this in schema.
>
>
Sounds like a nasty task. In past discussions we'd accepted that
documents with expressions would not be valid against the schema.

It would be fairly straightforward to create a tool that can accept a
document with expressions along with key/value pairs for all the
properties, parse it, resolve the expressions, emit a resolved doc and
validate that. But I don't really see much point in that, since parsing
it proves we can parse it.

--
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev