16:01:14 #startmeeting containers 16:01:14 Meeting started Tue Nov 3 16:01:14 2015 UTC and is due to finish in 60 minutes. The chair is adrian_otto. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:01:15 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 16:01:17 The meeting name has been set to 'containers' 16:01:22 #link https://wiki.openstack.org/wiki/Meetings/Containers#Agenda_for_2015-11-03_1600_UTC Our Agenda 16:01:28 #topic Roll Call 16:01:42 hi 16:01:43 o/ 16:01:44 o/ 16:01:44 o/ 16:01:47 Adrian Otto 16:01:50 hi 16:01:51 o/ 16:01:57 o/ 16:02:06 o/ 16:02:17 NOTE: daneyon sent his regrets, so he will not be joining us this morning. 16:02:39 o/ 16:03:02 hello jasonsb, rlrossit, rpothier, hongbin, Kennan, bradjones, thingee, muralia, and wanghua 16:03:17 hi all 16:03:21 adrian_otto: hi 16:03:26 hi 16:03:36 #topic Announcements 16:04:09 1) The OpenStack summit in Tokyo has concluded, so our regular meeting schedule has resumed, and has been posted to our wiki page 16:04:23 any further announcements from team members? 16:05:08 #topic Container Networking Subteam Update 16:05:27 normally Daneyon updates us, but he is out so I will update you 16:05:44 we did hod a networking past/present/future design session in Tokyo 16:05:50 s/hod/did/ 16:05:58 (fetching link now) 16:06:26 #link https://etherpad.openstack.org/p/mitaka-magnum-network Networking Design Session 16:06:45 strong consensus to implement what we worked to specify. 16:07:04 any thoughts that have surfaced since then you'd like to share? 16:07:37 Our Magnum Networking Subteam meeting is Thursdays at 1800 UTC 16:08:02 #topic Magnum UI Subteam Update (bradjones) 16:08:10 hey 16:08:26 :-) 16:08:38 it was great meeting many of the contributors in person last week 16:08:49 indeed!! 16:08:56 there are a few more people stepping up to contributing to the UI which is great 16:09:23 we should see a continuation of the containers ui work that Rob Cresswell has started 16:09:27 I'd love to help out with a screencast video demo that showcases the ui and our new features 16:09:29 within the next couple of week 16:09:56 adrian_otto: I'll work on something this week will be good to show it off :) 16:10:07 sweet, just give me a heads up 16:10:13 will do 16:10:32 like to try your ui 16:10:51 there are a few patches up to get translations working properly so help getting those merged will be great 16:10:58 other than that not much else to report 16:11:30 thanks bradjones!! 16:11:40 #topic Review Action Items 16:11:49 1) adrian_otto to send a message to our ML detailing our Design Summit sessions for requested attendance 16:11:55 Status: COMPLETED 16:12:08 #topic Blueprint/Bug Review 16:12:36 now, normally what I do here is drive status for high priority BPs 16:12:55 I have not completed the blueprint curating process for Mitaka yet 16:13:26 I hoped I would be able to do that with you in the Friday meetup in Tokyo, but travel schedules ended up in conflict with that aspiration, sorry! 16:13:47 I also managed to lose my cell phone that morning, but located it again once I got back to the US 16:14:01 so my apologies. 16:14:22 NP adrian 16:14:34 so I'll pause for any discussion relating to Blueprints, bugs, or other team work items for discussion 16:14:51 (we probably deserve a week or so of reduced pressure) 16:15:40 we did hold a team retrospective for the Liberty release cycle and to me it sounded like our team is happy with the way we are running things 16:16:23 if you think of new ideas for things we can change to do better, please find a way to share those so we can incorporate your input 16:17:02 ok, I'll advance to the next topic after just a brief pause. 16:17:22 #topic Functional Testing Strategy 16:17:32 this is a topic we covered in a design session 16:17:43 (does anyone have the link to the etherpad handy?) 16:18:13 we concluded that we'd like to set up a series of gate jobs so that each COE is tested in parallel in separate jobs 16:18:29 I don't think we have a etherpad for that session 16:18:38 this requires patches to project_config to get those set up 16:18:42 #link https://etherpad.openstack.org/p/mitaka-magnum-functional-testing 16:18:48 hongbin: aha, that explains why I could not find one 16:18:54 eliqiao sent a ML about this 16:19:00 thanks dane! 16:19:03 talk related fvt 16:19:44 one thing that came back up after our discussion was about our intent to use Tempest 16:19:59 a contributor expressed to me that we might not want to do that 16:20:33 the rationale offered was that Tempest makes it more difficult for casual contributors to run the tests from the CLI while developing 16:20:44 whereas tox tests are easy to run 16:20:50 thoughts on this point of view? 16:21:23 If not using tempset, the alternative is using magnum CLI? 16:21:54 hongbin: yes, a tox job that uses the CLI to run a defined sequence of tests. 16:22:17 I suppose other approaches are also possible, but that was my understanding as the alternative to Tempest 16:22:36 An issue is that if there is a change of two patches. One on server, the other on magnumclient 16:22:53 but I did note that we have a consensus for using Tempest, so I wanted to confirm that as our intent before we changed it 16:23:01 Then the server patch cannot pass the functional test, because the CLI patch is not merged 16:23:44 hongbin: yes, indeed. But if we were testing the Magnum API through Tempest, then we would not get stuck. 16:24:27 So, I would propose to remove the CLI dependency on the server tests 16:24:36 How other projects do their tests 16:24:46 agreed. Does anyone feel differently? 16:24:58 hongbin: could you give a example what's cause that issue ? 16:25:24 I did not find what's for our functional test for server/cli changes 16:25:28 Kennan: A patch on server to change the API, a second patch on CLI to adopt the new API 16:25:28 (sorry coming into the middle) why don't we want to use tempest? 16:25:42 Tempest is there to test APIs so I say use it... 16:26:01 rlrossit: I am trying to voice a minority position about ease of use 16:26:15 hongbin: seems depends on patch jenkins would deal that, i think 16:26:16 want to give this fair consideration before proceeding 16:26:45 to me the hardest thing to do is get up a successful devstack, not the running of tempest... 16:26:46 Kennan: we just learned about that feature late last week! 16:27:12 I'll speak for myself… I just learned about it. 16:27:37 and the fact that it worked across repos. Super cool. 16:27:43 Kennan: yes, it will. The issue is that the server patch needs the CLI patch to merge first 16:28:05 hongbin, maybe that's actually a good thing? 16:28:06 less dependencies == shorter house of cards == happier developers 16:28:17 hongbin: right now, some tests use rest API test 16:28:26 right? like baymodel related 16:28:47 adrian_otto: No, since the server patch is not able to pass the gate, since it needs the CLI patch that is not merged 16:29:07 adrian_otto: and gate only picked up the CLI patches that are merged 16:29:44 seems violbm have a patch related server_type 16:29:56 not sure if he solved the issue 16:30:04 it may be the issue you talked above 16:30:14 ok, there is another question I wanted to raise 16:30:23 about code coverage 16:31:04 We could add an automated code coverage job that would post coverage details, and deltas, as a non-voting gate job 16:31:28 coverage can take a long time to run when we have a lot of code to test 16:32:06 how would you all feel about having a job that automatically added coverage details into the comment stream of each patch? 16:32:32 hongbin: Doesn't the "Depends-On" construct in Gerrit handle the dependency across non-merged changes in different projects: #link http://docs.openstack.org/infra/manual/developers.html#cross-repository-dependencies 16:32:57 dane: yep 16:33:09 dane: I think it would deal with. but I need double confirm the test 16:33:43 adrian_otto: for coverage test 16:33:48 could you give a exmaple ? 16:33:53 any projects did ? 16:34:03 dane: rlrossit We can discuss the issue later, possibly after the meeting 16:34:07 I have not seen it for OpenStack projects before 16:34:44 but it makes sense when a project begin to mature, and test quality becomes a leading priority 16:35:07 adrian_otto: for coverage, I not sure what's the benefits can bring to us for magnum. but like to try if any tools relaed 16:35:18 we are still in rapid feature development mode, but I'd like to plan ahead and start really fleshing out our functional testing during Mitaka 16:35:56 I want to have confidence that if the gate passes, we are not causing regressions 16:36:19 and that confidence will only come from a solid set of automated tests 16:36:39 sure adrian_otto: #agreed 16:37:27 ok, I'll table the testing discussion for now as I think we've covered it well enough for now 16:38:14 we did decide not to require that all new contributions have a func test tied to them, but that we should ask contributors to supply them 16:38:20 ask != require 16:38:54 so my guidance to reviewers is to politely ask for functional tests along with new features. 16:39:10 but that we will not reject work if such tests are absent without a really good reason 16:39:17 fair enough? 16:39:21 +1 16:39:37 +1. In addition, create a tech-debt for a missing test 16:39:57 +1 16:39:59 yes, hongbin! LEt's file tech debt tickets where we know there are missing tests 16:40:16 good suggestion 16:40:20 this is a great way that new contributors can make meaningful improvements to Magnum by contributing tests 16:40:37 definitely a way to get a lot of love from me, I'll tell you that. 16:41:03 alright, let's proceed to open discussion. I noticed that thingee has a docs topic to touch on 16:41:12 #topic Open Discussion 16:41:46 o/ 16:42:02 :) welcome! 16:42:09 so there has been talks with how to install magnum. The current documentation assumes your developer. 16:42:11 http://lists.openstack.org/pipermail/openstack-operators/2015-October/008458.html 16:42:44 thingee: in our Tokyo contributor's meetup for magnum we covered this 16:42:49 there is quite a bit of promoting magnum happening in the conference, so I want to raise this issue that it would be good for us to be ready for operators. 16:42:55 excellent 16:43:06 we all agreed that producing more comprehensive documentation will be a focus of this cycle 16:43:39 we did a brainstorm and produced an outline of topics for operator (user) docs… because our "user" is a cloud operator persona. 16:44:35 that's about all from me. I'll report this convo back to the thread. 16:44:48 #link https://etherpad.openstack.org/p/magnum-mitaka-summit-meetup 16:44:52 see line 68+ 16:45:21 excellent, thank you adrian_otto 16:45:30 our pleasure 16:45:44 great docs will fuel Magnum's adoption 16:46:32 I have something to discuss if there's nothing else 16:46:39 ok 16:47:23 I saw https://github.com/openstack/magnum/commit/798c7e35ef4b27e81098ab2e4fb03976199ae57b went in, and I noticed in most of test_hacking, it does assertEqual(0/1, ) 16:47:51 there's fixtures set up already for _assert_has_errors() and _assert_has_no_errors() which is much easier to read 16:48:07 should I open up a bug to get those switched over to _assert_has_errors()? 16:48:29 rlrossit: yes 16:48:41 sounds good. Thanks! 16:48:50 i have a topic 16:49:09 feel free to blurt out whatever you like during this section 16:49:31 i attended the manila contributor meetup on friday 16:50:03 one of the topics was mount automation and i mentioned that magnum had discussed this in a session 16:50:35 in all fairness, I mentioned it as a desire (at a very high level), but it was not followed by much discussion 16:50:35 and that manila should consider both nova and magnum use-case when deciding on mount automation strategy (among other things) 16:50:45 certainly 16:50:57 one thing I'm a bit worried about is filesystems as an attack vector 16:51:04 so ben asked me to reach out to inquire about requirements etc 16:51:07 so I'd rather not allow filesystems to be user supplied 16:51:21 I'd like a way for a service provider to "sign" a filesystem 16:51:46 but I'm not even sure if what I want is possible/practical yet 16:52:03 is this in the context of tenant or project owned filesystems? 16:52:10 yes… 16:52:14 imagine this 16:52:28 we allow cinder volumes to be mounted, and accessed by the host 16:52:44 the host mounts the filesystem, causing execution within kernel space 16:53:01 evil user supplies a hacked filesystem designed to take advantage of kernel space execution 16:53:07 leads to compromise of the host 16:53:10 bad. 16:53:31 so one way to mitigate this is for filesystems to not be supplied by users 16:53:50 interesting 16:53:59 do you see manila having the same attack surface? 16:54:02 so maybe there could be a way that the filesystem could be verified as trusted in some way 16:54:24 jasonsb: I'm not sure about manila being vulnerable to that… but possibly. 16:54:45 jasonsb: are you working in manila ? 16:55:27 Kennan: i was pretty active earlier in the year and then dropped out a bit. trying to get back into it 16:56:00 adrian_otto: thank you i had not thought about this before. 16:56:16 It's been keeping me awake a bit worrying about that 16:56:45 is it true that this is a worry only for multi-tenant bare-metal? 16:56:46 the main defense from this in the kernel has been to limit access to the mount namespace 16:57:00 nova provisioned containers wont have this problem 16:57:17 well…. 16:58:14 what I can say is that we need to proceed with caution and offer ways to limit exposure to risks that come from user supplied filesystems, or prohibit them completely. 16:58:35 jasonsb: what do you mean nova provisioned containers ? do you mean nova-docker ? 16:58:36 ok 16:59:00 Kennan: containers inside KVM 16:59:16 we will need to wrap up in a minute and move to adjourn 16:59:17 i see almost out of time 16:59:30 but i'll be here 16:59:35 to learn more 16:59:58 our next meeting will be 2Tuesday 015-11-10 at 1600 UTC. See you then! 17:00:22 Correction: our next meeting will be Tuesday 2015-11-10 at 1600 UTC. See you then! 17:00:27 #endmeeting