[openstack-dev] [Kuryr] Refactoring into common library and kuryr-libnetwork + Nested_VMs

Vikas Choudhary choudharyvikas16 at gmail.com
Mon Jun 27 09:10:05 UTC 2016


On Mon, Jun 27, 2016 at 2:22 PM, Fawad Khaliq <fawad at plumgrid.com> wrote:

> Vikas,
>
> Thanks for starting this. Where would you classify the Segmentation
> (VLANID etc) allocation engine. Currently, the libnetwork plugin is tied to
> the api and talks to Neutron, how would libnetwork and api part interact?
>
> As per my current understanding, it should be present be part of
Kuryr-controller(server) running on cluster master node. My proposal is to
move all neutron api calling part to kuryr-controller and let libnetwork
plugin make request to kuryr-controller.


> Fawad Khaliq
>
>
> On Fri, Jun 24, 2016 at 9:45 AM, Vikas Choudhary <
> choudharyvikas16 at gmail.com> wrote:
>
>> Hi Team,
>>
>> As already discussed with some of teammates over irc and internally,
>> thought of bringing discussionto ml for more opinions:
>>
>> My idea on repo structure is something similar to this:
>>
>> kuryr
>> └── controller
>> │   ├── api (running on controller node(cluster master or openstack
>> controller node), talking to other services(neutron))
>> │   │
>> │   ├── kubernetes-controller
>> │   │       │
>> │   │       └── watcher (for network related services making api calls)
>> │   │
>> │   │___any_other_coe_controller_capable_of_watching_events
>>>>>>>> │___driver
>>      │____common (traffic tagging utilities and binding)
>>>>      │____kubernetes(cni)
>>>>      │____libnetwork(network and ipam driver)(for network related
>> services making api calls)
>>>>      │____ any_other_driver(calling api for nw related services if
>> watcher not supported)
>>
>>
>> Thoughts?
>>
>>
>> -Vikas
>>
>>
>>
>>
>> ---------- Forwarded message ----------
>> From: Vikas Choudhary <choudharyvikas16 at gmail.com>
>> Date: Thu, Jun 23, 2016 at 2:54 PM
>> Subject: Re: Kuryr Refactoring into common library and kuryr-libnetwork +
>> Nested_VMs
>> To: Antoni Segura Puimedon <toni at midokura.com>
>>
>>
>> @Toni, Can you please explain a bit on how the roles regarding
>>  vlan/segmentation id allocation, tagging ang untagging containers' traffic
>> are divided among entities you mentioned.
>>
>> In my understanding, in k8s case, API_watcher has resource translators
>> and these will be talking to neutron for port creation and ip allocation.
>> Then why for k8s case, neutron talking utilities are present in common lib.
>> Or in other words, which neutron apis will be used from common lib?
>>
>> -Vikas
>>
>> On Thu, Jun 23, 2016 at 2:22 PM, Antoni Segura Puimedon <
>> toni at midokura.com> wrote:
>>
>>>
>>>
>>> On Thu, Jun 23, 2016 at 7:28 AM, Irena Berezovsky <irena at midokura.com>
>>> wrote:
>>>
>>>> Hi guys,
>>>> Just minor suggestion from my side. Please link all the refactoring
>>>> patches to the same launchpad bp/topic so it will be easy to trace the
>>>> relevant work.
>>>>
>>>> Vikas, Gal,let me know if you need so help.
>>>>
>>>> BR,
>>>> Irena
>>>>
>>>> On Thu, Jun 23, 2016 at 7:58 AM, Vikas Choudhary <
>>>> choudharyvikas16 at gmail.com> wrote:
>>>>
>>>>> Hi Gal,
>>>>>
>>>>> Greeting of the day!!!
>>>>>
>>>>> I have trying reaching you over irc unsuccessfully since last two
>>>>> days. So finally thought of dropping an email.
>>>>>
>>>>> Since you have taken up the task of moving code to kuryr-libnetwork
>>>>> and I also have started working on refactoring/changes for nested-vm, seems
>>>>> there is some overlap. Therefore wanted to coordinate following two tasks:
>>>>>
>>>>> 1. Writing a common(COE agnostic) library , "Kuryr_api" or some other
>>>>> similar name, responsible for handling requests from kuryr-libnetwork and
>>>>> making requests to other OpenStack services.
>>>>>
>>>>> 2. Modify current kuryr controllers.py to make calls to common
>>>>> "Kuryr_api" and not to OpenStack services directly.
>>>>>
>>>>
>>> My idea was to leave:
>>>
>>>     https://github.com/openstack/kuryr
>>>
>>> with a single package
>>>
>>> kuryr
>>> └── lib
>>>     ├── binding
>>>     │   └── __init__.py
>>>     └── __init__.py
>>>
>>>
>>>  that would contain just a library with the common  bits like the
>>> controller, the binding, and utils to talk to neutron.
>>>
>>> Then, the other repos like openstack/kuryr-libnetwork and
>>> openstack/kuryr-kubernetes would have a package like the following:
>>>
>>> kuryr
>>> └── kubernetes
>>>     ├── cni
>>>     │   └── __init__.py
>>>     ├── __init__.py
>>>     └── watcher
>>>         └── __init__.py
>>>
>>> This way, all would be inside the namespace Python package kuryr (read
>>> the first and second answers to
>>> http://stackoverflow.com/questions/1675734/how-do-i-create-a-namespace-package-in-python
>>>
>>>
>>>
>>>
>>>>> Shall i start working on both of these or you are already working on
>>>>> either one? Please suggest.
>>>>>
>>>>>
>>>>> -Vikas
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>>
>> __________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160627/c6527346/attachment.html>


More information about the OpenStack-dev mailing list