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(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev

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.

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&lt;sdouglas(a)redhat.com > <mailto:sdouglas@redhat.com>> 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 > wildfly-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev >

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(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev

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 > wildfly-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > _______________________________________________ wildfly-dev mailing list wildfly-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev

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 >>> wildfly-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>> >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev

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(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev

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.

On 5 Sep 2014, at 09:59, Tomaž Cerar <tomaz.cerar(a)gmail.com&gt; wrote: > > On Thu, Sep 4, 2014 at 11:17 PM, Stuart Douglas <stuart.w.douglas(a)gmail.com&gt; wrote: > 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. > > > 90%+ of what users do in CLI is direct DMR. > Things that CLI adds that are not part of native DMR are handlers like: > > - ls (instead of :read-resource), > - reload (instead of :reload) > - try,catch > - batch* > - if, else > - clear, quit > + some others > > but in general most of the commands people write are direct DMR. > CLI only adds lots of usability features on top of them like tab completion. > > for example > /subsystem=io/worker=new-worker:add() > is 100% dmr operation. Yes, but isn’t the issue that it is nicer for end users, who are used to the CLI to write this rather than either using the serialized forms of the the DMR representation, e.g. either (raw DMR) { "address" => [ ("subsystem" => "io"), ("worker" => "new-worker") ], "operation" => “add” } or (JSON) { "address" : [ { "subsystem" : "io" }, { "worker" : "new-worker" } ], "operation" : "add" } is is a lot more usable to just be able to say /subsystem=io/worker=new-worker:add() > > In any case if we go with WildFly embedded in CLI mode all this discussion is non issue. > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev _______________________________________________ wildfly-dev mailing list wildfly-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev

The nice thing about expressing this in DMR as that you could have one consistent data model vs nesting a bunch of different ones (DMR inside of CLI syntax inside of XML syntax). We could also just add path support into the management API, just parse the equivalent string. { “install-feature-list” => [“io”, “something-else"], “tasks” => [ { “address” => “/subsystem=io/worker=new-worker1”,

“operation” => “add” }, { “address” => “/subsystem=io/worker=new-worker2”, “operation” => “add” }, { “address” => “/subsystem=io/worker=new-worker3”, “operation” => “add” } ] } Note that the CLI doesn’t hide DMR, in particular with an add operation. So the difference will be pretty small imo. On Sep 5, 2014, at 4:47 AM, Emmanuel Hugonnet <ehugonne(a)redhat.com&gt; wrote: > Can't the provisionning "build tool" convert the cli scripts in dmr in building the feature pack ? > Thus dmr would be the lingua franca of the provisionning itself. > That might mean more rebuilding during the feature pack creation / configuration from a user point of view. > Emmanuel > > Le 05/09/2014 11:22, Kabir Khan a écrit : >> >> On 5 Sep 2014, at 09:59, Tomaž Cerar <tomaz.cerar(a)gmail.com&gt; wrote: >> >>> >>> On Thu, Sep 4, 2014 at 11:17 PM, Stuart Douglas <stuart.w.douglas(a)gmail.com&gt; wrote: >>> 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. >>> >>> >>> 90%+ of what users do in CLI is direct DMR. >>> Things that CLI adds that are not part of native DMR are handlers like: >>> >>> - ls (instead of :read-resource), >>> - reload (instead of :reload) >>> - try,catch >>> - batch* >>> - if, else >>> - clear, quit >>> + some others >>> >>> but in general most of the commands people write are direct DMR. >>> CLI only adds lots of usability features on top of them like tab completion. >>> >>> for example >>> /subsystem=io/worker=new-worker:add() >>> is 100% dmr operation. >> Yes, but isn’t the issue that it is nicer for end users, who are used to the CLI to write this rather than either using the serialized forms of the the DMR representation, e.g. either (raw DMR) >> { >> "address" => [ >> ("subsystem" => "io"), >> ("worker" => "new-worker") >> ], >> "operation" => “add” >> } >> or (JSON) >> { >> "address" : [ >> { >> "subsystem" : "io" >> }, >> { >> "worker" : "new-worker" >> } >> ], >> "operation" : "add" >> } >> is is a lot more usable to just be able to say >> /subsystem=io/worker=new-worker:add() >> >> >>> >>> In any case if we go with WildFly embedded in CLI mode all this discussion is non issue. >>> >>> >>> _______________________________________________ >>> wildfly-dev mailing list >>> wildfly-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> >> >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev -- Jason T. Greene WildFly Lead / JBoss EAP Platform Architect JBoss, a division of Red Hat _______________________________________________ wildfly-dev mailing list wildfly-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev

On 5 Sep 2014, at 09:59, Tomaž Cerar <tomaz.cerar(a)gmail.com&gt; wrote: > > On Thu, Sep 4, 2014 at 11:17 PM, Stuart Douglas < stuart.w.douglas(a)gmail.com&gt; wrote: > 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. > > > 90%+ of what users do in CLI is direct DMR. > Things that CLI adds that are not part of native DMR are handlers like: > > - ls (instead of :read-resource), > - reload (instead of :reload) > - try,catch > - batch* > - if, else > - clear, quit > + some others > > but in general most of the commands people write are direct DMR. > CLI only adds lots of usability features on top of them like tab completion. > > for example > /subsystem=io/worker=new-worker:add() > is 100% dmr operation. Yes, but isn’t the issue that it is nicer for end users, who are used to the CLI to write this rather than either using the serialized forms of the the DMR representation, e.g. either (raw DMR) { "address" => [ ("subsystem" => "io"), ("worker" => "new-worker") ], "operation" => “add” } or (JSON) { "address" : [ { "subsystem" : "io" }, { "worker" : "new-worker" } ], "operation" : "add" } is is a lot more usable to just be able to say /subsystem=io/worker=new-worker:add() > > In any case if we go with WildFly embedded in CLI mode all this discussion is non issue. > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev

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(a)redhat.com&gt; 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(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev _______________________________________________ wildfly-dev mailing list wildfly-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev

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(a)redhat.com&gt; 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(a)redhat.com&gt; 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(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev

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(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev