Additional Platform Fields

Richard Hensman richard at onevisionconsulting.co.uk
Wed Oct 24 18:07:02 UTC 2012


Yes had a looking at Tagging, but I was unaware of the namespace stuff.

I can see how RHQ splits the tag on the equals sign and stores separately
in the database, but cannot see how this has any effect in the GUI. From a
usability point of view I was also hoping to display the values as shown in
my mockup. I wonder if Heiko's idea of using per resource type additional
fields would accomplish this?

On 22 October 2012 13:43, John Mazzitelli <mazz at redhat.com> wrote:

> Did you look at the Tags feature? This can give you I think most of what
> you want (if not all of it) already. you can define custom tags like:
>
> it:hwMake=Dell
> it:hwModel=Precision
> it:assetTag=123abc456
> rich:notes=This is for human resources
> biz:location=The HR building, fifth floor
>
> You can then search for them using the Tags Cloud view.
>
> Read: https://docs.jboss.org/author/display/RHQ/Tagging - it shows a
> screen snapshot of where you'd see these tags and how you'd add them (with
> the green circle + icon).
>
>
> ----- Original Message -----
> >
> > Hi
> >
> >
> > 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).
> >
> >
> > 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.
> >
> >
> > thanks
> >
> >
> > Richard
> >
> >
> > On 19 October 2012 00:25, John Mazzitelli < mazz at redhat.com > wrote:
> >
> >
> > These definitely would NOT go into the Resource object. These look
> > more like plugin configuration properties.
> >
> > You could look into using tags for something like this, too (
> > https://docs.jboss.org/author/display/RHQ/Tagging ). You could use
> > this today without changing plugins or things like that.
> >
> >
> >
> >
> > ----- Original Message -----
> > > Richard,
> > >
> > > > I have a requirement to display some a additional on the platform
> > > > in RHQ.
> > > > • Make
> > > > • Model
> > > > • Asset Tag
> > > > • Function
> > > > • Notes
> > > > Would it be ok to add these as additional fields to the Resource
> > > > so
> > > > that users can manually enter the values?
> > >
> > > Not sure if you mean this: The Resource.class is a bad place, as
> > > this
> > > is used for all the resources
> > > in the system and thus the fields would also apply to services like
> > > a
> > > war file.
> > >
> > > What you could do though is to use the configuration object(s) for
> > > this purpose and just e.g. add
> > > a resource configuration object of the Linux type in the platform
> > > plugin, which can then be filled by
> > > hand or via the plugin. It is not exactly the right place, but a
> > > place that already exists.
> > >
> > > I was thinking in the past about adding some location area to the
> > > platforms as well (geographical and/or
> > > building/room/rack/... ), so one could even add (attention: more
> > > work) a new configuration for this purpose
> > > that is also shown on the inventory tab, but a different subtab.
> > >
> > > I was also wondering in the past, if we could just have a generic
> > > configuration definition, where
> > > we'd provide some fields out of the box (e.g. "location" for a
> > > platform) and where the admin could
> > > then per resource type in the admin section of RHQ define
> > > additional
> > > fields. So those additional
> > > fields would then not be defined in the plugin descriptor, but
> > > dynamically - and could also only set
> > > manually and not through plugin code (as this may not even know
> > > about
> > > the existence of the field).
> > >
> > > > I have investigated populating Make and Model from the BIOS. This
> > > > can be done on Linux using dmidecode. This does mean the agent
> > > > would need to run as root though.
> > >
> > > This is something which is already in some places I think and which
> > > we may see more often.
> > > Could it make sense to not call dmidecode directly from the
> > > plugin/agent, but via some intermediary that
> > > is small and runs suid root so that the agent does not need to run
> > > as
> > > root?
> > >
> > > I wonder if we should start writing SELinux policies for those
> > > routines close to the operating system.
> > >
> > > Heiko
> > >
> > > --
> > > Reg. Adresse: Red Hat GmbH, Technopark II, Haus C,
> > > Werner-von-Siemens-Ring 14, D-85630 Grasbrunn
> > > Handelsregister: Amtsgericht München HRB 153243
> > > Geschaeftsführer: Mark Hegarty, Charlie Peters, Michael Cunningham,
> > > Charles Cachera
> > >
> > >
> >
> >
> > > _______________________________________________
> > > rhq-devel mailing list
> > > rhq-devel at lists.fedorahosted.org
> > > https://lists.fedorahosted.org/mailman/listinfo/rhq-devel
> > >
> > _______________________________________________
> > rhq-devel mailing list
> > rhq-devel at lists.fedorahosted.org
> > https://lists.fedorahosted.org/mailman/listinfo/rhq-devel
> >
> >
> > _______________________________________________
> > rhq-devel mailing list
> > rhq-devel at lists.fedorahosted.org
> > https://lists.fedorahosted.org/mailman/listinfo/rhq-devel
> >
> _______________________________________________
> rhq-devel mailing list
> rhq-devel at lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/rhq-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.fedorahosted.org/pipermail/rhq-devel/attachments/20121024/ed77fd07/attachment.html>


More information about the rhq-devel mailing list