14:00:16 #startmeeting nova 14:00:16 Meeting started Thu Oct 6 14:00:16 2016 UTC and is due to finish in 60 minutes. The chair is mriedem. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:00:17 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:00:20 The meeting name has been set to 'nova' 14:00:26 o/ 14:00:28 \o 14:00:32 o.hai 14:00:33 o/ 14:00:33 o/ 14:00:34 \_@_/ 14:00:34 \o 14:00:36 o/ 14:00:39 \o 14:00:39 o 14:00:40 o/ 14:00:42 o/ 14:00:45 o/ 14:00:50 * kashyap waves 14:00:57 o/ 14:01:00 o/ 14:01:10 o/ 14:01:15 #link agenda https://wiki.openstack.org/wiki/Meetings/Nova 14:01:27 let's do this 14:01:31 #topic release news 14:01:41 #info newton release should happen today 14:01:53 #link Draft Ocata release schedule: https://wiki.openstack.org/wiki/Nova/Ocata_Release_Schedule 14:01:53 it's done http://lists.openstack.org/pipermail/openstack-announce/2016-October/001776.html 14:02:12 oh nice 14:02:21 o/ 14:02:27 well congratulations everyone 14:02:38 \o/ 14:02:39 yay 14:02:42 #topic summit planning 14:02:53 #link Nova Ocata design summit draft schedule: https://www.openstack.org/summit/barcelona-2016/summit-schedule/global-search?t=Nova%3A 14:03:11 we also have a 5pm nova/neutron session on wed in the neutron room 14:03:18 and jroll is asking about a 10pm nova/ironic session on wed 14:03:25 heh 14:03:26 more like 6pm 14:03:26 lol 14:03:47 i'm open to that if others can come too, specifically dansmith and jaypipes given it's placement related 14:03:54 yeah, I'm down 14:04:03 not with the timing, but I <3 jroll too much to miss it 14:04:04 so another option would be something like 11am friday, if you could spare some api/placement people, figure it doesn't overlap with libvirt too much 14:04:05 jroll is going to provide beer, right? 14:04:07 d'aww 14:04:09 sure 14:04:14 or sangria 14:04:35 jroll: dansmith will need to be in the libvirt session 14:04:44 so for context, the session is around allowing users to do advanced raid/partioning requests 14:04:52 or maybe putting that in flavors or something 14:05:00 jroll: I can probably make 11am Fri 14:05:32 if people are cool with 6pm wed I'm good with that 14:05:32 I will be more grumpy on friday 14:05:36 jroll: contributorse meetup maybe ? 14:05:46 dansmith: how would we be able to tell? 14:05:47 ooooh contributors* 14:05:50 bauzas: yeah that could work too 14:06:00 people are leaving friday afternoon 14:06:04 edleafe: I have a gauge.. it's kinda hidden.. remind me to show it to you 14:06:21 dansmith: eeek! Put that thing away! 14:06:23 O_O 14:06:27 ok, well we have some flexibility with our 11am slot on friday if needed 14:06:27 mriedem: that's a good question, I dunno who will stay 14:06:45 i.e. we could move that to 9am and slide up the cinder/docs sessions 14:06:52 but if 6pm on wed is ok for people then let's do that 14:06:54 o/ 14:07:02 mriedem: okay, I'll talk to ironic people, preferring 6pm wed > 11am fri > fri afternoon 14:07:09 cool 14:07:16 thanks! 14:07:29 ok, were there any questions about the design summit track layout? 14:07:37 no one screamed in the ML 14:07:46 mdbooth confirmed he's good with 11am on friday 14:08:02 so i'll assume people are generally in favor 14:08:09 mriedem: lgtm 14:08:19 oh i see cdent replied 14:08:21 mriedem: i made a last minute que 14:08:23 yeah, jinx 14:08:29 nothing bad, just curious 14:08:53 cdent: so there is a xp session on tuesday or wednesday on scaling review teams/decomposition, etc 14:09:03 which is more for the high level meta type discussions 14:09:07 mriedem: yeah, saw that too 14:09:23 we'll be doing a retrospective specifically on placement as we have actionable things there i think 14:09:23 I think it's both days at this point, yeah? 14:09:39 and we'll be doing sort of a mini retrospective in the libvirt imagebackend session on friday 14:09:39 like I said, 40 mins is short, and I'd like to get actionable items 14:09:42 Well, I hope we can transfer them elsewhere too, because everybody else needs action too. 14:10:04 i'm not sure what that means 14:10:15 there is plenty of work to go around 14:10:37 I have a question, when would be the best time to talk new contributor stuff? Friday? 14:10:45 probably 14:11:05 is there a slot for talking about security stuff w.r.t. nova? 14:11:13 auggy: what do you want to address ? I think we made a good progress last summit on the process 14:11:23 mriedem: I mean any actions we learn from retrospecting on placement can hopefully be applied across nova 14:11:25 dane-fichter: no, i don't think anyone proposed anything on that 14:11:49 dane-fichter: so by default that moves to friday meetup style 14:11:59 mriedem: when's a good time to talk new features? friday? 14:12:24 auggy: yeah we had a session on new contributors in austin, at this point i'd like to get feedback from new contributors before having another session on process changes 14:12:27 we need the loop 14:12:33 bauzas: I proposed a session + brainstorm etherpad with objectives 14:12:35 dane-fichter: unconference or friday meetup 14:12:50 mriedem: cool, thanks. 14:13:06 Right that's what I'm proposing, how to get feedback 14:13:08 keep in mind that unconference is time boxed to 4 10 min sessions 14:13:37 auggy: are you sure you'd get feedback from new contributors at the Summit ? I certainly doubt 14:13:53 auggy: i think friday meetup is fine for that, 14:13:55 auggy: I was more thinking of some dematerialized way to get feedback 14:14:02 you could even start that discussion in the ML if you have thoughts 14:14:13 ok i can go that route 14:14:15 mriedem: that's fine. just looking to cover some details of cert validation 14:14:26 yeah, the austin session was not a normal occurrence 14:14:44 and I don't really think we should do that again, especially considering the shortened schedule 14:14:44 bauzas: i wasn't expecting to get feedback from contributors, the session i proposed was about talking about what data we wanted to collect, etc 14:15:11 auggy: I think we can handle that asynchronously, esp. given the tight schedule in BCN :) 14:15:17 +1 14:15:20 works for me 14:15:34 like i said, you might want to start priming that pump in the ML before barcelona 14:15:59 it may also feed into the xp session 14:16:10 ok moving on 14:16:12 #topic bugs 14:16:27 we have 2 critical bugs this morning it looks like 14:16:28 https://bugs.launchpad.net/nova/+bugs?search=Search&field.importance=Critical&field.status=New&field.status=Incomplete&field.status=Confirmed&field.status=Triaged&field.status=In+Progress 14:16:57 garyk reported both of those against newton 14:17:49 mriedem: first one is permission denied on the filesystem 14:18:27 I think we was debugging that with mdbooth this morning 14:19:02 ok i've marked the first as incomplete given mdbooth's triage questions 14:19:08 and i've marked the 2nd as high, not critical 14:19:10 as it's in a periodic task 14:19:36 mdbooth: thanks for triaging those 14:19:47 mriedem: First looked like a config issue in the end. Not confirmed, but probable. 14:20:01 yeah 14:20:25 yeah, it *looks* 14:20:31 would be good to know if the latter one is a regression in newton, but we can check that later 14:20:57 ok moving on 14:21:01 gate status is not terrible 14:21:05 there are some bugs though 14:21:50 looks like the ceph one that was plaguing us has a fix merged now though and is dropping off https://review.openstack.org/#/c/377118/ 14:22:24 3rd party ci status, 14:22:36 virtuozzo storage ci should be fixed 14:22:49 i don't have anything to report on other 3rd party ci 14:23:22 sorry I'm late... 14:23:33 #topic reminders 14:23:40 (auggy): DocImpact tag reminder to reviewers! Changes with DocImpact tags create a bug; make sure there's a description of what documentation is needed! 14:23:47 * edleafe stops gossiping about jaypipes 14:23:57 yes that 14:24:10 basically when you use a docimpact tag, don't forget to provide some info 14:24:24 i'd also like to remind nova-specs cores that if you approve a spec, please remember to toggle the bp bits in launchpad, like mark it approved and target it for ocata 14:24:45 there were about 14 bugs in expired or new state last i'd checked (i've been working through them) 14:24:51 i'm trying to keep a daily track of how much throughput we have on bps 14:25:01 auggy: docs bugs? 14:25:12 yeah sorry, doc impact auto-bugs 14:25:42 if there's docinfo, i can mark as confirmed and often tag as low hanging fruit so others can pick up the work 14:25:46 anyways that's all i had on that :) 14:25:49 ok before i ask about bug skimming duty, 14:26:06 i wanted to ask if there are any newish contributors here that are even interested in helping out with bugs 14:26:12 because no one attended the bugs meeting this week 14:26:45 imo bug duty is a repo maintainers job, not a new contributors job 14:26:50 which is why it doesn't get a lot of traction 14:27:14 so let's move on 14:27:19 mriedem: I've been wanting to for months, but no cycles 14:27:26 that may be changing 14:27:38 I suspect "no cycles" is a common problem 14:27:42 also even if people just want to skim a bug here and there or do other bug queue maintenance in between things, it's a big help 14:27:47 cdent: is there something you want to tell jaypipes in public? 14:28:01 oh jaypipes knows, it's not like I'm quiet about it 14:28:34 auggy: yes i'm not trying to say triage isn't appreciated, there are always very simple invalid bugs that can be closed out 14:29:07 #topic Stable branch status: https://etherpad.openstack.org/p/stable-tracker 14:29:09 of course! didn't get that impression at all, just letting folks know they can help out with bug skimming without committing to it ;) 14:29:17 honestly, it's not really big deal to play with bugs 14:29:33 * mriedem thinks of a joke 14:29:36 you can commit only a few mins of your time or a whole day 14:29:55 yes it's helpful to spend 15 minutes each day looking at new bugs 14:30:01 just take one bug if you can't afford more, it'll still help 14:30:10 so onto stable 14:30:15 we released stable/liberty last week 14:30:17 i think 12.0.5 14:30:22 probably our last stable/liberty release 14:30:24 before EOL 14:30:25 * jaypipes gives cdent a bicycle. there, you now have more cycles. 14:30:34 \o/ 14:30:35 * mriedem does rimshot 14:30:46 i requested a stable/mitaka release last night 14:30:53 I hope it is shiny and red and comes with a big orange flag 14:31:04 mriedem: but all you got was that lousy master branch? 14:31:05 and we'll be doing a stable/newton release next week for bugs that didn't make the official release 14:31:16 cdent: but what color will the shed be? 14:31:42 edleafe: brown. 14:31:42 jaypipes: yeah, those bums 14:31:43 https://review.openstack.org/#/c/382695/ 14:31:47 mriedem: I know it's a question I always ask, but when do we plan to phase-II Mitaka ? 14:31:48 :) 14:32:03 bauzas: that's a better question for the stable team weekly meeting 14:32:12 i defer to tonyb 14:32:18 okay, I guess I can hold my breath until then :) 14:32:45 btw, thanks to those that did the mitaka review push last week 14:32:54 i saw the queue really drained, so thanks for that 14:33:02 i know who you are 14:33:07 ;) 14:33:21 #topic subteam highlights 14:33:27 let's blow through these 14:33:32 alaski: cells didn't have a meeting this week 14:33:33 right? 14:33:35 yep 14:33:40 * edleafe has mine queued up 14:33:42 edleafe: scheduler 14:33:43 go 14:33:45 We discussed work on traits API and final RequestSpec object tasks 14:33:45 We also tried to make the idea of pair development clearer to spread knowledge 14:33:48 Lots of confusion about required/optional placement DB in Ocata 14:33:50 Resolution was it will remain optional until placement engine is separated from Nova 14:33:53 that's it 14:34:48 ok 14:34:55 tdurakov: are you around? 14:35:05 pkoniszewski: ? 14:35:15 i wasn't around for the live migration meeting 14:36:04 one thing of news for live migration, 14:36:15 pkoniszewski got a job in the nova experimental queue that runs live migration + grenade multinode 14:36:29 so we can actually test live migration from newton to ocata and ocata to newton now 14:36:34 which is super sweet 14:36:44 there are changes up for review to toggle the back and forth that raj_singh helped with also 14:36:44 https://review.openstack.org/#/q/topic:lm-grenade 14:36:58 i'm around 14:37:04 pkoniszewski: just singing your praises 14:37:10 oh, thanks :D 14:37:17 yeah, we discussed ways to make progress and a config in tempest I think 14:37:31 thx pkoniszewski! 14:37:34 so yeah, i proposed a chain of patches to implement new config option 14:37:51 so that basing on a job type it will live migrate both ways or just one way 14:38:31 yup and the grenade multinode jobs will be the ones that test live migration both ways 14:38:39 exactly 14:38:45 so we don't burn cycles trying to live migration both ways to the same node 14:38:56 ok, let's move on 14:39:05 sdague: alex_xu: johnthetubaguy: api subteam meeting highlights? 14:39:22 we skipped it this week 14:39:31 ok 14:39:41 i know there are specs up for review 14:39:41 will discuss the plan for the summit session, and the security groups spec I have up next week 14:39:42 for the api 14:40:21 wznoinsk: lbeliveau: sriov/pci meeting? 14:40:23 i think that happened 14:40:25 yes 14:40:32 both tempests for cold migration and revert migration has been merged (works also for non-SRIOV) 14:40:36 mriedem: yes 14:40:44 we had some discussions around CI and blueprints, but nothing major to report 14:40:54 there is one outstanding commit left that fixes functionnality for cold migration revert 14:40:57 lbeliveau: i saw that tempest patch landed, that's cool 14:41:03 jaypipes: dansmith: if you can have a look at the new patch set that would be great https://review.openstack.org/#/c/349060/ 14:41:11 that's it :) 14:41:26 lbeliveau: so will ^ be tested/verified with the new tempest test? 14:41:58 via mellanox ci i mean 14:42:12 let me verify with moshele 14:42:21 ok 14:42:26 that would be good info in that change 14:42:55 gibi: notifications meeting highlights? 14:43:02 yes 14:43:04 just two things 14:43:10 about 10 notification transformation patches are up for review already 14:43:14 subteam reviewing the patches 14:43:15 mriedem: hi, sorry, was afk 14:43:20 and 14:43:25 [3;2~the tranformation work got a new automatic burndown chart and todo list 14:43:34 #link https://vntburndown-gibi.rhcloud.com/index.html 14:43:54 that is all 14:44:07 i saw that, nice 14:44:22 #topic stuck reviews 14:44:30 (peter-hamilton): Would like to discuss ways forward for https://review.openstack.org/#/c/357151/ . Related to: https://blueprints.launchpad.net/nova/+spec/nova-support-image-signing 14:44:47 should i summarize the spec or just jump right in? 14:44:53 i've asked danpb to join 14:44:59 mriedem: thanks! 14:45:14 lbeliveau: I've had that up in my todo list for a while now. will get to it today, promise. 14:45:14 danpb: hola 14:45:30 jaypipes: thanks ! 14:45:33 danpb: discussing https://review.openstack.org/#/c/357151/ 14:45:39 peter-hamilton: ok go ahead 14:45:59 ok, the spec's for improving signature verification by adding cert validation 14:46:20 mriedem: ok, pretty much as i said on the review - i don't think this proposal takes us in a direction we want to go 14:46:46 danpb: understood, alternatives have implications 14:46:54 its not even solving the stated problem in the spec 14:47:12 and building something that is of no use to us once we have the real solution 14:47:28 which gives us a maintenance burden we don't need 14:47:29 danpb: how is it not solving the problem 14:47:47 the problem is that the signing certs aren't validated. 14:48:02 the tenant user wants to boot an image and want guarantee that the image is signed by a cert that *they* trust 14:48:21 the solution is providing a way for cloud admin to list what certs the /host/ trusts 14:48:30 so that does nothing to help the tenant user 14:49:03 I'd argue that the tenant user has to trust the cloud admin already... 14:49:04 the cloud admin shoudln't even care about certs at all 14:49:16 i disagree 14:49:27 peter-hamilton: you have alternatives, right? 14:49:29 all the images are running inside VMs, so whether the image is signed or not is irrelevant to the cloud admin 14:49:35 dane-fichter: yes 14:49:45 let's discuss those 14:50:03 arguing over this trust model isn't going to progress this discussion imp 14:50:06 imo* 14:50:11 a service has to handle the tenant/user -> trusted cert mapping 14:50:23 which is not barbican i read 14:50:29 there are 3 options: nova, keystone, barbican/castellan 14:50:33 so a new service to manage certs? 14:50:39 * peter-hamilton shudders 14:50:44 that's a non-starter 14:50:53 have you talked to the keystone team about this? 14:51:03 we don't need anything to manage certs for an initial implementation 14:51:15 the boot API in nova could simply take the ID of a trusted cert 14:51:26 and the tenant can provide that when booting each VM 14:51:32 that would require the user to know the ID, seems very unreasonable 14:51:52 the ID of an individual cert that is 14:51:53 especially since the trusted image may not be uploaded by the end user 14:51:55 of course it would be useful to have a permanent record of the tenant/cert mapping but solving that's not a pre-requisite for doing useful cert validation in nova 14:52:25 danpb: understood 14:52:38 so you're proposing an API change in Nova? 14:53:12 i think that's desirable as the first step yes, as it avoids blocking the entire effort on creation of some cert managment service 14:53:18 the consensus we've received from cores in the past is that modifying the boot command to support image signing is a non-starter 14:53:26 while still proividing a very useful capability to nova 14:53:50 dane-fichter: i've certainly not said that before - i've suggested this approach in every cycle where this work has been proposed 14:53:56 danpb: I admire the simplicity of this from an implementation perspective 14:54:21 time check, we have 6 minutes 14:54:34 can we move this to the mailing list? sounds like something we will need to discuss at the summit 14:54:44 probably part of unconference and then bleed into friday meetup 14:54:45 yes, i was just going to suggest moving it to summit 14:55:00 danpb: yeah i'll be at the summit to discuss this 14:55:06 i'd like to have the alternatives fleshed out with pros/cons before the summit 14:55:07 let's wrap it up for now 14:55:09 so we don't have to play catchup 14:55:10 thanks 14:55:19 mriedem: will do 14:55:22 thanks 14:55:22 maybe fill out the alternatives section of the spec? 14:55:38 * bauzas needs to drop earlier \o 14:55:38 well, there might be a new spec 14:55:40 johnthetubaguy: we can expand it, there are several options listed already 14:55:43 johnthetubaguy: we'll flesh that out more too 14:55:45 or swap the main change and alternatives 14:55:56 #topic open discussion 14:55:56 yeah, all of those sound good 14:56:03 (mriedem): Start thinking about PTG attendance, February 20-2. Mon/Tues are cross-project, Wed-Fri are vertical team meetup-style. Mon and Fri would be 'optional'. 14:56:14 i got an email from the foundation asking if nova was going to be at the PTG 14:56:20 they have a survey, 14:56:24 i'm assuming some people will be there 14:56:29 i can't say i will be at this time 14:56:40 but i wanted to bring that up as an fyi 14:56:50 if you are sure you're going to the PTG please let me know in -nova 14:56:58 else i'll start a thread in the ML 14:57:06 open a thread 14:57:08 ok with 3 minutes left 14:57:11 (hferenc): Unifying image and flavor metadata (https://bugs.launchpad.net/nova/+bug/1582693 14:57:12 Launchpad bug 1582693 in OpenStack Compute (nova) "Image and flavor metadata for libvirt watchdog is handled erroneously" [Undecided,In progress] - Assigned to Richil Bhalerao (richil-bhalerao) 14:57:21 because some would engage discussions with management based on thart 14:57:30 bauzas: ok wil do 14:57:48 hferenc_: did you want to speak to that? ^ 14:57:54 hi 14:57:55 yes 14:57:59 so i came across this issue some time ago when i was trying to implement tests that used flavor extra specs 14:58:06 shortly, different modules/projects use extra specs formats inconsistently 14:58:11 flavor is ':' based, image is '_' while '_' is used for both in horizon 14:58:20 my question would be whether there is any ongoing work that aims to unify the extra specs formats? 14:58:26 or are there any plans to do this in the future? 14:58:38 PTG is the dev meetup at the marketing summit, right ? 14:58:42 fyi, melwitt recently went through something with this 14:58:45 I was hoping to straighten a lot of that out with the tags things related to placement 14:58:45 danpb: no 14:58:56 danpb: PTG is the midcycle replacement 14:59:09 I thought it was the design summit replacement 14:59:10 so much confusion on this 14:59:11 danpb: but at the beginning of the cycle now 14:59:26 danpb: marketing summit is now midway through the release 14:59:38 danpb: https://www.openstack.org/ptg/ 14:59:55 hferenc_: let's move this to #openstack-nova 14:59:56 we're out of time 14:59:57 mriedem: oh right, wrong way around 14:59:59 thanks everyone 15:00:01 #endmeeting