----- Original Message -----
From: "Itamar Heim" <iheim@redhat.com> To: "Yaniv Kaul" <ykaul@redhat.com> Cc: engine-devel@ovirt.org Sent: Sunday, March 18, 2012 2:31:45 PM Subject: Re: [Engine-devel] Bridgeless Networks api design
On 03/18/2012 11:27 AM, Yaniv Kaul wrote:
On 03/18/2012 10:43 AM, Michael Pasternak wrote:
On 03/18/2012 10:21 AM, Itamar Heim wrote:
On 03/18/2012 09:33 AM, Michael Pasternak wrote:
the question is Management/Migration/Storage/Display can be non-bridged?, if so, <bridged>true|false</bridged> makes sense. bridge is an implementation detail at host level, hence the discussion is about abstracting it from users. a VM network doesn't have to have bridge at host level, for networks using VMFex or SR-IOV <network> <designation>Management|Migration|Storage|Display|VM</designation> </network>
what do you say about having it as another /designation/ type?
Not sure I understand: Management can be bridge-less, Migration can be bridge-less, Storage can be bridge-less, Display can be bridge-less, VM is the only that perhaps today cannot be bridge-less, so I do think that '<bridged>true|false</bridged>' makes some sense. However, I'd generalize it to 'attachment' as I believe we'll have other types in the future (Macvtap, SRIOV and friends), so something like <attachment>bridge|sriov|macvtap|...</attachment> Y.
attachment would be at physical host level and could vary from host to host. this is about intended allowed usages of the logical network across the system
we should probably have a set of, so called, "usages" and not a single one. It should give enough flexibility for future usages with an easy upgrade. something like: <network> <usages>management,display,VM</usages> <network> or: <network> <usages> <usage>management</usage> <usage>display</usage> <usage>VM</usage> </usages> </network>
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel