6 Replies Latest reply on Jun 17, 2010 10:48 PM by starksm64

    default values in domain management

    aloubyansky

      I thought it's worth a separate thread.

       

      There are of course very different kinds of properties. I.e. the ones that are set in deployment descriptors and those that can't be, e.g. jvm args, environment variables, etc.

       

      Here is what I think about those that are set in deployment descriptors. I maybe off the path, so please correct my view on this.

      At least in the beginning, domain.xml could be optional from the server instance start-up point of view. I.e. it would be possible to start a stand-alone server instance without domain.xml. Then all the services/containers would be initialized from their deployment descriptors (and possibly other config files) as it's happening now. But if domain.xml is present then the values it contains will override the corresponding values from the deployment descriptors.

       

      As Brian said in the other thread this approach implies that to have correct values of a manged component in an admin tool the managed service must be initialized at a minimum.

       

      In addition, the values for managed properties are duplicated, i.e. in the deployment descriptors and domain.xml, which is confusing. Admin tool will apply changes to domain.xml but not the deployment descriptor. domain.xml is synchronized between the server instances in the domain but deployment descriptors probably won't. Which means if the value is removed from the domain.xml the default value for the property on every server instance coming from the deployment descriptors maybe different.

        • 1. Re: default values in domain management
          dmlloyd

          Alexey Loubyansky wrote:

           

          I thought it's worth a separate thread.

           

          There are of course very different kinds of properties. I.e. the ones that are set in deployment descriptors and those that can't be, e.g. jvm args, environment variables, etc.

          You can break it down like this:

          1. Properties that are part of a deployment
          2. Properties that are global to the domain
          3. Properties that are specific to a server group
          4. Properties that are specific to a host

           

          Items 1-3 are definitely part of the domain model either explicitly or implicitly.  If I deploy an application into a server group or server groups, then that deployment becomes part of the domain.

           

          Alexey Loubyansky wrote:

           

          At least in the beginning, domain.xml could be optional from the server instance start-up point of view. I.e. it would be possible to start a stand-alone server instance without domain.xml. Then all the services/containers would be initialized from their deployment descriptors (and possibly other config files) as it's happening now. But if domain.xml is present then the values it contains will override the corresponding values from the deployment descriptors.

          My feeling on this is that deployments have to be part of the domain model if we are to retain a consistent view of configuration and deployment (i.e. to allow "undo" operations and allow servers to go offline and download changes in order when they come back online).  Since deployments are part of the domain model, you can't deploy without the domain controller.  If you get deployments, you get a domain.xml, so it's not possible to start up a server with deployments but without domain.xml.

           

          I don't think this is incompatible with the desire that people have to (a) keep a deploy/ drop-in directory like we have to day (for development purposes) or (b) have an embeddible mode.  These could simply be a specialized, minimal implementation of the domain controller/server manager interaction.

           

          Alexey Loubyansky wrote:

           

          As Brian said in the other thread this approach implies that to have correct values of a manged component in an admin tool the managed service must be initialized at a minimum.

           

          In addition, the values for managed properties are duplicated, i.e. in the deployment descriptors and domain.xml, which is confusing. Admin tool will apply changes to domain.xml but not the deployment descriptor. domain.xml is synchronized between the server instances in the domain but deployment descriptors probably won't. Which means if the value is removed from the domain.xml the default value for the property on every server instance coming from the deployment descriptors maybe different.

          I don't see any reason, given what I've said above, to require duplication of what's in the deployment descriptors into the domain.xml file.  It would only happen in the case where something specific needs to be overridden.

           

          Maybe Brian's idea of having the defaults in the schema isn't such a bad one after all: as long as we have separate namespaces for each successive version of each component, the version can be used to imply the defaults in play.  We have to make sure that the implementation of the parsing layer makes it easy to support multiple namespaces (and know which is in play) in this case though.

          • 2. Re: default values in domain management
            aloubyansky

            Ok, so far we agree that defaults come from the deployment descriptors. At least it would be the next (perhaps not the last) source for initialization values if they are missing from the domain.xml.

             

            By property/value duplication I didn't mean it as a requirement for all the properties. But it will be the case for those that are overriden in domain.xml. It's not so much a value duplication but the property config duplication which won't be in sync (between the domain.xml and the deployment descriptors) which is a bit confusing.

             

            Ok, so I think I understand it better now. Again, correct me if I am wrong:

            - to start a domain (member of a domain), I'll use a separate tool/script (not the usual run.sh/ran.bat) that will start things according to the domain.xml (that will happen in collaboration with the domain controller or actually the tool/script will just delegate the tasks to the domain controller);

            - further dynamic (hot) deployment operations will also be performed using a tool/script and through the domain controller;

            - config changes of any kind (including managed components) will be performed also using a tool/script and through the domain controller.

             

            So, actually, in the domain-running mode all the operations including start-up/shutdown and any config changes will be performed using a tool/script, not manually, i.e. not by manually changing deployment descriptors at runtime, manually copying/removing deployments from the deploy dir, etc.

             

            At the same time, there will still be the usual run.sh/run.bat that will start server instances as usually (passing by the domain.xml), they won't join the domain, i.e. will be running stand-alone and deployment operations and config changes will be performed traditionally manually.

            • 3. Re: default values in domain management
              dmlloyd

              Alexey Loubyansky wrote:

               

              Ok, so far we agree that defaults come from the deployment descriptors. At least it would be the next (perhaps not the last) source for initialization values if they are missing from the domain.xml.

              Yeah, I think it's hard to say anything more specific without use case examples.  Some things might not appear in a deployment descriptor at all though, like the JBossWeb server configuration for example, because they apply to the server as a whole, not a specific deployment.

               

              Alexey Loubyansky wrote:

               

              By property/value duplication I didn't mean it as a requirement for all the properties. But it will be the case for those that are overriden in domain.xml. It's not so much a value duplication but the property config duplication which won't be in sync (between the domain.xml and the deployment descriptors) which is a bit confusing.

              What do you mean by "in sync" in this case?  One would only override a configuration property if there was a deployment to override.  I imagine that any overriding properties in the domain.xml file that pertain to a specific deployment will be children of an element which defines that deployment, so if there's no such element, there's no such deployment, and such an element can't exist without the deployment being present.

              Alexey Loubyansky wrote:

               

              Ok, so I think I understand it better now. Again, correct me if I am wrong:

              - to start a domain (member of a domain), I'll use a separate tool/script (not the usual run.sh/ran.bat) that will start things according to the domain.xml (that will happen in collaboration with the domain controller or actually the tool/script will just delegate the tasks to the domain controller);

              - further dynamic (hot) deployment operations will also be performed using a tool/script and through the domain controller;

              - config changes of any kind (including managed components) will be performed also using a tool/script and through the domain controller.

               

              So, actually, in the domain-running mode all the operations including start-up/shutdown and any config changes will be performed using a tool/script, not manually, i.e. not by manually changing deployment descriptors at runtime, manually copying/removing deployments from the deploy dir, etc.

               

              At the same time, there will still be the usual run.sh/run.bat that will start server instances as usually (passing by the domain.xml), they won't join the domain, i.e. will be running stand-alone and deployment operations and config changes will be performed traditionally manually.

              Yes and no.  We can still have a deploy directory.  But if we do, the scanner for that directory would take deployments and feed them through the DC, so the domain model info would be automatically updated at the same time.

               

              We can still have run.sh; it just starts the server manager which starts all the server instances according to domain.xml.

               

              I don't forsee any mode of operation that does not involve domain.xml.  Even an embedded server should have something performing the role of DC and SM even if it's all in the same process space.  This way there's only one API for deployment and configuration.

              • 4. Re: default values in domain management
                brian.stansberry

                David Lloyd wrote:


                Alexey Loubyansky wrote:


                At the same time, there will still be the usual run.sh/run.bat that will start server instances as usually (passing by the domain.xml), they won't join the domain, i.e. will be running stand-alone and deployment operations and config changes will be performed traditionally manually.

                Yes and no.  We can still have a deploy directory.  But if we do, the scanner for that directory would take deployments and feed them through the DC, so the domain model info would be automatically updated at the same time.

                 

                We can still have run.sh; it just starts the server manager which starts all the server instances according to domain.xml.

                 

                I don't forsee any mode of operation that does not involve domain.xml.  Even an embedded server should have something performing the role of DC and SM even if it's all in the same process space.  This way there's only one API for deployment and configuration.

                 

                Agreed. Going through the lifecycle use cases what seems to be falling out is a two step process where step 1) is registering with a domain and getting the local environment consistent with the domain, then step 2) starting a Server based on the domain.xml. A "stand-alone server" use case or an embedded one would mostly differ from the more complete one in skipping step 1). (Embedded would presumably also at least partly use an API to establish the domain model rather than getting everything from a domain.xml.)

                 

                Interesting question on how to do deployment operations and make config changes on a "stand-alone" server. If the stand-alone server is running the DomainControllerSubprofile, then it exposes the full management capability of a larger domain and can be managed the same way. If it doesn't run the DomainControllerSubprofile, then we need to establish what post-startup management capability it will expose.

                 

                First, my opinion on a requirement: the "standalone server" and embedded use cases are meant for developers, not for production systems.  Setting up a production system consisting of a bunch of stand-alone servers, each running the DomainControllerSubprofile could work but is not the recommended architecture. Setting up a production system consisting of a bunch of stand-alone servers that don't run the DomainControllerSubprofile is not a supported architecture.

                 

                Put another way, the full stable supported management API we are developing is exposed by a DomainController, so if you want the full capabilities you need the DomainControllerSubprofile. But what does API does the non-DC stand-alone server expose?

                 

                I think the answer to this will largely fall out of working through the embedded use cases, plus working out the interaction between a separate-process DC and a Server. For sure a stand-alone server needs an deployment API, otherwise it's useless in an IDE.

                 

                One thing I think there is consensus on: hot deployment is limited to a deploy/ dir that only contains end user deployments, no core services. So reconfiguring a core service by changing some -beans.xml file and having HDScanner pick it up is not a supported configuration mechanism.

                • 5. Re: default values in domain management
                  aloubyansky

                  David Lloyd wrote:

                  Alexey Loubyansky wrote:

                   

                  By property/value duplication I didn't mean it as a requirement for all the properties. But it will be the case for those that are overriden in domain.xml. It's not so much a value duplication but the property config duplication which won't be in sync (between the domain.xml and the deployment descriptors) which is a bit confusing.

                  What do you mean by "in sync" in this case?  One would only override a configuration property if there was a deployment to override.  I imagine that any overriding properties in the domain.xml file that pertain to a specific deployment will be children of an element which defines that deployment, so if there's no such element, there's no such deployment, and such an element can't exist without the deployment being present.

                  I simply mean that there will be two values for the property: one in the deployment descriptor (i.e. the default one) and one in the domain.xml (the actual one).

                  • 6. Re: default values in domain management
                    starksm64

                    Right, but this is true now for the 5.1 profileservice, and it is what we want as the deployment descriptors, even if they support their own DSL are still more closely tied to implementation details than they are the admin view we want to expose. The domain model is the relevant set of admin oriented information for each subsystem. As soon as a subystem has a representation in the domain model, the deployment descriptors and associated metadata/deployers are subservient to the domain model. This is also how we want it. The implementation of the subsystem can change, there can even be alternate implementations active, but there is one versioned domain model view of the admin configuration that is a public API.

                     

                    Note we have largely been focsued on configuration metadata in the model. We also need to define the read-only statistics that are expected from subystems as well as any operations in order for the JON and other tools to provide consistency with what they offer today using the domain model and API.