Open Stack

Hi Team,

kuryr-libnetwork needs kuryr(along with refactoring changes)  to be
installed through requirements.txt, [1] . If we merge changes in kuryr to
achieve so we might end-up messing up both repos.

To handle this, I have forked kuryr repo on my github account, [2], and
doing required changes in my local forked kuryr.

kuryr-libnetwork patches will resolve kuryr dependency from my forked kuryr
project(with required changes). Once kuryr-libnetwork is stable with all
unit test-cases and functional test cases working as they do today in kuryr
repo, we can start making changes to kuryr project. This way atleast one
repo would be working at all time.

I will keep updating patches in kuryr from my forked kuryr project.

thoughts?


Regards
Vikas

[1] https://review.openstack.org/#/c/336661/4/requirements.txt
[2] https://github.com/vikaschoudhary16/kuryr/tree/rpc_ns



On Tue, Jun 28, 2016 at 3:45 PM, Vikas Choudhary <choudharyvikas16 at gmail.com
> wrote:

>
>
> On Tue, Jun 28, 2016 at 3:41 PM, Antoni Segura Puimedon <
> toni+openstackml at midokura.com> wrote:
>
>>
>>
>> On Tue, Jun 28, 2016 at 11:54 AM, Vikas Choudhary <
>> choudharyvikas16 at gmail.com> wrote:
>>
>>>
>>>
>>> On Tue, Jun 28, 2016 at 1:53 PM, Antoni Segura Puimedon <
>>> toni+openstackml at midokura.com> wrote:
>>>
>>>>
>>>>
>>>> On Mon, Jun 27, 2016 at 11:10 AM, Vikas Choudhary <
>>>> choudharyvikas16 at gmail.com> wrote:
>>>>
>>>>>
>>>>>
>>>>> 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.
>>>>>
>>>>
>>>> Right now we have three repositories
>>>>
>>>> - kuryr
>>>> - kuryr-libnetwork
>>>> - kuryr-kubernetes
>>>>
>>>> My proposal is that the common code (as described below in Vikas'
>>>> email, this includes the binding code) lives in `kuryr`.
>>>> The kuryr server for the nested swarm case would also live there, as it
>>>> would be a generic rest API.
>>>>
>>>> The local libnetwork code, the REST server that we have that serves the
>>>> libnetwork ipam and remote driver APIs would live in kuryr-libnetwork.
>>>> For the nested case, I'd put a configuration option to the libnetwork
>>>> driver to prefer the vlan tagging binding script.
>>>>
>>>
>>> vlan tagging part looks common to both libnetwork and k8s(cni). Will it
>>> be present in both the repos, kuryr-libnetwork and kuryr-k8s or we can put
>>> this also in common 'Kuryr'?
>>>
>>
>> It would be in common kuryr. The configuration option to use it instead
>> of the port type would be defined in both kuryr-libnetwork and kuryr-k8s.
>>
>>
>
> Thanks for the confirmation Toni. Now it totally makes sense.
>
>
>>>
>>>>
>>>> Both CNI and the API watcher I would put in the kuryr-kubernetes
>>>> repositories under /kuryr/{cni,watcher}
>>>>
>>>
>>>>
>>>>>
>>>>>
>>>>>> 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
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> __________________________________________________________________________
>>>>> 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
>>>>
>>>>
>>>
>>>
>>> __________________________________________________________________________
>>> 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/20160703/a399ed17/attachment.html>