On 23 May 2014 12:31, 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.
I am at loss here: if you say that you couldn't fit at the plugin level, that is because it is the wrong level!! Sitting above it and redo all the glue code around it to add DHCP notifications etc continues the bad practice within the Neutron codebase where there is not a good separation of concerns: for instance everything is cobbled together like the DB and plugin logic. I appreciate that some design decisions have been made in the past, but there's no good reason for a nice new feature like GP to continue this bad practice; this is why I feel strongly about the current approach being taken. > > 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. I am not sure I understand what overhead you mean here. Could you clarify? Actually looking at the code, I see a mind boggling set of interactions going back and forth between the GP plugin, the policy driver manager, the mapping driver and the core plugin: they are all entangled together. For instance, when creating an endpoint the GP plugin ends up calling the mapping driver that in turns ends up calls the GP plugin itself! If this is not overhead I don't know what is! The way the code has been structured makes it very difficult to read, let alone maintain and extend with other policy mappers. The ML2-like nature of the approach taken might work well in the context of core plugin, mechanisms drivers etc, but I would argue that it poorly applies to the context of GP. > > 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? I am still not sure why do you even need to go all the way down to the Controller class. After all it's almost like GP could be a service in its own right that makes use of Neutron to map the application centric abstractions on top of the networking constructs; this can happen via the REST interface. I don't think there is a dependency on the core refactoring here: the two can progress separately, so long as we break the tie, from an implementation perspective, that GP and Core plugins need to leave in the same address space. Am I missing something? Because I still cannot justify why things have been coded the way they have. Thanks, Armando > > 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