Open Stack

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
<kukura at 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 at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>