On Tue, Jun 28, 2016 at 1:53 PM, Antoni Segura Puimedon <
toni+openstac...@midokura.com> wrote:
>
>
> 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.
>
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 <
>>> 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
>
>
__________________________________________________________________________
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
