Hi Bob, The approach towards having the neutron.manager.NeutronManager provide access to the Controller classes seems like something worth exploring for the shorter term.
Thanks, ~Sumit. On Fri, May 23, 2014 at 12:31 PM, Robert Kukura <kuk...@noironetworks.com> wrote: > > 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 > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
