<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Nov 23, 2016 at 2:59 PM, Arik Hadas <span dir="ltr"><<a href="mailto:ahadas@redhat.com" target="_blank">ahadas@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi All,<br>
<br>
We are working on something that is expected to have a big impact, hence this heads-up.<br>
First, we want you to be aware of this change and provide your feedback to make it as good as possible.<br>
Second, until the proposed mechanism is fully merged there will be a chase to cover all features unless new features are also implemented with the new mechanism. So please, if you are working on something that adds/changes something in the Libvirt's domain xml, do it with this new mechanism as well (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 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 reviewed in 2 projects, this will eliminate the one that tends to take longer.<br>
4. Prevent shortcuts in the form of VDSM-only changes that should be 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 when using vm-leases (need to make sure we're using the up-to-date VM configuration though).<br>
7. We already found improvements and cleanups that could be made while touching this area (e.g., remove the boot order from devices in the database).<br>
<br>
* Challenges<br>
1. Not to move host-specific information to the engine. For example, path 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 next phase.<br>
<br>
* Status<br>
As a first step, we began with producing the Libvirt XML in the engine by 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></blockquote><div><br></div><div>This is an interesting path to take, but centralizing the logic to a single component often limits and does not allow scaling.<br></div><div>A large amount of solutions these days attempt to distribute work, reducing central work to a minimum, but this approach suggests the opposite.<br><br></div><div>In the networking area, from my limited experience, changes are pushed faster to VDSM compared to Engine.<br>In many cases it is just logically simpler: Engine needs to handle and be concern about all the system as a whole, while VDSM just takes care of the host.<br></div><div>Therefore, in my mind, the goal is to distribute as much as possible to the edges, keeping in the centre the minimum required to connect then all together.<br><br></div><div>This approach will remove a conversion and with it an abstraction layer. I find abstraction useful, decoupling components and increasing modularity.<br></div><div>As an example from the OvS integration work, changing the underlying networking implementation should not concern the upper business logic components,<br></div><div>it should be well hidden in the hypervisor, exposing only capabilities and nothing more that hints about the what and how.<br></div><div><br></div><div>Thanks,<br></div><div>Edy.<br></div><div><br></div></div><br></div></div>