| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-06-13 | |||
| 19:48:08 | mriedem | openstack --version | |
| 19:48:08 | mriedem | ? | |
| 19:49:57 | jmlowe | X-OpenStack-Nova-API-Version: 2.15 is in the request, ran with debug | |
| 19:50:11 | jmlowe | that version was 3.15.0 | |
| 19:50:16 | mriedem | and you got a 400? | |
| 19:50:30 | jmlowe | yes | |
| 19:50:35 | mriedem | pike? | |
| 19:50:43 | jmlowe | yes | |
| 19:51:05 | jmlowe | nova 16.1.4 | |
| 19:52:45 | mriedem | this all looks fine to me https://github.com/openstack/nova/blob/stable/pike/nova/api/openstack/compute/server_groups.py#L151 | |
| 19:53:19 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Add trusted_image_certificates to REST API https://review.openstack.org/486204 | |
| 19:53:20 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Add notification support for trusted_certs https://review.openstack.org/563269 | |
| 19:53:21 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Add certificate validation docs https://review.openstack.org/560158 | |
| 19:53:22 | openstackgerrit | Matt Riedemann proposed openstack/nova master: WIP: Add trusted certs to feature support matrix docs https://review.openstack.org/574890 | |
| 19:53:23 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Remove max_size parameter from fake_libvirt_utils.fetch_*image methods https://review.openstack.org/574911 | |
| 19:53:26 | mriedem | bpoulos: melwitt: ^ | |
| 19:57:10 | mriedem | jmlowe: i'm stumped | |
| 19:58:44 | bpoulos | mriedem: thank you for making those updates! | |
| 20:00:39 | mriedem | mgagne: were you working a patch for bug 1776743? if not, i can start on that | |
| 20:00:40 | openstack | bug 1776743 in OpenStack Compute (nova) "Allocation healer should ignore deleted instances" [High,Triaged] https://launchpad.net/bugs/1776743 - Assigned to Matt Riedemann (mriedem) | |
| 20:02:41 | mgagne | mriedem: didn't start work yet. but I found that you need to update filters at 2 places just so you know | |
| 20:03:27 | mriedem | mgagne: yup, the 2 places i pointed out? :P | |
| 20:03:51 | mgagne | only saw one? might be be that didn't read carefully as usual. | |
| 20:04:12 | mgagne | yea... just me being myself :-/ | |
| 20:05:44 | jmlowe | I'm looking for some way I may have restricted the max microversion | |
| 20:08:31 | jmlowe | Is there some way I may be stuck in v2 compatibility mode? | |
| 20:11:10 | melwitt | jmlowe: check the url in the service catalog (apologies if this has been said before in previous scrollback). it should end in /v2.1 | |
| 20:11:18 | mriedem | jmlowe: hmm, i wouldn't think so, were you hitting any microversions beyond 2.1 before pike? | |
| 20:11:30 | mriedem | might want to also check your api-paste.ini | |
| 20:11:41 | melwitt | I've seen people get stuck if they had an old url that ends in /v2.0, that would prevent you from ever getting any new microversions | |
| 20:11:51 | jmlowe | https://iu.jetstream-cloud.org:8774/v2/e0c43302e9a740a480d05381d20aa66e/os-server-groups | |
| 20:14:01 | jmlowe | hmm which probably comes from /v2/%(tenant_id)s | |
| 20:15:26 | melwitt | I think that v2 there is wrong, that will prevent you from getting microversions | |
| 20:15:39 | melwitt | it should be v2.1 | |
| 20:15:58 | jmlowe | yep, that endpoint dates all the way back to kilo probably | |
| 20:16:18 | jmlowe | and I now get my microversions | |
| 20:16:40 | melwitt | yeah, the folks at Oath ran into the same thing, upgrading from Juno, they had an old school url in the service catalog that they needed to update to v2.1 | |
| 20:17:24 | jmlowe | thanks melwitt and mriedem! | |
| 20:18:16 | mriedem | i was just wondering that too | |
| 20:18:21 | melwitt | we have a cells v2 faq but not a general faq | |
| 20:18:24 | mriedem | we don't really have faqs, only for cells v2 | |
| 20:18:45 | mriedem | it's likely already on ask.o.o but not sure how discoverable it would be since it's a really obscure problem | |
| 20:19:08 | mriedem | it wouldn't be asked as "microversions don't work", it would be, "operation foo" doesn't work | |
| 20:19:50 | melwitt | yeah, agreed | |
| 20:21:13 | mriedem | the endpoint creation here in the install guide is correctly v2.1 https://docs.openstack.org/nova/latest/install/controller-install-ubuntu.html | |
| 20:21:23 | mriedem | but there is/was nothing like that for upgrades from pre-microversions to microversions | |
| 20:21:30 | mriedem | lucky if anything was in the pre-reno release notes worki | |
| 20:21:32 | mriedem | *wiki | |
| 20:21:54 | mriedem | https://wiki.openstack.org/wiki/ReleaseNotes/Kilo#OpenStack_Compute_.28Nova.29 | |
| 20:22:39 | mriedem | sad trombone http://specs.openstack.org/openstack/nova-specs/specs/kilo/implemented/api-microversions.html#other-deployer-impact | |
| 20:23:13 | melwitt | yeah, was thinking similar if it was part of the upgrade reno when microversions came into existence | |
| 20:23:26 | melwitt | that's where we'd need to signal people ideally | |
| 20:24:18 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Don't heal allocations for deleted servers https://review.openstack.org/575222 | |
| 20:24:19 | mriedem | mgagne: thar she blar ^ | |
| 20:25:14 | mgagne | mriedem: lgtm | |
| 20:25:17 | dansmith | mriedem: so.. we could have stale allocations for deleted instances, right? | |
| 20:25:23 | mgagne | mriedem: I see potential with the filters variable | |
| 20:25:28 | dansmith | I guess compute will actually nuke those? | |
| 20:25:45 | mgagne | dansmith: afaik, the tool doesn't delete stalled allocations? | |
| 20:26:04 | dansmith | I'm just thinking | |
| 20:26:22 | dansmith | if it's in the db as deleted, compute will actually clean them up I think | |
| 20:26:23 | mgagne | next iteration of the tool =) | |
| 20:26:30 | dansmith | that's the only case it cleans up now, IIRC | |
| 20:27:17 | mgagne | which db is used to list instances? nova_api? | |
| 20:27:29 | dansmith | no, the cell | |
| 20:27:34 | dansmith | the instances only live there | |
| 20:27:47 | mgagne | but there is an instance_mapping in nova_api | |
| 20:27:51 | dansmith | and we don't have deleted= flags in the api db | |
| 20:27:57 | mgagne | so I thought maybe it could read something from here first | |
| 20:28:13 | dansmith | we don't know much at all about the instance in the api db | |
| 20:28:14 | mgagne | yea, that was the point I wanted to make | |
| 20:28:26 | melwitt | efried: is the bp you had mentioned at the onboarding session as completed but not marked as completed still not marked completed here? https://blueprints.launchpad.net/nova/rocky | |
| 20:28:31 | mgagne | right | |
| 20:31:34 | jmlowe | ok, one more, after changing the endpoint nova client ignores https but osc does the right thing | |
| 20:33:48 | mriedem | jmlowe: which version of novaclient? | |
| 20:33:52 | mriedem | the https thing sounds familiar | |
| 20:34:08 | jmlowe | 9.1.0 | |
| 20:35:15 | jmlowe | weird, in debug the curl hint does the right thing REQ: curl -g -i -X GET https://iu.jetstream-cloud.org:8774/v2.1 -H "User-Agent: python-novaclient" -H "Accept: application/json" | |
| 20:35:46 | jmlowe | client tries http in spite of this | |
| 20:38:36 | mriedem | i bet andreykurilin would remember the https thing in novaclient i'm trying to think of | |
| 20:41:02 | mriedem | i'm thinking of this https://github.com/openstack/python-novaclient/commit/bd0a2adefe5e89c4269f6589837f871764c6f1f6#diff-815379030879ca27268b9336fecbe7dc | |
| 20:41:06 | mriedem | but that's in 9.1.0 | |
| 20:47:35 | artom_ | dansmith, so, about https://review.openstack.org/#/c/566398/ - is a MigrationContext created for live migration, and if so, where? | |
| 20:47:52 | dansmith | just a sec | |
| 20:48:02 | dansmith | it's different for live (ofcourse) | |
| 20:48:35 | artom_ | dansmith, heh - I'm going by the spec (https://specs.openstack.org/openstack/nova-specs/specs/rocky/approved/numa-aware-live-migration.html), so this migration context business is news to me | |
| 20:48:48 | artom_ | I saw it for cold migration, but couldn't find anything for live | |
| 20:49:06 | dansmith | oh, you know, | |
| 20:49:13 | dansmith | I might be confusing the migration with the context actually | |
| 20:49:25 | artom_ | Admittedly, migration and claims aren't areas I know well | |
| 20:49:27 | dansmith | we weren't doing that for live migration before I added it for the double claim fix | |
| 20:49:37 | dansmith | but yeah you might be right actually | |
| 20:50:16 | dansmith | so, I think we don't claim anything on the destination for live migration, IIRC | |
| 20:50:23 | dansmith | so I'm not sure what sahid means about the claiming part | |
| 20:51:04 | artom_ | dansmith, we do stuff with placement allocations, that's for sure | |
| 20:51:20 | dansmith | artom_: for the base resources, but not numa | |
| 20:51:28 | mriedem | we don't do claims for live migration | |
| 20:51:31 | dansmith | hence my comment on the later one | |
| 20:51:41 | artom_ | dansmith, right, and NUMA isn't ready in placement, so we're using RT for now (right?) | |
| 20:51:55 | dansmith | artom_: RT for numa, and not for live migration | |