| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-05-22 | |||
| 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 | |
| 21:19:07 | sean-k-mooney | honestly i dont think there is any issue with it failing when it gets to the schduler either | |
| 21:19:17 | mriedem | no it's not doing that, | |
| 21:19:32 | mriedem | just commented on that in the api validatoin code, it won't work as written | |
| 21:20:21 | sean-k-mooney | https://review.opendev.org/#/c/645520/20 is the code change ? | |
| 21:20:28 | mriedem | surya already pointed out the same thing i just did | |
| 21:20:32 | mriedem | sean-k-mooney: yes | |
| 21:20:40 | mriedem | if you request a host, we can look up the host mapping | |
| 21:20:47 | mriedem | if you request only a node, then we have to iterate the cells looking for it | |
| 21:20:58 | mriedem | or let the scheduler do that | |
| 21:21:01 | mriedem | since it already is | |
| 21:21:11 | sean-k-mooney | i would let the schduler do it personally | |
| 21:21:56 | sean-k-mooney | is there a reason not to use in_tree in the placement request as well? | |
| 21:22:34 | mriedem | the scheduler code will use in_tree already | |
| 21:23:13 | mriedem | but it will do the same compute node lookup to find the node uuid | |
| 21:23:33 | mriedem | the RequestSpec.requested_destination currently only has the host and nodename, not the uuid | |
| 21:23:54 | sean-k-mooney | well it could look it up via placmenet i nthe hypervior_host name case | |
| 21:24:08 | sean-k-mooney | the compute node RP name is the hypervior host name i think | |