| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-07-17 | |||
| 21:23:07 | efried | dansmith: So the NUMATopologyFilter lives on the scheduler despite needing to know very specific things about the NUMA topology of the host it's filtering for? | |
| 21:23:55 | efried | (recognizing that one is an us-provided filter, that does things beyond just binarily saying yea or nay to a host) | |
| 21:24:45 | dansmith | efried: yeah, that's kinda the whole point | |
| 21:25:09 | efried | okay; I mean I'm just curious how the NUMATopologyFilter gets to know those things about the hosts | |
| 21:25:11 | dansmith | I'm not even sure how you're thinking things would/could be working with them on the compute | |
| 21:25:29 | dansmith | but the compute and virt driver expose a generalized model so the scheduler can operate on an abstraction, because not all clouds have all the same hypervisors, versions of hypervisors, etc | |
| 21:25:37 | efried | I guess the compute service comes up and detects the topology and reports it back to the scheduler or puts it in the database or something. | |
| 21:25:42 | dansmith | efried: they expose a generalized model | |
| 21:34:04 | efried | dansmith: thanks. I posted answers to your comments on the providers.yaml spec. LMK if you want to discuss (since Dakshina doesn't really seem to do IRC ): | |
| 21:34:25 | dansmith | ack, it'll be tomorrow | |
| 21:34:42 | efried | thanks | |
| 23:30:04 | openstackgerrit | Merged openstack/python-novaclient master: Add Python 3 Train unit tests https://review.opendev.org/669439 | |
| #openstack-nova - 2019-07-18 | |||
| 00:26:59 | openstackgerrit | Artom Lifshitz proposed openstack/nova master: [WIP-until-series-is-ready] Introduce live_migration_claim() https://review.opendev.org/635669 | |
| 00:27:00 | openstackgerrit | Artom Lifshitz proposed openstack/nova master: New objects for NUMA live migration https://review.opendev.org/634827 | |
| 00:27:00 | openstackgerrit | Artom Lifshitz proposed openstack/nova master: LM: add support for sending NUMAMigrateData to the source https://review.opendev.org/634828 | |
| 00:27:01 | openstackgerrit | Artom Lifshitz proposed openstack/nova master: LM: add support for updating NUMA-related XML on the source https://review.opendev.org/635229 | |
| 00:27:01 | openstackgerrit | Artom Lifshitz proposed openstack/nova master: RPC changes to prepare for NUMA live migration https://review.opendev.org/634605 | |
| 00:27:02 | openstackgerrit | Artom Lifshitz proposed openstack/nova master: NUMA live migration support https://review.opendev.org/634606 | |
| 00:27:03 | openstackgerrit | Artom Lifshitz proposed openstack/nova master: Deprecate CONF.workarounds.enable_numa_live_migration https://review.opendev.org/640021 | |
| 03:23:51 | openstackgerrit | Alex Xu proposed openstack/nova master: [WIP] Populate the existing mediated devices in the libvirt device manager https://review.opendev.org/670787 | |
| 03:23:51 | openstackgerrit | Alex Xu proposed openstack/nova master: [WIP] Using the claim/unclaim_for_instance for mdevs https://review.opendev.org/671222 | |
| 03:23:52 | openstackgerrit | Alex Xu proposed openstack/nova master: Add DeviceManager to the libvirt virt driver https://review.opendev.org/671388 | |
| 05:20:30 | openstackgerrit | Alex Xu proposed openstack/nova master: Populates the existing mediated devices in the libvirt device manager https://review.opendev.org/670787 | |
| 05:20:31 | openstackgerrit | Alex Xu proposed openstack/nova master: Using the claim/unclaim_for_instance for mdevs https://review.opendev.org/671222 | |
| 05:20:31 | openstackgerrit | Alex Xu proposed openstack/nova master: Adds functional test for creating the instance with vgpus https://review.opendev.org/671398 | |
| 05:22:09 | alex_xu | bauzas: ^ need your review on those patches, I move the mdev into the new claim_for_instance interface | |
| 06:30:50 | openstackgerrit | Alex Xu proposed openstack/nova master: Add DeviceManager to the libvirt virt driver https://review.opendev.org/671388 | |
| 06:30:51 | openstackgerrit | Alex Xu proposed openstack/nova master: Populates the existing mediated devices in the libvirt device manager https://review.opendev.org/670787 | |
| 06:30:51 | openstackgerrit | Alex Xu proposed openstack/nova master: Using the claim/unclaim_for_instance for mdevs https://review.opendev.org/671222 | |
| 06:30:52 | openstackgerrit | Alex Xu proposed openstack/nova master: Adds functional test for creating the instance with vgpus https://review.opendev.org/671398 | |
| 06:46:55 | openstackgerrit | Yongli He proposed openstack/python-novaclient master: Microversion 2.75 - show server topology https://review.opendev.org/670790 | |
| 07:43:36 | openstackgerrit | Dakshina Ilangovan proposed openstack/nova-specs master: Spec: Provider config YAML file https://review.opendev.org/612497 | |
| 08:22:07 | stephenfin | efried: Correct. We're doing that already and we've decided it's not an issue since operators should already have separate hosts for pinned and non-pinned instances | |
| 08:23:33 | stephenfin | efried: and if they don't, they get pretty much what they had before, even if placement inventory will be kind of a lie | |
| 08:27:12 | cdent | lying is bad, mmmkay? | |
| 08:44:49 | openstackgerrit | QingFeng Hao proposed openstack/nova master: Add get_host_memory_stats in zvm driver https://review.opendev.org/671430 | |
| 08:48:46 | gibi | sean-k-mooney: left comments in https://review.opendev.org/#/c/671338 overall direction looks good to me | |
| 08:53:12 | sean-k-mooney | gibi: thanks, ya the unit test failures are valid i ran them locally with a regex of things i tought might break but i obviously missed some | |
| 09:26:35 | openstackgerrit | Stephen Finucane proposed openstack/nova master: tox: Keeping going with docs https://review.opendev.org/670332 | |
| 09:26:52 | kashyap | Heya, a random question: what else tooling do people use besides `git-review` to make life pleasant with Gerrit? | |
| 09:27:25 | kashyap | (I'm asking because, I'm providing a data point for those who are mailing lists, and are considering web-based workflows, GitLab/GitHub; not Gerrit at this point) | |
| 09:27:45 | kashyap | I think `gertty` would be another for those who like the offline caching and terminal-based reviews | |
| 09:29:44 | sean-k-mooney | its mainly git review for me. with web for review. i strongly dislike mailing list based workflows to the point that unless that project also has patchwork i almost entirly avoid them | |
| 09:29:59 | sean-k-mooney | at least when it comes to code reviews | |
| 09:30:06 | sean-k-mooney | gertty if fine for reviewing | |
| 09:30:35 | sean-k-mooney | but its offline asspect comes at the cost that it needs to build up an sql database of the open changes | |
| 09:30:45 | sean-k-mooney | that can be slow with large repos like nova | |
| 09:31:15 | gibi | efried: I added comments to https://review.opendev.org/#/c/612497 | |
| 09:31:39 | kashyap | I maintain Gertty in Fedora, FWIW, because I enjoy the offline ability. And the DB build-up is a negligible cost | |
| 09:31:50 | kashyap | sean-k-mooney: It's not SQL; but Berkely | |
| 09:32:07 | sean-k-mooney | kashyap: no is sqlight3 | |
| 09:32:11 | kashyap | Ah, right | |
| 09:32:13 | kashyap | Sorry | |
| 09:33:52 | sean-k-mooney | there are allo tools like https://github.com/openstack-infra/git-restack or https://github.com/dhellmann/git-nit | |
| 09:34:28 | kashyap | sean-k-mooney: Thanks; /me checks | |
| 09:34:56 | sean-k-mooney | kashyap: personally i find mailing list much slower and harder to follow since you have to constuct all that tooling yourself | |
| 09:34:58 | kashyap | Ah, didn't know of them | |
| 09:35:40 | sean-k-mooney | git restack is old and not really uses much i think | |
| 09:36:31 | sean-k-mooney | personally i found doing a interactive rebase manullay to the same base commit was just as quick | |
| 09:36:59 | kashyap | sean-k-mooney: Nod. (But the kernel and other systems folks still maintain mailing lists are the "best way" to manage large projects as kernel: https://lwn.net/Articles/702177/) | |
| 09:37:12 | kashyap | sean-k-mooney: Okay, thanks for the opinion and notes :-) | |
| 09:39:59 | bauzas | alex_xu: ack, will look | |
| 09:40:08 | alex_xu | bauzas: thanks | |
| 09:42:43 | bauzas | alex_xu: wow, that's a massive refactoring, I'll do this this afternoon | |
| 09:42:48 | bauzas | thanks for it | |
| 09:43:06 | bauzas | alex_xu: FWIW, I'm also working on https://review.opendev.org/#/c/589085/ | |
| 09:43:59 | alex_xu | bauzas: I guess it should works with your patch also, and you get the vgpu claim for dst host | |
| 09:44:23 | bauzas | alex_xu: that's why I need to look at your series to exactly understand how it works | |
| 09:46:06 | bauzas | alex_xu: also, a nit, I wonder if we should have a specless bp for this | |
| 09:46:35 | alex_xu | bauzas: yea, probably we can ask efried about that | |
| 10:28:33 | openstackgerrit | Stephen Finucane proposed openstack/nova master: bindep: Remove dead markers https://review.opendev.org/671452 | |
| 10:30:25 | stephenfin | bauzas, alex_xu: Easiest +2 you'll ever have right here https://review.opendev.org/671452 | |
| 10:30:44 | bauzas | stephenfin: hands on deck | |
| 11:06:16 | kashyap | bauzas: Isn't it simple enough to just go ahead and +W it? | |
| 11:06:44 | kashyap | (It being the 'bindep' one) | |
| 11:06:48 | bauzas | no | |
| 11:07:08 | bauzas | fast-approval seems right, but honestly people could have concerns | |
| 11:08:11 | kashyap | If there _can_ be concerns, okay, fair enough. | |
| 11:08:20 | sean-k-mooney | kashyap: even if it was stephenfin wrote it so we shoul dnot have a redhat core +2+w without someone else looking at it | |
| 11:08:58 | kashyap | Well, not that asinine reason again. There are sensible exceptions | |
| 11:09:10 | sean-k-mooney | kashyap: yep this is not one of them | |
| 11:09:22 | kashyap | On that point, see my extended point here: http://lists.openstack.org/pipermail/openstack-discuss/2019-May/006080.html | |
| 11:09:28 | kashyap | sean-k-mooney: Okay. | |
| 11:09:49 | kashyap | I don't care about this change particularly, BTW. Just the simplicity of it is what prompted me to say it. | |
| 11:18:29 | cdent | kashyap++ and *hugs* | |
| 11:18:47 | kashyap | :-) | |
| 11:22:05 | kashyap | sean-k-mooney: For argument's sake, why is this not one of them? Precise is even EOL | |
| 11:22:34 | kashyap | This is definitely one of those dead-simple changes that doesn't require an completely unhinged process to interfere | |
| 11:22:43 | kashyap | Anyway, not my circus, not my clowns. | |
| 11:23:31 | kashyap | s/"an completely"/"a completely"/ | |
| 11:27:55 | sean-k-mooney | ignoring the same company aspect. one out of curtusy to other disto maintainer we shoudl not fast merge thing related to our competitor distro without any external reveiew, second we only use singel +2 in very limited cases like when you would have been the second +2 but you fix a minor nit in someone esle pathc or rebased a patch that went int merge confcit and you are proxing a previous +2 from a | |
| 11:27:57 | sean-k-mooney | core, third its not urgent, i.e. there is no bug associated wthi this stepen jsut noticed it and its not blocking the gate. put that to gether with the same company core thing and even though its trivial and it looks correct i dont think this has a stong case for bypassing our standard policy | |
| 11:29:35 | kashyap | Sure, it is not about "urgency", but needless, grinding processes coming in the way. Also on courtesy, who says it is being incourteous? Assume good intent. | |
| 11:30:00 | kashyap | gibi: :-) I was just "thinking (or arguing) out loud". | |
| 11:31:02 | sean-k-mooney | i am assuming good intent but i would assume you would like to see change to fedora requirement before they merged if i was droping support for a fedora version | |
| 11:31:18 | kashyap | For an EOL release? I don't give a damn | |
| 11:31:48 | sean-k-mooney | anyway thanks gibi :) | |
| 11:32:18 | gibi | we an always revert such patches :) | |
| 11:32:23 | gibi | we can | |
| 11:32:26 | kashyap | Yes, exactly. | |