Earlier  
Posted Nick Remark
#openstack-nova - 2019-07-17
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.
11:32:34 kashyap The "revert" hammer is always near by :D
11:32:49 sean-k-mooney keep it away from artom for a while
11:32:55 kashyap Haha
11:38:36 openstackgerrit Surya Seetharaman proposed openstack/nova master: API microversion 2.75: Add 'power-update' external event https://review.opendev.org/645611

Earlier   Later