Hi Team, kuryr-libnetwork needs kuryr(along with refactoring changes) to be installed through requirements.txt, [1] . If we merge changes in kuryr to achieve so we might end-up messing up both repos.
To handle this, I have forked kuryr repo on my github account, [2], and doing required changes in my local forked kuryr. kuryr-libnetwork patches will resolve kuryr dependency from my forked kuryr project(with required changes). Once kuryr-libnetwork is stable with all unit test-cases and functional test cases working as they do today in kuryr repo, we can start making changes to kuryr project. This way atleast one repo would be working at all time. I will keep updating patches in kuryr from my forked kuryr project. thoughts? Regards Vikas [1] https://review.openstack.org/#/c/336661/4/requirements.txt [2] https://github.com/vikaschoudhary16/kuryr/tree/rpc_ns On Tue, Jun 28, 2016 at 3:45 PM, Vikas Choudhary <[email protected] > wrote: > > > On Tue, Jun 28, 2016 at 3:41 PM, Antoni Segura Puimedon < > [email protected]> wrote: > >> >> >> 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. >> >> > > Thanks for the confirmation Toni. Now it totally makes sense. > > >>> >>>> >>>> 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 >> >> >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
