Thursday, 2016-06-23

*** limao has joined #openstack-kuryr00:30
*** limao_ has joined #openstack-kuryr00:34
*** limao has quit IRC00:37
*** limao_ has quit IRC01:12
*** limao has joined #openstack-kuryr01:14
*** shashank_hegde has quit IRC01:15
*** salv-orlando has joined #openstack-kuryr01:18
*** hongbin has joined #openstack-kuryr01:23
*** salv-orlando has quit IRC01:25
*** hongbin has quit IRC01:29
*** banix has joined #openstack-kuryr01:35
*** hongbin has joined #openstack-kuryr02:20
*** salv-orlando has joined #openstack-kuryr02:49
*** salv-orlando has quit IRC02:54
*** yamamoto_ has joined #openstack-kuryr03:02
*** hongbin has quit IRC03:09
*** shashank_hegde has joined #openstack-kuryr03:41
*** shashank_hegde has quit IRC03:49
*** yamamoto_ has quit IRC03:54
*** salv-orlando has joined #openstack-kuryr04:00
*** huikang has joined #openstack-kuryr04:03
*** salv-orlando has quit IRC04:14
*** shashank_hegde has joined #openstack-kuryr04:20
*** limao has quit IRC04:28
*** janonymous has joined #openstack-kuryr04:30
*** vikasc has joined #openstack-kuryr04:31
vikascgsagie, ping04:33
*** diga has joined #openstack-kuryr04:33
vikascbanix, hi04:34
banixVikasC: hi04:34
vikascbanix, I updated test cases and fixed fullstack as per your suggestion :)04:35
vikascbanix, https://review.openstack.org/#/c/331050/04:35
banixVikasC: yes noticed it; had a quick look, it looks good. will review more carefully tomorrow (thursday)04:35
vikascbanix, sure04:35
banixVikasC: thanks for working on it04:36
*** huikang has quit IRC04:36
vikascbanix, my pleasure04:36
vikascbanix, now i have started working on nested vm04:36
banixVikasC: containers in VMs?04:36
*** huikang has joined #openstack-kuryr04:36
vikascbanix, yes04:36
banixcool04:36
vikascbanix, I feel our current 'Kuryr' code should be rename as "kuryr-driver"04:37
vikascor something similar04:37
vikascbanix,  and parallel to it one more common kuryr-api should be written04:38
vikascbanix,  kuryr-api will be responsible for talking to other openstack services04:39
banixwell, Kuryr seems to be expanding to cover a few things beyond the libnetwork driver which means what you suggest makes sense04:39
vikascbanix, kuryr-drivers will talk to kuryr api04:39
vikascbanix, kuryr apis will be generic04:39
vikascbanix, kuryr-driver part will have seperate support directories like driver-libnetwork, driver-k8s etc04:40
banixwell we are having a separate repo for k8s04:41
*** huikang has quit IRC04:41
vikascbanix, makes sense... libnetwork-driver part got to kuryr libnetwork and similarly k8s driver to kuryr-k8s04:41
vikascbanix, common library , kuryr-api will remain in our current Kuryr04:42
vikascbanix, makes sense?04:42
banixyes thats where we are going; may need to be revised as we go forward04:42
vikascthanks banix , wanted to just confirm04:43
vikasc:)04:43
banixgreat; ttyl04:44
vikascbanix, bye04:44
*** yamamoto_ has joined #openstack-kuryr04:45
*** salv-orlando has joined #openstack-kuryr04:50
*** banix has quit IRC04:52
*** limao has joined #openstack-kuryr04:55
*** reedip has quit IRC04:58
*** salv-orl_ has joined #openstack-kuryr04:59
*** salv-orlando has quit IRC05:02
*** tfukushima has joined #openstack-kuryr05:16
vikasctfukushima, ping05:29
vikascirenab, ping05:31
irenabvikasc: hi05:31
vikascirenab, Hi, should not this "doc/specs/mitaka" directory be renamed to "specs/newton" now?05:31
vikascirenab, wanted to discuss before raising a bug05:31
irenablet me check what is there inside05:32
vikascirenab, or the ones completed can be there and a new directory , newton can be created for active specs?05:32
irenabI think you are right, but lets check how they do it in neutron. I beleive there is some sort of approved sub folder05:32
*** shashank_hegde has quit IRC05:34
irenabIactually, its in nova. there is approved and implemented sub folders05:35
irenabBut I think renaming to newton will be good enough05:35
vikascyeah, in neutron there is no release-wise folder05:35
vikascyes, because all are being implemented in newton05:35
irenabits nice in nova:  https://github.com/openstack/nova-specs/tree/master/specs/newton05:35
*** diga has quit IRC05:36
irenabbut we do not have too many specs right now, so I guess moving these specs to newton is fine05:36
vikascirenab, makes sense.05:36
vikascirenab, I will also open a bug you brought up in last meeting regarding neutron restart05:37
vikascirenab, just to keep track05:37
irenabvikasc: thanks, it wa still on my todo list -)05:37
vikascirenab, shall i do it?05:38
*** shashank_hegde has joined #openstack-kuryr05:38
irenabvikasc: I think we should consider cases where neutron is restarted or maybe even upgraded or reconfigured to keep it in sync with kuryr05:38
vikascirenab, valid point05:38
irenabvikasc: I do not mind, either way. I can do it now before being distructed by other tasks :-)05:39
vikascirenab, please go ahead :)05:39
vikascvikasc, i will take care of renaming task05:40
vikascirenab, nested-vm spec is too abstract05:40
irenabvikasc: I agree05:41
vikascirenab,  documentation on seperation of project into common kuryr library and other COE specific drivers is also not there05:41
irenabI think adding devref for more detailed implementation details will be very helpful05:41
vikascirenab, should we enhance nested-vm spec or several small small devrefrences will be better05:42
irenabvikasc: do you think documentation is required? I thought we can have launchpad bp for this05:42
irenabfor code split05:42
irenabvikasc:  I do not have preference, I think maybe both …05:43
irenabclarify the spec + adding devref for more design/implementation details05:43
vikascirenab, ok... will add to todo-list05:44
irenab:-)05:44
vikascirenab, thanks :)05:44
vikascirenab, Can you please review this one, https://review.openstack.org/#/c/328656/ its a very minor doc change05:45
vikascirenab, its been there since long05:45
irenabvikasc:  sure, after the bug report ….05:46
vikascirenab, Also if you get timewould appreciate review comments on "short-term fix for overlapping", https://review.openstack.org/#/c/331050/05:46
irenabadding to my todo list :-)05:47
irenabvikasc: https://bugs.launchpad.net/kuryr/+bug/159539905:48
openstackLaunchpad bug 1595399 in kuryr "kuryr does not support neutron server reconnect" [Undecided,New]05:48
vikascirenab, thanks05:50
vikascirenab, I could not find any bp for refactoring. Can you please share link?05:51
irenabI think it was discussed that there is no such. Can you please create one, or coordinate with gsagie ?05:51
vikascirenab, Closest one is this by fawad mentioning kuryr agent and kuryr server, https://blueprints.launchpad.net/kuryr/+spec/kuryr-agent05:51
vikascirenab, you already mailed, so i expect he would reply05:52
irenabvikasc: I think the code split is unrelated, it is needed for k8s/libnetwork as well05:52
vikascirenab, as per my current understanding, Kuryr server will be this common library which will reside with current Kuryr project05:53
vikascirenab, agents will be specific to each coe like libnetwork/k8s and will be maintained in seperate repos like kuryr-libnetwork and kuryr-k8s05:54
vikascirenab, am i saying wrong something05:54
vikascirenab, so it seems to me that fawad bp covers Kuryr(common library/server) and kuryr-libnetwork(agent) part05:56
vikascirenab, though enough details are missing05:56
irenabvikasc: I beleive that code split is not only about server/agent reorg. We need also common kuryr part to be shared between libnetwork/k8s integration. Please try to rreach gsagie to coordinate the work. If you create launchpad bp, you can put your ideas in the whileboard section there05:58
vikascirenab, ok so i am going to create a bp for code refactoring05:58
vikascirenab, im my understanding , "Kuryr common part" is being refered to as Kuryr server only. This server is different from remote driver server listening for libnetwork api calls06:00
vikascirenab,  I will add details on bp06:01
vikascirenab, we can discuss there. Thanks for the time :)06:01
irenabvikasc: welcome, have a great day06:02
*** oshidoshi has joined #openstack-kuryr06:05
gsagiehi vikasc06:06
vikaschi gsagie06:07
gsagieI havent started working on the split part, so if you would like to do it feel free06:07
gsagieand let me know how i can help06:07
vikascgsagie, ok.. so i was just drafting a bp for refactoring but before that i would like to confirm very briefly my understanding06:07
gsagiei will start reading the channel buffer :)06:07
vikascgsagie, that will be great06:08
vikascgsagie,  whatever i was just discussing with irenab , please share your view on that06:08
vikascgsagie, I am waiting06:08
gsagieok06:11
gsagieso yes. we have 2 repos already for libnetwork specific integration and k8s06:11
gsagiethe common lib should have the "controller" part with the binding for example and the part that speak with Neutron probably06:11
vikascgsagie,  yes and this will be like common kuryr server running on cluster controller node, serving requests from kuryrs agents running inside vms06:12
vikascgsagie, is this correct?06:13
gsagievikasc: not sure what you mean server/agent06:13
gsagieif you mean the nested containers/kubernetes integration06:13
gsagiethats something else i think06:13
gsagiefor example the code in libnetwork repo should still call the Neutron API, same implementation we have today for Neutron06:14
gsagiebut code wise, the libnetwork driver and IPAM should be inside libnetwork driver, the controller binding part should be in Kuryr as a library that the libnetwork code use06:14
gsagieto communicate with Neutron06:14
gsagiei think something along these lines, but thats what i had in mind, happy to hear if anyone had anything else in mind06:14
vikasci have a little different than this in my mind06:15
vikascgsagie, would appreciate if you have time and patience to understand my view point :)06:16
gsagieof course06:16
vikascgsagie, I was thinking like this06:16
vikascgsagie, kuryr-libnetwork or kuryr-k8s will have code talking to conatiner run-time and will talk on the other side to kuryr controller only06:18
vikasckuryr repo will have code for kuryr controller06:18
vikascKuryr controller will be like kuryr-api, talking to other services on behalf of kuryr-k8s or kuryr-libnetwork06:19
vikasckuryr controller will talk to neutron to get plumbing done on nova nodes and will allocate and pass per-container tag to kuryr-libnetwork/kuryr-k8s running on vm.06:21
vikascgsagie, am i making a bit sense :) ?06:21
vikascgsagie, kuryr-libnet/kuryr-k8s running inside vm will configure let say local ovs for tagging container traffic06:22
gsagiesec reading :)06:24
vikascgsagie,  to tag container traffic kuryr-libnet/k8s will configure ovs running inside vm using tags received from kuryr-controller running on cluster controller node06:24
gsagievikasc: you are making sense, however if we take the examples we have right now, the libnetwork implementation you will need to write a new mechanism to sync between the "agents" and the controller06:25
gsagieor the one that is calling Neutron06:25
gsagieand you will have to define an API to do so06:25
gsagieor a message patterns06:25
vikascgsagie, true.. APIs would be my preference and "agent" will actually be a client06:26
vikascgsagie, kuryr-libnet/k8s will be client to kuryr controller to get things done06:27
vikascgsagie, so whatever kuryr controller will think that client needs such as IP of vif will be passed to client and if something is to configured such as untagging part on compute, that controller can get done by talking to neutron06:28
vikascgsagie, so these "clients" kuryr-k8s or kuryr-libnetwork will work as drivers for native docker but client for kuryr controller and not talking to any other openstack service06:29
gsagievikasc: i will have to think about it, it sounds like a good direction overall, the thing i  am not sure about  is the communication channel between the "client" and controller, for example in Kubernetes plan the CNI driver is just doing binding and talking06:29
gsagiewith Kubernetes master maybe over the kubernetes API06:29
vikascgsagie, cant it be rest calls06:29
gsagieand the "controller" is basically a watcher on the API of the Kube master06:30
gsagieso there is not required to be any communication between the agent/client and Kuryr controller/watcher06:30
vikascgsagie,  but our approach should be working for other coes  also such as swarm06:31
gsagiei think that by doing what you propose we are locked to a certain way of implementing things06:31
gsagievikasc: yes, i agree that doing something like that make sense for Swarm06:31
gsagiei think it make sense for the nested VMs case06:31
vikascgsagie, yes06:31
gsagiebut again make sense for libnetwork/Swarm06:32
gsagieless for Kubernetes06:32
vikascgsagie, i thought of all this while splitting tasks for nested vm,06:32
gsagievikasc: yeah i can see where you coming from :) i do want us to reuse as much as possible so its good thinking06:32
vikascgsagie,  :D06:32
gsagiei would raise this in the mailing list06:32
gsagieor maybe in the next IRC meeting06:33
vikascgsagie, thanks.. i think you can better present my thinking06:33
vikasc:)06:33
gsagienp, i will send the email today06:33
vikascgsagie, shall i open a bp for refactoring also06:33
gsagievikasc: yep06:33
vikascwith current thoughts. ok06:34
vikascgsagie,  thanks Gal06:34
gsagiethank you vikasc :)06:34
*** irenab has quit IRC06:58
vikascgsagie, we can have config options in controller. If controllerd configured for k8s it will use api watcher patch otherwise handling rest cases.07:00
*** irenab has joined #openstack-kuryr07:00
vikascgsagie,  s/patch/path07:01
*** irenab has quit IRC07:01
openstackgerritMerged openstack/kuryr: Fix .rst format in kuryr_k8s_integration.rst  https://review.openstack.org/32865607:03
*** irenab has joined #openstack-kuryr07:08
*** irenab has quit IRC07:09
*** irenab has joined #openstack-kuryr07:09
vikascgsagie, controller may futher have k8s-controller(api-watcher), libnetwork-controller and so on07:14
vikascgsagie, to me k8s-integration is one specific case of nested vm.07:15
*** irenab has quit IRC07:17
*** salv-orl_ has quit IRC07:18
*** irenab has joined #openstack-kuryr07:38
*** limao_ has joined #openstack-kuryr07:41
*** limao has quit IRC07:44
apuimedoI just got headache reading so many early morning messages :P07:59
apuimedogsagie: vikasc: I think taking this discussion to the mailing list would be the best08:00
*** salv-orlando has joined #openstack-kuryr08:05
*** diga has joined #openstack-kuryr08:15
vikascapuimedo, :) , gsagie would initiating a thread on ml08:26
*** shashank_hegde has quit IRC08:29
*** irenab_ has joined #openstack-kuryr08:29
*** irenab has quit IRC08:30
*** irenab_ is now known as irenab08:30
*** irenab has quit IRC08:40
openstackgerritOpenStack Proposal Bot proposed openstack/kuryr: Updated from global requirements  https://review.openstack.org/33230408:41
openstackgerritvikas choudhary proposed openstack/kuryr: Rename spec directory to newton  https://review.openstack.org/33318508:47
*** salv-orlando has quit IRC08:49
*** salv-orlando has joined #openstack-kuryr08:50
*** salv-orlando has quit IRC08:55
*** vikasc has quit IRC08:59
*** vikasc has joined #openstack-kuryr09:12
apuimedocool09:13
*** neiljerram has joined #openstack-kuryr09:14
*** irenab has joined #openstack-kuryr09:20
openstackgerritMerged openstack/kuryr: Rename spec directory to newton  https://review.openstack.org/33318509:36
*** salv-orlando has joined #openstack-kuryr09:42
*** limao_ has quit IRC10:06
openstackgerritvikas choudhary proposed openstack/kuryr: Short-Term fix for overlapping cidrs using docker options  https://review.openstack.org/33105010:36
*** salv-orl_ has joined #openstack-kuryr10:58
*** salv-orlando has quit IRC11:01
*** salv-orl_ has quit IRC11:53
*** banix has joined #openstack-kuryr11:56
*** vikasc has quit IRC11:59
openstackgerritPeter V. Saveliev proposed openstack/kuryr: contrib/vagrant: fix env vars type conversion  https://review.openstack.org/33329511:59
*** diga has quit IRC12:06
*** yamamoto_ has quit IRC12:41
*** banix has quit IRC12:44
*** salv-orlando has joined #openstack-kuryr12:47
*** janonymous has quit IRC12:51
*** lezbar__ has joined #openstack-kuryr13:08
*** lezbar has quit IRC13:12
*** salv-orlando has quit IRC13:40
*** salv-orlando has joined #openstack-kuryr13:41
*** huikang has joined #openstack-kuryr13:50
*** huikang has quit IRC13:51
*** huikang has joined #openstack-kuryr13:51
*** huikang has quit IRC13:54
*** huikang has joined #openstack-kuryr13:55
*** diga has joined #openstack-kuryr13:57
*** huikang has quit IRC14:09
*** diga has quit IRC14:12
*** huikang has joined #openstack-kuryr14:12
*** kfox1111 is now known as kfox1111_away14:17
*** salv-orlando has quit IRC14:35
*** salv-orlando has joined #openstack-kuryr14:36
*** yamamoto has joined #openstack-kuryr14:59
openstackgerritOpenStack Proposal Bot proposed openstack/kuryr: Updated from global requirements  https://review.openstack.org/33230415:32
*** salv-orlando has quit IRC15:33
*** huikang has quit IRC15:48
*** oshidoshi has quit IRC15:49
*** diga has joined #openstack-kuryr15:58
*** diogogmt has joined #openstack-kuryr16:03
*** tfukushima has quit IRC16:05
*** huikang has joined #openstack-kuryr16:29
*** huikang has quit IRC16:34
*** shashank_hegde has joined #openstack-kuryr17:11
*** huikang has joined #openstack-kuryr17:19
*** shashank_hegde has quit IRC17:26
*** huikang has quit IRC17:35
*** salv-orlando has joined #openstack-kuryr17:42
*** salv-orl_ has joined #openstack-kuryr17:49
*** salv-orlando has quit IRC17:49
*** shashank_hegde has joined #openstack-kuryr17:51
openstackgerritMohammad Banikazemi proposed openstack/kuryr: Waiting for Neutron port to become ACTIVE  https://review.openstack.org/31948418:22
*** yamamoto has quit IRC18:22
*** yamamoto has joined #openstack-kuryr18:22
*** salv-orl_ has quit IRC18:28
*** yamamoto has quit IRC18:30
*** salv-orlando has joined #openstack-kuryr18:36
*** huikang has joined #openstack-kuryr18:36
*** huikang has quit IRC18:41
*** huikang has joined #openstack-kuryr18:48
*** huikang has quit IRC18:49
*** hongbin has joined #openstack-kuryr18:51
*** huikang has joined #openstack-kuryr19:05
*** salv-orlando has quit IRC19:30
*** yamamoto has joined #openstack-kuryr19:30
*** yamamoto has quit IRC19:40
*** salv-orlando has joined #openstack-kuryr19:52
*** banix has joined #openstack-kuryr20:13
*** huikang has quit IRC20:16
openstackgerritMohammad Banikazemi proposed openstack/kuryr: Waiting for Neutron port to become ACTIVE  https://review.openstack.org/31948420:17
*** huikang has joined #openstack-kuryr20:24
*** huats has quit IRC20:27
*** huats has joined #openstack-kuryr20:27
*** huikang has quit IRC20:28
*** fkautz has quit IRC20:30
*** fkautz has joined #openstack-kuryr20:42
*** diga has quit IRC20:55
*** huikang has joined #openstack-kuryr21:18
*** irenab has quit IRC21:19
*** huikang has quit IRC21:24
*** huikang has joined #openstack-kuryr21:40
*** irenab has joined #openstack-kuryr21:41
*** ivc_ has joined #openstack-kuryr22:03
*** huikang has quit IRC22:05
*** ivc_ has quit IRC22:06
*** limao has joined #openstack-kuryr22:28
*** diogogmt has quit IRC22:33
*** diogogmt has joined #openstack-kuryr22:44
*** dingboopt has joined #openstack-kuryr22:46
*** salv-orl_ has joined #openstack-kuryr22:59
*** salv-orlando has quit IRC23:02
*** limao_ has joined #openstack-kuryr23:13
*** hongbin has quit IRC23:21
*** limao_ has quit IRC23:23
*** banix has quit IRC23:32

Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!