Earlier  
Posted Nick Remark
#openstack-nova - 2019-05-22
15:26:49 stephenfin That's a good point
15:27:02 efried alas, I sense I have sold you on this idea
15:27:08 efried okay, I'll go make it so.
15:27:45 stephenfin Think I've fixed up the issues with the one non-WIP patch that was failing [1] too, so they should all be good to go now [1] https://review.opendev.org/#/c/651311/
15:28:07 stephenfin It took me too long but it should make mriedem happy (it resolves one of his todo's in the process)
15:31:50 mriedem or just separately in the series?
15:31:50 mriedem stephenfin: hmm, you're talking about https://review.opendev.org/#/c/651311/3/nova/compute/manager.py right? would it be possible for us to do that refactor outside of the cells v1 removal series?
15:33:00 stephenfin I was afraid you'd say that
15:33:13 openstackgerrit John Garbutt proposed openstack/nova-specs master: Add Unified Limits Spec https://review.opendev.org/602201
15:34:31 stephenfin bauzas: https://redhat.bluejeans.com/2519408175/
15:34:53 bauzas wrong chan, dude
15:38:00 openstackgerrit Arnaud Morin proposed openstack/nova master: Force refresh instance network info on deletion https://review.opendev.org/660761
15:42:18 openstackgerrit Matt Riedemann proposed openstack/nova master: WIP: libvirt: dump console log if _clean_shutdown fails https://review.opendev.org/660766
16:22:17 openstackgerrit Stephen Finucane proposed openstack/nova master: Stop passing 'kwargs' to 'rebuild_instance' https://review.opendev.org/651312
16:22:17 openstackgerrit Stephen Finucane proposed openstack/nova master: Remove cells v1 parameter from 'ComputeTaskAPI.resize_instance' https://review.opendev.org/651311
16:22:18 openstackgerrit Stephen Finucane proposed openstack/nova master: filters: Stop handling cells v1 https://review.opendev.org/651314
16:22:18 openstackgerrit Stephen Finucane proposed openstack/nova master: Stop passing 'delete_type' to 'terminate_instance' https://review.opendev.org/651313
16:22:19 openstackgerrit Stephen Finucane proposed openstack/nova master: Remove 'ComputeManager._reschedule' https://review.opendev.org/660774
16:28:58 mriedem kaisers: would it be possible to remove the feature parts of this backport? https://review.opendev.org/#/c/660706/
16:31:22 mriedem kaisers: https://review.opendev.org/#/c/660705/ also mixes in stuff that should have just been master-only IMO, i.e. the privsep conversion
16:47:20 openstackgerrit sean mooney proposed openstack/nova master: Run revert resize tests in nova-live-migration https://review.opendev.org/653498
16:47:21 openstackgerrit sean mooney proposed openstack/nova master: [DNM] use iptables in nova-multinode https://review.opendev.org/660782
16:48:15 sean-k-mooney ^ is just a repoducer so you can ignore it
16:51:27 stephenfin mriedem: Split out that patch too, fwiw https://review.opendev.org/#/c/660774/
16:51:56 mriedem thanks
16:59:09 mriedem bauzas: dansmith: melwitt: can one of you hit this stein backport? https://review.opendev.org/#/c/660370/
16:59:41 dansmith jes
16:59:54 dansmith I'm probably due to go through backports
17:01:44 melwitt same
17:03:56 dansmith let me also say.. I really hate the use of partial in here, which seems to be a growing cancer lately
17:12:13 melwitt looks like it's mirroring what we were already doing with post_live_migration
17:14:07 dansmith the partials you mean? that's what I'm talking about yeah
17:14:32 melwitt yeah, the partial thing
17:19:01 dansmith oopsie, I approved that xen ssl thing for rocky before stein
17:22:52 dansmith mriedem: this seems like a bug of omission to me that affects support-ability and thus pretty reasonable for stable: https://review.opendev.org/#/c/657125/1
17:22:56 dansmith mriedem: do you really disagree?
18:03:26 mriedem i haven't dug into it much yet, it's big,
18:03:35 mriedem it's also an admin api so i'm less concerned about that
18:22:02 mriedem dansmith: ok +2 on that one now
18:32:53 openstackgerrit Matt Riedemann proposed openstack/nova stable/stein: Disable limit if affinity(anti)/same(different)host is requested https://review.opendev.org/659239
18:34:43 mriedem ^ should also be ready to go
18:35:06 mriedem once https://review.opendev.org/#/q/status:open+project:openstack/nova+branch:stable/stein+label:Code-Review=2 is merged i think we should do a stein release
18:49:10 dansmith mriedem: thanks
19:54:22 sean-k-mooney dansmith: for what its worth that bug only happens in a specifci edge casse.
19:55:34 sean-k-mooney dansmith: basically it only happens if the kernel/nic diriver is configred such that it does not bind the VF to the network driver after its detached from the gues or when you pre bind the vfs to vvfio
19:56:31 sean-k-mooney so in some case it would work by acident because libvirt would auto add the missing element and in other cases it would fail which was a crapy operator experience
20:12:57 mriedem ganso: melwitt: replied in https://review.opendev.org/#/c/659338/
20:14:04 melwitt thanks
20:27:39 openstackgerrit Merged openstack/nova stable/stein: Reproduce bug #1819460 in functional test https://review.opendev.org/657600
20:27:40 openstack bug 1819460 in OpenStack Compute (nova) stein "instance stuck in BUILD state due to unhandled exceptions in conductor" [Medium,In progress] https://launchpad.net/bugs/1819460 - Assigned to Balazs Gibizer (balazs-gibizer)
20:30:02 openstackgerrit Merged openstack/nova stable/stein: Fix exception type in test_boot_reschedule_fill_provider_mapping_raises https://review.opendev.org/657601
20:31:47 mriedem melwitt: thanks but https://review.opendev.org/#/c/659338/ isn't a backport so you might want to drop the +W
20:35:58 melwitt mriedem: oh :( ok
20:38:22 melwitt mriedem: I think I need to change the commit message or something to stop it from going to the gate. I can add [stable-only] to it
20:46:03 openstackgerrit Matt Riedemann proposed openstack/nova stable/rocky: [stable-only] Delete allocations even if _confirm_resize raises (part 2) https://review.opendev.org/659338
20:46:11 openstackgerrit Matt Riedemann proposed openstack/nova stable/rocky: Add functional confirm_migration_error test https://review.opendev.org/658834
20:46:13 mriedem done
20:47:26 melwitt thank you
20:51:20 ganso mriedem: thank you =D
20:56:44 openstackgerrit Matt Riedemann proposed openstack/nova master: Update description of valid whitelist for non-admin user https://review.opendev.org/642403
21:01:55 sean-k-mooney having ssh exposed on a static ip is always fun
21:02:18 openstackgerrit Matt Riedemann proposed openstack/nova master: Skip existing VMs when hosts apply force_config_drive https://review.opendev.org/659703
21:02:56 sean-k-mooney i have 4 ip currently trying to brute force my root password. which will be hard since i dont allow password loggin as root
21:04:14 mriedem efried: on the virtual persistent memory spec https://review.opendev.org/#/c/601596/ and cyborg integration spec https://review.opendev.org/#/c/603955/ i'm waiting to see those settle down from the people that have been most involved, but is there light at the end of the tunnel at some point?
21:04:34 efried mriedem: I hope so. What do you mean?
21:04:54 mriedem every time i look at these there are multiple -1s
21:04:59 mriedem for like, months
21:05:14 mriedem i guess i'm saying feel free to ping me to review those when they settle down
21:05:23 efried mriedem: ah, cool, thanks.
21:05:24 mriedem but until them i'm not wanting to jump into reviewing them
21:05:30 mriedem *then
21:05:31 efried yeah, understood.
21:06:00 efried for my part, I'm waiting until you're done tearing the host/hypervisor_hostname spec apart before I re-engage :)
21:09:45 sean-k-mooney mriedem: efried i dont think there is much curn on the cyborg one at this point but sundar also has not updated it in two weeks so that is why most of the -1s are still there
21:10:21 efried Right, I think that one is pretty close, updates still trickling down from PTG discussions.
21:10:33 mriedem efried: this? https://review.opendev.org/#/c/660560/
21:11:01 efried mriedem: no, https://review.opendev.org/#/c/660560/3
21:11:11 mriedem i'm just adding it to the nova meeting agenda for a stuck review, i see boxiang is getting some back and forth
21:11:22 mriedem that's the same change :)
21:11:43 mriedem seems the debate is if we should validate the requested host/node in the api and fail fast or fail late in the scheduler with novalidhost
21:11:57 efried thought the whole point of the exercise was to fail early.
21:11:59 mriedem i think unless it's egregious we generally want to validate and fail fast in the api if possible
21:12:20 mriedem the whole point of the spec is to request a host and/or node and have the scheduler filters validate it
21:12:22 mriedem rather than force it through
21:12:31 mriedem which is what we have today (unless you're using the little known query hint)
21:13:09 mriedem anyway, i've said on the code change to take it to the ML or meeting agenda to sort it out with more than 2 people invovled
21:14:19 mriedem if we could throw a generic RequestGroup with the in_tree attribute set in the request spec from the api then the redundancy in the scheduler would be avoided
21:14:21 mriedem but that gets complicated
21:14:48 sean-k-mooney i have not read that one but if we are specifying the host or hypervior host name i assume we would be passing intree to placement and failing in teh scudler if we get no allocation candiates or the filters eliminate the host?
21:14:54 efried Right, I thought we wanted the scheduler filter validation so we would know earlier whether the guest was viable for the host. Rather than "forcing" it to a host it couldn't work on so it would fail late (or worse, pretend to succeed but really be borked)
21:15:13 mriedem efried: that is true
21:15:33 mriedem the debate is if that is good enough or if we should also validate that the requested host/node exist in the API so we can return a 400 if they don't
21:15:42 efried dahhh
21:15:47 mriedem b/c if you don't validate in the api, and they don't exist, you'll get a 202 and then NoValidHost later
21:15:50 mriedem which everyone loves
21:16:03 sean-k-mooney efried: well the current way to force the host is via the AZ e.g. --availability-zone nova:my_host
21:16:20 efried oh, "in the API" meaning before we get to the scheduler
21:16:37 efried f, I don't see why not. How expensive is that check?
21:17:20 sean-k-mooney is it just checkign the api db to see if there is a host mapping for the requested host?
21:17:25 sean-k-mooney if so then cheap

Earlier   Later