Hi,
I have performed a review of the API specification in order to make it as
compliant as possible with the convention of the Openstack API specification.
Moreover, for each operation I have added samples of request and response
objects, in order to give a clear picture of what should be suppli
> Ok, If it doesn't break backward compatibility, which it doesn't seem to do,
> I have no issue with this change.
It did. At least it required a new options parameter of the __init__ method of
the plugin.
I updated the branch and restored quantum_plugin_base as it was before.
In the future, if
Review: Approve netstack-core
Great work Salvatore! We are getting there. I am approving this for merge to
trunk as this branch is definitely a step in the right direction.
--
https://code.launchpad.net/~netstack/quantum/quantum-unit-tests/+merge/68308
Your team Netstack is subscribed to branch
The proposal to merge lp:~netstack/quantum/quantum-unit-tests into lp:quantum
has been updated.
Status: Needs review => Approved
For more details, see:
https://code.launchpad.net/~netstack/quantum/quantum-unit-tests/+merge/68308
--
https://code.launchpad.net/~netstack/quantum/quantum-unit-t
Hi Rajaram,
I'm working on Cisco's API extensions by using the extension framework
and have some questions. Hope to get your help.
1. If our plug-in requires multiple extensions, we just need to
list all of those aliases in supports_extension() function in the
plug-in, right?
2. T
Hi Ying,
1. You are right. Extension aliases would be the way plugins would advertise
the extensions they support. Right now to support multiple plugins you would
have to do something like this:
class SomePlugin :
...
def supports_extension(self, extension):
if extension.a
6 matches
Mail list logo
