Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-04-18
16:52:09 mriedem efried: the whole point is we don't want catalog_info
16:52:18 mriedem so we're going to deprecate that once we start using ksa
16:52:22 jaypipes right
16:52:25 mriedem and we just have a service_type and interface option
16:52:29 jaypipes bingo
16:52:32 mriedem so service_type=cinderv3, interface=public
16:52:34 mriedem or whatever
16:52:43 jaypipes and frankly, even the interface is questionable... but meh. :)
16:52:44 mriedem interface defaults to None in nova.conf, which defaults to public in ksa
16:52:47 mriedem sure
16:52:58 mriedem i only mention interface b/c of the one we added for placement for andymccr
16:53:01 jaypipes ya
16:53:19 mriedem johnthetubaguy: ok will look after the notifications meeting
16:53:35 mriedem where i'm sure we'll talk about loading instance.tags by default
16:53:40 mriedem so dansmith might want to be there
16:53:56 dansmith "want"
16:54:09 mriedem "so i want dansmith to be there"
16:54:11 mriedem better?
16:54:13 dansmith yes
16:54:29 mriedem sorry i'm midwestern
16:54:33 mriedem and therefore passive aggressive
16:54:58 openstackgerrit Sylvain Bauza proposed openstack/nova-specs master: Claims in the scheduler https://review.openstack.org/437424
16:55:11 bauzas mriedem: dansmith: edleafe: cdent: jaypipes: BOOOM ^
16:55:19 bauzas that said, \o
16:55:33 jaypipes bauzas: k, thx. will re-review shortly.
16:55:58 mordred TIL novaclient validates payloads more in python3 than in python2
16:56:25 sdague mordred: interesting...
16:56:41 sdague mordred: define more?
16:57:56 mordred sdague: http://logs.openstack.org/48/457548/2/check/gate-shade-python35/0b68957/testr_results.html.gz - the test failure there only fails on python3 - in python3 it passed. the error is that I was returning the wrong top-level key in my response
16:58:11 mordred (was returning security_groups and not security_group)
16:59:34 sdague weird
17:03:05 mordred yah
17:03:27 mordred I mean, it's neat that novaclient in python3 double-checked that for me - it caught a bug :)
17:03:45 sdague yeh, I wonder what actually is different there
17:05:16 edmondsw mriedem, are you saying we would still have service_type and interface options in conf?
17:05:44 mriedem edmondsw: yes
17:05:51 mriedem because we need to know if you're going to use cinderv2 or cinderv3
17:05:59 mriedem or cinderv4
17:06:10 edmondsw mriedem, ok, good... I would even be fine with (at least eventually) hardcoding service_type... but not interface
17:06:11 mriedem details are in the spec
17:06:28 edmondsw mriedem well that's the thing... I read the spec and this was far from clear
17:06:46 edmondsw unfortunately I read it after it was merged
17:06:51 mordred sdague: I can't see anything different in the code
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

Earlier   Later