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