Configuration conundrum with Express

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

Configuration conundrum with Express

Pete Muir
Warning, I may be repeating an existing query, so tell me politely where to go if that is the case ;-)

I've been adding Express support to Forge, in the run up to doing demos at JavaOne. I've hit the point where I want to add an entry (an Infinispan cache) to the standalone.xml (or domain.xml), and I want to do it without having to write a parser. If the node is available via the mgmt interface this is easy - I can use the REST interface etc. However, my node isn't, and the recommended way to configure it is to edit .openshift/configuration/standalone.xml.

Any thoughts on how I can make use of the management capabilities of AS to define this (in a machine controllable way without me reinventing the wheel) for OpenShift Express?
_______________________________________________
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: Configuration conundrum with Express

David Lloyd-2
On 09/28/2011 10:43 AM, Pete Muir wrote:
> Warning, I may be repeating an existing query, so tell me politely where to go if that is the case ;-)
>
> I've been adding Express support to Forge, in the run up to doing demos at JavaOne. I've hit the point where I want to add an entry (an Infinispan cache) to the standalone.xml (or domain.xml), and I want to do it without having to write a parser. If the node is available via the mgmt interface this is easy - I can use the REST interface etc. However, my node isn't, and the recommended way to configure it is to edit .openshift/configuration/standalone.xml.
>
> Any thoughts on how I can make use of the management capabilities of AS to define this (in a machine controllable way without me reinventing the wheel) for OpenShift Express?

If there is something that is in standalone.xml that can't be affected
with management operations, I'd say we have a bug.  You should be able
to get at any configuration item at runtime.

--
- DML
_______________________________________________
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: Configuration conundrum with Express

Benjamin Browning

On Sep 28, 2011, at 12:13 PM, David M. Lloyd wrote:

> On 09/28/2011 10:43 AM, Pete Muir wrote:
>> Warning, I may be repeating an existing query, so tell me politely where to go if that is the case ;-)
>>
>> I've been adding Express support to Forge, in the run up to doing demos at JavaOne. I've hit the point where I want to add an entry (an Infinispan cache) to the standalone.xml (or domain.xml), and I want to do it without having to write a parser. If the node is available via the mgmt interface this is easy - I can use the REST interface etc. However, my node isn't, and the recommended way to configure it is to edit .openshift/configuration/standalone.xml.
>>
>> Any thoughts on how I can make use of the management capabilities of AS to define this (in a machine controllable way without me reinventing the wheel) for OpenShift Express?
>
> If there is something that is in standalone.xml that can't be affected
> with management operations, I'd say we have a bug.  You should be able
> to get at any configuration item at runtime.

I believe the issue is no management interfaces are enabled in Express. Your only interface is standalone.xml.

Ben


_______________________________________________
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: Configuration conundrum with Express

Scott Stark
In reply to this post by Pete Muir
On 9/28/11 8:43 AM, Pete Muir wrote:
> Warning, I may be repeating an existing query, so tell me politely where to go if that is the case ;-)
>
> I've been adding Express support to Forge, in the run up to doing demos at JavaOne. I've hit the point where I want to add an entry (an Infinispan cache) to the standalone.xml (or domain.xml), and I want to do it without having to write a parser. If the node is available via the mgmt interface this is easy - I can use the REST interface etc. However, my node isn't, and the recommended way to configure it is to edit .openshift/configuration/standalone.xml.
>
> Any thoughts on how I can make use of the management capabilities of AS to define this (in a machine controllable way without me reinventing the wheel) for OpenShift Express?
The management ops have not been exposed in openshift yet, so only the
.openshift/configuration/standalone.xml can be used to update the server
configuration.

The next change I'll make is to have a .openshift/management/cli script
that can be run against the server to update the server configuration
via the cli tools.

_______________________________________________
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: Configuration conundrum with Express

Pete Muir
In reply to this post by Benjamin Browning
Scott has a fix in the pipe for this to expose the management interfaces :-)

On 28 Sep 2011, at 09:14, Benjamin Browning wrote:

>
> On Sep 28, 2011, at 12:13 PM, David M. Lloyd wrote:
>
>> On 09/28/2011 10:43 AM, Pete Muir wrote:
>>> Warning, I may be repeating an existing query, so tell me politely where to go if that is the case ;-)
>>>
>>> I've been adding Express support to Forge, in the run up to doing demos at JavaOne. I've hit the point where I want to add an entry (an Infinispan cache) to the standalone.xml (or domain.xml), and I want to do it without having to write a parser. If the node is available via the mgmt interface this is easy - I can use the REST interface etc. However, my node isn't, and the recommended way to configure it is to edit .openshift/configuration/standalone.xml.
>>>
>>> Any thoughts on how I can make use of the management capabilities of AS to define this (in a machine controllable way without me reinventing the wheel) for OpenShift Express?
>>
>> If there is something that is in standalone.xml that can't be affected
>> with management operations, I'd say we have a bug.  You should be able
>> to get at any configuration item at runtime.
>
> I believe the issue is no management interfaces are enabled in Express. Your only interface is standalone.xml.
>
> Ben
>
>
> _______________________________________________
> jboss-as7-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev


_______________________________________________
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: Configuration conundrum with Express

Max Rydahl Andersen

> Scott has a fix in the pipe for this to expose the management interfaces :-)

Any info on what the fix is ?

Since just exposing this doesn't really help since users would then have to remember to invoke these operations always from whatever tool they use, wether that is command line, forge, eclipse, netbeans, maven etc.

I hope its done with something that doesn't requires N implementations - but something like the suggested feature of being able to deploy management changes.

/max
 

>
> On 28 Sep 2011, at 09:14, Benjamin Browning wrote:
>
>>
>> On Sep 28, 2011, at 12:13 PM, David M. Lloyd wrote:
>>
>>> On 09/28/2011 10:43 AM, Pete Muir wrote:
>>>> Warning, I may be repeating an existing query, so tell me politely where to go if that is the case ;-)
>>>>
>>>> I've been adding Express support to Forge, in the run up to doing demos at JavaOne. I've hit the point where I want to add an entry (an Infinispan cache) to the standalone.xml (or domain.xml), and I want to do it without having to write a parser. If the node is available via the mgmt interface this is easy - I can use the REST interface etc. However, my node isn't, and the recommended way to configure it is to edit .openshift/configuration/standalone.xml.
>>>>
>>>> Any thoughts on how I can make use of the management capabilities of AS to define this (in a machine controllable way without me reinventing the wheel) for OpenShift Express?
>>>
>>> If there is something that is in standalone.xml that can't be affected
>>> with management operations, I'd say we have a bug.  You should be able
>>> to get at any configuration item at runtime.
>>
>> I believe the issue is no management interfaces are enabled in Express. Your only interface is standalone.xml.
>>
>> Ben
>>
>>
>> _______________________________________________
>> jboss-as7-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>
>
> _______________________________________________
> jboss-as7-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

/max
http://about.me/maxandersen




_______________________________________________
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: Configuration conundrum with Express

Pete Muir


On 17 Oct 2011, at 08:13, Max Rydahl Andersen wrote:

>
>> Scott has a fix in the pipe for this to expose the management interfaces :-)
>
> Any info on what the fix is ?

I believe exposing the management interface of the Express instance via whatever normal remote management protocol is used (e.g. CLI). This solves my need, which is to tweak the standalone configuration from forge or maven. I think this is consistent with the way AS7 works in general.

Scott will know more.

>
> Since just exposing this doesn't really help since users would then have to remember to invoke these operations always from whatever tool they use, wether that is command line, forge, eclipse, netbeans, maven etc.
>
> I hope its done with something that doesn't requires N implementations - but something like the suggested feature of being able to deploy management changes.

AS7 doesn't allow this generally, right? So why would it be different on express?

>
> /max
>
>>
>> On 28 Sep 2011, at 09:14, Benjamin Browning wrote:
>>
>>>
>>> On Sep 28, 2011, at 12:13 PM, David M. Lloyd wrote:
>>>
>>>> On 09/28/2011 10:43 AM, Pete Muir wrote:
>>>>> Warning, I may be repeating an existing query, so tell me politely where to go if that is the case ;-)
>>>>>
>>>>> I've been adding Express support to Forge, in the run up to doing demos at JavaOne. I've hit the point where I want to add an entry (an Infinispan cache) to the standalone.xml (or domain.xml), and I want to do it without having to write a parser. If the node is available via the mgmt interface this is easy - I can use the REST interface etc. However, my node isn't, and the recommended way to configure it is to edit .openshift/configuration/standalone.xml.
>>>>>
>>>>> Any thoughts on how I can make use of the management capabilities of AS to define this (in a machine controllable way without me reinventing the wheel) for OpenShift Express?
>>>>
>>>> If there is something that is in standalone.xml that can't be affected
>>>> with management operations, I'd say we have a bug.  You should be able
>>>> to get at any configuration item at runtime.
>>>
>>> I believe the issue is no management interfaces are enabled in Express. Your only interface is standalone.xml.
>>>
>>> Ben
>>>
>>>
>>> _______________________________________________
>>> jboss-as7-dev mailing list
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>
>>
>> _______________________________________________
>> jboss-as7-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>
> /max
> http://about.me/maxandersen
>
>
>


_______________________________________________
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: Configuration conundrum with Express

Max Rydahl Andersen
>>
>> Since just exposing this doesn't really help since users would then have to remember to invoke these operations always from whatever tool they use, wether that is command line, forge, eclipse, netbeans, maven etc.
>>
>> I hope its done with something that doesn't requires N implementations - but something like the suggested feature of being able to deploy management changes.
>
> AS7 doesn't allow this generally, right? So why would it be different on express?

I don't want Express to be different, I want both AS7 locally, on remote hosts and on express to be easy to configure/setup without relying on a running server or that your tool has access to do the right management calls at the right times.

i.e. before we could copy a .war and a -ds.xml and it would work/deploy from any tech.

Now we need to have forge, cli, jboss tools, netbeans, eclipse, intellij, my eclipse etc. be aware of AS7 management model and not only be able to tell the server to set something up, but also be able to handle the possible error conditions (i.e. datasource is already there, operation not permitted etc.) to do an outofbox deployment without too much fuzz.

/max

>
>>
>> /max
>>
>>>
>>> On 28 Sep 2011, at 09:14, Benjamin Browning wrote:
>>>
>>>>
>>>> On Sep 28, 2011, at 12:13 PM, David M. Lloyd wrote:
>>>>
>>>>> On 09/28/2011 10:43 AM, Pete Muir wrote:
>>>>>> Warning, I may be repeating an existing query, so tell me politely where to go if that is the case ;-)
>>>>>>
>>>>>> I've been adding Express support to Forge, in the run up to doing demos at JavaOne. I've hit the point where I want to add an entry (an Infinispan cache) to the standalone.xml (or domain.xml), and I want to do it without having to write a parser. If the node is available via the mgmt interface this is easy - I can use the REST interface etc. However, my node isn't, and the recommended way to configure it is to edit .openshift/configuration/standalone.xml.
>>>>>>
>>>>>> Any thoughts on how I can make use of the management capabilities of AS to define this (in a machine controllable way without me reinventing the wheel) for OpenShift Express?
>>>>>
>>>>> If there is something that is in standalone.xml that can't be affected
>>>>> with management operations, I'd say we have a bug.  You should be able
>>>>> to get at any configuration item at runtime.
>>>>
>>>> I believe the issue is no management interfaces are enabled in Express. Your only interface is standalone.xml.
>>>>
>>>> Ben
>>>>
>>>>
>>>> _______________________________________________
>>>> jboss-as7-dev mailing list
>>>> [hidden email]
>>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>>
>>>
>>> _______________________________________________
>>> jboss-as7-dev mailing list
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>
>> /max
>> http://about.me/maxandersen
>>
>>
>>
>

/max
http://about.me/maxandersen




_______________________________________________
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: Configuration conundrum with Express

Pete Muir

On 17 Oct 2011, at 14:10, Max Rydahl Andersen wrote:

>>>
>>> Since just exposing this doesn't really help since users would then have to remember to invoke these operations always from whatever tool they use, wether that is command line, forge, eclipse, netbeans, maven etc.
>>>
>>> I hope its done with something that doesn't requires N implementations - but something like the suggested feature of being able to deploy management changes.
>>
>> AS7 doesn't allow this generally, right? So why would it be different on express?
>
> I don't want Express to be different, I want both AS7 locally, on remote hosts and on express to be easy to configure/setup without relying on a running server or that your tool has access to do the right management calls at the right times.
>
> i.e. before we could copy a .war and a -ds.xml and it would work/deploy from any tech.
>
> Now we need to have forge, cli, jboss tools, netbeans, eclipse, intellij, my eclipse etc. be aware of AS7 management model and not only be able to tell the server to set something up, but also be able to handle the possible error conditions (i.e. datasource is already there, operation not permitted etc.) to do an outofbox deployment without too much fuzz.

Ok, to be clear, Scott was just talking about exposing the existing model from Express, not changing the way the existing model works.
_______________________________________________
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: Configuration conundrum with Express

jtgreene
Administrator
In reply to this post by Max Rydahl Andersen
On 10/17/11 8:10 AM, Max Rydahl Andersen wrote:

>>>
>>> Since just exposing this doesn't really help since users would then have to remember to invoke these operations always from whatever tool they use, wether that is command line, forge, eclipse, netbeans, maven etc.
>>>
>>> I hope its done with something that doesn't requires N implementations - but something like the suggested feature of being able to deploy management changes.
>>
>> AS7 doesn't allow this generally, right? So why would it be different on express?
>
> I don't want Express to be different, I want both AS7 locally, on remote hosts and on express to be easy to configure/setup without relying on a running server or that your tool has access to do the right management calls at the right times.
>
> i.e. before we could copy a .war and a -ds.xml and it would work/deploy from any tech.
>
> Now we need to have forge, cli, jboss tools, netbeans, eclipse, intellij, my eclipse etc. be aware of AS7 management model and not only be able to tell the server to set something up, but also be able to handle the possible error conditions (i.e. datasource is already there, operation not permitted etc.) to do an outofbox deployment without too much fuzz.

We are going to add support for -ds.xml and )probably jms destination
deployments if we can find the time), but don't expect everything that
is manageable to become a deployment. That will just never happen.


--
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: Configuration conundrum with Express

Max Rydahl Andersen
>>>> I hope its done with something that doesn't requires N implementations - but something like the suggested feature of being able to deploy management changes.
>>>
>>> AS7 doesn't allow this generally, right? So why would it be different on express?
>>
>> I don't want Express to be different, I want both AS7 locally, on remote hosts and on express to be easy to configure/setup without relying on a running server or that your tool has access to do the right management calls at the right times.
>>
>> i.e. before we could copy a .war and a -ds.xml and it would work/deploy from any tech.
>>
>> Now we need to have forge, cli, jboss tools, netbeans, eclipse, intellij, my eclipse etc. be aware of AS7 management model and not only be able to tell the server to set something up, but also be able to handle the possible error conditions (i.e. datasource is already there, operation not permitted etc.) to do an outofbox deployment without too much fuzz.
>
> We are going to add support for -ds.xml and )probably jms destination
> deployments if we can find the time), but don't expect everything that
> is manageable to become a deployment. That will just never happen.

And i've never asked for it to be manageable so i'm fine with that - looking forward to it ;)

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.

/max
http://about.me/maxandersen




_______________________________________________
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: Configuration conundrum with Express

jtgreene
Administrator
On 10/17/11 9:43 AM, Max Rydahl Andersen wrote:

>>>>> I hope its done with something that doesn't requires N
>>>>> implementations - but something like the suggested feature of
>>>>> being able to deploy management changes.
>>>>
>>>> AS7 doesn't allow this generally, right? So why would it be
>>>> different on express?
>>>
>>> I don't want Express to be different, I want both AS7 locally, on
>>> remote hosts and on express to be easy to configure/setup without
>>> relying on a running server or that your tool has access to do
>>> the right management calls at the right times.
>>>
>>> i.e. before we could copy a .war and a -ds.xml and it would
>>> work/deploy from any tech.
>>>
>>> Now we need to have forge, cli, jboss tools, netbeans, eclipse,
>>> intellij, my eclipse etc. be aware of AS7 management model and
>>> not only be able to tell the server to set something up, but also
>>> be able to handle the possible error conditions (i.e. datasource
>>> is already there, operation not permitted etc.) to do an outofbox
>>> deployment without too much fuzz.
>>
>> We are going to add support for -ds.xml and )probably jms
>> destination deployments if we can find the time), but don't expect
>> everything that is manageable to become a deployment. That will
>> just never happen.
>
> And i've never asked for it to be manageable so i'm fine with that -
> looking forward to it ;)
>
> 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

--
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: Configuration conundrum with Express

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

Re: Configuration conundrum with Express

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

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.

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
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

_______________________________________________
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: Configuration conundrum with Express

Brian Stansberry
On 10/17/11 4:04 PM, Scott Stark wrote:
> 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.
>
> 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,

I interpreted "execution environment the server is being administered
in" as meaning where the admin tool runs. If that's correct, why are
these a property of where the admin tool runs rather than the server
environment?

> 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.
>
> 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
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>
> _______________________________________________
> jboss-as7-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev


--
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: Configuration conundrum with Express

Scott Stark
On 10/17/11 2:33 PM, Brian Stansberry wrote:

> On 10/17/11 4:04 PM, Scott Stark wrote:
>> 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.
>>
>> 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,
> I interpreted "execution environment the server is being administered
> in" as meaning where the admin tool runs. If that's correct, why are
> these a property of where the admin tool runs rather than the server
> environment?
>
>
They happen to be collocated in this case since the script is connected
to the git repository of the application. It is the execution
environment of the jbossas7 server that determines the environment
values. The problem can be framed as there being a domain specific set
of environment/properties that one wants to be externalized to avoid
having to change the jbossas7 server configuration as it is run in a
different provider environment.
_______________________________________________
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: Configuration conundrum with Express

Max Rydahl Andersen
In reply to this post by Scott Stark
> 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
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>
> _______________________________________________
> jboss-as7-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

/max
http://about.me/maxandersen




_______________________________________________
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: Configuration conundrum with Express

jtgreene
Administrator
On 10/18/11 2:43 AM, Max Rydahl Andersen wrote:

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

I think Brian's question was "Why can't we just put the env expressions
in the management operation?" Perhaps the CLI doesn't fully use the
expression type when seen?

--
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: Configuration conundrum with Express

Scott Stark
On 10/18/11 7:07 AM, Jason T. Greene wrote:

> On 10/18/11 2:43 AM, Max Rydahl Andersen wrote:
>>> 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 ?
>>
Correct.

>> 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.
Right, so, can we have a tools "configured server" notion that takes the
standalone.xml at a given point, a cli batch file, and overwrites the
standalone.xml and reapplies the batch file as a configure operation? In
general this will be different from the remote/cloud environment even if
one can use env/system property references because I'll have my desktop
using a different database than in the remote env for example. Maybe the
way to handle this is to have multiple scripts, one for the commands
common to each environment, another for the configurations that differ
more fundamentally based on the services available in the environment.

>>
>>> 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.
>
> I think Brian's question was "Why can't we just put the env
> expressions in the management operation?" Perhaps the CLI doesn't
> fully use the expression type when seen?
>
I am talking about having the env expressions in the batch script of the
management operations. The issue was that these are not being replaced
by the command line tools.
_______________________________________________
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: Configuration conundrum with Express

Brian Stansberry
On 10/18/11 1:28 PM, Scott Stark wrote:
> On 10/18/11 7:07 AM, Jason T. Greene wrote:
>> I think Brian's question was "Why can't we just put the env
>> expressions in the management operation?" Perhaps the CLI doesn't
>> fully use the expression type when seen?
>>
> I am talking about having the env expressions in the batch script of the
> management operations. The issue was that these are not being replaced
> by the command line tools.

They are not meant to be replaced by the command line tools; they should
be passed through to the server and stored as expressions. I'll put
through a change today in how some less-recently changed parts of the
model (e.g. interfaces, sockets) deal with expressions; I believe they
are not handling expressions that come in via the management APIs
correctly; they just deal with them properly in the parser.

> _______________________________________________
> jboss-as7-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev


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