Open Stack

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'?


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