14:00:15 <edleafe> #startmeeting nova_scheduler
14:00:16 <openstack> Meeting started Mon Apr 10 14:00:15 2017 UTC and is due to finish in 60 minutes.  The chair is edleafe. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:17 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:19 <openstack> The meeting name has been set to 'nova_scheduler'
14:00:25 <mriedem> o/
14:00:28 <edleafe> Good UGT Morning, all!
14:00:35 <jimbaker> o/
14:00:42 <jaypipes> ya, here.
14:00:45 <macsz> \o
14:00:50 <cdent> o/
14:01:29 <edleafe> well, let's get into it.
14:01:30 <edleafe> #topic Specs & Reviews
14:01:45 <bauzas> \o
14:01:47 <edleafe> Traits
14:01:48 <edleafe> #link Add Traits API to Placement https://review.openstack.org/#/c/376200/
14:02:35 <edleafe> That looks like it's ready to go
14:02:50 <edleafe> Any comments?
14:03:11 <cdent> apparently not
14:03:15 <edleafe> Next up: os-traits
14:03:16 <edleafe> #link os-traits reorg: https://review.openstack.org/#/c/448282/
14:03:45 <edleafe> I added my automation on top of the NIC code
14:03:52 <cdent> ed's automation and de-register +1
14:04:27 <edleafe> Again, this series looks ready to go
14:04:32 <edleafe> Next up: Placement API
14:04:33 <edleafe> #link Improvements to PUT and POST https://review.openstack.org/#/c/447625/
14:04:58 <cdent> looks like it just needs its +W back
14:05:03 <edleafe> That's got a ton of +2s, but no +W
14:05:07 <edleafe> Any reason why?
14:05:31 <edleafe> oh, wait - the rechecks
14:05:42 <cdent> It did, but got rebased
14:05:45 <edleafe> bauzas had +W'd it earlier
14:06:05 <bauzas> kaboom
14:06:10 <edleafe> thx
14:06:13 <bauzas> or rather +W'aboom
14:06:27 <edleafe> heh
14:07:24 <edleafe> Moving on: Claims in placement spec
14:07:24 <edleafe> #link WIP placement doing claims: https://review.openstack.org/437424
14:07:27 <edleafe> #link Forum session proposed for claims in the scheduler: http://forumtopics.openstack.org/cfp/details/63
14:07:30 <edleafe> We'll be having a hangout in a few hours to discuss this in more depth to help move it forward
14:08:37 <mriedem> i need to follow up with fifeld
14:08:42 <mriedem> *t
14:09:50 <edleafe> So please join the hangout at 1600 UTC. mriedem will post the link in -nova, right?
14:10:07 <mriedem> umm,
14:10:11 <mriedem> it's super secret
14:10:19 <mriedem> but i can
14:10:30 <bauzas> FWIW, I haven't yet updated the spec, holding until the Clarification
14:10:34 <edleafe> We Follow the 3.5 Opens!
14:11:05 <jimbaker> :)
14:11:27 <edleafe> ok, next up: Show scheduler hints in server details
14:11:28 <edleafe> #link Show sched. hints in server details: https://review.openstack.org/440580
14:11:30 <edleafe> There are mixed opinions on whether this belongs in all server detail responses, or only when specifically requested.
14:11:40 <mriedem> if we did this,
14:11:45 <mriedem> i agree it should be a subresource as sdague noted
14:11:50 <edleafe> IMO it's unnecessary clutter
14:11:55 <mriedem> it sounds like gibi wants to abandon now though
14:12:12 <edleafe> ah, ok. Hadn't looked in a few days
14:13:15 <mriedem> unless something changes in the next couple of days,
14:13:19 <mriedem> it will probably die on the vine for pike
14:13:55 <edleafe> Moving on: Nested Resource Providers
14:13:55 <edleafe> #link Nested RPs: https://review.openstack.org/#/c/415920/
14:13:56 <edleafe> Nested Resource provider series still on hold until traits is done, but will this effort be revived soon?
14:14:04 <edleafe> jaypipes: ^^
14:14:24 <edleafe> since traits is pretty darn close
14:14:48 <jaypipes> edleafe: it's rebased locally, but will need to be rebased again with the 1.6 mircoversion that traits API adds.
14:15:19 <jaypipes> edleafe: I'd really like to get the os-traits patches merged.
14:15:50 <edleafe> jaypipes: there don't seem to be any objections to them, right?
14:16:03 <edleafe> what do they need to get over the finish line?
14:16:06 <jaypipes> edleafe: just needs core reviews AFAIK
14:16:19 <edleafe> ok, cores, you know who you are!
14:16:37 <mriedem> i don't
14:16:49 <mriedem> i've starred that last change, i haven't reviewed any of the traits stuff,
14:16:57 <mriedem> but i can try to get to it with some gentle prodding
14:17:00 <mriedem> this afternoon
14:17:21 * edleafe gets out the virtual cattle prod
14:17:30 <cdent> I think you need a sheep prod, if you want gentle
14:18:29 <cdent> I've got a spec to add to the list, which i forgot to put on the agenda, once we get to the end
14:19:10 <edleafe> OK, then, last agenda item: Use local-scheduler spec
14:19:10 <edleafe> #link Add use-local-scheduler spec https://review.openstack.org/#/c/438936/
14:19:13 <edleafe> Seems like a bit of a misnomer - more like "merge scheduler into conductor"
14:19:40 <mriedem> i think that one is premature for pike, last i checked
14:20:03 <edleafe> agreed
14:20:06 <bauzas> well, it could be good to have it for cellsv2
14:20:14 <cdent> it's in "backlog" so okay
14:20:25 <bauzas> but yeah, pike seems early
14:20:26 <mriedem> oh didn't realize it was backlog
14:20:43 <macsz> i moved it
14:20:51 <macsz> it seems we are not yet ready for this, either way
14:20:55 <macsz> agreed or not
14:20:55 <mriedem> the recent discovery of the instance info upcalls from compute scared me for this one
14:21:26 <macsz> kept the comments, will address them later, after the spec freeze
14:21:51 <edleafe> ok, then - cdent, you had a spec to add?
14:22:03 <cdent> yeah, wrote it up last week after realizing my api change needed one
14:22:11 <cdent> #link placement idempotent put resource class: https://review.openstack.org/#/c/453732/
14:22:33 <cdent> there's already code for that. the change is relatively straightforward, and it has a small but relevant data integrity impact
14:23:53 <edleafe> OK, then let's get some specs-core reviewers to go over that one
14:24:05 <edleafe> Anything else for specs & reviews?
14:24:16 <mriedem> so this is just create-or-update right?
14:24:24 <cdent> mriedem: yes
14:24:37 <cdent> just to mention, there are pending placement-api-ref changes in progress
14:24:49 <cdent> get your reviews in early if you want to help set tone or whatever
14:25:02 <cdent> it's probably going to be a many stage process
14:25:23 <cdent> #link placement-api-ref https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:cd/placement-api-ref
14:26:01 <cdent> mriedem: actually it's not realy update, more create-or-verify, as there's no body
14:26:38 <edleafe> "make sure this exists"
14:27:22 <edleafe> cdent: be sure to add those to the agenda if there are any issues
14:27:45 <edleafe> Anything else for specs & reviews?
14:27:47 <cdent> edleafe: none, yet, but wil
14:27:48 <cdent> l
14:27:53 <_gryf> edleafe, regarding "Provide detailed error information for placement API" (https://review.openstack.org/#/c/418393/) blueprint, it seems that I will not be able to finish this
14:28:55 <edleafe> _gryf: is it a time constraint, or an issue with the BP itself?
14:29:08 <_gryf> edleafe, neither (or both)
14:29:19 <edleafe> :)
14:29:28 <mriedem> _gryf isn't working on openstack anymore, right?
14:29:41 <mriedem> so it's a person constraint
14:29:48 <macsz> mriedem: yes
14:29:48 <_gryf> edleafe, I've been assigned to different tasks within my division
14:30:00 <edleafe> _gryf: ah, understood.
14:30:17 * cdent shakes his tiny fist
14:30:31 <_gryf> so that I've simply no time for finish that.
14:30:41 * _gryf is really sorry
14:30:54 <bauzas> _gryf: don't be sorry
14:30:57 <bauzas> never.
14:31:02 <cdent> just to be clear my fist is shaking at capitalism (or something) not _gryf
14:31:15 <bauzas> cdent: it's life and life can be hard
14:31:18 <edleafe> well, it looks like a worthwhile BP.
14:31:35 * bauzas teaching his 6-yr daughter of such
14:31:41 <mriedem> if we could get closure on the spec,
14:31:44 <mriedem> and agreement to a plan,
14:31:48 <mriedem> then that would be a good clean break,
14:31:52 <mriedem> and someone else could pick it up
14:32:05 <mriedem> having said that, i haven't reviewed it
14:32:09 <bauzas> we could put that for the nova 101 session at the Forum
14:32:45 <bauzas> I guess some folks could be interested in working on operator-related issues
14:32:48 * johnthetubaguy wonders about the consistent API errors work, and the logging working group
14:32:59 <bauzas> that too, of course, but let's not diverge
14:33:11 <bauzas> I just think that blueprint is worth being shared with volunteers
14:33:27 <johnthetubaguy> well that is one of the consistent API errors bit, just thinking about co-ordinating those efforts
14:33:42 <edleafe> johnthetubaguy: +2
14:33:47 <johnthetubaguy> API-WG spec is maybe enough, just curious
14:33:55 <edleafe> sorry, didn't mean to sound that enthusiastic
14:34:01 <edleafe> I really just meant +1
14:34:06 * edleafe has fat fingers
14:34:06 <johnthetubaguy> lol
14:34:42 <bauzas> paying more is always appreciated :)
14:35:20 <bauzas> johnthetubaguy: got your point, maybe the above doesn't require a spec then ?
14:35:35 <johnthetubaguy> it needs a spec, its an API change
14:35:50 <johnthetubaguy> just curious on co-ordination
14:35:53 <bauzas> sorry, I'm unclear
14:35:57 <johnthetubaguy> but we should move on if no one has an update
14:36:25 <edleafe> johnthetubaguy: something for the api-wg meeting?
14:36:35 <johnthetubaguy> probably
14:36:36 <bauzas> I was misunderstanding by the fact that I thought we had a spec covering that already
14:37:10 <edleafe> OK, moving on then
14:37:14 <edleafe> #topic Bugs
14:37:21 <edleafe> None added to the agenda
14:37:35 <edleafe> Anyone have a bug that they would like to focus on?
14:37:38 <mriedem> i sort of have something
14:37:48 <mriedem> due to time,
14:37:58 <mriedem> i haven't written a functional test for https://bugs.launchpad.net/nova/+bug/1679750 but someone could
14:37:59 <openstack> Launchpad bug 1679750 in OpenStack Compute (nova) "Allocations are not cleaned up in placement for instance 'local delete' case" [Undecided,New]
14:38:20 <mriedem> we have some local delete functional tests now under nova/tests/functional/regressions that could be copied as a start
14:38:31 <mriedem> not a huge issue,
14:38:48 <mriedem> plus, i guess it depends on if we actually decide to delete allocations in placement from the api during a local delete scenario
14:39:21 <mriedem> we could also handle cleaning up the allocations when the host comes back up
14:39:36 <mriedem> which would keep nova-api from needing to have a dependency on placement, which might be ideal
14:40:04 <edleafe> mriedem: stuff like this was the reason for the periodic updates, no?
14:40:07 <mriedem> anywho, ^ is a quagmire for someone to drown in
14:40:23 <mriedem> edleafe: maybe?
14:40:36 <edleafe> we kind of know that things can get out of sync from time to time
14:40:36 <jimbaker> standard cleanup quandary it would seem... :)
14:40:37 <mriedem> however,
14:40:51 <mriedem> i assume the periodic updates in the compute rely on actually having instances running on that host right?
14:41:03 <mriedem> since those are tied to the allocations as the consumer_id
14:41:19 <mriedem> if we delete the instances in the api, then i doubt anything in the compute is looking up those deleted instances and cleaning up allocations
14:41:20 <cdent> the allocations for the entire host are retrieved as well, and compared
14:41:22 <mriedem> they are zombies
14:41:33 <mriedem> if this is a non-issue, i'm happy
14:41:34 <cdent> (if I recall correctly, ymmv, etc)
14:41:58 <edleafe> that's something that has been kind of hand-wavy. One of the reasons we want to add a bunch of functional tests that cover these scenarios
14:41:58 <mriedem> but i'm fairly sure we don't have a functional test for the scenario to be able to tell
14:42:07 <edleafe> jinx
14:42:17 <mriedem> hence why i was going to write that first
14:42:20 <mriedem> but time
14:42:23 <cdent> thank goodness edleafe said it, it would be bad form to call jinx on other people
14:42:47 <mriedem> ok i'm done
14:42:49 <edleafe> #agreed Bad form to call jinx on other people
14:43:06 <edleafe> #topic Open discussion
14:43:20 <edleafe> So... what's on your mind?
14:44:27 <jimbaker> although i plan to be lurking for a bit, i do plan to work on nova related things going forward, as part of osic; most likely scheuler
14:44:30 <jimbaker> scheduler
14:44:40 <jimbaker> so hi everyone
14:44:45 * johnthetubaguy waves at jimbaker
14:44:53 <cdent> yay, new people
14:44:58 <jroll> \o/
14:44:59 * edleafe hands jimbaker a cookie
14:45:22 <jimbaker> thanks everyone!
14:45:56 <johnthetubaguy> cdent I spoke to jimbaker about your email on the placement performance
14:46:13 <cdent> ah, excellent
14:46:14 <jimbaker> yep, so that looks like a good way into the project
14:46:21 <jimbaker> touches a few things
14:46:40 <cdent> I think as a first pass just observing placement under load to see how it behaves is a great start
14:46:53 <cdent> I've never taken it beyond a single node :(
14:47:17 <mriedem> hell,
14:47:22 <cdent> then from those observations some more rigorous testing ought to reveal itself
14:47:30 <mriedem> comparing boot times between filter scheduler with placement and without would be a nice start
14:47:31 <johnthetubaguy> I mentioned fake virt, no idea how good that is right now for this purpose
14:47:33 <jimbaker> johnthetubaguy asked me to look at workload characterization with respect to placement performance - so i guess we will look at more than one node after all
14:47:40 <johnthetubaguy> mriedem: +1
14:48:35 <mriedem> i'm not sure if rally/os-profiler would tell us enough info before/after using placement in the scheduler or not
14:48:41 <mriedem> but you could do that with newton pretty easily
14:48:58 <mriedem> as placement in the scheduler is optional in newton, if it's not there the scheduler falls back to the pre-placement code
14:49:03 <johnthetubaguy> true newton does both, good idea
14:49:12 <mriedem> doing this comparison in ocata would be tricky
14:49:39 <jimbaker> got it
14:49:58 <mriedem> ping me if you need details on how to fake that out for a test run in newton
14:50:13 <mriedem> i think even single node to start would be fine
14:50:19 <bauzas> no
14:50:23 <bauzas> ocata does both
14:50:27 <jimbaker> mriedem, thanks. and in general, i think instrumentation is a good thing. i'm sure i will it get it wrong at first
14:50:40 <bauzas> newton can do placement, but with less features
14:50:48 <mriedem> bauzas: oh that's right
14:50:49 <mriedem> good point
14:50:53 <cdent> right, the filter scheduler doesn't start requesting providers until ocata
14:50:54 <mriedem> jimbaker: yeah sorry, so start with ocata
14:50:59 <bauzas> while ocata can exactly do both, if you run newton computes
14:51:09 <mriedem> ocata will fallback if placement isn't available
14:51:16 <mriedem> or not new enough
14:51:17 <jimbaker> but my general sense of things is that better instrumentation results in better implementations, and better ecosystem in general
14:51:23 <johnthetubaguy> ah, so just kill the endpoint in keystone to fall back
14:51:35 <bauzas> oh man, jimbaker has the exact same pidgin color than mriedem
14:52:05 <mriedem> johnthetubaguy: or goof the placement creds in nova.conf
14:52:06 <jimbaker> hashing to a small number of bits... got to love it
14:52:15 <mriedem> anyway
14:52:16 <johnthetubaguy> mriedem: thats simpler
14:52:19 <mriedem> we can discuss the details later
14:52:31 <jimbaker> again, thanks for the ideas, and i know who to find here!
14:52:35 <bauzas> johnthetubaguy: I'd just use newton computes with ocata scheduler
14:52:37 <mriedem> reminds me i need to figure out how to get a new devstack vm in the new job
14:52:41 <bauzas> bench them
14:52:47 * macsz has the same color problem with mriedem johnthetubaguy and _gryf
14:52:55 <bauzas> and then, start deploying placement and rollup ocata computes
14:53:25 <mriedem> bauzas: that seems much more complicated for someone that's new
14:53:31 <johnthetubaguy> bauzas: that sounds complicated
14:53:36 <mriedem> throwing upgrades into the mix would just make this harder
14:53:41 <bauzas> fair enough
14:53:49 <mriedem> jimbaker: we can talk in -nova after the meeting
14:53:53 <mriedem> which should end right now!
14:54:03 <johnthetubaguy> makes it hard to switch back to retest, but lots of ways
14:54:04 <bauzas> yup, 3 hours of meetings back to back
14:54:09 <jimbaker> mriedem, +1
14:54:09 <edleafe> hey,w e still have 6 minutes!
14:54:15 <johnthetubaguy> mriedem: good hinting
14:54:19 <bauzas> and I'm just at the end of my first hour
14:54:26 * edleafe was just letting you guys hash it out
14:54:26 <bauzas> so, please save my soul
14:54:30 <edleafe> #endmeeting