16:00:03 <hongbin> #startmeeting containers
16:00:04 <openstack> Meeting started Tue May 24 16:00:03 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:06 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:08 <openstack> The meeting name has been set to 'containers'
16:00:10 <hongbin> #link https://wiki.openstack.org/wiki/Meetings/Containers#Agenda_for_2016-05-24_1600_UTC Today's agenda
16:00:16 <hongbin> #topic Roll Call
16:00:21 <strigazi> Spyros Trigazis o/
16:00:21 <muralia_> murali allada
16:00:27 <mkrai> Madhuri Kumari
16:00:29 <jvgrant> Jaycen Grant
16:00:36 <rochaporto> Ricardo Rocha
16:00:49 <dane_leblanc> o/
16:01:00 <juggler> o/
16:01:04 <rpothier> o/
16:01:25 <Drago> o/
16:01:55 <hongbin> Thanks for joining the meeting strigazi muralia_ mkrai jvgrant rochaporto dane_leblanc juggler rpothier Drago
16:02:03 <adrian_otto> Adrian Otto
16:02:12 <hongbin> #topic Announcements
16:02:25 <hongbin> Any annoucement from out team members?
16:02:34 <hongbin> s/out/our/
16:02:50 <hongbin> #topic Review Action Items
16:02:56 <hongbin> None
16:03:03 <hongbin> #topic Essential Blueprints Review
16:03:08 <hongbin> 1. Support baremetal container clusters (strigazi)
16:03:14 <hongbin> #link https://blueprints.launchpad.net/magnum/+spec/magnum-baremetal-full-support
16:03:25 <hongbin> strigazi: any update for this BP?
16:03:59 <strigazi> Mostly working on install-guide, but I managed to create a working environment for devstack with magnum and ironic
16:04:16 <strigazi> We can find someone to fix:
16:04:43 <strigazi> kubecluster-fedora-ironic.yaml
16:05:14 <hongbin> OK. That is only thing to fix?
16:05:46 <hongbin> strigazi: ^^
16:05:58 <strigazi> I think that if we fix that openstack stack create kubecluster-fedora-ironic.yaml would work
16:06:12 <hongbin> ack
16:06:24 <hongbin> Who can help to fix the Ironic heat templates?
16:06:29 <strigazi> docker.service.yaml file is missing
16:06:44 <strigazi> from kubeminion-fedora-ironic.yaml
16:07:20 <hongbin> strigazi: OK, I will find a contributor to work with you to fix the Heat teamplates
16:07:26 <strigazi> ack
16:07:37 <hongbin> #action hongbin find contributor to work with strigazi to fix the Ironic Heat templates
16:07:48 <strigazi> ironic works good on devstacl so far
16:08:01 <strigazi> s/devstacl/devstack
16:08:05 <hongbin> strigazi: anything else you want to update?
16:08:21 <strigazi> Not for this bp :)
16:08:29 <hongbin> Thanks strigazi
16:08:33 <hongbin> 2. Magnum User Guide for Cloud Operator (tango)
16:08:40 <hongbin> #link https://blueprints.launchpad.net/magnum/+spec/user-guide
16:09:17 <hongbin> tango: any update from your side?
16:09:26 <tango> Hi, has problem joining today
16:09:33 <tango> We have 3 sections added
16:09:45 <adrian_otto> I contributed the section that was assigned to me, or COE selection.
16:09:45 <tango> Choosing COE from Adrian,
16:10:05 <tango> Storage from me, and Notification from Whenzi
16:10:19 <hongbin> Sounds great
16:10:23 <tango> I added a WIP patch on bay drivers
16:10:24 <strigazi> and bay driver today
16:10:30 <strigazi> it's a WIP
16:10:43 <strigazi> https://review.openstack.org/#/c/320532/1
16:10:47 <tango> Yes, please feel to comment
16:10:55 <hongbin> #link https://review.openstack.org/#/c/320532/1
16:11:16 <tango> This should help get everyone on the same page
16:11:47 <hongbin> Thanks tango . Anything else you want to update the team?
16:11:56 <tango> that's all from me
16:12:06 <hongbin> 3. COE Bay Drivers (jamie_h)
16:12:13 <hongbin> #link https://blueprints.launchpad.net/magnum/+spec/bay-drivers
16:12:13 <muralia_> I can update.
16:12:21 <hongbin> muralia_: please go ahead
16:12:42 <muralia_> the spec is close to being done. there are a few comments about tracking minor versions
16:12:54 <muralia_> and the directory structure.
16:13:10 <hongbin> Yes, we have a session to discuss it later in the agenda
16:13:11 <muralia_> i've create a wip with the directory structure and started with swarm.
16:13:19 <muralia_> https://review.openstack.org/#/c/319973/
16:13:27 <hongbin> #link https://review.openstack.org/#/c/319973/
16:13:55 <muralia_> thats it for now. we should discuss the comments later
16:14:12 <hongbin> Thanks muralia_ . Any question regarding to this BP?
16:14:47 <hongbin> 4. Create a magnum installation guide (strigazi)
16:14:49 <strigazi> Install from source:
16:14:53 <hongbin> #link https://blueprints.launchpad.net/magnum/+spec/magnum-installation-guide
16:14:54 <strigazi> #link https://review.openstack.org/#/c/319399/
16:15:18 <strigazi> tested on ubuntu trusty and centos7
16:15:18 <tcammann> sorry, I'm a bit late...
16:15:26 <hongbin> tcammann: hey
16:15:34 <juggler> hello tc
16:15:53 <strigazi> The idea is two have a system user and install in a virtualenv
16:16:20 <strigazi> I added example init scipts and systemd units to manage services properly
16:16:52 <strigazi> This week I'll sync this content with packaged installations
16:17:19 <strigazi> We have mitaka packages for fedora, suse, debian and ubuntu
16:17:30 <strigazi> that's it from me
16:17:34 <strigazi> oh
16:17:38 <hongbin> strigazi: Thanks strigazi .
16:17:46 <hongbin> strigazi: anything else?
16:17:54 <strigazi> please review and focus on the technical part
16:18:09 <hongbin> I can do that
16:18:25 <strigazi> nothing else
16:18:34 <hongbin> Any question for strigazi ?
16:19:01 <hongbin> #topic Magnum UI Subteam Update (bradjones)
16:19:08 <hongbin> I updated you on behalf of Shu Mutou:
16:19:24 <hongbin> (Shu) I drafted following blueprints to adopt recent Horizon's changes.
16:19:34 <hongbin> (Shu) But it needs some investigation (e.g changes of registry service).
16:19:43 <hongbin> (Shu) https://blueprints.launchpad.net/magnum-ui/+spec/navigation-improvements
16:19:50 <hongbin> (Shu) https://blueprints.launchpad.net/magnum-ui/+spec/generic-detail-framework
16:19:59 <hongbin> (Shu) These will be needed for Newton Release, I think.
16:20:06 <hongbin> That is all from him
16:20:36 <hongbin> Any comment?
16:20:43 <hongbin> #link https://blueprints.launchpad.net/magnum-ui/+spec/navigation-improvements
16:20:49 <hongbin> #link https://blueprints.launchpad.net/magnum-ui/+spec/generic-detail-framework
16:21:24 <hongbin> OK. Adance topic
16:21:28 <hongbin> #topic Other blueprints/Bugs/Reviews/Ideas
16:21:35 <hongbin> 1. Discuss bay driver version
16:21:41 <hongbin> #link https://review.openstack.org/#/c/296384/11/specs/bay-drivers.rst
16:22:19 <hongbin> muralia_: could you give a summary of the discussion in the patch?
16:22:26 <muralia_> so, one topic to discuss is how to track minor versions of a baymodel.
16:22:55 <hongbin> you mean bay driver? (not baymodel)
16:23:02 <tcammann> From the summit, it was understood there was a usecase where operators would need to understand what version of a bay a user is running
16:23:08 <muralia_> basically, when a baymodel changes dramatically, we can expect operators to create a new folder for it
16:23:13 <adrian_otto> I made an outline of an approach in my review comments on that patch
16:23:53 <adrian_otto> bays can have attributes to indicate baymodel name and version. That would allow for bays created from different versions of the same baymodel to exist concurrently.
16:24:31 <hongbin> But bay driver will have a version too
16:24:45 <hongbin> That means bay driver version needs to match a baymodel version?
16:25:10 <hongbin> Or totally remove bay driver version?
16:25:19 <tcammann> Aren't baymodels meant to be immutable?
16:25:42 <tcammann> Why do baymodels need a version?
16:26:03 <muralia_> good point.
16:26:18 <adrian_otto> you can version bays, baymodels, and bay drivers
16:26:25 <muralia_> do we are saying we create a new baymodel everytime we make a minor chage to the driver.
16:26:47 <strigazi> in this case the change is not minor, IMO
16:26:51 <adrian_otto> you expect to have bays of various versions created from the same baymodel. The baymodel will refer to the newest version of a bay driver.
16:26:51 <tcammann> How do you version a bay??
16:27:05 <adrian_otto> you have an attribute for baymodel name, and baymodel version.
16:27:14 <adrian_otto> and those values are immutable.
16:27:33 <strigazi> makes sense
16:27:36 <adrian_otto> actually, it's simpler than that
16:27:48 <adrian_otto> it's baymodel_name and bay_driver_version
16:27:52 <adrian_otto> on the bay
16:28:00 <adrian_otto> the baymodel refers to one bay driver version at a time
16:28:06 <rochaporto> i think that makes sense
16:28:06 <tcammann> yes there shouldn't be a baymodel version
16:28:16 <adrian_otto> and there can be multiple versions of a bay driver present
16:28:39 <tcammann> how are we versioning the bay driver?
16:29:01 <rochaporto> in the dir structure?
16:29:07 <muralia_> we do that by creating subfolders
16:29:35 <adrian_otto> using a semver string taht is recorded initially in the baymodel in a bay_driver_verision attribute. That value is copied to the bay's bay_driver_version upon bay creation.
16:30:13 <tcammann> sure. Can we say the sub dirs version are mandatory, unnecessarily complicates it with making it optional
16:30:15 <adrian_otto> the directory structure in the baymodel can follow the semver string value explicitly
16:30:21 <tcammann> yes
16:30:25 <adrian_otto> or we can use a manifest
16:30:26 <muralia_> how does the baymodel get that string? would we put that in a manifest file? or from the name of the sub directory?
16:31:01 <rochaporto> if we need to keep multiple versions of one driver a manifest won't be enough
16:31:03 <tcammann> Making a manifest makes it far simpler to modify the version
16:31:16 <tcammann> It's going to be a pain in the arse copying and moving directories around
16:31:23 <tcammann> git history looks like a mess too
16:31:48 <muralia_> rochaporto: can you elaborate?
16:32:23 <tcammann> each bay driver dir has a manifest which contains a name and a version. rochaporto that should solve your issue
16:32:23 <rochaporto> don't you need multiple copies of the driver (for multiple versions)?
16:33:06 <eghobo> tcammann: +1 for manifests
16:33:12 <tcammann> if we go down either route, we still need to define when a version bumb is done
16:33:14 <tcammann> *bump
16:33:32 <hongbin> We could use manifest + dir structure
16:33:36 <hongbin> manifest for versioning
16:33:36 <rochaporto> i'm ok with a manifest if everyone else thinks it works (though i don't see how yet :))
16:33:54 <hongbin> dir naming for avoiding name collision for multiple version of hte same driver
16:34:31 <adrian_otto> at our design session we talked about having a subdirectory to contain subsequent versions. If we continue with that idea, we can use the name of that subdirectory to match the baymodel's bay_driver_version string
16:34:35 <tcammann> hongbin: but we Magnum only reads the manifest for resolving the version
16:34:39 <adrian_otto> so it's really easy to match them up.
16:34:59 <hongbin> tcammann: I think there is a use case that to have muliple version of k8s bay driver
16:35:08 <tcammann> I agree
16:35:10 <rochaporto> current|next
16:35:17 <hongbin> tcammann: Like sahara, there is hadoop 1.X hadoop 2.x
16:35:42 <hongbin> tcammann: Then, we need to use the dir naming to avoiding name collision
16:36:07 <adrian_otto> the resolution of "current" and "next" can be in the manifest
16:36:18 <hongbin> ok
16:36:31 <adrian_otto> so the manefest does not need to hold an arbitrary number of values
16:37:00 <tcammann> hongbin: yes, but I don't think we should put the logic for versioning in the sub dir name. Magnum only interprets version from the manifest but we can use sub dirs to avoid name collision
16:37:11 <muralia_> +1
16:37:34 <hongbin> OK
16:37:42 <strigazi> So we'll have both
16:37:43 <hongbin> In summary, manifest for versioning.
16:37:54 <hongbin> sub dirs for name collision
16:38:00 <hongbin> Everyone agree?
16:38:08 <muralia_> +1
16:38:09 <rochaporto> +1 (clear now)
16:38:11 <tcammann> hmm what if you have the same version in 2 sub dirs?
16:38:25 <tcammann> How do you choose a sub dir?
16:38:47 <hongbin> We choose by iterating the dirs, and read the manifest
16:38:50 <adrian_otto> THis shoul dbe answered in a revision of the spec
16:39:03 <rochaporto> the first one :)
16:39:11 <adrian_otto> get all the questions on the review, and allow a revision to address them based on guidance from today
16:39:23 <tcammann> ... or remove subdirs and just have top level dirs which have a manifest and name
16:39:49 <hongbin> tcammann: Yes, that could be another option
16:40:03 <tcammann> simpler for sure
16:40:07 <rochaporto> ok i see now. if we're iterating the dirs then subdirs are not needed
16:40:07 <strigazi> With that we don't have versions
16:40:17 <strigazi> we have just many drivers
16:40:31 <tcammann> why do you want versions?
16:40:47 <muralia_> yes, that might be simpler. it makes sense because sub directories are full copies any way
16:40:55 <hongbin> Users might want to choose the version of k8s to deploy
16:41:04 <hongbin> So version might be needed
16:41:11 <hongbin> E.g. user A deploy k8s 1.x
16:41:16 <hongbin> user B deploy k8s 2.x
16:41:21 <adrian_otto> if bay drivers are not versioned then you must destroy bays when you update bay drivers, or have a proliferation of tons of baymodels.
16:41:37 <tcammann> I mean why do we want to support multiple versions
16:41:52 <tcammann> We need each baydriver versioned so operators understand what the users are runnign
16:42:01 <adrian_otto> we anticipate the cloud operator will find problems that they will resolve by updating the bay driver
16:42:18 <tcammann> agree, but why do we need a sub dir holding multiple vers
16:42:19 <adrian_otto> and we don't want them to have to destroy bays and re-create them to address that
16:43:27 <adrian_otto> if you don't destroy the bays, then you will not know which bays were created with the broken version of the bay driver, and which were created with the fixed version
16:43:52 <adrian_otto> if the bays have bay_driver_version attributes on them, then you know this, and you have that version of the driver available to act on them
16:44:26 <muralia_> adrian_otto: we can do the same with just top level directories. we will have a manifest with a version number in all top level dirs.
16:44:32 <tcammann> I 100% behind having a version somewhere... I'm saying we don't need mutliple sub dirs containing the different versions
16:44:32 <hongbin> Another use case I can think of is to deprecate a old bay driver, we need to have both new and old driver co-exist
16:44:35 <adrian_otto> or example, if you want to stop using a heat resource group for bay masters, and begin using individual heat resources.
16:44:53 <adrian_otto> s/^or/for/
16:45:11 <adrian_otto> tcammann: bear with me here
16:45:32 <hongbin> OK. push the discussion into the reviews
16:45:38 <tcammann> :)
16:45:45 <hongbin> 2. Nested container networking
16:45:48 <adrian_otto> if I make that change, and I have a bay from driver v1 and a bay from driver v2, acting on them requires different logic
16:45:52 <hongbin> #link http://lists.openstack.org/pipermail/openstack-dev/2016-May/095745.html
16:46:34 <hongbin> As explained in hte ML, I proposed to have a magnum-kuryr liaison
16:46:47 <hongbin> To sync up the status of container networking implementation
16:46:55 <tango> I can help with that
16:47:02 <hongbin> Kuryr team seems to have a liaision
16:47:07 <hongbin> tango: Thanks Ton
16:47:42 <tango> I have been talking to them, so I will continue and make it more regular
16:47:46 <hongbin> tango: Could I ask you to give status update in the team meeting every weeks  for the integration work?
16:47:54 <tango> sure
16:48:01 <hongbin> tango: thanks
16:48:18 <hongbin> I will reply the ML and mention Ton as our liaison
16:48:36 <eghobo> tango: what is first COE to integrate?
16:49:05 <tango> I am looking at integrating the current Kuryr driver for Swarm
16:49:20 <tango> It's pretty well understood
16:49:58 <tango> For Kubernetes and Mesos, we should wait for the CNI implementation in Kuryr
16:50:20 <eghobo> got it, thx
16:50:42 <hongbin> Thanks tango for taking this responsibility
16:50:54 <tango> glad to help
16:50:54 <hongbin> #topic Open Discussion
16:52:12 <hongbin> Nothing to discuss. Then we can end the meeting earlier
16:52:17 <hongbin> ?
16:52:25 <muralia_> do we have updated api docs anywhere?
16:52:44 <hongbin> AFAIK, there is no api docs right now
16:52:52 <muralia_> is anyone working on them?
16:52:57 <hongbin> Yuanying is working on a swagger integration
16:53:15 <muralia_> ok.
16:53:21 <hongbin> If his patch lands, we might be able to generate api docs by using swagger
16:53:31 <rochaporto> i would like to start working on this one: https://blueprints.launchpad.net/magnum/+spec/magnum-coe-client-config
16:53:49 <hongbin> rochaporto: I can assign it to you if you want
16:53:53 <rochaporto> yes please
16:54:32 <hongbin> rochaporto: you id?
16:54:40 <rochaporto> rocha-porto
16:54:54 <hongbin> done
16:54:57 <rochaporto> ta
16:55:56 <hongbin> Wrap up earlier?
16:56:31 <hongbin> All. Thanks for joining the meeting. Our next team meeting will be in next week the same time
16:56:35 <hongbin> #endmeeting