[wildfly-dev] Customizing a provisioned server

[James R. 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 <emartins at redhat.com> 
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 <jperkins at redhat.com> 
> 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 
>> <emartins at redhat.com> 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 <sdouglas at redhat.com> 
>>> 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
>>>>  wildfly-dev at lists.jboss.org
>>>>  https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>> 
>>> 
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> wildfly-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20140904/e85079c9/attachment-0001.html