Hi Folks, The first thing that I want to mention here is that I am not any longer part of Cisco. I recently joined a startup called PLUMgrid. Kyle Mestery is the contact point for all Cisco-related action items.
About this discussion, I want to bring to the table a different point of view and this is a bout services. Do you see L3 as a network service? I do and I believe we should start thinking about plugins for different services and then splitting Quantum APIs into different areas, basically per services. I believe this is a good way to scale up. So, the day of tomorrow we will have core API for all L2 functionally, the same for L3, LBaaS, etc. Any thoughts? Thanks, Edgar On Jan 21, 2013, at 11:28 AM, Dan Wendlandt <[email protected]> wrote: > Its interesting, as there are really several aspects of "core" when you tease > it apart: > > 1) the bare minimum API required to be a "quantum" install. > 2) a stable API that we expect to remain unchanged moving forward (i.e., no > removals, and any additions are separate extensions) > 3) included as part of the "standard" setup in admin documentation. > > My feeling is that we definitely want #2 and #3 for grizzly, but that there > are reasonable arguments against #1. > > I have a feeling we will see this more moving forward. For example, once we > have stabalized the lbaas APIs, we will want to indicate what is the core > portion of that API, and document that. However, there obviously won't be a > requirement that all quantum deployments expose that API. > > The root cause here seems to be that the designation of an "extension" can > mean anything from a one-off API change for a particular plugin/technology to > a very common API that is usually (but not always) used. > > We could go the route of including these items in core once "most" backends > implement it, forcing non-compliant plugins to implement less than the full > core API and return "unsupported". > > The other alternative would be to have a notion of "community supported > extensions", which effectively represent the set of extensions that are > managed by the community as if they were a core API, but are not strictly > required to be a part of a quantum deployment. > > One advantage of the extensions approach is that there is already a > standardized way for the user to query quantum about what extensions it > supports, enabling a user for example, to see if the l3 and lbaas apis are > implemented on a particular quantum endpoint. The alternative is somewhat > messier of forcing the user to make each type of call, and checking whether > the create succeeds or fails with an unsupported. > > I'll add this to the agenda for today's meeting. > > Dan > > > > > On Mon, Jan 21, 2013 at 6:01 AM, Gary Kotton <[email protected]> wrote: > On 01/21/2013 03:30 PM, Salvatore Orlando wrote: > Hi guys, > > while I am doing progress on the implementation of this blueprint, I > realized something which might be a blocker for it. > It seems indeed that the bigswitch and cisco plugins do not support > the L3 APIs; moving them into core will therefore violate one of > Quantum principles, ie: the core API should be the smallest set of > APIs supported by all the plugins. > > The NVP plugin has the same issue, but this is currently being > addressed by another blueprint targeting Grizzly-3. > I think Sumit and Edgar are respectively the maintainers for these > plugins; at a first glance I do not see plans for adding Layer-3 > support in the Grizzly release. > If that is the case, I suggest postponing moving l3 apis into Quantum > core to the next release, just as we did for the provider networks > API. > > What are your thoughts? > > I think that we are between a rock and a hard place. It would be great if the > aforementioned could be moved into the core API. I think that there are a > number of areas that we need to address: > 1. timing > 2. plugin support > > Regarding the timing the sooner in a series that this is done the better. If > we decide to go ahead with this in this cycle then we will need to make sure > that we have the resources allocated to review and test. > The plugin support is interesting and challenging. An alternative that may be > worth considering is moving it to the core and return "NotSupported" if the > plugin does not support the API (this can be done via a configuration > variable). > > Thanks > Gary > > > > Regards, > Salvatore > > > > -- > Mailing list: https://launchpad.net/~quantum-core > Post to : [email protected] > Unsubscribe : https://launchpad.net/~quantum-core > More help : https://help.launchpad.net/ListHelp > > > > -- > ~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Dan Wendlandt > Nicira, Inc: www.nicira.com > twitter: danwendlandt > ~~~~~~~~~~~~~~~~~~~~~~~~~~~ > -- > Mailing list: https://launchpad.net/~quantum-core > Post to : [email protected] > Unsubscribe : https://launchpad.net/~quantum-core > More help : https://help.launchpad.net/ListHelp
-- Mailing list: https://launchpad.net/~quantum-core Post to : [email protected] Unsubscribe : https://launchpad.net/~quantum-core More help : https://help.launchpad.net/ListHelp
