On 5/23/14, 12:46 AM, Mandeep Dhami wrote:
Hi Armando:
Those are good points. I will let Bob Kukura chime in on the specifics
of how we intend to do that integration. But if what you see in the
prototype/PoC was our final design for integration with Neutron core,
I would be worried about that too. That specific part of the code
(events/notifications for DHCP) was done in that way just for the
prototype - to allow us to experiment with the part that was new and
needed experimentation, the APIs and the model.
That is the exact reason that we did not initially check the code to
gerrit - so that we do not confuse the review process with the
prototype process. But we were requested by other cores to check in
even the prototype code as WIP patches to allow for review of the API
parts. That can unfortunately create this very misunderstanding. For
the review, I would recommend not the WIP patches, as they contain the
prototype parts as well, but just the final patches that are not
marked WIP. If you such issues in that part of the code, please DO
raise that as that would be code that we intend to upstream.
I believe Bob did discuss the specifics of this integration issue with
you at the summit, but like I said it is best if he represents that
side himself.
Armando and Mandeep,
Right, we do need a workable solution for the GBP driver to invoke
neutron API operations, and this came up at the summit.
We started out in the PoC directly calling the plugin, as is currently
done when creating ports for agents. But this is not sufficient because
the DHCP notifications, and I think the nova notifications, are needed
for VM ports. We also really should be generating the other
notifications, enforcing quotas, etc. for the neutron resources.
We could just use python-neutronclient, but I think we'd prefer to avoid
the overhead. The neutron project already depends on
python-neutronclient for some tests, the debug facility, and the
metaplugin, so in retrospect, we could have easily used it in the PoC.
With the existing REST code, if we could find the
neutron.api.v2.base.Controller class instance for each resource, we
could simply call create(), update(), delete(), and show() on these. I
didn't see an easy way to find these Controller instances, so I threw
together some code similar to these Controller methods for the PoC. It
probably wouldn't take too much work to have
neutron.manager.NeutronManager provide access to the Controller classes
if we want to go this route.
The core refactoring effort may eventually provide a nice solution, but
we can't wait for this. It seems we'll need to either use
python-neutronclient or get access to the Controller classes in the
meantime.
Any thoughts on these? Any other ideas?
Thanks,
-Bob
Regards,
Mandeep
_______________________________________________
OpenStack-dev mailing list
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
