14:00:55 <apuimedo> #startmeeting kuryr 14:00:55 <openstack> Meeting started Mon Sep 5 14:00:55 2016 UTC and is due to finish in 60 minutes. The chair is apuimedo. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:00:56 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:00:59 <openstack> The meeting name has been set to 'kuryr' 14:01:13 <ivc_> o/ 14:01:22 <apuimedo> Hello and welcome to the first September meeting of Kuryr 14:01:28 <apuimedo> who's here for the fun? 14:01:42 <tonanhngo> o/ 14:01:45 <limao> o/ 14:01:45 <vikasc> o/ 14:02:49 <apuimedo> devvesa: are you gere? 14:02:51 <apuimedo> *here 14:03:35 <devvesa> o/ 14:03:43 <janonymous> o/ 14:04:04 <apuimedo> #info ivc_, tonanhngo, limao, vikasc, devvesa, janonymous and apuimedo in attendance 14:04:14 <apuimedo> #topic kuryr-lib 14:04:41 <apuimedo> Some good work in cleanups for the upcoming release happened in the last week 14:04:58 <apuimedo> #info all the necessary cleanups for kuryr-lib got merged 14:05:05 <apuimedo> #link https://review.openstack.org/361972 14:05:12 <apuimedo> #link https://review.openstack.org/361937 14:05:20 <apuimedo> #link https://review.openstack.org/361937 14:05:23 <apuimedo> mmm 14:05:28 <apuimedo> crap, I repeated one 14:05:54 <apuimedo> #link https://review.openstack.org/362070 14:06:12 <apuimedo> now, on for what's mising 14:06:16 <apuimedo> for the release 14:06:31 <apuimedo> #info we are missing the keystonev3 support that I've been working on 14:07:20 <apuimedo> I'm merging keystone and neutron configuration all inside a neutron section 14:07:34 <apuimedo> so, like in nova and Neutron, there'll be just on section 14:07:38 <apuimedo> [neutron] 14:07:46 <apuimedo> that will contain neutron and neutron auth opts 14:08:20 <apuimedo> that's all I have on kuryr-lib 14:08:24 <tonanhngo> I have a question: 14:08:29 <apuimedo> tonanhngo: go ahead 14:09:00 <tonanhngo> When we configure for the VM case, would these config continue to be stored on the VM? 14:10:11 <apuimedo> no, not this one 14:10:41 <apuimedo> the only configuration on the VM would be how to reach the kuryr-lib rest server that will then send the calls to neutron 14:10:49 <apuimedo> vikasc is working on that 14:11:05 <apuimedo> oh, I forgot 14:11:08 <vikasc> apuimedo, rpc_server 14:11:16 <apuimedo> vikasc: yes, sorry 14:12:08 <apuimedo> more questions? topics? under kuryr-lib 14:12:10 <apuimedo> ? 14:12:13 <tonanhngo> ok, for Magnum integration, one concern is storing things like account name, password in a config file on the VM 14:12:25 <vikasc> junst an info 14:12:39 <vikasc> i have updated testing for rest driver in kuryr-lib https://review.openstack.org/#/c/342624/ 14:12:42 <apuimedo> tonanhngo: what's the current solution? 14:13:09 <apuimedo> there should probably be some auth between kuryr-libnetwork remote driver in the VMs and the rpc server 14:13:44 <apuimedo> either that, or whitelisting origin addresses 14:13:58 <tonanhngo> Before Kuryr, Magnum does not store any service password on the VM 14:14:19 <tonanhngo> We leave it to the users to enter these, for security 14:14:31 <apuimedo> tonanhngo: how does the kubernetes load balancer plugin that talks to Neutron work then? 14:14:46 <tonanhngo> It uses the user credential 14:15:26 <tonanhngo> but now, it seems we need to give the services password, like Neutron, rabbit 14:15:48 <apuimedo> we do not need rabbit on the VMs 14:16:04 <tonanhngo> for the openvswitch agent? 14:16:10 <apuimedo> that runs on the host 14:16:13 <apuimedo> not on the VMs 14:16:25 <apuimedo> the only credentials would be something so that only the remote driver talks to the kuryr rpc server 14:16:56 <tonanhngo> ok good, then is there a security concern in this case? 14:17:08 <apuimedo> well, we have to decide how to do it 14:17:22 <apuimedo> it's still undefined 14:17:40 <apuimedo> first we have to get it running, then we'll restrict access 14:17:56 <tonanhngo> sounds good, I am just voicing a concern from what we see. 14:18:08 <apuimedo> tonanhngo: and you do well to keep it in our minds 14:19:00 <apuimedo> tonanhngo: can you remind me how does the Kubernetes on Magnum, which runs on a VM, access the Neutron API server 14:19:05 <apuimedo> which runs on the overlay 14:19:15 <apuimedo> ? 14:19:37 <tonanhngo> The Kubernetes plugin uses the user credential to authenticate with Keystone and get a session 14:20:00 <tonanhngo> then the client just talks to Neutron in that session 14:20:25 <tonanhngo> It requires the service endpoints, so that's what Magnum configures 14:20:52 <apuimedo> so magnum makes keystone and neutron available in the overlay 14:21:12 <tonanhngo> for the user credential, Magnum does not handle it. We leave it to the user to log into the node and type in the credential 14:21:53 <tonanhngo> Yes, the user VM can access the services 14:22:29 <tonanhngo> I haven't checked from the Flannel overlay, but I think the pods can reach the services also, but the pods would not have the credential 14:22:57 <apuimedo> ok. I'll try to set up a devstack to check it out 14:23:01 <apuimedo> thanks tonanhngo 14:23:22 <tonanhngo> There is a concern that the pods can reach the config files and get the credential, but we don't deal with that since that's how Kubernetes set it up 14:23:23 <vikasc> thanks tonanhngo 14:23:29 <janonymous> I guess authentication code is for reference: https://github.com/kubernetes/kubernetes/blob/master/pkg/cloudprovider/providers/openstack/openstack.go#L219 14:23:31 <tonanhngo> np 14:23:32 <apuimedo> #action apuimedo, vikas to work out the auth remotedriver-> rpc driver 14:23:43 <apuimedo> thanks janonymous 14:23:54 <apuimedo> #link https://github.com/kubernetes/kubernetes/blob/master/pkg/cloudprovider/providers/openstack/openstack.go#L219 14:24:01 <apuimedo> #topic kuryr-libnetwork 14:24:51 <apuimedo> #info the contents of the 'common' package have been moved to the base package as agreed, thanks to vikas' patch https://review.openstack.org/361567 14:25:08 <apuimedo> some code cleanups as well 14:25:15 <apuimedo> #link https://review.openstack.org/362857 14:26:01 <apuimedo> #info sample config file generation is now generated by a script that prevents common mistakes when using oslo-config-generator 14:26:06 <apuimedo> #link https://review.openstack.org/364240 14:26:30 <apuimedo> this will prevent the wrong config being generated when you are working on config patches 14:27:07 <apuimedo> #info limao fixed the MTU bug that meant that MTU was not being retrieved from Neutron 14:27:22 <apuimedo> #link https://review.openstack.org/#/c/355714/ 14:27:54 <apuimedo> #info Docker 1.9 compat patch was merged as well https://review.openstack.org/352768 14:28:18 <apuimedo> #info devstack should now be back into a working state 14:28:47 <apuimedo> limao: did you try https://review.openstack.org/365336 14:28:57 <apuimedo> I wonder if the job now completes successfully 14:29:30 <limao> job has not passed yet 14:29:34 <limao> I will check them 14:30:00 <apuimedo> limao: thanks 14:30:03 <janonymous> i will help too.. 14:30:14 <apuimedo> #action limao and janonymous to check the rally jobs 14:30:16 <apuimedo> :-) 14:30:41 <limao> :-) 14:31:47 <apuimedo> #action vikasc apuimedo to review https://review.openstack.org/#/c/363414/1 14:32:10 <apuimedo> we had originally screwed up the move from 2376 to 23750 14:32:53 <apuimedo> anything else about kuryr-libnetwork? 14:33:40 <apuimedo> alright, moving on 14:33:48 <apuimedo> #topic kuryr-kubernetes 14:34:13 <apuimedo> #info last Thursday a kuryr-kubernetes videoconf meeting was held 14:34:29 <apuimedo> #info More information about it can be found on the mailing list 14:34:41 <flaper87> Are there recordings of that meeting? 14:36:34 <apuimedo> flaper87: can be provided on demand 14:36:36 <apuimedo> :-) 14:36:48 <apuimedo> but I made quite extensive meeting points 14:36:55 <apuimedo> in the mailing list 14:37:14 <vikasc> apuimedo, agree 14:37:29 <apuimedo> #info devvesa is working on the python3 upstreaming 14:37:55 <apuimedo> #info ivc_ is working on a py2/py3 eventlet PoC that matches its features 14:38:09 <apuimedo> we're reviewing both 14:38:44 <apuimedo> #info There is a new spec proposal for the watcher/translator interaction for kuryr-kubernetes 14:38:55 <apuimedo> #link https://review.openstack.org/365600 14:39:01 <apuimedo> I appreciate reviews 14:39:03 <devvesa> still have to take a deep look, but I like it :) 14:39:12 <apuimedo> specially from devvesa and ivc_, since they are implementing 14:39:15 <apuimedo> cool 14:40:05 <apuimedo> we should be studying studying also the Magnum deployment for the kubernetes integration 14:40:07 <ivc_> +1 devvesa. tho need to take a deeper look at it 14:40:15 <apuimedo> (what I was saying earlier was more for kuryr-libnetwork) 14:40:45 <apuimedo> #action apuimedo, vikas to review https://review.openstack.org/363758 14:40:58 <vikasc> sure 14:41:24 <devvesa> btw, this patch introduces kind of first approach 14:41:27 <apuimedo> #action apuimedo, devvesa, ivc to come up with a functional testing approach for the gates 14:41:27 <devvesa> https://review.openstack.org/#/c/363758/ 14:41:46 <apuimedo> #link https://review.openstack.org/#/c/363758/ 14:42:14 <apuimedo> thanks limao for getting so fast to testing the libnetwork gates :-) 14:42:34 <limao> :-) 14:42:39 <apuimedo> alright, does anybody else have stuff for kubernetes integration? 14:42:41 <devvesa> for functional testing first we should create a devstack plugin to deploy, right? 14:42:54 <apuimedo> devvesa: yes 14:43:02 <devvesa> any volunteer in the room?? :D 14:43:04 <apuimedo> probably minikube 14:43:13 <apuimedo> :-) 14:43:31 <ivc_> minukube is virtualbox based i'm afraid 14:43:39 <devvesa> ivc_ yes 14:43:44 <apuimedo> oh, sorry, ivc_, I meant hyperkube 14:43:46 <apuimedo> xD 14:43:48 <ivc_> or more specifically its vagrant 14:44:09 <apuimedo> I prefer bare-metal for starters 14:44:18 <apuimedo> so hyperkube should serve us 14:44:19 <devvesa> I think this script can run on local 14:44:22 <devvesa> https://github.com/kubernetes/kubernetes/blob/master/hack/local-up-cluster.sh 14:44:30 <devvesa> without nothing else than Go 1.6 14:44:38 <devvesa> But I haven't tried so far. 14:44:49 <apuimedo> devvesa: compiling and running all in the gate may be too resource intensive 14:44:50 <ivc_> i think we can just go with hyperkube 14:44:53 <devvesa> What's true is that a functional testing is mandatory 14:44:54 <janonymous> +8gb ram for build , 64bit os 14:45:03 <apuimedo> that's far too much 14:45:09 <devvesa> :( 14:45:11 <apuimedo> I propose devstack plugin with hyperkube 14:45:18 <ivc_> +1 on that 14:45:27 <apuimedo> and that the kubelet container mounts the CNI driver on a volume 14:45:31 <devvesa> last time I looked at, I could not find the command that spawns hyperkube anymore 14:45:40 <apuimedo> really? 14:45:52 <pablochacin> apuimedo: I think it is deprecated 14:45:55 <apuimedo> #action apuimedo to check hyperkube for signs of life 14:46:06 <apuimedo> pablochacin: that makes me a bit grumpy 14:46:13 <devvesa> #action apuimedo ask to Kubernetes-dev on Slack :) 14:46:25 <apuimedo> installing Slack again... 14:46:28 <apuimedo> ok, ok 14:46:32 <apuimedo> I'll get to that too 14:46:36 <devvesa> I can do it, no problem 14:46:53 <apuimedo> #action devvesa to ask about hyperkube on kubernetes-dev slack 14:46:55 <ivc_> i've got hyperkube-based deployment on my poc. i'll be adding details on that to my research doc 14:46:56 <apuimedo> thanks devvesa 14:47:01 <janonymous> minikube maybe but not sure 14:47:35 <apuimedo> let's try to come up with the necessary info to take a decision for next Monday ;-) 14:47:48 <vikasc> +1 14:47:57 <apuimedo> #info next meeting to discuss and decide the testing approach and tools 14:48:07 <apuimedo> anything else? 14:48:12 <irenab> apuimedo: yes 14:48:28 <irenab> just procedural question about docs location 14:48:58 <apuimedo> #info Usage docs should go on kuryr-kubernetes / kuryr-libnetwork 14:49:05 <irenab> should devrefs be hosted on the kuryr-k8s or kuryr repo? 14:49:08 <apuimedo> #info specs on openstack/kuryr 14:49:17 <irenab> apuimedo: thanks 14:49:30 <apuimedo> if everybody disagrees we can change it though 14:49:44 <apuimedo> I just want to minimize the effort to add info for now 14:49:51 <irenab> apuimedo: design on k8s/libnetwork 14:50:17 <apuimedo> and approving the specs on one place, making it easier to refer to one another seems more comfy to me 14:50:32 <apuimedo> irenab: please, elaborate 14:50:38 <irenab> apuimedo: specs are not devrefs 14:50:46 <irenab> devrefs are more design 14:50:54 <irenab> spec are more requirements 14:51:01 <apuimedo> irenab: the distinction gets a bit lost on me, sorry 14:51:11 <apuimedo> so probably my last patch is more of a devref 14:51:16 <irenab> spec is about what and devref is about how 14:51:32 <irenab> at least its how I get it 14:51:33 <apuimedo> irenab: I'd be grateful if you could help me understand it with examples of our current doc 14:51:39 <apuimedo> it can be offline 14:51:45 <apuimedo> and I'll send an email to the mailing list 14:51:47 <devvesa> we may need to add new directory for 'why' 14:51:48 <apuimedo> so we can all wigh in 14:51:51 <apuimedo> and decide 14:51:53 <devvesa> (sorry, bad jokes) 14:52:04 <apuimedo> devvesa: :-) 14:52:07 <devvesa> (you know I support you, Irena) 14:52:10 <irenab> apuimedo: sure, but just for now, devrefs are to be in specific or the general kuryr one? 14:52:27 <apuimedo> irenab: until we take it to the ML yes 14:52:41 <apuimedo> the current status was all devref and specs go to openstack/kuryr 14:53:08 <apuimedo> but I agree that the implementation heavy documentation will probably live better in kuryr-libnetwork and kuryr-k8s 14:53:11 <irenab> as long as there is guideline, it does not matter too much 14:53:13 <apuimedo> ;-) 14:53:32 <apuimedo> I guess most of us have the four repos cloned in any case 14:53:37 <apuimedo> so we'll find the better fit 14:53:45 <apuimedo> but it's not a showstopper, I hope 14:53:54 <apuimedo> but let's have it fixed soon 14:54:03 <apuimedo> other questions/comments? 14:54:22 <irenab> apuimedo: question about new added sub project for storage 14:54:29 <apuimedo> I'm not getting to the address pairs point in the agenda since icoughlan couldn't attend 14:54:35 <apuimedo> irenab: go ahead 14:55:09 <apuimedo> #action gsagie to get fuxi people on the weekly meetings so that they also participate :-) 14:55:10 <irenab> does it has its own core reviewers? How it is going to be managed, blueprints, specs, etc.? 14:55:25 <apuimedo> irenab: it does not have its own core reviewers yet 14:55:34 <apuimedo> the idea, just as with libnetwork and kubernetes 14:55:41 <apuimedo> is that they can get their own cores 14:55:53 <apuimedo> but kuryr-core people will keep core over the repo as well 14:56:30 <apuimedo> irenab: oh, sorry, correction, the main developer is a core 14:56:36 <apuimedo> Zhang Ni 14:56:47 <irenab> apuimedo: and for specs, devrefs, will be the same policy like with k8s/libnetwork? 14:56:50 <apuimedo> so it would be good if he can join the weekly meetings 14:57:04 <apuimedo> irenab: we should try to have the same policy for all 14:57:23 <irenab> apuimedo: makes sense 14:57:35 <apuimedo> It should make us be flexible enough 14:57:41 <apuimedo> #topic open discussion 14:57:50 <apuimedo> any other open discussion item in these last three minutes? 14:58:31 <apuimedo> I'd like to remind everybody about the mailing list thread to discuss and propose topics for the summit work sessions 14:58:51 <devvesa> Thanks for the agenda, btw 14:59:08 <apuimedo> devvesa: you're most welcome 14:59:19 <devvesa> I think that a reminder and agenda suggestions can provide attention from other projects/people 14:59:24 <apuimedo> although I should have published it the latest on friday 14:59:31 <apuimedo> indeed 14:59:57 <apuimedo> #action apuimedo to post the agenda by Thursday and ML reminder so people have time to add items 15:00:06 <devvesa> We should kind of improve our visibility. Devstack/functional test is an example that we need collaborators 15:00:23 <devvesa> However, I ignore how to do it 15:00:27 <apuimedo> devvesa: any proposal? 15:00:29 <apuimedo> ah, ok 15:00:31 <apuimedo> :-) 15:00:37 <apuimedo> well, increasing ML communication is the easiest way 15:00:41 <apuimedo> also, if you are trying things 15:00:44 <devvesa> yes. and first one 15:00:47 <apuimedo> please blog and twit about it! 15:01:04 <devvesa> that was another idea... but I am afraid I have no time to blog properly 15:01:10 <apuimedo> we all love to know what everybody else is doing 15:01:14 <apuimedo> devvesa: then twit ;-) 15:01:16 <apuimedo> for example 15:01:21 <devvesa> a blog post is an amount of work considerable 15:01:49 <devvesa> Oh, my twitter account is only about cycling :D I'll have to create another account 15:01:53 <apuimedo> gotten #openstack #kuryr #kubernetes python3 upstreaming to work with pod translation 15:01:55 <apuimedo> :-) 15:02:06 <apuimedo> devvesa: do it then ;-) 15:02:15 <apuimedo> or I'll make a kurry logo on bicycle 15:02:22 <apuimedo> Thank you all for joining! 15:02:25 <devvesa> thanks! 15:02:28 <apuimedo> have a nice and productive week 15:02:30 <apuimedo> #endmeeting