| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-12-03 | |||
| 18:26:55 | eandersson | I mean we have a super custom way of deploying, plus probably 20 custom nova patches at least | |
| 18:27:02 | sean-k-mooney | this is not the first time i have heard this requrest however | |
| 18:27:17 | eandersson | So it's not a big deal, but would be a lot easier for us to manage it if it was pluggable | |
| 18:27:27 | dansmith | scheduler filters *are* pluggable | |
| 18:27:35 | sean-k-mooney | eandersson: as are the weighers | |
| 18:27:36 | dansmith | presumably you're dependent on other changes/ | |
| 18:27:46 | eandersson | They are? | |
| 18:27:50 | sean-k-mooney | yep | |
| 18:28:00 | sean-k-mooney | but its non ovious how to do it | |
| 18:28:09 | dansmith | it's very obvious | |
| 18:28:20 | dansmith | it may not be _documented_ :) | |
| 18:28:34 | eandersson | btw we also have weights for upgrading computes (e.g. a compute that needs a OS upgrade would be moved into an aggregate to reduce the changes of it getting scheduled to) | |
| 18:28:48 | dansmith | https://docs.openstack.org/nova/latest/user/filter-scheduler.html#writing-your-own-filter | |
| 18:29:00 | sean-k-mooney | eandersson: here is an example https://opendev.org/x/nfv-filters | |
| 18:30:15 | eandersson | Ah yea I see | |
| 18:31:08 | sean-k-mooney | you just do filter_scheduler.available_filters=nova.scheduler.filters.all_filters,nfv_filters.nova.scheduler.filters.aggregate_instance_type_filter | |
| 18:31:15 | openstackgerrit | Stephen Finucane proposed openstack/nova master: nova-net: Kill it https://review.opendev.org/696518 | |
| 18:31:15 | openstackgerrit | Stephen Finucane proposed openstack/nova master: Rename 'nova.network.neutronv2' -> 'nova.network' https://review.opendev.org/696745 | |
| 18:31:16 | openstackgerrit | Stephen Finucane proposed openstack/nova master: Rename 'nova.network.security_group.neutron_driver' -> 'nova.network.security_group' https://review.opendev.org/696746 | |
| 18:31:17 | openstackgerrit | Stephen Finucane proposed openstack/nova master: Remove unnecessary 'neutronv2' prefixes https://review.opendev.org/696776 | |
| 18:31:17 | openstackgerrit | Stephen Finucane proposed openstack/nova master: nova-net: Remove unused exceptions https://review.opendev.org/697149 | |
| 18:31:17 | openstackgerrit | Stephen Finucane proposed openstack/nova master: nova-net: Remove db methods for ProviderMethod https://review.opendev.org/697150 | |
| 18:31:18 | openstackgerrit | Stephen Finucane proposed openstack/nova master: nova-net: Remove unused 'stub_out_db_network_api' https://review.opendev.org/697151 | |
| 18:31:18 | openstackgerrit | Stephen Finucane proposed openstack/nova master: nova-net: Remove remaining nova-network quotas https://review.opendev.org/697152 | |
| 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 | |