14:00:10 <edleafe> #startmeeting nova_scheduler
14:00:11 <openstack> Meeting started Mon Feb 19 14:00:10 2018 UTC and is due to finish in 60 minutes.  The chair is edleafe. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:12 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:15 <openstack> The meeting name has been set to 'nova_scheduler'
14:00:19 <efried> @/
14:00:20 <cdent> hola
14:00:22 <edleafe> Good UGT morning! Who's here?
14:00:26 <jroll> \o
14:00:27 <takashin> o/
14:00:44 <leakypipes> o/
14:01:19 <edleafe> Should be a quick meeting today
14:01:23 * leakypipes currently reading stephenfin's numa vswitch spec. thanks cdent for ruining my next couple hours.
14:01:28 * bauzas waves
14:01:47 * edleafe has the numa vswitch open in a safely buried tab
14:01:55 <ttsiouts_> o/
14:02:35 <cdent> jaypipes: sorry about that. it's got pictures at least. The formatted version is a much better read than the rst version.
14:03:19 <jaypipes> cdent: link to the html version?
14:03:26 <efried> http://logs.openstack.org/90/541290/4/check/build-openstack-sphinx-docs/da8d825/html/specs/rocky/approved/numa-aware-vswitches.html
14:03:30 <cdent> thanks efried
14:03:31 <efried> I win
14:03:35 <jaypipes> danke
14:03:41 * edleafe hands efried a cookie
14:03:48 <efried> nomnomnom
14:04:30 <edleafe> #topic Specs & Reviews
14:04:33 <jaypipes> ok so what's on the docket? more spec reviews I presume?
14:04:39 <edleafe> Lots of new specs this week
14:04:56 <edleafe> Rather than go over them all, are there any that need discussion?
14:05:18 <jaypipes> nothing that shouldn't be discussed on the specs, IMHO
14:05:24 <arvindn05> https://review.openstack.org/#/c/541507/ -glance image traits
14:05:24 <efried> I'm going to abandon resource class affinity.
14:05:40 <jaypipes> efried: k. I'm going to abandon hope.
14:05:48 <edleafe> jaypipes: sure, but immediate feedback/discussion can clarify quicker
14:05:52 <arvindn05> i got good comments on the spec and updated it...needs to know if they are any major gotchas to address
14:05:55 <jaypipes> edleafe: ack
14:06:04 <jaypipes> arvindn05: will review this morning.
14:06:04 <efried> There's still a hole that needs to be filled, and I'll be interested to see how we plan to fill it.
14:06:13 <arvindn05> * thanks jaypipes
14:06:14 <jaypipes> arvindn05: you're in the top 5 of the queue.
14:06:33 <edleafe> #link Glance image traits https://review.openstack.org/#/c/541507/
14:06:40 <jaypipes> efried: re: affinity, I'm inclined to punt on it to at least "S"
14:06:56 <jaypipes> efried: and keep affinity stuff in nova-scheduler filters for now
14:07:08 <efried> jaypipes: We talking NUMA affinity?  I got the impression that wasn't going to wait for S.
14:07:23 <jaypipes> efried: yes, including NUMA affinity porting to placement.
14:07:26 <efried> people are going to implement it right now, whether we "enable" them or not.
14:07:31 <bauzas> mmm
14:07:33 * arvindn05 thanks jaypipes
14:07:42 <efried> Just hope we don't get painted into a corner.
14:07:44 <jaypipes> efried: err, we already support NUMA affinity. just not in placement.
14:07:45 <bauzas> I was planning to implement NUMA affinity for vGPUs by Rocky
14:07:58 <bauzas> so maybe we should be discussing about that in the PTG
14:08:03 <jaypipes> bauzas: there's no reason that cannot be done as a weigher.
14:08:06 <efried> Yes, there's a number of NUMA topics in the etherpad.
14:08:22 <bauzas> jaypipes: maybe, I just want to discuss the design with the community :)
14:08:34 <bauzas> I don't have any concern :)
14:09:28 <jaypipes> sure, I have no issues with NUMA stuff. it's just a priority thing. I'm not prioritizing NUMA work (*in placement*) compared to other items, mostly the update_provider_tree() work and solving the many issues around aggregates we have.
14:10:08 <jaypipes> IOW, I want to solve the bugs we created for folks like mgagne before adding yet more features to placement.
14:10:27 <efried> Cool.  Let's merge u_p_t this week :)
14:10:28 <jaypipes> so, getting RBAC in placement API would be higher priority, for instance, than NUMA affinity
14:10:45 <jaypipes> again, this is just my opinion on where priorities should be for R
14:11:12 <edleafe> Great fodder for PTG!
14:11:21 <jaypipes> I'm eager to hear others opinions on prioritization of various items.
14:11:33 <cdent> jaypipes: did you see my latest response on mgagne's rbac requirements? Summary is "I still don't get it" (no need to discuss it here, just noting it for sake of reminder)
14:11:35 <bauzas> honestly, fine
14:11:52 <jaypipes> cdent: yes, I saw it. I think dansmith responded?
14:15:48 <cdent> jaypipes: if he did, I missed it, will go digging
14:16:26 <edleafe> Anything else for specs/reviews ahead of PTG?
14:17:01 <jaypipes> nothing from me.
14:17:39 <edleafe> moving on then...
14:17:44 <edleafe> #topic Bugs
14:17:54 <edleafe> #link Bugs https://bugs.launchpad.net/nova/+bugs?field.tag=placement&orderby=-id&start=0
14:18:08 <edleafe> A few new ones this week
14:18:44 <edleafe> efried is on the non-sharing bug
14:19:11 <efried> patch is up for that 'un
14:19:46 <edleafe> #link Placement returns 503 when Keystone is down https://bugs.launchpad.net/nova/+bug/1749797
14:19:46 <openstack> Launchpad bug 1749797 in OpenStack Compute (nova) "placement returns 503 when keystone is down" [Undecided,Confirmed]
14:19:56 <edleafe> That one is interesting
14:20:09 <jaypipes> hmm.
14:21:01 <edleafe> seems more like a keystone thing than placement, no?
14:21:12 <cdent> not keystone itself, keystonemiddlware
14:21:34 <jaypipes> edleafe: well, either way, placement shouldn't return a 503 should it? or maybe it should? not sure actually...
14:21:45 <cdent> it _kinda_ maps
14:21:48 <edleafe> jaypipes: well, I did say "interesting" :)
14:21:51 <jaypipes> yeah, I guess so
14:21:54 <jaypipes> :)
14:22:15 <arvindn05> for other api's is 503 expected when keystone is down? i would guess o
14:24:13 <edleafe> I agree that improving the error message for all would be a good step forward
14:25:35 <cdent> I don't see any real alternative?
14:25:51 <edleafe> cdent: agree
14:26:07 <edleafe> other than "don't upgrade keystone ever" :)
14:26:34 <edleafe> So... Anything else for Bugs?
14:27:04 <arvindn05> slightly related question
14:27:18 <edleafe> go ahead
14:27:39 <arvindn05> for some nova api calls when no host could be found we just return "no valid host"
14:27:58 <arvindn05> would improving the error message there be a good improvement?
14:28:38 <edleafe> arvindn05: improved in what way?
14:28:48 <arvindn05> since we now have traits, filters etc it would good to let the end user know what went wrong or where empty results are coming from etc
14:29:02 <edleafe> arvindn05: we don't want to report details of the infrastructure to end users
14:29:19 <edleafe> operators can see that info in the logs
14:29:31 <arvindn05> for example if placement api could not find host for traits, have it return that instead of user having to guess filter vs traits etc
14:29:56 <arvindn05> edleafe: got it...
14:30:27 <arvindn05> should be the same here right? why do want the 503 error message to be specific
14:31:09 <edleafe> Because it's (we hope) a temporary thing?
14:31:11 <arvindn05> operators are doing the upgrade and they can get the information of keystone not available in logs and dont really need to be exposed to end user right?
14:31:37 <edleafe> Generally if there aren't the right resources to match the request, that won't change in the near future
14:32:11 <edleafe> But a 503 at least tells the user that the problem isn't theirs
14:32:46 <edleafe> It's not perfect, so that's why we're trying to figure out the best way to deal with it
14:33:31 <arvindn05> yep got that. i thought the bug in question is asking to change the message from "503 Service Unavailable"  -> Bad response code while validating token: 503: ServiceUnavailable: Service Unavailable (HTTP 503)
14:34:40 <arvindn05> 503 definitely makes sense for me...i can add comments to the bug...we can move on...thanks for the info/discussion
14:34:42 <edleafe> arvindn05: the bug was that returning 503 in general felt wrong to the bug reporter
14:35:03 <jroll> edleafe: but now I realize the error of my thoughts :P
14:35:09 <edleafe> the error message change was in the discussion about it
14:35:21 <jroll> I think it's fine to expose that to the placement user, I suspect we don't intend end users to use placement anyhow?
14:35:24 * edleafe realizes most of his thought are in error
14:35:37 <edleafe> jroll: zactly
14:35:55 <edleafe> #topic Open Discussion
14:35:58 <jroll> I hope my operators already know that keystone is down :P
14:36:44 <edleafe> So I have a question: who is or is not going to be at PTG?
14:36:49 * edleafe will be there
14:36:53 * jroll will
14:36:53 <cdent> o/
14:37:07 <takashin> will
14:37:36 <efried> o/
14:37:37 <arvindn05> except for the traits api within placement...placement API is not intended to be exposed to end user, as i understand it
14:37:43 <efried> There's an attendance list at the top of the etherpad.
14:37:51 <efried> oh.  There was.
14:37:55 <efried> Now it's at the bottom.
14:38:02 <efried> Make sure you're updated on there.
14:38:40 <cdent> jaypipes: you're at ptg, yes?
14:39:00 <cdent> they have crunchie bars in IE?
14:39:02 <efried> L329
14:39:50 <edleafe> #link Nova Rocky PTG etherpad https://etherpad.openstack.org/p/nova-ptg-rocky
14:40:15 <edleafe> If you're going, add your name to the list near the bottom of ^^
14:41:38 <edleafe> If it isn't obvious yet, no meeting next week
14:41:49 <edleafe> ...at least on IRC
14:42:38 <edleafe> The following week (5 March) I will be in transit and not able to run the meeting. If the rest of you want a meeting then, someone else will have to chair it
14:43:12 <edleafe> If there's nothing else, let's wrap this up
14:43:40 <cdent> nada
14:44:11 <edleafe> Thanks everyone! Looking forward to seeing many of you in Dublin!
14:44:13 <edleafe> #endmeeting