On Mon, Jun 27, 2016 at 11:10 AM, Vikas Choudhary <
choudharyvika...@gmail.com> wrote:
>
>
> On Mon, Jun 27, 2016 at 2:22 PM, Fawad Khaliq <fa...@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.
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 <
>> choudharyvika...@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 <choudharyvika...@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 <t...@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 <
>>> t...@midokura.com> wrote:
>>>
>>>>
>>>>
>>>> On Thu, Jun 23, 2016 at 7:28 AM, Irena Berezovsky <ir...@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 <
>>>>> choudharyvika...@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-requ...@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-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
