21:00:35 <alaski> #startmeeting nova_cells
21:00:36 <openstack> Meeting started Wed May 18 21:00:35 2016 UTC and is due to finish in 60 minutes.  The chair is alaski. Information about MeetBot at http://wiki.debian.org/MeetBot.
21:00:37 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
21:00:39 <openstack> The meeting name has been set to 'nova_cells'
21:00:42 <mriedem> o/
21:00:44 <doffm> o/
21:00:49 <melwitt> o/
21:00:49 * bauzas waves
21:00:58 <dansmith> o7
21:01:11 <bauzas> broken arm ?
21:01:13 <melwitt> a salute
21:01:18 <melwitt> is my guess
21:01:30 <dansmith> salute
21:01:30 <alaski> dansmith has requested a full hour meeting so let's see what we can do
21:01:30 <bauzas> o~ then
21:01:41 <alaski> #topic testing
21:01:59 <alaski> any news from anyone here?
21:02:06 <alaski> ccarmack isn't around
21:02:22 <melwitt> I don't know if anyone's mentioned in the meeting before but the cells job seemed more prone to fail on the fernet token bug
21:02:36 <melwitt> which I saw mriedem reverted the change today, right? I saw an ML post
21:02:38 <alaski> I was not aware of that
21:02:45 <alaski> the increase in failures
21:02:57 <bauzas> orly
21:03:08 <mriedem> the revert merged hours ago
21:03:13 <melwitt> the bug was affecting the gate in general but it seemed to be more frequent in the cells job for some reason
21:03:15 <mriedem> i was so gd tired of that
21:03:19 <alaski> melwitt: did you do any digging on cause, or just noticed the correlation?
21:03:39 <melwitt> just noticed a correlation unscientifically
21:03:41 <mriedem> alaski: it's a token revocation race, not sure why cells v1 would make it worse
21:03:45 <mriedem> since it's totally a keystone test
21:03:47 <mriedem> doesn't hit nova
21:03:52 <alaski> huh
21:04:09 <mriedem> we could use logstash to get a scientific correlation
21:04:12 <mriedem> outside of this meeting
21:04:28 <alaski> okay. something to keep an eye out for when fernet tokens come back as the default
21:04:49 <mriedem> it's not actually special to the cells job
21:04:52 <mriedem> according to logstash
21:05:10 <alaski> I need to check in with ccarmack on testing, but I'm not aware of anything to mention here
21:05:12 <melwitt> okay. just me being paranoid then. sorry for the noise
21:05:14 <alaski> so we'll move on
21:05:26 <mriedem> ccarmack isn't really working on this anymore as far as i know
21:05:30 <mriedem> he's been reassigned
21:05:32 <alaski> melwitt: it was worth checking out
21:05:33 <mriedem> internally
21:05:33 <alaski> mriedem: ahh
21:06:28 <alaski> then I'll look into pulling together what he had and dumping it for someone else to look at if they wish
21:06:44 <alaski> his plan I mean
21:06:49 <alaski> #topic Open Reviews
21:06:55 <alaski> as always https://etherpad.openstack.org/p/newton-nova-priorities-tracking
21:07:17 <mriedem> oh what rebase?! https://review.openstack.org/#/c/301916
21:07:19 <alaski> I feel like there's been an increase in reviews recently which is great
21:08:13 <alaski> yeah, merge conflict
21:08:25 <alaski> one of doffms patches I think
21:08:28 <dansmith> the last patch of the keypair set never landed due to a merge conflict, but it's good to go now:
21:08:41 <dansmith> https://review.openstack.org/313664
21:08:57 <mriedem> ok, +2 on https://review.openstack.org/#/c/301916/ again
21:09:10 <dansmith> and I got the patches up to move and undo some of the inventory stuff, but the principals should probably look at those first and I've already pinged them
21:09:13 <alaski> dansmith: okay, I'll take a look again after
21:09:32 <alaski> dansmith: great
21:10:00 <alaski> #topic Open Discussion
21:10:09 <doffm> I finally got around to updating the quota migration spec with the things we discussed last week.
21:10:23 <doffm> I also added an instance groups migration spec. Both are on the priorities page.
21:10:32 <alaski> awesome
21:10:43 <doffm> Intending to start on the quotas when the aggregates stuff starts merging.
21:11:05 <alaski> okay. I was thinking of starting on it once my scheduler interaction patches are all up
21:11:12 <alaski> but I can grab something else
21:11:34 <doffm> Instance groups is for grabs. :)
21:11:36 <alaski> I feel like I need to help with migrations or testing next
21:11:55 <melwitt> I wanted to mention to the group about the oslo.messaging transport_url thing, I proposed a spec to oslo-specs and it turned out the impl-specific transport options are not recommended to use and are being deprecated
21:12:06 <alaski> doffm: cool, I'll look at that one then
21:12:15 <doffm> melwitt: So they will all be going to transport urls?
21:12:49 <melwitt> doffm: yes. CONF.transport_url is the recommended way. sileht mentioned there isn't yet total support for it in the zmq driver but he will fix that
21:12:56 <doffm> Great.
21:13:12 <alaski> melwitt: I noticed that the other options aren't marked with deprecate_for_removal yet
21:13:29 <melwitt> so, alaski and I were thinking for the nova-manage command we'll try to use CONF.transport_url if it's there and if not, error out saying to pass --transport-url
21:14:35 <melwitt> alaski: yeah, I mentioned that in the review, I -1'ed it because I thought all the options would go deprecated at the same time. but probably there will be follow on patches
21:14:43 <alaski> okay
21:15:05 <melwitt> I'll keep an eye out over there and follow up about it with sileht
21:15:10 <alaski> that also brought to light that devstack isn't using transport_url right? So that's something we'll want to fix
21:15:30 <mriedem> that could be fixed today right?
21:15:31 <melwitt> right. we'll want to get devstack generating nova.conf with transport_url
21:15:38 <alaski> mriedem: yes
21:15:39 <mriedem> action item?
21:15:46 <mriedem> who wants it
21:15:50 <mriedem> not it
21:16:11 <melwitt> I can do it. hopefully. I know it's not possible for zeromq yet but I don't even know if you can setup a devstack that way anyhow
21:16:38 <alaski> #action melwitt update devstack to use transport_url for messaging config
21:16:48 <doffm> alaski: Thinking of devstack.. do you have a patch up to add your 'one_command_to_rule_them_all'. I have an old devstack change to add cell0 setup, I should probably abandon.
21:17:08 <alaski> melwitt: looks like there's a zmq plugin
21:17:46 <melwitt> alaski: ah, right. I feel like I've seen ML posts regarding the plugin before
21:17:49 <alaski> doffm: I don't yet
21:18:07 <alaski> doffm: but it still hasn't merged
21:18:21 <doffm> Ok.
21:18:47 <alaski> I can throw something up with a depends-on though
21:19:18 <melwitt> alaski: I'm not sure if it's an option to convert the ones that are possible now and then update zmq when a version of oslo.messaging gets released that can handle connection expressed as transport_url
21:20:51 <alaski> melwitt: okay. I have no idea either. It''ll just mean devstack has to pass in transport_url with the nova-manage command for a bit
21:20:56 <mriedem> melwitt: you can case stuff in devstack generally
21:21:10 <alaski> but this also implies that cells isn't going to work with zmq until this is fixed
21:21:12 <mriedem> with a TODO to add zmq later
21:21:22 <mriedem> anyone run cells with zmq?
21:21:27 <mriedem> anyone run zmq, period?
21:21:34 <alaski> not that I know of
21:21:42 <melwitt> well, I think it also means cells doesn't work with zmq now
21:21:44 <doffm> The driver is 10 months old. (The new one)
21:21:50 <alaski> melwitt: yep
21:21:51 <bauzas> I thought zmq was a bit defunct
21:22:01 <bauzas> oh, there is a new one?
21:22:10 <doffm> I think someone in mirantis is trying to bring it back to life.
21:22:12 <alaski> there seems to be a bit of a revival around it
21:22:23 <dansmith> this is a minor thing, right?
21:22:31 <alaski> I know it's being tested heavily
21:22:34 <dansmith> it'll work when that is fixed/updated, no need to worry about it right now I think
21:22:43 <alaski> yep, just calling it out
21:23:09 <mriedem> zmq, the amqp backend for hipsters
21:23:13 <melwitt> yeah, so I'll convert for the ones now and put the TODO for zmq
21:23:14 <mriedem> re: revival
21:23:34 <alaski> well it sounds like we're all pretty much on the same page overall, and have plenty to work on
21:23:49 <alaski> so I'll wrap up here unless dansmith wants to continue
21:23:57 <mriedem> if i have procedural -2s on anything let me know in the next 24 hours
21:23:57 * dansmith is not amused
21:24:18 <alaski> cool. thanks all!
21:24:23 <alaski> #endmeeting