Open Stack

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/20160628/2788202c/attachment.html>