Re: [openstack-dev] [neutron] - L3 flavors and issues with use cases for multiple L3 backends

On 01/02/16 14:11, Kevin Benton wrote: > Hi all, > > I've been working on an implementation of the multiple L3 backends > RFE[1] using the flavor framework and I've run into some snags with the > use-cases.[2] Is there any good documentation for flavors yet? I recall looking unsuccessfully, a

Re: [openstack-dev] [neutron] - L3 flavors and issues with use cases for multiple L3 backends

Not that you could call it scheduling. The intent was that the user could pick the best flavor for his task (e.g. a gold router as opposed to a silver one). The system then would “schedule” the driver configured for gold or silver. Rescheduling wasn’t really a consideration… German From: Doug

Re: [openstack-dev] [neutron] - L3 flavors and issues with use cases for multiple L3 backends

Choosing from multiple drivers for the same flavor is scheduling. I didn't mean automatically selecting other flavors. On Feb 2, 2016 17:53, "Eichberger, German" wrote: > Not that you could call it scheduling. The intent was that the user could > pick the best flavor

[openstack-dev] [neutron] - L3 flavors and issues with use cases for multiple L3 backends

Hi all, I've been working on an implementation of the multiple L3 backends RFE[1] using the flavor framework and I've run into some snags with the use-cases.[2] The first use cases are relatively straightforward where the user requests a specific flavor and that request gets dispatched to a

Re: [openstack-dev] [neutron] - L3 flavors and issues with use cases for multiple L3 backends

Yes, scheduling was a big gnarly wart that was punted for the first pass. The intention was that any driver you put in a single flavor had equivalent capabilities/plumbed to the same networks/etc. doug > On Feb 1, 2016, at 7:08 AM, Kevin Benton wrote: > > Hi all, > >