<div dir="ltr"><div><div><div><div>I agree with Piotr&amp;Edward:<br><ul><li>having engine uses 
libvirt xml would impose coupling between engine and libvirt (a 
cross-layers dependency), which currently does not exist.</li><li>moreover,
 engine would be coupled to all versions of libvirt api that it manages -
 currently each VDSM version knows how to interact with libvirt it uses 
(de-centralized approach)<br></li><li>currently we do not have a 
mechanism that ensures libvirt version based on cluster level (IMHO). 
Ensuring that would imply requesting a very specific version of libvirt 
by VDSM.</li><li>cluster version means a minimum level of compatibility,
 but what if cluster of version (x.y) contains a host of a newer version
 (x+1.y+2). What would be able to tell about libvirt it uses?</li></ul></div></div><br></div>Regards,<br></div>Yevgeny</div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Dec 9, 2016 at 12:58 PM, Martin Sivak <span dir="ltr">&lt;<a href="mailto:msivak@redhat.com" target="_blank">msivak@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"><span class="">&gt; I like transport abstractions (DTOs) and here we make the libvirt xml<br>
&gt; (its structure) part of our communication interface.<br>
<br>
</span>I agree, but only partially. We can have a DTO for this, but we need a<br>
library to convert from/to it. Hosted engine has to duplicate the<br>
current Java code as it has to convert the OVF to the format vdsm is<br>
expecting. And that is very error prone. Getting the domain XML from<br>
the engine and using it directly would solve a lot of bugs we have. Or<br>
alternatively the ability to send the OVF to vdsm without<br>
preprocessing.<br>
<br>
On the other hand, the logic we have in vdsm is not that complicated<br>
and we could move it to the engine, because we have (almost) all the<br>
information there as well. The (complicated) logic needed to use vdsm<br>
verbs is part of engine anyway and I am constantly under pressure to<br>
not use (for example from virt) the verbs directly. It does not make<br>
sense to maintain the current separation in the situation where there<br>
is tight coupling anyway.<br>
<br>
This whole discussion will boil to a simple point eventually: What is<br>
the role of vdsm and how dumb is it supposed to be in the future (it<br>
is pretty dumb currently.. just a conversion proxy + monitoring, at<br>
least in areas I am concerned about). I would like slightly smarter<br>
vdsm with engine acting only as the high level boss, without the<br>
micromanaging of storage verbs for example.<br>
<br>
TLDR; I would like to get data from storage (currently OVF) and pass<br>
them to vdsm without any preprocessing. Separation is not a bad idea,<br>
but we currently have three different formats with no clear rules for<br>
conversion. I would also like to have slightly more high level API in<br>
vdsm (&quot;prepareImage&quot; should make sure domain monitor is up, domain is<br>
mounted and so on.. I do not want to micromanage that).<br>
<span class="HOEnZb"><font color="#888888"><br>
Martin<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
On Fri, Dec 9, 2016 at 11:39 AM, Piotr Kliczewski<br>
&lt;<a href="mailto:piotr.kliczewski@gmail.com">piotr.kliczewski@gmail.com</a>&gt; wrote:<br>
&gt; I like transport abstractions (DTOs) and here we make the libvirt xml<br>
&gt; (its structure) part of our communication interface.<br>
&gt; We were never good at evolving our api. Here is [1] recent example of it.<br>
&gt;<br>
&gt; I am not against this change but I would like us to think about<br>
&gt; potential changes to this xml. With this approach when change<br>
&gt; happens we would need to change the engine and vdsm code and make sure<br>
&gt; that supported engine/vdsm matrix still work.<br>
&gt;<br>
&gt; Will it be possible to have different libvirt versions (different xml<br>
&gt; structure) between version clusters? If so, how are we going to<br>
&gt; handle different xml structure per cluster?<br>
&gt;<br>
&gt; Thanks,<br>
&gt; Piotr<br>
&gt;<br>
&gt; [1] <a href="https://gerrit.ovirt.org/#/c/67596" rel="noreferrer" target="_blank">https://gerrit.ovirt.org/#/c/<wbr>67596</a><br>
&gt;<br>
&gt;<br>
&gt; On Thu, Dec 8, 2016 at 11:30 PM, Edward Haas &lt;<a href="mailto:ehaas@redhat.com">ehaas@redhat.com</a>&gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; On Wed, Nov 23, 2016 at 2:59 PM, Arik Hadas &lt;<a href="mailto:ahadas@redhat.com">ahadas@redhat.com</a>&gt; wrote:<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Hi All,<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; We are working on something that is expected to have a big impact, hence<br>
&gt;&gt;&gt; this heads-up.<br>
&gt;&gt;&gt; First, we want you to be aware of this change and provide your feedback to<br>
&gt;&gt;&gt; make it as good as possible.<br>
&gt;&gt;&gt; Second, until the proposed mechanism is fully merged there will be a chase<br>
&gt;&gt;&gt; to cover all features unless new features are also implemented with the new<br>
&gt;&gt;&gt; mechanism. So please, if you are working on something that adds/changes<br>
&gt;&gt;&gt; something in the Libvirt&#39;s domain xml, do it with this new mechanism as well<br>
&gt;&gt;&gt; (first version would be merged soon).<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; * Goal<br>
&gt;&gt;&gt; Creating Libvirt XML in the engine rather than in VDSM.<br>
&gt;&gt;&gt; ** Today&#39;s flow<br>
&gt;&gt;&gt; Engine: VM business entity -&gt; VM properties map<br>
&gt;&gt;&gt; VDSM:   VM properties map  -&gt; Libvirt XML<br>
&gt;&gt;&gt; ** Desired flow<br>
&gt;&gt;&gt; Engine: VM business entity -&gt; Libvirt XML<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; * Potential Benefits<br>
&gt;&gt;&gt; 1. Reduce the number of conversions from 2 to 1, reducing chances for<br>
&gt;&gt;&gt; mistakes in the process.<br>
&gt;&gt;&gt; 2. Reduce the amount of code in VDSM.<br>
&gt;&gt;&gt; 3. Make VM related changes easier - today many of these changes need to be<br>
&gt;&gt;&gt; reviewed in 2 projects, this will eliminate the one that tends to take<br>
&gt;&gt;&gt; longer.<br>
&gt;&gt;&gt; 4. Prevent shortcuts in the form of VDSM-only changes that should be<br>
&gt;&gt;&gt; better reflected in the engine.<br>
&gt;&gt;&gt; 5. Not to re-generate the XML on each rerun attempt of VM run/migration.<br>
&gt;&gt;&gt; 6. Future - not to re-generate the XML on each attempt to auto-start HA VM<br>
&gt;&gt;&gt; when using vm-leases (need to make sure we&#39;re using the up-to-date VM<br>
&gt;&gt;&gt; configuration though).<br>
&gt;&gt;&gt; 7. We already found improvements and cleanups that could be made while<br>
&gt;&gt;&gt; touching this area (e.g., remove the boot order from devices in the<br>
&gt;&gt;&gt; database).<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; * Challenges<br>
&gt;&gt;&gt; 1. Not to move host-specific information to the engine. For example, path<br>
&gt;&gt;&gt; to storage domain or sockets of channels.<br>
&gt;&gt;&gt;    The solution is to use place-holders that will be replaced by VDSM.<br>
&gt;&gt;&gt; 2. Backward compatibility.<br>
&gt;&gt;&gt; 3. The more challenging part is the other direction - that will be the<br>
&gt;&gt;&gt; next phase.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; * Status<br>
&gt;&gt;&gt; As a first step, we began with producing the Libvirt XML in the engine by<br>
&gt;&gt;&gt; converting the VM properties map to XML in the engine [1]<br>
&gt;&gt;&gt; And using the XML that is received as an input in VDSM [2]<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; [1] <a href="https://gerrit.ovirt.org/#/c/64473/" rel="noreferrer" target="_blank">https://gerrit.ovirt.org/#/c/<wbr>64473/</a><br>
&gt;&gt;&gt; [2] <a href="https://gerrit.ovirt.org/#/c/65182/" rel="noreferrer" target="_blank">https://gerrit.ovirt.org/#/c/<wbr>65182/</a><br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Regards,<br>
&gt;&gt;&gt; Arik<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; This is an interesting path to take, but centralizing the logic to a single<br>
&gt;&gt; component often limits and does not allow scaling.<br>
&gt;&gt; A large amount of solutions these days attempt to distribute work, reducing<br>
&gt;&gt; central work to a minimum, but this approach suggests the opposite.<br>
&gt;&gt;<br>
&gt;&gt; In the networking area, from my limited experience, changes are pushed<br>
&gt;&gt; faster to VDSM compared to Engine.<br>
&gt;&gt; In many cases it is just logically simpler: Engine needs to handle and be<br>
&gt;&gt; concern about all the system as a whole, while VDSM just takes care of the<br>
&gt;&gt; host.<br>
&gt;&gt; Therefore, in my mind, the goal is to distribute as much as possible to the<br>
&gt;&gt; edges, keeping in the centre the minimum required to connect then all<br>
&gt;&gt; together.<br>
&gt;&gt;<br>
&gt;&gt; This approach will remove a conversion and with it an abstraction layer. I<br>
&gt;&gt; find abstraction useful, decoupling components and increasing modularity.<br>
&gt;&gt; As an example from the OvS integration work, changing the underlying<br>
&gt;&gt; networking implementation should not concern the upper business logic<br>
&gt;&gt; components,<br>
&gt;&gt; it should be well hidden in the hypervisor, exposing only capabilities and<br>
&gt;&gt; nothing more that hints about the what and how.<br>
&gt;&gt;<br>
&gt;&gt; Thanks,<br>
&gt;&gt; Edy.<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; ______________________________<wbr>_________________<br>
&gt;&gt; Devel mailing list<br>
&gt;&gt; <a href="mailto:Devel@ovirt.org">Devel@ovirt.org</a><br>
&gt;&gt; <a href="http://lists.phx.ovirt.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.phx.ovirt.org/<wbr>mailman/listinfo/devel</a><br>
&gt; ______________________________<wbr>_________________<br>
&gt; Devel mailing list<br>
&gt; <a href="mailto:Devel@ovirt.org">Devel@ovirt.org</a><br>
&gt; <a href="http://lists.phx.ovirt.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.phx.ovirt.org/<wbr>mailman/listinfo/devel</a><br>
______________________________<wbr>_________________<br>
Devel mailing list<br>
<a href="mailto:Devel@ovirt.org">Devel@ovirt.org</a><br>
<a href="http://lists.phx.ovirt.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.phx.ovirt.org/<wbr>mailman/listinfo/devel</a><br>
</div></div></blockquote></div><br></div>