<div dir="ltr"><div><div><div><div>I agree with Piotr&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"><<a href="mailto:msivak@redhat.com" target="_blank">msivak@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">> I like transport abstractions (DTOs) and here we make the libvirt xml<br>
> (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 ("prepareImage" 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>
<<a href="mailto:piotr.kliczewski@gmail.com">piotr.kliczewski@gmail.com</a>> wrote:<br>
> I like transport abstractions (DTOs) and here we make the libvirt xml<br>
> (its structure) part of our communication interface.<br>
> We were never good at evolving our api. Here is [1] recent example of it.<br>
><br>
> I am not against this change but I would like us to think about<br>
> potential changes to this xml. With this approach when change<br>
> happens we would need to change the engine and vdsm code and make sure<br>
> that supported engine/vdsm matrix still work.<br>
><br>
> Will it be possible to have different libvirt versions (different xml<br>
> structure) between version clusters? If so, how are we going to<br>
> handle different xml structure per cluster?<br>
><br>
> Thanks,<br>
> Piotr<br>
><br>
> [1] <a href="https://gerrit.ovirt.org/#/c/67596" rel="noreferrer" target="_blank">https://gerrit.ovirt.org/#/c/<wbr>67596</a><br>
><br>
><br>
> On Thu, Dec 8, 2016 at 11:30 PM, Edward Haas <<a href="mailto:ehaas@redhat.com">ehaas@redhat.com</a>> wrote:<br>
>><br>
>><br>
>> On Wed, Nov 23, 2016 at 2:59 PM, Arik Hadas <<a href="mailto:ahadas@redhat.com">ahadas@redhat.com</a>> wrote:<br>
>>><br>
>>> Hi All,<br>
>>><br>
>>> We are working on something that is expected to have a big impact, hence<br>
>>> this heads-up.<br>
>>> First, we want you to be aware of this change and provide your feedback to<br>
>>> make it as good as possible.<br>
>>> Second, until the proposed mechanism is fully merged there will be a chase<br>
>>> to cover all features unless new features are also implemented with the new<br>
>>> mechanism. So please, if you are working on something that adds/changes<br>
>>> something in the Libvirt's domain xml, do it with this new mechanism as well<br>
>>> (first version would be merged soon).<br>
>>><br>
>>> * Goal<br>
>>> Creating Libvirt XML in the engine rather than in VDSM.<br>
>>> ** Today's flow<br>
>>> Engine: VM business entity -> VM properties map<br>
>>> VDSM: VM properties map -> Libvirt XML<br>
>>> ** Desired flow<br>
>>> Engine: VM business entity -> Libvirt XML<br>
>>><br>
>>> * Potential Benefits<br>
>>> 1. Reduce the number of conversions from 2 to 1, reducing chances for<br>
>>> mistakes in the process.<br>
>>> 2. Reduce the amount of code in VDSM.<br>
>>> 3. Make VM related changes easier - today many of these changes need to be<br>
>>> reviewed in 2 projects, this will eliminate the one that tends to take<br>
>>> longer.<br>
>>> 4. Prevent shortcuts in the form of VDSM-only changes that should be<br>
>>> better reflected in the engine.<br>
>>> 5. Not to re-generate the XML on each rerun attempt of VM run/migration.<br>
>>> 6. Future - not to re-generate the XML on each attempt to auto-start HA VM<br>
>>> when using vm-leases (need to make sure we're using the up-to-date VM<br>
>>> configuration though).<br>
>>> 7. We already found improvements and cleanups that could be made while<br>
>>> touching this area (e.g., remove the boot order from devices in the<br>
>>> database).<br>
>>><br>
>>> * Challenges<br>
>>> 1. Not to move host-specific information to the engine. For example, path<br>
>>> to storage domain or sockets of channels.<br>
>>> The solution is to use place-holders that will be replaced by VDSM.<br>
>>> 2. Backward compatibility.<br>
>>> 3. The more challenging part is the other direction - that will be the<br>
>>> next phase.<br>
>>><br>
>>> * Status<br>
>>> As a first step, we began with producing the Libvirt XML in the engine by<br>
>>> converting the VM properties map to XML in the engine [1]<br>
>>> And using the XML that is received as an input in VDSM [2]<br>
>>><br>
>>><br>
>>> [1] <a href="https://gerrit.ovirt.org/#/c/64473/" rel="noreferrer" target="_blank">https://gerrit.ovirt.org/#/c/<wbr>64473/</a><br>
>>> [2] <a href="https://gerrit.ovirt.org/#/c/65182/" rel="noreferrer" target="_blank">https://gerrit.ovirt.org/#/c/<wbr>65182/</a><br>
>>><br>
>>> Regards,<br>
>>> Arik<br>
>><br>
>><br>
>> This is an interesting path to take, but centralizing the logic to a single<br>
>> component often limits and does not allow scaling.<br>
>> A large amount of solutions these days attempt to distribute work, reducing<br>
>> central work to a minimum, but this approach suggests the opposite.<br>
>><br>
>> In the networking area, from my limited experience, changes are pushed<br>
>> faster to VDSM compared to Engine.<br>
>> In many cases it is just logically simpler: Engine needs to handle and be<br>
>> concern about all the system as a whole, while VDSM just takes care of the<br>
>> host.<br>
>> Therefore, in my mind, the goal is to distribute as much as possible to the<br>
>> edges, keeping in the centre the minimum required to connect then all<br>
>> together.<br>
>><br>
>> This approach will remove a conversion and with it an abstraction layer. I<br>
>> find abstraction useful, decoupling components and increasing modularity.<br>
>> As an example from the OvS integration work, changing the underlying<br>
>> networking implementation should not concern the upper business logic<br>
>> components,<br>
>> it should be well hidden in the hypervisor, exposing only capabilities and<br>
>> nothing more that hints about the what and how.<br>
>><br>
>> Thanks,<br>
>> Edy.<br>
>><br>
>><br>
>><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>
> ______________________________<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>
______________________________<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>