[jboss-as7-dev] Configuration conundrum with Express

Max Rydahl Andersen max.andersen at redhat.com
Tue Oct 18 03:43:27 EDT 2011


> So the plan, and what I'll be working on this week is to have a batch 
> CLI script that exists in the openshift express application repository, 
> when pushed to the express server, is run against the jbossas server CLI 
> interface.

I assume this starts on a pristine new setup every time to avoid duplicate/overlapping changes ?

That's not the case when running against a local server thus always doing it as part as tool  deploy
is then not feasible IMO - having a way to easily run the script would be relevant though.

> One issue that is coming up is the need to refer to environment 
> variables for things like the interfaces/ports for socket services.  
> These values are a property of the execution environment the server is 
> being administered in, and activation of a mysql datasource for example 
> depends on the user "embedding" the mysql cartridge into the jbossas7 
> openshift application. To run the same configuration against a local 
> server in jboss tools, we would need to allow for the typical 
> ${env-var:default} type of syntax. Right now the CLI does not do any 
> system property or environment variable replacement. I think this is a 
> feature that needs to be added to allow the scripts to be portable 
> across provisioning environments.

Agreed - this is why I was hoping AS7 would support the .cli archive notion.

/max

> 
> On 10/17/11 10:29 AM, Max Rydahl Andersen wrote:
>>>> For the general case Scott suggested us is that we support executing
>>>> a list of .cli operations during deploy - but that would then be very
>>>> specific for JBoss tools which is why I was having high hopes for the
>>>> support for .cli archives that I believe Jesper was working on since
>>>> that would handle the deploy/undeploy cases in a way that is sharable
>>>> between the various tools - but not sure where that went.
>>> Their are major problems with a CLI deployment:
>>> 
>>> 1. Guaranteeing undeploy actually undoes what it did, which may or may not be possible
>>> 2. VM crash forcing a relaunch, forcing re-running non-idempotent operations
>>> 3. Lack of visibility into what global state each CLI deployment touches
>> 
>> yeah I understand that. It's the exact same problems users and devs of the various tools that need to setup and run an app on the server today
>>  - maybe large pieces of this just isn't meant to be automated.
>> 
>> /max
>> http://about.me/maxandersen
>> 
>> 
>> 
>> 
>> _______________________________________________
>> jboss-as7-dev mailing list
>> jboss-as7-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
> 
> _______________________________________________
> jboss-as7-dev mailing list
> jboss-as7-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

/max
http://about.me/maxandersen






More information about the jboss-as7-dev mailing list