| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-04-18 | |||
| 17:28:39 | efried | mordred Will service-types-authority be complete and definitive in pike (in time to be used for this impl)? | |
| 17:28:58 | mordred | doubful - can you point me to the spec you're talking about? | |
| 17:29:12 | efried | mordred https://review.openstack.org/#/c/454983/7/specs/pike/approved/use-service-catalog-for-endpoints.rst | |
| 17:29:19 | mordred | thanks! | |
| 17:29:46 | efried | Thank _you_. I'm very much struggling just to understand the context here. Any guidance is much appreciated. | |
| 17:39:14 | efried | jaypipes mriedem Suggestions for where the new get_service_url() method should live? | |
| 17:39:49 | jaypipes | efried: nova/utils.py? | |
| 17:39:55 | efried | ight | |
| 17:40:38 | efried | jaypipes Not service.py, service_auth.py, or context.py, then. | |
| 17:41:52 | jaypipes | efried: I think nova/utils.py is a fine home. we can always move it in the future if need be. | |
| 17:41:57 | efried | rgr | |
| 17:43:43 | mriedem | yeah nova.utils is fine | |
| 17:49:27 | efried | concern: circular imports... | |
| 17:51:10 | openstackgerrit | Monty Taylor proposed openstack/nova-specs master: Fix old terminology https://review.openstack.org/457746 | |
| 17:51:10 | openstackgerrit | Monty Taylor proposed openstack/nova-specs master: Implement use-service-catalog-for-endpoints differently https://review.openstack.org/457747 | |
| 17:51:26 | mordred | jaypipes, efried, mriedem: ^^ there is me arguing | |
| 17:53:39 | mriedem | mordred: publicURL is in the config defaults right now https://github.com/openstack/nova/blob/master/nova/conf/cinder.py#L26 | |
| 17:53:44 | mriedem | that's why it was in the spec | |
| 17:54:01 | mordred | mriedem: I totally understand. but publicURL is a keystonev2 holdover | |
| 17:54:26 | mriedem | yeah that's fine, we could change the default config option | |
| 17:54:36 | mriedem | we already changed cinderv2 to cinderv3 in that option in pike | |
| 17:54:52 | mriedem | mordred: you could propose the change and get your ATC badge | |
| 17:55:15 | mordred | ah - so I totally misunderstood taht the config option already existed | |
| 17:55:21 | mriedem | right | |
| 17:55:51 | mordred | so - my sugestion of 2 new options still stands - but if this is already a thing I guess there is no point in doing a double migration | |
| 17:56:12 | mriedem | jaypipes: efried: so i guess we lost something in one of the patch sets on that spec where it listed the options we'd provide as overrides, like service_type and interface | |
| 17:56:19 | mriedem | which is maybe why edmondsw was confused | |
| 17:58:06 | mriedem | edmondsw: mordred: see https://review.openstack.org/#/c/454983/4..7/specs/pike/approved/use-service-catalog-for-endpoints.rst@a76 | |
| 17:58:13 | mriedem | ps4 on the original spec called some of this out | |
| 17:59:03 | efried | So if service_type is provided, use it. If interface is provided, use it. If not provided, cycle through them (if neither provided, does it matter which is inner and which is outer loop?) | |
| 17:59:14 | macsz | bug team meeting in 2 minutes @ openstack-meeting-4 | |
| 17:59:27 | efried | Is the service catalog guarateed to present at most one hit for a given service? | |
| 18:00:09 | mriedem | efried: i've been in other meetings so didn't follow any of the discussion about iterating things | |
| 18:00:11 | efried | Sorry, I mean I guess e.g. glance can provide multiple endpoints - but only for one service_type/interface combo? | |
| 18:00:57 | efried | mriedem Yeah, so jaypipes (I think) suggested having a hardcoded list of service_type values and trying them in (what?) order. | |
| 18:01:50 | efried | ...or is service_type required (defaulting to something "sensible" for each service)? | |
| 18:02:28 | mordred | starting with "nicest" default - that is, whatever is in service-type-authority - and then falling back to other items in preferred order | |
| 18:02:52 | jaypipes | mordred: right, xactly what I think is appropriate.y | |
| 18:03:21 | efried | And for further fun, continue supporting existing conf options, with deprecation warnings, through pike. | |
| 18:03:36 | mordred | btw - I'm writing a quick spec for "just use os-client-config" - which I started hacking on but it's entirely possible that none of you know that, since I didn't write a spec | |
| 18:04:14 | efried | mordred Is there an example somewhere of os-client-config being used for something like this? | |
| 18:04:24 | mriedem | efried: novaclient functional tests | |
| 18:04:48 | mriedem | https://github.com/openstack/python-novaclient/blob/master/novaclient/tests/functional/base.py#L157 | |
| 18:07:20 | mriedem | so what is the list of service types for cinder? | |
| 18:07:27 | mriedem | and this is a ListOpt or what? | |
| 18:07:44 | mriedem | [cinder]service_types=volumev3,volumev2,cinderv3,cinderv2? | |
| 18:10:01 | mriedem | mordred: "ditch the concept of a single value that is a colon separated tuple, since that form is not used to indicate an OpenStack service pretty much anywhere else" is adorable | |
| 18:10:11 | mriedem | mordred: cinder copied that from nova, and manila copied that from cinder | |
| 18:10:58 | jaypipes | mriedem: in case you were wondering, I'm working on patches that add get_inventory() implementation for all the non-Ironic virt drivers. | |
| 18:12:25 | mriedem | jaypipes: ok | |
| 18:12:33 | mriedem | i'm working on reviewing already approved specs | |
| 18:12:39 | mriedem | so we can rewrite them | |
| 18:13:44 | jaypipes | lol | |
| 18:28:04 | mordred | mriedem: heh. I meant in the world of people consuming openstack services | |
| 18:29:09 | openstackgerrit | Monty Taylor proposed openstack/nova-specs master: Add spec for using os-client-config for service clients https://review.openstack.org/457760 | |
| 18:32:22 | openstackgerrit | Monty Taylor proposed openstack/nova-specs master: Fix old terminology https://review.openstack.org/457746 | |
| 18:44:14 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Fix docstring in _validate_requested_port_ids https://review.openstack.org/457767 | |
| 18:57:51 | openstackgerrit | Dan Smith proposed openstack/nova master: Make server groups api aware of multiple cells for membership https://review.openstack.org/457338 | |
| 18:57:52 | openstackgerrit | Dan Smith proposed openstack/nova master: Sort CellMappingList.get_all() for safety https://review.openstack.org/443174 | |
| 18:57:53 | openstackgerrit | Dan Smith proposed openstack/nova master: Clean up ClientRouter debt https://review.openstack.org/444487 | |
| 18:57:54 | openstackgerrit | Dan Smith proposed openstack/nova master: Add workaround to disable group policy check upcall https://review.openstack.org/442736 | |
| 19:06:54 | mriedem | johnthetubaguy: i went through https://review.openstack.org/#/c/452577/ and short answer is i don't know why the existing code isn't working :( | |
| 19:07:17 | mriedem | unless the info cache is getting concurrent updates and some stale data overwrites our update with the newly attached port | |
| 19:36:01 | openstackgerrit | Jay Pipes proposed openstack/nova master: placement: implement get_inventory() for libvirt https://review.openstack.org/457782 | |
| 19:41:53 | openstackgerrit | Monty Taylor proposed openstack/nova-specs master: Add spec for using os-client-config for service clients https://review.openstack.org/457760 | |
| 19:49:52 | openstackgerrit | Jon Bernard proposed openstack/nova master: Add tempest-dsvm-ceph-rc https://review.openstack.org/456292 | |
| 19:53:39 | openstackgerrit | Jon Bernard proposed openstack/nova master: Add tempest-dsvm-ceph-rc https://review.openstack.org/456292 | |
| 19:55:38 | Laszlo_ | hello | |
| 19:56:01 | Laszlo_ | I've run into an interesting situation with Newton: | |
| 19:56:20 | Laszlo_ | I have a user user1 in project1 | |
| 19:56:28 | Laszlo_ | the user is creating a VM | |
| 19:56:50 | Laszlo_ | then the admin user in the admin project is creating a volume | |
| 19:57:59 | Laszlo_ | next the admin user is attaching the volume using the ID of the VM (server) created by the user and the ID of the voulme created by admin | |
| 19:58:38 | Laszlo_ | all fine, the volume is visible inside the server. | |
| 19:59:05 | mriedem | user tries to detach the volume or delete the instance and it blows up because the user doesn't have access to GET the volume | |
| 19:59:08 | mriedem | by design | |
| 19:59:27 | Laszlo_ | next the user is deleting the server (actually is deleting the entire stack that has created the server) | |
| 19:59:52 | Laszlo_ | openstack stack delete lab2 | |
| 20:00:03 | Laszlo_ | no errors so far | |
| 20:00:35 | Laszlo_ | but when I'm looking at the volume created by the admin user I can still see it as being attached .... | |
| 20:00:48 | mriedem | because nova failed to detach it | |
| 20:00:55 | mriedem | because the instance user doesn't have access to the volume | |
| 20:01:16 | Laszlo_ | I see ... | |
| 20:01:24 | mriedem | fails here https://github.com/openstack/nova/blob/master/nova/compute/manager.py#L2267 | |
| 20:01:39 | Laszlo_ | can I run the detach as admin? (now the VM is already gone .... ) | |
| 20:01:40 | mriedem | you should see one of those warnings in the logs | |
| 20:01:54 | mriedem | you'd have to detach the volume as admin before deleting the server | |
| 20:02:00 | mriedem | you can't detach it after the server is gone | |
| 20:02:11 | mriedem | otherwise you need to force a reset of the volume state on the cinder side | |
| 20:02:32 | Laszlo_ | is there a way out from this situation? | |
| 20:03:22 | mriedem | Laszlo_: i think you have to use the os-reset_status API on the cinder side in that case | |
| 20:04:06 | mriedem | https://developer.openstack.org/api-ref/block-storage/v2/index.html#reset-volume-statuses | |
| 20:04:23 | Laszlo_ | mriedem: OK. I will chack it. I have not used this before | |
| 20:04:30 | mriedem | it's really a backdoor hack | |
| 20:04:35 | mriedem | when something goes wrong | |
| 20:04:47 | mriedem | your root problem is that you have the admin creating and attaching a volume to a server it does not own | |
| 20:05:13 | mriedem | so when the server is deleted, the owner of the server does not have access to detach the volume | |
| 20:05:19 | mriedem | b/c it can't get access to the volume | |
| 20:05:22 | mriedem | since the admin owns it | |
| 20:05:37 | mriedem | so either, use a single tenant, or make sure your tooling has the admin detach the volume before the server is deleted | |