6:13 a.m.
I am wondering if it will be possible to create profiles from the web ui? Does it make
sense? A similiar question arises for host configurations. How does the discovery work?
Can someone outline which parts of the model cannot be changed? I.e would require a
controller restart?
For now i am assuming that profiles are immutable (the top level elements, not the
subsystems).
Ike
6:29 a.m.
On 02/14/2011 01:13 PM, Heiko Braun wrote:
I am wondering if it will be possible to create profiles from the web ui? Does it make
sense?
Yes, in the domain creating new profiles and assigning them to
server-groups should be possible. In standalone there is only a single
profile, so only subsystems are mutable.
A similiar question arises for host configurations. How does the
discovery work?
At the moment there is only a static element in host.xml defining how a
host connects to the DC. So you can't create a new host from the UI,
however they would appear once they are connected to the DC. The
elements in the host.xml can be managed for each host though.
Can someone outline which parts of the model cannot be changed? I.e
would require a controller restart?
Hmm, the only operations we talked about requiring a restart are most
likely when you change the management port configuration. Other
operations shouldn't require a restart, especially not on the DC.
6:43 a.m.
On 02/14/2011 12:29 PM, Emanuel Muckenhuber wrote:
On 02/14/2011 01:13 PM, Heiko Braun wrote:
>
> I am wondering if it will be possible to create profiles from the web ui? Does it
make sense?
Yes, in the domain creating new profiles and assigning them to
server-groups should be possible. In standalone there is only a single
profile, so only subsystems are mutable.
> A similiar question arises for host configurations. How does the discovery work?
>
At the moment there is only a static element in host.xml defining how a
host connects to the DC. So you can't create a new host from the UI,
however they would appear once they are connected to the DC. The
elements in the host.xml can be managed for each host though.
This is how I saw it on Brian's YouTube video so I assume host
manipulation is something that will be retained (once a host is started)
as it is a major feature already talked about publicly.
> Can someone outline which parts of the model cannot be changed?
I.e would require a controller restart?
>
Hmm, the only operations we talked about requiring a restart are most
likely when you change the management port configuration. Other
operations shouldn't require a restart, especially not on the DC.
_______________________________________________
jboss-as7-dev mailing list
jboss-as7-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
9:09 a.m.
On 2/14/11 6:43 AM, Darran Lofthouse wrote:
On 02/14/2011 12:29 PM, Emanuel Muckenhuber wrote:
> On 02/14/2011 01:13 PM, Heiko Braun wrote:
>>
>> I am wondering if it will be possible to create profiles from the web ui? Does it
make sense?
>
> Yes, in the domain creating new profiles and assigning them to
> server-groups should be possible. In standalone there is only a single
> profile, so only subsystems are mutable.
>
>> A similiar question arises for host configurations. How does the discovery work?
>>
>
> At the moment there is only a static element in host.xml defining how a
> host connects to the DC. So you can't create a new host from the UI,
> however they would appear once they are connected to the DC. The
> elements in the host.xml can be managed for each host though.
This is how I saw it on Brian's YouTube video so I assume host
manipulation is something that will be retained (once a host is started)
as it is a major feature already talked about publicly.
The ability that I demoed (sic???) to add a new server to an existing
host will certainly be retained (as will other forms of host
manipulation). A new server can be created because there is an existing
HostController and ProcessController that can spawn it.
>> Can someone outline which parts of the model cannot be
changed? I.e would require a controller restart?
>>
>
> Hmm, the only operations we talked about requiring a restart are most
> likely when you change the management port configuration. Other
> operations shouldn't require a restart, especially not on the DC.
> _______________________________________________
> jboss-as7-dev mailing list
> jboss-as7-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
_______________________________________________
jboss-as7-dev mailing list
jboss-as7-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
--
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat
10:51 a.m.
On Feb 14, 2011, at 1:29 PM, Emanuel Muckenhuber wrote:
Yes, in the domain creating new profiles and assigning them to
server-groups should be possible. In standalone there is only a single
profile, so only subsystems are mutable.
How would you do that?
Profiles consist of includes and specific subsystems.
How do I get a list of subsystems that can be mixed in a new, custom profile?
What about dependencies between subsystems?
Are you sure this can be achieved in a drag&drop manner?
Ike
10:54 a.m.
On 02/14/2011 10:51 AM, Heiko Braun wrote:
On Feb 14, 2011, at 1:29 PM, Emanuel Muckenhuber wrote:
> Yes, in the domain creating new profiles and assigning them to
> server-groups should be possible. In standalone there is only a single
> profile, so only subsystems are mutable.
How would you do that?
Profiles consist of includes and specific subsystems.
How do I get a list of subsystems that can be mixed in a new, custom profile?
What about dependencies between subsystems?
That's an outstanding issue. I think we should strive to modify our
subsystem/extension architecture such that there are no inter-subsystem
dependencies. In particular, the worst offender (the threads subsystem)
is scheduled for termination (in its current form).
I think we should proceed on the assumption that it won't be possible to
have a subsystem configured which has a dependency on another subsystem
which is missing.
--
- DML
10:59 a.m.
On Feb 14, 2011, at 5:54 PM, David M. Lloyd wrote:
I think we should proceed on the assumption that it won't be
possible to
have a subsystem configured which has a dependency on another subsystem
which is missing.
Yes, but to build tooling around that (web UI), I would need to know subsystem
interdependencies upfront.
(i.e. meta data). Otherwise I cannot put this feature into the console.
Hence my question in the first place.
Ike
11:18 a.m.
On 2/14/11 10:59 AM, Heiko Braun wrote:
On Feb 14, 2011, at 5:54 PM, David M. Lloyd wrote:
> I think we should proceed on the assumption that it won't be possible to
> have a subsystem configured which has a dependency on another subsystem
> which is missing.
Yes, but to build tooling around that (web UI), I would need to know subsystem
interdependencies upfront.
(i.e. meta data). Otherwise I cannot put this feature into the console.
Is that really a requirement, i.e. making things foolproof? I totally
agree it's highly desirable and something we should see if we can
improve, but is it a requirement? If people are trying to add profiles
(or subsystems) to running domains via the web UI, they are either going
to be in dev mode or they've tested what they are doing in advance.
Hence my question in the first place.
Ike
_______________________________________________
jboss-as7-dev mailing list
jboss-as7-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
--
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat
11:35 a.m.
On Feb 14, 2011, at 6:18 PM, Brian Stansberry wrote:
>>
>> I think we should proceed on the assumption that it won't be possible to
>> have a subsystem configured which has a dependency on another subsystem
>> which is missing.
>
> Yes, but to build tooling around that (web UI), I would need to know subsystem
interdependencies upfront.
> (i.e. meta data). Otherwise I cannot put this feature into the console.
>
Is that really a requirement, i.e. making things foolproof? I totally
agree it's highly desirable and something we should see if we can
improve, but is it a requirement? If people are trying to add profiles
(or subsystems) to running domains via the web UI, they are either going
to be in dev mode or they've tested what they are doing in advance.
I completely agree. But for this exact reason I would say it doesn't even need to be
possible through the web UI.
IMO we can easily consider this out of scope.
Ike
11:56 a.m.
On 2/14/11 11:35 AM, Heiko Braun wrote:
On Feb 14, 2011, at 6:18 PM, Brian Stansberry wrote:
>>>
>>> I think we should proceed on the assumption that it won't be possible to
>>> have a subsystem configured which has a dependency on another subsystem
>>> which is missing.
>>
>> Yes, but to build tooling around that (web UI), I would need to know subsystem
interdependencies upfront.
>> (i.e. meta data). Otherwise I cannot put this feature into the console.
>>
>
> Is that really a requirement, i.e. making things foolproof? I totally
> agree it's highly desirable and something we should see if we can
> improve, but is it a requirement? If people are trying to add profiles
> (or subsystems) to running domains via the web UI, they are either going
> to be in dev mode or they've tested what they are doing in advance.
I completely agree. But for this exact reason I would say it doesn't even need to be
possible through the web UI.
IMO we can easily consider this out of scope.
Haha, I have to do better at getting my head fully out of core API mode
and into web UI mode. So, I agree; just because the core management API
makes something possible doesn't mean there has to be a polished GUI for
it. We need to allow adding profiles in the core API, otherwise to add a
new profile to a domain users would have to down the DC, edit domain.xml
and restart DC. The web UI is a whole different animal.
--
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat
11:03 a.m.
On Feb 14, 2011, at 5:54 PM, David M. Lloyd wrote:
I think we should strive to modify our
subsystem/extension architecture such that there are no inter-subsystem
dependencies.
Sorry, I had to read your email a second time. Do you really think this will be possible?
A typical shared subsystem is the the TransactionManager. How can JCA be left out
in a custom profile without including this one?
Ike
11:14 a.m.
On 02/14/2011 11:03 AM, Heiko Braun wrote:
On Feb 14, 2011, at 5:54 PM, David M. Lloyd wrote:
> I think we should strive to modify our
> subsystem/extension architecture such that there are no inter-subsystem
> dependencies.
Sorry, I had to read your email a second time. Do you really think this will be
possible?
A typical shared subsystem is the the TransactionManager. How can JCA be left out
in a custom profile without including this one?
The way we've solved this in other subsystems is by introducing optional
dependencies at the service level. For example if the transaction
subsystem is configured with an ORB present, we configure JTS, otherwise
we do not; if OSGi and Txn are both present, then OSGi exposes the Txn
service.
I'm not 100% certain we can extend this technique to all cases, but I
think we should at least try to. JCA for example would obviously be
quite crippled without JTA. So I do not have an answer to that case;
maybe it suffices to print a warning message in this case. We should at
least explore it before we throw out the idea though.
--
- DML
11:23 a.m.
On 02/14/2011 05:14 PM, David M. Lloyd wrote:
On 02/14/2011 11:03 AM, Heiko Braun wrote:
>
> On Feb 14, 2011, at 5:54 PM, David M. Lloyd wrote:
>
>> I think we should strive to modify our
>> subsystem/extension architecture such that there are no inter-subsystem
>> dependencies.
>
>
> Sorry, I had to read your email a second time. Do you really think this will be
possible?
> A typical shared subsystem is the the TransactionManager. How can JCA be left out
> in a custom profile without including this one?
The way we've solved this in other subsystems is by introducing optional
dependencies at the service level. For example if the transaction
subsystem is configured with an ORB present, we configure JTS, otherwise
we do not; if OSGi and Txn are both present, then OSGi exposes the Txn
service.
I wonder how far this can be taken once the deployments come into this,
those will introduce dependencies on other subsystems that are not
necessarily needed for all possible deployments.
I'm not 100% certain we can extend this technique to all cases,
but I
think we should at least try to. JCA for example would obviously be
quite crippled without JTA. So I do not have an answer to that case;
maybe it suffices to print a warning message in this case. We should at
least explore it before we throw out the idea though.
11:54 a.m.
On 02/14/2011 11:23 AM, Darran Lofthouse wrote:
On 02/14/2011 05:14 PM, David M. Lloyd wrote:
> On 02/14/2011 11:03 AM, Heiko Braun wrote:
>>
>> On Feb 14, 2011, at 5:54 PM, David M. Lloyd wrote:
>>
>>> I think we should strive to modify our
>>> subsystem/extension architecture such that there are no inter-subsystem
>>> dependencies.
>>
>>
>> Sorry, I had to read your email a second time. Do you really think
>> this will be possible?
>> A typical shared subsystem is the the TransactionManager. How can JCA
>> be left out
>> in a custom profile without including this one?
>
> The way we've solved this in other subsystems is by introducing optional
> dependencies at the service level. For example if the transaction
> subsystem is configured with an ORB present, we configure JTS, otherwise
> we do not; if OSGi and Txn are both present, then OSGi exposes the Txn
> service.
I wonder how far this can be taken once the deployments come into this,
those will introduce dependencies on other subsystems that are not
necessarily needed for all possible deployments.
The only sensible action we can take here is to trigger a deployment
error in cases where something is missing a dependency, and ignore
descriptors for subsystems which aren't loaded (which also happens to be
the current behavior). If we add complex logic to detect missing
subsystems (even for the purpose of diagnostics), we will be duplicating
some of the logic from each subsystem anyway.
--
- DML
11:27 a.m.
On 2/14/11 11:14 AM, David M. Lloyd wrote:
On 02/14/2011 11:03 AM, Heiko Braun wrote:
>
> On Feb 14, 2011, at 5:54 PM, David M. Lloyd wrote:
>
>> I think we should strive to modify our
>> subsystem/extension architecture such that there are no inter-subsystem
>> dependencies.
>
>
> Sorry, I had to read your email a second time. Do you really think this will be
possible?
> A typical shared subsystem is the the TransactionManager. How can JCA be left out
> in a custom profile without including this one?
The way we've solved this in other subsystems is by introducing optional
dependencies at the service level. For example if the transaction
subsystem is configured with an ORB present, we configure JTS, otherwise
we do not; if OSGi and Txn are both present, then OSGi exposes the Txn
service.
I'm not 100% certain we can extend this technique to all cases, but I
think we should at least try to. JCA for example would obviously be
quite crippled without JTA. So I do not have an answer to that case;
maybe it suffices to print a warning message in this case. We should at
least explore it before we throw out the idea though.
Let's assume for the sake of argument that we want to expose dependency
info via the management interface. I see here hard dependencies (e.g.
presumably JCA and JTA) and optional. Extensions could register these
dependencies when they initialize. It opens up a can of worms though, as
we'd need a proper language to describe the dependencies.
Thinking out loud here, could we use the module dependency information
for this? Nah, that would just say, e.g. that JCA needs the JTA APIs,
but says nothing about the impl.
--
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat
11:38 a.m.
On Feb 14, 2011, at 6:27 PM, Brian Stansberry wrote:
Let's assume for the sake of argument that we want to expose
dependency
info via the management interface. I see here hard dependencies (e.g.
presumably JCA and JTA) and optional. Extensions could register these
dependencies when they initialize. It opens up a can of worms though, as
we'd need a proper language to describe the dependencies.
Thinking out loud here, could we use the module dependency information
for this? Nah, that would just say, e.g. that JCA needs the JTA APIs,
but says nothing about the impl.
As I said in an earlier email. To me, this is edge case that can easily be considered
something that we don't support. If we need or want todo it, it needs to be fool
proof
and hence require a way to describe these dependencies and to validate newly created
profiles.
Furthermore, if it's not a strict requirement, we drop this idea.
Ike
1:27 p.m.
On 2/14/11 11:38 AM, Heiko Braun wrote:
On Feb 14, 2011, at 6:27 PM, Brian Stansberry wrote:
> Let's assume for the sake of argument that we want to expose dependency
> info via the management interface. I see here hard dependencies (e.g.
> presumably JCA and JTA) and optional. Extensions could register these
> dependencies when they initialize. It opens up a can of worms though, as
> we'd need a proper language to describe the dependencies.
>
> Thinking out loud here, could we use the module dependency information
> for this? Nah, that would just say, e.g. that JCA needs the JTA APIs,
> but says nothing about the impl.
As I said in an earlier email. To me, this is edge case that can easily be considered
something that we don't support. If we need or want todo it, it needs to be fool
proof
and hence require a way to describe these dependencies and to validate newly created
profiles.
Furthermore, if it's not a strict requirement, we drop this idea.
We do have requirements in this area (see ERD, also pasted below for
quick reference). Instead of shipping 50 profile configs, we want users
to be able to easily enable and disable their subsystems. So IMO I think
it makes a lot of sense to eventually be in the web console.
Ultimately for both the installer, and the admin tools (again if not
now, eventually) I think we will need a very basic subsystem dependency
expression for the sole purpose of validation (this was discussed in
Madison long ago). If, as david says, we have no deps then thats great,
but I suspect that we will.
As to knowing what subsystems are available, thats something we can
represent in the profiles metatype info. The deps would also be
contained there.
EAP.01084:
Requirement: "It will be possible to enable / disable individual
subsystems that will be effective at the next (re)start."
Comments: "The domain configuration will contain a subsystem config per
subsystem; profiles are made up of subsystems. Subsystems can be removed
from the configuration which will result in them not being loaded."
EAP.01086:
Requirement "It will be possible to determine the dependencies between
services."
Comments: "This will allow tooling to prevent invalid combinations. The
domain and tooling will error, or attempt to prevent broken dependencies."
--
Jason T. Greene
JBoss, a division of Red Hat
1:38 p.m.
On 02/14/2011 07:27 PM, Jason T. Greene wrote:
Requirement "It will be possible to determine the dependencies
between
services."
Comments: "This will allow tooling to prevent invalid combinations. The
domain and tooling will error, or attempt to prevent broken dependencies."
For this requirement what is a 'service'?
We have subsystems and we have deployments but the dependencies of the
subsystems can be very much affected by the deployments e.g. does the
EJB3 subsystem depend on JCA if it has no deployments that use a JCA
resource? Same goes for a web deployment, you could want to just deploy
some simple servlets or you could want to deploy an app that uses EJBs
and has some database access.
1:44 p.m.
On 2/14/11 1:38 PM, Darran Lofthouse wrote:
On 02/14/2011 07:27 PM, Jason T. Greene wrote:
> Requirement "It will be possible to determine the dependencies between
> services."
>
> Comments: "This will allow tooling to prevent invalid combinations. The
> domain and tooling will error, or attempt to prevent broken
> dependencies."
For this requirement what is a 'service'?
We have subsystems and we have deployments but the dependencies of the
subsystems can be very much affected by the deployments e.g. does the
EJB3 subsystem depend on JCA if it has no deployments that use a JCA
resource? Same goes for a web deployment, you could want to just deploy
some simple servlets or you could want to deploy an app that uses EJBs
and has some database access.
The requirement is just in relation to altering the domain
configuration, and preventing bad profiles. Deployments could be a
problem but those can have failures at deploy time (which would be
resolved by adding the missing subsystem).
I think the rule should be that we only prevent non-working
configurations. E.g if there is a way to make EJB work without JCA there
should be no reason to disallow that.
--
Jason T. Greene
JBoss, a division of Red Hat
12:01 p.m.
On 02/14/2011 11:27 AM, Brian Stansberry wrote:
On 2/14/11 11:14 AM, David M. Lloyd wrote:
> The way we've solved this in other subsystems is by introducing optional
> dependencies at the service level. For example if the transaction
> subsystem is configured with an ORB present, we configure JTS, otherwise
> we do not; if OSGi and Txn are both present, then OSGi exposes the Txn
> service.
>
> I'm not 100% certain we can extend this technique to all cases, but I
> think we should at least try to. JCA for example would obviously be
> quite crippled without JTA. So I do not have an answer to that case;
> maybe it suffices to print a warning message in this case. We should at
> least explore it before we throw out the idea though.
Let's assume for the sake of argument that we want to expose dependency
info via the management interface. I see here hard dependencies (e.g.
presumably JCA and JTA) and optional. Extensions could register these
dependencies when they initialize. It opens up a can of worms though, as
we'd need a proper language to describe the dependencies.
Yeah the can of worms is what I seek to avoid, though it might be
inevitable eventually.
Thinking out loud here, could we use the module dependency
information
for this? Nah, that would just say, e.g. that JCA needs the JTA APIs,
but says nothing about the impl.
I don't think module deps would cut it for this use case. The
dependency exists at purely a subsystem level, not at a module level,
and imposing a constraint between the two just for this reason really
rubs me the wrong way; anyway module dependencies are not by any means
static (we just use them that way, most of the time) and are definitely
not suitable as management layer metainformation.
--
- DML
12:23 p.m.
On 2/14/11 12:01 PM, David M. Lloyd wrote:
On 02/14/2011 11:27 AM, Brian Stansberry wrote:
> On 2/14/11 11:14 AM, David M. Lloyd wrote:
>> The way we've solved this in other subsystems is by introducing optional
>> dependencies at the service level. For example if the transaction
>> subsystem is configured with an ORB present, we configure JTS, otherwise
>> we do not; if OSGi and Txn are both present, then OSGi exposes the Txn
>> service.
>>
>> I'm not 100% certain we can extend this technique to all cases, but I
>> think we should at least try to. JCA for example would obviously be
>> quite crippled without JTA. So I do not have an answer to that case;
>> maybe it suffices to print a warning message in this case. We should at
>> least explore it before we throw out the idea though.
>
> Let's assume for the sake of argument that we want to expose dependency
> info via the management interface. I see here hard dependencies (e.g.
> presumably JCA and JTA) and optional. Extensions could register these
> dependencies when they initialize. It opens up a can of worms though, as
> we'd need a proper language to describe the dependencies.
Yeah the can of worms is what I seek to avoid, though it might be
inevitable eventually.
Where it can come in is via a graphical installer. As discussed
elsewhere on this thread I don't think it's required for the web UI. For
users of the CLI, native API or xml-editing I think proper documentation
is sufficient. It's users of a graphical installer who would expect the
installer to tell them about missing dependencies.
> Thinking out loud here, could we use the module dependency
information
> for this? Nah, that would just say, e.g. that JCA needs the JTA APIs,
> but says nothing about the impl.
I don't think module deps would cut it for this use case. The
dependency exists at purely a subsystem level, not at a module level,
and imposing a constraint between the two just for this reason really
rubs me the wrong way; anyway module dependencies are not by any means
static (we just use them that way, most of the time) and are definitely
not suitable as management layer metainformation.
Yeah, that was just me thinking (and rejecting) out loud.
--
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat
1:34 p.m.
On 2/14/11 12:01 PM, David M. Lloyd wrote:
On 02/14/2011 11:27 AM, Brian Stansberry wrote:
> Thinking out loud here, could we use the module dependency
information
> for this? Nah, that would just say, e.g. that JCA needs the JTA APIs,
> but says nothing about the impl.
I don't think module deps would cut it for this use case. The
dependency exists at purely a subsystem level, not at a module level,
and imposing a constraint between the two just for this reason really
rubs me the wrong way; anyway module dependencies are not by any means
static (we just use them that way, most of the time) and are definitely
not suitable as management layer metainformation.
I agree that module deps and subsystem deps are essentially orthogonal.
However, adding "slimming" support (not something needed for 7.0), would
require that we have way to group chunks of functionality that can be
removed from the module repo. The majority of this could be dynamically
resolved by starting at all used subsystem entry points (implies we
need a convention here), resolving the full dep tree, and building a
purge list for modules that are never referenced. The challenge is
modules which are referenced by name (e.g. typically used to build refs
for deployments). So we may need a way for a subsystem to register
by-name stuff in some way.
Anyway we don't have to solve this now, I just wanted to point out that
there is a limited relationship.
--
Jason T. Greene
JBoss, a division of Red Hat
5031
days inactive
5031
days old
21 comments
7 participants
participants (7)
-
Brian Stansberry -
Darran Lofthouse -
Darran Lofthouse -
David M. Lloyd -
Emanuel Muckenhuber -
Heiko Braun -
Jason T. Greene