16:00:14 #startmeeting containers 16:00:14 Meeting started Tue Oct 4 16:00:14 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:15 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 16:00:18 The meeting name has been set to 'containers' 16:00:22 #link https://wiki.openstack.org/wiki/Meetings/Containers#Agenda_for_2016-10-04_1600_UTC Our Agenda 16:00:30 #topic Roll Call 16:00:34 Adrian Otto 16:00:35 o/ 16:00:36 Stephen Watson o/ 16:00:37 Jaycen Grant 16:00:38 Ton Ngo 16:00:39 o/ 16:00:39 Hieu LE o/ 16:00:41 o/ 16:00:43 o/ 16:00:57 o/ 16:01:19 o/ 16:01:28 Hello Drago1 swatson jvgrant tonanhngo strigazi hieulq_ dane_leblanc_ muralia hongbin and diga 16:01:34 o/ 16:02:56 hello eghobo 16:03:06 #topic Announcements 16:03:13 1) There will be no team meeting on 2016-10-25 because that is the week of the OpenStack Summit in Barcelona. 16:03:27 2) I have responded indicating that the Magnum team will definitely participate in the PTG in Atlanta in February. 16:03:28 #link http://www.openstack.org/ptg 16:04:01 Does anyone have questions about either of these? We will cover Design Summit planning later in our agenda today. 16:04:54 #topic Review Action Items 16:04:57 1) #action adrian_otto follow up with Kuryr PTL to arrage a joined session 16:05:15 Status: Pending. 16:05:34 I do have information from ttx about when the various session timeslots are planned 16:05:50 so I expect to have topics roughly arranged to those over the next week or so. 16:06:00 #action adrian_otto follow up with Kuryr PTL to arrange a joined session 16:06:16 #topic Essential Blueprint Review 16:06:23 Support baremetal container clusters (strigazi) 16:06:29 #link https://blueprints.launchpad.net/magnum/+spec/magnum-baremetal-full-support 16:07:07 I was mostly testing the optional private network approach and there is a bp for that 16:07:11 fetching 16:07:32 #link https://blueprints.launchpad.net/magnum/+spec/decouple-private-network 16:07:53 With this change it will be possible to consolidate the bm vm drivers 16:08:10 thanks strigazi 16:08:27 adrian_otto have a look at the bp 16:08:35 it will be nice to have a single driver for each COE/OS 16:08:35 it's not approved yet 16:08:51 That is the goal, 16:08:59 ok, one moment. 16:09:09 then all drivers will be bm/vm compatible 16:09:30 assuming there are bm images :) 16:09:41 how would we choose between a vm and bm? 16:09:42 thanks 16:09:46 if a driver supports both? 16:09:47 okay, I approved the direction 16:09:50 --server-type 16:09:59 and I set the definition status to Drafting 16:10:04 it will use the same templates 16:10:16 muralia ^^ 16:10:31 we can talk a bit later about the right Series Goal and Milestone Target for it 16:10:49 sure 16:11:04 it's very close 16:11:14 muralia, do you have a question? 16:11:35 yes, we wanted to get away from looking at multiple flags before choosing a driver 16:11:47 now we'll have drivername and server_type 16:12:09 It will still be one driver 16:12:10 So you prefer to maitain two driver? 16:12:14 So you prefer to maitain two drivers? 16:12:51 sure. just getting --driver from the user should be good enough 16:12:59 let's table design discussion on this for now, and revisit it either in open discussion or in a subsequent topic section in an upcoming meeting. I do want to capture this, but I'm worried we may not have adequate time to cover what's planned for today. 16:13:17 ok 16:13:25 thanks muralia and strigazi 16:13:31 #link https://blueprints.launchpad.net/magnum/+spec/user-guide Magnum User Guide for Cloud Operator (tango) 16:13:40 I don't have further update, likely won't get to revisit the user guide until after the summit. I think there is sufficient content for now. 16:13:44 Unless Spyros wants to cover the operator guide, we can probably drop this from the agenda for now. 16:14:18 should this BP be marked as Implemented, and superseded by a more narrowly scoped BP? 16:14:48 or is there actually work on the user guide that needs to be complete to consider this done? 16:15:08 Well, I guess we can mark it as implemented, but of course it will be updated on an ongoing basis 16:15:16 +1 16:15:24 documentation is never done 16:15:28 I see the guide as a living document, so we will always be improving it 16:15:33 exactly 16:16:02 ok, marking it as such. Feel free to open more BP's for the remaining scope. 16:16:15 sounds good, thanks Adrian 16:16:40 #link https://blueprints.launchpad.net/magnum/+spec/bay-drivers COE Bay Drivers (muralia) 16:16:49 (Cluster Drivers) 16:16:49 https://review.openstack.org/#/c/374906/ 16:17:01 so the functional tests are still timing out and failing 16:17:28 There is a problem with the OSIC cluster and the devstack neutron configuration 16:17:33 I see a comment from spyros this morning and he's seeing the same behaviour as me. they pass on my devstack 16:17:55 so when I looked into this late last week it looked like there were external web resources used by python (libraries I think) that were failing to download in order to set up the gate test system. 16:18:05 the problem is that we use 10/8 16:18:15 has that trouble continued, or are there other problems that I did not notice? 16:18:21 adrian_otto, that is another problem and it is fixed 16:18:22 thats been fixed now. 16:18:47 ok, I'm glad to hear that. 16:18:50 this morning, tests actually ran and failed due to time outs 16:19:09 do we need team participation or guidance from any other teams to get through the current trouble? 16:19:33 I'm thinking timeouts = slow servers, or did we change the gate tests so they take longer now? 16:19:42 Let me explain for a minute 16:20:19 The osic cluster uses a physical network 10.0.0.0/8 16:20:45 and we use the same to provide the private network in the dsvm 16:21:04 because of that rabbit it unreachable 16:21:14 oh, I see 16:21:22 the neutron devstack team works on that 16:21:38 I have pushed a temporary fix until they address the issue 16:21:47 we'll if it works 16:21:48 so what if we used another RFC/1918 address range for our purposes? 16:21:53 did that get merged? 16:21:54 https://review.openstack.org/381940 16:22:12 adrian_otto, yes that is the solution 16:22:39 but in patch 381940 the subnet is in the 10.0.0.0/8 block. 16:23:18 it's just an address toward the end of the block 16:24:08 What network do you propose? 16:24:08 okay, let's continue that discussion on the comment stream for: 16:24:12 #link https://review.openstack.org/381940 16:24:44 172.16.0.0/12 Might work well for that 16:24:52 ok 16:25:19 if other have time, do download the driver patch and test it while we wait for the gates to pass. 16:26:04 ok, that concludes review for essential blueprints. Thanks muralia. 16:26:08 #topic Other Blueprints/Bugs/Reviews/Ideas 16:26:15 Kuryr Integration Update (tango) 16:26:19 Hongbin and I attended the Kuryr meeting yesterday. 16:26:35 They have dropped the rest/api driver design due to the security concern we raised 16:26:46 oh, wow 16:26:50 Now they are considering other ideas 16:27:34 Hongbin suggested breaking the agent into two parts and 2 potential ways to handle secure connection 16:28:11 They asked us to post to the ML to ask for ideas from the Keystone team. I will do that later today 16:28:28 sweet. I'm thrilled to hear it. Thanks hongbin and tonanhngo. 16:28:34 (describe the scenario and the requirement) 16:28:35 any other remarks on this topic? 16:28:57 We also suggested inviting the Keystone team to join our Barcelona session to discuss further 16:29:15 I did talk to the Keystone PTL (Steve) about this use case 16:29:56 thanks tonanhngo 16:30:05 He doesn't see a good solution 16:30:15 This may require something new 16:30:40 this might be something to put on the PTG schedule 16:30:49 and Summit 16:31:09 we can see what we get from the ML 16:31:12 one last topic to clear before we get to Summit Session Planning 16:31:25 tonanhngo: okay to assign you an action for that? 16:31:35 Sure 16:31:58 #action tonanhngo to lead am ML discussion to find potential solutions for secure Kuryr/Magnum integration. 16:32:05 s/am/an/ 16:32:17 next topic is: 16:32:18 Grenade gate for testing upgrades (Drago) 16:32:42 #undo 16:32:42 Removing item from minutes: 16:32:59 #action tonanhngo to lead an ML discussion to find potential solutions for secure Kuryr/Magnum integration. 16:33:19 Drago: anything to cover for this week on this topic? 16:33:29 So there is a project called Grenade that has a plugin that would allow us to test rolling upgrades to make sure no patch breaks upgrading from one version to the next 16:33:41 Heat has such a gate. Here's their spec for it https://github.com/openstack/heat-specs/blob/master/specs/liberty/upgrade-tests.rst 16:34:01 I think Magnum should have a grenade gate as well 16:34:13 #link https://github.com/openstack/heat-specs/blob/master/specs/liberty/upgrade-tests.rst Heat Grenade Gate 16:34:17 +1 16:34:21 +1 16:34:22 for our service? 16:34:24 +1 16:34:28 or to test the drivers? 16:34:29 Drago: what exactly we are going to use this project to test? 16:34:32 yes, strigazi 16:34:35 For the service 16:34:43 ok 16:34:48 sounds good 16:35:03 any opposing points of view to consider? 16:35:08 I am still not sure what is covered by using that test? 16:35:46 i guess we would test upgrades from the last magnum release (newton) to the latest in master 16:36:10 ok, that is basically a db migration 16:36:10 hongbin: It ought to function as it does for Heat. So the spec (and its links) should have the info you need 16:36:32 ok, i need sometime to go though the spec 16:36:43 hongbin: As I understand it, it runs the service at different versions at the same time too, so not just a db migration 16:37:06 so it run a mitaka magnum, and a newton magnum? 16:37:27 Yes. Install M, upgrade one to N, then other to N 16:38:14 what kinds of pitfall this test is going to capture? 16:38:56 maybe we don't need to discuss teh details in this meeting 16:39:05 hongbin: See https://github.com/openstack-dev/grenade#theory-of-upgrade 16:39:20 i am ok to postponse the discussion in irc 16:39:47 https://github.com/openstack/heat-specs/blob/master/specs/liberty/upgrade-tests.rst has a problem description section which would roughly apply to Magnum clusters as well. 16:40:09 That's all I had 16:40:25 thanks Drago 16:40:35 #topic Summit Session Planning 16:40:59 #link https://etherpad.openstack.org/p/ocata-magnum-topics Summit Session Planning Etherpad 16:41:15 I'd like all of your input on the topics we should cover together in Barcelona 16:41:20 where is the old document? 16:41:29 one moment, I will look 16:42:00 was it https://etherpad.openstack.org/p/magnum-newton-midcycle-topics ? 16:42:17 https://etherpad.openstack.org/p/magnum-newton-midcycle-topics-restored-998 16:42:19 the etherpad server seems really slow for me 16:42:22 Restored link ^ 16:42:23 https://etherpad.openstack.org/p/magnum-ocata-summit-topics 16:42:49 from here: http://eavesdrop.openstack.org/meetings/containers/2016/containers.2016-09-20-16.00.log.html 16:42:49 oh, let's not use mine then 16:42:59 Let's use this one: 16:43:04 #link https://etherpad.openstack.org/p/magnum-newton-midcycle-topics 16:43:26 but that's for newton 16:43:34 so I will copy those over to here: 16:43:36 adrian_otto: https://etherpad.openstack.org/p/magnum-ocata-summit-topics 16:43:47 right: 16:43:49 #link https://etherpad.openstack.org/p/magnum-ocata-summit-topics 16:47:47 Lots of typing going on in the etherpad. What did we want to discuss about this during the meeting? 16:49:33 Drago: i just took a lot at the Grenade project. it seems it is a good idea to use it in magnum 16:49:55 hongbin: Good :) 16:50:38 Let's get the topics in the etherpad and put some votes on them to judge relative importance of each 16:50:59 and in a few minutes we can enter Open Discussion 16:51:12 we will revisit this again next week once I have matched what we have with our scheduled timeslots 16:53:11 our nodegroup pool design sessions will probably need 2 hours 16:53:54 thoughts on having both a fishbowl and discussion on that one? 16:54:24 ok, feel free to continue putting detail into the etherpad 16:54:35 I will enter open discussion as well now 16:54:41 #topic Open Discussion 16:55:03 jvgrant and I are going to try go get as much of the spec ironed out as possible so that people can review it before the summit and we have a better idea of what needs to be discussed there 16:55:28 thanks Drago and jvgrant 16:55:29 adrian_otto: Still +1 to fishbowl and discussion 16:55:51 adrian_otto: Maybe have the fishbowl first? 16:56:23 ideally we would meet as a team and arrange our thoughts nicely around the spec, and then be ready to show that in a fishbowl for wider community input. 16:56:43 but I do see the wisdom in reversing it if we have a spec worked out in advance 16:56:59 adrian_otto: Yes, that's what I was hoping the lead-up to the summit would be 16:57:24 Otherwise I would agree that it'd make sense to do the fishbowl 2nd 16:57:26 I'd like us to be well prepared on all topics with supporting written plans (or problem statements) for each 16:57:47 since we have all the initial design from mid-cycle and our first spec, it would be good to get a fishbowl, and then the last session to finalize to be ready to implement 16:58:06 ok, I'm happy to hold the fishbowl first, and then use a team session following that to act on the input. 16:58:20 adrian_otto: Perhaps we should dedicate some time in the last weekly meeting before the summit to have a more focused discussion on NodeGroups 16:58:21 jvgrant: +1 16:58:44 okay, I can put our agendas up for the next two weeks 16:58:51 on the meetings page for Magnum 16:58:55 Which would be the 18th? And let everyone know about that next week 16:59:01 yep 16:59:03 Thanks 16:59:37 jvgrant: Maybe we could have an action item to get as much of the spec done this week as we can 16:59:37 thanks everyone for attending today. Our next meeting will be 2016-10-11 at 1600 UTC 16:59:58 #endmeeting