14:00:24 <efried> #startmeeting nova-scheduler
14:00:25 <openstack> Meeting started Mon Mar  4 14:00:24 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:26 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:28 <openstack> The meeting name has been set to 'nova_scheduler'
14:00:32 <takashin> o/
14:00:48 <alex_xu> \o
14:00:59 <tetsuro> o/
14:01:09 <edleafe> \o
14:01:54 <gibi> o/
14:02:00 <cdent> o/
14:02:03 <efried> #link agenda (just updated, please refresh) https://wiki.openstack.org/wiki/Meetings/NovaScheduler#Agenda_for_next_meeting
14:02:28 <bauzas> \o
14:02:45 <efried> #topic last meeting
14:02:45 <efried> #link last minutes http://eavesdrop.openstack.org/meetings/nova_scheduler/2019/nova_scheduler.2019-02-25-14.00.html
14:03:26 <efried> old business:
14:03:31 <efried> #link alloc cands in_tree series starting at https://review.openstack.org/#/c/638929/
14:03:31 <efried> merged \o/
14:03:36 <cdent> huzzah
14:04:00 <efried> #link the OVO-ectomy https://review.openstack.org/#/q/topic:cd/less-ovo+(status:open+OR+status:merged)
14:04:00 <efried> merged \o/
14:04:23 <efried> the rest we'll get to in new bizniss.
14:04:29 <efried> anything else from last week?
14:04:50 <efried> #topic specs and review
14:04:50 <efried> #link latest pupdate http://lists.openstack.org/pipermail/openstack-discuss/2019-March/003385.html
14:04:50 <efried> pupdates are back \o/
14:05:09 <efried> #link blueprint tracking https://etherpad.openstack.org/p/nova-stein-blueprint-status
14:05:21 <efried> #link libvirt reshaper https://review.openstack.org/#/c/599208/
14:05:21 <efried> bauzas, what news?
14:05:46 <bauzas> efried: I just provided a comment
14:06:00 <bauzas> given the concern of alex_xu
14:06:15 <bauzas> but tbc, the series is done
14:06:21 <bauzas> we need reviews
14:06:44 <efried> o right, alex_xu would you please have a look?
14:06:59 <efried> Since you're here - if you still have concerns, we can discuss them in #opens
14:07:00 <alex_xu> yea, sorry just saw the reply
14:07:17 <efried> or, uh, now I guess would also be fine.
14:07:42 <alex_xu> no, my reading is slow, please go through other item first
14:07:55 <efried> sure thing.
14:08:07 <efried> #link DRY/clean up placement objects starting at https://review.openstack.org/#/c/637325/
14:08:41 <efried> This is getting tall. Much work is being done here. jaypipes has a -1 on the bottom, cdent has responded (TLDR: what jaypipes suggests is happening, just further up the chain)
14:08:43 <cdent> I rebased that this morning, more than I initially intended
14:08:50 <efried> heh, I noticed
14:09:11 <cdent> my local tree had something already merged in it and I got confused
14:09:39 <efried> white belt mistake
14:09:53 * cdent has never liked rebasing
14:10:17 <efried> anyway, most of those 15 reviews are pretty easy, more eyes would be most welcome.
14:10:37 <efried> 14 (/me can't count)
14:10:38 <cdent> yeah, if we could get more of that merged, it would make the tallness less of a challenge
14:11:01 <efried> #topic Extraction
14:11:01 <efried> #link Extraction https://etherpad.openstack.org/p/placement-extract-stein-5
14:11:09 <efried> whoops, I put a link in the wrong place on the agenda...
14:11:15 <efried> #link Placement is set up to use storyboard https://review.openstack.org/#/c/639445/
14:11:18 <efried> ^ is merged
14:11:27 <cdent> #link storyboard: https://storyboard.openstack.org/#!/project_group/placement
14:11:27 <efried> what does this mean, that we've officially got a storyboard presence?
14:11:32 <efried> thanks cdent
14:11:48 <efried> I've never used storyboard before, will need to find the storyboard-for-dummies reference
14:11:51 <cdent> yes, but we haven't yet solidified plans of how to use it
14:12:02 <cdent> ditto
14:12:15 <cdent> I think they have some test projects too where it is possible to play around
14:12:42 <cdent> related to storyboard: I marked as "fix committed" a bunch of bugs that were committed but hadn't been auto updated. there are a few left I'm not sure about:
14:13:18 <cdent> which I suppose we can talk about during the bugs topic
14:13:33 <SotK> https://storyboard-dev.openstack.org/ is the sandbox for storyboard
14:13:41 <SotK> for playing around in
14:13:46 <efried> Thanks SotK
14:13:56 <bauzas> to make it clear, you want to use storyboard for what ? blueprints only or bugs ?N
14:13:58 <efried> #link storyboard sandbox https://storyboard-dev.openstack.org/
14:14:20 <cdent> bauzas: nothing yet, because we haven't yet made a plan and it seemed weird to try to make a plan at this stage in the cycle
14:14:26 <efried> why?
14:14:26 <bauzas> ok
14:14:41 <bauzas> why to who ?
14:14:44 <bauzas> me or cdent?
14:15:01 <efried> why shouldn't we try to figure out how we're going to use sb?
14:15:05 <bauzas> me : because I'd like to know what to do when you want to provide some feature for placement
14:15:22 <bauzas> that's it
14:15:24 <efried> what are the options on the table?
14:15:34 <cdent> we should figure it out, but we don't need to rush to change anything because we don't want to confuse end users who might be wanting to report bugs _now_
14:15:44 <cdent> and are not party to our meanderings
14:15:58 <cdent> for train related features I would think that creating stories in storyboard will be the way to go
14:16:00 <edleafe> Some time at the PTG for SB discussion/education would be a help
14:16:09 <bauzas> agreed with edleafe
14:16:11 <efried> What does it take to get, um, "subscribed" to new things that are put into sb against our project?
14:16:19 <bauzas> or wait for the new PTL to decide :)
14:16:28 <cdent> but since we're not in a hurry in that direction, and people are focused on feature freeze and other things, I assumed we could put the SB planning on the back burner
14:16:53 <cdent> efried: go to preferences under your name
14:17:03 <cdent> where there are email settings you can choose
14:17:10 <edleafe> Yeah, let's not do StoryBoard 101 now
14:17:24 <efried> figured it out.
14:17:32 <efried> It was fairly intuitive, once I had realized I needed to log in.
14:17:35 <efried> so
14:17:57 <efried> It's probably fairly obvious, having decided to use this thing at all, what should happen in the Train cycle.
14:18:10 <SotK> feel free to come and ask questions in #storyboard when you start trying to figure things out
14:18:38 <efried> Namely: new features and long-term wishlist items should get a, um, "story". And bugs should be reported there too.
14:18:49 <efried> I think it's the interim between now and then that's not cut and dried
14:18:56 <efried> is that a reasonable assessment?
14:19:10 <cdent> yes
14:20:01 <edleafe> Be prepared for a "moving to git from svn" brain reshuffling. The workflow is not 1:1 to launchpad
14:20:16 <efried> so it seems to me as though we do need to figure out that interim, precisely so that people are not confused about where and how to report bugs
14:20:18 <cdent> I think for "us" we can manage to use both launchpad and storyboard for the rest of the cycle, and in train it will be only storyboard. But for "them" I think asking people to switch not on a cycle boundardy is weird
14:20:42 <efried> then this seems like an ideal transition period.
14:20:48 <efried> Send an email announcing we're migrating to SB
14:20:55 <efried> and that we'll continue accepting lp bugs until train opens
14:21:10 * bauzas just loves the SB acronym
14:21:21 <efried> but at that point we'll shut down lp (which I guess we won't/can't really do, but we can say it) and all bugs need to be reported in sb.
14:21:37 <bauzas> AFAIK, there are some tools for migrating bugs from LP to SB
14:21:42 <efried> and meanwhile train specs should be opened in sb exclusively.
14:21:53 <jaypipes> efried: sorry, was etherpadding about cyborg... yes, will try to get to that series today.
14:21:56 <efried> bauzas: I think that's the part we're planning to wait on, until train officially opens.
14:21:59 <cdent> right: the main stickler here is that people will _always_ continue reporting bugs in launchpad, so we can't simply forget about it because nova isn't getting shut down
14:22:00 <efried> jaypipes: ack, thx
14:22:07 <bauzas> you should poke some folks in #storyboard that'd be happy to help you, incl. but not exhaustively fungi (IIRC)
14:22:26 <fungi> definitely not exhaustively ;)
14:22:37 <efried> yup, I get it cdent. When we officially cut over, we would I guess start marking placement bugs as Invalid in lp, requesting they be opened in sb instead.
14:22:51 <cdent> something like that
14:22:51 <bauzas> there is an upgrade path
14:22:59 <bauzas> again, you should get info first
14:23:11 <cdent> I really don't think we need to over analyzse this. there is a very small number of bugs that get reported on placement itself
14:23:12 <bauzas> but some projects already made the leap
14:23:13 <efried> and in the interim, we would respond to all such bugs with a message like, "Okay, we're dealing with this here now, but on such-and-such a date we're transitioning..."
14:23:20 <cdent> we just need to pay some attention and it will be fine
14:23:37 <efried> Okay, but in terms of immediate action, IMO somebody should send an email.
14:23:52 <cdent> to which audience?
14:24:00 <cdent> because we already did to "us"
14:24:02 <efried> ML
14:24:03 <bauzas> again, before taking any action, just consider the migration path *first* :)
14:24:27 <cdent> efried: I mean which audience within the ML
14:24:31 <bauzas> unless you only wanna features
14:24:33 <efried> I can volunteer for that, though it'll have to be exclusively "what" since I have no idea on the "how".
14:24:41 <efried> [placement] ought to suffice, no?
14:24:57 <efried> because we only care about people opening bugs/features against placement
14:25:00 <cdent> efried: I'm asking if you mean end users/operators or devs? Because that changes the pitch of the message
14:25:12 <efried> it does?
14:25:12 <cdent> In any case:
14:25:14 <efried> Lemme draft something
14:25:18 <efried> and I'll show it to you
14:25:21 <efried> and we can go from there
14:25:22 <cdent> #action: cdent send a message about storyboard
14:25:24 <cdent> i'll do it
14:25:25 <efried> I don't think this is rocket science
14:25:26 <efried> okay.
14:25:36 <efried> moving on
14:25:46 <cdent> It's not rocket science is what I've been trying to say for the last 10 minutes
14:25:52 <efried> anything else extraction?
14:26:07 <cdent> some of the puppet stuff merged, which is cool
14:27:14 <cdent> other than that, I think extraction is pretty much done for this cycle
14:27:26 <cdent> it's next cycle when nova deletes placement that things get exciting again
14:28:18 <efried> cool
14:28:30 <efried> #topic bugs
14:28:30 <efried> #link Placement bugs https://bugs.launchpad.net/nova/+bugs?field.tag=placement
14:28:42 <efried> cdent: you wanted to talk about some possibly-done bugs needing to be marked in lp?
14:28:58 <cdent> yeah, one sec
14:29:06 <cdent> #link https://bugs.launchpad.net/nova/+bug/1696830
14:29:07 <openstack> Launchpad bug 1696830 in OpenStack Compute (nova) "nova-placement-api default config files is too strict" [Low,In progress] - Assigned to Corey Bryant (corey.bryant)
14:29:15 <cdent> #link https://bugs.launchpad.net/nova/+bug/1778591
14:29:15 <openstack> Launchpad bug 1778591 in OpenStack Compute (nova) "GET /allocations/{uuid} on a consumer with no allocations provides no generation" [Medium,In progress]
14:29:21 <cdent> are either done or stuck, I'm not sure which
14:30:04 <cdent> I dropped https://goo.gl/vzGGDQ from 17 to 6 earlier today
14:30:19 <cdent> mostly because we no longer have auto reporting of "fix committed"
14:30:25 <efried> \o/
14:31:40 <cdent> I assuming we have a similar problem with bugs not yet marked as in progress:
14:31:51 <cdent> #link https://goo.gl/TgiPXb
14:31:52 <cdent> but i haven't checked that and probably won't get to it today
14:32:45 <efried> so what needs to be done to move things along? Or is it necessary to move things along with any urgency?
14:33:30 <cdent> no immediate urgency, but if any of those are "done" or "dead" they can be made to not cloud the storyboard waters
14:33:51 <cdent> and just as a matter of principle a bug that hasn't had attention in a while isn't really real
14:35:07 <efried> okay.
14:35:20 <efried> #topic opens
14:35:20 <efried> (From last last week) Format of this meeting - new PTL to query ML
14:35:20 <efried> (From last last week) Placement team logistics at PTG - new PTL to query ML
14:35:20 <efried> #link post-extraction plans for placement specs/bps/stories http://lists.openstack.org/pipermail/openstack-discuss/2019-February/003102.html
14:35:40 <efried> libvirt reshaper fup - alex_xu, ready to discuss?
14:35:51 <alex_xu> yea
14:36:05 <efried> bauzas: ^
14:36:19 <bauzas> yup
14:36:21 <alex_xu> may i ask why we have this middle step https://review.openstack.org/#/c/599208/18? before we have multiple types
14:36:42 <bauzas> because if not, we need to reshape once more
14:36:57 <efried> Perhaps alex_xu is suggesting we go straight to multiple type support
14:37:03 <bauzas> the original PS was only providing a single inventory per *type
14:37:18 <efried> alex_xu: I think we agreed to do it in stages just to keep the surface area manageable for stein.
14:37:19 <bauzas> but for NUMA awareness, that couldn't make it
14:37:19 <alex_xu> oh...that is what i thought when I read the spec
14:37:34 <bauzas> so, we decided to not just take only one aspect at once
14:37:50 <bauzas> but rather model the resources as the best for both affinity and type check
14:38:07 <bauzas> even if both affinity and type check features aren't there yet
14:38:22 <bauzas> - just to prevent extra reshapes that are costly -
14:38:41 <bauzas> HTH ?
14:39:12 <alex_xu> yea, i see the reason now
14:39:41 <alex_xu> but in the end, when we have numa and multiple type, then we will put same type in the same RP, right?
14:39:59 <efried> I don't think so.
14:40:05 <efried> I think we would still split along pGPU lines.
14:40:18 <alex_xu> what is the reason behind that ?
14:40:40 <efried> because it's still important to be able to map inventory units (placement) to PCI addresses (libvirt/linux)
14:41:06 <efried> and a given pGPU has a given number of VGPU units available
14:41:17 <efried> that's assuming we keep the traits of all the pGPUs the same, which isn't necessarily going to happe
14:41:18 <efried> n
14:41:36 <efried> and if we were to change the config of a pGPU that had been consolidated with another of the previously-same type, we would have to reshape.
14:41:38 <bauzas> yup, correct
14:41:47 <efried> whereas if we keep them separate, we can just do the change.
14:41:48 <alex_xu> yea, agree with that, at least a vm needn't a lot of vGPU
14:41:56 <bauzas> we will still provide inventories per physical GPUs
14:42:12 <alex_xu> then we simple the code a little since RP mapping to the PCI address
14:42:19 <bauzas> if two pGPUs share same type, that's good, but that's still two RPs
14:42:31 <bauzas> alex_xu: there is a spec on it
14:42:38 <bauzas> that basically says that yes
14:42:46 <alex_xu> cool, thanks, i got it
14:43:36 <bauzas> alex_xu: fyk https://specs.openstack.org/openstack/nova-specs/specs/rocky/approved/vgpu-rocky.html
14:43:40 <efried> Do any of the other reviewers who have participated along the way want the opportunity to give it a nod before we +W it?
14:43:55 <bauzas> honestly, except you and alex_xu... :p
14:44:09 <bauzas> and matt co-authored, so he can't really argue
14:44:17 <alex_xu> but at the edge case, like each two of PGPU only left 1 VGPU, and a VM is asking 2 VGPUs?
14:44:19 <efried> mriedem jaypipes cdent artom melwitt gibi
14:44:52 <efried> alex_xu: If requested in the same request group, fail. If requested separately, that request can be fulfilled.
14:44:52 <alex_xu> or actually pGPU can provide enough number of VGPUs? that isn't the case worry about?
14:45:11 <alex_xu> efried: but that required a different flavor
14:45:24 <gibi> efried: I followed a bit. and I'm for representing separate PGPUs as separate RPs
14:45:56 <cdent> I think the implementation is what we said it should be, and in general a different "physical" thing should be a different rp
14:46:00 <efried> if I were designing a flavor, and it had multiple vgpus in it, and I wanted to assure most-likely-to-fit, I would request resources1:VGPU=1&resources2:VGPU=1&...&resourcesN:VGPU=1&group_policy=none
14:46:31 <gibi> at some point somebody will ask for the numa awareness of the vgpu-s and then we need to know which vgpu is coming from which PGPU which close to which numa node
14:46:32 <jaypipes> efried: I'd like the opportunity.
14:46:35 <jaypipes> please
14:46:39 <efried> if I were being lazy and didn't care so much about most-likely-to-fit, I would request resources:VGPU=N
14:46:56 <alex_xu> oh....request group can use like that
14:46:56 <efried> but that would bounce in scenarios of high saturation as alex_xu mentions
14:47:21 <efried> jaypipes:  ack. So alex_xu if you approve, please don't +W
14:47:28 <bauzas> you lost me
14:47:39 <bauzas> I was dragged from two mins
14:47:56 <alex_xu> no, I will leave that to jaypipes, I'm not follow this series enough
14:48:08 <efried> okay
14:48:11 <efried> bauzas: I think we're clear.
14:48:15 <bauzas> are we drawing something ?
14:48:21 <efried> a conclusion?
14:48:24 <alex_xu> yes, I'm clean :)
14:48:27 <bauzas> just to make it clear, the reshape is just modeling resources
14:48:32 * efried rolls out his Jump To Conclusions Mat.
14:48:34 <bauzas> not how you query them :)
14:48:53 <bauzas> given you can't allocate more than a single vGPU atm, it's a no-brainer :)
14:49:02 <jaypipes> for the record, I've reviewed that series a number of times now. I think half my reviews are sitting in draft state because various others bring up identical points I was raising.
14:49:11 <jaypipes> just would like to do a once over on it.
14:49:17 <jaypipes> for peace of mind
14:49:20 <efried> that would be helpful in any case jaypipes, thank you.
14:49:22 <bauzas> tbh, the reshape change is hairy
14:49:45 <bauzas> hence why I'm very reluctant to have more than a single reshape :)
14:50:48 <efried> yeah, it's not that it's a resource drain on the system or anything; it's just pretty complicated to code up. And a special-purpose chunk of code that's going to get run at most once in a deployment and then never used again.
14:51:14 <efried> so good to minimize how many reshapers we write overall.
14:51:30 <efried> anything else on this topic before we move on?
14:51:57 <efried> okay, other topics for open discussion before we close?
14:52:45 <efried> Thanks everyone.
14:52:45 <efried> o/
14:52:45 <efried> #endmeeting