| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-12-13 | |||
| 17:11:22 | mriedem | melwitt: yes otherwise we could release things in pike/queens that are not yet released in rocky | |
| 17:11:31 | mriedem | generally need to snowball these from newest to oldest branch | |
| 17:11:44 | melwitt | good point, I should have thought of that. thanks | |
| 17:12:07 | openstackgerrit | Merged openstack/nova stable/rocky: Handle tags in _bury_in_cell0 https://review.openstack.org/624813 | |
| 17:14:31 | openstackgerrit | Matt Riedemann proposed openstack/nova stable/queens: Make compute rpcapi version calculation check all cells https://review.openstack.org/625060 | |
| 17:35:59 | openstackgerrit | melanie witt proposed openstack/nova master: Propagate exception message from _prep_block_device https://review.openstack.org/624832 | |
| 17:35:59 | openstackgerrit | melanie witt proposed openstack/nova master: Add method to generate device names universally https://review.openstack.org/573066 | |
| 17:35:59 | openstackgerrit | melanie witt proposed openstack/nova master: WIP Add configuration of maximum disk devices to attach https://review.openstack.org/616777 | |
| 17:40:47 | colby_ | Hey Eveyrone. We just upgraded to queeens. Im seeing some weird issues when creating an instance from an already created volume. Im seeing this error: | |
| 17:40:47 | colby_ | Build of instance aborted: Nova does not support Cinder API version 2. The catalog is set to use v3 cinder as default, and in the nova config we have this set for cinder: catalog_info=volumev3:cinderv3:internalURL | |
| 17:41:06 | colby_ | we have a volumev3 in the catalog as well that points to the v3 api | |
| 17:55:20 | melwitt | colby_: is it possible you have [cinder]endpoint_template set, which will override catalog_info? | |
| 18:01:55 | cezary_zukowski | Hey, how to simulate/mimic a network disruption occuring between a Nova instance/server and Cinder (volume/storage)? Does detaching a volume from instance manually would be a sensible approach/substitute? | |
| 18:01:57 | mriedem | that would be my guess, endpoint_template is set | |
| 18:02:20 | cezary_zukowski | Command for detaching: nova volume-detach <instance_id> <volume_id> | |
| 18:02:48 | cezary_zukowski | mriedem: What do you mean? | |
| 18:03:38 | colby_ | melwitt: no its not set in the config anywhere | |
| 18:03:46 | mriedem | cezary_zukowski: was answering a different question | |
| 18:03:56 | cezary_zukowski | mriedem: ah, right | |
| 18:04:29 | mriedem | colby_: do you have this? https://github.com/openstack/nova/commit/c7d87f6691bbc39daca918729b769cc2d2000abd | |
| 18:04:45 | mriedem | that's in 17.0.6 | |
| 18:04:50 | mriedem | if you're queens ga you wouldn't have that | |
| 18:05:13 | mriedem | not sure if that's your problem though | |
| 18:17:42 | melwitt | colby_: aside from all of that, I would just take a look at your keystone catalog again and double check there's no /v2.0 for nova (should be /v2.1) and no /v2 for cinder | |
| 18:18:33 | melwitt | because the only other thing I see the code doing to determine the cinder version is parsing the version from the endpoint found in the catalog | |
| 18:18:45 | colby_ | oh it has the wrong config on the actual compute nodes. Thanks that helped me narrow it down. Ill switch that config there. Apparently it just got switched on the controller services | |
| 18:20:14 | melwitt | ok, cool | |
| 18:45:35 | mpiwowarczy | hello | |
| 18:46:36 | mpiwowarczy | can I have a question to nova deprecated personality parameter? | |
| 18:47:14 | mpiwowarczy | seems it will be removed in microversion 2.57 | |
| 18:47:42 | mpiwowarczy | but can not found when 2.57 will be used? | |
| 18:47:55 | mpiwowarczy | for Rocky release it was microversion 2.27 | |
| 18:48:06 | mpiwowarczy | which version will be used in Stein? | |
| 18:49:01 | mpiwowarczy | or is there any fixed date when 2.57 version will be dropped? | |
| 18:54:22 | artom | mpiwowarczy, microversions are never dropped, we still support 2.1 if the client asks for it | |
| 18:54:34 | artom | mpiwowarczy, in terms of releases, have a look at https://docs.openstack.org/nova/latest/reference/api-microversion-history.html | |
| 18:56:49 | mpiwowarczy | artom: thanks for the answer | |
| 18:56:56 | mpiwowarczy | so when personality files (files injection) feature will be dropped? | |
| 18:58:11 | mpiwowarczy | will be this supported in Stein release? | |
| 19:01:35 | artom | mpiwowarczy, it'll never be dropped per se | |
| 19:02:05 | artom | mpiwowarczy, you can keep using it in Stein if the client asks for a microversion < 2.57 | |
| 19:03:49 | mpiwowarczy | ok, thanks for your help | |
| 19:07:37 | melwitt | mpiwowarczy: it's dropped in a sense that if/when you find yourself needing to request microversion >= 2.57 when you call the REST API to get a different feature/addition, you will not be able to use personality files at the same time/in the same call | |
| 19:08:40 | mpiwowarczy | melwitt: I see | |
| 19:10:15 | mpiwowarczy | do you intend to maintain all versions, starting from 2.1, in all future OpenStack releases? | |
| 19:11:22 | mpiwowarczy | day by day it is more difficult to maintain :) | |
| 19:18:33 | mriedem | what is more difficult to maintain? writing apps against the API? or maintaining the various microversions in the API? | |
| 19:18:54 | mriedem | the client opts into the behavior, so if you are ok with v2.1 then you don't need to ever change that | |
| 19:20:01 | mpiwowarczy | oh yeah, you're right | |
| 19:20:49 | mpiwowarczy | just one more question - latest novaclient 11.1.0, which microversion it uses? | |
| 19:20:59 | mriedem | the alternative is we don't use microversions, change the api from release to release, and all client software everywhere in the world has to deal with that based on the cloud they are talking to | |
| 19:21:00 | mpiwowarczy | where I can check that? | |
| 19:21:27 | mriedem | the client-side support is defined here https://github.com/openstack/python-novaclient/blob/master/novaclient/__init__.py#L28 | |
| 19:21:35 | mriedem | novaclient python APIs by default use 2.1 | |
| 19:21:51 | mriedem | the CLI by default negotiates the highest supported microversion between the client and the server | |
| 19:22:24 | mriedem | so if you're using novaclient as a python sdk, then it's opt-in, | |
| 19:22:37 | mriedem | if you're using the CLI, it's negotiated unless you tell it otherwise | |
| 19:23:09 | mpiwowarczy | it is about SDK | |
| 19:23:14 | mriedem | then it's opt-in | |
| 19:23:27 | mpiwowarczy | we have defined version python-novaclient==11.1.0 and we use file injection | |
| 19:23:32 | mriedem | api methods in novaclient are wrapped / bound based on what versions they support | |
| 19:23:49 | mriedem | as i said, unless you opt into a newer microversion, it will use 2.1 | |
| 19:23:51 | mriedem | for the sdk | |
| 19:23:55 | openstackgerrit | Merged openstack/nova stable/rocky: Harden placement init under wsgi https://review.openstack.org/617297 | |
| 19:24:11 | mpiwowarczy | *python-novaclient>=9.1.0 # Apache-2.0 | |
| 19:25:05 | mpiwowarczy | thanks, you helped me a lot | |
| 19:25:32 | mriedem | yw | |
| 19:33:26 | melwitt | mriedem: do happen to know if we have the opposite of --availability-zone ZONE:HOST:NODE for admins where it would mean launch the server anywhere but this node? curious because I know in the request spec we have both force_hosts and ignore_hosts | |
| 19:33:50 | melwitt | I didn't think we did but not 100% sure | |
| 19:34:13 | mriedem | not from the api i don't think so | |
| 19:34:24 | mriedem | ignore_hosts is for when you're moving a server and you ignore the source host from schedluing | |
| 19:34:27 | cdent | i've had people ask about that too, and also couldn't find it | |
| 19:34:30 | mriedem | or ignore hosts you've rescheduled from | |
| 19:35:01 | melwitt | thanks. someone asked recently and I told them I think forbidden traits is the closest thing to something like that | |
| 19:35:21 | mriedem | well, | |
| 19:35:45 | mriedem | for that to work, you'd have to temporarily put a custom trait on the blacklisted host, schedule to !host via forbidden trait, and then remove the trait | |
| 19:36:03 | mriedem | if you're going to do that, you might as well just disable the compute service and then re-enable it after the scheduling is done | |
| 19:36:11 | mriedem | b/c the ComputeFilter essentially does the same thing | |
| 19:36:19 | mriedem | unless you're cern and you drop the max placement results down to 10 | |
| 19:36:57 | melwitt | yeah, well I was thinking more general if there was an underlying reason to avoid that host, like there's special hardware there that you want to avoid taking up | |
| 19:37:26 | melwitt | but as a one shot thing if there's no other meaning to it, yeah, I agree disabling is easier | |
| 19:38:18 | mriedem | i believe tetsuro's forbidden aggregates spec goes into detail about that | |
| 19:38:20 | mriedem | for blazar | |
| 19:38:45 | mriedem | it is essentially the same problem, you have a special pool of resources that non-special requests can't have access to | |
| 19:39:18 | melwitt | yeah | |
| 20:09:16 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Remove GROUP BY clause from CellMapping.get_by_project_id https://review.openstack.org/619061 | |
| 20:09:17 | mriedem | zzzeek: i did that subquery and it works ^ thanks for the tip there | |
| 20:09:45 | zzzeek | mriedem: that's great. keep pinging me for thse so we can make the DB code better :) | |
| 21:15:45 | openstackgerrit | Jack Ding proposed openstack/nova master: Preserve UEFI NVRAM variable store https://review.openstack.org/621646 | |
| 22:11:05 | openstackgerrit | Merged openstack/python-novaclient master: Fix flavor keyerror when nova boot vm https://review.openstack.org/582147 | |
| 22:11:05 | openstackgerrit | Merged openstack/python-novaclient stable/rocky: Improve the description of optional arguments https://review.openstack.org/602056 | |
| 22:15:43 | mriedem | melwitt: you want to just fast approve this backport https://review.openstack.org/#/c/623546/ for rocky and then we can queue up a rocky release with a couple of depends on | |
| 22:15:53 | mriedem | the only other one i'm watching is https://review.openstack.org/#/c/623507/ | |
| 22:17:57 | melwitt | ok. depends-on being this one I'd think? https://review.openstack.org/624982 | |
| 22:18:31 | openstackgerrit | Merged openstack/nova master: Use external placement in functional tests https://review.openstack.org/617941 | |
| 22:37:03 | mriedem | melwitt: i would like to let that bake a bit | |
| 22:37:12 | melwitt | k | |
| 22:37:15 | mriedem | dan and i were talking about something in there as an unexpected side effect this morning | |
| 22:37:17 | mriedem | hence the depends-on | |
| 22:37:47 | mriedem | so just the docs change and lee's backport | |