Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-04-18
17:07:35 edmondsw efried, so see mriedem's reply above... service_type and interface would still be in conf
17:08:56 efried edmondsw Hm, see jaypipes from 20min ago
17:10:10 edmondsw efried he seemed to agree at 12:52
17:10:27 jaypipes edmondsw: gimme 10 minutes and I'll disagree with myself.
17:10:36 edmondsw :)
17:10:55 efried edmondsw Oh, I misunderstood, thought that was params to the function, not conf options.
17:11:07 edmondsw jaypipes I like a man who can change his mind when it makes sense
17:11:18 jaypipes edmondsw: I totally disagree.
17:11:21 edmondsw lol
17:11:24 jaypipes :P
17:13:01 edmondsw "interface" is what I was calling "endpoint_type" in our conversation because that's what the spec had called it
17:13:06 edmondsw efried ^
17:13:45 efried edmondsw Yeah, I've picked up on that dual naming.
17:14:03 efried edmondsw It's either-or all over the place.
17:16:05 edmondsw efried keystone calls it "interface"... at least in v3, I don't remember in v2
17:18:19 mordred yah. interface is the 'correct' term, endpoint_type is the legacy type
17:18:51 mordred fwiw, I would vote for not having service_type in the conf myself, but that's just me perhaps
17:19:48 efried mordred The concern was that we would then have to try some number of service types (in some possibly-arbitrary order) before we find the right one.
17:19:54 mordred mriedem: I do not think you need to have service_type so that you know cinderv2/cinderv3 - since that's in the cinder discovery doc
17:20:34 mordred efried: yes. you may have to do that - but that is fairly cheap. whereas continuing to allow configuration of service_type perpetuates the idea that it's ok for people to set them to something other than the one thing they should be set to
17:20:46 mordred but, as I said, i'm the extremist view on all of this
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: 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

Earlier   Later