Hi <div><br></div><div>To illustrate what I had in mind, please find attached mock up. I was thinking of including the the additional fields about the traits (shown in red).</div><div><br></div><div>I agree using configuration would be an easy option, however this information would then be hidden away under a configuration tab. I have added this to the mockup to check my understanding. </div>
<div><br></div><div>thanks</div><div><br></div><div>Richard<br><br><div class="gmail_quote">On 19 October 2012 00:25, John Mazzitelli <span dir="ltr">&lt;<a href="mailto:mazz@redhat.com" target="_blank">mazz@redhat.com</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">These definitely would NOT go into the Resource object. These look more like plugin configuration properties.<br>
<br>
You could look into using tags for something like this, too ( <a href="https://docs.jboss.org/author/display/RHQ/Tagging" target="_blank">https://docs.jboss.org/author/display/RHQ/Tagging</a> ). You could use this today without changing plugins or things like that.<br>

<div class="HOEnZb"><div class="h5"><br>
<br>
----- Original Message -----<br>
&gt; Richard,<br>
&gt;<br>
&gt; &gt; I have a requirement to display some a additional on the platform<br>
&gt; &gt; in RHQ.<br>
&gt; &gt;     • Make<br>
&gt; &gt;     • Model<br>
&gt; &gt;     • Asset Tag<br>
&gt; &gt;     • Function<br>
&gt; &gt;     • Notes<br>
&gt; &gt; Would it be ok to add these as additional fields to the Resource so<br>
&gt; &gt; that users can manually enter the values?<br>
&gt;<br>
&gt; Not sure if you mean this: The Resource.class is a bad place, as this<br>
&gt; is used for all the resources<br>
&gt; in the system and thus the fields would also apply to services like a<br>
&gt; war file.<br>
&gt;<br>
&gt; What you could do though is to use the configuration object(s) for<br>
&gt; this purpose and just e.g. add<br>
&gt; a resource configuration object of the Linux type in the platform<br>
&gt; plugin, which can then be filled by<br>
&gt; hand or via the plugin. It is not exactly the right place, but a<br>
&gt; place that already exists.<br>
&gt;<br>
&gt; I was thinking in the past about adding some location area to the<br>
&gt; platforms as well (geographical and/or<br>
&gt; building/room/rack/... ), so one could even add (attention: more<br>
&gt; work) a new configuration for this purpose<br>
&gt; that is also shown on the inventory tab, but a different subtab.<br>
&gt;<br>
&gt; I was also wondering in the past, if we could just have a generic<br>
&gt; configuration definition, where<br>
&gt; we&#39;d provide some fields out of the box (e.g. &quot;location&quot; for a<br>
&gt; platform) and where the admin could<br>
&gt; then per resource type in the admin section of RHQ define additional<br>
&gt; fields. So those additional<br>
&gt; fields would then not be defined in the plugin descriptor, but<br>
&gt; dynamically - and could also only set<br>
&gt; manually and not through plugin code (as this may not even know about<br>
&gt; the existence of the field).<br>
&gt;<br>
&gt; &gt; I have investigated populating Make and Model from the BIOS. This<br>
&gt; &gt; can be done on Linux using dmidecode. This does mean the agent<br>
&gt; &gt; would need to run as root though.<br>
&gt;<br>
&gt; This is something which is already in some places I think and which<br>
&gt; we may see more often.<br>
&gt; Could it make sense to not call dmidecode directly from the<br>
&gt; plugin/agent, but via some intermediary that<br>
&gt; is small and runs suid root so that the agent does not need to run as<br>
&gt; root?<br>
&gt;<br>
&gt; I wonder if we should start writing SELinux policies for those<br>
&gt; routines close to the operating system.<br>
&gt;<br>
&gt;   Heiko<br>
&gt;<br>
&gt; --<br>
&gt; Reg. Adresse: Red Hat GmbH, Technopark II, Haus C,<br>
&gt; Werner-von-Siemens-Ring 14, D-85630 Grasbrunn<br>
&gt; Handelsregister: Amtsgericht München HRB 153243<br>
&gt; Geschaeftsführer:  Mark Hegarty, Charlie Peters, Michael Cunningham,<br>
&gt; Charles Cachera<br>
&gt;<br>
&gt;<br>
</div></div><div class="HOEnZb"><div class="h5">&gt; _______________________________________________<br>
&gt; rhq-devel mailing list<br>
&gt; <a href="mailto:rhq-devel@lists.fedorahosted.org">rhq-devel@lists.fedorahosted.org</a><br>
&gt; <a href="https://lists.fedorahosted.org/mailman/listinfo/rhq-devel" target="_blank">https://lists.fedorahosted.org/mailman/listinfo/rhq-devel</a><br>
&gt;<br>
_______________________________________________<br>
rhq-devel mailing list<br>
<a href="mailto:rhq-devel@lists.fedorahosted.org">rhq-devel@lists.fedorahosted.org</a><br>
<a href="https://lists.fedorahosted.org/mailman/listinfo/rhq-devel" target="_blank">https://lists.fedorahosted.org/mailman/listinfo/rhq-devel</a><br>
</div></div></blockquote></div><br></div>