On 01/21/2013 05:51 PM, Salvatore Orlando wrote:
Hi Gary,
Some more comments inline.
Thanks,
Salvatore
On 21 January 2013 14:01, 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.
Code wise this is not a big deal. It's pretty much refactoring and optimization.
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.
Sure. I can anticipate a diff size of about 1,000 lines (more or less
+600/-400).
Not small, but neither extremely big. The code however has changes in
all plugins, even if small.
I unfortunately have little to no idea about how it would take to add
L3 support to the other two plugins.
Hopefully their maintainer will chime in; however if there are no
plans to add this support there's little we can do.
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).
Yes, I considered it. We do the same for bulk support, and we are
going to do the same for pagination.
But in these cases we offer API 'emulation' of the feature, so users
will have a consistent experience.
One of the purposes of the core API is to have a small subset of
features which is guaranteed to be portable - and this would hardly be
true if some API operations might raise NotImplemented.
Agreed.
Still, mimicking what we've done with bulk ops and pagination, we can
optimize the db layer assuming most plugins do support l3 extension,
leaving the API layer as it is. The drawback of this is that there
will be only a single unused db attribute (external on networks), for
plugins not supporting l3.
Then we can complete the work with the API layer for the 'H' release.
Maybe we should discuss this at the meeting this evening.
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
--
Mailing list: https://launchpad.net/~quantum-core
Post to : [email protected]
Unsubscribe : https://launchpad.net/~quantum-core
More help : https://help.launchpad.net/ListHelp
