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