| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-04-18 | |||
| 16:18:26 | andymccr | efried: it makes sense to me so i'll do it and can always revise :) | |
| 16:18:27 | efried | Basically, we don't want a CONTENT_LENGTH that's not an int. | |
| 16:18:35 | cdent | i think once you get tests in place, the solutions will be pretty clear | |
| 16:18:43 | andymccr | yeah agreed | |
| 16:19:25 | efried | Thanks guys. Felt like we were going around in circles a bit trying to have this conversation via gerrit. | |
| 16:20:13 | andymccr | haha yeah probably - and thanks for the pointers/help on that one. | |
| 16:21:23 | openstackgerrit | dane-fichter proposed openstack/nova master: Add trusted certificates to InstanceExtras https://review.openstack.org/457711 | |
| 16:21:44 | efried | andymccr cdent sfinucan Aha - it was getattr() I was confusing with. If you don't provide the default there, it raises. <facepalm> | |
| 16:22:33 | sfinucan | efried: Yup, I only realized last week that you could even use a default. Had been using a 1-2 hasattr/getattr combo up to that point | |
| 16:27:22 | cdent | efried: thanks for that linking | |
| 16:27:32 | efried | yahyoubetcha | |
| 16:33:00 | openstackgerrit | Stephen Finucane proposed openstack/nova master: conf: Gather 'live_migration_scheme', 'live_migration_inbound_addr' https://review.openstack.org/456572 | |
| 16:33:00 | openstackgerrit | Stephen Finucane proposed openstack/nova master: conf: Add three new '[libvirt] live_migration_*' options https://review.openstack.org/456571 | |
| 16:33:01 | openstackgerrit | Stephen Finucane proposed openstack/nova master: conf: Set default for live_migration_scheme https://review.openstack.org/457716 | |
| 16:33:01 | openstackgerrit | Stephen Finucane proposed openstack/nova master: conf: Convert 'live_migration_inbound_addr' to HostAddressOpt https://review.openstack.org/456573 | |
| 16:34:40 | johnthetubaguy | mriedem: I have some questions on https://review.openstack.org/#/c/452577 I just took a look | |
| 16:34:54 | johnthetubaguy | mriedem: I am trying to workout why the existing logic doesn't work correctly | |
| 16:46:21 | efried | mriedem jaypipes Clarification on https://review.openstack.org/#/c/454983/ (Service catalog for endpoints): Do we *want* to include config options like [cinder]catalog_info for all the services, or just use a hardcoded service_type? | |
| 16:48:04 | jaypipes | efried: I'd prefer to use a hard-coded service type, from the service-types-authority: https://github.com/openstack/service-types-authority/ | |
| 16:48:19 | jaypipes | efried: unfortunately cinder isn't in there :( | |
| 16:48:37 | efried | jaypipes Okay, I dig the idea of having fewer conf settings. But edmondsw also had concerns about hardcoding the endpoint_type. | |
| 16:49:00 | jaypipes | efried: but cinder is proposed for "block-storage": https://review.openstack.org/#/c/436178/ | |
| 16:49:40 | jaypipes | efried: for Cinder, specifically, we'll need to have a list of hard-coded service types and try them in order. | |
| 16:50:05 | jaypipes | efried: for instance, try "block-storage", then "volumev2", then "volume", etc | |
| 16:50:25 | jaypipes | efried: because Cinder is the odd man out of all this. | |
| 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 | |