Customizing a provisioned server

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

Customizing a provisioned server

Stuart Douglas-2
Hi everyone,

Work on the provisioning tool is now well underway, so I would like to
revisit something I mentioned in my original email, which is allowing
the provisioning tool to customize a provisioned server.

I think there are a few options here, some more palatable than others.
In no particular order:

1) Customize the XML directly

Using this approach we would just directly customize the XML
configuration files. This would basically require the use of XSLT
(yuck), or require us to basically invent our own version of XSLT (even
more yuck). Even though this approach will work, and will be fairly easy
to implement, I think it would really suck from an end-user point of
view, and I think we should discount it.

2) Allow the user to provide CLI commands to customise the server

This is by far my favorite approach. The provisioning file would just
contain a list of CLI commands, and would execute them in order. I think
this is by far the most intuitive, and the CLI is well documented.

3) Allow the user to provide DMR operations to customize the server

Similar to 2, but allow the user to provide DMR or JSON operations to
customize the server. I think this is not nearly as nice as 2, as users
are much more likely to be familiar with the CLI rather than DMR.


I think 2 is by far the best approach, however it does open up the
question of how and when to execute the operations. I think the easiest
way to do this would be to just start the server in admin only mode on a
custom port (so it will not interfere with any existing running Wildfly
instances), and just execute the CLI commands in admin only mode.

Does this all sound reasonable?

Stuart

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

Re: Customizing a provisioned server

Stuart Douglas
Something I forgot to mention is that these customizations will need to
be specified per config file, so you may specify different
customizations for standalone.xml, standalone-full.xml and domain.xml
for example. Unfortunately this will involve stopping and starting the
admin only server multiple times, but I can't really see any way around
that.


Stuart Douglas wrote:

> Hi everyone,
>
> Work on the provisioning tool is now well underway, so I would like to
> revisit something I mentioned in my original email, which is allowing
> the provisioning tool to customize a provisioned server.
>
> I think there are a few options here, some more palatable than others.
> In no particular order:
>
> 1) Customize the XML directly
>
> Using this approach we would just directly customize the XML
> configuration files. This would basically require the use of XSLT
> (yuck), or require us to basically invent our own version of XSLT (even
> more yuck). Even though this approach will work, and will be fairly easy
> to implement, I think it would really suck from an end-user point of
> view, and I think we should discount it.
>
> 2) Allow the user to provide CLI commands to customise the server
>
> This is by far my favorite approach. The provisioning file would just
> contain a list of CLI commands, and would execute them in order. I think
> this is by far the most intuitive, and the CLI is well documented.
>
> 3) Allow the user to provide DMR operations to customize the server
>
> Similar to 2, but allow the user to provide DMR or JSON operations to
> customize the server. I think this is not nearly as nice as 2, as users
> are much more likely to be familiar with the CLI rather than DMR.
>
>
> I think 2 is by far the best approach, however it does open up the
> question of how and when to execute the operations. I think the easiest
> way to do this would be to just start the server in admin only mode on a
> custom port (so it will not interfere with any existing running Wildfly
> instances), and just execute the CLI commands in admin only mode.
>
> Does this all sound reasonable?
>
> Stuart
>
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Customizing a provisioned server

jtgreene
Administrator
In reply to this post by Stuart Douglas-2

On Sep 3, 2014, at 11:16 PM, Stuart Douglas <[hidden email]> wrote:

> Hi everyone,
>
> Work on the provisioning tool is now well underway, so I would like to
> revisit something I mentioned in my original email, which is allowing
> the provisioning tool to customize a provisioned server.
>
> I think there are a few options here, some more palatable than others.
> In no particular order:
>
> 1) Customize the XML directly
>
> Using this approach we would just directly customize the XML
> configuration files. This would basically require the use of XSLT
> (yuck), or require us to basically invent our own version of XSLT (even
> more yuck). Even though this approach will work, and will be fairly easy
> to implement, I think it would really suck from an end-user point of
> view, and I think we should discount it.
>
> 2) Allow the user to provide CLI commands to customise the server
>
> This is by far my favorite approach. The provisioning file would just
> contain a list of CLI commands, and would execute them in order. I think
> this is by far the most intuitive, and the CLI is well documented.
>
> 3) Allow the user to provide DMR operations to customize the server
>
> Similar to 2, but allow the user to provide DMR or JSON operations to
> customize the server. I think this is not nearly as nice as 2, as users
> are much more likely to be familiar with the CLI rather than DMR.
>
>
> I think 2 is by far the best approach, however it does open up the
> question of how and when to execute the operations. I think the easiest
> way to do this would be to just start the server in admin only mode on a
> custom port (so it will not interfere with any existing running Wildfly
> instances), and just execute the CLI commands in admin only mode.


My big concern is how we deal with overlapping configuration. If we figure that out something like 2 or 3 aren’t that much different to me. 2 is just an abbreviated syntax for the operation element.

Note that we have a feature request for “offline CLI” which amounts to really an embedded management mode with no ports.


--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat


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

Re: Customizing a provisioned server

Heiko Braun
In reply to this post by Stuart Douglas-2

2) builds on 3), right?

On 04 Sep 2014, at 06:16, Stuart Douglas <[hidden email]> wrote:

2) Allow the user to provide CLI commands to customise the server

This is by far my favorite approach. The provisioning file would just 
contain a list of CLI commands, and would execute them in order. I think 
this is by far the most intuitive, and the CLI is well documented.

3) Allow the user to provide DMR operations to customize the server

Similar to 2, but allow the user to provide DMR or JSON operations to 
customize the server. I think this is not nearly as nice as 2, as users 
are much more likely to be familiar with the CLI rather than DMR.


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

Re: Customizing a provisioned server

Thomas Heute
In reply to this post by Stuart Douglas-2

I would need to provision Wildfly remotely with something like JON or
Fabric8 for instance, the CLI would not work for that if I understand
correctly.

REST-ish API would work better I think (I guess option 3 covers that),
Fabric8 preference would likely be option 1 though (note that in this
usecase the end-user doesn't really touch the XML files, he's using a tool)

BTW: I completely missed the discussion about provisioning tool until
this email so please forgive my ignorance. If there is a document or
email thread that would help me catch up I would love to have a look.

Thomas


On 09/04/2014 06:16 AM, Stuart Douglas wrote:

> Hi everyone,
>
> Work on the provisioning tool is now well underway, so I would like to
> revisit something I mentioned in my original email, which is allowing
> the provisioning tool to customize a provisioned server.
>
> I think there are a few options here, some more palatable than others.
> In no particular order:
>
> 1) Customize the XML directly
>
> Using this approach we would just directly customize the XML
> configuration files. This would basically require the use of XSLT
> (yuck), or require us to basically invent our own version of XSLT (even
> more yuck). Even though this approach will work, and will be fairly easy
> to implement, I think it would really suck from an end-user point of
> view, and I think we should discount it.
>
> 2) Allow the user to provide CLI commands to customise the server
>
> This is by far my favorite approach. The provisioning file would just
> contain a list of CLI commands, and would execute them in order. I think
> this is by far the most intuitive, and the CLI is well documented.
>
> 3) Allow the user to provide DMR operations to customize the server
>
> Similar to 2, but allow the user to provide DMR or JSON operations to
> customize the server. I think this is not nearly as nice as 2, as users
> are much more likely to be familiar with the CLI rather than DMR.
>
>
> I think 2 is by far the best approach, however it does open up the
> question of how and when to execute the operations. I think the easiest
> way to do this would be to just start the server in admin only mode on a
> custom port (so it will not interfere with any existing running Wildfly
> instances), and just execute the CLI commands in admin only mode.
>
> Does this all sound reasonable?
>
> Stuart
>
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Customizing a provisioned server

Eduardo Sant´Ana da Silva


2014-09-04 7:15 GMT-03:00 Thomas Heute <[hidden email]>:

I would need to provision Wildfly remotely with something like JON or
Fabric8 for instance, the CLI would not work for that if I understand
correctly.

REST-ish API would work better I think (I guess option 3 covers that),
Fabric8 preference would likely be option 1 though (note that in this
usecase the end-user doesn't really touch the XML files, he's using a tool)

BTW: I completely missed the discussion about provisioning tool until
this email so please forgive my ignorance. If there is a document or
email thread that would help me catch up I would love to have a look.

Thomas


On 09/04/2014 06:16 AM, Stuart Douglas wrote:
> Hi everyone,
>
> Work on the provisioning tool is now well underway, so I would like to
> revisit something I mentioned in my original email, which is allowing
> the provisioning tool to customize a provisioned server.
>
> I think there are a few options here, some more palatable than others.
> In no particular order:
>
> 1) Customize the XML directly
>
> Using this approach we would just directly customize the XML
> configuration files. This would basically require the use of XSLT
> (yuck), or require us to basically invent our own version of XSLT (even
> more yuck). Even though this approach will work, and will be fairly easy
> to implement, I think it would really suck from an end-user point of
> view, and I think we should discount it.
>
> 2) Allow the user to provide CLI commands to customise the server
>
> This is by far my favorite approach. The provisioning file would just
> contain a list of CLI commands, and would execute them in order. I think
> this is by far the most intuitive, and the CLI is well documented.
>
> 3) Allow the user to provide DMR operations to customize the server
>
> Similar to 2, but allow the user to provide DMR or JSON operations to
> customize the server. I think this is not nearly as nice as 2, as users
> are much more likely to be familiar with the CLI rather than DMR.
>
>
> I think 2 is by far the best approach, however it does open up the
> question of how and when to execute the operations. I think the easiest
> way to do this would be to just start the server in admin only mode on a
> custom port (so it will not interfere with any existing running Wildfly
> instances), and just execute the CLI commands in admin only mode.
>
> Does this all sound reasonable?
>
> Stuart
>
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev



--
__________________________
Eduardo Sant'Ana da Silva - Dr.
Pesquisador / Consultor de TI


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

Re: Customizing a provisioned server

Tomaž Cerar-2
In reply to this post by Stuart Douglas-2
Best would be to go with 3)

as it works directly with mgmt interface without need for CLI interpreter.
This way commands an be executed ether localy or remotely via REST api.

CLI enhancements are not all that useful for customizations, beyond few shortcuts with high-level commands.

Tomaz


On Thu, Sep 4, 2014 at 6:16 AM, Stuart Douglas <[hidden email]> wrote:
Hi everyone,

Work on the provisioning tool is now well underway, so I would like to
revisit something I mentioned in my original email, which is allowing
the provisioning tool to customize a provisioned server.

I think there are a few options here, some more palatable than others.
In no particular order:

1) Customize the XML directly

Using this approach we would just directly customize the XML
configuration files. This would basically require the use of XSLT
(yuck), or require us to basically invent our own version of XSLT (even
more yuck). Even though this approach will work, and will be fairly easy
to implement, I think it would really suck from an end-user point of
view, and I think we should discount it.

2) Allow the user to provide CLI commands to customise the server

This is by far my favorite approach. The provisioning file would just
contain a list of CLI commands, and would execute them in order. I think
this is by far the most intuitive, and the CLI is well documented.

3) Allow the user to provide DMR operations to customize the server

Similar to 2, but allow the user to provide DMR or JSON operations to
customize the server. I think this is not nearly as nice as 2, as users
are much more likely to be familiar with the CLI rather than DMR.


I think 2 is by far the best approach, however it does open up the
question of how and when to execute the operations. I think the easiest
way to do this would be to just start the server in admin only mode on a
custom port (so it will not interfere with any existing running Wildfly
instances), and just execute the CLI commands in admin only mode.

Does this all sound reasonable?

Stuart

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


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

Re: Customizing a provisioned server

Eduardo Martins-2
In reply to this post by Stuart Douglas-2
Perhaps we should start with extending the capabilities of the (standalone) server provisioner api, that we now use to build the server, to stop a server, upgrade it offline, and start it again.

The offline upgrade would for now first delete files that were added in the previous version of the server provision, supporting excludes/includes filters to don’t mess with user/server data, and then provision “everything” again, skipping files that were kept in the output dir. Tools would have access to the previous version of the server provision and start editing from that.

—E

On 04 Sep 2014, at 05:16, Stuart Douglas <[hidden email]> wrote:

> Hi everyone,
>
> Work on the provisioning tool is now well underway, so I would like to
> revisit something I mentioned in my original email, which is allowing
> the provisioning tool to customize a provisioned server.
>
> I think there are a few options here, some more palatable than others.
> In no particular order:
>
> 1) Customize the XML directly
>
> Using this approach we would just directly customize the XML
> configuration files. This would basically require the use of XSLT
> (yuck), or require us to basically invent our own version of XSLT (even
> more yuck). Even though this approach will work, and will be fairly easy
> to implement, I think it would really suck from an end-user point of
> view, and I think we should discount it.
>
> 2) Allow the user to provide CLI commands to customise the server
>
> This is by far my favorite approach. The provisioning file would just
> contain a list of CLI commands, and would execute them in order. I think
> this is by far the most intuitive, and the CLI is well documented.
>
> 3) Allow the user to provide DMR operations to customize the server
>
> Similar to 2, but allow the user to provide DMR or JSON operations to
> customize the server. I think this is not nearly as nice as 2, as users
> are much more likely to be familiar with the CLI rather than DMR.
>
>
> I think 2 is by far the best approach, however it does open up the
> question of how and when to execute the operations. I think the easiest
> way to do this would be to just start the server in admin only mode on a
> custom port (so it will not interfere with any existing running Wildfly
> instances), and just execute the CLI commands in admin only mode.
>
> Does this all sound reasonable?
>
> Stuart
>
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev


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

Re: Customizing a provisioned server

Eduardo Martins-2
We would still need a few mngt ops, to fetch and upgrade the server provisioning. The upgrade op perhaps would just trigger a backup, store the new server provisioning and setup something that would indicate the need for upgrade, and restart the server. Then on startup, it would notice the upgrade and do it, only after that completes the real server would be started.

Wdyt?

—E

On 04 Sep 2014, at 14:06, Eduardo Martins <[hidden email]> wrote:

> Perhaps we should start with extending the capabilities of the (standalone) server provisioner api, that we now use to build the server, to stop a server, upgrade it offline, and start it again.
>
> The offline upgrade would for now first delete files that were added in the previous version of the server provision, supporting excludes/includes filters to don’t mess with user/server data, and then provision “everything” again, skipping files that were kept in the output dir. Tools would have access to the previous version of the server provision and start editing from that.
>
> —E
>
> On 04 Sep 2014, at 05:16, Stuart Douglas <[hidden email]> wrote:
>
>> Hi everyone,
>>
>> Work on the provisioning tool is now well underway, so I would like to
>> revisit something I mentioned in my original email, which is allowing
>> the provisioning tool to customize a provisioned server.
>>
>> I think there are a few options here, some more palatable than others.
>> In no particular order:
>>
>> 1) Customize the XML directly
>>
>> Using this approach we would just directly customize the XML
>> configuration files. This would basically require the use of XSLT
>> (yuck), or require us to basically invent our own version of XSLT (even
>> more yuck). Even though this approach will work, and will be fairly easy
>> to implement, I think it would really suck from an end-user point of
>> view, and I think we should discount it.
>>
>> 2) Allow the user to provide CLI commands to customise the server
>>
>> This is by far my favorite approach. The provisioning file would just
>> contain a list of CLI commands, and would execute them in order. I think
>> this is by far the most intuitive, and the CLI is well documented.
>>
>> 3) Allow the user to provide DMR operations to customize the server
>>
>> Similar to 2, but allow the user to provide DMR or JSON operations to
>> customize the server. I think this is not nearly as nice as 2, as users
>> are much more likely to be familiar with the CLI rather than DMR.
>>
>>
>> I think 2 is by far the best approach, however it does open up the
>> question of how and when to execute the operations. I think the easiest
>> way to do this would be to just start the server in admin only mode on a
>> custom port (so it will not interfere with any existing running Wildfly
>> instances), and just execute the CLI commands in admin only mode.
>>
>> Does this all sound reasonable?
>>
>> Stuart
>>
>> _______________________________________________
>> wildfly-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev


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

Re: Customizing a provisioned server

James Perkins
In reply to this post by Eduardo Martins-2
If I understand it correctly the provisioning tool is used to create a server. What server will be running that would need to be stopped and then restarted? This doesn't sound like a provisioning thing to me. Is it also meant to do patching?

--
James R. Perkins
JBoss by Red Hat

On Thu, Sep 4, 2014 at 6:06 AM, Eduardo Martins <[hidden email]> wrote:
Perhaps we should start with extending the capabilities of the (standalone) server provisioner api, that we now use to build the server, to stop a server, upgrade it offline, and start it again. The offline upgrade would for now first delete files that were added in the previous version of the server provision, supporting excludes/includes filters to don’t mess with user/server data, and then provision “everything” again, skipping files that were kept in the output dir. Tools would have access to the previous version of the server provision and start editing from that. —E On 04 Sep 2014, at 05:16, Stuart Douglas <[hidden email]> wrote:
Hi everyone, Work on the provisioning tool is now well underway, so I would like to revisit something I mentioned in my original email, which is allowing the provisioning tool to customize a provisioned server. I think there are a few options here, some more palatable than others. In no particular order: 1) Customize the XML directly Using this approach we would just directly customize the XML configuration files. This would basically require the use of XSLT (yuck), or require us to basically invent our own version of XSLT (even more yuck). Even though this approach will work, and will be fairly easy to implement, I think it would really suck from an end-user point of view, and I think we should discount it. 2) Allow the user to provide CLI commands to customise the server This is by far my favorite approach. The provisioning file would just contain a list of CLI commands, and would execute them in order. I think this is by far the most intuitive, and the CLI is well documented. 3) Allow the user to provide DMR operations to customize the server Similar to 2, but allow the user to provide DMR or JSON operations to customize the server. I think this is not nearly as nice as 2, as users are much more likely to be familiar with the CLI rather than DMR. I think 2 is by far the best approach, however it does open up the question of how and when to execute the operations. I think the easiest way to do this would be to just start the server in admin only mode on a custom port (so it will not interfere with any existing running Wildfly instances), and just execute the CLI commands in admin only mode. Does this all sound reasonable? Stuart _______________________________________________ wildfly-dev mailing list [hidden email] https://lists.jboss.org/mailman/listinfo/wildfly-dev
_______________________________________________ wildfly-dev mailing list [hidden email] https://lists.jboss.org/mailman/listinfo/wildfly-dev

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

Re: Customizing a provisioned server

Eduardo Martins-2
The provisioning tool assembles a server from a set of feature packs, it will also be able to customize the assembled and possibly running server, for instance add feature pack, add modules, etc.

—E

On 04 Sep 2014, at 16:51, James R. Perkins <[hidden email]> wrote:

If I understand it correctly the provisioning tool is used to create a server. What server will be running that would need to be stopped and then restarted? This doesn't sound like a provisioning thing to me. Is it also meant to do patching?

--
James R. Perkins
JBoss by Red Hat

On Thu, Sep 4, 2014 at 6:06 AM, Eduardo Martins <[hidden email]> wrote:
Perhaps we should start with extending the capabilities of the (standalone) server provisioner api, that we now use to build the server, to stop a server, upgrade it offline, and start it again. The offline upgrade would for now first delete files that were added in the previous version of the server provision, supporting excludes/includes filters to don’t mess with user/server data, and then provision “everything” again, skipping files that were kept in the output dir. Tools would have access to the previous version of the server provision and start editing from that. —E On 04 Sep 2014, at 05:16, Stuart Douglas <[hidden email]> wrote:
Hi everyone, Work on the provisioning tool is now well underway, so I would like to revisit something I mentioned in my original email, which is allowing the provisioning tool to customize a provisioned server. I think there are a few options here, some more palatable than others. In no particular order: 1) Customize the XML directly Using this approach we would just directly customize the XML configuration files. This would basically require the use of XSLT (yuck), or require us to basically invent our own version of XSLT (even more yuck). Even though this approach will work, and will be fairly easy to implement, I think it would really suck from an end-user point of view, and I think we should discount it. 2) Allow the user to provide CLI commands to customise the server This is by far my favorite approach. The provisioning file would just contain a list of CLI commands, and would execute them in order. I think this is by far the most intuitive, and the CLI is well documented. 3) Allow the user to provide DMR operations to customize the server Similar to 2, but allow the user to provide DMR or JSON operations to customize the server. I think this is not nearly as nice as 2, as users are much more likely to be familiar with the CLI rather than DMR. I think 2 is by far the best approach, however it does open up the question of how and when to execute the operations. I think the easiest way to do this would be to just start the server in admin only mode on a custom port (so it will not interfere with any existing running Wildfly instances), and just execute the CLI commands in admin only mode. Does this all sound reasonable? Stuart _______________________________________________ wildfly-dev mailing list [hidden email] https://lists.jboss.org/mailman/listinfo/wildfly-dev
_______________________________________________ wildfly-dev mailing list [hidden email] https://lists.jboss.org/mailman/listinfo/wildfly-dev


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

Re: Customizing a provisioned server

James Perkins
Ah okay so we may add feature packs to an already "provisioned" server.

I don't think it's a good idea for the provisioning to tool to stop and start a server. If you stop shutdown a server, apply the new feature packs and start a new process. The new process may inherit the parent processes I/O which could be problematic.

--
James R. Perkins
JBoss by Red Hat

On Thu, Sep 4, 2014 at 9:06 AM, Eduardo Martins <[hidden email]> wrote:
The provisioning tool assembles a server from a set of feature packs, it will also be able to customize the assembled and possibly running server, for instance add feature pack, add modules, etc.

—E

On 04 Sep 2014, at 16:51, James R. Perkins <[hidden email]> wrote:

If I understand it correctly the provisioning tool is used to create a server. What server will be running that would need to be stopped and then restarted? This doesn't sound like a provisioning thing to me. Is it also meant to do patching?

--
James R. Perkins
JBoss by Red Hat

On Thu, Sep 4, 2014 at 6:06 AM, Eduardo Martins <[hidden email]> wrote:
Perhaps we should start with extending the capabilities of the (standalone) server provisioner api, that we now use to build the server, to stop a server, upgrade it offline, and start it again. The offline upgrade would for now first delete files that were added in the previous version of the server provision, supporting excludes/includes filters to don’t mess with user/server data, and then provision “everything” again, skipping files that were kept in the output dir. Tools would have access to the previous version of the server provision and start editing from that. —E On 04 Sep 2014, at 05:16, Stuart Douglas <[hidden email]> wrote:
Hi everyone, Work on the provisioning tool is now well underway, so I would like to revisit something I mentioned in my original email, which is allowing the provisioning tool to customize a provisioned server. I think there are a few options here, some more palatable than others. In no particular order: 1) Customize the XML directly Using this approach we would just directly customize the XML configuration files. This would basically require the use of XSLT (yuck), or require us to basically invent our own version of XSLT (even more yuck). Even though this approach will work, and will be fairly easy to implement, I think it would really suck from an end-user point of view, and I think we should discount it. 2) Allow the user to provide CLI commands to customise the server This is by far my favorite approach. The provisioning file would just contain a list of CLI commands, and would execute them in order. I think this is by far the most intuitive, and the CLI is well documented. 3) Allow the user to provide DMR operations to customize the server Similar to 2, but allow the user to provide DMR or JSON operations to customize the server. I think this is not nearly as nice as 2, as users are much more likely to be familiar with the CLI rather than DMR. I think 2 is by far the best approach, however it does open up the question of how and when to execute the operations. I think the easiest way to do this would be to just start the server in admin only mode on a custom port (so it will not interfere with any existing running Wildfly instances), and just execute the CLI commands in admin only mode. Does this all sound reasonable? Stuart _______________________________________________ wildfly-dev mailing list [hidden email] https://lists.jboss.org/mailman/listinfo/wildfly-dev
_______________________________________________ wildfly-dev mailing list [hidden email] https://lists.jboss.org/mailman/listinfo/wildfly-dev


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

Re: Customizing a provisioned server

Brian Stansberry
In reply to this post by Heiko Braun
Not necessarily. Everything in the end speaks the underlying management
API. But that doesn't mean the syntax needs to be the raw dmr or json
equivalent.

This is primarily about UX and parsing. If we supported CLI syntax
there's no requirement to also parse basic DMR. The CLI itself doesn't.

If we support CLI syntax though it seems logical to use the CLI libs
themselves to do it. Otherwise we are maintaining two code bases for the
same thing. (I doubt the CLI parsing code can easily be extracted out
for reuse, although I may be wrong.)

On 9/4/14, 2:05 AM, Heiko Braun wrote:

>
> 2) builds on 3), right?
>
> On 04 Sep 2014, at 06:16, Stuart Douglas <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>> 2) Allow the user to provide CLI commands to customise the server
>>
>> This is by far my favorite approach. The provisioning file would just
>> contain a list of CLI commands, and would execute them in order. I think
>> this is by far the most intuitive, and the CLI is well documented.
>>
>> 3) Allow the user to provide DMR operations to customize the server
>>
>> Similar to 2, but allow the user to provide DMR or JSON operations to
>> customize the server. I think this is not nearly as nice as 2, as users
>> are much more likely to be familiar with the CLI rather than DMR.
>
>
>
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>


--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Customizing a provisioned server

Stuart Douglas
I thought that it was already possible to use the CLI in library mode?

The tool will have access to a full server at the point it needs to do
this (as the server has already been provisioned), so it could
potentially just load the CLI lib from the provisioned server and use that.

Stuart

Brian Stansberry wrote:

> Not necessarily. Everything in the end speaks the underlying management
> API. But that doesn't mean the syntax needs to be the raw dmr or json
> equivalent.
>
> This is primarily about UX and parsing. If we supported CLI syntax
> there's no requirement to also parse basic DMR. The CLI itself doesn't.
>
> If we support CLI syntax though it seems logical to use the CLI libs
> themselves to do it. Otherwise we are maintaining two code bases for the
> same thing. (I doubt the CLI parsing code can easily be extracted out
> for reuse, although I may be wrong.)
>
> On 9/4/14, 2:05 AM, Heiko Braun wrote:
>> 2) builds on 3), right?
>>
>> On 04 Sep 2014, at 06:16, Stuart Douglas<[hidden email]
>> <mailto:[hidden email]>>  wrote:
>>
>>> 2) Allow the user to provide CLI commands to customise the server
>>>
>>> This is by far my favorite approach. The provisioning file would just
>>> contain a list of CLI commands, and would execute them in order. I think
>>> this is by far the most intuitive, and the CLI is well documented.
>>>
>>> 3) Allow the user to provide DMR operations to customize the server
>>>
>>> Similar to 2, but allow the user to provide DMR or JSON operations to
>>> customize the server. I think this is not nearly as nice as 2, as users
>>> are much more likely to be familiar with the CLI rather than DMR.
>>
>>
>> _______________________________________________
>> wildfly-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>
>
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Customizing a provisioned server

Stuart Douglas
In reply to this post by Thomas Heute


Thomas Heute wrote:
> I would need to provision Wildfly remotely with something like JON or
> Fabric8 for instance, the CLI would not work for that if I understand
> correctly.
>

This is more about how to customize a server after it has been
provisioned. So for example you can have a file that basically says 'I
want a WF instance with these features, these deployments, and then
perform these mgmt ops to configure it'

Stuart

> REST-ish API would work better I think (I guess option 3 covers that),
> Fabric8 preference would likely be option 1 though (note that in this
> usecase the end-user doesn't really touch the XML files, he's using a tool)
>
> BTW: I completely missed the discussion about provisioning tool until
> this email so please forgive my ignorance. If there is a document or
> email thread that would help me catch up I would love to have a look.
>
> Thomas
>
>
> On 09/04/2014 06:16 AM, Stuart Douglas wrote:
>> Hi everyone,
>>
>> Work on the provisioning tool is now well underway, so I would like to
>> revisit something I mentioned in my original email, which is allowing
>> the provisioning tool to customize a provisioned server.
>>
>> I think there are a few options here, some more palatable than others.
>> In no particular order:
>>
>> 1) Customize the XML directly
>>
>> Using this approach we would just directly customize the XML
>> configuration files. This would basically require the use of XSLT
>> (yuck), or require us to basically invent our own version of XSLT (even
>> more yuck). Even though this approach will work, and will be fairly easy
>> to implement, I think it would really suck from an end-user point of
>> view, and I think we should discount it.
>>
>> 2) Allow the user to provide CLI commands to customise the server
>>
>> This is by far my favorite approach. The provisioning file would just
>> contain a list of CLI commands, and would execute them in order. I think
>> this is by far the most intuitive, and the CLI is well documented.
>>
>> 3) Allow the user to provide DMR operations to customize the server
>>
>> Similar to 2, but allow the user to provide DMR or JSON operations to
>> customize the server. I think this is not nearly as nice as 2, as users
>> are much more likely to be familiar with the CLI rather than DMR.
>>
>>
>> I think 2 is by far the best approach, however it does open up the
>> question of how and when to execute the operations. I think the easiest
>> way to do this would be to just start the server in admin only mode on a
>> custom port (so it will not interfere with any existing running Wildfly
>> instances), and just execute the CLI commands in admin only mode.
>>
>> Does this all sound reasonable?
>>
>> Stuart
>>
>> _______________________________________________
>> wildfly-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Customizing a provisioned server

Stuart Douglas
In reply to this post by Tomaž Cerar-2
The problem with 3 is that for the most part users do not use DMR
directly, they use the CLI, and all our documentation reflects this. If
we use DMR directly for this it just one more thing that we require our
users to learn.

Stuart

Tomaž Cerar wrote:

> Best would be to go with 3)
>
> as it works directly with mgmt interface without need for CLI interpreter.
> This way commands an be executed ether localy or remotely via REST api.
>
> CLI enhancements are not all that useful for customizations, beyond few
> shortcuts with high-level commands.
>
> Tomaz
>
>
> On Thu, Sep 4, 2014 at 6:16 AM, Stuart Douglas <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     Hi everyone,
>
>     Work on the provisioning tool is now well underway, so I would like to
>     revisit something I mentioned in my original email, which is allowing
>     the provisioning tool to customize a provisioned server.
>
>     I think there are a few options here, some more palatable than others.
>     In no particular order:
>
>     1) Customize the XML directly
>
>     Using this approach we would just directly customize the XML
>     configuration files. This would basically require the use of XSLT
>     (yuck), or require us to basically invent our own version of XSLT (even
>     more yuck). Even though this approach will work, and will be fairly easy
>     to implement, I think it would really suck from an end-user point of
>     view, and I think we should discount it.
>
>     2) Allow the user to provide CLI commands to customise the server
>
>     This is by far my favorite approach. The provisioning file would just
>     contain a list of CLI commands, and would execute them in order. I think
>     this is by far the most intuitive, and the CLI is well documented.
>
>     3) Allow the user to provide DMR operations to customize the server
>
>     Similar to 2, but allow the user to provide DMR or JSON operations to
>     customize the server. I think this is not nearly as nice as 2, as users
>     are much more likely to be familiar with the CLI rather than DMR.
>
>
>     I think 2 is by far the best approach, however it does open up the
>     question of how and when to execute the operations. I think the easiest
>     way to do this would be to just start the server in admin only mode on a
>     custom port (so it will not interfere with any existing running Wildfly
>     instances), and just execute the CLI commands in admin only mode.
>
>     Does this all sound reasonable?
>
>     Stuart
>
>     _______________________________________________
>     wildfly-dev mailing list
>     [hidden email] <mailto:[hidden email]>
>     https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Customizing a provisioned server

Brian Stansberry
In reply to this post by Stuart Douglas-2
On 9/3/14, 11:16 PM, Stuart Douglas wrote:

> Hi everyone,
>
> Work on the provisioning tool is now well underway, so I would like to
> revisit something I mentioned in my original email, which is allowing
> the provisioning tool to customize a provisioned server.
>
> I think there are a few options here, some more palatable than others.
> In no particular order:
>
> 1) Customize the XML directly
>
> Using this approach we would just directly customize the XML
> configuration files. This would basically require the use of XSLT
> (yuck), or require us to basically invent our own version of XSLT (even
> more yuck). Even though this approach will work, and will be fairly easy
> to implement, I think it would really suck from an end-user point of
> view, and I think we should discount it.
>

I can't see this as workable at all for generic customization. I could
see it for a setup where a user provides a list of capabilities, and we
produce a tailored xml that provides those capabilities. The xml is
still some standard config, just mildly customizable by listing
capabilities. Implemented perhaps using something like the templating
thing we've used in the past.

But if the idea is to support arbitrary config changes, no way xml is an
option.

> 2) Allow the user to provide CLI commands to customise the server
>
> This is by far my favorite approach. The provisioning file would just
> contain a list of CLI commands, and would execute them in order. I think
> this is by far the most intuitive, and the CLI is well documented.
>
> 3) Allow the user to provide DMR operations to customize the server
>
> Similar to 2, but allow the user to provide DMR or JSON operations to
> customize the server. I think this is not nearly as nice as 2, as users
> are much more likely to be familiar with the CLI rather than DMR.
>
>
> I think 2 is by far the best approach, however it does open up the
> question of how and when to execute the operations. I think the easiest
> way to do this would be to just start the server in admin only mode on a
> custom port (so it will not interfere with any existing running Wildfly
> instances), and just execute the CLI commands in admin only mode.
>

If we are going to use the management API, we need to start an embedded
process with no ports open. Otherwise people should just use one of our
existing management tools.

> Does this all sound reasonable?
>
> Stuart
>
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>


--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Customizing a provisioned server

Brian Stansberry
In reply to this post by Stuart Douglas
Yes, the CLI can be used as a library. But it works via remote
communication, which IMHO is not something we should be doing here.

Running the server embedded in the tool with no ports open is fine though.

I think if people want to configure the server remotely they should
launch it and use one of the existing tools.

On 9/4/14, 4:14 PM, Stuart Douglas wrote:

> I thought that it was already possible to use the CLI in library mode?
>
> The tool will have access to a full server at the point it needs to do
> this (as the server has already been provisioned), so it could
> potentially just load the CLI lib from the provisioned server and use that.
>
> Stuart
>
> Brian Stansberry wrote:
>> Not necessarily. Everything in the end speaks the underlying management
>> API. But that doesn't mean the syntax needs to be the raw dmr or json
>> equivalent.
>>
>> This is primarily about UX and parsing. If we supported CLI syntax
>> there's no requirement to also parse basic DMR. The CLI itself doesn't.
>>
>> If we support CLI syntax though it seems logical to use the CLI libs
>> themselves to do it. Otherwise we are maintaining two code bases for the
>> same thing. (I doubt the CLI parsing code can easily be extracted out
>> for reuse, although I may be wrong.)
>>
>> On 9/4/14, 2:05 AM, Heiko Braun wrote:
>>> 2) builds on 3), right?
>>>
>>> On 04 Sep 2014, at 06:16, Stuart Douglas<[hidden email]
>>> <mailto:[hidden email]>>  wrote:
>>>
>>>> 2) Allow the user to provide CLI commands to customise the server
>>>>
>>>> This is by far my favorite approach. The provisioning file would just
>>>> contain a list of CLI commands, and would execute them in order. I
>>>> think
>>>> this is by far the most intuitive, and the CLI is well documented.
>>>>
>>>> 3) Allow the user to provide DMR operations to customize the server
>>>>
>>>> Similar to 2, but allow the user to provide DMR or JSON operations to
>>>> customize the server. I think this is not nearly as nice as 2, as users
>>>> are much more likely to be familiar with the CLI rather than DMR.
>>>
>>>
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>
>>
>>


--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Customizing a provisioned server

Brian Stansberry
In reply to this post by Stuart Douglas-2
Are we going to do anything related to the "Provisioning" stuff on [1]
here? That's an intermediate level of granularity than saying "I want
xyz feature pack" (and perhaps tweaking the module set a bit) and doing
a bunch of detailed config like
"/subsystem=elytron/elytron-thingy=foo:write-attribute(name=bar,value=true).
It's more for stuff like saying "I want jts, I want remote ejb, I want
JSR-160" all of which are optional capabilities provided by various
extensions.


[1] https://developer.jboss.org/docs/DOC-52712
On 9/3/14, 11:16 PM, Stuart Douglas wrote:

> Hi everyone,
>
> Work on the provisioning tool is now well underway, so I would like to
> revisit something I mentioned in my original email, which is allowing
> the provisioning tool to customize a provisioned server.
>
> I think there are a few options here, some more palatable than others.
> In no particular order:
>
> 1) Customize the XML directly
>
> Using this approach we would just directly customize the XML
> configuration files. This would basically require the use of XSLT
> (yuck), or require us to basically invent our own version of XSLT (even
> more yuck). Even though this approach will work, and will be fairly easy
> to implement, I think it would really suck from an end-user point of
> view, and I think we should discount it.
>
> 2) Allow the user to provide CLI commands to customise the server
>
> This is by far my favorite approach. The provisioning file would just
> contain a list of CLI commands, and would execute them in order. I think
> this is by far the most intuitive, and the CLI is well documented.
>
> 3) Allow the user to provide DMR operations to customize the server
>
> Similar to 2, but allow the user to provide DMR or JSON operations to
> customize the server. I think this is not nearly as nice as 2, as users
> are much more likely to be familiar with the CLI rather than DMR.
>
>
> I think 2 is by far the best approach, however it does open up the
> question of how and when to execute the operations. I think the easiest
> way to do this would be to just start the server in admin only mode on a
> custom port (so it will not interfere with any existing running Wildfly
> instances), and just execute the CLI commands in admin only mode.
>
> Does this all sound reasonable?
>
> Stuart
>
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>


--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Customizing a provisioned server

Thomas Heute
In reply to this post by Stuart Douglas

On 09/04/2014 11:15 PM, Stuart Douglas wrote:

>
>
> Thomas Heute wrote:
>> I would need to provision Wildfly remotely with something like JON or
>> Fabric8 for instance, the CLI would not work for that if I understand
>> correctly.
>>
>
> This is more about how to customize a server after it has been
> provisioned. So for example you can have a file that basically says 'I
> want a WF instance with these features, these deployments, and then
> perform these mgmt ops to configure it'


Sounds like what I want to do remotely :)
Let's take an example, I would like to be able to "deploy and configure"
keycloak on a group of servers (i can handle the "group" part).
Deploying and installing keycloak today requires to:
     - Add a few modules
     - add 1 extension and 1 subsytem in standalone/domain.xml
     - add 1 security domain in standalone/domain.xml

If Keycloak could be delivered as "feature pack" to do the 3 steps above
I would still want the possibility to do this remotely on a set of servers.

You could argue that you need to prepare a package beforehand "locally"
and they deploy the fully customized WF but I don't think it would
always be the preferred solution

Does that make sense ?

Thomas

>
> Stuart
>
>> REST-ish API would work better I think (I guess option 3 covers that),
>> Fabric8 preference would likely be option 1 though (note that in this
>> usecase the end-user doesn't really touch the XML files, he's using a
>> tool)
>>
>> BTW: I completely missed the discussion about provisioning tool until
>> this email so please forgive my ignorance. If there is a document or
>> email thread that would help me catch up I would love to have a look.
>>
>> Thomas
>>
>>
>> On 09/04/2014 06:16 AM, Stuart Douglas wrote:
>>> Hi everyone,
>>>
>>> Work on the provisioning tool is now well underway, so I would like to
>>> revisit something I mentioned in my original email, which is allowing
>>> the provisioning tool to customize a provisioned server.
>>>
>>> I think there are a few options here, some more palatable than others.
>>> In no particular order:
>>>
>>> 1) Customize the XML directly
>>>
>>> Using this approach we would just directly customize the XML
>>> configuration files. This would basically require the use of XSLT
>>> (yuck), or require us to basically invent our own version of XSLT (even
>>> more yuck). Even though this approach will work, and will be fairly
>>> easy
>>> to implement, I think it would really suck from an end-user point of
>>> view, and I think we should discount it.
>>>
>>> 2) Allow the user to provide CLI commands to customise the server
>>>
>>> This is by far my favorite approach. The provisioning file would just
>>> contain a list of CLI commands, and would execute them in order. I
>>> think
>>> this is by far the most intuitive, and the CLI is well documented.
>>>
>>> 3) Allow the user to provide DMR operations to customize the server
>>>
>>> Similar to 2, but allow the user to provide DMR or JSON operations to
>>> customize the server. I think this is not nearly as nice as 2, as users
>>> are much more likely to be familiar with the CLI rather than DMR.
>>>
>>>
>>> I think 2 is by far the best approach, however it does open up the
>>> question of how and when to execute the operations. I think the easiest
>>> way to do this would be to just start the server in admin only mode
>>> on a
>>> custom port (so it will not interfere with any existing running Wildfly
>>> instances), and just execute the CLI commands in admin only mode.
>>>
>>> Does this all sound reasonable?
>>>
>>> Stuart
>>>
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>
>> _______________________________________________
>> wildfly-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev

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