<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Hi,<div><br></div><div>this email is triggered by&nbsp;<a href="https://bugzilla.redhat.com/show_bug.cgi?id=846756">https://bugzilla.redhat.com/show_bug.cgi?id=846756</a></div><div><br></div><div>Basically in AS7 domain mode you have 2 conceptually different things:</div><div>- configuration information</div><div>- runtime information</div><div><br></div><div>Configuration information is present in e.g. the profiles with all their subsystems and and sub-resources,</div><div>but also in the form of server-group-definition or by creating new managed servers.</div><div>In domain mode all configuration changes must go through the domain controller.</div><div><br></div><div>Runtime information is present as data on deployments, and managed servers</div><div><br></div><div>And then there is the constraint that configurations need to be changed on the</div><div>domain controller and not on the host controllers.</div><div><br></div><div>So I think that on a host controller, the profiles section should not be shown,&nbsp;</div><div>and probably also not the server groups. Same for deployments, as they are supposed</div><div>to be manipulated on the DC as well.</div><div><br></div><div>For the managed servers, that are created on the DC, but are instantiated on the individual HCs,</div><div>we have a mixed situation:</div><div><br></div><div>- manipulation should happen on the DC</div><div>- metrics runtime should optimally be obtained on the HCs via an agent on the machine</div><div><br></div><div>So where in the tree do we show the managed servers?</div><div>Current situation is to show them as direct child of the respective HC</div><div><br></div><div>We could also show all managed servers on the level of the DC:</div><div><br></div><div><img height="306" width="235" apple-width="yes" apple-height="yes" id="e85b2a58-2419-45de-b04a-2ce39de1da29" src="cid:19FAA3E3-5ADF-44BE-AA75-97BB097B4DAC"></div><div><br></div><div>This view could be improved by having the managed server name in the form of &lt;product&gt; &lt;host&gt;/&lt;name&gt; e.g.</div><div>"EAP master/server-one" or "AS7 pintAS/pint one"</div><div><br></div><div>Another alternative could be to move the managed servers one level down below the hosts</div><div><br></div><div><img height="484" width="233" apple-width="yes" apple-height="yes" id="1848d9da-3e91-48a8-97c3-b130989d6999" src="cid:5ED1E065-B687-423A-A3AF-287A8E0A042D"></div><div><br></div><div>So that it is clear which host hosts which managed servers.</div><div><br></div><div>This scenario would require to make the managed servers a service or</div><div>the hosts a server too (*1)</div><div><br></div><div>Still the question of where do we take which metrics from stays open, as in the</div><div>above scenarios, the usability improves, as the domain management is better</div><div>centered around one place, but would require to run all requests for metrics to</div><div>go through the DC (*2).</div><div><br></div><div>Optimally, we would show the managed servers with their configuration parts</div><div>below the host at the DC, have each HC list the managed servers as they are</div><div>today for metric collection AND have a sibling relationship from the managed</div><div>server a the DC below the host to the "real" one on the respective HC.</div><div>As this would further require splitting and duplicating resource types in the</div><div>already overfull plugin descriptor, we would also need to allow to add a flag</div><div>in the descriptor that can for runs-inside types enable/disable a certain element</div><div>for a specific (set of) parent(s). As example:</div><div><br></div><div>&lt;service bla&gt;</div><div>&nbsp; &lt;runs-inside&gt;</div><div>&nbsp; &nbsp; &nbsp;&lt;server managed-as/&gt;</div><div>&nbsp; &nbsp; &nbsp;&lt;service profile/&gt;</div><div>&nbsp; &nbsp; &nbsp;&lt;service deployment/&gt;</div><div>&nbsp; &lt;/runs-inside&gt;</div><div>&nbsp; &nbsp;&nbsp;</div><div>&nbsp; &lt;metric name="a" &nbsp;available="not(profile)" .../&gt;</div><div>&nbsp; &lt;operation name="b" available="not(profile)" .. /&gt;</div><div>&nbsp; &lt;operation name="c" available="profile"/&gt;</div><div>&nbsp; &lt;operation name="d" available="profile,managed-as"/&gt;</div><div><br></div><div>&nbsp; &lt;resource-configuration available="profile"../&gt;</div><div><br></div><div><br></div><div>Detection if a HC is &nbsp;a HC or a DC is simple (*3), so modifying the</div><div>discovery to not discovery profiles at HC level can be easily achieved.</div><div>&nbsp; &nbsp; &nbsp;</div><div>&nbsp; &nbsp;Heiko</div><div><br></div><div><br></div><div>*1) Services can not have servers inside in the resource category; we may also just</div><div>loosen that requirement.</div><div>*2) Which on the other hand allows to support hosts in a domain that do not run</div><div>an RHQ agent, which may be of interest in small virtual machine installations.</div><div>*3)&nbsp;</div><div>&nbsp; &nbsp; &nbsp; &nbsp; Operation op = new ReadAttribute(new Address(),"process-type");<br>&nbsp; &nbsp; &nbsp; &nbsp; Result res = connection.execute(op);<br>&nbsp; &nbsp; &nbsp; &nbsp; if (res.isSuccess()) {<br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; String type = (String) res.getResult();<br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; return type.startsWith("Domain");</div><div><br><div>--&nbsp;<br>Reg. Adresse: Red Hat GmbH, Technopark II, Haus C,&nbsp;<br>Werner-von-Siemens-Ring 14, D-85630 Grasbrunn<br>Handelsregister: Amtsgericht München HRB 153243<br>Geschaeftsführer: &nbsp;Mark Hegarty, Charlie Peters, Michael Cunningham, Charles Cachera</div><br></div></body></html>