22:00:26 #startmeeting containers 22:00:27 Meeting started Tue Sep 22 22:00:26 2015 UTC and is due to finish in 60 minutes. The chair is adrian_otto. Information about MeetBot at http://wiki.debian.org/MeetBot. 22:00:28 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 22:00:30 The meeting name has been set to 'containers' 22:00:32 #link https://wiki.openstack.org/wiki/Meetings/Containers#Agenda_for_2015-09-22_2200_UTC Our Agneda 22:00:41 #topic Roll Call 22:00:43 o/ 22:00:44 Adrian Otto 22:00:51 o/ 22:00:51 Steven Wilson 22:00:52 o/ 22:00:52 Ton Ngo 22:00:53 o/ 22:00:54 Perry Rivera o/ 22:00:54 o/ 22:00:55 Wanghua 22:00:59 o/ 22:01:05 o/ 22:01:13 o/ 22:01:39 hello mfalatic, daneyon_, Tango, muralia, juggler, eghobo, wanghua, rods, hongbin, bradjones 22:01:45 o/ 22:01:51 hello! 22:01:53 hi 22:01:55 hello Drago 22:02:05 o/ 22:02:10 :) hi all 22:02:11 hello 22:03:02 #topic Announcements 22:03:49 o/ 22:04:03 due to a compounded sequence of events, there was no candidate submitted for Magnum PTL prior to the deadline for candidacy submission. 22:04:34 Both Hongbin and I submitted entries after the deadline, so the TC has decided to hold a separate election to decide who the PTL will be going forard. 22:04:59 the electorate is Magnum contributors. 22:05:16 when the dates for that election is known, we will relay them to you 22:05:19 any questions? 22:05:36 none here 22:05:49 nope 22:05:51 any other announcements from team members? 22:06:12 hello wznoinsk 22:06:34 #topic Container Networking Subteam Update (daneyon_) 22:06:41 #link http://eavesdrop.openstack.org/meetings/container_networking/2015 Previous Meetings 22:06:45 thx 22:06:55 \o 22:07:00 we had our weekly meeting as usual last Thurs 22:07:01 o/ 22:07:12 We reviewed the kuryr design spec 22:07:22 #link https://review.openstack.org/#/c/213490/ 22:07:34 the spec has +1's from the magnum community 22:07:50 now it's a metter of getting the CR's to vote and merge 22:08:14 I created a bp for the kuryr/magnum integration work 22:08:16 #link https://blueprints.launchpad.net/kuryr/+spec/containers-in-instances 22:08:41 the bp will be the reference point for both communities 22:08:54 last but not least.... 22:09:10 I have the magnum container networking model working for swarm bays 22:09:18 as of 1 hour ago 22:09:45 awesome news! 22:09:46 yeah! 22:09:52 daneyon_: use flannel? 22:10:15 i can instantiate a swarm bay with multiple nodes, pass the network-driver, labels to modify flannel config attributes. I can deploy multiple containers using swarm across multiple nodes and containers can communicate with one aother over the flannel overlay network 22:10:21 yes, using flennel 22:10:40 fennel ;-) mmmmm, yummy 22:10:47 as part of this effort, I changed swarm discovery to use etcd instead of public discovery. 22:11:09 ectd need discovery, too 22:11:12 the key issue, we can not support multiple disocvery processes in a single bay 22:11:55 since flannel is required (it's our only support network-driver), swarm needs to implement etcd 22:12:08 lol 22:12:31 wanghua correct, etcd still uses the public discovery mechanism. 22:12:55 we just can;t have swarm and etcd both using public discovery. 22:12:59 daneyon_: but we have one etcd at master 22:13:13 we have zookeper for mesos 22:13:34 eghobo: I don't think zookeeper is good for service discovery 22:13:34 We can let swarm use the etcd in bay 22:14:03 it's possible to have multiple discovery processes in a bay, it would require larger code changes though 22:14:07 hongbin_: zookepeer was just example 22:14:20 eghobo: k 22:14:21 ok, lets wrap up the Network subteam update if we can 22:14:37 eghobo swarm did not use etcd 22:14:55 hongbin_ i have yet to look at the mesos stuff 22:15:24 daneyon_: let me know if you need help for mesos bay 22:15:40 if we need to support multiple public discovery mechanisms in a bay, then we will need to make bigger changes to how the public_url is implemented. 22:15:58 If i have a bay with zk and etcd, they each need their own public_url for public discovery 22:15:59 daneyon_:Swarm can use etcd in the bay to discover like in k8s 22:16:57 wanghua that's what i implemented. swarm uses etcd and etcd uses the public-url for it's public discovery mechanism. 22:17:21 daneyon_: swarm support etcd already. 22:17:23 here is the current work 22:17:25 #link https://review.openstack.org/#/c/224367/ 22:17:38 it's funcational, so give it a spin 22:18:17 daneyon: Thanks for all the awesome work. This is super exciting to see!! Does this conclude your update? 22:18:21 wanghua correct. However, magnum was not using etcd to back swarm, it was using swarm's public discovery 22:18:38 adrian_otto yes 22:18:46 any other questions we can take off line 22:18:47 daneyon_: We can make a little adjustment 22:18:49 thanks daneyon_ 22:18:53 yw 22:18:54 #topic Magnum UI Subteam Update 22:19:04 bradjones: any update to share? 22:19:09 sure 22:19:30 not a huge update (was on vacation last week) 22:19:45 we managed to merge some of the API work 22:19:55 big thanks to those that have been active reviewing 22:20:18 going to rebase my WIP patches that have the views for Bay and BayModel tomorrow 22:20:27 onto that code 22:20:42 then hopefully will be on track to merge those views in by the end of the week 22:20:59 sweet! Any questions for Brad? 22:21:33 thanks bradjones 22:21:36 #topic Review Action Items 22:21:44 adrian_otto to follow up with project-config cores to ask if we can arrange to merge https://review.openstack.org/216933 22:21:49 Status: COMPLETE 22:21:52 the code is merged 22:22:10 ^^ 1) 22:22:16 2) Tango and manjeets_ to work together to complete https://blueprints.launchpad.net/magnum/+spec/external-lb 22:22:26 I have seen a series of advancements on that BP 22:22:40 is this action complete? 22:22:47 The latest patch works end to end 22:22:53 WHOOT 22:22:59 There is the issue about handling the password 22:23:35 after some discussion and feedback from the team, I decided to take the manual approach to avoid any potential security issue 22:23:46 Handling the password is a common issue in several bps 22:23:53 later we can investigate and evaluate the several approaches 22:24:08 very helpful suggestions from the team 22:24:15 Tango: I think DNS is issue 22:24:28 not everyone run Designate 22:24:51 ok, I can follow up with you to better understand 22:25:01 ok, let's revisit this in just a moment when we get to this in BP/Bug Review 22:25:37 Tango: should I carry this action item forward, or should we consider it done? 22:25:47 I think it's done 22:25:48 I think it's done, but want to be sure you see it that way 22:25:51 ok 22:25:56 Status: COMPLETE 22:25:59 #topic Blueprint/Bug Review 22:26:07 Essential Blueprint Updates 22:26:14 #link https://blueprints.launchpad.net/magnum/+spec/objects-from-bay Obtain the objects from the bay endpoint (vilobhmm) 22:26:22 vilobhmm11: update on this? 22:26:30 working on making changes since v1 patch merged yest 22:26:36 so some test are breaking 22:26:39 fixing them 22:26:49 adrian_otto : ^^ 22:27:17 ok. IS there any help you need from the team to keep moving on this? 22:27:44 need help esp with the unit tests 22:27:55 our unit test framework is closely tied to DB 22:28:01 with objects from bay 22:28:09 we are removing this tight coupleing 22:28:30 mostly help with unit test would be handy 22:28:38 right, so many unit tests will need to be refactored, right? 22:28:51 adrian_otto : yes 22:29:17 almost every unit test in read/write path for service/rc/pod needs to be modified 22:29:30 ok, if we have a way to identify all the tests that need to be refactored, and make somme sort of a list that references them we can point contributors to that and ask for help adjusting them all 22:29:41 it might be nice if we could show an example of how to fix them 22:29:59 adrian_otto : will do so..have an etherpad link up by tommorow 22:30:11 and how to do them as patches that depend on the refactor review 22:30:30 is there one particular commit that needs to merge before all the unit tests are adjusted? 22:30:37 or does this need to be done all as one big patch? 22:30:57 I have separtaed out patches for each object seperately 22:31:07 seperate patch for rc/service/pod 22:31:37 ok, any questions on this from the team? 22:31:56 adrian_otto : does the above info answer your question ? 22:32:04 yes, thanks 22:32:10 ok np 22:32:30 thats it from objects-from-bay 22:32:44 thanks vilobhmm11 22:32:44 #link https://blueprints.launchpad.net/magnum/+spec/secure-kubernetes Secure the client/server communication between ReST client and ReST server (madhuri) 22:32:54 madhuri is not present 22:33:10 most of this has been merged. 22:33:25 apmelton: any comments on this one? 22:33:38 not for k8s specifically 22:33:45 ok 22:33:48 #link https://blueprints.launchpad.net/magnum/+spec/external-lb Support the kubernetes service external-load-balancer feature (Tango) 22:34:05 One good news is that the Kubernetes-V1 patch merged 22:34:13 that makes things a lot easier 22:34:39 yay! 22:34:42 As mentioned earlier, the patch for LB should be good now, but it needs review 22:34:54 excellent Tango 22:35:00 (and team) 22:35:12 I am writing a guide to explain how to use the feature 22:35:25 want to post links to work needing review? 22:35:39 Tango, is the feature optional? 22:35:41 https://review.openstack.org/#/c/191878/ 22:35:55 maybe these? 22:36:06 #link https://review.openstack.org/#/q/status:open+project:openstack/magnum+branch:master+topic:bp/external-lb,n,z external-lb reviews 22:36:13 wanghua: Yes with the manual step for editing the password, the feature is disabled by default 22:36:49 the user needs to log into the master node to enter the password in a config file, then restart kube-apiserver and kube-controller-manager 22:37:04 So you have the option of not using the feature 22:37:47 user = administrator 22:38:04 Right 22:38:14 I am adding a functional test using nginx 22:38:41 Tango: adrian_otto Don't think so, anyone who create the bay can be a user, not necessary an admn 22:38:47 ok, sounds like some automation there might be a nice future enhancement. We should file bugs or BP's for that when these are finished. 22:39:22 hongbin_: right. I can't remember the official name of the persona who owns the bay. 22:39:36 I suppose "cloud user" is right then 22:39:52 k 22:39:55 Right, we need to evaluate best support to implement the additional automation to handle the password 22:40:06 there are several approaches 22:40:13 As handling user credentials in the bays is a common issue in several bps, we need to decide a way 22:40:25 yes 22:40:43 Can we use trust? 22:40:58 if we can wanghua, I'd much prefer it 22:41:12 we also have this concern for the Docker Distribution (registry-v2) component 22:41:26 I think trust requires token? 22:41:32 Tango: rather than a password, did you mean an auth token? 22:41:33 I seem to remember seeing a 'trust-id' config param for Docker Distribution 22:41:53 auth token will expire 22:41:56 because if you support an auth token, then it can take a trust token too. 22:42:02 adrian_otto: That would be the ideal solution, but will require change in kus 22:42:05 k8s 22:42:05 and the trust token can be scoped to have a far future expiry 22:42:57 I see. First things first. Let's make it work, and then iterate on it to make it better. 22:42:57 If we don't give expire time when we create trust, then the trust will never expire. 22:43:19 wanghua: exactly 22:43:36 if there is a common set of requirement for several BPs, we should pull together and see if this can be solved in a common way. 22:43:48 this might also fold into the instance user discussion that's ongoing in nova currently 22:44:42 adrian_otto, any reference? 22:44:51 for nova discussion 22:44:53 #link https://review.openstack.org/#/c/222293/1/specs/instance-users.rst,cm Instance Users Spec 22:45:26 More homework to be done 22:45:43 #link https://review.openstack.org/222293 Instance Users for Cloud Interaction 22:46:09 ok, thanks Tango. Lots of good progress this past week, thanks! 22:46:24 #link https://blueprints.launchpad.net/magnum/+spec/secure-docker Secure client/server communication using TLS (apmelton) 22:46:49 I've got a review up on this 22:46:52 with some good input 22:46:53 https://review.openstack.org/212598 22:47:06 #link https://review.openstack.org/#/c/212598/ 22:47:14 #link https://review.openstack.org/212598 Add TLS to Docker-Swarm Template (WIP) 22:47:30 what's remaining to promote this from WIP to normal status? 22:47:54 I need to add an 'insecure' flag so tls can be disabled 22:48:22 can we do that as a follow-up review that is WIP that depends on this one? 22:48:53 or do you see that as a minor addition (not making any assumptions here) 22:48:58 actually, if this patch lands, and you can't disable TLS the container conductor will be broken 22:49:03 ok 22:49:19 yes, I remember that now rom the midcycle… catching up on the comment stream 22:49:29 ok 22:49:40 my next step after adding the insecure flag is going to be working through what's necessarily to get the conductors talking TLS 22:50:22 I'll be breaking that suffiently so it can be shared between conductors for k8s/swarm/mesos/etc 22:50:42 Sweet! Any more before we advance to Open Discussion? 22:50:51 not from me 22:50:54 #topic Open Discussion 22:50:57 thanks apmelton 22:51:17 any status highlights for the Japan Summit? 22:51:40 you mean in term of highlighting new features we added in this release? 22:52:53 sure and general status of prep work towards the the summit, etc. 22:52:56 I have a question 22:53:04 about container-create cli command 22:53:11 Would request core-reviewers to merge https://review.openstack.org/#/c/226491/ - this will fix functional test failure and help others proceed 22:53:33 juggler: that's something we will pick up as soon as the PTL election concludes 22:54:10 adrian_otto: excellent 22:54:15 Does magnum support ironic now? 22:54:34 yes, there are heat templates for ironic 22:54:44 but ironic does not completely support neutron 22:55:08 Then it can not work? 22:55:14 so depending on how your network is laid out, you may have some tweaking to do in order to make it work right with your network setup 22:55:28 it's not universally compatible with all network drivers. 22:55:30 is there plan to add glance integration for container-create command? i.e. provide ability to access/use containers which are in glance as part of container-create 22:56:07 devkulkarni: not that I'm aware of. I'd suggest using Heat for that. 22:56:25 Why we need to do this 22:56:34 Heat in combination with this: https://review.openstack.org/193174 22:56:36 I think you can do it by nova-docker 22:57:00 wanghua: nobody is really maintaining nova-docker 22:57:48 adrian_otto: but heat won't do the scheduling of containers on the bay nodes, right? so I was thinking of using the container-create within solum to run application containers on the bay nodes. 22:58:13 devkulkarni: if you are using the code I referenced, heat uses a Magnum Bay 22:58:15 solum has ability to store application containers in glance and swift 22:58:23 and the Bay includes the scheduling capability 22:58:57 I think you can use swarm to do it 22:59:06 and put the image in docker registry 22:59:07 adrian_otto: ok, will take a closer look at it. I haven't yet started on the integration yet 22:59:16 for that integration, you'd want to place the images in the private repo we put in swift with Docker Distribution 22:59:20 then pull from that 22:59:34 we are coming to the scheduled end of our meeting time now 22:59:37 adrian_otto: yes, that is one option 23:00:00 wanghua: yes, that is an option 23:00:08 Our next team meeting is scheduled for Tuesday 2015-09-29 at 1600 UTC. 23:00:23 see you then. Thanks everyone! 23:00:26 #endmeeting