Red Hat Bugzilla – Bug 813214
[as7] Re-visit JVM handling as soon as AS7 knows what they want to do
Last modified: 2013-09-01 15:20:13 EDT
This is triggered by Bug 708332 :
the original idea was that a host and server group defines a jvm definition and a managed server can "point to it".
Now the case is that a managed server can have child jmv definitions - from which "the first" is taken to define overrides over the sg and host ones.
[10:43:38] <pilhuhn> If I define 2 jvms below /host=master/server-config=server-one/jvm=* how does the managed server decide, which to pick?
[10:46:53] <pilhuhn> IIrc, that used to be a simple attribute that points to a jvm on e.g. server-goup level (what you wrote above)
[10:47:10] <pilhuhn> but now I can define multiple children -- and there is no attribute saying which to pick
[10:47:21] <+emuckenhuber> it's the first one
[10:47:25] <+emuckenhuber> which gets picked
[10:47:34] <maximilienw> stuartdouglas: got it thanks
[10:48:03] <pilhuhn> emuckenhuber define "first" ?
[10:48:17] <+emuckenhuber> we wanted to fix it, so that you can only have a single child - however that will most likely only get done in 7.2
[10:48:42] <pilhuhn> why child at all? can't one just point to a definition on sg-level?
[10:48:48] <+emuckenhuber> the first entry serverModel.get(JVM).keys() returns
[10:49:32] <pilhuhn> emuckenhuber and why should I then define multiple jvms on sg-level? When I can't re-use them?
[10:50:06] <+emuckenhuber> yeah, both server-group and server should only have a single jvm element - where you can define 1st) the reference to the host VM
[10:50:19] <+emuckenhuber> 2nd) the server-group and server specific overrides
[10:50:28] <+emuckenhuber> i.e. debugging is server only
[10:50:33] <pilhuhn> hm
[10:51:29] <pilhuhn> and then (we talked about that before, but I don't recall details) when I read server/jvm=default, there should be a way to get the full information at client level - and not just the specific override
[10:53:29] <pilhuhn> emuckenhuber is there a JIRA for " <+emuckenhuber> we wanted to fix it" ?
[10:54:07] <+emuckenhuber> hmm, i am not sure - probably not... i will check and create it if i don't find it
[10:56:16] <pilhuhn> and then server overrides sg overrides host definition?
[10:56:58] <+emuckenhuber> yes, exactly
[13:13:28] <pilhuhn> Thanks -- can I assume that this jvm is always called "default" if it exists?
[13:13:56] <pilhuhn> Or can we make that "deal" ?
[13:15:11] <+emuckenhuber> hmm, well the issue is that the name is actually the reference to the host VM - that is unfortunate
[13:15:23] <+emuckenhuber> makes it a bit more complex :-/
[13:17:51] <pilhuhn> So on host level I can have multiple of tehm. Then on sg-level I can have ? A SG spans multiple hosts. Who guarantees that all hosts in the SG have a definition "foo" ?
[13:21:54] <+emuckenhuber> there is no guarantee - i am not sure if it's missing is a failure though
Local implementation is now as follows:
The resource type of "JVM Definition" for server-groups (SG) and managed servers (MS) are singletons below the level of managed server or server group. This means that a MS or SG can only have one child of that type. Unfortunately the UI allows to create as many singleton resources of a type as the user wants ( Bug 814305 )
The name of the resource must be one of the jvm definitions at host level. Unfortunately the UI does not allow for pre-computed names (see Bug 814309 ) so the user can enter any name at the wizard. On the properties page he gets the list of allowed base definitions that are then turned into the final name.
When the user has submitted the resource creation request and another resource of this type exists already, an Excption is thrown saying that this is a singleton and that he should delete the other resource first.
Bulk closing of BZs that have no target version set, but which are ON_QA for more than a year and thus are in production for a long time.