April 2010 - jboss-dev-forums - Jboss List Archives

Re: [jboss-dev-forums] [Management Development] - To scope or not to scope (domain.xml)

by Emanuel Muckenhuber

Emanuel Muckenhuber [http://community.jboss.org/people/emuckenhuber] replied to the discussion "To scope or not to scope (domain.xml)" To view the discussion, visit: http://community.jboss.org/message/536375#536375 -------------------------------------------------------------- > Brian Stansberry wrote: > > Since we're in the mode of defining things, what is a "multi-domain notion?" I see it as a an ability to manage within the same tool multiple sets of servers where each set has it's own management policy. The sets of servers are conceptually distinct (hence the separate management policy / domain) but, generally for operational ease of use reasons, users wish to manage multiple domains from the same tool. Just to clearify what i meant with "multi-domain" - is that in this case a node can be part of more management domains. The difference i see is that in a multi-domain notion you have multiple domains - where the "managable unit" would be the domain itself. In case of server-groups you have a single domain - however the "manageable unit" is more or less a server-group. In case a server should be the "managable unit" then we don't need a domain model - right? ;) -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/536375#536375] Start a new discussion in Management Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]

15 years, 12 months

1
0
0 / 0

Re: [jboss-dev-forums] [Management Development] - To scope or not to scope (domain.xml)

by Brian Stansberry

Brian Stansberry [http://community.jboss.org/people/bstansberry%40jboss.com] replied to the discussion "To scope or not to scope (domain.xml)" To view the discussion, visit: http://community.jboss.org/message/536369#536369 -------------------------------------------------------------- > Jason Greene wrote: > When you think about it, a server-group, and a cluster are really the same thing, the only difference is that the cluster has an additional set of services that a basic group does not. Yes, but isn't the set of capabilities that a server has defined by its profile? We could say that defining a server as part of a cluster means that additional capabilities are added beyond what's in the profile. But then we are dividing the definition of a profile into two places. Also, exactly what capabilities should be added if a server is in a cluster is unclear. A very simple concept of a cluster is that it is a server-group that also exposes some predefined configuration properties that need to be kept consistent throughout the group. (A server-group would not have such properties by default, although users could add custom ones.) Things such as: * Group name (current -g) * Type of intra-group communication to use by default (udp, tcp) * Default interface to use for intra-group communication * Default multicast address to use * other defaults less commonly changed A cluster might also have some management capabilities besides what is available to a server-group, although I'm not sure what. It should be possible for example to perform a (rolling) redeployment to a server-group. A separate discussion is how communication will occur between servers who are not members of a cluster. There needs to be a group communication mechanism that spans the entire domain. > This was what I meant by the cluster-service tag, a way to specify how a group would cluster a particular service (maybe not all services should be clustered). Although it was just something I through out there as an example. A better way likely exists Currently how we cluster a particular service is defined in that service's configuration, it's not something applied externally. And the details of what needs to be configured are often disparate between different services, so I'm not sure those configs can profitably be externalized into some common configuration element. Ah, or are you talking about "clustered-service" as a wrapper to describe how to manage the service, e.g. how to (re)deploy across cluster? -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/536369#536369] Start a new discussion in Management Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]

15 years, 12 months

1
0
0 / 0

Re: [jboss-dev-forums] [Management Development] - To scope or not to scope (domain.xml)

by Scott Stark

Scott Stark [http://community.jboss.org/people/scott.stark%40jboss.org] replied to the discussion "To scope or not to scope (domain.xml)" To view the discussion, visit: http://community.jboss.org/message/536368#536368 -------------------------------------------------------------- > Brian Stansberry wrote: > > Since we're in the mode of defining things, what is a "multi-domain notion?" I see it as a an ability to manage within the same tool multiple sets of servers where each set has it's own management policy. The sets of servers are conceptually distinct (hence the separate management policy / domain) but, generally for operational ease of use reasons, users wish to manage multiple domains from the same tool. > Right, which is why I don't see this as impacting what the domain.xml looks like. This notion exists above the servers and profileservice. We are told what domain we are operating in. > The "server-group" notion is the collection of unclustered servers. So in the simple case of a domain that's a collection of a homogenous set of unclustered servers, we'd just be requiring a bit more XML. > > I can see having a capability to deploy to a domain as a convenience, but it can get conceptually messy. > > We need to keep a clear separation between configuration and provisioning. > > Agreed, but not sure what you were getting at here. Were we mixing them? I see deploying to a domain as both a configuration of a profile at the domain level, and a runtime operation of pushing content out to all servers. I see it can be messy if the deployment impacts clustered services. If we have any hope of getting the domain.xml function in AS6, we need to separate getting a server to be driven by a domain.xml from how the provisioning would happen. -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/536368#536368] Start a new discussion in Management Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]

15 years, 12 months

1
0
0 / 0

Re: [jboss-dev-forums] [Management Development] - To scope or not to scope (domain.xml)

by Brian Stansberry

Brian Stansberry [http://community.jboss.org/people/bstansberry%40jboss.com] replied to the discussion "To scope or not to scope (domain.xml)" To view the discussion, visit: http://community.jboss.org/message/536361#536361 -------------------------------------------------------------- > Scott Stark wrote: > > I agree with those definitions. By the way, we need someone from the JON team to chime in on some of these discussions to ensure we are in sync with them. I've pinged Charles to let him know about these threads. > I don't see that a true multi-domain notion is in scope for this effort. Since we're in the mode of defining things, what is a "multi-domain notion?" I see it as a an ability to manage within the same tool multiple sets of servers where each set has it's own management policy. The sets of servers are conceptually distinct (hence the separate management policy / domain) but, generally for operational ease of use reasons, users wish to manage multiple domains from the same tool. > In the base usage you are deploying to the domain, otherwise I have to have a cluster even if I just have a collection of non-clustered servers. I would think we do have profiles at the domain, cluster server group and server levels. The "server-group" notion is the collection of unclustered servers. So in the simple case of a domain that's a collection of a homogenous set of unclustered servers, we'd just be requiring a bit more XML. I can see having a capability to deploy to a domain as a convenience, but it can get conceptually messy. > We need to keep a clear separation between configuration and provisioning. Agreed, but not sure what you were getting at here. Were we mixing them? -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/536361#536361] Start a new discussion in Management Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]

15 years, 12 months

1
0
0 / 0

Re: [jboss-dev-forums] [Management Development] - To scope or not to scope (domain.xml)

by Scott Stark

Scott Stark [http://community.jboss.org/people/scott.stark%40jboss.org] replied to the discussion "To scope or not to scope (domain.xml)" To view the discussion, visit: http://community.jboss.org/message/536360#536360 -------------------------------------------------------------- Right, that is why we really need some input from the JON team as we need to be in sync with the administrator perspective. It has been our tendency (I'm being kind to us ;) ) to not properly reflect their view of dealing with server and domain configuration. I'll ping Charles on the current two threads in play. -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/536360#536360] Start a new discussion in Management Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]

15 years, 12 months

1
0
0 / 0

Re: [jboss-dev-forums] [Management Development] - To scope or not to scope (domain.xml)

by Jason Greene

Jason Greene [http://community.jboss.org/people/jason.greene%40jboss.com] replied to the discussion "To scope or not to scope (domain.xml)" To view the discussion, visit: http://community.jboss.org/message/536358#536358 -------------------------------------------------------------- For another point of reference, I noticed that the Glassfish was attempting to move away from a reference based model, to more of a scoping one. This is described in a V3Specification doc available http://fisheye5.atlassian.com/browse/~raw,r=1.5/glassfish/www/v3/admin/pl... here. It appears however, that this was not completely adopted, no idea why. In this proposal they nest server definitions as part of a group or a cluster. I think this would actually make the file harder to read. Another unique aspect of this specification is that they made groups heterogenous and clusters homogenous. This seems strange to me since I view clustering as more of a service. -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/536358#536358] Start a new discussion in Management Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]

15 years, 12 months

1
0
0 / 0

Re: [jboss-dev-forums] [Management Development] - To scope or not to scope (domain.xml)

by Scott Stark

Scott Stark [http://community.jboss.org/people/scott.stark%40jboss.org] replied to the discussion "To scope or not to scope (domain.xml)" To view the discussion, visit: http://community.jboss.org/message/536351#536351 -------------------------------------------------------------- I agree with those definitions. By the way, we need someone from the JON team to chime in on some of these discussions to ensure we are in sync with them. I don't see that a true multi-domain notion is in scope for this effort. In the base usage you are deploying to the domain, otherwise I have to have a cluster even if I just have a collection of non-clustered servers. I would think we do have profiles at the domain, cluster server group and server levels. We need to keep a clear separation between configuration and provisioning. -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/536351#536351] Start a new discussion in Management Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]

15 years, 12 months

1
0
0 / 0

Re: [jboss-dev-forums] [Management Development] - To scope or not to scope (domain.xml)

by Jason Greene

Jason Greene [http://community.jboss.org/people/jason.greene%40jboss.com] replied to the discussion "To scope or not to scope (domain.xml)" To view the discussion, visit: http://community.jboss.org/message/536347#536347 -------------------------------------------------------------- > Brian Stansberry wrote: > > Excellent question! We need to agree on the definition of some terms. > > To me a "domain" is a set of servers meant to be managed as a unit (acknowledgment: how things are "managed as a unit" is vague/fuzzy; a key task is to clarify exactly what that means.) The servers don't need to all have a homogenous profile, as people may wish to tier things. (In example above written for the clustering meeting the "DataGrid" profile was meant to describe a bunch of servers running Infinispan to serve as large scale grid storage behind a JEE tier.) > > I see a domain as needing to allow multiple clusters, even ignoring the different tier idea. Mutliple clusters are a useful mechanism for a rolling upgrade; you subdivide your overall capacity into N smaller clusters, and then can upgrade those by taking a cluster at a time off line. This is needed instead of a rolling upgrade of 1 server at a time within the same cluster if the new version of the app can't co-exist with the old in the same cluster (e.g. incompatible state). I have a slightly simpler definition, but is essentially the same as what you are describing. I used it in req 1: "A *+domain+* is a management policy that applies to one or more servers/nodes, which may or may not be part of a cluster" In other words, the only thing that every member of the domain has in common is the fact that they have the same domain.xml file. A better definition would probably be. "A domain is a management policy that applies to one or more servers/nodes, which may or may not be part of a homogenous group". When you think about it, a server-group, and a cluster are really the same thing, the only difference is that the cluster has an additional set of services that a basic group does not. This was what I meant by the cluster-service tag, a way to specify how a group would cluster a particular service (maybe not all services should be clustered). Although it was just something I through out there as an example. A better way likely exists -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/536347#536347] Start a new discussion in Management Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]

15 years, 12 months

1
0
0 / 0

Re: [jboss-dev-forums] [Management Development] - To scope or not to scope (domain.xml)

by Brian Stansberry

Brian Stansberry [http://community.jboss.org/people/bstansberry%40jboss.com] replied to the discussion "To scope or not to scope (domain.xml)" To view the discussion, visit: http://community.jboss.org/message/536340#536340 -------------------------------------------------------------- Excellent question! We need to agree on the definition of some terms. To me a "domain" is a set of servers meant to be managed as a unit (acknowledgment: how things are "managed as a unit" is vague/fuzzy; a key task is to clarify exactly what that means.) The servers don't need to all have a homogenous profile, as people may wish to tier things. (In example above written for the clustering meeting the "DataGrid" profile was meant to describe a bunch of servers running Infinispan to serve as large scale grid storage behind a JEE tier.) I see a domain as needing to allow multiple clusters, even ignoring the different tier idea. Mutliple clusters are a useful mechanism for a rolling upgrade; you subdivide your overall capacity into N smaller clusters, and then can upgrade those by taking a cluster at a time off line. This is needed instead of a rolling upgrade of 1 server at a time within the same cluster if the new version of the app can't co-exist with the old in the same cluster (e.g. incompatible state). <domain> <profile name=”jee”>.... define a set of capabilities, configuration thereof</profile> <cluster name=”jee-1” mcast_addr=”234.5.6.7” default_stack=”udp” profile=”jee”/> <cluster name=”jee-2” mcast_addr=”235.6.7.8” default_stack=”udp” profile=”jee”/> <server name=”jee-1-1” bind_address=”192.168.0.100”> <cluster-ref name=”jee-1” cluster_address=”10.0.0.100”/> </server> <server name=”jee-1-2” bind_address=”192.168.0.101”> <cluster-ref name=”jee-1” cluster_address=”10.0.0.101”/> </server> <server name=”jee-2-1” bind_address=”192.168.0.102”> <cluster-ref name=”jee-2” cluster_address=”10.0.0.102”/> </server> <server name=”jee-2-1” bind_address=”192.168.0.103”> <cluster-ref name=”jee-2” cluster_address=”10.0.0.103”/> </server> </domain> Re: deployment, I don't see deploying to a domain. You'd deploy to a cluster, a server-group (if we end up with such a thing) or a standalone server. The "profile" element I showed is problematic though, since if management actions are occuring against a cluster/server-group/standalone server, how are changes written back? Perhaps what I showed becomes a "proifile-template" and then the smaller groups declare a "profile" that extends the template. -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/536340#536340] Start a new discussion in Management Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]

15 years, 12 months

1
0
0 / 0

Re: [jboss-dev-forums] [JBoss Web Services Development] - JBWS-2210 : CXF Username Token JAAS integration

by ANIL SALDHANA

ANIL SALDHANA [http://community.jboss.org/people/anil.saldhana%40jboss.com] replied to the discussion "JBWS-2210 : CXF Username Token JAAS integration" To view the discussion, visit: http://community.jboss.org/message/536327#536327 -------------------------------------------------------------- If you are trying to do the authentication in JBoss AS, you can use PicketBox Api. http://community.jboss.org/wiki/PicketBoxOverview http://community.jboss.org/wiki/PicketBoxOverview -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/536327#536327] Start a new discussion in JBoss Web Services Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]

15 years, 12 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums April 2010