14:01:14 <johnthetubaguy> #startmeeting nova
14:01:15 <openstack> Meeting started Thu May 29 14:01:14 2014 UTC and is due to finish in 60 minutes.  The chair is johnthetubaguy. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:01:16 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:01:19 <openstack> The meeting name has been set to 'nova'
14:01:36 <mriedem> hi
14:01:39 <dansmith> o/
14:01:41 <PaulMurray> hi
14:01:44 <gibi> o/
14:01:44 <n0ano> o/
14:01:50 <johnthetubaguy> Hi, so mikal can't make it today, so you get me, sorry!
14:01:59 * mriedem leaves...
14:02:06 <johnthetubaguy> its very late/early where kangaroos live
14:02:15 <mriedem> some live in a zoo
14:02:18 <mriedem> in different TZs
14:02:37 <mriedem> there are agenda topics at least: https://wiki.openstack.org/wiki/Meetings/Nova
14:02:41 <johnthetubaguy> very true...
14:02:48 <johnthetubaguy> so.. I need to ping people
14:03:30 <johnthetubaguy> ok so none of the ping people are in this channel so lets skip that
14:03:34 <mriedem> is it just me or is it weird to see names listed for pinging at the top of the meeting but don't have agenda topics on the wiki?
14:03:46 <jaypipes> o/ (partly.. on phone too)
14:03:46 <johnthetubaguy> #topic Juno mid-cycle meetup date/location
14:03:50 <johnthetubaguy> we have some topics
14:03:50 <dims> o/
14:03:59 <johnthetubaguy> so we need to decide a date
14:04:03 <dansmith> mriedem: I think it's because some people don't have calendars, not because they have something to say
14:04:07 <johnthetubaguy> we have two options, so… lets vote
14:04:30 <johnthetubaguy> #link please vote on meetup date https://docs.google.com/forms/d/1ws6iezBwQHvvEP5_9lOI2MclJOLFi75XwbPfji4ea_M/viewform
14:04:46 <johnthetubaguy> so I think some people with strong opinions are moving house
14:04:52 <johnthetubaguy> so some dates fit better than others
14:04:58 <mriedem> ha
14:05:03 <johnthetubaguy> anyways, anything more people want to say about the meet up date?
14:05:14 <johnthetubaguy> just please vote, and lets see how it goes I guess
14:05:17 <mriedem> are the ironic guys doing the same dates as us?
14:05:27 <mriedem> or have they decided dates/locations?
14:05:40 <johnthetubaguy> good question, I don't remember...
14:05:46 <johnthetubaguy> I guess they get a big vote
14:05:50 <mriedem> devananda: ^?
14:05:50 <n0ano> mriedem, that's the plan, I'm getting a room for them
14:06:02 <johnthetubaguy> n0ano: OK cool, makes sense
14:06:08 <mriedem> n0ano: so ironic is just going to do whatever nova does?
14:06:10 <johnthetubaguy> I think I hurd two rooms next to each other
14:06:11 <dansmith> n0ano: which campus is this going to be at?
14:06:29 <johnthetubaguy> so we bug each other in some common sessions
14:06:36 <n0ano> dansmith, undetermined at this time, depend upon availability when we get exact dates.
14:06:42 <dansmith> n0ano: okay
14:07:04 <johnthetubaguy> cools
14:07:06 <dansmith> personally, I'm a little worried that a 100% overlap with ironic will turn the whole thing into an ironic meetup
14:07:11 <n0ano> idea is 3 room, ~40 for nova, ~20 for ironic and ~6 for individual breakout
14:07:36 <johnthetubaguy> dansmith: we will have to learn to ignore them a bit
14:07:45 <johnthetubaguy> but its a good point, need to avoid that
14:07:47 <n0ano> dansmith, separate but equal, should be OK
14:07:54 <johnthetubaguy> OK, any more on this...?
14:08:17 <johnthetubaguy> #topic Blueprints
14:08:35 <johnthetubaguy> cools, so the next think is really about Juno-1, its about 2 weeks away
14:09:05 <johnthetubaguy> so… I have been trimming the juno-1 blueprint list (a little bit)
14:09:33 <johnthetubaguy> so I am trying to keep all things in this list to have approved specs:
14:09:35 <johnthetubaguy> https://blueprints.launchpad.net/nova/juno
14:09:48 <johnthetubaguy> but this is juno-1
14:09:52 <johnthetubaguy> #link https://launchpad.net/nova/+milestone/juno-1
14:10:16 <johnthetubaguy> #action can people please update their blueprint status and check their milestones
14:10:52 <johnthetubaguy> and we should probably start pushing hard on reviewing what is ready for review to close that out
14:11:21 <johnthetubaguy> so question… do people want to think about a juno-1 blueprint proposal freeze? was that useful before?
14:11:39 <dansmith> I do, just because I think we need to focus on reviewing *code* at some point
14:12:02 <johnthetubaguy> dansmith: +1
14:12:10 <PhilD> +1 to the BP freeze
14:12:17 <johnthetubaguy> I don't like extra process, but this one seemed useful
14:12:46 <johnthetubaguy> so I guess I should give people a week to get their code up, and blueprint moved to "Needs Code Review" before we bump them to J-2
14:12:48 <danpb> dansmith: yes, it does seem like we've spent alot of time reviewing blueprints and not so much reviewing code
14:12:58 <dansmith> danpb: yeah :(
14:13:00 <johnthetubaguy> danpb: good point
14:13:08 <danpb> of course that's not neccessarily a bad thing
14:13:17 <danpb> since it should mean the code we eventually review will be less insane
14:13:43 <PhilD> Reviewing the BPs should reduce some the churn in the code review though
14:13:46 <johnthetubaguy> OK… so maybe we should stop blueprint view focus today ish? and let the freeze focus people on getting the code up for review?
14:14:13 <johnthetubaguy> (not that we had a focus, except for it being a new shiney thing)
14:14:18 <PhilD> We can carry on with BP reviews - but any that get approved from here on will go into J-2 or beyond
14:14:48 <danpb> yep, and if choosing between the two, the priority should be on reviewing actual J-1 code
14:14:52 <johnthetubaguy> PhilD: yeah, I suppose, just think we should "foucs" on blueprint code reviews for the next little while
14:14:57 <johnthetubaguy> danpb: +1
14:15:18 <johnthetubaguy> PhilD: but I agree, no block on blueprint approvals for later milestones
14:15:29 <johnthetubaguy> everyone happy with that?
14:15:42 <dansmith> if we're not frozen,
14:15:58 <dansmith> we'll still get pings about reviewing specs all day and night
14:16:12 <johnthetubaguy> dansmith: hmm, thats a good point...
14:16:13 <dansmith> which we can ignore, of course, but having a line in the sand helps explain things, IMHO
14:16:33 <johnthetubaguy> PhilD: you OK with us not approving any blueprints for two weeks?
14:16:45 <PhilD> Just don't want to switch off BP review al toghter - otherwise we we'll won't have BPs ready to go into J-2
14:17:13 <gibi> I tend to agree with PhilD that we need some BP to be ready for J-2
14:18:00 <johnthetubaguy> yeah… but there are lots of stuff from J-1 that will fill up J-2, if we are being honest with ourselves
14:18:09 <dansmith> ...right.
14:18:22 <danpb> and i tend to expect that people are writing their code regardless of whether the BP is approved
14:18:38 <dansmith> well, we're not supposed to be approving the actual BP unless they do
14:18:41 <danpb> so not approving the BP probably won't actually delay people significantly
14:18:43 <dansmith> (the launchpad part)
14:19:05 <PhilD> Maybe we just need to work out what the balance is here - so that we have a sustainable approach going forwards.  Boom and Bust on either isn't good
14:19:20 <gibi> PhilD: +1
14:19:21 <dansmith> I don't feel like we're on either side of the extreme here,
14:19:31 <dansmith> we have a bunch of things in the queue that have gotten some review, but not approved
14:19:38 <johnthetubaguy> PhilD: agreed we do, but right now we don't have the bandwidth, so this seems like a pragmatic choice
14:19:44 <johnthetubaguy> so...
14:19:44 <dansmith> that seems like a plenty fine situation going into J2
14:20:05 <danpb> yep, we're saying carry on reviewing BPs but don't make it your top priority job for the day - reviewing code should be the top job, and BP #2 job
14:20:07 <johnthetubaguy> maybe lets say no more spec approves monday onwards?
14:20:25 <johnthetubaguy> danpb: yeah, the soft freeze is probably easier
14:20:39 <dansmith> nobody is going to turn off the +2 button on reviews anyway :)
14:20:47 <johnthetubaguy> dansmith: true
14:20:56 <PhilD> Just want to be clear - are we saying what is already apporved fills up through Juno ?
14:21:19 <johnthetubaguy> PhilD: well day after Juno-2 we start approving more though
14:21:34 <johnthetubaguy> its only for the few weeks to get Juno-1 pushed out I think
14:21:51 <PhilD> Ok, that sounds reasonable.
14:21:51 <danpb> yep, once J-1 is done, we can approve as much as we want again
14:21:57 <johnthetubaguy> cools
14:22:09 <johnthetubaguy> sounds like we kinda have agreement.. lets summarize
14:22:19 <gibi> Ok
14:22:23 <johnthetubaguy> avoid spec reviews, till we ship Juno-1
14:22:35 <johnthetubaguy> focus on needs code review blueprints, getting them to complete
14:22:51 <johnthetubaguy> sounds cool?
14:23:00 <PhilD> Woudl help if at somepoint we had a way to assign a priority to BPS after they get approved - to help prioriise teh reviews and allow new (urgnet) ideas to come though.  Sometimes the most important BPS are teh most complex to review,
14:23:23 <PhilD> and I wan't to avoid that we only get the simple changes into each milestone
14:23:28 <johnthetubaguy> PhilD: yeah, the priority needs work...
14:23:43 <johnthetubaguy> so I have some ideas I am working on...
14:24:02 <johnthetubaguy> (assuming we are agreed on the blueprint push for Juno-1 speak up if you are not happy with that)
14:24:19 <johnthetubaguy> talking to the user committee to get their priority list
14:24:22 <johnthetubaguy> second...
14:24:34 <johnthetubaguy> working out the dependencies on "structural" changes we agreed at the summit
14:24:36 <johnthetubaguy> …so
14:24:44 <johnthetubaguy> we say objects are super high priority
14:24:49 <johnthetubaguy> as is scheduler split, etc
14:24:53 <johnthetubaguy> as it blocks other stuff
14:25:11 <johnthetubaguy> … but I need to try and formalize that, so I can present a more… concrete idea
14:25:27 <johnthetubaguy> ideas and help very welcome there
14:25:55 <johnthetubaguy> …OK so we should go back to the list of blueprints
14:26:19 <johnthetubaguy> what stuff do we REALLY need...
14:26:27 <johnthetubaguy> where do we need to tweak priorities
14:26:34 <johnthetubaguy> https://launchpad.net/nova/+milestone/juno-1
14:27:06 <johnthetubaguy> seems like most of the high priority ones are getting somewhere, but need the last push
14:27:18 <johnthetubaguy> any vmware folks about?
14:27:41 <mriedem> there are just a couple patches left on the vmware refactor phase 1/2 stuff
14:27:43 <mriedem> 3 last i checked
14:28:04 <johnthetubaguy> cool
14:28:10 <mriedem> phase 3 was oslo.vmware integratoin i think, vui lam was working on that i think
14:28:21 <johnthetubaguy> alaski: your stuff is close now right?
14:28:27 <johnthetubaguy> alaski: is it all up for review now?
14:28:39 <johnthetubaguy> #link https://blueprints.launchpad.net/nova/+spec/remove-cast-to-schedule-run-instance
14:28:47 <PhilD> extensible-resource-tracker is neesed for a whole bunch of other BPs under review that want to add data to the compute_node
14:28:53 <alaski> johnthetubaguy: the final important piece is up for review, and very close I think
14:29:06 <dansmith> I just +Warthog'd it
14:29:18 <johnthetubaguy> cool
14:29:19 <alaski> johnthetubaguy: then there are some cleanup patches after that are up for review but haven't received much attention yet, which is fine
14:29:25 <johnthetubaguy> alaski: np
14:29:44 <johnthetubaguy> PhilD: yes, good point, thats the structural stuff I guess, needed to help scheduler split
14:30:17 <PhilD> ... and we have been talking about this for ages
14:30:20 <johnthetubaguy> I guess we could make that high, but medium is still "tracked", so maybe that enough at this point
14:30:25 <johnthetubaguy> PhilD: very true
14:30:48 <dansmith> I don't think it's high
14:31:02 <jaypipes> I'm pretty -1 on the xtensible resource tracker implementation at this point...
14:31:04 <johnthetubaguy> OK… any more worries on the J-1 plan, and mostly any bad priorities people can spot
14:31:16 <dansmith> I really think we need to use our priorities to reflect what we think is important/critical and not "what has been waiting for a while"
14:31:56 <johnthetubaguy> dansmith: yes, technically, it has to be "likely hood to merge" but we need the important stuff to be likely to merge
14:32:15 * johnthetubaguy hopes that made sense to someone
14:32:28 <PhilD> Sure - but importance shoudl reflect what else it holds up as well as the change itself
14:32:32 <johnthetubaguy> dansmith: anywhere you feel we have got it wrong?
14:32:50 <dansmith> johnthetubaguy: I was just referring to the extensible resource tracker stuff being high priority
14:33:15 <dansmith> I waffle between -0 and -2 on that, so I can't really imagine it being high priority
14:33:15 <johnthetubaguy> dansmith: right, medium seems OK at this point, its a soft dependency on the major work, I think
14:33:24 <PhilD> From my perspective its high
14:33:32 <dansmith> what major work does it block?
14:33:35 <dansmith> scheduler stuff?
14:34:05 <johnthetubaguy> PhilD: well, don't not merge + high priority = medium chance to merge maybe
14:34:26 <PaulMurray> dansmith, extensible RT it is waiting for approval
14:34:32 <PhilD> Pretty much all of the other scheduler stuff that other people want to bring in later in J
14:34:38 <johnthetubaguy> … lets just park this till open discussion?
14:35:21 <johnthetubaguy> PhilD: its just the best way, not the only way, but I do like it myself, but lets sort that later
14:35:32 <johnthetubaguy> any other blueprints we have worries about, in terms of priority
14:35:38 <johnthetubaguy> any crucial stuff we missed
14:36:00 <johnthetubaguy> not that we are doing spec reviews for a bit, quick reminder about...
14:36:02 <johnthetubaguy> #link https://etherpad.openstack.org/p/juno-nova-summit-specs
14:36:16 <johnthetubaguy> do add stuff agreed at the summit that we need to do paper work for
14:36:25 <johnthetubaguy> although thats a J-2 thing now
14:36:53 <PhilD> There are only 4 Bps approved for J-1 that are in the state of needs code review doesn't that sort of set the priority in terms of what can be done anyway ?
14:37:43 <johnthetubaguy> PhilD: a little, yes, but most people don't update the blueprint status, I will start pinging people and chasing up on that
14:37:55 <PhilD> OK
14:38:00 <johnthetubaguy> not sure everyone knows Juno-1 is so soon, hopefully my email about the freeze sorts that out
14:38:13 <johnthetubaguy> (and massive blueprint commenting…)
14:38:35 <johnthetubaguy> OK, any more on blueprints?
14:39:07 <johnthetubaguy> OK
14:39:32 <johnthetubaguy> sounds like we have a plan about the freeze
14:39:55 <johnthetubaguy> #action johnthetubaguy to sort out an email about blueprint proposal freeze, and spec review slow down for juno-1
14:40:02 <johnthetubaguy> #topic Bugs
14:40:18 <johnthetubaguy> now, I don't have anything about the top bug list...
14:40:34 <johnthetubaguy> there is a plan to get the top few "burning" bugs from the bug team each week
14:40:47 <johnthetubaguy> and a general hope we get better at managing the massive backlog
14:41:02 <johnthetubaguy> but anyone got bugs or bug process things they want to talk about?
14:41:32 <johnthetubaguy> https://bugs.launchpad.net/nova/+bug/1299517
14:41:37 <johnthetubaguy> I think is what was mentioned
14:42:10 <PhilD> That was the one that sprang to my mind.
14:42:27 <johnthetubaguy> #info Bug Day on next Wedesday 4th June
14:42:36 <johnthetubaguy> I think that was the ml post
14:42:41 <johnthetubaguy> http://osdir.com/ml/openstack-dev/2014-05/msg02075.html
14:42:42 <PhilD> Feels like we goofed a bit here and broke our API compatibility rules
14:42:56 <PhilD> So can we just revert that set of changes for now ?
14:43:05 <dansmith> I think we should
14:43:29 <johnthetubaguy> yeah… makes sense
14:43:35 <alaski> +1
14:43:36 <johnthetubaguy> any one want to take that one?
14:43:42 <dansmith> too bad the horizon folks didn't mention it,
14:43:46 <dansmith> as they had to remove something as a result
14:43:55 <PhilD> There was talk of a "partial" revert so that only defaults can be set - but I think that could come as a separate change
14:43:56 <danpb> yep, seems the claim "It turns out os-quota-classes-sets never worked.... Since this doesn't work no need to keep it around."  was not quite correct :-)
14:44:20 <mriedem> i can post the revert for stable/icehouse of the api removal for v2
14:44:26 <johnthetubaguy> do we have a tempest test on the way?
14:44:26 <mriedem> easy enough
14:44:28 <dansmith> I thought vishy was going to do it, so maybe we should wait and let him do it now that we agree
14:44:32 <dansmith> or that
14:44:33 <johnthetubaguy> mriedem: awesome thank you
14:44:57 <johnthetubaguy> #action mriedem to take on lp 1299517
14:45:02 <mriedem> vishy can do the revert of the master branch if he wants
14:45:08 <johnthetubaguy> mriedem: you ok to check with vishy about the test?
14:45:25 <mriedem> sure, i don't know what test we're talking about, but i can bug him :)
14:45:26 <dansmith> mriedem: should go to master first anyway
14:45:27 <johnthetubaguy> mriedem: or get him to do the bug fix too :)
14:45:32 <dansmith> mriedem: we need a test :)
14:45:43 <mriedem> test our APIs?!
14:45:51 <johnthetubaguy> crazy talk … I know
14:46:02 <PhilD> as in "we need a test as well as the revert" - or we need a test first ?
14:46:16 <dansmith> we need a test post-revert to prevent it from breaking again
14:46:17 <johnthetubaguy> erm, test how it should be after the revert
14:46:20 <danpb> do a plain revert, and then add a test
14:46:22 <mriedem> well test would go on master, and there is a series on master that needs to be reverted
14:46:23 <johnthetubaguy> dansmith: +1
14:46:38 <mriedem> i'm going to revert the api removal on stable
14:46:42 <mriedem> since that's the immediate problem
14:47:00 <johnthetubaguy> mriedem: master first surely?
14:47:01 <mriedem> if vishy wants to take over from there on master, i'm fine with that
14:47:05 <dansmith> mriedem: but you really should cherry-pick the master one
14:47:11 <johnthetubaguy> dansmith: +1
14:47:17 <johnthetubaguy> else the world turns upside down
14:47:25 <dansmith> mriedem: that's how this is supposed to go.. fix in master, cherry-pick to stable when it's merged
14:47:25 <PhilD> Master first and cherry pick to stable
14:47:50 <mriedem> i'll get it all worked out
14:47:55 <mriedem> don't worry
14:48:02 <johnthetubaguy> mriedem: sorry, don't mean to be picking on you, particularly given you are the kind person who offered to fix it :)
14:48:04 <mriedem> what could go wrong?!
14:48:09 <johnthetubaguy> :)
14:48:39 <johnthetubaguy> so… any more bugs?
14:48:53 <johnthetubaguy> bug day will be fun, read the ML for more details I guess
14:49:25 <johnthetubaguy> #topic Sub Team reports
14:49:34 <adrian_otto> Containers Subteam Update
14:49:41 <johnthetubaguy> any takers?
14:49:46 * n0ano gantt
14:49:50 <adrian_otto> #idea attend https://wiki.openstack.org/wiki/Meetings/Containers on Tue at 2200 to discuss options for where containers specific funcitonality should be implemented in OpenStack.
14:49:50 * johnthetubaguy raises his XenAPI hand
14:49:56 <johnthetubaguy> adrian_otto: fire away
14:50:01 <adrian_otto> tx!
14:50:10 <adrian_otto> Various options will be debated.
14:50:17 * danpb Libvirt
14:50:30 <adrian_otto> In our last meeting we concluded that there were sufficient use cases for containers that did not require Cinder support to disregard that as an acceptance criteria for inclusion in Nova.
14:50:37 <adrian_otto> #link http://eavesdrop.openstack.org/meetings/containers/2014/containers.2014-05-27-16.02.log.html#l-120 Cinder with Containers Discussion
14:50:43 <adrian_otto> That's it for our update. I can take any questions.
14:51:08 <johnthetubaguy> I guess the question is… do the people in this Nova meeting agree?
14:51:15 <dansmith> yeah, that's my question :)
14:51:28 <adrian_otto> or if there is disagreement, we can field that on Tuesday
14:51:30 <danpb> FYI see https://etherpad.openstack.org/p/containers  line 135 onwards for examples
14:51:56 <adrian_otto> tx danpb
14:52:04 <danpb> basically the core observation is that there are genuine use cases for completely stateless instances, and many use cases where the state is accessed over the network (eg remote database or whatever)
14:52:04 <PhilD> Does not supporting cinder mean that a system using containers won't pass the DevRef standard ?
14:52:21 <johnthetubaguy> well not sure we have time for that debate here… lets add that on the open discussion queue
14:52:40 <adrian_otto> ok
14:52:49 <danpb> PhilD: IMHO that would indicate DevRef is flawed
14:52:49 <johnthetubaguy> and if you really care about it, try send info to the contianer meeting somehow
14:53:05 <johnthetubaguy> yeah, DevRef may have to morph
14:53:15 <adrian_otto> I'd be happy to proxy any questions arguments if you are unable to attend
14:53:23 <adrian_otto> we will have an ML thread to
14:53:33 <johnthetubaguy> but anyways… feels to me like not being able to add extra storage is bad, but yeah, lets take that offline
14:53:53 <johnthetubaguy> n0ano: your turn I think/hope
14:53:57 <n0ano> NP
14:54:12 <n0ano> Two major items this week, no-db scheduler and the forklift effort
14:54:40 <n0ano> nodb cause a lot of discussion, there are some major concerns with the current design, everyone should read:
14:54:44 <n0ano> #link https://review.openstack.org/#/c/92128/2/specs/juno/no-db-scheduler.rst
14:55:01 <n0ano> we're going to try to go over that at the meeting next tues.
14:55:13 * johnthetubaguy will try to attend this time
14:55:30 <johnthetubaguy> hows forklift going, there are patches to review I guess?
14:55:41 <n0ano> for the forklift, we have some concrete BPs and code out that need to be reviewed, they are to clean up the interfaces between nova and the scheduler
14:56:00 <n0ano> here's the 3 links:
14:56:04 <n0ano> #link https://review.openstack.org/82133 (scheduler-lib validated)
14:56:06 <johnthetubaguy> forklift = spliting out scheduler into gnatt
14:56:11 <n0ano> #link https://review.openstack.org/89893 (isolate-sched-db review in progress)
14:56:17 <n0ano> #link https://review.openstack.org/94916 (prep_resize to move to conductor - review in progress)
14:56:21 <n0ano> johnthetubaguy, +1
14:56:36 <johnthetubaguy> cool, sounds good, progress
14:56:49 <n0ano> that's about all for now, expect firworks next tues :-)
14:56:57 <johnthetubaguy> heh
14:57:07 <johnthetubaguy> so XenAPI update...
14:57:25 <johnthetubaguy> I am at the Xen hackathon, mostly talking but its a nice day out
14:57:41 <johnthetubaguy> hopefuly rackspace are taking on more active role with XenServer CI
14:57:48 <johnthetubaguy> had an outage, but its back now
14:57:51 <johnthetubaguy> that is all
14:58:10 <johnthetubaguy> danpb: your turn
14:58:17 <danpb> Libvirt update
14:58:38 <danpb> groups of folks from   B1 systems, Citrix and SUSE to investigate CI options for Libvirt + Xen
14:58:57 <danpb> they will report back when there is interesting progress to tell the group
14:59:06 <johnthetubaguy> cool
14:59:25 * johnthetubaguy feels silly chatting to danp via IRC when he is sat next to me
14:59:28 <danpb> related to this there is someone at Rackspace investigating CI for Libvirt + LXC
14:59:43 <johnthetubaguy> yes, I can confirm LXC rumers
14:59:55 <johnthetubaguy> I think its a bit delayed, and canonical are helping too I think
15:00:10 <dansmith> (note time)
15:00:25 * johnthetubaguy looks at watch
15:00:33 <johnthetubaguy> #topic Open Discussion
15:00:35 <danpb> In general, there is quite a bit of activity around Libvirt + LXC and the issues we're identifying about missing APIs in Nova overlap with Docker, so we're engaged with Containers team
15:00:52 <johnthetubaguy> cool, sorry to cut you short
15:01:01 <danpb> nothing more to report (see logs at https://wiki.openstack.org/wiki/Meetings/Libvirt)
15:01:10 <johnthetubaguy> so… thanks all for putting up with me
15:01:19 <johnthetubaguy> feedback welcome
15:01:29 <johnthetubaguy> lets push for Juno-1
15:01:35 <johnthetubaguy> #endmeeting