| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-04-18 | |||
| 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: 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 | |