| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-03-22 | |||
| 15:16:45 | jaypipes | sdague: if a nova instance is booted with a volume UUID, we would look up the traits and aggregates associated with the provider of that volume and winnow the set of compute node providers based on that list of traits and aggregates. | |
| 15:17:05 | mriedem | frickler: i guess i hadn't planned on updating that release note since it's already released | |
| 15:17:12 | mriedem | frickler: if we mention anything, it would be in a new release note | |
| 15:18:02 | openstackgerrit | Sujitha proposed openstack/nova master: Add description to policies in certificates.py https://review.openstack.org/448267 | |
| 15:19:03 | mriedem | jaypipes: sdague: this also came up in the dev ML http://lists.openstack.org/pipermail/openstack-dev/2017-February/112903.html | |
| 15:19:06 | mriedem | for that exact use case | |
| 15:19:17 | mriedem | jaypipes: if you have thoughts or details on how to solves that, please reply to that thread | |
| 15:19:30 | openstackgerrit | Sujitha proposed openstack/nova master: Add description to policies in admin_actions. https://review.openstack.org/440829 | |
| 15:19:56 | jaypipes | mriedem: ok | |
| 15:21:20 | frickler | mriedem: I think the release notes are confusing anyway. 14.0.4 lists the known issue, 14.0.5 doesn't list it anymore, so one could assume it being resolved there already | |
| 15:21:43 | sneti | johnthetubaguy, Can you please review https://review.openstack.org/#/c/396420/. I have just resolved merge conflict. | |
| 15:23:06 | mriedem | johnthetubaguy: on the host power action (shutdown/reboot) API, is the nova-compute service running on a separate host managing the backend hypervisor cluster | |
| 15:23:07 | mriedem | ? | |
| 15:23:42 | mriedem | johnthetubaguy: because otherwise the sync_instance_power_states periodic wouldn't be running if the nova-compute service is dead (because you stopped the host), and we wouldn't update the instance states to show them as shutdown | |
| 15:24:07 | johnthetubaguy | mriedem: not usually, its generally in a VM on that host | |
| 15:24:19 | johnthetubaguy | mriedem: yes, the power status stuff is all broken I suspect | |
| 15:24:48 | mriedem | ok, so if you run that api to stop your host, you effecitvely kill nova-compute managing the guests on that host :) | |
| 15:25:04 | mriedem | reboot would/should eventually come back, the service might be disabled for a time via the servicegroup health check, | |
| 15:25:06 | johnthetubaguy | yep | |
| 15:25:18 | mriedem | but otherwise the instances are never 'stopped' in the nova db status sense | |
| 15:25:19 | johnthetubaguy | I am fairly sure we only added that because the API was there | |
| 15:25:23 | mriedem | ha | |
| 15:25:32 | johnthetubaguy | the start is even crazier, thats just not possible | |
| 15:25:33 | mriedem | yeah i found that literally no backend supports host startup | |
| 15:25:43 | johnthetubaguy | ah, that makes sense | |
| 15:25:45 | mriedem | so we have an API that is just not supported, at all | |
| 15:25:57 | mriedem | there might be out of tree drivers, but... | |
| 15:26:03 | johnthetubaguy | yeah, I guess it must have been the old baremetal thing or something | |
| 15:27:22 | mriedem | ok i can check that old bm driver | |
| 15:28:31 | mriedem | frickler: btw i'll never remember your irc nick for who you are :) | |
| 15:28:38 | mriedem | if only you were just jens or something | |
| 15:32:41 | frickler | mriedem: that is too common here in germany. and I'll change my lastname in summer. I may consider a nick change, then ;) | |
| 15:36:25 | nkorabli | Hi there! I've got a little question about multitenancy in nova: | |
| 15:36:53 | mriedem | johnthetubaguy: even the old bm driver didn't support this stuff https://github.com/openstack/nova/blob/juno-eol/nova/virt/baremetal/driver.py | |
| 15:37:03 | nkorabli | login as demo user and create an instance . | |
| 15:37:04 | nkorabli | login as demo user and try to unshelve the instance shelved by admin user | |
| 15:37:04 | nkorabli | login as a admin user navigate to admin panel and shelve the instance (as admin user is able shelve any instance) | |
| 15:37:05 | nkorabli | expected : instance should be unshelved | |
| 15:37:06 | johnthetubaguy | mriedem: that is a mystery then :S | |
| 15:37:07 | nkorabli | Actual : instance is not shelved but is went to error state. | |
| 15:38:28 | nkorabli | I am sorry, for interrupting, though. But I just was wondering if that (what I've posted above) is expected or not? | |
| 15:38:45 | openstackgerrit | Hironori Shiina proposed openstack/nova master: Ironic: Support boot from Cinder volume https://review.openstack.org/215385 | |
| 15:39:26 | mriedem | nkorabli: check your policy, can non-admins users unshelve in your deployment? | |
| 15:39:49 | cfriesen | mriedem: even if they couldn't, presumably it should just return an error message rather than put the instance into error state | |
| 15:40:03 | mriedem | cfriesen: true | |
| 15:40:07 | mriedem | policy fail would be a 403 | |
| 15:40:13 | openstackgerrit | Sujitha proposed openstack/nova master: Add description to policies in baremetal_nodes.py https://review.openstack.org/448650 | |
| 15:40:33 | mriedem | default policy for shelve is admin or owner | |
| 15:40:39 | mriedem | so the demo user that created the instance should be able to unshelve it | |
| 15:40:53 | mriedem | the error is probably due to the instance actually failing to unshelve, i.e. spawn on a host | |
| 15:41:05 | mriedem | which is not a policy issue, just an issue | |
| 15:41:25 | nkorabli | oh, alright... | |
| 15:41:25 | mriedem | nkorabli: so check the conductor, scheduler and nova-compute logs for failures | |
| 15:41:27 | mriedem | for the unshelve | |
| 15:41:40 | mriedem | it should be pretty obvious if the instance is in ERROR state | |
| 15:42:07 | nkorabli | Got it! Let me check that.. | |
| 15:42:18 | nkorabli | Thanks a lot! | |
| 15:44:20 | mriedem | alex_xu: did you want me to specifically call out that the search-related GET methods for os-hypervisors will not be changed in https://review.openstack.org/#/c/447149/1/specs/pike/approved/service-hyper-uuid-in-api.rst@117 ? | |
| 15:45:40 | mriedem | sdague: johnthetubaguy: dansmith: thoughts on https://review.openstack.org/#/c/447149/1/specs/pike/approved/service-hyper-uuid-in-api.rst@128 and if we change the value of the id key to be a uuid value, or add a uuid key to the response, or completely drop id and just return a uuid key? | |
| 15:45:57 | mriedem | server.id response is a uuid, but aggregates response has both id (int) and uuid | |
| 15:46:14 | dansmith | mriedem: I'm fine eitther way | |
| 15:46:20 | mriedem | ok | |
| 15:46:21 | dansmith | tend to thing re-using id is easier | |
| 15:46:22 | openstackgerrit | Gábor Antal proposed openstack/nova master: Ensure instance is in active state after notification test https://review.openstack.org/448655 | |
| 15:46:23 | dansmith | *think | |
| 15:46:30 | mriedem | dansmith: that's what i was originally planning too | |
| 15:47:11 | mriedem | shit, now that i mention aggregates https://developer.openstack.org/api-ref/compute/?expanded=show-aggregate-details-detail#host-aggregates-os-aggregates | |
| 15:47:16 | mriedem | /os-aggregates/{aggregate_id} | |
| 15:47:19 | mriedem | is the primary key int | |
| 15:47:30 | mriedem | dansmith: have you gotten to aggregates in your multi-cell api series yet? | |
| 15:47:36 | dansmith | mriedem: aggs are in api db | |
| 15:47:42 | mriedem | oh | |
| 15:47:42 | dansmith | mriedem: so just ugly, but not a problem | |
| 15:47:49 | mriedem | ok | |
| 15:47:54 | mriedem | i should have known that | |
| 15:48:41 | sdague | mriedem: changing the id field is probably fine, documentation will be a little odd on that, but should be fine. | |
| 15:48:48 | mriedem | yeah | |
| 15:48:50 | mriedem | ok | |
| 15:53:17 | openstackgerrit | Gábor Antal proposed openstack/nova master: Transform instance.volume_attach notification https://review.openstack.org/401992 | |
| 15:53:37 | mriedem | sdague: dansmith: and we're good with changing "PUT /os-services/disable" to "PUT /os-services/{service_id}disable" ? | |
| 15:53:51 | mriedem | for the 4 service action APIs | |
| 15:54:01 | mriedem | and removing the host/binary body as identifiers | |
| 15:54:10 | mriedem | https://developer.openstack.org/api-ref/compute/?expanded=show-aggregate-details-detail,disable-scheduling-for-a-compute-service-detail#disable-scheduling-for-a-compute-service | |
| 15:54:47 | mriedem | or just tell me to shut up and stop asking | |
| 15:56:51 | sdague | the whole empty PUT thing seems weird to me, as it's not a thing you would GET | |
| 15:58:09 | mriedem | what do we change it to? | |
| 15:58:10 | mriedem | POST? | |
| 15:58:25 | mriedem | POST is what we use for the server action APIs | |
| 15:59:38 | sdague | yes | |
| 16:01:12 | cdent | POST is probably right for empty actions, but only because actions are outright weird in the first place | |
| 16:01:36 | cdent | we've started exploring empty PUTs in the placement API, but they do involve things which can be GET | |
| 16:01:54 | cdent | (and are still empty when gotten) | |
| 16:02:32 | sdague | cdent: that whole thing seem super weird to me as well, as it seems really odd to have resources with no content | |
| 16:03:22 | cdent | sdague: there's tons of those things across the placement api though: empty strings that mean stuff only by their existence | |
| 16:03:23 | cdent | customer resource classes and traits | |
| 16:03:35 | cdent | s/empty/simple/ | |
| 16:04:21 | mriedem | sdague: cdent: so to be clear, we can remove the body for this https://developer.openstack.org/api-ref/compute/?expanded=disable-scheduling-for-a-compute-service-detail#disable-scheduling-for-a-compute-service | |
| 16:04:24 | mriedem | which then makes it a POST | |
| 16:04:41 | mriedem | but we'd still have a body for https://developer.openstack.org/api-ref/compute/?expanded=log-disabled-compute-service-information-detail#log-disabled-compute-service-information | |
| 16:04:48 | mriedem | so does that become POST or remain PUT? | |