----- Original Message ----- > From: "Itamar Heim" <[email protected]> > To: "Yaniv Kaul" <[email protected]> > Cc: [email protected] > 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 > [email protected] > http://lists.ovirt.org/mailman/listinfo/engine-devel > _______________________________________________ Engine-devel mailing list [email protected] http://lists.ovirt.org/mailman/listinfo/engine-devel
