1 2 3 4 5 Previous Next 69 Replies Latest reply on May 28, 2010 7:11 PM by dmlloyd Go to original post
      • 30. Re: domain.xml work
        emuckenhuber

        Brian Stansberry wrote:


        This is something we need to discuss with the console folks. Having a separate view for updating the domain is simpler but not particularly intuitive from a UI point of view. Perhaps more intuitive for a CLI though.

         

        We need to think about a separate DomainView in general - whereas the configuration is shared across a domain and therefore the same on all nodes, this is not true for metrics and runtime statistics. It most probably would make sense to return a collection of metrics of each node, where the management clients can decide how to present this information and do the interpretation.

        • 31. Re: domain.xml work
          emuckenhuber

          Scott Stark wrote:

           

          The ManagedComponent view is an admin client view of the deployment metadata, including any override values applied previously. This view would show the value of properties that are specified at an admin domain view, but if I change such a property I have overriden it at a component level. It is a post admin edit view. If we are to allow editing of a local server domain.xml, changes to a ManagedComponent view would have to propagate to the domain.xml. Changes to properties that are dervied from some higher level admin domain would not be propagated because you would not be specifying the domain level value. The admin domain would have a separate component for that.

          This is actually a tricky part. One the one hand we cannot expose the domain.xml only, since there would be components missing - which don't have overrides. On the other hand we cannot expose the ManagedComponents based on the deployment metadata either, since it would contain processed variables e.g. system properties - where ${jboss.server.home} might differ from one node to another.

          • 32. Re: domain.xml work
            emuckenhuber

            Brian Stansberry wrote:

             

            Requirement #2 is somewhat in conflict with some of what I've read on this thread, wherein the domain.xml configuration data is applied as an override. That means the primary and authoritative representation of the domain is the combination of wherever the overridden configuation values come from + the domain.xml configuration.

             

            That's always going to partially be the case, because all the IOC wiring stuff is really configuration.  But how far are we looking to push this concept? I'm going to give a specific example below, but I'm less interested in the specifics than the general issue of how much is meant to be coming from domain.xml.

             

            What you mentioned about "the IOC wiring stuff is really configuration" - seem to be the one of the problems with configuration in general. Our current management view is actually a override of the original deployment metadata representing the actual beans. This requires classloading and the bean deployed, where actual management overrides update the IOC wiring (BeanMetaData).

             

            So we were talking about using a offline MO (xml) model, defining this override and how a component is exposed though the management view. In case this still applies - the question is if this concept of configuration should be externalized in general - using the same way to register against the namespace/xpath of the domain.xml Scott mentioned.

             

            Basically this seems to be more critical in terms of persistable configuration with default values, than runtime MOs just dispatching requests or exposing metrics - which should most probably just be merged into a configuration MO.

            • 33. Re: domain.xml work
              emuckenhuber

              WRT (1) - another interesting question would be the deployment behavior of a domain. So if it actually makes sense to have something like local deployments. In the end we want to enable users to manage a domain of 100 nodes, why would you care about a local deployment on a single instance? I mean what are the expectations of manageability of such a deployment? e.g. is deploy/ going to be "farmed" when connected to a management domain by default or not?

              • 34. Re: domain.xml work
                brian.stansberry

                In a true multi-server domain (i.e. not just a collection of servers each with the proposed first-stage standalone server domain) a new node joining should get its configuration from a "central point"; whatever it has locally on disk when it first starts should be replaced. In Westford we discussed that any of the running servers in the domain whose profile has the required capability could act as that "central point", with an HASingleton-like mechanism used to determine which node is currently taking on that role.

                 

                The node joining the domain would need to know enough to contact the domain to get its config; such info would presumably be provided via the command line (or perhaps a simple properties file). I envision that working somewhat like HA-JNDI does now; the client is (optionally) provided a set of well-known URLs to contact, (optionally) falling back to multicast discovery.

                • 35. Re: domain.xml work
                  brian.stansberry

                  I added an 8th requirement:

                   

                  It must be clear in all client interfaces which actions:

                  1. affect the domain model
                  2. affect components associated with the domain model but not the domain model itself (e.g. an obscure property exposed via a component's managment interface that isn't part of the domain model).
                  3. affect non-classified components

                   

                  Thinking about it, the example in 2. above is probably overly narrow. Besides the case of obscure properties not included in the domain model, there is also the case of actions that are meant to temporarily override the domain value (e.g. to tweak a logging level).

                   

                  Further to that, if we are going to allow temporarily overriding the domain value, that should be one of the requirements.

                  • 36. Re: domain.xml work
                    starksm64

                    It seems to me we are not all on the same page with regard to how the profileservice functions in terms of management edits. I'm sorry if this seems to be going backwards, but I want to be clear on how we are all viewing the domain.xml. There are 3 elements:

                     

                    1. The metadata that drives the deployers to create runtime components.

                    2. The profileservice admin view of the metadata as described by the ManagedComponents. This is a possibly indirect mapping that allows the deployer/container specific metadata that carries implementation details from a stable admin view that is compatible across releases. Realize that right now we are far from complete in this being a one to one mapping. Only a fraction of the projects have an admin view that is anywhere near complete. The embedded console uses this admin view implicitly by defining its own mapping of ManagedComponent properties onto its UI elements. The push to define a domain.xml is a centralization of the admin view of the metadata. The intention is that this really is the only supported admin interface. Perhaps I have obscured the issue by mentioning that there could be ManagedComponents not in the domain.xml or even properties not in the domain.xml. What is important is that we are defining a complete admin view of the metadata that is decoupled from the deployer metadata. This is our historic problem which manifested as implementation xml files spread out all over in the server deployments.

                    3. The profileservice implementation which is manages applying admin edits to the admin (domain) metadata view onto the deployer implementation metadata.

                     

                    Related to Brian's question he started on another summary thread, the first step is to define a sufficient domain.xml metadata model that we accept as our supported admin interface, and evolve that compatibily for each subsequent release. Realize we already have a limited admin domain model that JON supports that is defined by the rhq-plugin.xml mapping between ManagedComponents and the console's supported admin components. We have to step outside of our project metadata models and deal with both the admin metadata view and implementation view. I don't see a limited domain.xml in AS6.0 as a problem because that is in fact the reality. My notion for a minimal domain.xml is one that encapsulates the current embedded JON rhq-plugin.xml model.

                    • 37. Re: domain.xml work
                      starksm64

                      I'm thinking that the profileservice ManagedComponent api is no longer relevant for our discussion. The fact that we introduced an indirection layer to allow for a stable metadata is only one part of what is needed. We need a well defined domain model that describes what the supported administration capabilities are for a given release. Now I'm thinking that the domain.xml is all that matters. Until a feature of the server has a representation in the domain.xml model, its not properly managable.

                      • 38. Re: domain.xml work
                        starksm64

                        Each part of the component namespace would include a wildcard properties bag to allow for configuration outside of the domain model to at least exist in the domain model. To have some safety there could be a notion of whether or not a property needed to be understood by the ManagedComponent that maps from the domain model onto deployment metadata.

                        • 39. Re: domain.xml work
                          starksm64

                          Right.

                          • 40. Re: domain.xml work
                            starksm64

                            Having IOC type of configuration in the domain.xml really defeats the purpose of IOC as I see it. The endpoint of most injection references should be resolvable via the type/component naming conventions of the spec. The only domain.xml elements that should exist are those that correspond to the non-spec defined container information that would be found in jboss.xml server specific settings. Only for cases where the resolution is ambiguous or one is attempting non-standard behaviors like resolving an endpoint to an bean in another deployment would one need to administer IOC information.

                            • 41. Re: domain.xml work
                              jason.greene

                              Scott Stark wrote:

                               

                              I'm thinking that the profileservice ManagedComponent api is no longer relevant for our discussion. The fact that we introduced an indirection layer to allow for a stable metadata is only one part of what is needed. We need a well defined domain model that describes what the supported administration capabilities are for a given release. Now I'm thinking that the domain.xml is all that matters. Until a feature of the server has a representation in the domain.xml model, its not properly managable.

                               

                              I totally agree. We should focus on the requirements, use-cases and the model/configuration itself. I also agree that something has to be in domain.xml for it to be truly managable. I kind of saw runtime management of components not in domain.xml as more of a stop-gap. However, it probably is easier to just focus on the domain model, and look at the non-classified runtime stuff later, if it is even relevant anymore.

                              • 42. Re: domain.xml work
                                emuckenhuber

                                Seems you misunderstood me. I was not talking about having IOC in the domain.xml at all. I said using IOC for configuration is a problem, since ProfileService does not understand injection. Just look at how persistence overrides are applied to the e.g. the service-binding-manager - where we actually override properties with <inject /> with the beans constructed within profileservice - based on the peristence information. Again this has nothing to do with the actual domain.xml, it is more about the mapping and override layer.

                                • 43. Re: domain.xml work
                                  jason.greene

                                  Emanuel Muckenhuber wrote:

                                   

                                  Seems you misunderstood me. I was not talking about having IOC in the domain.xml at all. I said using IOC for configuration is a problem, since ProfileService does not understand injection. Just look at how persistence overrides are applied to the e.g. the service-binding-manager - where we actually override properties with <inject /> with the beans constructed within profileservice - based on the peristence information. Again this has nothing to do with the actual domain.xml, it is more about the mapping and override layer.

                                   

                                  The service binding manager should be obviated by the domain model, so there should be no need for injection overrides. Put another way, anything managed by domain.xml should not be allowed in some arbitrary beans.xml descriptor.

                                  • 44. Re: domain.xml work
                                    brian.stansberry

                                    Jason Greene wrote:

                                     

                                    Scott Stark wrote:

                                     

                                    I'm thinking that the profileservice ManagedComponent api is no longer relevant for our discussion. The fact that we introduced an indirection layer to allow for a stable metadata is only one part of what is needed. We need a well defined domain model that describes what the supported administration capabilities are for a given release. Now I'm thinking that the domain.xml is all that matters. Until a feature of the server has a representation in the domain.xml model, its not properly managable.

                                     

                                    I totally agree. We should focus on the requirements, use-cases and the model/configuration itself. I also agree that something has to be in domain.xml for it to be truly managable. I kind of saw runtime management of components not in domain.xml as more of a stop-gap. However, it probably is easier to just focus on the domain model, and look at the non-classified runtime stuff later, if it is even relevant anymore.

                                     

                                    Great. I'm a lot more comfortable with this approach. Multiple different management approaches coexisting in the same management API, some of which map back to domain.xml and some not -- yuck.