16:04:31 <adrian_otto> #startmeeting containers
16:04:31 <openstack> Meeting started Tue Sep 29 16:04:31 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:04:32 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:04:34 <juggler> no problem :)
16:04:35 <openstack> The meeting name has been set to 'containers'
16:04:57 <adrian_otto> #topic Roll Call
16:05:01 <adrian_otto> Adrian Otto
16:05:01 <ctrath> o/
16:05:01 <vilobhmm111> o/
16:05:02 <rlrossit> o/
16:05:03 <hongbin> o/
16:05:05 <dane_leblanc> o/
16:05:06 <juggler> howdy all Perry Rivera o/
16:05:07 <wanghua> o/
16:05:08 <bradjones_alt> o/
16:05:08 <Tango> Ton Ngo
16:05:16 <eghobo_> o/
16:05:19 <muralia1> o/
16:05:19 <madhuri> o/
16:05:53 <daneyon_> o/
16:05:56 <adrian_otto> #link https://wiki.openstack.org/wiki/Meetings/Containers#Agenda_for_2015-09-29_1600_UTC Our Agenda
16:06:04 <adrian_otto> hello everyone
16:06:12 <adrian_otto> #topic Announcements
16:06:22 <adrian_otto> 1) New weekly meeting schedule. We will no longer alternate. Instead we will always meet Tuesdays at 1600 UTC.
16:06:41 <adrian_otto> we have confirmation from our impacted core reviewer that the new approach is acceptable.
16:06:47 <mfalatic> o/
16:07:11 <adrian_otto> The first new meeting time occurs next week.
16:07:25 <adrian_otto> I will send an email to the ML to announce the change there as well
16:07:34 <adrian_otto> #action adrian_otto to announce meeting time change to ML
16:07:39 <adrian_otto> any questions?
16:07:46 <Drago> o/
16:07:48 <adrian_otto> thanks to hongbin for suggesting the change
16:07:54 <hongbin> np
16:08:03 <adrian_otto> 2) Liberty release cuts this week
16:08:28 <adrian_otto> if you have code in review, and you'd like that to be included, please get your revisions in so we can merge them today.
16:08:47 <adrian_otto> 3) New core reviewers
16:09:08 <adrian_otto> I will be proposing two new core reviewers for consideration by our team of contributors
16:09:34 <adrian_otto> discussion will happen on the mailing list beginning today
16:09:43 <adrian_otto> any concerns before I initiate that nomination process?
16:10:11 <adrian_otto> ok, let's check in with our subteams
16:10:24 <juggler> no concerns here
16:10:29 <eghobo_> adrian_otto: 1 sec about Liberty
16:10:33 <madhuri> TLS has two reviews pending
16:10:36 <adrian_otto> I will pause a moment for announcements from team members, or remaining quesitons
16:10:56 <adrian_otto> eghobo_: yes?
16:10:58 <diga> o/
16:11:13 <eghobo_> do we know which features we must have in Liberty?
16:11:24 <adrian_otto> blueprints marked as Essential
16:11:31 <madhuri> link #https://review.openstack.org/#/c/202873/ and https://review.openstack.org/#/c/207324/
16:11:52 <adrian_otto> we need to wrap up all related work, and cut a release candidate for review
16:12:23 <eghobo_> I see and couple of weeks for testing/bug fixes after that?
16:12:24 <adrian_otto> eghobo_: does that answer your question?
16:12:27 <madhuri> https://review.openstack.org/#/c/202873/  I have a point regarding this review
16:12:33 <adrian_otto> yes
16:12:46 <adrian_otto> madhuri: let's revisit that in the BP review agenda item
16:12:46 <eghobo_> adrian_otto: thx
16:12:52 <adrian_otto> I will call on you
16:13:00 <adrian_otto> ^^ madhuri
16:13:03 <madhuri> Ok sure
16:13:09 <adrian_otto> #topic #topic Container Networking Subteam Update (daneyon_)
16:13:16 <daneyon_> thank you
16:13:31 <daneyon_> i have been busy implementing the CNM in swarm
16:13:41 <daneyon_> the tls patch set me back a bit
16:14:05 <daneyon_> as part of this work, i am implementing load-balancing for the etcd service and the swarm api
16:14:22 <daneyon_> which is a bit of a problem when using tls
16:14:43 <daneyon_> this is b/c it appears that the neutron lbaas does not support ssl offload
16:15:19 <adrian_otto> why do we want ssl offload?
16:15:22 <daneyon_> I can remove the swarm api from the load-balancer pool, but then we will be back at this point when implementing ha
16:15:26 <eghobo_> daneyon_: do you have any bp which describe how it will work, sounds very interesting ;)
16:15:40 <daneyon_> a load-balancer is not required for swarm ha, but it is preferred.
16:16:04 <daneyon_> otherwise, I can get everything to work when using the insecure mode which bypasses tls
16:16:08 <adrian_otto> daneyon_: break it down, and progress incrementally
16:16:17 <adrian_otto> let's avoid the temptation to boil the ocean
16:17:12 <daneyon_> ok
16:17:13 <adrian_otto> daneyon_: we can use the tls bypass as a first step as long as it does not require cloud operators to run in an insecure mode if they are not using the Magnum CNM features
16:17:34 <adrian_otto> we effectively mark the feature as experimental… or even put it into a feature branch
16:17:47 <daneyon_> adrian_otto that is correct, operators would have a baymodel that uses flannel for swarm with insecure mode.
16:18:07 <daneyon_> they can have baymodels that use the default secure mode
16:18:26 <adrian_otto> ok, that's my guidance then
16:18:37 <daneyon_> otherwise, I'm hoping to have the swarm code ready for review in the next day or two.
16:18:43 <daneyon_> got it, thx.
16:18:50 <daneyon_> that's it for me
16:18:56 <daneyon_> any questions?
16:19:02 <adrian_otto> great, thanks daneyon_
16:19:08 <adrian_otto> (pause for quesitons)
16:19:24 <daneyon_> eghobo_ sorry i missed your question
16:19:35 <daneyon_> this work is part of the container network model spec.
16:19:54 <daneyon_> the spec has been merged, so let me know if you have any questions related to the spec
16:20:04 <adrian_otto> #topic Magnum UI Subteam Update (bradjones_alt)
16:20:05 <daneyon_> any other questions?
16:20:18 <adrian_otto> bradjones_alt: ready?
16:20:22 <bradjones_alt> yeah sure
16:20:43 <bradjones_alt> unfortunately I hit a bit of a roadblock getting the rest api working with the plugin architecture
16:20:50 <bradjones_alt> so that put me behind last week
16:21:05 <bradjones_alt> I have resolved it now so those patches are available for review
16:21:16 <adrian_otto> any chance we will have a horizon plugin to show in Tokyo?
16:21:26 <bradjones_alt> adrian_otto: definitely
16:21:30 <adrian_otto> oh, good!
16:21:41 <juggler> yea!
16:21:46 <hongbin> that is great!
16:21:47 <vilobhmm111> +1
16:21:49 <bradjones_alt> at the very least we will be able to show views for Bay and BayModel
16:21:55 <adrian_otto> give us a feeling for where things are today, and what to expect next, please.
16:22:13 <madhuri> \o/
16:22:24 <bradjones_alt> so today I have the ability to show a table view of BayModels
16:22:35 <bradjones_alt> view details about a specific BayModel etc
16:22:49 <bradjones_alt> transferring that over to Bay is trivial so will follow once the BayModel work has merged
16:22:59 <bradjones_alt> next step is to make the Create forms
16:23:10 <bradjones_alt> which I should get to by the end of the week
16:23:41 <bradjones_alt> and once that is done for one resource (BayModel) it will be simple to transfer the work to other resources
16:24:05 <adrian_otto> bradjones_alt: do you feel that you have enough support form the magnum-ui subteam?
16:24:12 <bradjones_alt> so providing there aren't too many challenges we may have more resource types included in the UI by tokyo
16:24:21 <adrian_otto> is there anything we can do to help?
16:24:25 <daneyon_> woohoo!!!!
16:24:38 <bradjones_alt> adrian_otto: I think things are going as well as they can at the moment
16:24:39 <juggler> nice brad
16:24:52 <bradjones_alt> obviously reviews are needed at the moment for the API work still out there
16:24:53 <adrian_otto> ok, sweet
16:25:05 <bradjones_alt> I will send an email round to everyone
16:25:16 <bradjones_alt> once the views are rebased
16:25:50 <bradjones_alt> what should we do about cutting the liberty release for magnum-ui?
16:26:20 <bradjones_alt> I imagine it would be good to sync it up with the magnum release but I think it may need slightly more time to get as much as we can in this release
16:26:40 <adrian_otto> we can include in in a subsequent release candidate
16:26:59 <bradjones_alt> adrian_otto: ok makes sense
16:26:59 <adrian_otto> we can cut a bunch of preliminary releases
16:27:37 <adrian_otto> but because we do not have 100% coverage in functional testing, we need to get plenty of eyeballs testing the code before release time
16:28:24 <adrian_otto> any more questions/concerns relating to our Magnum UI Subteam?
16:28:29 <bradjones_alt> adrian_otto: definitely, once we get closer to release time I will put together a video and some docs showing how it all works to make it easier for people to see
16:28:44 <adrian_otto> -!! sweet !!-
16:28:48 <juggler> thanks brad
16:29:00 <adrian_otto> #topic Review Action Items
16:29:06 <adrian_otto> (none)
16:29:18 <adrian_otto> #topic Blueprint/Bug Review
16:29:43 <vilobhmm111> adrian_otto : may be i can start
16:29:50 <adrian_otto> madhuri, was the one review that you want to covere part of the secure-kubernetes BP, or another topic?
16:29:55 <adrian_otto> vilobhmm111: one sec.
16:29:59 <vilobhmm111> sure
16:30:33 <madhuri> adrian_otto: Review
16:30:48 <madhuri> #link https://review.openstack.org/#/c/202873/
16:31:00 <adrian_otto> madhuri: Got it. I'll come back to you after vilobhmm111 goes.
16:31:08 <adrian_otto> #link https://blueprints.launchpad.net/magnum/+spec/objects-from-bay Obtain the objects from the bay endpoint (vilobhmm111)
16:31:36 <vilobhmm111> adrian_otto : Made lot of progress last week. Got all the unit test resolved for the ML sent last week. http://permalink.gmane.org/gmane.comp.cloud.openstack.devel/64748
16:31:37 <madhuri> adrian_otto: sure
16:32:00 <vilobhmm111> https://review.openstack.org/#/c/223367/ - Objects from Bay - Pods ; https://review.openstack.org/#/c/213368/ - Objects from Bay - Replication Controller for both of them the *one* functional test is failing because they expect bay_uuid to be passed as a mandatory parameter in magnumclient CLI.
16:32:12 <vilobhmm111> I have proposed 6 new patches to achieve the same. They need review. All the 6 patches have +1 from Jenkins.
16:32:23 <vilobhmm111> Plan :-
16:32:33 <vilobhmm111> #1. Merge these 6 patches (backend + magnum-client changes)
16:32:46 <vilobhmm111> #2. Merge 3 patches for objects (since now the *one* failing functional test will pass after #1. is merged)
16:33:09 <adrian_otto> #link https://review.openstack.org/#/q/status:open+project:openstack/magnum+branch:master+topic:bp/objects-from-bay,n,z related reviews
16:33:41 <vilobhmm111> magnumclient reviews are not showing up here adrian_otto
16:33:49 <adrian_otto> vilobhmm111: looks like jenkins voted -1 over half of them
16:34:04 <vilobhmm111> they are object-from-bay patches
16:34:05 <adrian_otto> oh, one moemnt, sorry
16:34:38 <vilobhmm111> onely 1 functional test is failing as I described above and thats because it expects a mandatory bay_uuid param from magnumclient
16:34:58 <adrian_otto> #link https://review.openstack.org/#/q/status:open+project:openstack/python-magnumclient+branch:master+topic:bp/objects-from-bay,n,z python-magnumclient reviews
16:35:01 <vilobhmm111> they should get fixed when these 6 patches are merged
16:35:14 <adrian_otto> ok, got it
16:35:18 <vilobhmm111> adrian_otto : thanks for the links
16:35:44 <vilobhmm111> adrian_otto : thats it from my side
16:35:49 <adrian_otto> besides merging he code for review, are there any blockers that need to be addressed?
16:36:06 <adrian_otto> s/he/the/
16:36:28 <adrian_otto> ok, advancing to madhuri
16:36:29 <vilobhmm111> adrian_otto : no
16:36:32 <adrian_otto> #link https://blueprints.launchpad.net/magnum/+spec/secure-kubernetes Secure the client/server communication between ReST client and ReST server (madhuri)
16:36:33 <vilobhmm111> sure thanks
16:36:36 <adrian_otto> thanks vilobhmm111
16:36:52 <madhuri> adrian_otto: I agree to your comment of changing insecure to tls_enabled
16:37:01 <adrian_otto> This is where:
16:37:04 <adrian_otto> #link https://review.openstack.org/202873
16:37:05 <adrian_otto> comes in
16:37:11 <madhuri> But that can be done in next patch, as this config is used in many other places
16:37:16 <adrian_otto> we can probably merge this with tech debt
16:37:26 <madhuri> Yes
16:37:26 <adrian_otto> tcammann1: tcammann_: ping
16:37:34 <suro-patz> tcammman_: proposed https://review.openstack.org/#/c/229035/
16:37:42 <madhuri> And then I will submit a change for the same
16:37:56 <adrian_otto> wow, that was quick!
16:38:34 <madhuri> Yes
16:38:48 <adrian_otto> so it sounds to me like we can merge both https://review.openstack.org/202873 and https://review.openstack.org/229035 and we should be satisfying everyone's interests
16:38:50 <madhuri> So we can merge the heat template patch
16:39:01 <adrian_otto> I have not looked at the new patch closely yet, but that's my hope
16:39:05 <madhuri> +1
16:39:30 <madhuri> I have tested the patch with local cert manager and it worked well
16:39:47 <eghobo_> madhuri: we need functional test, can you add one?
16:39:54 <madhuri> adrian_otto: After this patch gets merged, I will add functional test
16:39:59 <madhuri> Yes eghobo_ :)
16:40:07 <madhuri> eghobo_: ^
16:40:21 <adrian_otto> ok, sounds like a plan. I think we can draw this to conclusion today.
16:40:29 <madhuri> eghobo_: I will submit the patch tomorrow
16:40:44 <madhuri> Yes
16:41:04 <adrian_otto> If we merge https://review.openstack.org/229035 first, madhuri can you rebase against that?
16:41:16 <madhuri> adrian_otto: One point to add, I haven't tested with Barbican
16:41:17 <eghobo_> madhuri: thx, i cannot make this setup work but maybe it my environment issue
16:41:31 <madhuri> adrian_otto: Sure
16:41:54 <madhuri> I will do that
16:42:10 <adrian_otto> madhuri: okay, in that case, we should make a note it he config where barbican gets enabled that it has not been tested, and link to a bug ticket that can be closed when it is verified to work, or repaired.
16:42:12 <madhuri> eghobo_: Even I can't configure Barbican
16:42:18 <adrian_otto> then we can pull out that reference when it's known to work
16:42:36 <madhuri> +1 adrian_otto
16:42:46 <eghobo_> madhuri: I meant local certs
16:42:52 <adrian_otto> again, our first attempt at things does not need to be perfect, as long as we have a sensible path forward
16:43:24 <madhuri> eghobo_: We can take this to #openstack-containers channel later
16:43:44 <adrian_otto> madhuri: ready to yield to Tango now?
16:44:17 <madhuri> adrian_otto: Yes but please mark to conclusion
16:44:32 <adrian_otto> I do not understand, sorry
16:44:52 <adrian_otto> you want me to "bird dog" this (definition: to stalk) then I most certainly will
16:45:07 <madhuri> Sorry, I mean there are few points decided which should be marked as action points
16:45:24 <adrian_otto> we can mark a decision
16:45:41 <madhuri> Ok thanks adrian_otto
16:46:18 <adrian_otto> with a #agreed to merge https://review.openstack.org/229035 and rebase https://review.openstack.org/202873 against it, and to mark barbican configuration as untested with a link to a related bug ticket.
16:46:23 <adrian_otto> would that suffice?
16:46:25 <madhuri> Tango: You can take over
16:46:37 <Tango> ok thanks :)
16:46:42 <adrian_otto> irc://chat.freenode.net:6667/#agreed to merge https://review.openstack.org/229035 and rebase https://review.openstack.org/202873 against it, and to mark barbican configuration as untested with a link to a related bug ticket.
16:46:49 <adrian_otto> (ick, one sec)
16:46:51 <madhuri> Great adrian_otto :)
16:47:08 <adrian_otto> #agreed to merge https://review.openstack.org/229035 and rebase https://review.openstack.org/202873 against it, and to mark barbican configuration as untested with a link to a related bug ticket.
16:47:20 <adrian_otto> I can #undo that if anyone disagrees with the approach
16:48:01 <adrian_otto> ok, no objections head. advancing our agenda
16:48:03 <adrian_otto> #link https://blueprints.launchpad.net/magnum/+spec/external-lb Support the kubernetes service external-load-balancer feature (Tango)
16:48:07 <Tango> The patch for external load balancer on Fedora Atomic is ready, please review:
16:48:09 <Tango> https://review.openstack.org/#/c/191878/
16:48:18 <Tango> I added documentation:
16:48:24 * adrian_otto applause
16:48:35 <Tango> https://review.openstack.org/#/c/227689/
16:49:04 <Tango> I am adding a bug to follow up on the password handling, with feedback from the team
16:49:20 <Tango> this will need some investigation
16:49:44 <adrian_otto> Tango: as an item of technical debt, let's plan to rename dev-kubernetes-load-balancer.rst to kubernetes-load-balancer.rst
16:49:53 <adrian_otto> as this is not technically dev environment specific
16:50:04 <adrian_otto> that can be addressed in a separate bug/patch
16:50:31 <Tango> ok, I will open another bug on that
16:50:51 <Tango> The functional test needs to be deferred until we handle the password, because of the manual step to enable the load balancer
16:51:03 <adrian_otto> Tango, let's see if we have time in open discussion to get input in the password handling to give you directional guidance
16:51:16 <Tango> sure
16:51:39 <adrian_otto> thanks so much for your follow through on this, Tango. This was an exceedingly important feature to land.
16:51:52 <adrian_otto> advancing to our next BP
16:51:54 <Tango> I see a bug opened on CoreOS template, so l am looking at that as well, something about multimime support
16:52:11 <adrian_otto> thanks
16:52:13 <adrian_otto> #link https://blueprints.launchpad.net/magnum/+spec/secure-docker Secure client/server communication using TLS (apmelton)
16:52:24 <adrian_otto> apmelton appears absent today.
16:52:50 <diga> adrian_otto: Tango : is there help required on the coreos template side, let me know, I will take it up
16:53:33 <adrian_otto> I don't see any remaining reviews form Andrew queued, so it must have all merged
16:54:00 <adrian_otto> #topic Open Discussion
16:54:04 <Tango> diga: yes please help :)
16:54:06 <adrian_otto> Tango, do you want to go first here?
16:54:18 <diga> Tango: sure
16:54:31 <Tango> Sure, here is the bug on CoreOS:  https://bugs.launchpad.net/magnum/+bug/1499909?
16:54:31 <openstack> Launchpad bug 1499909 in Magnum "CoreOS doesn't support multi-part mimes and as such doesn't work" [Undecided,New]
16:54:51 <adrian_otto> oh, thanks for making that connection diga
16:54:54 <diga> Tango: I will take that
16:55:09 <Tango> About handling the password, basically we need to automate the step in a secure manner.
16:55:19 <diga> adrian_otto: :) welcome!
16:55:58 <adrian_otto> madhuri: I wanted to recognize all of your work on the TLS features, as well as Yuanying, and apmelton
16:56:09 <Tango> The best approach (from Hongbin) seems to be to create a new keystone domain per cluster and add that to the kube master.
16:56:21 <Tango> So I plan to look at that first
16:56:21 <adrian_otto> that was our most critical feature to land, and I'm really happy to see this coming together
16:56:49 <diga> adrian_otto: since many days I wasn't able to work on magnum due to busy schedule, sorry for that
16:57:24 <diga> now again wants to start
16:57:34 <daneyon_> I have a quick question related to the tls work
16:57:55 <daneyon_> #link  https://docs.docker.com/articles/https/
16:58:21 <daneyon_> according to ^ the --tls flag is not needed when performing mutual auth between the daemon/client.
16:58:53 <daneyon_> Am I missing something or should the --tls flag be removed from the daemon?
16:59:10 <daneyon_> looks like we're runnning out of time
16:59:11 <adrian_otto> —tls protects the full transport over the wire, right?
16:59:18 <adrian_otto> yes, we are out of time.
16:59:22 <daneyon_> feel free to respond on the magnum irc channel
16:59:51 <adrian_otto> our next meeting is Tuesday 2015-10-06 at 1600 UTC. See you all then!
17:00:01 <adrian_otto> thanks everyone!
17:00:04 <adrian_otto> #endmeeting