14:00:44 <efried> #startmeeting nova-scheduler
14:00:45 <openstack> Meeting started Mon Mar 18 14:00:44 2019 UTC and is due to finish in 60 minutes.  The chair is efried. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:46 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:49 <openstack> The meeting name has been set to 'nova_scheduler'
14:00:50 <cdent> \o/
14:00:51 <takashin> o/
14:00:53 <efried> what, I was like 45 seconds late
14:00:55 <alex_xu> \o
14:01:13 <efried> Changing over the laundry. Thought I was going to bleed into the next minute, but I made it.
14:01:20 <cdent> that was a glance not a glare
14:01:23 * bauzas sits at the back
14:01:27 <tetsuro> o/
14:01:37 <efried> #link Agenda https://wiki.openstack.org/wiki/Meetings/NovaScheduler#Agenda_for_next_meeting
14:01:47 <efried> #topic last meeting
14:01:47 <efried> #link last minutes http://eavesdrop.openstack.org/meetings/nova_scheduler/2019/nova_scheduler.2019-03-11-14.00.html
14:01:56 <efried> #link DRY/clean up placement objects phase 2 https://review.openstack.org/#/q/topic:cd/de-list-phase2+(status:open+OR+status:merged)
14:01:56 <efried> ^ merged \o/
14:02:05 <efried> other ol bidniss?
14:02:09 <edleafe> w00t!
14:02:19 * efried apologizes to non-English speakers
14:02:25 <efried> Any other old business?
14:02:54 <efried> #topic specs and review
14:02:54 <efried> #link latest pupdate http://lists.openstack.org/pipermail/openstack-discuss/2019-March/003865.html
14:03:01 <efried> #link negative aggregate membership https://review.openstack.org/#/q/topic:bp/negative-aggregate-membership
14:03:01 <efried> ^ Minimal additional work to make ready for Train
14:03:46 * alex_xu is googling
14:04:02 <efried> Folks could render opinions on:
14:04:02 <efried> #link getting rid of backslash continuations https://review.openstack.org/#/c/641497/
14:04:37 <mriedem> o/
14:04:42 <efried> and whether
14:04:42 <efried> #link using ``code`` role in section titles http://logs.openstack.org/04/641404/5/check/openstack-tox-docs/1d2faee/html/placement-api-microversion-history.html
14:04:42 <efried> is still ugly/shouting
14:04:52 <efried> It appears to be bad on mac, fine on linux/windows.
14:04:56 <edleafe> As the pep8 document clearly states, readability trumps absolute adherence to the guidelines
14:05:20 <mriedem> i don't love http://logs.openstack.org/04/641404/5/check/openstack-tox-docs/1d2faee/html/placement-api-microversion-history.html but it's better than it was originally
14:05:54 <efried> mriedem: So IYO, go with it or trash it?
14:06:14 <mriedem> i don't have a real strong opinion on this
14:06:18 <efried> ight
14:06:31 <efried> Maybe finucannot has one.
14:06:38 <cdent> let's do whatever finucannot wants
14:06:38 <efried> but I don't think he's around atm
14:06:45 <bauzas> he's on holiday today
14:06:52 <mriedem> heh i'm sure he has a bias since he added that to the docs theme tooling
14:06:56 <cdent> my passport says I should be on holiday today too
14:07:07 <bauzas> (Irish people have some times after a beer day, that's it)
14:07:10 <efried> oh, is it a "bank holiday"?
14:07:31 <cdent> on the island of ireland, yes
14:08:06 <efried> Any other reviews to discuss?
14:08:17 <efried> What about bps/specs lined up for Train?
14:08:19 <cdent> I have some doc changes that landed this morning/last night
14:08:28 <cdent> and are needed before we cut the rc
14:08:43 <efried> landed meaning proposed?
14:09:02 <efried> Please link, I will review soonest.
14:09:19 <cdent> (yes, as in landed on gerrit... ) there's still 1 or 1.5 big things left to do on the docs for rc front: upgrade from nova docs, and releasenotes review and prelude creation
14:10:10 <cdent> #link from-pypi install: https://review.openstack.org/#/c/643938/
14:10:21 <cdent> #link restructure install: https://review.openstack.org/#/c/643919/
14:10:31 <cdent> #link database singularity fix: https://review.openstack.org/#/c/643915/
14:10:40 <cdent> #link cleaner usage docs: https://review.openstack.org/#/c/643913/
14:11:00 <efried> ack
14:11:12 <edleafe> cdent: will review those soon
14:11:24 <cdent> do we have any volunteers for the upgrade from nova docs? It needs to be available for review by wednesday at the latest
14:12:08 <efried> I wouldn't know what that looks like I'm afraid. Can we tap like a lyarwood or a tonyb?
14:12:33 <cdent> why would they be good choices?
14:12:50 <efried> Don't they know how to upgrade things?
14:12:58 <efried> or, like, install things?
14:13:08 <efried> See, I don't even know who *knows* how to do that shit.
14:13:11 <efried> I'm clearly a terrible choice.
14:13:16 <mriedem> wouldn't that doc, at the very least, essentially be a walk through of the steps in the grenade patch?
14:13:21 <cdent> the issue isn't the way to normally do an upgrade, but rather the way in which upgrades are different
14:13:27 <cdent> mriedem: yes, that's the plan, as stated on the pupdate
14:13:48 <cdent> If nobody wants to volunteer I can do it, but I didn't want to clobber any toes that were already started
14:14:01 <cdent> also by having me do it, that means there's an added "why can't he type!?" review burden
14:14:27 <mriedem> doesn't matter to me, if you can't get to it i can put words to https://github.com/openstack-dev/grenade/blob/master/projects/60_nova/from-rocky/upgrade-nova
14:14:29 <mriedem> since we both worked on it
14:14:46 <mriedem> it won't be pretty but anything is better than nothing
14:15:02 <cdent> I think given that you (mriedem) are probably in some criitical nova paths, I'll take it
14:15:17 <mriedem> heh, i'm trying not to be, but ok
14:15:29 <cdent> #action cdent nova-to-placement upgrade doc
14:15:56 <efried> Spec-wise, I wanted to mention this as an early warning: I haven't started yet, but I plan to scribble down something to enable inter-provider affinity for various cases like NUMA and similar. We've brainstormed a few ideas on this at the past several PTGs but never really landed on anything (or, to my knowledge, written anything down).
14:16:25 <efried> Perhaps as a lead-in, I should start an etherpad to gather ideas first.
14:16:49 <cdent> While I think that's worth thinking/talking about, I would be put it pretty far behind getting nova using shared and nested more than it currently does
14:17:02 <cdent> I think there are plenty of non-affinity-using use cases that are not yet filled
14:17:21 <cdent> which is not to stymie any writing down. Definitely write down.
14:17:22 <mriedem> speaking of docs, i guess i'll be writing something up about https://review.openstack.org/#/c/538498/ in the nova reference docs
14:18:11 <efried> #link inter-provider affinity brainstorm etherpad https://etherpad.openstack.org/p/placement-inter-provider-affinity
14:18:32 <efried> mriedem: Can't you get aspiers to do it?
14:18:40 <efried> I mean, we already suckered him into finishing the patch
14:18:54 <mriedem> he's been poked a few times so i think he's probably ignoring it
14:18:58 <efried> And he did such an excellent job...
14:19:00 <efried> okay.
14:19:02 <mriedem> so i'll just puke up some words
14:19:19 <mriedem> he's also busy backporting this sev stuff for suse...
14:20:05 <efried> okay
14:20:05 <efried> #action mriedem to document compute driver capability traits per https://review.openstack.org/#/c/538498/
14:20:34 <efried> anything else review/spec wise?
14:20:52 <efried> #topic bugs
14:20:52 <efried> #link Placement bugs (launchpad) https://bugs.launchpad.net/nova/+bugs?field.tag=placement
14:20:52 <efried> #link Placement storyboard https://storyboard.openstack.org/#!/project_group/placement
14:21:03 <cdent> once RC is done and the dust settles, I intend to write up a refreshed spec on shared disk (after I do some learning)
14:21:11 <efried> any bugs to mention? In particular, things we want in Stein?
14:21:21 <efried> cdent: lmk if you want help with that.
14:21:33 <cdent> when I checked friday there wasn't anything critical bugwise, except for the already mentioned docs
14:21:47 <cdent> I'll do another review of that either later today or tomorrow morning
14:21:53 <bauzas> that reminds me one question
14:21:56 <cdent> but the impression that I had was that except for docs we are releasable
14:22:01 <efried> cool
14:22:10 <bauzas> what would we our backport policy once we cut RC1 ?
14:22:17 <bauzas> for bugfixes
14:22:30 <mriedem> same as always
14:22:31 <mriedem> right?
14:22:33 <mriedem> why change it
14:22:41 <efried> I'm a little curious whether we backport bugfixes into nova-placement
14:22:43 <cdent> yeah, what were you thinking bauzas ?
14:22:44 <bauzas> should we have backports to Stein and older against both placement and nova repos ?
14:22:50 <efried> yeah, that
14:22:56 <bauzas> okay I'm cool
14:23:05 <cdent> security fixes only to nova, I'd say
14:23:21 <efried> I agree
14:23:26 <cdent> because it's not supposed to be a "real" thing
14:23:31 <bauzas> cdent: actually, it's a question to the placement team, would you follow the stable policy ?
14:23:33 <efried> Encourage people to move.
14:23:42 <cdent> bauzas: for now, yes
14:24:10 <bauzas> if you follow the stable policy, all bugfixes, not only security ones, are candidates for backports
14:24:10 <cdent> I think there is scope to talk (some ways in the future) about getting off the standard release cycle but that's not something to do any time soon
14:24:25 <cdent> bauzas: yes, but nova isn't placement, so it doesn't matter
14:24:33 <cdent> how
14:24:34 <cdent> ever
14:24:34 <bauzas> I don't get the answer
14:24:50 <cdent> If we want to go back to rocky then yes, we would need to go back to nova
14:24:59 <bauzas> if someone proposes a change against stable/nova, I guess we will accept it
14:25:06 <cdent> i'm crossing my fingers that that won't be necessary
14:25:16 <mriedem> let's deal with the hypothetical when it actually comes up
14:25:19 <cdent> yes
14:25:28 <edleafe> mriedem: I was just typing something similar
14:25:37 <mriedem> i don't notice a lot of critical placement bugs right now
14:25:42 <bauzas> well, we'll branch with RC1, but sure, let's not rathole on it
14:25:44 <cdent> we've been really lucky so far, so let's hope it continues
14:25:58 <edleafe> s/lucky/skilled
14:25:59 <edleafe> :)
14:26:03 <mriedem> we've had some stuff that needed to go to both like that one postgres fix
14:26:09 <mriedem> for the consumers migration
14:26:15 <mriedem> but those are fairly obvious
14:26:39 <efried> Backtracking again, one more spec-ish thing to bring up.
14:26:39 <efried> #link Nova scheduler using openstacksdk instead of direct ksa to talk to placement https://review.openstack.org/643664
14:26:59 <efried> Wondering if this needs a bp and/or spec.
14:27:13 <efried> perhaps for the broader goal of using sdk for all our talk-to-services
14:27:37 <mriedem> a broader change to the sdk yes would be a bp at least imo
14:27:56 <mriedem> swapping the scheduler client stuff for sdk seems like not a huge win to me since the scheduler client is already just using ksa
14:28:16 <mriedem> getting rid of cinderclient/neutronclient/glanceclient are much bigger deals
14:28:24 <efried> oh, for sure, the only win is proving that the tweaks made in sdk work.
14:28:37 <efried> and establishing the framework in nova
14:28:49 <mriedem> sounds like ptg fodder to me
14:28:52 <efried> which, with the sdk tweaks, turns out to be fairly simple.
14:29:05 <efried> k, I think I added it to the ptg etherpad already
14:29:28 <mriedem> you'll just have to work on your sales pitch
14:29:40 <cdent> wear a tie
14:29:50 <efried> I'll just have mordred walk in
14:30:00 <efried> whereupon the Harlem Gospel Choir will burst into song
14:30:30 <efried> moving on
14:30:39 * bauzas won't do any "walks into a bar" jokes
14:30:42 <efried> #topic opens
14:30:42 <efried> On the agenda:
14:30:42 <efried> Should we further split objects/resource_provider.py? How?
14:30:57 <efried> This came up because cdent put up a patch to reorder the remaining 2KLOC of objects/resource_provider.py
14:31:07 <efried> and I poo-pooed it
14:31:09 <cdent> and we all ran screaming
14:31:27 <efried> and said I wanted to instead/first split resource_provider.py into (yet) smaller chunks
14:31:51 <efried> The only obvious way to do this is to sub-module it based on what things you're mucking with on the resource provider.
14:32:09 <cdent> another is db/not-db
14:32:11 <efried> So we have a module for Trait, where you mess with actual traits; but there would be a resource_provider.traits where you would mess with a resource provider's traits.
14:32:21 <cdent> but that's probably more invasive
14:32:28 <edleafe> I really don't like the idea of sub modules
14:32:42 <efried> I talked to edleafe last week about this, and he really didn't like the idea of sub modules.
14:33:12 <edleafe> RPs are big, complex things. It stands to reason that the code to describe them would be large.
14:33:24 <efried> how do others feel? Is 2KLOC small enough to not be worth the potential confusion of sub-module namespaces?
14:33:41 <efried> also keeping in mind that resource_providers.py could grow
14:33:49 <efried> unless tetsuro keeps trimming it down, which is ++
14:34:18 <cdent> My attitude is perhaps clear: I think long modules are bad news and that efforts to split them up seems to always lead to non-size related cleanups and bug fixes, so my preference would be that we consider size a bug, and fix things as possible
14:34:21 <efried> #link -74LOC in resource_provider.py https://review.openstack.org/#/c/643729/
14:34:42 <edleafe> Traits only apply to RPs. So where do we draw the line between objects.resource_provider.traits and objects.traits?
14:34:46 <cdent> not because size is _literally_ a bug, but it is a good excuse
14:35:09 <efried> edleafe: that's an easy one: objects.trait is for creating, deleting, and listing traits
14:35:20 <efried> edleafe: resource_provider.traits is for changing what traits are on a resource provider.
14:35:52 <edleafe> It really feels like an artificial split because of an aversion to a large module
14:36:06 <cdent> efried: you started a placement-related ptg etherpad at some point yes? put "refactoring goals and constraints" on there, perhaps?
14:36:21 <efried> I didn't
14:36:28 <cdent> what am I remember then?
14:36:30 <efried> I asked whether you did
14:36:40 <cdent> alright
14:36:43 <efried> in the middle of the night or on a weekend or something
14:36:52 <cdent> #action cdent make a ptg etherpad with refactoring goals and constraints on it
14:37:06 <cdent> (amongst other things)
14:37:15 <edleafe> I would much prefer to reorder resource_provider.py to group all the trait-related methods together
14:37:16 <efried> don't forget to add it to https://wiki.openstack.org/wiki/PTG/Train/Etherpads -- it seems like other teams have forgotten this.
14:37:26 <efried> edleafe: it's already in that order
14:37:29 <efried> which is another thing.
14:37:37 <cdent> we already moved some trait stuff out of rp,
14:37:41 <edleafe> Then I don't have a problem with it
14:37:51 <cdent> and kept the rp related stuff (for setting) in rp
14:37:53 <efried> I don't like the idea of reordering to class->public->private->alpha
14:38:00 <efried> I prefer keeping related stuff together.
14:38:06 <efried> (like, in a module, but failing that...)
14:38:09 <edleafe> vim is really fast at searching :)
14:38:24 <efried> Sure, so are real IDEs
14:38:33 <cdent> The idea beyond that mode is that you don't have to have subjective debates (as we already have over what is "related" to something else)
14:38:38 <efried> but it's nice to be able to see both methods on the same screen.
14:38:39 <cdent> it's the same reason for stick to pep8
14:38:44 <cdent> they aren't good rules
14:38:48 <cdent> but they are easy to calculate rules
14:39:25 <cdent> if we try a little bit harder, we can paint both of these sheds before the end of the hour
14:39:29 <cdent> or we could talk about something else
14:39:34 <efried> yeah, let's move on.
14:39:53 <efried> We have been carrying these three until we had a new PTL:
14:39:59 <efried> (From last last last last week) Format of this meeting - new PTL to query ML
14:39:59 <efried> (From last last last last week) Placement team logistics at PTG - new PTL to query ML
14:39:59 <efried> #link post-extraction plans for placement specs/bps/stories http://lists.openstack.org/pipermail/openstack-discuss/2019-February/003102.html
14:40:04 <cdent> (I'd enjoy seeing a refactoring and code structure ml discussion, btw)
14:40:20 <efried> wow, I don't think I would enjoy that.
14:40:30 <efried> that would go off into the weeds right quikck.
14:40:52 <cdent> yeah, gist is: specs in placement repo itself, bps as stories in storyboard, but I'm going to formalize that after the RC
14:41:05 <cdent> (sure it would, which is why email is a better place, it's async)
14:41:41 <edleafe> +1 to specs in the placement repo
14:42:07 <efried> Yeah, I don't think that one is too controversial, we seemed to reach consensus fairly easily
14:42:12 <efried> cdent: Would you like to open the discussion of fate of this meeting and/or PTG logistics here prior to asking ml?
14:43:08 <cdent> I think we have insufficient people participating here right now for any decisions made here, now, to stick. So I've got nothing on that, but if people have things to say, go for it
14:44:01 <efried> yeah, just thought a quick brainstorm
14:44:51 <cdent> If we make an RC and the world doesn't explode, I'll take core of that stuff soon after that
14:44:56 <cdent> care
14:44:58 <cdent> but speaking of core
14:45:25 <cdent> I'm going to port the nova-cores to placement, but would prefer to only port those that are actually interested
14:45:59 <cdent> a plan, which I'd like people here to verify or dismiss is: post to the ml asking for positive assent to be added to placement-code. That allows people who don't care or aren't paying attention to be dropped without effort
14:46:02 <cdent> Thoughts?
14:46:09 <mriedem> +
14:46:14 <mriedem> fwiw nova-core itself needs to be trimmed
14:46:18 <bauzas> that's fair
14:46:27 <efried> ++ cdent
14:47:24 <cdent> I'm not expecting there to be anyone who wants to participate but shouldn't, but if that comes up we'll cross that bridge
14:48:14 <edleafe> And, of course, anyone who later decides to become active would be welcomed back
14:48:47 <cdent> damn, was hoping to be able to shun
14:50:05 <cdent> I got nothing else
14:51:43 <efried> anybody anything else for opens?
14:52:42 <efried> alright, thanks all o/
14:52:42 <efried> #endmeeting