Open Stack

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
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140523/f3bebba2/attachment-0001.html>