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

Vikas Choudhary choudharyvikas16 at gmail.com
Fri Jun 24 04:45:03 UTC 2016


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
>>>
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160624/1c3e2ec7/attachment.html>


More information about the OpenStack-dev mailing list