15:00:15 #startmeeting kuryr 15:00:16 Meeting started Mon Aug 3 15:00:15 2015 UTC and is due to finish in 60 minutes. The chair is apuimedo. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:00:17 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:00:19 The meeting name has been set to 'kuryr' 15:00:33 Hi all 15:00:46 and welcome to the first community IRC meeting of Kuryr 15:00:52 hi 15:00:53 who is here to join the fun? 15:01:08 hi 15:01:18 Hi 15:01:20 hi 15:01:55 #info banix, apuimedo, yalie, tfukushima and red_trela present in the meeting 15:02:26 According to the agenda, the first point is: Review the project goals 15:02:54 #link https://wiki.openstack.org/wiki/Meetings/Kuryr 15:02:59 tfukushima got a patch merged that describes the current goals 15:03:23 https://github.com/openstack/kuryr/blob/master/doc/source/design.rst 15:03:44 #link https://review.openstack.org/#/c/206956/ 15:04:07 Did everybody have time to take a look? 15:04:33 Does somebody have further comments for the current definition or proposals for the following steps? 15:06:00 I am going to submit a draft blueprint that describes the mechanism that the different port types will follow for binding and unbinding the veths to the overlays 15:06:13 great 15:06:58 It will follow a similar pattern to the nova vif-plug-script proposal that was discussed in Vancouver 15:06:59 sounds good. there was/is an effort in Nova to have the vif plu/unplug sumting pluable but i don’t think that has happened… 15:07:15 banix: you are well informed 15:07:22 AFAIK it has not happened yet 15:07:32 but the approach will be similar 15:07:50 Since the task is very similar to what happens in nova 15:07:56 I want to aim for consistency 15:08:01 makes sense 15:08:40 and simplicity, and having just executables for bind and unbind seems the simplest and most powerful of the solutions (albeit it may bring some grief to selinux policy updaters) 15:09:31 #action apuimedo to submit a draft proposal for vif-binding-unbinding 15:09:39 hi apuimedo, what is the nova vif-plug-script proposal? 15:09:46 is there a link? 15:09:51 yalie: https://etherpad.openstack.org/p/nova_vif_plug_script_spec 15:09:55 thanks! 15:10:04 I think it made it to gerrit 15:10:08 but I can't find the link now 15:10:28 it's enough,thank you 15:11:01 there may have been some concern wrt security but I do not recall the details… will follow up 15:11:39 well, for me, as long as it has an appropriate apparmor selinux confinement it should be okay 15:12:14 I don't think Kuryr should run with full root, just CAP_NET_ADMIN 15:12:41 I believe the vif plug script was abandoned in favor of a library model 15:12:50 https://review.openstack.org/#/c/193668 15:13:29 #link https://review.openstack.org/#/c/193668 15:13:36 thanks SourabhP 15:13:47 I'll study it and take it into consideration for the draft! 15:13:51 :-) 15:14:12 Another issue that we should tackle leading to next week's meeting will be the one about configuration 15:14:33 whether we should have /etc/kuryr/kuryr.conf or just get config from Docker, or both 15:14:52 (Just raising it so people can start thinking about it :-) ) 15:15:45 #action apuimedo to put in the next week's agenda configuration management 15:16:09 Does anybody have any other thing for the first meeting point? 15:16:20 yes let’s think; to me there are some configs that docker shouldn’t care about but lets discuss more next week 15:17:26 banix: thanks banix. I was thinking maybe we should have an etherpad to draft a blueprint for that 15:17:57 apuimedo: ok let me get that started 15:17:57 I started implementing the actual code of bridging Kuryr and Neutron. I need to handle how I can set the information required by Neutron, i.e., user, password and the root endpoint URL. 15:18:23 I mean, I need to figure it out. 15:18:27 tfukushima: I guess for now we can use ENV variables 15:18:45 while we work on the blueprint draft that banix will set up 15:19:04 #action banix to set up a draft spec for configuration management 15:19:41 #info On to the second item of the day "Magnum/Kolla" 15:19:49 Ok, that makes sense. I'll use ENV vars for now. 15:19:57 That could be one use-case for having kuryr.conf? Keystone credentials for Neutron tenants ? 15:20:09 SourabhP: definitely 15:20:41 and I think that Kuryr should be properly registered in Keystone as a service and have its own token 15:20:46 SourabhP: speaking of tenant”s”, there ia lot to discuss as how we deal with multiple tenants 15:21:19 banix: that's a very interesting topic 15:21:34 Yes, I was trying to understand how to map Neutron’s use of tenants for container world 15:21:37 my thought was that single requests should pass a docker label 15:21:48 so if you do docker network create 15:22:12 you should be passing a label that contains a temporary token of your user 15:22:26 otherwise you can't have multiple tenants on the same host 15:22:38 but I have to fully consider the security implications of that 15:22:59 apuimedo: yes it seems that labels should be involved :) 15:23:26 Would these labels correspond to users/tenants in Keystone? 15:23:30 #info set up discussion about multi-tenancy for an eventual blueprint 15:23:48 SourabhP: the labels is just the Docker mechanism to pass arbitrary data to commands 15:23:59 in this case, it could be something like 15:24:12 #link https://docs.docker.com/userguide/labels-custom-metadata/ 15:24:29 apuimedo: thanks. will look that up. 15:24:37 so i think this is the area where we have to see how docker is evolving and what the plans (if any) are for the short and long term 15:25:02 #link https://github.com/docker/docker/pull/9882 15:25:23 yes, we'll have to keep up to date ;-) 15:26:51 It could look like `docker run --publish-service=db.mynet.kuryr --label token=180413823-48-03 cirros` 15:27:34 you can try labels in 1.8 experimtal builds 15:27:53 so, now. Magnum and Kolla 15:29:00 there was some discussion in the Magnum specs about the adequacy of the networking abstraction they propose 15:29:03 #link https://review.openstack.org/#/c/204686/ 15:30:05 seems this spec want to create a magnum network plugin? 15:30:20 However, seeing that unfortunately gsagie and mestery could not make it to the meeting today, and being that they are the ones that have most thoroughly reviewed that spec, I'd adjourn the discussion on Magnum for the next Monday. 15:30:55 yalie: IIUC it creates a layer to abstract several networking providers 15:31:17 sounds good 15:31:18 one of them could be Neutron via Kuryr 15:31:28 banix: you mean adjourning? 15:31:34 yes :) 15:31:58 #info Discussion about the Magnum spec postponed to the next meeting 15:32:00 magnum network plugin makes sense to me 15:32:26 #action apuimedo to add the topic to the next meeting agenda 15:32:27 I will be talking to the Magnum people about Kuryr. 15:32:28 but originally the neutron community said thye were not planning to touch neutron networking 15:32:29 sdake: Hi! 15:32:32 hey :) 15:32:43 sorry - saw kolla/magnum pop up - makes my comoputer buzz 15:32:56 sdake: I'm happy to see you here 15:32:59 you should invite daneyon to yournext meeting 15:33:06 sdake: indeed 15:33:12 I'll shoot him an email 15:33:19 danehans@cisco.com 15:33:25 #info next topic: Kolla 15:33:56 touch neutorn networking/ touch container networking 15:34:01 In regards to Kolla, the relationship between Kuryr and Kolla is no different than the one between Nova, Neutron, etc and Kolla 15:34:03 above 10 lines above ^^ 15:34:06 except that we want it more 15:34:17 sdake: my brain auto-corrected :P 15:34:25 yar 15:34:33 8am - brain barely operational 15:34:47 I know the feeling :P 15:35:07 We have to work with Kolla people asap and make a Kuryr container 15:35:17 I'll be happy if there is some taker :P 15:36:10 note to make containers we need something that is pip installable (from source container) or rpm installable (from binary container) 15:36:10 apuimedo: what do we need to do here? 15:36:40 sdake: gsagie set it up on pypi 15:36:40 then ideally add support for ansible to our networking monstrosity that supports linuxbridge and ovs atm 15:36:52 but we have to work on the whole installation 15:37:03 ansible work takes about 4 hours 15:37:10 container work takes about 4 hours 15:37:19 (for experienced people with kolla) 15:37:20 #info: we must look at ansible and pip/rpm based installation 15:37:27 for someone new might take twice as long 15:37:33 sdake: a deployment takes 4h? 15:37:36 i'd focus on from source first 15:37:40 a deployment takes 2 minutes 15:37:43 ah 15:37:44 making th ansible code takes 4 hours 15:37:49 cause that was my experience :P 15:37:58 2 minutes, I mean 15:38:08 cool 15:38:17 join us in #kolla 15:38:25 samyaple is the go to guy in our community on hard ansible questions 15:38:36 of which networking is hard because we have conditionals 15:38:36 sdake: thanks! 15:39:33 #info For work on Kolla-Kuryr contact sdake and samaple 15:39:39 #info For work on Kolla-Kuryr contact sdake and samyaple 15:39:48 rather join #kolla 15:39:55 and ask around - we have 8 core reviewers 15:39:57 any can help 15:40:35 #info kolla-kuryr join #kolla to get help on the integration 15:41:02 banix: it's basically get our pip/rpm deployment ready to be part of Kolla 15:41:11 got it 15:41:16 so that Kolla will be able to deploy Kuryr 15:41:30 it's its unbelievably fast show of OpenStack 15:41:45 I would really like it if we could demo Kuryr in Tokyo 15:41:50 running on Kolla 15:41:57 we will :) 15:42:09 note we jut started liberty-3 15:42:25 so now is the time to write a blueprint so I can set to discussions tage 15:43:07 sdake: you mean the blueprint at the kolla repo, right? 15:43:27 #action apuimedo to find takers for the kolla blueprint 15:43:32 apuimedo: did anyone take this? if not I will find out what is to be done and file the blueprint 15:43:45 well, that action was fast :P 15:43:46 you ahve to write a blueprint firstyes 15:43:49 we have a taker 15:43:49 no specs required 15:44:15 #action banix to look at Kolla and draft a spec for Kuryr inclusion 15:44:16 sdake: i will bug you and company in #kolla if not clear 15:44:26 wfm 15:44:26 sorry, I meant blueprint 15:44:39 ya dont waste time on a spec 15:44:44 ;-) 15:44:44 we only use those on rare circumstances 15:44:53 thanks for that :-) 15:45:08 basically to build consensus where there is none around the core reviewer team 15:45:25 #info Final agenda topic: reviews 15:45:42 Currently everything posted has been merged 15:46:03 I believe tfukushima will be pushing some patches soon 15:46:44 apuimedo: do you mean the basic function has been working? 15:47:10 yalie: no. We do mock answers to the requests 15:47:21 Yes, I have some code with unit tests. But again I need to run it against the real Neutron API. 15:47:24 but Docker already treats Kuryr as a driver 15:47:35 great 15:47:44 tfukushima: looking forward to see that code 15:47:57 any comments about the current working of the reviews? Things we should improve? 15:47:57 tfukushima: looking forward too 15:48:50 tfukushima: I was now wondering that for the unit tests that you are doing for the communication with the Neutron API 15:49:03 probably Magnum already has something done 15:49:18 and nova 15:49:30 actually probably Nova is more likely 15:49:37 since it does a very similar usage 15:49:47 I wonder if we can reuse some of their test work 15:49:56 I looked at python-neutronclient and followed what they're doing basically. 15:50:05 good :-) 15:50:18 that sounds about right tfukushima :) 15:50:40 tfukushima: I hope you soon have more company in the `git log` :-) 15:51:05 I don't test neutronclient itself but only the part of Kuryr mocking the calls against Neutron. 15:51:13 right 15:51:20 that's why I said Nova 15:51:28 because they have to do exactly the same 15:51:46 I'm assuming create_network and delete_network would be succeeded and return the appropriate response. Or I'll add tests for the failures. 15:51:54 good 15:51:57 tfukushima: yes please reach oout to me for any piece that can be done in parallel 15:52:11 thanks banix 15:52:15 #info Open floor. Anybody with another topic for the present meeting? 15:52:29 (8mins remaining) 15:52:43 apuimedo: great first meeting! 15:53:00 thank you apuimedo 15:53:03 banix: thanks ;-) I'm a chair newbie :P 15:53:20 apuimedo: you did very well 15:53:43 thanks a lot banix, yalie, tfukushima, SourabhP and sdake for participating! 15:54:00 Thanks all. 15:54:03 do we have an IRC channel by the way? 15:54:15 banix: for now we use #openstack-neutron 15:54:21 cool 15:54:33 this way the neutron cores have less work tracking us 15:54:34 interestingpattern ;-) 15:54:35 :-) 15:54:51 apuimedo: thanks! great first meeting! 15:54:58 thanks all 15:55:00 #endmeeting