21:00:00 <dansmith> #startmeeting nova_cells
21:00:01 <openstack> Meeting started Wed Dec 14 21:00:00 2016 UTC and is due to finish in 60 minutes.  The chair is dansmith. Information about MeetBot at http://wiki.debian.org/MeetBot.
21:00:02 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
21:00:04 <openstack> The meeting name has been set to 'nova_cells'
21:00:07 <dansmith> ohai
21:00:11 <dtp> hi
21:00:35 <dansmith> dtp: do you not stay on irc all the time? I went looking for you this morning and you weren't in -nova
21:00:57 <dtp> i try to keep it closed.  i find #nova distracting
21:01:05 <dtp> but it's not a big deal.  i'll be on more
21:01:09 <melwitt> o/
21:01:20 <dansmith> dtp: embrace the chaos
21:01:38 <dansmith> okay,
21:01:44 <dansmith> #topic test/bugs
21:02:03 <dansmith> we had a bug this week when the tripleo people were trying to upgrade past the cell setup requirement
21:02:12 <dansmith> I have a patch up to fix one of the major issues:
21:02:17 <dansmith> https://review.openstack.org/#/c/409890/
21:02:30 <dansmith> which was creating the cell0 map, then failing doing the host mapping,
21:02:49 <dansmith> which means that if you ran it again it would never re-do the latter bit because it assumed the cell0 map meant it was done
21:03:00 <dansmith> that, and we have some documentation stuff we need to suck less at
21:03:00 <mriedem> HI!
21:03:13 <dansmith> any other bug/testing stuff?
21:03:22 <mriedem> so, on docs
21:03:24 <mriedem> :)
21:03:32 <mriedem> i was thinking an arch diagram might be nice
21:03:40 <mriedem> given mgagne's questions about where the api db lives in cells v1
21:03:52 <dansmith> I'm sure you were
21:04:02 <melwitt> +1 to arch diagram
21:04:25 <dansmith> so,
21:04:45 <dansmith> in this fantasy I have about writing a blog post for this,
21:04:50 <dansmith> I had planned a series of diagrams going from "normal nova" to "cellsv2"
21:04:56 <dansmith> so you can see which parts get added, where, and why
21:04:59 <mriedem> i'm sure you were
21:05:04 <melwitt> that sounds super
21:05:23 <mriedem> +1 on super
21:05:59 <dansmith> anything else on this subject?
21:06:27 <dansmith> #topic open reviews
21:06:27 <mriedem> naw
21:06:45 <dansmith> my megaseries has made some progress, but also grown more patches: https://review.openstack.org/#/c/367557/
21:06:59 <dansmith> unit and functional tests pass for me on the top patch, however, which is somewhat mind boggling
21:07:18 <melwitt> that's sweet
21:07:34 <dansmith> the bottom patch has a couple comments on an older PS that I could fix up
21:07:47 <dansmith> but otherwise, several at the bottom there should be good for reviews
21:08:05 <dansmith> I noticed that melwitt pushed up a couple things for quotas
21:08:20 <dansmith> melwitt: it looked like those were just moving quotas to the api db.. did you decide against the counting plan?
21:08:32 <melwitt> yeah, I have WIP on them as they have no tests yet. but it would be nice to get a sanity check on where I'm going
21:08:45 <melwitt> no, counting is next and it's tied to a different spec
21:08:57 <dansmith> I thought the point was to do the counting so we don't move them?
21:09:03 <melwitt> we have to move limits and classes
21:09:25 <melwitt> I didn't move usages or reservations
21:09:30 <dansmith> okay, well, I haven't looked so I should shut up I guess
21:09:31 <dansmith> okay
21:10:04 <melwitt> so we have a minimal move needed to store quota limits and quota classes, even thought quota classes do nothing except handle the default quota
21:10:27 <dansmith> yeah, I guess I forgot about having to move the settings separate from the records
21:10:41 <mriedem> we could take the opportunity to kill quota classes,
21:10:44 <melwitt> next will be ripping out all the usages, reservations stuff and replacing it with counting
21:10:48 <mriedem> but it's probably a bit late for that right now
21:10:55 <dansmith> mriedem: yeah I was just wondering if we could just fake that or something
21:11:12 <mriedem> i had a ML post in newton about removing quota classes...
21:11:18 <mriedem> but it's all dropped out of my brain by now
21:11:21 <melwitt> yeah, that would involve a microversion on the API to take it out too right
21:11:33 <mriedem> well,
21:11:36 <mriedem> i'm not sure about that
21:11:45 <mriedem> the api could still return the default quotas
21:11:51 <dansmith> if it doesn't work, we just fake what we return right?
21:11:57 <melwitt> the quota-class-sets that lets you create and update quota classes
21:12:04 <dansmith> like "oh yeah, there are totally some classes, and here they are"
21:12:21 <mriedem> i'd have to go back and look at the ML thread
21:12:21 <dansmith> oh, I didn't think you could actually create them
21:12:30 <mriedem> i think some of the problem was some of that shit was already busted
21:12:31 <melwitt> oh yeah you can
21:12:37 <melwitt> which sucks
21:12:56 <dansmith> so you can create them but they don't work?
21:13:15 <mriedem> http://lists.openstack.org/pipermail/openstack-dev/2016-July/099218.html
21:13:55 <mriedem> " You can still create unique quota classes via the os-quota-class-sets  API (it does a create if the update operation fails), but as far as I  can tell you can't really use those in any meaningful way."
21:14:01 <melwitt> yeah, I read through that thread before moving them because it wasn't clear to me what it would take to remove them
21:14:30 <mriedem> "I think we should also add a microversion to the API in Ocata to disable  the ability to create new quota classes, so that update is only update,  and a 404 for anything else."
21:14:37 <mriedem> so...
21:14:45 <mriedem> we could just make update an update for default
21:14:47 <mriedem> and that's it
21:14:54 <mriedem> an update on a thing that doesn't exist is a 400
21:14:56 <mriedem> or 404
21:15:03 <mriedem> rather than update or create
21:15:08 <melwitt> that means we still have to move them I guess, if update is possible? if someone already created some other classes in the past? or does that not matter because no class other than default does anything?
21:15:20 <dansmith> or just not move those
21:15:23 <dansmith> so that they all become 404 :)
21:15:39 <dansmith> if there's no way to really use this, are we just being silly by maintaining compatibility?
21:15:52 <melwitt> we have to move them if they do something, I just don't understand yet whether they do anything. the non default ones if someone created some
21:16:10 <dansmith> compat is all well and good until you orchestrate a giant move of nothing from one database to another to ensure that a broken thing remains broken :/
21:16:32 <melwitt> yeah, agreed. if existing non default quota classes don't do anything, then we won't have to move them
21:16:35 <mriedem> Vek did provide the original concept http://lists.openstack.org/pipermail/openstack-dev/2016-July/099270.html
21:16:52 <mriedem> you create a class with more or less quota, and apply that to a tenant
21:17:02 <dansmith> so vek said he didn't care if it went away, and sdague said he'd be okay dropping it
21:17:04 <mriedem> in practice i don't know of anyone that uses it
21:17:24 <dansmith> mriedem: but I thought it doesn't actually work for anything but default
21:17:27 <dansmith> are you saying it does ?
21:17:35 <mriedem> idk, would have to test it out
21:18:02 <mriedem> like,
21:18:10 <mriedem> maybe i can change global default quota to 1 instance per tenant,
21:18:29 <mriedem> but then create a custom quota class that allows 2 instances per tenant, and assign that to another tenant, and see if i can create >1 instance on it
21:18:52 <melwitt> yeah. that would probably be a lot easier than trying to figure out from the code whether non default classes work
21:19:03 <melwitt> because it's awesomely confusing
21:19:10 <mriedem> so i'll take the todo to see you can actually use this today
21:19:13 <dansmith> okay, so mriedem you're going to do that?
21:19:14 <dansmith> cool
21:19:16 <mriedem> i've got a fresh desvstack
21:19:30 <mriedem> but yeah the quota classes stuff plumbed throughout the code makes everything harder to follow
21:19:45 <dansmith> yeah
21:20:00 <dansmith> okay, moving on
21:20:02 <mriedem> #action mriedem to see if custom quota classes actually work
21:20:14 <dansmith> dtp: did you push up a review?
21:20:18 <dtp> not yet
21:20:25 <dtp> but i have questions
21:20:33 <dansmith> dtp: shoot
21:20:41 <dtp> https://github.com/openstack/nova/blob/master/nova/consoleauth/rpcapi.py#L92
21:20:49 <dtp> if i understand what i'm doing here -
21:21:05 <dtp> i need to get the real data behind that token from memcache
21:21:33 <dtp> so that i can get the instance_uuid
21:21:57 <dtp> so is memcache somehow shared across all the cells?
21:22:08 <dtp> otherwise, if we're running a separate cache in each cell
21:22:24 <dtp> then i'll need to get to the cache to pull out of it, but i need the instance uuid to get to it
21:22:49 <melwitt> yeah, I was thinking the memcache is global but I haven't actually used the tokens before
21:22:57 <dansmith> well,
21:23:04 <dansmith> it'd be good if that didn't matter
21:23:17 <dansmith> so the problem is that we don't have the instance_uuid in the url for the console?
21:23:50 <dtp> that is one idea.  if i could get instance uuid passed, that would make things easier
21:24:00 <dtp> or perhaps the only idea
21:24:09 <dansmith> didn't we discuss adding the instance to the url already?
21:24:15 <melwitt> argh, I had thought that was available on the client side but it isn't
21:24:15 <dansmith> perhaps for a different problem
21:24:45 <dansmith> yeah it's not
21:24:55 <melwitt> what do you mean by add it to the url?
21:25:23 <dansmith> the console url is something like /console/<token> or something right?
21:25:36 <dtp> yes
21:25:37 <dansmith> so if it was /console/<instanceuuid>/<token>
21:25:40 <dansmith> then we'd have both
21:25:51 <melwitt> like the rest api call you mean? or something else
21:25:53 <dansmith> that'd be hella better than having to talk to memcache from this side
21:26:03 <bauzas> holy snap
21:26:05 <dtp> and since we generate console urls, we can do this?
21:26:13 <bauzas> just missed the beginning of the meeting
21:26:14 <dansmith> melwitt: well, the url you make the console call on, which is in the instance I think
21:26:19 <dansmith> dtp: I would think we could
21:26:59 <melwitt> yeah, I didn't intend on talking to memcache on the client side. I just didn't realize I was looking at the server side or something at the time
21:27:27 <dansmith> oh yeah,
21:27:31 <dansmith> I think it's easy
21:27:38 <dansmith> it's ?token= even
21:27:52 <dansmith> so just add instance_uuid in ther
21:27:56 <melwitt> easy == GOOD
21:27:56 <dansmith> sec
21:27:59 <dansmith> https://github.com/openstack/nova/blob/master/nova/compute/manager.py#L4546-L4548
21:28:01 <dansmith> now, here's the rub
21:28:07 <dansmith> that is done on the compute side,
21:28:15 <dansmith> which would make the api stop working until all computes get upgraded
21:28:33 <dansmith> so what might be even better is to have the api-side of that call tack on the instance uuid before returning what the compute returned,
21:28:45 <dansmith> which would fix it before computes are upgraded
21:29:02 <dansmith> so here: https://github.com/openstack/nova/blob/master/nova/api/openstack/compute/remote_consoles.py#L67-L67
21:29:09 <dansmith> you could tack on the instance uuid
21:29:21 <melwitt> ah, cool
21:29:22 <dansmith> dtp: you will want to sync up with sdague on this I think
21:29:29 <dansmith> but I think that's probably okay,
21:29:41 <dansmith> and I think he might've been in a convo about this for a different thing a while ago
21:29:52 <melwitt> do we need to worry about existing urls that don't have instance uuid?
21:29:57 <dansmith> dtp: if he seems receptive, tell him "dansmith sent me"
21:30:02 <dansmith> dtp: and if not, tell him it's all youridea
21:30:08 <dtp> lol
21:30:23 <dtp> i'm still processing what you have said, but don't let me hold you up
21:30:44 <dansmith> melwitt: it would mean anyone that grabbed a url before an upgrade wouldn't work, but they would just re-ask and get an updated one
21:30:46 <dansmith> melwitt: so I don't think it's too bad
21:31:10 <melwitt> okay, cool
21:31:24 <dtp> how is sdague involved?
21:31:25 <dansmith> dtp: so, this is turning into a little more meaty thing, but still not to bad I think
21:31:34 <dansmith> dtp: he says "no" to a lot of API stuff
21:32:03 <dansmith> dtp: if we can catch him in the next couple days I'll be glad to be there for that convo
21:32:22 <dansmith> dtp: if not, melwitt can surely back you up
21:32:33 <dansmith> sdague likes melwitt a lot more than he likes me anyway, so that's probably a good thing
21:33:04 <melwitt> hah
21:33:33 <melwitt> and yes, I can help talk to him next week if we can't catch him this week
21:33:41 <dansmith> dtp: okay, so have we jammed your brain full for the moment? definitely ask this kinda stuff sooner on irc if anything else comes up
21:33:56 <mriedem> melwitt: are you around next week?
21:34:00 <dtp> yes, head is full.  i would have but i have been delayed
21:34:03 <mriedem> dan is out after friday
21:34:04 <melwitt> mriedem: yep
21:34:27 <melwitt> I think I have next friday off as a company holiday
21:35:31 <melwitt> so I'll be around monday - thursday
21:35:43 <mriedem> alright
21:35:46 <dansmith> okay so, speaking of that
21:35:54 <dansmith> do we need to have a cells meeting for the next two weeks?
21:35:59 <dansmith> if so, ya'll'er on your own
21:36:53 <bauzas> hard
21:37:06 <mriedem> dansmith: probably not
21:37:07 <dansmith> soft?
21:37:10 <mriedem> limp
21:37:25 <dansmith> okay, so unless someone speaks up I shall send a mail to the list about it
21:37:38 <mriedem> i probably need to talk to jay about his involvement in the upcoming pagan holiday
21:37:42 <dtp> when is this work due?
21:37:54 <dansmith> dtp: heh, are you a student?
21:38:04 <mriedem> dtp: feature freeze is january 26th
21:38:10 <dtp> *studen of nova cells v2*
21:38:19 <dansmith> bah dum dum
21:38:31 <dtp> ok
21:38:50 <dansmith> since we have already...
21:38:54 <dansmith> #topic open discussion
21:38:56 <dansmith> anything else?
21:40:34 <dansmith> okay then
21:40:48 <dansmith> dtp: don't be a stranger, ask in -nova and ye shall receive :)
21:40:50 <dansmith> #endmeeting