16:00:12 <hongbin> #startmeeting containers
16:00:13 <openstack> Meeting started Tue Sep  6 16:00:12 2016 UTC and is due to finish in 60 minutes.  The chair is hongbin. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:15 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:17 <openstack> The meeting name has been set to 'containers'
16:00:20 <hongbin> #topic Roll Call
16:00:23 <muralia> Murali Allada
16:00:29 <tonanhngo> Ton Ngo
16:00:32 <jvgrant> Jaycen Grant
16:00:35 <strigazi> Spyros Trigazis
16:01:02 <adrian_otto> Adrian Otto
16:01:11 <dane_leblanc> o/
16:01:29 <rpothier> Rob Pothier
16:01:38 <hongbin> Thanks for joining the meeting muralia tonanhngo jvgrant strigazi adrian_otto dane_leblanc rpothier
16:01:47 <hongbin> #link https://wiki.openstack.org/wiki/Meetings/Containers#Agenda_for_2016-09-06_1600_UTC Today's agenda
16:01:52 <hongbin> Anything needs to be added to the agenda?
16:02:26 <hongbin> #topic Announcements
16:02:31 <hongbin> 1. python-magnumclient 2.3.0 release (final release in Newton)
16:02:38 <hongbin> #link http://lists.openstack.org/pipermail/openstack-announce/2016-August/001538.html
16:02:42 <hongbin> 2. magnum-ui 2.0.0 release
16:02:48 <hongbin> #link http://lists.openstack.org/pipermail/openstack-announce/2016-August/001539.html
16:02:55 <hongbin> 3. magnum 3.0.0 release
16:02:59 <hongbin> #link http://lists.openstack.org/pipermail/openstack-announce/2016-August/001547.html
16:03:16 <hongbin> #1 is the final release
16:03:23 * adrian_otto applause
16:03:27 <muralia> nice
16:03:37 <hongbin> we will possibly have another release for magnum-ui and magnum
16:04:02 <tonanhngo> When is the deadline for these?
16:04:03 <hongbin> will discuss the release schedule later in the agenda
16:04:11 <tonanhngo> ok
16:04:21 <hongbin> tonanhngo: the deadline is the final release candidate week
16:04:38 <strigazi> I think 9/15
16:04:55 <muralia> sep 26-30th
16:04:59 <muralia> is the final rc week
16:05:07 <hongbin> #link https://releases.openstack.org/newton/schedule.html
16:05:20 <hongbin> it is sep 26-30
16:05:39 <strigazi> 11-16 is rc1, sorry
16:05:43 <strigazi> 12-16 is rc1, sorry
16:05:48 <hongbin> that is all for the annoucement
16:06:03 <hongbin> any other annoucement from our team members?
16:06:24 <hongbin> #topic Review Action Items
16:06:25 <hongbin> none
16:06:31 <hongbin> #topic Essential Blueprints Review
16:06:38 <hongbin> 1. Support baremetal container clusters (strigazi)
16:06:45 <hongbin> #link https://blueprints.launchpad.net/magnum/+spec/magnum-baremetal-full-support
16:06:49 <hongbin> strigazi: ^^
16:07:33 <strigazi> I was testing k8s-ironic with lbaas-v2 because the relevant lbaas patch was breaking the k8s ironic tests
16:08:17 <strigazi> Couldn't find a solution and I think it's better to proceed without lbaas for that driver
16:08:20 <strigazi> but
16:09:26 <strigazi> lbaas v2 wasn't working for vm drivers either. I guess we don't have tests for creating cluster with lbaas
16:09:44 <strigazi> So,
16:10:29 <strigazi> if lbaas v2 is fixed are you ok to proceed with removing lbaas support from fedora k8s ironic driver?
16:11:17 <hongbin> for me, yes
16:11:37 <strigazi> next, I created a fedora 24 image for baremetal and passed the gate tests
16:11:47 <strigazi> it is uploaded here
16:12:05 <strigazi> #link https://fedorapeople.org/groups/magnum/fedora-24-kubernetes-ironic.tar.gz
16:12:51 <strigazi> I'll push tomorrow a patch to build it on infra
16:13:11 <strigazi> The same image could be used for swarm
16:13:11 <adrian_otto> if we remove lbaas support, that means that we would not have multi-master COE support anymore
16:13:36 <adrian_otto> because there would be nothing to route clients to an alternate master in the event of a master failure.
16:13:37 <strigazi> Only for the specific driver until it's fixed
16:13:52 <tonanhngo> This should be temporary
16:13:56 <strigazi> not across magnum
16:13:56 <hongbin> I think strigazi means upgrade from lbaas to lbaas v2, not removing
16:14:44 <adrian_otto> ok, I suppose I did not understand your proposal strigazi
16:14:45 <strigazi> that is, *IF* lbaas V2 works
16:15:09 <strigazi> one more thing
16:15:12 <tonanhngo> yes, but Neutron removes lbaas, so there is not choice unless we get lbass v2 working
16:15:31 <hongbin> it is better to get lbaas v2 working in newton
16:15:32 <strigazi> tonanhngo: so
16:15:50 <strigazi> if we fix lbaas v2 only orinic won't have it
16:15:58 <strigazi> if we fix lbaas v2 only ironic won't have it
16:16:52 <strigazi> The final thing I want to discuss is how to handle the bm drivers in terms of commom code with the vm drivers
16:17:20 <strigazi> The bm drivers should be as close as possible to the VM drivers
16:17:47 <strigazi> therefore share all templates/fragments/*
16:19:03 <strigazi> we can put all common file in common/templates/COE_IMAGE/fragments directory
16:19:14 <strigazi> or just in common/templates/fragments
16:19:17 <strigazi> or
16:19:44 <strigazi> point to the files directly to the VM driver
16:20:03 <strigazi> The last option
16:20:07 <Drago> +1 to common/templates/COE_IMAGE/fragments, since otherwise the files would probably have COE_IMAGE prefixed to them
16:20:36 <strigazi> makes the ironic driver dependent to the VM driver
16:21:05 <muralia> i like putting them in the common folder too
16:21:05 <adrian_otto> agreed
16:21:13 <strigazi> ok
16:21:49 <tonanhngo> Just for clarity, COE_IMAGE means kubernetes, swarm, ... ?
16:22:09 <strigazi> muralia: do you want me to continue you split or you can abandon it
16:22:20 <strigazi> tonanhngo: k8s_muralia
16:22:29 <strigazi> tonanhngo: k8s_fedora
16:22:37 <muralia> just continue with the same patch. that might be easier for you actually
16:22:39 <tonanhngo> ok
16:22:50 <strigazi> and
16:23:34 <strigazi> I have this change for treating common template definitions #link https://review.openstack.org/#/c/365286/
16:23:34 <Drago> Should we do common/templates/COE/IMAGE/fragments?
16:24:14 <strigazi> Drago: we could
16:24:20 <strigazi> what others think?
16:24:44 <muralia> yes, we need to create /coe/image/fragments
16:24:52 <strigazi> ok
16:24:56 <jvgrant> i think COE/IMAGE/fragments is a little better
16:24:57 <Drago> I guess what I was really thinking, for things that are not image-specific, just put them in common/templates/COE/fragments, not COE_IMAGE or COE/IMAGE
16:25:38 <hongbin> i have a feeling that it is oversplitting
16:25:47 <muralia> yes, common for all drivers will go under /common/fragements. common for only one type of driver will go under /common/coe/image/fragemtns
16:25:58 <jvgrant> would there ever be common pieces that are shared on the COE level?
16:26:04 <jvgrant> if so then the extra split is nice
16:26:10 <strigazi> coreos and fedora
16:26:18 <Drago> Well there's k8s_fedora and k8s_coreos. I don't know how much is common between the two
16:26:33 <hongbin> i would proposal an alternative
16:27:06 <hongbin> common/templates/COE/fragments/<IMAGE_PREFIX>_XXX
16:27:22 <hongbin> then the dirs level is smaller
16:27:29 <strigazi> I like that too, less directories
16:27:35 <muralia> yes
16:27:43 <Drago> Works for me
16:27:46 <tonanhngo> We should document the convention we adopt, so others can follow later.
16:27:49 <jvgrant> +1
16:28:06 <strigazi> ok, I can update the bay-drivers spec
16:28:25 <adrian_otto> tonanhngo: where should that be documented?
16:28:33 <adrian_otto> in the Hacking guide?
16:28:49 <tonanhngo> There is the section on bay drivers in the user guide
16:28:50 <strigazi> IMO, in the spec and in the guide for creating new drivers
16:29:32 <tonanhngo> strigazi: +1
16:29:54 <strigazi> btw, to create a new driver we need two level of directories
16:30:14 <strigazi> driver_name/driver_name/driver.py
16:30:35 <muralia> why?
16:30:39 <strigazi> the first level would contain the setup.py file to install the driver
16:30:58 <strigazi> and the second all the files as descuibed in the spec
16:31:05 <strigazi> and the second all the files as described in the spec
16:31:17 <Drago> Will the setup.py change from driver to driver?
16:31:37 <strigazi> that is only for contrib drivers
16:31:45 <strigazi> not ours
16:31:56 <muralia> drago: yes. strigazi: we dont need to do this for the default drivers that come with magnum
16:32:10 <muralia> infact the default driver will not have a setup.py
16:32:23 <strigazi> true
16:32:23 <muralia> we just add entry points for those in the setup.cfg file directly
16:32:36 <strigazi> yes, I'm talking about contrib drivers
16:32:41 <muralia> ah ok
16:33:12 <strigazi> I'll do an iteration on the docs
16:33:21 <strigazi> and we can discuss it there
16:33:25 <muralia> sure
16:33:32 <strigazi> I think we can move topic
16:33:41 <strigazi> 26 min left
16:33:53 <hongbin> ok, le't move on
16:33:58 <hongbin> 2. Magnum User Guide for Cloud Operator (tango)
16:34:03 <hongbin> #link https://blueprints.launchpad.net/magnum/+spec/user-guide
16:34:07 <hongbin> tonanhngo: ^^
16:34:20 <tonanhngo> The section on scaling containers and cluster is under review. Thanks everyone for the comments
16:34:41 <tonanhngo> I will add the remaining sections to wrap up the user guide for Newton:  Horizon, clients
16:35:17 <tonanhngo> We discussed a section on scalability and tuning.  This work is still going on and we won't have the data until Oct
16:35:43 <tonanhngo> So I will add this section later
16:35:56 <tonanhngo> That's all for now
16:36:22 <hongbin> thanks tonanhngo
16:36:34 <hongbin> any comment about the user guide?
16:36:51 <hongbin> 3. COE Bay Drivers (muralia)
16:36:56 <hongbin> #link https://blueprints.launchpad.net/magnum/+spec/bay-drivers
16:37:02 <hongbin> muralia: ^^
16:38:07 <muralia> nothing new to discuss on this topic. I'm still working on fixing all broken tests. basically the I'm having to go to every test and add mocks for the driver.
16:38:11 <muralia> so this is taking a while.
16:38:20 <muralia> but nothing new to add since last week
16:38:58 <muralia> thats all for me.
16:39:05 <hongbin> thanks muralia
16:39:13 <hongbin> 4. Rename bay to cluster (jvgrant)
16:39:19 <hongbin> #link https://blueprints.launchpad.net/magnum/+spec/rename-bay-to-cluster
16:39:25 <hongbin> jvgrant: ^^
16:39:36 <jvgrant> Lots of merges this last week.  Working on last patch(hopefully) to switch db and object for bay.  Testing now should have review out today
16:40:11 <strigazi> jvgrant: how many patches? Was it possible to break it?
16:40:51 <jvgrant> strigazi: I did my best on this one. the db and object changes have so many references so they are very hard to break up
16:41:39 <strigazi> I know, maybe it's impossible :(
16:41:52 <jvgrant> trying to keep them as small as i can since the constant merge conflicts are rough
16:42:22 <tonanhngo> If it's too hard, we can just bite the bullet and get it done in one big patch
16:42:23 <jvgrant> there is light at the end of the tunnel though and we should be done soon :)
16:42:35 <jvgrant> the last one won't be too big
16:42:51 <jvgrant> since everything else is already changed, just a lot of little changes all over
16:43:01 <jvgrant> that is all
16:43:53 <hongbin> Thanks jvgrant for working on this efforts, The renaming is a large amount of work than I ever thought
16:44:07 <hongbin> jvgrant: thanks for your huge contribution :)
16:44:13 <adrian_otto> +1
16:44:15 <tonanhngo> +1
16:44:15 <strigazi> +1
16:44:26 <Drago> It's just a simple sed command, sheesh ;)
16:44:27 <jvgrant> hongbin: your welcome, it was much bigger than i thought as well :) 10000+ lines of changes so far
16:44:54 <strigazi> Drago xD
16:44:55 <adrian_otto> better now than later
16:44:55 <muralia> wow! :)
16:45:05 <hongbin> #topic Kuryr Integration Update (tango)
16:45:13 <hongbin> tonanhngo: ^^
16:45:27 <tonanhngo> I attended the Kuryr meeting yesterday.  Good things that they now are back to weekly meeting
16:45:58 <tonanhngo> Release 1 is still ongoing, and they start implementing Release 2 with the Rest/API server
16:46:22 <tonanhngo> I raised our concern about security, because they are storing service credential in the VM config file
16:46:46 <tonanhngo> They acknowledge the concern and will address it in their implementation
16:47:14 <tonanhngo> There was a video conference last week to work on the implementation for Kubernetes CNI
16:47:20 <strigazi> you mean openstack usename and password?
16:47:40 <tonanhngo> strigazi:  Neutron service name and password
16:47:51 <tonanhngo> and rabbit
16:48:05 <strigazi> :-O
16:48:26 <tonanhngo> some of this is being changed in the Release 2, but they are still storing a new credential to talk to their Rest/API server
16:48:52 <tonanhngo> So, on going implementation there
16:49:09 <tonanhngo> They are making a push to implement the CNI driver by the Summit
16:49:22 <tonanhngo> but it will certainly not be in Newton
16:50:10 <tonanhngo> I am testing the remaining patches for the older Kuryr driver with our Swarm cluster.
16:50:39 <tonanhngo> I was thinking of making this for Newton, but given the security exposure, I am debating whether this is worth the effort
16:51:07 <strigazi> the default  swarm? 1.0.0 (for CERN's deployment it's a no go)
16:51:16 <tonanhngo> At best it will just be for experimenting, not for general use
16:51:31 <tonanhngo> Yes our current Swarm driver
16:52:04 <tonanhngo> We can just leave it as WIP for now, so people can try if out if they wat
16:52:21 <tonanhngo> s/wat/want
16:52:33 <strigazi> sounds good
16:52:47 <hongbin> thanks tonanhngo
16:53:04 <hongbin> any other comment?
16:53:25 <hongbin> #topic Other blueprints/Bugs/Reviews/Ideas
16:53:30 <hongbin> 1. Magnum Newton release
16:53:35 <hongbin> #link http://releases.openstack.org/newton/schedule.html Newton release scheduler
16:54:21 <hongbin> as stated earlier, the deadline to land patches is the final release candidate week
16:54:41 <hongbin> however, if you have patches, do it as soon as possible
16:55:01 <hongbin> so far, is there any patch that is not landed ?
16:55:28 <muralia> the driver patch
16:55:40 <hongbin> muralia: ack
16:55:43 <jvgrant> last bay to cluster patch
16:55:43 <tonanhngo> 2 more for the user guide
16:55:57 <hongbin> jvgrant: tonanhngo ack
16:56:04 <strigazi> final update for the install-guide
16:56:15 <hongbin> strigazi: ack
16:56:27 <hongbin> ok. get that.
16:56:34 <strigazi> will happen last week, since I must check the distro packages
16:57:10 <hongbin> all, try to finish it before the final release candidate week
16:57:28 <hongbin> #topic Open Discussion
16:57:32 <Drago> It's a bit early, but should we start thinking about fishbowl/design session topics?
16:57:37 <Drago> At least put an etherpad up
16:57:43 <adrian_otto> I have a concern about our review queue
16:58:25 <jvgrant> on release topic, i see a lot of reviews around config options, we should probably decide whether those are all going in before release or none
16:58:35 <jvgrant> wouldn't want only half to make it
16:59:00 <hongbin> Drago: ok, we can do that
16:59:19 <strigazi> jvgrant, I think after, we might miss important thing if we do it in a hurry
16:59:29 <adrian_otto> we have 100 reviews up, about half are in merge conflict, and many of them are three months old with no updates
16:59:35 <jvgrant> strigazi: that was my concern as well
16:59:38 <adrian_otto> there's too much up there to review in one sitting.
16:59:53 <hongbin> #action hongbin clean up the review queue
16:59:54 <adrian_otto> I suggest abandoning the lower 50 of them
17:00:06 <tonanhngo> +1
17:00:08 <hongbin> ok, time is up
17:00:16 <hongbin> all, thanks for joining the meeting
17:00:23 <hongbin> #endmeeting