21:01:15 #startmeeting nova 21:01:15 o/ 21:01:16 Meeting started Thu Apr 9 21:01:15 2015 UTC and is due to finish in 60 minutes. The chair is mikal. Information about MeetBot at http://wiki.debian.org/MeetBot. 21:01:17 Hey all 21:01:18 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 21:01:20 The meeting name has been set to 'nova' 21:01:22 o/ 21:01:24 \o even 21:01:25 o/ 21:01:28 Greetings earth humans 21:01:32 o/ 21:01:52 I've decided that a power trip is as good as a holiday, so there's only one agenda item for the meeting today 21:02:00 RC1 21:02:16 I went to bed with there being a bunch of bugs open, but it looks like all but one got closed over night 21:02:19 So thanks for that 21:02:29 o/ 21:02:31 dansmith: want to talk about the RPC version patch as the only remaining rc1 bug? 21:02:44 yeah we filtered some of them 21:02:49 #link https://review.openstack.org/#/c/172152/4 21:02:56 mikal: sure, but what is there to say? 40 revisions down the tube, we should do it :) 21:03:08 haven't done it since havana 21:03:10 +1 21:03:14 There's some talk about CI fail? We don't think its related to that patch? 21:03:20 mikal: it's not 21:03:34 this patch passed CI an hour ago 21:03:42 grenade is hosed, bug 1442367 21:03:43 bug 1442367 in python-neutronclient "2.4.0 release destroys grenade since stable/juno isn't capped properly" [Critical,Confirmed] https://launchpad.net/bugs/1442367 21:03:43 Ok, so if another core wants to +2 +W that patch, then I think that means we're ok for rc1? 21:03:59 we should be careful about reviewing hte change 21:04:06 mriedem: agreed 21:04:16 i noticed someone slapped a +2 on there quick :) 21:04:23 I read it! 21:04:27 riiiiight 21:04:30 Heh 21:04:41 alaski: and we're passing cells now, so we should be good as soon as grenade gets unfscked 21:04:44 Anyways, the release process is that once everythign is merged I give a git sha to release to ttx 21:05:03 dansmith: excellent. +2 from me then. once tests show up 21:05:04 So, we need to stop merging random stuff (not that I think we are at the moment) 21:05:06 o/ 21:05:08 Then get this thing merged 21:05:10 dansmith: mmm, are we passing cells ? o_O 21:05:12 Note the sha, and email ttx 21:05:25 bauzas: the devstack job that we failed earlier 21:06:04 So, any questions about that? 21:06:05 bauzas: the "other" cells job 21:06:12 melwitt: right 21:06:15 dansmith: oh right 21:06:18 melwitt: the easy one 21:06:22 melwitt: thanks, not the tempest one 21:06:26 :) 21:06:58 I'm going say that's no questions then... 21:07:19 IIRC Liberty opens once infra has cut a branch, so there's a brief pause while that happens and then you can have at it again 21:07:24 So... 21:07:28 #topic Open Discussion 21:07:36 Anything else we need to cover? 21:07:39 yea 21:07:42 xenserver ci 21:07:43 busted 21:07:46 I'd like to remain super focussed on RC1 for today if possible 21:08:00 mriedem: how long as that been the case? 21:08:04 there are a lot of discussions about the microversions on novaclient and people cannot reach an agreement 21:08:05 over 24 hours 21:08:14 mikal: like -1 on everything 21:08:16 claudiub: please hold for a sec 21:08:24 and bob ball hasn't been around 21:08:24 mriedem: have we disabled the CI account yet? 21:08:28 mriedem: due to a network issue AFAIK 21:08:28 no, 21:08:35 should at least be non-voting 21:08:47 bauzas: i hadn't heard specific 21:08:49 *s 21:08:51 Ok, infra can help with that, but we should request it via an openstack-dev mailing list post 21:08:59 mriedem: do you want to do that given you have the details? 21:09:01 mriedem: we just need to ask them to turn it off right? 21:09:05 sure 21:09:24 mriedem: that's a specific test which is failing AFAIK 21:09:27 dansmith: yeah, the reason for the paper trail is that infra will require the PTL to approve turning it back on again 21:09:38 mikal: sure 21:10:02 bauzas: so you're saying its not broken, just one test? 21:10:07 bauzas: or are there two issues? 21:11:32 mikal: it was one test on the last checks I did 21:11:44 mikal: but it needs to be doublechecked for sure 21:12:09 and logstash can't help me :) 21:12:13 Ok, sounds like mriedem is going to chase it down and send an email? 21:12:18 mriedem: I tricked you into that, right? 21:12:23 not a trick 21:12:26 it's call delegation 21:12:26 VMware NSX CI seems to be down as well 21:12:34 Sigh 21:12:41 http://208.91.1.172/logs/168820/2/1428246278/testr_results.html.gz 21:12:50 checking.... 21:12:53 but vmware isn't voting 21:12:54 is it? 21:13:15 I thought it was 21:13:25 it looks like they know since it hasn't run on nova since yesterday 21:13:25 i thought it was too 21:13:33 ok 21:13:49 well, xen has been going nuts on a lot of changes for over 24 hours 21:13:57 emai lsent 21:13:58 our guy is on it - just came back from sweden 21:14:11 full of delicious chocolate 21:14:13 tjones1: any bugs in nova we should get in for Kilo? 21:14:24 no we are good 21:14:31 just wish list so too late 21:14:34 jogo: I think its too late anyways, give rc1 is "due" today 21:14:40 yep 21:14:42 given even 21:14:44 good 21:14:49 :-) 21:14:51 Ok, so claudiub has been patient 21:14:54 claudiub: talk to us 21:15:28 mikal: no problem. :) so, there has been a lot of disscussions about the novaclient microversions : https://etherpad.openstack.org/p/novaclient_microversions_design 21:16:02 and andreykurilin is working on this, but there hasn't been a lot of agreement on the implementation 21:16:21 clarkb: mikal told me to do it, i swear! 21:16:38 my question is do you want no comments at all or just no -1s? 21:16:45 no -1's is something nova has control over 21:16:47 mikal: i've lost track of the commits, since there were a lot of them and there are abbandoned commits 21:17:08 clarkb: hang ten a sec please 21:18:04 Do we think this is complex enough to write a spec? I know we don't do those for client changes, but it might help move this discussion forwards. 21:18:42 this is about the service catalog endpoint names that the current proposal wants to hardcode as "computev21" for example and make that a default 21:19:19 so, the issue was that if a user requests a certain microversion, it should use the v3 endpoint 21:19:42 everythin will be the same endpoint soon, right? 21:19:44 v2 will go away 21:19:48 v2.1 will become v2 21:19:51 and v3 will be gone, yes? 21:20:02 Yeah, I also thought those endpoint names were configurable by the deployer? 21:20:08 that too, 21:20:16 but I mean, we will only have one to configure anyway very soonb 21:20:19 regardless of what you call it 21:20:26 it will be what is currently v2.1 21:20:34 IIUC, v2.1 == v2 nope ? 21:20:35 exactly. that's why I don't want novaclient using non-standard endpoint names other than "compute" "volume" etc 21:20:51 I think that's right 21:20:53 melwitt: that sounds fair to me 21:21:17 users can anyway pass the endpoint name they want using --service-type "computev21" if their deployer has set up such an endpoint in their catalog 21:21:28 * dansmith nods 21:21:37 agreed 21:22:19 it is true, but it is a bit overkill to use --service-type and --os-compute-api-version 21:22:32 claudiub: you can set env vars 21:22:37 OS_SERVICE_TYPE 21:22:41 claudiub: that's only for the case where a user wants a specific microversion, right? 21:22:42 well the point is, we don't expect anyone will override it 21:22:43 very soon 21:22:54 mikal: yes 21:23:01 mikal: hmm? what does this have to do with a specific microversion? 21:23:02 claudiub: why would anyone want a specific microversion? 21:23:07 that's what's also confusing about novaclient IMO, is the service-type == keystone catalog endpoint name and compute-api-version == client object class 21:23:28 mikal: for example, to use certain features. v2.2 offers x509 keypairs 21:23:40 dansmith: the etherpad claudiub linked to talks about the client wanting to request a specific microversion and how to configure that 21:23:55 we do that in a header provided by the client, right? 21:24:03 using an endpoint for that is wrong, no? 21:24:04 dansmith: yes 21:24:26 And I guess I had assumed that novaclient would always ask for the latest version 21:24:35 mikal: the microversion is included in header, but if the endpoint is 'compute', it will go to the contrib modules 21:24:36 dansmith: I think the question is how to influence that header from the cli 21:24:39 Unless the endpoint it was talking to didn't do microversions at all 21:24:40 aka v2.0 21:24:50 alaski: I see 21:25:07 I figured novaclient would always support the latest, by version number 21:25:08 claudiub: v2.0 will be going away in L though 21:25:15 and fall back to 2.0 if that version is unsupported 21:25:17 why an user could want a specific version but the latest ? 21:25:20 dansmith: yeah, that's what I thought too 21:25:33 that's the only way it's sane, I think :) 21:26:01 bauzas: that will remain to be seen on how the api will evolve. the api will change in behaviour 21:26:05 Ok, so in all honesty I don't think we're going to solve this in an IRC meeting 21:26:11 side note I'm not sure how ironicclient is doing the same, considering it also has microversions 21:26:15 For a start I think we need Kenichi involved 21:26:22 So at the very least this seems like a -dev mail thread to me 21:26:26 If not a spec 21:26:26 bauzas: for now, I think the latest microversion is v2.3 and v2.4 is under review 21:26:42 melwitt: they're writing specs for it this week IIRC 21:26:50 mikal: ah, okay 21:27:03 So yeah, I think we need to take this to the mailing list 21:27:12 yep 21:27:18 ok 21:27:35 claudiub: thanks for bringing it up 21:27:51 Ok, clarkb talk to me 21:28:02 mikal: no problem. and even though v2.0 will be gone in L, it will still remain in Juno and Kilo and we have to support them 21:29:19 mriedem: I assume clarkb is trying to decide what to do about your CI email? 21:29:27 mikal: he said we can control the - 21:29:29 *-1 21:29:29 mriedem: do we think turning off -1 voting is enough? 21:29:33 i do 21:29:35 mriedem: I didn't realize that was an option 21:29:44 And I have no idea how to do that thing 21:29:56 me neither 21:30:06 Ok, so clarkb has wandered off 21:30:11 might just be a project-config toggle, not sure 21:30:13 But let's resolve to remove -1 but not +1 if we can 21:30:20 And work out how to do that after the meeting 21:30:34 If its hard, we'll remove all voting instead 21:31:00 Anything else on that one? 21:31:01 mikal: see your email 21:31:16 you can remove +/-1 21:31:26 I ask because mriedem specifically says "the reason we want this i the number of -1s" 21:31:26 clarkb: oh hai 21:31:44 clarkb: can you explain how to do that to mriedem and I once we're out of this meeting? 21:31:56 just remove the account from https://review.openstack.org/#/admin/groups/511,members and then the account can't vote anymore 21:31:59 mikal: it's in your email 21:32:13 Ok, I think that's my confusion 21:32:18 i see it 21:32:19 I thought you said we could remove -1, but keep +1 21:32:20 on it 21:32:29 Which removing the account from that group wont do 21:32:37 done https://review.openstack.org/#/admin/groups/511,members 21:33:17 Ok, cool 21:33:23 Anything else for this meeting? 21:33:30 Or shall we go and do a RC1 thing? 21:33:35 Just wanted to inform we have submitted specs for improving performance of unshelving process for instances booted from image 21:33:42 #link https://review.openstack.org/#/c/135387 21:33:50 Targeted for liberty release 21:33:56 tpatil: cool, I would expect L spec review to start up in the next week or two 21:33:57 Please review this specs and give some constructive feedback. 21:34:10 ok 21:34:17 can we be done now? 21:34:20 mikal: Thanks 21:34:23 I think we are 21:34:25 early mark! 21:34:27 bye 21:34:27 #endmeeting