<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jun 27, 2016 at 11:10 AM, Vikas Choudhary <span dir="ltr"><<a href="mailto:choudharyvikas16@gmail.com" target="_blank">choudharyvikas16@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span class="">On Mon, Jun 27, 2016 at 2:22 PM, Fawad Khaliq <span dir="ltr"><<a href="mailto:fawad@plumgrid.com" target="_blank">fawad@plumgrid.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Vikas,<div><br></div><div>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?</div></div><div class="gmail_extra"><br clear="all"></div></blockquote></span><div>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. </div></div></div></div></blockquote><div><br></div><div>Right now we have three repositories<br><br></div><div>- kuryr<br></div><div>- kuryr-libnetwork<br></div><div>- kuryr-kubernetes<br><br></div><div>My proposal is that the common code (as described below in Vikas' email, this includes the binding code) lives in `kuryr`.<br>The kuryr server for the nested swarm case would also live there, as it would be a generic rest API.<br><br></div><div>The local libnetwork code, the REST server that we have that serves the libnetwork ipam and remote driver APIs would live in kuryr-libnetwork.<br></div><div>For the nested case, I'd put a configuration option to the libnetwork driver to prefer the vlan tagging binding script.<br><br></div><div>Both CNI and the API watcher I would put in the kuryr-kubernetes repositories under /kuryr/{cni,watcher}<br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><div class="h5"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_extra"><div><div data-smartmail="gmail_signature"><div dir="ltr">Fawad Khaliq<div><br></div></div></div></div>
<br><div class="gmail_quote"><div><div>On Fri, Jun 24, 2016 at 9:45 AM, Vikas Choudhary <span dir="ltr"><<a href="mailto:choudharyvikas16@gmail.com" target="_blank">choudharyvikas16@gmail.com</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div><div dir="ltr">Hi Team,<div><br></div><div>As already discussed with some of teammates over irc and internally, thought of bringing discussionto ml for more opinions:</div><div><br></div><div>My idea on repo structure is something similar to this:</div><div><br></div><div><span style="color:rgb(80,0,80);font-family:monospace,monospace">kuryr</span><br style="color:rgb(80,0,80);font-family:monospace,monospace"><span style="color:rgb(80,0,80);font-family:monospace,monospace">└── controller</span></div><div><span style="color:rgb(80,0,80);font-family:monospace,monospace">│</span><span style="color:rgb(80,0,80);font-family:monospace,monospace">   ├── api (running on controller node(cluster master or openstack controller node), talking to other services(neutron)) </span></div><div><span style="color:rgb(80,0,80);font-family:monospace,monospace">│</span><span style="color:rgb(80,0,80);font-family:monospace,monospace">   │   </span></div><div><span style="color:rgb(80,0,80);font-family:monospace,monospace">│</span><span style="color:rgb(80,0,80);font-family:monospace,monospace">   ├── kubernetes-controller</span><br style="color:rgb(80,0,80);font-family:monospace,monospace"><span style="color:rgb(80,0,80);font-family:monospace,monospace">│</span><span style="color:rgb(80,0,80);font-family:monospace,monospace">   </span><span style="color:rgb(80,0,80);font-family:monospace,monospace">│</span><span style="color:rgb(80,0,80);font-family:monospace,monospace">       </span><span style="color:rgb(80,0,80);font-family:monospace,monospace">│ </span></div><div><span style="color:rgb(80,0,80);font-family:monospace,monospace">│</span><span style="color:rgb(80,0,80);font-family:monospace,monospace">   </span><span style="color:rgb(80,0,80);font-family:monospace,monospace">│</span><span style="color:rgb(80,0,80);font-family:monospace,monospace">       └── watcher (for network related services making api calls)</span></div><div><span style="color:rgb(80,0,80);font-family:monospace,monospace">│   </span><span style="color:rgb(80,0,80);font-family:monospace,monospace">│</span></div><div><span style="color:rgb(80,0,80);font-family:monospace,monospace">│</span><span style="color:rgb(80,0,80);font-family:monospace,monospace">   </span><span style="color:rgb(80,0,80);font-family:monospace,monospace">│</span><span style="color:rgb(80,0,80);font-family:monospace,monospace">___any_other_coe_controller_capable_of_watching_events </span><span style="color:rgb(80,0,80);font-family:monospace,monospace"> </span></div><div><span style="color:rgb(80,0,80);font-family:monospace,monospace">│</span><span style="color:rgb(80,0,80);font-family:monospace,monospace"><br></span></div><div><span style="color:rgb(80,0,80);font-family:monospace,monospace">│</span><span style="color:rgb(80,0,80);font-family:monospace,monospace"><br></span></div><div><span style="color:rgb(80,0,80);font-family:monospace,monospace">│</span><span style="color:rgb(80,0,80);font-family:monospace,monospace"><br></span></div><div><span style="color:rgb(80,0,80);font-family:monospace,monospace">│___driver</span></div><div><span style="color:rgb(80,0,80);font-family:monospace,monospace">     </span><span style="color:rgb(80,0,80);font-family:monospace,monospace">│____common (traffic tagging utilities and binding)</span></div><div><span style="color:rgb(80,0,80);font-family:monospace,monospace">     </span><span style="color:rgb(80,0,80);font-family:monospace,monospace">│</span></div><div><span style="color:rgb(80,0,80);font-family:monospace,monospace">     </span><span style="color:rgb(80,0,80);font-family:monospace,monospace">│____kubernetes(cni)</span></div><div><span style="color:rgb(80,0,80);font-family:monospace,monospace">     </span><span style="color:rgb(80,0,80);font-family:monospace,monospace">│</span></div><div><span style="color:rgb(80,0,80);font-family:monospace,monospace">     </span><span style="color:rgb(80,0,80);font-family:monospace,monospace">│____libnetwork(network and ipam driver)(for network related services making api calls)</span></div><div><span style="color:rgb(80,0,80);font-family:monospace,monospace">     </span><span style="color:rgb(80,0,80);font-family:monospace,monospace">│</span></div><div><span style="color:rgb(80,0,80);font-family:monospace,monospace">     </span><span style="color:rgb(80,0,80);font-family:monospace,monospace">│____ any_other_driver(calling api for nw related services if watcher not supported)</span></div><div><span style="color:rgb(80,0,80);font-family:monospace,monospace"><br></span></div><div><span style="color:rgb(80,0,80);font-family:monospace,monospace"><br></span></div><div><span style="color:rgb(80,0,80);font-family:monospace,monospace">Thoughts?</span></div><div><span style="color:rgb(80,0,80);font-family:monospace,monospace"><br></span></div><div><span style="color:rgb(80,0,80);font-family:monospace,monospace"><br></span></div><div><span style="color:rgb(80,0,80);font-family:monospace,monospace">-Vikas</span></div><div><span style="color:rgb(80,0,80);font-family:monospace,monospace"><br></span></div><div><span style="color:rgb(80,0,80);font-family:monospace,monospace"><br></span></div><div><span style="color:rgb(80,0,80);font-family:monospace,monospace"><br></span></div><div><span style="color:rgb(80,0,80);font-family:monospace,monospace"> </span><br><div class="gmail_quote">---------- Forwarded message ----------<br>From: <b class="gmail_sendername">Vikas Choudhary</b> <span dir="ltr"><<a href="mailto:choudharyvikas16@gmail.com" target="_blank">choudharyvikas16@gmail.com</a>></span><br>Date: Thu, Jun 23, 2016 at 2:54 PM<br>Subject: Re: Kuryr Refactoring into common library and kuryr-libnetwork + Nested_VMs<br>To: Antoni Segura Puimedon <<a href="mailto:toni@midokura.com" target="_blank">toni@midokura.com</a>><br><br><br><div dir="ltr">@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.<div><br></div><div>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?</div><span><font color="#888888"><div><br></div><div>-Vikas </div></font></span></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jun 23, 2016 at 2:22 PM, Antoni Segura Puimedon <span dir="ltr"><<a href="mailto:toni@midokura.com" target="_blank">toni@midokura.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span>On Thu, Jun 23, 2016 at 7:28 AM, Irena Berezovsky <span dir="ltr"><<a href="mailto:irena@midokura.com" target="_blank">irena@midokura.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hi guys,<div>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.</div><div><br></div><div>Vikas, Gal,let me know if you need so help.</div><div><br></div><div>BR,</div><div>Irena</div></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jun 23, 2016 at 7:58 AM, Vikas Choudhary <span dir="ltr"><<a href="mailto:choudharyvikas16@gmail.com" target="_blank">choudharyvikas16@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hi Gal,<div><br></div><div>Greeting of the day!!!</div><div><br></div><div>I have trying reaching you over irc unsuccessfully since last two days. So finally thought of dropping an email.</div><div><br></div><div>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:</div><div><br></div><div>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.</div><div><br></div><div>2. Modify current kuryr controllers.py to make calls to common "Kuryr_api" and not to OpenStack services directly.</div></div></blockquote></div></div></div></div></blockquote><div><br></div></span><div>My idea was to leave:<br><br></div><div>    <a href="https://github.com/openstack/kuryr" target="_blank">https://github.com/openstack/kuryr</a><br><br></div><div>with a single package <br><br><div style="margin-left:40px"><span style="font-family:monospace,monospace">kuryr<br>└── lib<br>    ├── binding<br>    │   └── __init__.py<br>    └── __init__.py</span><br><br><br></div> that would contain just a library with the common  bits like the controller, the binding, and utils to talk to neutron.<br><br></div><div>Then, the other repos like openstack/kuryr-libnetwork and openstack/kuryr-kubernetes would have a package like the following:<br><br><div style="margin-left:40px"><span style="font-family:monospace,monospace">kuryr<br>└── kubernetes<br>    ├── cni<br>    │   └── __init__.py<br>    ├── __init__.py<br>    └── watcher<br>        └── __init__.py</span><br></div><br></div><div>This way, all would be inside the namespace Python package kuryr (read the first and second answers to <a href="http://stackoverflow.com/questions/1675734/how-do-i-create-a-namespace-package-in-python" target="_blank">http://stackoverflow.com/questions/1675734/how-do-i-create-a-namespace-package-in-python</a><br><br><br></div><span><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div><div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><br></div><div>Shall i start working on both of these or you are already working on either one? Please suggest.</div><span><font color="#888888"><div><br></div><div><br></div><div>-Vikas </div><div><br></div><div><br></div></font></span></div>
</blockquote></div><br></div>
</div></div></blockquote></span></div><br></div></div>
</blockquote></div><br></div>
</div></div></div><br></div></div>
<br></div></div>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div>
<br>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div></div></div><br></div></div>
<br>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div></div>