Mechanism for guest edits

Folks, I'm about to send a patch to you guys that: 1) adds "serial" as a graphics type 2) allows you to edit the graphics type on a cold guest In doing so and talking with Adam and Aline, it seems that a rework of how the guest's xml is edited is in order. When you edit a template, for example, the whole templates xml is basically re-instantiated and only the values that kimchi cares about is added. The rest libvirt fills in. The editing of guest xmls differs from that mechanism. Right now the actual xml is edited and resubmitted. If you think about editing components of a guest (think about changing graphics types), you can see where long-term there is an increased opportunity for the xml to become complicated and maybe even incorrect. XML creep if you will. So, we are thinking that the cold guest edition should more closely follow how the template works, where critical parts that kimchi has fields for is inserted and libvirt does the rest of the work. This will also allow for future growth/change where new components are added. I'll likely start a branch for it and get started on this. In the meanwhile, I'll submit my graphics patches for a start. Brent

On 2014年08月29日 04:52, Brent Baude wrote:
Folks,
I'm about to send a patch to you guys that:
1) adds "serial" as a graphics type 2) allows you to edit the graphics type on a cold guest
In doing so and talking with Adam and Aline, it seems that a rework of how the guest's xml is edited is in order. When you edit a template, for example, the whole templates xml is basically re-instantiated and only the values that kimchi cares about is added. The rest libvirt fills in.
The editing of guest xmls differs from that mechanism. Right now the actual xml is edited and resubmitted. If you think about editing components of a guest (think about changing graphics types), you can see where long-term there is an increased opportunity for the xml to become complicated and maybe even incorrect. XML creep if you will.
So, we are thinking that the cold guest edition should more closely follow how the template works, where critical parts that kimchi has fields for is inserted and libvirt does the rest of the work. This will also allow for future growth/change where new components are added. Hi Brent,
Thanks for contributing your ideas and patches! Do you mean undefine the old one then generate and define a new one with the updated xml? Is that mean common params dict+updated param=a dict for xml generation? If so, I'm wandering if we need to store two copies of metadata for a vm-- one from kimchi, another is libvirt xml?
I'll likely start a branch for it and get started on this. In the meanwhile, I'll submit my graphics patches for a start.
Brent
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
participants (2)
-
Brent Baude
-
Royce Lv