On Tue, Jan 22, 2013 at 12:06 PM, Edgar Magana <[email protected]> wrote:
> 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. > Actually, I think having L3 as a separate service with its own plugins was really always the plan, in order to support different models of creating "routers" (e.g., agent, VM, physical router, etc.). The mixin approach that tightly coupled L3 to a particular plugin was originally done to get the change in before the Folsom deadline. > So, the day of tomorrow we will have core API for all L2 functionally, the > same for L3, LBaaS, etc. > Yes, this is similar to how I have been thinking abou it, though I would include IPAM with the base L2, since they are tightly coupled. One interesting follow-on question is whether the fact that we allow L3 to be implemented using other plugin dictate that it is not part of the "base" quantum functionality that any tenant can expect from an OpenStack cloud. Essentially, is there any "required" APIs other than the core L2 + IPAM API? The easy answer is "no", but we need to consider whether we are doing a dis-service to OpenStack users by making the guaranteed feature set so skimpy. There's also an interesting corollary which is whether it would be valid to only expose a higher level API (e.g., LBaaS) without the lower level APIs, if the high-level API did not require IDs from the lower-level API. Note: this is somewhat different from the use case where tenants do not have permissions to create/view the lower level API. Dan > > 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<https://launchpad.net/~quantum-core> >> Post to : >> [email protected].**net<[email protected]> >> Unsubscribe : >> https://launchpad.net/~**quantum-core<https://launchpad.net/~quantum-core> >> More help : >> https://help.launchpad.net/**ListHelp<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 > > > -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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
