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