| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-12-03 | |||
| 18:31:19 | openstackgerrit | Stephen Finucane proposed openstack/nova master: nova-net: Remove use of legacy 'FloatingIP' object https://review.opendev.org/697153 | |
| 18:31:19 | openstackgerrit | Stephen Finucane proposed openstack/nova master: nova-net: Remove use of legacy 'Network' object https://review.opendev.org/697154 | |
| 18:31:20 | openstackgerrit | Stephen Finucane proposed openstack/nova master: nova-net: Remove use of legacy 'SecurityGroup' object https://review.opendev.org/697155 | |
| 18:31:20 | openstackgerrit | Stephen Finucane proposed openstack/nova master: nova-net: Remove unused nova-network objects https://review.opendev.org/697156 | |
| 18:32:07 | sean-k-mooney | you can similary have out of tree weighers that you can load in a similar way | |
| 18:34:19 | sean-k-mooney | dansmith: by the way this is actully a lot simpler then i rememeberd i was thinking of out of tree virt drivers which require you to reopen the nova namespace and do other things to make them work | |
| 18:34:39 | sean-k-mooney | dansmith: be we dont really want that to be plugablle in the same way so it makes sense that is more work | |
| 18:34:54 | dansmith | yup | |
| 18:49:33 | artom | Do we not reset the old flavor back on the instance if we fail a resize? Fail as in, something goes wrong during _prep_resize or resize_instance | |
| 18:49:51 | efried | gosh, I would hope we do | |
| 18:50:19 | artom | I can't find it - maybe I'm looking in the wrong place... | |
| 18:50:24 | artom | I mean, we must | |
| 18:50:38 | sean-k-mooney | in pre_resize i dont think we have saved the instace yet | |
| 18:51:22 | artom | Oh, is that how? | |
| 18:51:29 | sean-k-mooney | i have not looked at that in a while however. have we saved it since old_flavor was defined | |
| 18:51:30 | artom | We just don't persist until it's final | |
| 18:51:51 | sean-k-mooney | well we woudl presisti it before we go to resize verify | |
| 18:52:44 | sean-k-mooney | i would just check where it is saved first | |
| 18:53:02 | artom | That's what I'm looking for... | |
| 18:53:03 | dansmith | not just save, but save() after instance.flavor is set, unrelated to instance.old_flavor | |
| 18:55:32 | sean-k-mooney | i think this is where we revert it if we get to revert resize https://github.com/openstack/nova/blob/757fc03b78d542e7262343b65eacea02ce11dd04/nova/objects/instance.py#L1021-L1035 | |
| 18:55:44 | sean-k-mooney | but im not sure that is required if we fail early | |
| 18:58:21 | sean-k-mooney | this is where we update the instace i think https://github.com/openstack/nova/blob/757fc03b78d542e7262343b65eacea02ce11dd04/nova/compute/manager.py#L5260-L5292 | |
| 18:59:25 | sean-k-mooney | so assuming we call _prep_resize before _finish_resize if you fail in _prep_resize im not sure you need to do anything | |
| 19:00:28 | sean-k-mooney | artom: is that what you were looking for? | |
| 19:02:54 | artom | sean-k-mooney, I'm looking for where the request spec is reverted back to the old flavor | |
| 19:03:01 | artom | I said instance dind't I? | |
| 19:03:05 | artom | I meant request spec | |
| 19:03:49 | openstackgerrit | Matt Riedemann proposed openstack/nova master: WIP: Implement cleanup_instance_network_on_host for neutron API https://review.opendev.org/697162 | |
| 19:07:12 | dansmith | artom: compute can't reset the reqspec, so if it happens late enough, that won't happen | |
| 19:07:53 | dansmith | er, s/happens/fails/ | |
| 19:08:55 | dansmith | I think the only downside to that is if we do something that looks at the reqspec and not the instance, not sure what that would be | |
| 19:17:55 | artom | Sorry, was on a call | |
| 19:18:54 | artom | Context is https://review.opendev.org/#/c/662522/13 | |
| 19:19:56 | artom | So I guess scheduling looks at request spec | |
| 19:21:00 | eandersson | btw major annoyance at the moment is when instances get stuck in building | |
| 19:21:11 | eandersson | often you don't know which compute they are stuck buidling against | |
| 19:24:26 | mriedem | check the launched_on field on the instance - that wasn't cleaned up until recently | |
| 19:24:39 | mriedem | if instances are getting stuck in BUILD status somewhere when we failed, report a bug | |
| 19:25:41 | mriedem | like you did with bug 1837955 | |
| 19:25:41 | openstack | bug 1837955 in OpenStack Compute (nova) stein "MaxRetriesExceeded sometime fails with messaging exception" [Medium,Fix committed] https://launchpad.net/bugs/1837955 - Assigned to Matt Riedemann (mriedem) | |
| 19:26:51 | mriedem | efried: dustinc: what baremetal api version is used when we get a node's details now? https://github.com/openstack/nova/blob/master/nova/virt/ironic/driver.py#L226 | |
| 19:27:18 | mriedem | since we're not using the client_wrapper there i can't tell if it's 1.46 https://github.com/openstack/nova/blob/master/nova/virt/ironic/client_wrapper.py#L35 or something else | |
| 19:27:32 | efried | negotiated by sdk, no? | |
| 19:27:39 | dansmith | artom: so you mean a failed resize followed by a migration would use the new flavor as part of scheduling yeah? | |
| 19:27:41 | mriedem | based on the fields requested? | |
| 19:28:00 | efried | no, based on what's available | |
| 19:28:24 | efried | I think sdk does version discovery and uses the latest they mutually understand. mordred? | |
| 19:28:48 | mordred | uh | |
| 19:28:50 | mordred | reading | |
| 19:28:51 | dustinc | I don't know, I never had to deal with it so I _assume_ it is the most recent common version | |
| 19:29:26 | mriedem | is there a way to tell if the sdk will use 1.50+ to get the node.owner field? | |
| 19:29:52 | mriedem | ah yes | |
| 19:29:56 | mriedem | _max_microversion = '1.52' | |
| 19:29:57 | mordred | yes - that's right. it does discovery and gets the latest that sdk and the remote both understand | |
| 19:30:15 | mordred | so yeah - shuold be 1.50+ - assuming the ironic supports that | |
| 19:30:19 | mriedem | ah but the sdk node object doesn't have an explicit owner property so i'd have to add that | |
| 19:30:49 | mordred | yah. dtantsur|afk ^^ | |
| 19:30:51 | efried | mriedem: right -- the sdk is kind of supposed to abstract away "microversion" and instead let you think about "feature" -- in this case node.owner. | |
| 19:31:25 | mriedem | sure. i didn't know it hard-coded all of the properties though. | |
| 19:31:31 | efried | so if you want $feature at $microversion, sdk has to be plumbed to a) use $microversion, and b) expose $feature. Then nova has to require the release of sdk that does that, etc. | |
| 19:31:39 | efried | oh. Yeah :) | |
| 19:32:35 | mriedem | makes my little wip hackaroo i was going to do this afternoon not so simple, but anyway | |
| 19:32:36 | mriedem | thanks | |
| 19:33:09 | artom | dansmith, I think so | |
| 19:33:11 | dustinc | https://docs.openstack.org/openstacksdk/latest/user/microversions.html | |
| 19:33:11 | mordred | mriedem: one day we'll get to the point where people will add support for a thing to sdk when they add it to a service and life will be magical | |
| 19:33:19 | artom | (Sorry, got ADHD'ed away to another thing) | |
| 19:33:21 | mordred | we are not at that day today | |
| 19:33:37 | dansmith | artom: might be valid to refresh the reqspec from the instance before we go into an operation like that | |
| 19:34:08 | mriedem | mordred: and osc et al :) | |
| 19:34:45 | mriedem | efried: note the ..note:: rendering at the bottom of https://docs.openstack.org/openstacksdk/latest/user/microversions.html - tickles your rst ocd?! | |
| 19:35:12 | efried | aaaaaagh! | |
| 19:36:35 | artom | Hey, so I'm backporting https://review.opendev.org/#/c/619953/10/nova/conf/libvirt.py@719 internally | |
| 19:36:42 | artom | And wondering about changing the default to 'unique' | |
| 19:36:44 | efried | mordred: mriedem: https://review.opendev.org/697168 | |
| 19:36:52 | efried | ...and, you suck. | |
| 19:37:03 | artom | Can't imagine Windows would appreciate its sysinfo_serial changing under it | |
| 19:37:52 | artom | Am I just being paranoid about this? mriedem, dansmith, ^^ you guys are the approvers do you recall talking about this at all? | |
| 19:38:21 | mordred | efried: +A | |
| 19:40:14 | eandersson | mriedem I think there are at least a handful of bugs causing it for us | |
| 19:40:23 | eandersson | difficult to get a handle on the causes | |
| 19:41:26 | mriedem | artom: backporting features huh | |
| 19:41:39 | artom | mriedem, only backportable ones | |
| 19:41:46 | mriedem | are you asking about the serial changing on an existing guest? | |
| 19:41:50 | artom | mriedem, yeah | |
| 19:42:02 | mriedem | so change the default to 'auto' like it was? | |
| 19:42:29 | artom | mriedem, well, not sure it makes sense to go back at this point | |
| 19:42:43 | mriedem | there was quite a bit of discussion around that blueprint, including being able to override the host config with image meta or flavors but that was dropped | |
| 19:42:50 | eandersson | btw launched_on is is always null | |
| 19:42:51 | artom | But... there's an impact, right? The default becomes 'unique', instance is hard-rebooted, boom, new serial | |
| 19:42:55 | artom | Linux is probably OK, but Windows... | |
| 19:43:46 | artom | So lyarwood just updated our proposed backport to not change the default | |
| 19:43:51 | artom | Do... do we need to do the same upstream? | |
| 19:43:57 | mriedem | there is an upgrade release note. i'd have to dig into all of the comments on that patch to determine if we changed the default later or not for good reason | |
| 19:44:10 | mriedem | that was released in stein | |
| 19:44:16 | mriedem | changing the default from 2 releases back would be weird | |
| 19:44:17 | artom | Right, so it's already out there | |
| 19:44:20 | artom | I know | |
| 19:45:07 | efried | mriedem: see gibi's comment at the bottom of https://review.opendev.org/#/c/696992/ -- is it possible the bw test was removed when you refactored to get rid of tempest-slow? | |