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. > 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
