16:00:21 <adrian_otto> #startmeeting containers
16:00:21 <openstack> Meeting started Tue Sep 15 16:00:21 2015 UTC and is due to finish in 60 minutes.  The chair is adrian_otto. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:22 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:24 <openstack> The meeting name has been set to 'containers'
16:00:28 <adrian_otto> #link https://wiki.openstack.org/wiki/Meetings/Containers#Agenda_for_2015-09-15_1600_UTC Our Agenda
16:00:32 <adrian_otto> #topic Roll Call
16:00:36 <adrian_otto> Adrian Otto
16:00:37 <xek> o/
16:00:42 <fawadkhaliq> o/
16:00:43 <eghobo> o/
16:00:44 <rlrossit> o/
16:00:44 <mfalatic> o/
16:00:46 <wanghua> o/
16:00:51 <rpothier> o/
16:00:56 <madhuri> o/
16:00:56 <dave-mccowan> o/
16:01:01 <Tango> Ton Ngo
16:01:07 <hongbin> o/
16:01:09 <muralia> o/
16:01:09 <thomasem> o/
16:01:26 <juggler> o/ [slow connection possibly because of rain?]
16:01:53 <adrian_otto> hello xek, fawadkhaliq, eghobo, rlrossit, mfalatic, wanghua, rpothier, madhuri, dave-mccowan, Tango, hongbin, muralia, thomasem, and juggler
16:01:58 <vilobhmm_11> o/
16:02:03 <muralia> hey all
16:02:22 <adrian_otto> hello vilobhmm_11
16:02:25 <juggler> good localtime all
16:02:30 <adrian_otto> ;-)
16:02:35 <daneyon_> o/
16:02:39 <vilobhmm_11> hello adrian_otto,  hello all
16:02:47 <daneyon_> hola!
16:02:52 <adrian_otto> I'm happy to see you back, madhuri
16:03:08 <hongbin> welcome back
16:03:45 <juggler> hello hello :)
16:04:02 <madhuri> Thanks adrian_otto hongbin :)
16:04:14 <madhuri> I am happy too
16:04:25 <adrian_otto> ok, let's begin.
16:04:30 <adrian_otto> #topic Announcements
16:04:36 <adrian_otto> any announcements from team members?
16:05:23 <daneyon_> It's raining in So Cal!!!
16:05:27 <daneyon_> :-)
16:05:29 <thomasem> awww yissss
16:05:33 <adrian_otto> well, that's true
16:05:37 <thomasem> put your water bottkes out
16:05:37 <dave-mccowan> I'm visiting from the Barbican team.  I wanted to let you all know that our subCA blueprint is mostly complete now and our "snakeoil" development CA is working, if you guys are ready to test with it.
16:05:38 <madhuri> I have joined Intel
16:05:40 <juggler> ^^ :)
16:05:43 <thomasem> bottles*
16:05:44 <adrian_otto> first meaningful rain in months
16:05:48 <apmelton> o/
16:05:55 <adrian_otto> #topic Container Networking Subteam Update (daneyon)
16:05:59 <adrian_otto> hello apmelton
16:06:12 <adrian_otto> #link http://eavesdrop.openstack.org/meetings/container_networking/2015 Previous Meetings
16:06:15 <daneyon_> Lets talking networking
16:06:38 <daneyon_> IMO The kuryr design spec is close to being merged
16:06:44 <madhuri> Thank dave-mccowan for the information
16:07:06 <daneyon_> I worked with gsagie yesterday to dive deeper into kuryr/magnum integration
16:07:35 <daneyon_> I am going to create a Kuryr BP in the next day or two to highlight the details for the initial integration.
16:07:54 <adrian_otto> I heard from gsagie__ who invited us to collaborate in a Neutron design session for kuryr at the tokyo summit
16:07:57 <daneyon_> All the Magnum Container Networking Model patches are out of WIP
16:08:28 <daneyon_> I was having problems getting the cross repo dependencies to work, so the func tests were failing in the gate for 2 patches
16:08:36 <adrian_otto> whoot!
16:08:51 <adrian_otto> was == resolved now?
16:09:10 <daneyon_> I have pulled the client test code from the 2 patches and just resubmitted. They should now pass and be ready to merge.
16:09:25 <daneyon_> I will add the client tests back in when the 2 client patches are merged
16:09:44 <daneyon_> It might be best to get everyone to vote on the client patches asap
16:10:00 <adrian_otto> ok, go ahead and drop links to them here now
16:10:12 <daneyon_> when those 2 hit, then I can add the client tests back in or submit a follow-on patch
16:10:43 <daneyon_> adrian_otto yes, as a workaround I removed the client tests for labels and net-driver
16:10:53 <daneyon_> the cross repo dependency thingy does not work
16:11:19 <adrian_otto> are those https://review.openstack.org/222749 and https://review.openstack.org/215260?
16:11:20 <daneyon_> i tried every which way to create a dependency from my magnum patches to the client patches, but no luck
16:11:48 <adrian_otto> ok, any more for the networking update?
16:11:51 <daneyon_> adrian_otto yes those are the 2 client patches that need to get merged
16:11:58 <daneyon_> nope
16:12:15 <adrian_otto> thanks
16:12:18 <daneyon_> yw
16:12:19 <adrian_otto> #topic Magnum UI Subteam Update
16:12:30 <adrian_otto> bradjones: yt?
16:13:03 <adrian_otto> we merged the initial repo
16:13:12 <adrian_otto> and there is a review up for an API client:
16:13:36 <adrian_otto> #link https://review.openstack.org/222617 Add magnum api client
16:14:24 <adrian_otto> #link https://blueprints.launchpad.net/magnum-ui/+spec/bay-model-api Create API hook for bay model
16:14:28 <adrian_otto> that's the BP it's for
16:14:36 <hongbin> Those reviews are full of html and javascript. Need horizon experts to review
16:14:49 <vilobhmm_11> hongbin : +1
16:15:03 <adrian_otto> yes, that's why we have a ui core group with UI skills
16:15:32 <adrian_otto> so there is notable progress since last week. I just wanted to take a moment to highlight that
16:16:01 <adrian_otto> any other discussion on magnum-ui?
16:16:16 <adrian_otto> #topic Review Action Items
16:16:25 <adrian_otto> #action adrian_otto to follow up with project-config cores to ask if we can arrange to merge
16:16:42 <adrian_otto> I am carrying this forward from last week. I was not able to make this move at all yet
16:16:51 <juggler> excellent!
16:16:56 <adrian_otto> 2) Tango and manjeets_ to work together to complete https://blueprints.launchpad.net/magnum/+spec/external-lb
16:17:05 <adrian_otto> Tango: ?
16:17:15 <Tango> We got a bit of good news
16:17:24 <adrian_otto> #undo
16:17:24 <openstack> Removing item from minutes: <ircmeeting.items.Action object at 0xa285950>
16:17:26 <Tango> I wrote the details on the BP
16:17:40 <adrian_otto> #action adrian_otto to follow up with project-config cores to ask if we can arrange to merge https://review.openstack.org/216933
16:17:55 * adrian_otto looks at BP
16:18:12 <Tango> basically after adding lots of logging in k8s and stepping through the code, we figured out the discrepancies
16:18:25 <Tango> between what k8s expects and magnum provides
16:18:35 <Tango> once we fixed those, the load balancer works
16:18:52 <Tango> the patches have been updated with the fixes, I am about to upload them
16:18:59 <adrian_otto> oh, sweet!
16:19:12 <Tango> Gus has been very helpful with consultation and pointers
16:19:14 <adrian_otto> so we should be landing this in a few days?
16:19:24 <Tango> he even tried to build devstack with magnum
16:19:31 <Tango> yes we are wrapping up
16:19:37 <adrian_otto> that's terrific!
16:19:56 <Tango> Manjeet is working on the patch to set the parameters, I am adding functional test with nginx
16:20:07 <Tango> Will try wordpress later
16:20:16 <adrian_otto> manjeet was scheduled to arrive at the OSIC in San Antonio yesterday
16:20:26 <adrian_otto> not sure if he is settled in yet
16:20:36 <apmelton> hope it's started to cool off down there!
16:20:42 <Tango> He mentioned he should be able to resume this week
16:20:56 <Tango> I will work with him on the patch
16:21:15 <adrian_otto> ok, so for this action item, we should carry it forward to next week?
16:21:31 <Tango> Sure, for completeness
16:22:22 <adrian_otto> #action Tango and manjeets_ to work together to complete https://blueprints.launchpad.net/magnum/+spec/external-lb
16:22:35 <adrian_otto> that concludes action items
16:22:52 <adrian_otto> #topic Blueprint/Bug Review
16:22:59 <adrian_otto> Essential Blueprint Updates
16:23:11 <adrian_otto> #link https://blueprints.launchpad.net/magnum/+spec/objects-from-bay Obtain the objects from the bay endpoint (vilobhmm_11)
16:23:31 <vilobhmm_11> After a positive signal from hongbin on the proposed approach for WIP : Objects from Bay - Replication Controller : https://review.openstack.org/#/c/213368/
16:23:43 <vilobhmm_11> proposed 2 new patches for service and pods object
16:23:49 <vilobhmm_11> WIP : Objects from Bay - Services : https://review.openstack.org/#/c/223384/
16:23:54 <vilobhmm_11> WIP : Objects from Bay - Pods : https://review.openstack.org/#/c/223367/
16:23:59 <adrian_otto> what's happening with the gate tests on that patch?
16:24:18 <adrian_otto> both of them seem to be failing the py27 test
16:24:41 <vilobhmm_11> need to fix it…the reason for that is till now create used to happen using db..but that has now changed for these objects https://github.com/openstack/magnum/blob/master/magnum/tests/unit/objects/utils.py#L152
16:24:48 <vilobhmm_11> will fix it
16:24:50 <adrian_otto> ok, I see they are WIP
16:25:26 <hongbin> One more thing I want to mention for the patch
16:25:27 <adrian_otto> you can mark them as workflow -1 as well as a signal that you are about to post a revision
16:25:43 <hongbin> Consider set a dependency to the k8s v1 patch
16:25:53 <adrian_otto> this will help optimize reviewer time so you get us to see the next one rather than this one
16:25:55 <vilobhmm_11> adrian_otto : but as compared to last week I now have all 3 objects covered…will remove the WIP once i fix them…we should have clean patches with jenkins +1 soon
16:26:06 <hongbin> Otherwise, it will possibly break after the k8s client upgrade
16:26:06 <adrian_otto> ok, sweet
16:26:25 <vilobhmm_11> hongbin : sure
16:26:34 <hongbin> vilobhmm_11: thx
16:26:36 <adrian_otto> vilobhmm_11: I trust you know how to produce that dependency?
16:26:56 <adrian_otto> any more participation needed from the team on this?
16:27:03 <madhuri> +1
16:27:05 <vilobhmm_11> I will check with hongbin on IRC
16:27:17 <vilobhmm_11> adrian_otto : ^^
16:27:20 <adrian_otto> ok, thanks
16:27:29 <vilobhmm_11> don't want to take team;s time here
16:27:31 <vilobhmm_11> hongbin has been very kind with all the feedback and reviews
16:27:34 <vilobhmm_11> thanks hongbin
16:27:40 <adrian_otto> #link https://blueprints.launchpad.net/magnum/+spec/secure-kubernetes Secure the client/server communication between ReST client and ReST server (madhuri)
16:27:43 <hongbin> welcome
16:28:17 <adrian_otto> and related:
16:28:18 <adrian_otto> #link https://blueprints.launchpad.net/magnum/+spec/secure-docker Secure client/server communication using TLS (apmelton)
16:28:47 <adrian_otto> I looked on Friday, and it looked like almost all of this code was merged
16:28:48 <apmelton> so, I've making really great progress getting TLS working with docker and swarm
16:29:08 <apmelton> late last week I was able to spin up a docker cluster secured with TLS using the local cert manager
16:29:17 <adrian_otto> whoot!
16:29:18 <apmelton> I'm just working on cleaning up that patch
16:29:38 <apmelton> I'll have something up this afternoon that should be ready for some serious review
16:30:03 <adrian_otto> great, are there specific team members who we should point at it so we get that through quickly?
16:30:28 <daneyon_> apmelton awesome!
16:31:01 <apmelton> anyone who's familiar with the flow of things for TLS should check it out
16:31:41 <adrian_otto> ok, any more on the TLS topics?
16:31:55 <adrian_otto> #link https://blueprints.launchpad.net/magnum/+spec/external-lb Support the kubernetes service external-load-balancer feature (Tango)
16:32:02 <adrian_otto> we looked at this in AI review
16:32:12 <adrian_otto> sounds like this will be done this week
16:32:21 <Tango> I think so
16:32:40 <adrian_otto> great. if you get stuck, let's talk and see what we can do to work around
16:32:51 <adrian_otto> and that brings us to.....
16:32:58 <adrian_otto> #topic Open Discussion
16:33:01 <adrian_otto> yay!
16:33:09 <hongbin> One have one to discuss
16:33:19 <adrian_otto> wassup, hongbin?
16:33:30 <hongbin> There is a vote on the team meeting time
16:33:37 <hongbin> #link http://doodle.com/poll/76ix26i2pdz89vz4
16:33:45 <hongbin> Please vote if you haven't
16:33:48 <adrian_otto> yes, thanks for the reminder
16:33:54 <adrian_otto> did we sent that out on the ML?
16:34:00 <hongbin> yes, I did
16:34:17 <adrian_otto> that explains the wide participation ;-)
16:35:03 <adrian_otto> looks like 1600 UTC is very popular
16:35:13 <hongbin> yes, it is
16:35:22 <adrian_otto> so assuming new votes do not change that
16:35:32 <adrian_otto> might it make sense to stop alternating to 2200 UTC?
16:35:46 <hongbin> works for me
16:35:55 <adrian_otto> do we have any key contributors who would need to stop attending if we did that?
16:35:55 <wanghua> +1
16:36:07 <hongbin> there are two
16:36:10 <gsagie_> +1 :)
16:36:14 <hongbin> yuanying and eli cannot make it
16:37:12 <hongbin> but it is almost impossible to find a time that works for everyone
16:37:17 <adrian_otto> right.
16:37:34 <adrian_otto> the 2200 UTC time looks like it works for yuanying
16:37:55 <adrian_otto> this is a good problem to have, but a hard one to solve
16:38:07 <hongbin> agree
16:38:11 <hongbin> :)
16:38:37 <adrian_otto> ok, I'll talk it over with yuanying and see what he thinks of the change, and what balance we might be able to strike
16:38:47 <adrian_otto> is eli	a regular attendee?
16:39:09 <adrian_otto> maybe he uses another nick that I'd recognize?
16:39:09 <hongbin> he/she submitted patches, but haven't see him/her in meeting
16:39:22 <adrian_otto> ok, there's no requirement to show up here
16:39:42 <adrian_otto> but I'd like to be inclusive for those who can add value in our discussions
16:39:50 <adrian_otto> I'll take an official action for this
16:40:10 <madhuri> +1
16:40:27 <adrian_otto> #action adrian_otto to follow up with yuanying and eli to ask about adjusting the team IRC meeting schedule
16:40:33 <wanghua> I have something about docker registry to discuss.
16:40:50 <adrian_otto> great, what is it, wanghua?
16:40:58 <wanghua> docker registry configs are list in https://github.com/docker/distribution/blob/master/docs/configuration.md#openstack-swift
16:41:09 <adrian_otto> you don't have to ask in open discussion… you can blurt out whatever you like ;-)
16:41:19 <wanghua> Should we expose these configs to users?
16:41:32 <wanghua> all read the configs from magnum config file
16:41:39 <wanghua> or
16:42:23 <wanghua> Different user may need different docker registry.
16:42:41 <adrian_otto> great question.
16:42:55 <daneyon_> looks like a potential use case for labels
16:43:31 <adrian_otto> as a user, I'd like the ability to specify my own swift backend… or even possibly a non-openstack cloud backend for Docker Distribution.
16:43:40 <adrian_otto> maybe there is a way to allow that?
16:43:58 <adrian_otto> where a default one is supplied for me (by my cloud operator)?
16:44:09 <adrian_otto> daneyon_: good idea!
16:44:21 <daneyon_> pass the params as --labels, have conductor map them to extra_params that get pulled into the heat templates
16:44:37 <hongbin> adrian_otto: that means users need to upload their remote cloud credential
16:44:52 <adrian_otto> hongbin: yes, that's a bummer.
16:45:10 <daneyon_> in combination with having something like a --docker_registry_backend api attr
16:45:16 <daneyon_> and object
16:45:37 <adrian_otto> well, let's try not to over-engineer it up front
16:45:57 <wanghua> adrian_otto: I think we can implement swift backend first
16:45:58 <adrian_otto> try to get a naive implementation first, something quick and dirty
16:46:13 <hongbin> +1
16:46:13 <adrian_otto> and then make a blueprint for enhancing it
16:46:35 <wanghua> +1
16:47:03 <adrian_otto> and we can collaborate on the BP to get something really sweet for the follow-up iterations on that feature
16:47:03 <wanghua> again the problem, should we expose the configs to users
16:47:25 <adrian_otto> not if they are shared between tenants
16:47:40 <adrian_otto> and not if they are supplied by the cloud operator on behalf of the tenant
16:47:49 <adrian_otto> but yes in the case where they are supplied by the user.
16:48:17 <adrian_otto> we should not make the actual keystone credential readable after it is provided
16:48:42 <adrian_otto> but the other bits (possibly as labels) seem ok to me.
16:49:01 <daneyon_> I would think it's required to allow users to manage the registry config.
16:49:21 <adrian_otto> yes, the question is how
16:49:23 <daneyon_> As with the networking stuff, batteries included but replaceable approach.
16:49:34 <rlrossit> adrian_otto: do we want to quickly discuss https://bugs.launchpad.net/magnum/+bug/1495981 and get a game plan for it?
16:49:36 <openstack> Launchpad bug 1495981 in Magnum "Any error in k8s is returned as 500 from magnum api" [Undecided,New] - Assigned to Ryan Rossiter (rlrossit)
16:49:38 <daneyon_> sane defaults, keep things simple and allow users to expand
16:49:57 <wanghua> We can create a user without any role assigned to it.
16:50:08 <adrian_otto> rlrossit: thanks for filing that bug!!
16:50:14 <wanghua> The user can only communicate with swift with a trust
16:50:44 <rlrossit> adrian_otto: no prob! how does magnum handle API return code changes?
16:50:58 <daneyon_> seems like we need to manage the yml file that tells registry what to do
16:51:35 <wanghua> https://review.openstack.org/#/c/223526/
16:51:46 <adrian_otto> rlrossit: check in with madhuri_ on this one
16:51:56 <adrian_otto> that should help get us moving in the right direction
16:52:25 <madhuri_> rlrossit: I will take a look on it
16:52:37 <adrian_otto> daneyon_: I'm not 100% convinced we need to manage every feature.
16:52:44 <apmelton> daneyon_: the cool thing about distribution is the yaml config keys map directly to environment variables
16:52:45 <rlrossit> thanks madhuri_! we can probably discuss further on IRC if needed
16:52:47 <daneyon_> i would like to discuss discovery, but I'll use the ML since we are running short on time.
16:52:51 <apmelton> we may not need to futz with a yaml config
16:53:06 <madhuri_> sure
16:53:25 <daneyon_> adrian_otto agreed, we can leave most of the config file alone and just manage the pieces that are high priority
16:54:04 <adrian_otto> yes. If someone wants to do something really wacky they can edit the config on the bay master node(s)
16:54:28 <daneyon_> apmelton yeah, I think we manage the registry yml the same way we manage other files. At the surface, this seems straight forward.
16:54:33 <adrian_otto> we should have a default setup that we expect to be widely useful and helps automate things for the general case.
16:55:06 <daneyon_> the default should be as it is today, to use Docker hub.
16:55:37 <adrian_otto> and maybe we have some feature like —no-registry-auto-config or something… so you can bake in your own in your image
16:56:14 <eghobo> daneyon_: dcoker hardcoded docker.io as default and you cannot change it
16:56:35 <adrian_otto> eghobo: WAT???
16:56:46 <eghobo> only redhat fork has this fearure
16:57:06 <adrian_otto> oh, I know what you are talking about
16:57:17 <adrian_otto> the docker.io/image-name thing
16:57:54 <adrian_otto> ok, we have a few minutes remaining. Anything else we should be thinking about before we wrap up?
16:59:09 <adrian_otto> Our next team meeting is Tuesday 2015-09-22 at 2200 UTC (sorry for the difficult time!). See you then!
16:59:15 <daneyon_> thx
16:59:19 <daneyon_> bye!
16:59:20 <apmelton> p/
16:59:22 <apmelton> o/
16:59:25 <wanghua> bye
16:59:26 <adrian_otto> #endmeeting