On Tue, Jun 28, 2016 at 11:54 AM, Vikas Choudhary < [email protected]> wrote:
> > > On Tue, Jun 28, 2016 at 1:53 PM, Antoni Segura Puimedon < > [email protected]> wrote: > >> >> >> On Mon, Jun 27, 2016 at 11:10 AM, Vikas Choudhary < >> [email protected]> wrote: >> >>> >>> >>> On Mon, Jun 27, 2016 at 2:22 PM, Fawad Khaliq <[email protected]> >>> 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 < >>>> [email protected]> 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 <[email protected]> >>>>> 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 <[email protected]> >>>>> >>>>> >>>>> @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 < >>>>> [email protected]> wrote: >>>>> >>>>>> >>>>>> >>>>>> On Thu, Jun 23, 2016 at 7:28 AM, Irena Berezovsky <[email protected] >>>>>> > 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 < >>>>>>> [email protected]> 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: >>>>> [email protected]?subject:unsubscribe >>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>>> >>>>> >>>> >>>> >>>> __________________________________________________________________________ >>>> OpenStack Development Mailing List (not for usage questions) >>>> Unsubscribe: >>>> [email protected]?subject:unsubscribe >>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>> >>>> >>> >>> >>> __________________________________________________________________________ >>> OpenStack Development Mailing List (not for usage questions) >>> Unsubscribe: >>> [email protected]?subject:unsubscribe >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >>> >> >> __________________________________________________________________________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: >> [email protected]?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
