[one-users] [one-ecosystem] Custom monitoring attributes in VM TEMPLATE

Ruben S. Montero rsmontero at opennebula.org
Thu Apr 25 03:23:13 PDT 2013


Hi Simon

The criteria is that every thing to be consumed by OpenNebula should be in
the Template, so the user can not modify it. Otherwise it may lead to
OpenNebula incorrectly manage the object (e.g. remove or modify an
attribute from the DISK section) or a security threat (e.g. a user
modifying the SOURCE attribute to access someone else's image ) That is the
main reason to place the system generated information in the TEMPLATE
section, including monitoring info (you may bypass a billing system based
on a probe).

You are right that ERROR should be moved to USER TEMPLATE. The user may
want to delete the error once she is notified... I've opened an issue for
this [1]

Now the other probes. This is for historical reasons. First versions of
OpenNebula 1.0 (4 years ago!) did not have the functionality that we have
now, and that lead to some inconsistencies in the data model. Probably CPU,
NETRX... and the other probe results should be placed probably under a
MONITOR section. During the development of the project we've opted to keep
backwards compatibility over a more consistent data model. Probably we are
wrong, but trying to keep the ecosystem and other adaption working from one
release to other has been a priority for us.

You've raised other interesting issue. First, we are sorry if we failed to
engage in any discussion about the implementation of new issues. This is by
no means because of a lack of interest but for the trillions of things we
have to deal with. Your feedback is very valuable for us and always
considered internally even if we fail to answer it.

I'd say that comments to issues in redmine is a good place to link the
discussions to specific features, new things and general aspects should go
to the mailing list.

However, this is probably not as fluent and agile as it should. We've done
in the past IRC meetings that we may restore plan a regular hangout for
example. We'll work on this and send a proposal to the mailing list.

Thank you very much for feedback!

[1] http://dev.opennebula.org/issues/1955




On Wed, Apr 24, 2013 at 4:24 PM, Simon Boulet <simon at nostalgeek.com> wrote:

> Hi,
>
> Custom monitoring attributes (extra attributes returned by the IM MONITOR
> or VMM POLL) are currently being added under the TEMPLATE section of the VM
> definition (from vm/VirtualMachine.cc:3165)
>
> Perhaps I'm wrong, but I am seeing the TEMPLATE section a block that
> containt the "static" definition of the VM (number of CPU, maximum memory,
> attached NICs, Disks, etc.). Ex. one could cache the information found in
> the TEMPLATE section on their frontend for a certain period of time. And it
> starts to make even more sense now that we have a USER_TEMPLATE section
> (since OpenNebula 4.0).
>
> Also errors are added under the TEMPLATE section.
>
> Wouldn't it make more sense if the custom monitoring attributes (and
> errors) were being reported directly under the VM section (just like the
> other monitoring attributes NETRX, NETTX, etc. are being reported).
>
> PS. Not sure if the ecosystem list is the right place for this. In the
> past I used the users list as well as the bug tracker to submit technical
> questions and discussions. And I find it difficult to be informed, sharing
> the vision and debating some implementations of upcoming features in
> OpenNebula.
>
> Simon
>
> _______________________________________________
> Ecosystem mailing list
> Ecosystem at lists.opennebula.org
> http://lists.opennebula.org/listinfo.cgi/ecosystem-opennebula.org
>
>


-- 
Ruben S. Montero, PhD
Project co-Lead and Chief Architect
OpenNebula - The Open Source Solution for Data Center Virtualization
www.OpenNebula.org | rsmontero at opennebula.org | @OpenNebula
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opennebula.org/pipermail/users-opennebula.org/attachments/20130425/97aace75/attachment-0001.htm>


More information about the Users mailing list