Open Stack

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.


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