16:03:06 <adrian_otto> #startmeeting containers
16:03:06 <openstack> Meeting started Tue May 12 16:03:06 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:03:07 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:03:09 <openstack> The meeting name has been set to 'containers'
16:03:14 <adrian_otto> #link https://wiki.openstack.org/wiki/Meetings/Containers#Agenda_for_2015-05-12_1600_UTC Our Agenda
16:03:18 <adrian_otto> #topic Roll Call
16:03:18 <xek> o/
16:03:22 <adrian_otto> Adrian Otto
16:03:27 <apmelton> Andrew Melton
16:03:28 <joffter> Jennifer Carlucci
16:03:31 <hongbin> o/
16:03:33 <Tango> Ton Ngo
16:03:35 <juggler> Perry Rivera
16:03:36 <sdake_> yar hey folks sdake here o/
16:03:40 <johnthetubaguy> John Garbutt (lurking only)
16:03:45 <rpothier> Rob Pothier
16:04:18 <adrian_otto> Hello xek, apmelton, joffter, hongbin, Tango, juggler, sdake_, johnthetubaguy, and rpothier
16:04:48 <adrian_otto> special welcome to johnthetubaguy, our Nova PTL here to discuss our nova-docker agenda item with us
16:05:05 <adrian_otto> do we have other Nova team members present today?
16:05:34 <adrian_otto> ok, let's begin
16:05:38 <adrian_otto> #topic Announcements
16:05:52 <adrian_otto> 1) Reminder: Our IRC Meeting will be skipped on 2015-05-19 because we will be at the Vancouver Design Summit
16:05:56 <adrian_otto> that's next week
16:06:09 <adrian_otto> we have a very full summit coming up.
16:06:17 <jjlehr> o/
16:06:31 <adrian_otto> 2) I will be moving our topics from our etherpad to the design summit schedule today
16:06:44 <sdake_> hmm I did that this morning adrian_otto ;-)
16:06:54 <sdake_> but feel free to reorder
16:07:00 <adrian_otto> Yay, one less thing to do!
16:07:07 <juggler> nifty
16:07:10 <adrian_otto> thanks for your help sdake_
16:07:14 <sdake_> the summit orgs want to lock down the schedule today
16:07:20 <sdake_> so we need to finish the job on that asap
16:07:28 <adrian_otto> 3) We found a defect in 2015.1.0
16:07:37 <sdake_> 5 defects in fact ;-)
16:07:48 <adrian_otto> so we will be releasing 2015.1.1 based on stable/keystone
16:08:05 <sdake_> stable/kilo ;-)
16:08:14 * sdake_ thinks adrian_otto needs more sleep :)
16:08:18 <adrian_otto> this raises the question of the effectiveness of our gate tests, which we can discuss in Open Discussion today
16:08:27 <adrian_otto> OMG, what did I say
16:08:32 <diga_> Digambar Patil
16:08:37 <adrian_otto> yes, I in fact only had 3 hours of sleep
16:08:37 <juggler> hehe
16:08:47 <adrian_otto> sorry, you know what I meant
16:09:11 <sdake_> adrian_otto tell me about it been running on 5 hrs of sleep for 5 weeks str8
16:09:15 <adrian_otto> so I wanted to bring up the release to see if there are any other backports that we should get in before I tag 2015.1.1?
16:09:17 <sdake_> but got 12 yesterday so I am rockin today :)
16:09:27 <adrian_otto> sdake_: I'm jealous
16:09:50 <adrian_otto> that's it for prepared announcements.
16:09:56 <adrian_otto> any announcements form team members?
16:09:59 <adrian_otto> *from
16:10:10 <sdake_> yes
16:10:16 <sdake_> magnum is finally operational in kolla as a container
16:10:20 <sdake_> \o/
16:10:22 <adrian_otto> WHOOT!!
16:10:24 <apmelton> woooo
16:10:25 <sdake_> redis example works
16:10:32 <juggler> yeah
16:10:36 <jjlehr> cool!
16:10:42 <adrian_otto> sdake, do we need any docs for how to set that up?
16:10:57 <adrian_otto> perhaps juggler may be willing to volunteer to assist?
16:11:18 <juggler> *gulp* :)
16:11:36 <sdake_> docs, hmm, you just run kolla start
16:11:38 <sdake_> and your good to go
16:11:45 <juggler> or verify at the least
16:11:47 <sdake_> there are scripts in the demo/magnum directory of kolla
16:11:54 <sdake_> juggler ya feel free to verify
16:11:55 <adrian_otto> maybe we can just mention that in our FAQ
16:11:58 <sdake_> that run the examples
16:12:03 <sdake_> adrian_otto faq is good idea
16:12:14 <sdake_> juggler could use a second eyeball set to verify if your up to it
16:12:24 <sdake_> read kolla dev-quickstart to get rolling
16:12:26 <adrian_otto> because I'd like Openstack cloud operators to know that Magnum will work with an OpenStack cloud where all the services run in Kolla
16:12:27 <sdake_> should take you less then 20 minutes
16:12:43 <juggler> i hope :)
16:12:55 <adrian_otto> turtles turtles all the way down…
16:13:06 <sdake_> oh not again ;)
16:13:11 <sdake_> someone said tha twith tripleo :)
16:13:15 <juggler> turtles?
16:13:16 <adrian_otto> awesome. I also got a new computer that I can use to make screencasts with
16:13:21 <adrian_otto> juggler: n/m
16:13:31 <adrian_otto> so I plan to make one to have on our project page
16:13:59 <adrian_otto> please raise your hand if you will be attending the Summit next week
16:14:01 <adrian_otto> o/
16:14:06 <sdake_> o/
16:14:06 <apmelton> o/
16:14:11 <hongbin> o/
16:14:12 <Tango> 0/
16:14:25 <johnthetubaguy> o/
16:14:36 <jjlehr> o/
16:14:41 <rpothier> o/
16:14:48 <adrian_otto> that's terrific. I have something to share… one sec
16:15:37 <adrian_otto> #link http://libertydesignsummit.sched.org/adrian.otto.ics Adrian's Schedule
16:15:39 <thomasem> Hey all, sorry I'm late.
16:15:54 <adrian_otto> so those are the sessions I'm planning to attend, including all of ours
16:16:22 <adrian_otto> so if you have not planned your week yet, you can use that as a starting point.
16:16:34 <adrian_otto> ok, any more announcements?
16:16:51 <adrian_otto> we had no action items last week, so I will skip reviewing that
16:17:14 <xek> I finished the oslo.versionedobject port https://blueprints.launchpad.net/magnum/+spec/versioned-objects
16:17:28 <dims> o/
16:17:30 <adrian_otto> #topic It is essential we finish design session planning
16:17:34 <adrian_otto> #link https://etherpad.openstack.org/p/liberty-magnum-topics
16:17:45 <adrian_otto> sdake_: is there any more to be done here?
16:17:58 <sdake_> double check, reorg for ordering?
16:18:02 <adrian_otto> xek: awesome!
16:18:05 <sdake_> I had to cut 1 session I think
16:18:06 <thomasem> o/ I am also attending the Vancouver summit
16:18:13 <adrian_otto> thomasem: great!
16:18:24 <sdake_> I ordered based upon when I htink people will be bestfor the most popular +1 sessions
16:18:26 <johnthetubaguy> not sure if you have seen this one: https://wiki.openstack.org/wiki/Summit/Liberty/Etherpads
16:19:11 <adrian_otto> thanks johnthetubaguy. I can make sure Magnum's get listed there.
16:19:40 <adrian_otto> isn't there also a tool from ttx for getting the abstracts onto the sched.org system?
16:19:52 <johnthetubaguy> adrian_otto: there is
16:20:05 <adrian_otto> #action adrian_otto to add Magnum's design sessions to https://wiki.openstack.org/wiki/Summit/Liberty/Etherpads
16:20:07 <johnthetubaguy> adrian_otto: design-summit-prep.openstack.org
16:20:13 <adrian_otto> thanks johnthetubaguy
16:20:31 <ttx> adrian_otto: I re-sent the email to sdake so he can do it too
16:20:46 <adrian_otto> thanks ttx
16:20:56 <sdake_> adrian_otto I can take it on or you can, let me know now so I can plan my day ;)
16:21:03 <ttx> adrian_otto: but the site shall be self-explaining. Only thing to know is that obvious limitations are by design
16:21:08 <adrian_otto> sdake_:  Please help with that
16:21:17 <sdake_> ack
16:21:29 <adrian_otto> if too busy I will take it
16:21:48 <sdake_> i'm good - today is a chill day for me
16:21:49 <adrian_otto> looks awesome. great job on this ttx
16:21:56 <adrian_otto> ok, sweet
16:22:00 <adrian_otto> next topic
16:22:10 <adrian_otto> we're all good on this, right?
16:22:17 <sdake_> iwell
16:22:24 <sdake_> do people want to reorg the sessiosn in any way?
16:22:38 <sdake_> maybe we should take a couple minutes and look at the etherpad
16:22:39 <adrian_otto> we did sort them as a team last week
16:22:48 <adrian_otto> ok, let's review it now
16:22:58 <sdake_> I dont hvaae a link handy :)
16:23:04 <adrian_otto> #link https://etherpad.openstack.org/p/liberty-magnum-topics
16:23:57 <adrian_otto> you are welcome to add votes and request a re-sort
16:24:29 <adrian_otto> so Scaling Magnum and Everything You Wanted… will drop off
16:24:41 <adrian_otto> the previous six will get the workrooms
16:25:26 <sdake_> nah, on thursday I have those sessions scheduled
16:25:32 <sdake_> I jut renamed them to somethign shorter to fit in the etherpad
16:25:52 <thomasem> Can't remember which I voted for already :(
16:26:06 <thomasem> best guess
16:26:09 <sdake_> everything you wanted to know about magnum dropped off
16:26:26 <adrian_otto> sdake_: take a look at the numbering I just put in. Does that match your efforts?
16:26:53 <juggler> thomasem: i think you're color-coded as powder blue on there. click the users icon (upper right corner)
16:27:10 <thomasem> juggler: I am, but some of the coloring got lost in the sorting.
16:27:12 <juggler> or whatever color that is
16:27:14 <juggler> :)
16:27:16 <thomasem> :P
16:27:24 <diga_> adrian_otto, sdake_ : will there be any possibility/arrangment for remote member to attend the 1/2 session ?
16:27:37 <apmelton> I don't see "Magnum Scheduler Design Breakout " in the schedule at the top
16:27:39 <juggler> +1 diga
16:27:40 <sdake_> adrian_otto yup looks good
16:27:43 <adrian_otto> diga_: Sorry, but not this time
16:27:51 <apmelton> did it get merged into something else?
16:27:57 <diga_> adrian_otto: NP
16:28:02 <sdake_> I tried to put the sessions equireing high thought on wednesday
16:28:06 <juggler> possible recordings taking place?
16:28:21 <sdake_> juggler there is no recording of essions - only 28 seats per room
16:28:27 <adrian_otto> ok, let's wrap up on this one
16:28:37 <sdake_> the main openstack summit sessions will all be recorded tho
16:28:38 <juggler> ah
16:28:41 <adrian_otto> fishbowls do get recorded, I think
16:28:54 <sdake_> yup that makes sense adrian_otto
16:29:18 <adrian_otto> ok, any final thoughts on this before advancing topics?
16:29:22 <apmelton> sdake_: adrian_otto: "Magnum Scheduler Design Breakout" is number two in the workrooms list, but I don't see it in the schedule
16:29:29 <apmelton> was it renamed or merged with another topic?
16:29:44 <adrian_otto> apmelton: sdake_ volunteered to solve this today.
16:30:22 <adrian_otto> ok, let's talk nova-docker
16:30:28 <sdake_> apmelton I merged that with abstracting the container backend
16:30:31 <apmelton> sdake_: ok
16:30:40 <adrian_otto> I'm coing to paste a bunch form the agenda in here for archival purposes
16:30:44 <sdake_> I'll come up with a better title
16:30:44 <adrian_otto> *going
16:31:12 <adrian_otto> Everything in backlog can be moved to the Meetup
16:31:33 <adrian_otto> #topic Discuss adopting nova-docker as an in-tree Nova driver
16:31:43 <adrian_otto> #link http://lists.openstack.org/pipermail/openstack-dev/2015-May/063727.html ML Thread about in-tree nova-docker
16:31:52 <adrian_otto> Magnum plans to get all of its Nodes from Nova through Heat. Ideally, these would come from whatever virt-driver Nova has loaded. Over time, we should become more and more agnostic about what instance types Nova produces. One valid use case is running Magnum Bays on Nodes that were created using the nova-docker virt driver such that the Bay Nodes are actually containers, and when we run containers on the Bay, we
16:31:58 * dims pays attention
16:32:01 <adrian_otto> Note that use of nova-docker assumed that you use the Nova API to treat a (docker container) Nova instance as a machine, not as a container. All container specific features that reach beyond the scope of the Nova API should be implemented in Magnum, not Nova.
16:32:12 <adrian_otto> Note that nova-docker started within the Nova tree, and was pulled out into a Stackforge project so it could be worked on as a separate effort with a high commit velocity. It needed more test coverage, and additional features. Current commit velocity is low, and there are not a ton of bugs to deal with. Those were added, and now would be a good time to consider bringing it back into the Nova tree again. I think
16:32:23 <adrian_otto> Let's discuss the possibility of adopting nova-docker to maintain it within the Nova tree so that it does not fall into disrepair. Do we think this is something we would be willing to take on as part of the Magnum team responsibilities?
16:32:36 <adrian_otto> #link https://bugs.launchpad.net/nova-docker/ nova-docker bug list
16:32:41 <adrian_otto> As you can see, the bug list is mostly full of wishlist items for additional features. One approach might be to adopt this as maintainers, not as feature developers. In that case, we would commit to fixing defects, and reviewing new features, but that we would not necessarily allocate any resources into feature development. Thoughts?
16:32:52 <adrian_otto> (I will give you a moment to digest the quesiton)
16:33:27 <sdake_> docker-driver as part of magnum maintenance - not in agreement on this objective
16:33:29 <dims> i am already on the hook as a core on the stackforge nova-docker project. fyi.
16:33:40 <adrian_otto> Note that containers can come from libvirt-lxc virt driver today, which is in-tree
16:34:57 <dims> so johnthetubaguy, i'll be working/helping on nova-docker whether in-tree or in stackforge
16:35:01 <adrian_otto> I suppose the question reduces to how important does the Magnum team think nova-docker merging back into Nova is important, and what effort are we willing to volunteer to ensure that happens, if any?
16:35:03 <sdake_> I think we need to stay focused on the code bases we have (heat-co-templates, python-magnumclient, and magnum)
16:35:17 <adrian_otto> dims is already committed
16:35:27 <dims> sdake_: python-k8client
16:35:28 <dims> too
16:35:34 <apmelton> I think maintaining a nova driver clashes with magnum's goals quite a bit
16:35:40 <sdake_> dims we havet hat integrated in magnum but ya it should probably come out
16:35:42 <johnthetubaguy> so I am open to ideas here, its just I worry about a team of one on a driver
16:35:59 <johnthetubaguy> now I see containers in Nova being useful and important
16:36:08 <dims> johnthetubaguy: i hope to rustle up some folks at the summit
16:36:08 <johnthetubaguy> reasons covered well on the ML
16:36:24 <johnthetubaguy> and totally agree that magnum is where the container focused APIs go
16:36:30 <sdake_> I think it should remain part of nova not part of magnum
16:36:33 <sdake_> or separate
16:36:40 <sdake_> magnum has too much on plate atm
16:36:44 <sdake_> our dev team is only 40 strong ;)
16:36:46 <adrian_otto> sdake_: we agree on that
16:36:53 <johnthetubaguy> a nova driver lives in nova, thats cool
16:36:54 <sdake_> we need moreminerals to take this on
16:36:59 <dims> johnthetubaguy: ++
16:37:26 <johnthetubaguy> so if you can work with dims to get a community to own the driver and find it useful
16:37:37 <johnthetubaguy> they thats really cool
16:37:44 <johnthetubaguy> then thats really cool
16:37:50 <thomasem> Do we know how far along the nova-docker driver is wrt container nesting and general feature parity with the other drivers?
16:38:03 <dims> johnthetubaguy: i know some folks who are using it, they are just not on the ML actively
16:38:16 <adrian_otto> Solum uses it
16:38:23 <thomasem> oh okay
16:38:25 <adrian_otto> in the default deploy
16:38:42 <thomasem> What would be the value of the nova-docker driver over libvirt-lxc?
16:38:57 <adrian_otto> thomasem: great question…
16:38:59 <thomasem> which is already in-tree and supported
16:39:03 <johnthetubaguy> support for docker images?
16:39:09 <adrian_otto> the advantage is docker images
16:39:11 <dims> yep
16:39:21 <thomasem> the layered approach?
16:39:22 <dims> the entire docker eco system
16:39:22 <juggler> have the nova-docker folks identified which projects the bugs impacts? perhaps they might be able to wrangle volunteers through those who are interested in obtaining critical fixes?
16:39:35 <adrian_otto> which will reduce the friction needed to produce suitable instances for running a COE
16:40:07 <adrian_otto> that should be in our interest because if COE creation is convoluted, development there will not be as active
16:40:34 <sdake_> i am definately not in favor of implementing a template for COE of nova-docker
16:40:36 <adrian_otto> ideally we want the addition or adaptation of COE backends for bays to be easy
16:40:57 <johnthetubaguy> COE?
16:40:58 <adrian_otto> sdake_: okay, can you please explain your rationale?
16:40:59 <sdake_> we already have swarm which does the jobn nicely
16:41:01 <apmelton> sdake_: +1, I think that will diverge quite a bit from other templates
16:41:14 <sdake_> adrian_otto just explained ^^
16:41:15 <adrian_otto> COE == Container Execution Environment (Kubernetes, Swarm, Mesos, etc.)
16:41:24 <sdake_> COE = container orchestration environment
16:41:28 <apmelton> interacting with docker images is very different from interacting with nova instances
16:41:31 <juggler> +1 sdake
16:41:35 <apmelton> i.e. cloud init, ssh, etc...
16:41:50 <adrian_otto> yes, orchestration, that's what I meant.
16:41:57 <johnthetubaguy> cool
16:41:59 <johnthetubaguy> thanks
16:42:46 <adrian_otto> ok, so based on initial feedback, our team is not yet willing to expand scope to include the nova-docker virt driver
16:43:11 <adrian_otto> any opposing viewpoints to consider?
16:43:19 <johnthetubaguy> adrian_otto: thats cool, that feels like the right choice
16:43:27 <dims> totally agree
16:43:51 <adrian_otto> ok, and if our position changes, we are happy to revisit it
16:44:08 <adrian_otto> since there should be no rush
16:44:17 <juggler> agree, but as a sugg at the summit maybe bring up that nova-docker could use some assistance?
16:44:33 <dims> ++ juggler
16:44:53 <johnthetubaguy> well we need to be able to articulate where its really useful, and where people want to use it
16:45:32 <adrian_otto> most if my arguments for nova-docker can also be answered by libvirt-lxc
16:46:02 <adrian_otto> so as long as we have at least *some* answer to a nested container arrangement, I'll be satisfied
16:46:10 <diga_> adrian_otto: +1
16:46:19 <apmelton> at the moment, does the nova docker drive actually use the docker registry or do the iamges have to be hosted in glance?
16:46:23 <johnthetubaguy> right, libvirt-lxc is staying and maintained
16:46:26 <thomasem> Also the docker image still has to wind up in Glance, so...
16:46:30 <johnthetubaguy> what would docker do on top?
16:46:31 <dims> apmelton: glance
16:46:44 <adrian_otto> apmelton: is uses glance now, to my disappointment
16:46:51 <thomasem> Kind of undermines the point there, while using a swarm backend in Magnum still gets you the docker images
16:47:03 <adrian_otto> exactly
16:47:12 <adrian_otto> glad we discussed this. Thanks everyone for your input
16:47:23 <adrian_otto> let's spend a few minutes on task review now.
16:47:36 <adrian_otto> #topic Blueprint/Task Review
16:47:56 <adrian_otto> any work items anyone would like to raise for team discussion today?
16:48:19 <johnthetubaguy> adrian_otto: thanks for your time on that
16:48:22 <xek> I submitted a blueprint and would like to get a green light or maybe some comments https://blueprints.launchpad.net/magnum/+spec/versioned-objects-indirection-api
16:48:29 <adrian_otto> johnthetubaguy: thanks for joining us!
16:48:37 <juggler> thx john
16:48:48 * adrian_otto looks at versioned-objects-indirection-api
16:49:09 <dims> thanks johnthetubaguy
16:49:12 <adrian_otto> #link https://blueprints.launchpad.net/magnum/+spec/versioned-objects-indirection-api Versioned Objects Indirection API
16:50:00 <apmelton> very interesting xek
16:50:15 <adrian_otto> I have no objections to this xek
16:50:19 <adrian_otto> thoughts from others?
16:50:27 <thomasem> Didn't know about that
16:50:36 <adrian_otto> what's the T-Shirt size estimate for this?
16:50:48 <adrian_otto> sounds like an L or XL
16:50:49 <apmelton> I almost wonder how crazy it would be to implement our conductors as versioned objects
16:51:44 <xek> I plan to implement the object backporting first
16:52:11 <apmelton> rather, pulling most of our conductor logic into the versioned objects*
16:52:13 <xek> and figure out if this can go separate
16:52:32 <sdake_> zek lgtm
16:52:36 <adrian_otto> xek, is this something that's achievable in the Liberty release timeframe?
16:52:49 <diga_> :)
16:53:01 <xek> adrian_otto, I'm pretty sure it's achievable
16:53:25 <adrian_otto> and you (or a team you coordinate) is willing to contribute it?
16:54:02 <xek> adrian_otto, yes, my team is growing :)
16:54:12 <xek> adrian_otto, we are mainly interested in the ease of upgrades
16:54:24 <adrian_otto> Direction == Approved
16:54:29 <xek> adrian_otto, and making the upgrade process maintainable
16:54:40 <adrian_otto> you are welcome to submit a spec, or patches
16:54:58 <sdake_> zek we don't have a formal spec process so its not mandatory
16:55:01 <xek> adrian_otto, ok thanks!
16:55:02 <sdake_> pehraps after liberty
16:55:06 <adrian_otto> is there any more design work besides the proposal at https://wiki.openstack.org/wiki/ObjectProposal
16:55:55 <adrian_otto> that's complete enough for me
16:56:10 <adrian_otto> Definition == Approved
16:56:13 <adrian_otto> bring it.
16:56:35 <apmelton> it's getting pretty close to the end, but I wanted to get some eyes on https://blueprints.launchpad.net/magnum/+spec/async-container-operations
16:56:52 <adrian_otto> ok
16:57:35 <apmelton> I think this is pretty critical to magnum, considering one of the stated benefits we'd like to bring to the community was async container operations
16:57:50 <adrian_otto> Direction == Approved
16:58:03 <adrian_otto> let's revisit in in our next team meeting in 2 weeks
16:58:14 <adrian_otto> hopefully you have time to propose a design by then
16:58:15 <apmelton> sounds good, I'll have a more detailed plan after the summit anyways
16:58:20 <adrian_otto> #topic Open DIcsuttion
16:58:25 <diga_> apmelton: do you need help on this, please let me know
16:58:27 <adrian_otto> #topic Open Discussion
16:58:28 <juggler> please also take a few moments to complete a survey. your feedback is appreciated!: http://goo.gl/forms/W6ggrLiYFv
16:58:38 <juggler> (after the meeting)
16:58:41 <adrian_otto> thanks juggler!!
16:58:58 <adrian_otto> so our time is limited today, sorry about that
16:59:03 <juggler> you're welcome!
16:59:03 <apmelton> diga_: I appreciate it, it will likely have lots of pieces to work on
16:59:16 <adrian_otto> I look forward to seeing most of you in Vancouver next week
16:59:27 <sdake_> should send that to the ml
16:59:31 <diga_> apmelton: Sure
16:59:39 <sdake_> the survey
16:59:48 <adrian_otto> our next team meeting is Tuesday 2015-05-26 at 1600 UTC
16:59:59 <adrian_otto> thanks everyone for attending today!
17:00:05 <juggler> noted sdake!
17:00:12 <adrian_otto> #endmeeting