[Engine-devel] Bridgeless Networks api design

[Einav Cohen]

> ----- Original Message -----
> From: "Roy Golan" <rgolan at redhat.com>
> Sent: Sunday, March 18, 2012 3:31:46 PM
> 
> ----- Original Message -----
> > From: "Itamar Heim" <iheim at redhat.com>
> > To: "Yaniv Kaul" <ykaul at redhat.com>
> > Cc: engine-devel at 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 at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
>