So when can one do this? Is there an architectural change in Quantum to
keep track of resources also - effectively act like a controller?
Is there a blueprint on this?
thanks
BIll
On Sun, Aug 12, 2012 at 3:33 PM, Dan Wendlandt wrote:
>
>
> On Thu, Aug 9, 2012 at 6:47 PM, Bill Shetti wrote:
>
On Thu, Aug 9, 2012 at 6:47 PM, Bill Shetti wrote:
> Sorry - catching up.
>
> Makes sense.
>
> So, then theoretically can one instantiate a call to quantum which can
> then intern enable a virtual network (for VXLAN) spanning OVS (Nicira's or
> the public version), and say a vendor specific one
Sorry - catching up.
Makes sense.
So, then theoretically can one instantiate a call to quantum which can then
intern enable a virtual network (for VXLAN) spanning OVS (Nicira's or the
public version), and say a vendor specific one like Cisco N1k?
On Mon, Aug 6, 2012 at 9:25 AM, Dan Wendlandt
On Sat, Aug 4, 2012 at 3:46 PM, Bill Shetti wrote:
> Hi, catching up, and sorry for the request for history... but here it is.
You can see a short explanation of this on the FAQ here:
http://wiki.openstack.org/QuantumDevelopment . Longer explanation below.
>
> What compelled the original dec
Hi, catching up, and sorry for the request for history... but here it is...
What compelled the original decision to be made on enabling only ONE
plugin/backend (whatever you want to call it)?
Ideally you will want to instantiate multiple services from different
vendors etc.
Ueno-san's metaplugin
Ueno
> [na...@nttmcl.com (mailto:na...@nttmcl.com)]
> Sent: Thursday, August 02, 2012 6:53 PM
> To: OpenStack Development Mailing List
> Cc: netstack@lists.launchpad.net (mailto:netstack@lists.launchpad.net)
> Subject: Re: [Netstack] [openstack-dev] [Quantum] plugin -> backend
>
: Thursday, August 02, 2012 6:53 PM
To: OpenStack Development Mailing List
Cc: netstack@lists.launchpad.net
Subject: Re: [Netstack] [openstack-dev] [Quantum] plugin -> backend
2012/8/2 Dan Wendlandt mailto:d...@nicira.com>>
Suffice it to say we're not going to make any drastic changes wit
2012/8/2 Dan Wendlandt
> Suffice it to say we're not going to make any drastic changes with the
> time remaining on F-3, but I think we can talk about this at the Grizzly
> summit.
>
>
I agree. This is reason why I implemented this function my plugin and
extension.
> We actually put a lot of th
Suffice it to say we're not going to make any drastic changes with the time
remaining on F-3, but I think we can talk about this at the Grizzly summit.
We actually put a lot of thought into whether IPAM should have a separate
plugin or not, and decided that the two where so tightly coupled that i
Hi Hua
I agree with you. Current plugin architecture is kind of silo.
My concern is about IPAM and L3.
- IPAM
IPAM plugin and L2 plugin can be different. However it is combined in
current structure.
- L3 function
It needed to be connected each L2 plugin in L3.
They are a reason I'm proposi
just add my cents here.
"Driver" concept make sense to my understaning. The current quantum
underline plugins works and behaves more like network connectivity provider
on top of specific type of device, from hardware and software, from vendors
to open source. You can only enable ONE of it to provi
11 matches
Mail list logo
