14:00:46 <efried> #startmeeting nova
14:00:47 <openstack> Meeting started Thu Feb  6 14:00:46 2020 UTC and is due to finish in 60 minutes.  The chair is efried. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:48 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:51 <openstack> The meeting name has been set to 'nova'
14:00:57 <bauzas> \o (in 1:1 meeting also)
14:01:00 <alex_xu> o/
14:01:02 <huaqiang> o/
14:01:21 <gmann> o/ (in TC meeting also )
14:02:20 <efried> #link agenda https://wiki.openstack.org/wiki/Meetings/Nova#Weekly_Nova_team_meeting
14:03:19 <brinzhang> o/
14:03:21 <efried> #topic Last meeting
14:03:21 <efried> #link Minutes from last meeting: http://eavesdrop.openstack.org/meetings/nova/2020/nova.2020-01-30-21.00.html
14:03:23 <sean-k-mooney> o/
14:03:31 <efried> We had some action items from last time...
14:03:41 * efried sean-k-mooney to do the train implemented specs business
14:03:54 <sean-k-mooney> damit ill do that now
14:04:03 <efried> :) Thanks
14:04:17 * efried lyarwood to propose train & stein releases
14:04:33 <lyarwood> ^ is done and released
14:04:34 <efried> this got done. I think I saw both merged today.
14:04:45 <lyarwood> yup
14:04:45 <efried> Thanks lyarwood
14:04:45 <lyarwood> np
14:04:46 * efried lyarwood to curate rocky EM list
14:05:16 <lyarwood> ^ this hasn't started due to stable/rocky being blocked by tempest issues
14:05:22 <lyarwood> once these pass I'll get on with this
14:06:27 <efried> great, thanks.
14:06:41 <efried> #topic Bugs (stuck/critical)
14:06:41 <efried> No Critical bugs
14:06:53 <efried> However, the other bug numbers (see project heartbeat) have been creeping up
14:06:59 <efried> #help triage bugs!
14:07:01 <brinzhang> can we close this bug fix https://review.opendev.org/#/q/status:open+project:openstack/nova+branch:master+topic:bug/1663456
14:08:12 <efried> stephenfin: that ^ was where dansmith had jumped in and redirected at some point, right?
14:08:23 <efried> so he should probably be the +A?
14:09:21 <efried> brinzhang: let's follow up on that in the main channel when dansmith is about.
14:09:52 <efried> #topic Reminders
14:09:52 <efried> SPEC FREEZE IS NEXT WEEK
14:09:59 <brinzhang> yeah, that need get dansmith's comments
14:10:34 <efried> Last week I scrubbed the
14:10:34 <efried> #link ussuri blueprints https://blueprints.launchpad.net/nova/ussuri
14:10:35 <efried> and the specs I could find
14:11:06 <efried> #link etherpad (feel free to leave notes etc.) https://etherpad.openstack.org/p/nova-ussuri-planning
14:11:53 <efried> I've been making noise about scrubbing the list once we pass the milestone.
14:12:40 <efried> As a reminder, this would be an exercise where we make up *some* kind of criteria to pick which blueprints we're going to pursue and which we're going to defer for Ussuri.
14:13:33 <efried> Right now we have 41 blueprints against ussuri, of which seven are already implemented.
14:13:59 <efried> IMHO, given the size of the team, that's too many to land
14:15:02 <efried> but 20 are still not design:approved at this point, so I'm guessing we'll be starting with a smaller number anyway.
14:15:25 <efried> Probably a good idea to set up a spec review day for early next week. Tuesday work for everyone?
14:15:33 <sean-k-mooney> so 21 are design approve and 7 of those are done
14:15:41 <efried> yes
14:15:42 <sean-k-mooney> leaveing 14 remaining
14:15:53 <gmann> design approve means spec not merged right? I always get confused with LP mapping
14:16:01 <gmann> *design not approve
14:16:24 <efried> sorry gmann, it's a new thing. Yes, when we merge the spec we change the blueprint to design:approved.
14:16:51 <bauzas> efried: count me on it
14:16:53 <efried> for specless blueprints we can change to design:approved once we have agreement on the *how*.
14:17:18 <efried> direction:approved speaks to the *when*
14:17:23 <sean-k-mooney> https://review.opendev.org/#/c/706276/ is the review to update the implemented spec in train by the way
14:17:23 <efried> #action efried to ML about spec scrub day
14:17:25 <gmann> efriedok, yeah you old last time also but somehow i forget
14:17:31 <brinzhang> there is a spec, I think it's ready to go, I sended ML of this spec https://review.opendev.org/#/c/623120/, ML:http://lists.openstack.org/pipermail/openstack-discuss/2020-February/012352.html
14:17:32 <efried> thanks sean-k-mooney
14:18:25 <efried> Probably given who's here (and not here) it'll be best to take specific spec review requests/discussions offline.
14:18:50 <gmann> +1
14:19:30 <efried> anything else, process-wise, about spec freeze?
14:19:47 <efried> Rocky EM (lyarwood)
14:19:47 <efried> #link open rocky patches https://review.opendev.org/#/q/status:open+(project:openstack/os-vif+OR+project:openstack/python-novaclient+OR+project:openstack/nova)+branch:stable/rocky
14:19:47 <efried> we already talked about this.
14:20:00 <efried> #topic PTG/Summit planning
14:20:00 <efried> Please mark **attendance** and topics on
14:20:00 <efried> #link PTG etherpad https://etherpad.openstack.org/p/nova-victoria-ptg
14:20:35 <efried> I've been asked to fill out the survey thingy to let the planners know how much space we're going to need, so please do at least the attendance bit of that ^ as soon as you can.
14:21:56 <efried> Tough to say based on the shanghai PTG, but how big a room do folks think we'll need?
14:22:41 <brinzhang> I think at least 15 people sits :P
14:23:05 <efried> agree; that would seem to be the bare minimum to me.
14:23:24 <gmann> it was more dynamic attendance also, so expected +5 should be counted
14:23:35 <sean-k-mooney> that would cover the active memebers barely
14:23:39 <brinzhang> agree
14:24:22 <sean-k-mooney> if we want to be able to have a cross team meeing in the nova room
14:24:26 <efried> the layout options jump from 20 to 40, which is weird, I would expect us to be somewhere in between at max capacity. I guess I'll ask for the bigger one.
14:24:42 <efried> yeah, good call
14:24:45 <efried> okay, moving on.
14:24:47 <efried> #topic Sub/related team Highlights
14:24:47 <efried> Placement (tetsuro)
14:25:10 <efried> I think the only thing going here is consumer types, which tetsuro and melwitt have been working through.
14:25:46 <efried> There was some discussion about whether we should try to close the gaps in anti-affinity expressiveness so we can cover a few remaining corner cases in NUMA modeling.
14:26:03 <efried> but I think we agreed that could be deferred, right sean-k-mooney bauzas?
14:26:27 <bauzas> correct, PCI devices affinity can't be done in Ussuri
14:26:30 <sean-k-mooney> we could defer if we keep the numa toplogy filter to check the numa of numa nodes
14:26:31 <bauzas> (at least from me)
14:26:39 <efried> for now we'll use group_policy=none and let the NTF do the anti-affinity
14:26:49 <sean-k-mooney> yep
14:26:51 <efried> we're not talking about devices yet.
14:26:58 <efried> okay
14:27:07 <efried> API (gmann)
14:27:07 <efried> gmann did not send the updated report this week. Last updates on ML: http://lists.openstack.org/pipermail/openstack-discuss/2020-January/012260.html
14:27:11 <gmann> i did not get chance to send updates on ML. But working on few API spec review and policy work.
14:27:26 <gmann> i will appreciate review on this - #link https://review.opendev.org/#/q/project:openstack/nova+branch:master+topic:bp/policy-defaults-refresh
14:27:44 <gmann> changes are easy and on same line as first set of os-service API merged
14:28:12 <gmann> I will be pushing more API changes soon once bring up the stable gate up
14:28:19 <gmann> that's all from my side
14:28:22 <sean-k-mooney> gmann: that review of the code not the spec right
14:28:28 <sean-k-mooney> the design is already approved
14:28:34 <gmann> sean-k-mooney yes, code
14:28:38 <sean-k-mooney> cool
14:29:05 <gmann> first set of changes also merged with agreement with john and how we should do for other APIs
14:29:57 <efried> ready to move on?
14:30:09 <efried> #topic Stuck Reviews
14:30:18 <efried> [huaqiang] the spec 'mixed cpu policy instance spec' still needs more input
14:30:19 <efried> #link Use PCPU and VCPU in one instance : https://review.opendev.org/#/c/668656/
14:30:19 <efried> placement-ess style interface ('resources:(P|V)CPU') vs legacy flavor style (eg: 'hw(:|_)numa_pinned_cpus') interface through a CPU mask
14:30:35 <efried> we've been back and forth on this one.
14:30:38 <stephenfin> I think that needs dansmith to resolve
14:30:39 <huaqiang> stephen gives a -1
14:31:03 <huaqiang> he recomends the legacy flavor style interface
14:31:16 <dansmith> it does?
14:31:35 <efried> by the way, I thought the design work for NUMA topo brought out some great examples of why we should prefer the hw: style over the placement syntax.
14:31:36 <stephenfin> dansmith: Yup. fwict, you're asking for us to mix placement-style syntax with traditional extra specs. I absolutely don't want that
14:32:33 <dansmith> sounds like there's no room for compromise, and I'm not even -1 on that spec, so .. not much to discuss I guess?
14:33:13 <stephenfin> I was guessing you'd a good reason for preferring the thing I don't like
14:33:33 <sean-k-mooney> well at one point supporting both was an option.
14:33:41 <stephenfin> Yup, I'm fine with that too
14:33:52 <alex_xu> ok for support both too
14:33:52 <stephenfin> just not bits of one style and bits of another
14:33:53 <bauzas> the consensus on the NUMA topology spec is to *not* ask for placement-ished flavor syntax
14:34:03 <sean-k-mooney> yes
14:34:10 <bauzas> we'll provide a translation mechanism
14:34:12 <bauzas> but
14:34:31 <bauzas> the question remains, should we block flavors already expressing placement-esque ?
14:34:56 <stephenfin> let's figure that out in that spec
14:34:56 <bauzas> because I'd like to see the same agreement for huaqiang's spec
14:35:04 <stephenfin> oh, okay
14:35:11 <efried> I don't especially have a problem if the code supports the placement-ese syntax, but IMO we should not encourage it. IOW we should document the other way for any given feature.
14:35:15 <sean-k-mooney> i think that is a seperate question. i spoke to dansmith about this and i think long term no we dont block
14:35:24 <sean-k-mooney> but i would not encurage the use of groups
14:35:45 <bauzas> if we say that operators are enough grown-up for using placement-esque syntaxes, then we aslo agree that the translation mechanism is just for legacy reasons
14:35:47 <sean-k-mooney> and we need to consider evolving the current support to add a translation layer for the plamcenet syntax
14:36:05 <stephenfin> I've no objections to someone doing e.g. '... --propety resources:PCPU=N --property resources:VCPU=M'
14:36:11 <bauzas> right, that's why I tie the two specs together
14:36:21 <stephenfin> not sure how useful it is but if people want it, why not
14:36:38 <bauzas> we're talking of flavor extra specs
14:36:43 <efried> yes
14:36:55 <sean-k-mooney> the only point i object to for placement syntax is using it to expres toplogy via groups
14:36:56 <stephenfin> but I disallowed '--property hw:cpu_policy=<anything> --property:(V|P)CPU=<anything>' for cpu-resources
14:37:06 <stephenfin> and I still think disallowing that makes sense
14:37:06 <bauzas> stephenfin: if you're okay with validating the craziness of it with your own spec, then okay :)
14:37:06 <dansmith> my major complaint is that we have a hundred bespoke DSLs encoded into 255 characters with little consistency, and that we are (IMHO) reversing course on the preferred way to specify those things. I want it to be highly abstract and consistent, and placement syntax is at least a step in that direction
14:37:33 <dansmith> but I think that's the thing that most of you actually want, because it's easier on *us* instead of the *users*
14:37:42 <bauzas> I think we have a way to restrict the fooliness of extra specs with stephenfin's spec about flavor validation
14:37:44 <efried> it's the abstract-ness I have a problem with, exactly because it's harder on the users.
14:37:55 <dansmith> yes, well, we disagree obviously
14:38:17 <stephenfin> dansmith: what's easier on us? the legacy extra spec stuff?
14:38:20 <bauzas> honestly, the current NUMA extra specs are a poor DSL
14:38:27 <dansmith> anyway, I said _many_ times in the original conversation that I would not block on this, and haven't even lodged a -1 so I'm not sure why we're talking about this
14:38:33 <bauzas> I'd prefer placement-esque syntax
14:38:34 <efried> with hw:* only *we* have to understand the shape of the provider model. With resources:* etc, the *user* would have to understand it. And how placement works.
14:38:38 <bauzas> butg
14:38:44 <alex_xu> DSL is an abstract which is better than placement synatx
14:38:56 <alex_xu> numa vs a set of request groups...
14:39:08 <bauzas> but, between a standard alloc candidates query and a larger one asking for in_tree and member_of, there is a big change
14:39:12 <stephenfin> ah, then we can move on. I just didn't want huaqiang rewriting stuff only to have to undo it again
14:39:22 <efried> ++
14:39:23 <bauzas> we can move on, but the question remains
14:39:50 <huaqiang> seems I can move on now...
14:39:57 <bauzas> and I'd appreciate we get a consensus on this either in the NUMA topology spec or in the huaqiang's spec
14:40:01 <alex_xu> what about the bitmask?
14:40:17 <alex_xu> huaqiang: ^ that is still question?
14:40:25 <sean-k-mooney> we are goign to support that right?
14:40:31 <stephenfin> alex_xu: I _think_ that's what huaqiang is suggesting still, yeah
14:40:40 <alex_xu> ok cool
14:40:45 <huaqiang> I like the cpu mask solution
14:40:57 <brinzhang> agree
14:41:12 <alex_xu> yea, me too, just want to ensure
14:41:25 <sean-k-mooney> that is consitent with the numa toplogy in plamcent spec too
14:41:50 <sean-k-mooney> we shoudl revisit the question of placement syntax as a ptg topic i think
14:42:09 <stephenfin> good idea
14:42:21 <huaqiang> actually sean-k-money offers a good comments on cpu mask interface I'll follow that
14:43:03 <sean-k-mooney> efried: i thnk we can move to the next topic
14:43:09 <efried> #topic Open discussion
14:43:09 <efried> https://blueprints.launchpad.net/nova/+spec/config-tsc-freq
14:43:09 <efried> https://etherpad.openstack.org/p/invtsc
14:43:13 <efried> umbSublime: ^
14:43:22 <efried> proposal is to add the ability to expose an invariant tsc cpu flag and specify the frequency to allow live migration.
14:43:22 <efried> we previously discussed this and said it could be a specless blueprint if the blueprint content was sufficient. do we agree that it is?
14:44:10 <sean-k-mooney> so looking the blueprint it has nto been updated yet but the proposed text is in the etherpad
14:45:28 <sean-k-mooney> umbSublime: could you summerise you usecase for this
14:46:16 <umbSublime> Yes, in our openstack platform we host many game servers, some only run on windows VMs and require this flag to be present. If it isn't the process either crashes or the game server is really slow because it relies on another clock
14:47:11 <sean-k-mooney> am i correct in saying you currently work around this with the cpu_extra_flags config option
14:47:33 <sean-k-mooney> but that approch causes issues since you cannot live migrate for maintance
14:47:58 <umbSublime> My work-around it to manually virsh edit the VM after it's lauched, but obvisouly that doesn't persist any operations and I also loose the ability to live-migrate
14:48:29 <dansmith> this seems like a straightforward spec.. does it need discussion?
14:49:04 <brinzhang> yeah, that's need a spec
14:49:11 <sean-k-mooney> we had said it could be adress specless if we agreed the blueprint contianed the enough info
14:49:18 <sean-k-mooney> back in november
14:49:48 <sean-k-mooney> but if it needs a spec it would noe be hard to submit it and fill out the remaining parts of the template
14:49:54 <dansmith> it adds two new extra_specs, image props, and some virt specific behavior..seems like a spec to me
14:50:22 <stephenfin> agreed
14:50:44 <sean-k-mooney> ok umbSublime if that is ok with you ill help you prepare that
14:51:09 <umbSublime> sure this is fine with me
14:51:10 <huaqiang> only allow to migrate on hosts with same TSC frequency?
14:51:22 <efried> #agreed need spec for https://blueprints.launchpad.net/nova/+spec/config-tsc-freq
14:51:38 <brinzhang> huaqiang: I think so
14:51:41 <dansmith> huaqiang: isn't the tsc frequency specified in the flavor/image?
14:51:55 <dansmith> huaqiang: if you need to inspect something about the host like that, it will be a much larger effort
14:52:25 <huaqiang> dansmith: I don't need it, just curious about the answer.
14:52:41 <huaqiang> some CPUs with differnt model has same TSC
14:52:51 <sean-k-mooney> huaqiang: not the tsc frequecse is not the host tsc frequence
14:52:58 <sean-k-mooney> its the emulated frequency
14:53:01 <dansmith> huaqiang: I'm confused.. what happens if you migrate to a host with a cpu that isn't compatible?
14:53:04 <dansmith> and how do you know?
14:53:26 <umbSublime> KVM does some math based on the TSC value presented to the VM and the one on the host. to present an invariant TSC to them VM even after migrating to another host with different base freq
14:53:31 <dansmith> sean-k-mooney: right, I thought it was pure emulation
14:53:42 <dansmith> right, okay...
14:53:47 <sean-k-mooney> well its usign https://lkml.org/lkml/2015/9/28/15
14:54:32 <sean-k-mooney> anyway we can call that out in the spec i guess
14:54:39 <efried> Note that time is short here. In order to have a shot, I think the spec should be ready for serious review by start of business Tuesday for the review push
14:54:48 <efried> Any other open topics before we end?
14:55:10 <efried> Okay, thanks all.
14:55:10 <efried> o/
14:55:10 <efried> #endmeeting