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

Simon Boulet simon at nostalgeek.com
Thu Apr 25 09:18:01 PDT 2013

Hi Ruben

I like the idea of placing the monitoring information under a MONITOR

I'm looking at scaling OpenNebula and adding some caching, having the
TEMPLATE section to be static  where the information would change only ex.
when a VM resize operation is done (or at least, not being updated each
time the VM is monitored). One could identify each sections "lifetime" ex. :

USER_TEMPLATE = updated on vm.update or when a VM action fails (and the
ERROR attribute is updated)
TEMPLATE = updated on vm.resize, attach, detach, etc. operation
MONITOR = updated on each poll (typically LASTPOLL + MONITORING_INTERVAL in
oned.conf.. perhaps add a NEXTPOLL attribute to make caching lifetime
HISTORY_RECORDS = updated on VM state changes (one.vm.action) etc.

Then perhaps vm.vmpool could return only the base <VM> attributes (nothing
below the USER_TEMPLATE, TEMPLATE, MONITOR) and one would have to call
one.vm.info to retrieve the full VM XML.

I understand that would break backward compatibility. But I think it would
be a huge improvement to ease caching of the OpenNebula information.

> 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.

Users or ecosystem list?


On Thu, Apr 25, 2013 at 6:23 AM, Ruben S. Montero
<rsmontero at opennebula.org>wrote:

> 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/c49510b6/attachment-0001.htm>

More information about the Users mailing list