schema for standalone server

[aloubyansky]

I've been thinking about "Standalone  server" schema https://jira.jboss.org/browse/JBAS-8178. I thought I'd think here, because I realize I need a better picture and get different opinions.

In fact I have an impression that at some point standalone was not even considered. Anyway, if we are going to support it then what I would try to do wrt the server configuration is to make it as close as possible to the domain one making the most use of the same terms, types and elements. Avoding for the user having to learn another configuration options and structures, etc. It has to be in the same "language".

It could be just one file. I.e. it could be a mix of domain and host, starting with e.g. root element 'standalone' which could contain elements from 'domain' such as profiles, deployments, interfaces, socket-binding-groups, etc (removing domain-configuration and server-groups) and elements from 'host' such as interfaces, jvms and server (instead of servers).

This approach feels messy and confusing. If a user has to deal with both domain and standalone config and switch between the two, it seems to me it might be easy to get confused what option is available where or where it should go.

Another approach would be still keep two files. One would be an equivalent of the domain.xml - standalone.xml, for example, and the other one - an equivalent of the (domain) host.xml - (standalone-)host.xml, for example.

It may seem like too much config for a standalone. On the other hand, if all the user wants is a standalone and wants easily make similar compies of standalone then it might be convenient in a way that all you need to change is mostly values in (standalone-)host.xml.

It would be great if we could make the same host.xml usable in two modes (domain and standalone).

Both these approaches may still be too complex. As I said I'd like to get a better picture, perhaps, coming up with a different configuration for standalone (avoiding too much generalization and re-use of terms) would make it much simpler.

[brian.stansberry]

The suggestion to make cloning standalone servers easy via a separate standalone.xml and host.xml is intriguing and worth exploring. I think the key is whether the host.xml contents can be the same between the standalone use case and the domain controller use case. A host.xml in the domain controller case is meant to support multiple servers, plus includes information telling the ServerManager how to contact the domain controller.

[brian.stansberry]

Apologies in advance for kinda hijacking this thread here. David and I were discussing getting rid of some of the "container" elements in domain.xml, e.g. deployments, interfaces, socket-binding-groups, server-groups. Currently they aren't consistently used (e.g. there are no <profiles> or <extensions>) and prevent users organizing things as they see fit. WDYT?

I bring this up here because it may or may not relate to differences between a domain.xml vs. a standalone.xml. But mostly because I know you're following this thread.

[aloubyansky]

Brian Stansberry wrote:

Apologies in advance for kinda hijacking this thread here. David and I were discussing getting rid of some of the "container" elements in domain.xml, e.g. deployments, interfaces, socket-binding-groups, server-groups. Currently they aren't consistently used (e.g. there are no <profiles> or <extensions>) and prevent users organizing things as they see fit. WDYT?

Preventing users organizing things as they see fit could be a bad as well as a good thing. I.e. they won't have a chance to mess things up and will keep them organized the way we see them fit

To me, wrapping elements are there exactly for that purpose:

- structuring fragments of XML (with the goal to make it clearer, more readable/visual);

- to force keeping same elements together in one place.

If neither of the above is a problem then we don't need them. But remember if the file is huge and anything can appear anywhere then you know...

Brian Stansberry wrote:

I bring this up here because it may or may not relate to differences between a domain.xml vs. a standalone.xml. But mostly because I know you're following this thread.

Normally I follow all of them here.

[dmlloyd]

Brian Stansberry wrote:

The suggestion to make cloning standalone servers easy via a separate standalone.xml and host.xml is intriguing and worth exploring. I think the key is whether the host.xml contents can be the same between the standalone use case and the domain controller use case. A host.xml in the domain controller case is meant to support multiple servers, plus includes information telling the ServerManager how to contact the domain controller.

This is possible.  It raises a question of semantics though: the standalone.xml approach declares exactly the parameters for a single server.

If we used host.xml in the standalone case, as Brian pointed out there would be redundant server declarations (you'd have to indicate which one is the single server configuration to use); also there'd be a domain controller reference which would also be useless.

In the domain mode, the host.xml file is the "bootstrap" configuration used to kick off the server manager process.  In standalone mode, having standalone.xml perform this function but still having host.xml present seems odd.

Also, at run time, to me it makes the most conceptual sense for the server instance to always be based on a single server object model even in domain mode: in domain mode, the host.xml and domain.xml would be combined to create this object model.  It seems logical to have this model map directly to the XML configuration for a standalone server rather than introducing the abstraction layer needed to support merging a standalone.xml with a host.xml (which contains redundant information).

[brian.stansberry]

Sorry, the comment about following this thread was stupid on my part.

[aloubyansky]

No, no problem really

[aloubyansky]

Another idea I had was to extract server-specific config (from host) to a separate file, i.e. to have a server-host config file per server instance. Then in case of the domain mode there would be domain.xml, possibly host.xml (?) and a number of server-specific files. And in case of the standalone mode there would be domain.xml (?), host.xml(?) and the server-specific config.

It's not looking simple at all, what I am trying to do is find a way to express domain and standalone config in a homogeneous way.

Perhaps, server-specific config could be made to include all the info and config currently belonging to host.xml. But also with a possibility to extract things like interfaces, jvms, extensions, etc to host.xml and later reference them by name/id from the server-specific config. This way the server-specific config might be self-sufficient and may work for standalone.

Although this approach would increase the number of config files and complexity of parsing/merging the configuration.

[aloubyansky]

It still looks like a better idea to me to just re-use domain.xml and host.xml for standalone.

There is domain-controller and servers under host but there could a choice instead like

{code:xml}<xs:choice>
   <xs:all>
      <xs:element name="domain-controller" type="locationType"/>
      <xs:element name="servers" type="serversType"/>
   </xs:all>
   <xs:element name="standalone" type="serverType"/>
</xs:choice>{code}

[dmlloyd]

Alexey Loubyansky wrote:

Another idea I had was to extract server-specific config (from host) to a separate file, i.e. to have a server-host config file per server instance. Then in case of the domain mode there would be domain.xml, possibly host.xml (?) and a number of server-specific files. And in case of the standalone mode there would be domain.xml (?), host.xml(?) and the server-specific config.

It's not looking simple at all, what I am trying to do is find a way to express domain and standalone config in a homogeneous way.

Perhaps, server-specific config could be made to include all the info and config currently belonging to host.xml. But also with a possibility to extract things like interfaces, jvms, extensions, etc to host.xml and later reference them by name/id from the server-specific config. This way the server-specific config might be self-sufficient and may work for standalone.

Although this approach would increase the number of config files and complexity of parsing/merging the configuration.

So what's the upside?

Having a separate standalone config doesn't seem like that big of a problem to me.  For the user it would just look something like:

<standalone>
    <extensions>
        ...
    </extensions>
    <interfaces>
        ...
    </interfaces>
    <socket-bindings>
        ...
    </socket-bindings>
    <system-properties>
        ...
    </system-properties>
    <profile>
        <web:container .../>
        ...
    </profile>
    <deployments>
        ...
    </deployments>
</standalone>

As you can see, only a small portion of the host element, and about half of the possible elements in domain, are really needed.  So if reusing host.xml and domain.xml adds so much complexity, and there's so much structural redundancy... why do it?  Just adding one standalone root element is so much easier.  I bet every single type of the elements defined therein are defined somewhere in the schema already, so it's just adding one root element with maybe six children and done.

Also from an implementation perspective this is the simplest: this object model would map exactly to the object model needed to start the single server instance.  Why not just do it this way?  It's so much easier...

[brian.stansberry]

Looking at the thread, I see two drivers for some kind of two-file solution for standalone-server config.

1) Helping users avoid confusion if they need to deal with configuring both full-on domains and standalone servers. IMHO though, a two-file solution for a standalone server is more confusing. Doing this for host.xml reduces the confusion for that file:

<xs:choice>
   <xs:all>
      <xs:element name="domain-controller" type="locationType"/>
      <xs:element name="servers" type="serversType"/>
   </xs:all>
   <xs:element name="standalone" type="serverType"/>
</xs:choice>

But the same kind of thing would need to be done to domain.xml. For example, in a standalone-server case, only a single "profile" or "socket-binding-group" element is appropriate. You could allow multiple, with the host.xsd schema for the "standalone" element requiring a mapping of which one applies, but that to me is confusing; it doesn't hide the whole domain notion, it forces the user to deal with it. Something like what David outlined above seems conceptually simpler.

2) Making it easy to re-use the same config for multiple standalone servers. This is where a separate document for the server-specific information is useful. How can we make this easy for people?

The 3 main things I see people wanting to change on a per-server basis are:

a) Server name

b) Assignment of IP addresses to interfaces

c) Port offsets to socket bindings.

There are others, but I think if we can make the above 3 easy I think we've covered the common use cases. Some vague-ish Sunday afternoon thoughts:

One thought is a simple conversion utility that people can execute from the command line to convert a -standalone.xml. Accepts command line switches for the server name, bind address, port offset, alters the standalone.xml

Taking this further is to have the main class that launches a standalone server accept command line switches for those things, and use the values passed in from the command line to update the -standalone.xml.

Taking that further, we could formalize what server-level configurations we'll allow to be set via a system property, and express that directly in the xsd. Something along the lines of what Jaikiran suggests in https://community.jboss.org/thread/153231?tstart=0

[dmlloyd]

Brian Stansberry wrote:

Looking at the thread, I see two drivers for some kind of two-file solution for standalone-server config.

1) Helping users avoid confusion if they need to deal with configuring both full-on domains and standalone servers. IMHO though, a two-file solution for a standalone server is more confusing. Doing this for host.xml reduces the confusion for that file:

<xs:choice>
   <xs:all>
      <xs:element name="domain-controller" type="locationType"/>
      <xs:element name="servers" type="serversType"/>
   </xs:all>
   <xs:element name="standalone" type="serverType"/>
</xs:choice>

But the same kind of thing would need to be done to domain.xml. For example, in a standalone-server case, only a single "profile" or "socket-binding-group" element is appropriate. You could allow multiple, with the host.xsd schema for the "standalone" element requiring a mapping of which one applies, but that to me is confusing; it doesn't hide the whole domain notion, it forces the user to deal with it. Something like what David outlined above seems conceptually simpler.

Well, leaving out some issues (i.e. you can't have an "all" inside a "choice", or at least I don't think you can), this isn't a bad idea: put the whole standalone element inside <host>, but take it a step farther so that it looks like the example I gave above.

This way we have one startup path, at least in concept: the first step is always to read host.xml and do whatever it says.  If it says to contact the domain controller, do it; otherwise do a standalone startup.

The practical difficulty comes from the process manager.  In a standalone setting we wouldn't want to bother with that.  So I guess it wouldn't actually solve the problem of two startup scripts.

Brian Stansberry wrote:

2) Making it easy to re-use the same config for multiple standalone servers. This is where a separate document for the server-specific information is useful. How can we make this easy for people?

The 3 main things I see people wanting to change on a per-server basis are:

a) Server name

b) Assignment of IP addresses to interfaces

c) Port offsets to socket bindings.

There are others, but I think if we can make the above 3 easy I think we've covered the common use cases. Some vague-ish Sunday afternoon thoughts:

One thought is a simple conversion utility that people can execute from the command line to convert a -standalone.xml. Accepts command line switches for the server name, bind address, port offset, alters the standalone.xml

Taking this further is to have the main class that launches a standalone server accept command line switches for those things, and use the values passed in from the command line to update the -standalone.xml.

Taking that further, we could formalize what server-level configurations we'll allow to be set via a system property, and express that directly in the xsd. Something along the lines of what Jaikiran suggests in https://community.jboss.org/thread/153231?tstart=0

Yeah I think people will have an expectation that they will still be able to control this stuff with system property replacement like today.  I think that Jaikiran's approach has both pros and cons though.  It gets us away from what is essentially a miniature expression language.  Thus we lose some power but we gain some simplicity.  Whether or not it meets the users' needs, it's hard to say.

[aloubyansky]

David Lloyd wrote:

Brian Stansberry wrote:

Looking at the thread, I see two drivers for some kind of two-file solution for standalone-server config.

1) Helping users avoid confusion if they need to deal with configuring both full-on domains and standalone servers. IMHO though, a two-file solution for a standalone server is more confusing. Doing this for host.xml reduces the confusion for that file:

<xs:choice>
   <xs:all>
      <xs:element name="domain-controller" type="locationType"/>
      <xs:element name="servers" type="serversType"/>
   </xs:all>
   <xs:element name="standalone" type="serverType"/>
</xs:choice>

But the same kind of thing would need to be done to domain.xml. For example, in a standalone-server case, only a single "profile" or "socket-binding-group" element is appropriate. You could allow multiple, with the host.xsd schema for the "standalone" element requiring a mapping of which one applies, but that to me is confusing; it doesn't hide the whole domain notion, it forces the user to deal with it. Something like what David outlined above seems conceptually simpler.

Well, leaving out some issues (i.e. you can't have an "all" inside a "choice", or at least I don't think you can), this isn't a bad idea: put the whole standalone element inside <host>, but take it a step farther so that it looks like the example I gave above.

No, IMO, making a separate schema for standalone would be better than pulling domain constructs into standalone in host.xml. So, I think I'm gonna do a separate schema after all.

[aloubyansky]

Alexey Loubyansky wrote:

No, IMO, making a separate schema for standalone would be better than pulling domain constructs into standalone in host.xml. So, I think I'm gonna do a separate schema after all.

Following that, it appears it's now better to merge domain and host schemas into one xsd with three top-level elements: domain, host and standalone. Otherwise, if we want to avoid duplicate type definitions in different xsds we'll have to split domain and host schemas into pieces (besides having the common xsd) and then assemble domain, host and standalone xsds using xsd:include which will be a mess.

[brian.stansberry]

Sounds good.

Some stuff got merged into upstream master since you posted the above messages.

Also, right now we've got topic branch going for working on booting a Server from a ServerManager. My copy is at http://github.com/bstansberry/jboss-as/tree/server-mgr-dev

John Bailey, Kabir Khan and I are working on that topic. John's focusing on taking Standalone (the class we're currently using for both representing the <standalone/> element and for a merged <domain/> + <server-group> + <host><server/> for a particular server) and starting services from that. I'm doing a lot of inter-process stuff to bootstrap ProcessManager, ServerManager, Server. Kabir has just started in and is going to look at making ProcessManager more robust.

We also want to start a Server as a standalone ASAP, so your work ties in there. You're welcome to join in on the server-mgr-dev branch and we can all push/pull from each other, or if you prefer you can work on a different topic branch. Either way we'll have to coordinate.