Earlier  
Posted Nick Remark
#openstack-nova - 2017-04-18
17:20:48 mriedem mordred: but i thought the service type in the catalog was cinder/cinderv2/cinderv3?
17:21:02 mriedem and cinder == v1
17:21:15 mordred mriedem: yes. well, this is a tragedy of history that is hopefully soon rectified
17:21:25 mordred since it causes baby bunnies to weep regularly
17:21:45 mordred (and it's volume, volumev2 and volumev3)
17:21:50 mriedem oh right
17:22:00 mriedem we have that hard-coded in the nova request context code too \o/
17:22:07 mordred but you can _easily_ try all three of those from the catalog, since it's a local dict lookup
17:22:17 mordred and, in fact, I even already have the logic for that written up :)
17:25:11 efried mordred mriedem Where can I get the exhaustive list of service_type values?
17:26:17 mordred efried: https://review.openstack.org/#/q/project:openstack/service-types-authority is the beginning of collecting them
17:26:51 mordred efried: there is also an unofficial list here: http://git.openstack.org/cgit/openstack/os-client-config/tree/os_client_config/constructors.json
17:27:17 mordred although hopefully we can make that go away and rely on s-t-a once it coalesces
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: Implement use-service-catalog-for-endpoints differently https://review.openstack.org/457747
17:51:10 openstackgerrit Monty Taylor proposed openstack/nova-specs master: Fix old terminology https://review.openstack.org/457746
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

Earlier   Later