Re: [Engine-devel] Bridgeless Networks api design
----- Original Message -----
From: "Roy Golan" <rgolan(a)redhat.com>
Sent: Sunday, March 18, 2012 3:31:46 PM
----- Original Message -----
> From: "Itamar Heim" <iheim(a)redhat.com>
> To: "Yaniv Kaul" <ykaul(a)redhat.com>
> Cc: engine-devel(a)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>
+1 on the last suggestion for representing network usages.
> _______________________________________________
> Engine-devel mailing list
> Engine-devel(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
>
_______________________________________________
Engine-devel mailing list
Engine-devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel