<div dir="ltr"><br><div class="gmail_extra">Hi<br><br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div dir="ltr"><div>
<br></div><div>USER_TEMPLATE = updated on vm.update or when a VM action fails (and the ERROR attribute is updated)</div><div>TEMPLATE = updated on vm.resize, attach, detach, etc. operation</div><div>MONITOR = updated on each poll (typically LASTPOLL + MONITORING_INTERVAL in oned.conf.. perhaps add a NEXTPOLL attribute to make caching lifetime easier)</div>
<div>HISTORY_RECORDS = updated on VM state changes (one.vm.action) etc.</div></div></blockquote><div><br></div><div> Exactly that would be perfect! </div><div><br></div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div></div><div><br></div><div>Then perhaps vm.vmpool could return only the base <VM> attributes (nothing below the USER_TEMPLATE, TEMPLATE, MONITOR) and one would have to call <a href="http://one.vm.info" target="_blank">one.vm.info</a> to retrieve the full VM XML.</div>
</div></blockquote><div><br></div><div>As the DB is structured in XML blobs it is in fact faster for the oned daemon to deliver the whole thing and let the clients parse the XML.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div dir="ltr">
<div><br></div><div>I understand that would break backward compatibility. But I think it would be a huge improvement to ease caching of the OpenNebula information.<br></div></div></blockquote><div><br></div><div style>This has been a long debate within the team. If we go for this:</div>
<div style><br></div><div style>1.- This can not happen in the 4.0 timeframe as we are just fixing the last bugs and this would require touching to many parts now. 4.0 would be the perfect release as we are changing major...</div>
<div style><br></div><div style>2.- I think we can fix something in the onedb upgrade process to restructure the xml's </div><div style><br></div><div style>3.- This would only impact on custom applications on top of OpenNebula</div>
<div style><br></div><div style>4.- As we are sending the whole XML, probably we would not help on the caching...</div><div style><br></div><div style>5.- We need to address similar situations in other objects e.g.. <MONITOR> in hosts...</div>
<div style><br></div><div style>Let's go like this:</div><div style><br></div><div style>1.- I've created an issue <a href="http://dev.opennebula.org/issues/1967">http://dev.opennebula.org/issues/1967</a></div><div style>
<br></div><div style>2.- We'll add a proposal there with the changes</div><div style><br></div><div style>3.- Then we can discuss if we want this change or not... if it'll break to many things...</div><div> </div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div></div><div><div><br></div><div>> <span style="font-family:arial,sans-serif;font-size:13.333333969116211px">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. </span></div>
<div><span style="font-family:arial,sans-serif;font-size:13.333333969116211px"><br></span></div></div><div><span style="font-family:arial,sans-serif;font-size:13.333333969116211px">Users or ecosystem list?</span></div></div>
</blockquote><div><br></div><div><br></div><div style>Users</div><div style><br></div><div style><br></div><div style>Ruben </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div dir="ltr"><span><font color="#888888"><div>
<span style="font-family:arial,sans-serif;font-size:13.333333969116211px"><br></span></div><div><span style="font-family:arial,sans-serif;font-size:13.333333969116211px">Simon</span></div></font></span></div><div>
<div><div class="gmail_extra">
<br><br><div class="gmail_quote">On Thu, Apr 25, 2013 at 6:23 AM, Ruben S. Montero <span dir="ltr"><<a href="mailto:rsmontero@opennebula.org" target="_blank">rsmontero@opennebula.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div dir="ltr">Hi Simon<div><br></div><div>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).</div>
<div><br></div><div>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]</div><div><br></div><div>
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.</div>
<div><br></div><div>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. </div>
<div><br></div><div>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. </div><div>
<br>
</div><div>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.</div>
<div><br></div><div>Thank you very much for feedback!</div><div><br></div><div>[1] <a href="http://dev.opennebula.org/issues/1955" target="_blank">http://dev.opennebula.org/issues/1955</a></div><div><br></div>
<div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote"><div><div>On Wed, Apr 24, 2013 at 4:24 PM, Simon Boulet <span dir="ltr"><<a href="mailto:simon@nostalgeek.com" target="_blank">simon@nostalgeek.com</a>></span> wrote:<br>
</div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div><div><div dir="ltr">Hi,<div><br></div><div>
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)</div>
<div><br></div><div>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).<br>
</div><div><br></div><div>Also errors are added under the TEMPLATE section.</div><div><div><br></div><div>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).</div>
<div> <br></div><div>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.</div>
</div><div><br></div><div>Simon</div></div>
<br></div></div>_______________________________________________<br>
Ecosystem mailing list<br>
<a href="mailto:Ecosystem@lists.opennebula.org" target="_blank">Ecosystem@lists.opennebula.org</a><br>
<a href="http://lists.opennebula.org/listinfo.cgi/ecosystem-opennebula.org" target="_blank">http://lists.opennebula.org/listinfo.cgi/ecosystem-opennebula.org</a><br>
<br></blockquote></div><span><font color="#888888"><br><br clear="all"><div><br></div>-- <br>Ruben S. Montero, PhD<br>Project co-Lead and Chief Architect<br>OpenNebula - The Open Source Solution for Data Center Virtualization<br>
<a href="http://www.OpenNebula.org" target="_blank">www.OpenNebula.org</a> | <a href="mailto:rsmontero@opennebula.org" target="_blank">rsmontero@opennebula.org</a> | @OpenNebula
</font></span></div>
</blockquote></div><br></div>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br>Ruben S. Montero, PhD<br>Project co-Lead and Chief Architect<br>OpenNebula - The Open Source Solution for Data Center Virtualization<br><a href="http://www.OpenNebula.org" target="_blank">www.OpenNebula.org</a> | <a href="mailto:rsmontero@opennebula.org" target="_blank">rsmontero@opennebula.org</a> | @OpenNebula
</div></div>