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