16:00:09 #startmeeting containers 16:00:10 Meeting started Tue Jan 5 16:00:09 2016 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:11 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 16:00:11 #link https://wiki.openstack.org/wiki/Meetings/Containers#Agenda_for_2016-01-05_1600_UTC Our Agenda 16:00:14 The meeting name has been set to 'containers' 16:00:15 #topic Roll Call 16:00:19 Hello 16:00:19 Adrian Otto 16:00:22 o/ 16:00:23 o/ 16:00:23 o/ 16:00:24 o/ 16:00:24 Ton Ngo 16:00:25 hi 16:00:26 o/ 16:00:26 o/ 16:00:31 Perry Rivera o/ 16:00:40 o/ 16:01:04 o/ 16:01:32 hello tcammann, madhuri, dane_, muralia, bradjones, Tango, rpothier, HimanshuGarg, Drago, juggler_, hongbin, and eghobo 16:01:41 Hi everyone 16:02:03 Hi all...Happy New Year 16:02:20 Happy New Year indeed! 16:02:25 Happy New Year everyone 16:03:03 ok, let's get started 16:03:08 #topic Announcements 16:03:22 1) adrian_otto will be delivering a magnum workshop for NASA/JPL Jan 11-13, so seeking pro-tem chair for our 2016-01-12 team meeting. 16:03:32 who can help out next week? 16:03:37 I can 16:03:43 thanks hongbin! 16:04:11 #agreed hongbin will chair our team meeting on 2016-01-12 while adrian_otto is out. 16:04:23 any other announcements from team members? 16:04:29 hi all 16:04:35 I have a quick note 16:04:37 hello vilobhmm11 16:04:42 ok Tango 16:04:48 I have uploaded a new image: https://fedorapeople.org/groups/magnum/fedora-21-7.qcow2 16:05:07 this has k8s 1.1, docker 1.9.1, flannel 0.5.5 16:05:39 We have been using it for about 2 weeks, it seems OK. Please feel free to try out and let me know if there is any problem 16:06:03 sweet, thanks Tango! 16:06:12 This is built with diskimagebuilder, and is Fedora, not Atomic 16:06:23 So hopefully it's a little easier to work with 16:06:37 gotcha 16:06:41 hi all 16:06:50 other announcements from team members? 16:06:58 hi rods 16:07:33 #topic Review Action Items 16:07:40 1) adrian_otto to plan midcycle by ML 16:07:43 Status: pending 16:07:55 sorry I have not started this, but will start today. 16:08:05 #action adrian_otto to plan midcycle by ML 16:08:22 #topic Container Networking Subteam Update (daneyon) 16:08:37 daneyon sis not chime in during roll call, not present today. 16:08:45 s/sis/did/ 16:08:56 #link http://eavesdrop.openstack.org/meetings/container_networking/2015 Previous Meetings 16:09:02 consult the above for updates 16:09:13 #topic Magnum UI Subteam Update (bradjones) 16:09:19 howdy 16:09:25 hi bradjones 16:09:35 not much happened over the break so can probably skip over update today 16:11:22 #topic Essential Blueprint Updates 16:11:40 #link https://blueprints.launchpad.net/magnum/mitaka Mitaka Blueprints 16:11:49 We have three marked Essential: 16:12:07 #link https://blueprints.launchpad.net/magnum/+spec/magnum-tempest (dimtruck) 16:12:25 one patch merged. working through test failures on the other two 16:13:02 correction: there are eight Essentials 16:13:19 thanks dimtruck 16:13:48 One of them is implemented, and 5 are in progress 16:13:54 so I'll ask for updates on the other 4 16:14:10 i will start 16:14:12 #link https://blueprints.launchpad.net/magnum/+spec/user-guide (Tango) 16:14:29 vilobhmm11: I will get to you in a moment, thanks 16:14:37 I started with a skeleton, to be filled in section by section 16:14:38 adrian_otto : sure np 16:15:15 Tango: should we plan to divide up this work now? 16:15:27 One question for the team is: there are some current document, e.g. TLS. Should we pull them into the user guide and make everything consistent? or should we keep them separate? 16:15:56 adrian_otto: Yes, my thought is that with the skeleton, everyone can jump in and contribute 16:16:07 great question. How about we start with the missing content, and then re-arrange it once we have the full set of content. 16:16:25 Sounds good 16:16:34 ok, so if you are looking for a way to help during the Mitaka release, look at this BP please 16:16:39 I think there should be one document for all 16:16:45 +1 16:16:55 madhuri: there will be a single index 16:17:07 That's my thought also, just want to double check with the team 16:17:08 to be consistent with the OpenStack documentation style 16:17:29 Yes 16:17:51 my suggestion is based on a concern that we should not spend too much effort initially working on the formatting, but be sure that we have the content together 16:17:55 Tango: I can help for the TLS part 16:18:08 and leave the editorial process to a subsequent stage within this dev cycle 16:18:10 madhuri: Thanks 16:18:40 Yes, we should fill in with the content first and revise later 16:18:52 great, let's look at the next BP 16:18:58 #link https://blueprints.launchpad.net/magnum/+spec/resource-quota (vilobhmm11) 16:19:23 adrian_otto : before the break we had a discussion on ML 16:19:28 http://lists.openstack.org/pipermail/openstack-dev/2015-December/082520.html 16:19:33 details captured here 16:20:13 #link http://lists.openstack.org/pipermail/openstack-dev/2015-December/082520.html ML Discussion about Resource Quota 16:20:14 in gist since we rely on heat the discussion stoped whether we should rely on quota provided by heat 16:20:43 I did propose a patch WIP https://review.openstack.org/#/c/259201/ but there is no clear direction here 16:20:50 the summary there is that we raised legitimate concerns about duplicating existing quota capabilities that exist elsewhere in OpenStack 16:21:19 I offered some guidance not to overlap, but focus on the areas where resource limits would be unique to Magnum 16:21:29 adrian_otto : thats a better way to put it thanks! 16:22:17 sure so for mitaka will restrict the blueprint to that i.e. resource limits would be unique to Magnum 16:22:24 if we feel that raising better exceptions for limits in other systems (such as Nova, for example) could enhance the user experience, we could view that as a low priority enhancement. 16:22:48 is that something our team feels comfortable with? 16:23:01 yes but for that we need support from other projects 16:23:14 for the second part 16:23:33 but for the first part, we would only implement limits on resources that are within Magnum 16:23:42 Yes agree ^ 16:23:45 sure 16:23:52 +1 16:24:09 +1 16:24:26 and if we do that well, then it makes sense to revisit the discussion to decide what overlap (if any) is appropriate for other key resources that come from other services. 16:24:42 Will there be anything we quota beyond bays? 16:24:52 possibly baymodels 16:24:57 yes 16:25:04 and maybe containers 16:25:32 IMHO better to start off with an etherpad seperating out which resource fall in which category magnum only vs depedent on other projects 16:25:36 yes, with an acknowledgement that container limits only apply when using the Magnum API, and not native APIs. 16:25:43 containers would be very interesting. If you locked your users out of the native APIs you can limit the container access :) 16:25:50 hongbin: How is it possible to quota containers when running from native clients? 16:26:03 adrian_otto: +1 16:26:07 You don't quota the native clients 16:26:10 madhuri : only track created using magnum api 16:26:11 madhuri: That would be an eventually consistent limit 16:26:22 there is a way, but it's not clean 16:26:28 madhuri: the assumption is not using native CLI 16:26:48 basically Magnum would need to poll native APIs for inventory, and compare those to configured limits 16:26:59 ripe for race conditions. 16:27:15 You would also have to know which users started which containers... 16:27:30 adrian_otto: magnum may poll COE for usage but may not get back the tennant data 16:27:46 we know which COE's belong to which tenant 16:27:54 but we would not have per-user limits in that case 16:28:05 yes plan to add that as part of the quota table which i am planning to introduce in magnum 16:28:27 per user limits for containers would be sexy though 16:28:30 absolute limits of per tenant quota can be stored there 16:28:56 tcammann: I do agree, but let's set a low bar to start with. 16:29:06 alrite lots of useful insights here…but the path seems clear now 16:29:10 thanks everyone 16:29:20 there is also another topic that surfaced in discussion 16:29:22 :) np adrian_otto 16:29:36 a distinction between a limit and an event used for accounting purposes 16:30:00 limits matter to operators for system stability, and to catch runaway usage patterns 16:30:22 accounting matters to the service providers who want to allocate costs for their infrastructure based on usage 16:30:54 so we can emit RPC events for usage for a wide variety of things 16:31:05 and implement limits for a subset of those. 16:31:16 adrian_otto : sure but isn't the event closely tied to the limit ? i mean you will raise an event if you reach above limit 16:31:26 yes, these go hand in hand 16:31:38 ok 16:31:46 there is also a distinction between a usage event and an alert 16:32:06 a quick study of ceilometer will give a sense of this 16:32:31 events are about measuring raw usage 16:32:32 adrian_otto : ok will check it out..thanks for the pointers ! 16:32:43 and alerts are about acting when events cross a threshold 16:32:59 ok, thanks vilobhmm11 for your work on this 16:33:05 anything more you need from the team to continue? 16:33:24 adrian_otto : no this was really useful..thanks everyone! 16:33:37 we can move to next topic…thats it from my side 16:33:40 ok, next BP is related to the user-guide, so might not require further discussion: 16:33:46 #link https://blueprints.launchpad.net/magnum/+spec/magnum-troubleshooting-guide (Tango) 16:34:17 Tango: anything unique to this BP that we should touch on today? 16:34:33 I also have a skeleton started, based on the initial brainstorm from the summit 16:35:03 I will upload that today so everyone can help to fill in 16:35:22 cool, thanks! 16:35:33 with Tango checking in the skeleton, it would get easier for the team to add individual cases 16:35:50 #link https://blueprints.launchpad.net/magnum/+spec/split-gate-functional-dsvm-magnum (eliqiao) 16:36:08 this one is the last essential BP that is marked as in progress. 16:36:49 eliqiao: yt? 16:37:16 #topic Open Discussion 16:38:13 I think the pluggable keystone bluprint can be closed now. https://blueprints.launchpad.net/magnum/+spec/pluggable-keystone-model 16:38:30 most of the things that are useful have been addressed by https://review.openstack.org/#/c/218699/5 16:39:35 muralia: okay, I marked it as Implemented. Will that suffice? 16:39:42 yes 16:40:16 ok 16:40:44 I want to take the chance to discuss the BP: https://blueprints.launchpad.net/magnum/+spec/unified-containers 16:41:02 do any contributors planning to attend our midcycle have scheduling constraints I should know about? 16:41:19 when is it Adrian? 16:41:30 probably in Feb 16:41:49 or possibly late Jan 16:41:55 ok 16:42:07 I can't do Jan or early Feb 16:42:12 adrian_otto: I will be away from 2/1 to 2/13 16:42:12 where will it be held? 16:42:13 we need to give attendees enough time to approve/arrange travel 16:42:51 probably in California 16:43:14 Need one week or two to get approval from me 16:43:24 we held two midcycles in the bay area, and those were well attended 16:43:33 hongbin: acknowledged 16:46:04 adrian_otto: let me know when we are ready to discuss the unified containers BP :) 16:46:23 my bad days are 1/21-24 and 2/11-15 16:46:28 tcammann: thoughts on HP hosting us in Sunnyvale? 16:46:54 hongbin: we can cover that now if you like 16:47:17 adrian_otto: thx! 16:47:42 Just a quick note. As we discussed, I started an etherpad to work on the spec 16:47:50 #link https://etherpad.openstack.org/p/magnum-unified-container-actions 16:48:07 Please contribute to the etherpad. Greatly appreciate it 16:48:10 Need some solid dates adrian_otto 16:48:45 ok, tcammann. We should have that in a couple of days. I will circulate a doodle poll. 16:48:52 great 16:49:02 I'll go start that now to narrow in on some dates. 16:49:24 if you can avoid the last week of January that will help others who may want to attend 16:49:47 it is tough for people from other projects to attend if all the mid-cycles occur at the same time 16:50:12 this can help: https://wiki.openstack.org/wiki/Sprints#Mitaka_sprints 16:50:37 thanks for that feedback anteaya 16:50:44 welcome 16:54:43 ok, here is the poll for selecting the date for the Magnum Midcycle: 16:54:59 #link http://doodle.com/poll/k8iidtamnkwqe3hd Find a date for the Magnum Midcycle 16:55:31 I can subtract from that based on overlap with other projects. Feel free to leave comments on the doodle poll about relevant conflicts. 16:55:59 thx adrian_otto 16:56:33 I posted a WIP review for using heat conditionals, as an alternative to provider networks in heat. 16:56:38 https://review.openstack.org/#/c/261094/ 16:56:42 We will wrap up in a few minutes 16:56:57 thanks rpothier 16:57:15 this is for simplifying our template generation? 16:57:21 yes 16:57:57 ok, cool 17:00:06 Our next team meeting will be on 2016-01-12 at 1600 UTC, chaired by hongbin. Cheers! 17:00:11 #endmeeting