| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-02-13 | |||
| 20:19:47 | sdague | cdent: it doesn't | |
| 20:19:55 | cdent | then all bets about good behavior are off | |
| 20:20:02 | mriedem | so i think the choices list is already busted | |
| 20:20:10 | cdent | mriedem: yes that's true | |
| 20:20:19 | mriedem | ok, so i'm just going to remove the choices in my patch | |
| 20:20:23 | mriedem | which is becoming a monster | |
| 20:20:27 | sdague | mriedem: cool | |
| 20:20:44 | cdent | sdague: sure it does: I have to know about the internals of keystone's interface limitations in order to be able to effectively config placement in nova. That's a nightmare that started long ago | |
| 20:20:45 | cdent | it should be _just_ a type | |
| 20:20:47 | cdent | that's it | |
| 20:20:50 | cdent | we agree on that, I believe | |
| 20:21:10 | cdent | anything beyond that and we have crossed a line into hacks upon hacks, at which point being helpful seems...nice? | |
| 20:21:12 | mriedem | you config placement in nova based on the service catalog in keystone, right? | |
| 20:21:35 | mriedem | and keystone v3 validates the endpoint interface when you create the endpoint record | |
| 20:22:17 | mriedem | | fa5fd2272e2640caac54b19024122eec | RegionOne | placement | placement | True | admin | http://10.10.23.14/placement | | |
| 20:22:17 | mriedem | | e9767ac20f6c4aceae1e5f761608b6dc | RegionOne | placement | placement | True | public | http://10.10.23.14/placement | | |
| 20:22:17 | mriedem | | 12736628e5ad46429023d0536692bc2c | RegionOne | placement | placement | True | internal | http://10.10.23.14/placement | | |
| 20:22:17 | mriedem | stack@mriedem-devstack:~$ openstack endpoint list | grep placement | |
| 20:22:24 | sdague | cdent: on the first endpoint call it's going to validate, be descriptive there of the issue at hand | |
| 20:23:08 | cdent | mriedem: yeah, I hate that, but that's the established pattern | |
| 20:23:55 | cdent | sdague: I'm not able to translate what you just said. | |
| 20:24:27 | sdague | cdent: you are arguing for copy / pasting keystone logic into nova config to validate the config before we ever make a call | |
| 20:24:49 | sdague | I am saying, if the value doesn't work in their cloud, it's going to explode on the *first* placement call | |
| 20:24:52 | sdague | with endpoint not found | |
| 20:25:02 | sdague | which lets keystone own the validation | |
| 20:25:10 | sdague | and still trigger very early | |
| 20:25:30 | sdague | and needs to be descriptive about what went wrong, then people can fix it | |
| 20:25:43 | cdent | (aside: which we've demonstrated time and time again is suprisingly hard to debug and uncover because of process start up races and timing with regard to service catalog registration) | |
| 20:26:42 | cdent | sdague: sure that's true, I'm not saying we _should_ duplicate keystone stuff into nova. I'm just saying it isn't all that much worse than some of the other things already being done so, meh) | |
| 20:27:07 | cdent | I'm 100% behind removing the choices. +1 | |
| 20:27:30 | sdague | cdent: ok, well I'm saying lets please not add more linkage debt that we can avoid, especially when we know the current convention is pretty sub optimal | |
| 20:28:42 | sdague | many deployers just use a single set of public urls, and use DNS in their datacenter so every node gets access to it's best / appropriate path to every service | |
| 20:28:45 | cdent | we (you and I) say that, and we're pretty sure, yet without us even noticing keystone has enshrined it in schema, so some people think it is fairly relevant. We (again you and I) should see if we can find out why. | |
| 20:30:56 | sdague | cdent: it's not just you and I, this was one of the things that came up with the service catalog double session in tokyo. Very few ops were in favor of the current model, and lots of them used internal to mean very different things. | |
| 20:31:33 | cdent | (I wasn't being exclusive of the whole world, simply trying to be inclusive of you and I) | |
| 20:34:36 | mriedem | BobBall: yup you guys run xen ci with FORCE=true http://dd6b71949550285df7dc-dda4e480e005aaa13ec303551d2d8155.r49.cf1.rackcdn.com/18/433218/2/check/dsvm-tempest-neutron-network/7ec24bf/logs/localrc.txt.gz | |
| 20:34:39 | mriedem | # Need to force devstack to run because we currently use saucy FORCE=yes | |
| 20:34:47 | mriedem | even though you use trusty | |
| 20:38:11 | mriedem | apparently devstack centos job is busted on cells v2 http://logs.openstack.org/18/433218/2/check/gate-tempest-dsvm-platform-centos7-nv/2b9bcf7/logs/devstacklog.txt.gz#_2017-02-13_18_28_38_928 | |
| 20:38:13 | mriedem | and no one cares | |
| 20:46:13 | sdague | mriedem: that sounds normal | |
| 20:53:14 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Cleanup some issues with CONF.placement.os_interface https://review.openstack.org/433257 | |
| 20:53:15 | mriedem | cdent: sdague: here we go ^ | |
| 20:58:45 | cdent | mriedem: looks OK. Left a question | |
| 20:59:31 | sdague | mriedem: we should leave a default I think | |
| 20:59:50 | sdague | or... I guess without a default keystoneauth1 has a default? | |
| 20:59:52 | mriedem | sdague: but we didn't specify a default before when we didn't even have this | |
| 20:59:54 | mriedem | right | |
| 21:00:24 | sdague | mriedem: we're going to need to be more dynamic on the ks_filter then, right? | |
| 21:00:35 | mriedem | sdague: passing interface=None is OK | |
| 21:01:07 | mriedem | i think, checking ksa again | |
| 21:01:26 | mriedem | this https://github.com/openstack/keystoneauth/blob/master/keystoneauth1/identity/base.py#L209 | |
| 21:02:16 | sdague | mriedem: yeh, that's some interesting selection logic | |
| 21:02:19 | sdague | but I think you are right | |
| 21:02:31 | cfriesen | where does the hex hash (or whatever it is) come from in the filenames in releasenotes/notes/ ? | |
| 21:02:40 | mriedem | cfriesen: reno | |
| 21:02:48 | mriedem | http://docs.openstack.org/developer/reno/usage.html | |
| 21:03:12 | cfriesen | mriedem: thx | |
| 21:03:34 | sdague | mriedem: ok, so you know what that means actually | |
| 21:04:04 | sdague | if osad only declared as single placement api service, and it was called internal, all this code would have still worked | |
| 21:04:36 | mriedem | osad? | |
| 21:04:44 | mriedem | openstack ansible? | |
| 21:05:22 | sdague | yeh | |
| 21:05:27 | mriedem | if you only have a single placement endpoint and it's interface is not "public" then you have to set this | |
| 21:05:36 | mriedem | and the "public" thing is only because of the default in ksa | |
| 21:06:02 | mriedem | i didn't really know how to express that in the config option, since we seem to have a weird catch-22 of not wanting to talk about how keystone/ksa encodes and defaults the endpoint interfaces | |
| 21:06:32 | mriedem | i can make the default value "public" if that helps | |
| 21:06:58 | mriedem | i mean, we have publicURL in our default for cinder.catalog_info | |
| 21:07:05 | mriedem | everyone loves that right? | |
| 21:07:25 | sdague | mriedem: right, because it's still assuming k2? | |
| 21:07:37 | mriedem | i guess | |
| 21:07:49 | sdague | mriedem: actually, no I think the existing code in nova works if you only have 1 endpoint, and it's call internal | |
| 21:07:51 | mriedem | public == publicURL as a keystone v3 vs v2 thing is news to me as of today | |
| 21:08:06 | sdague | the code before the patch landed that is | |
| 21:08:19 | sdague | https://github.com/openstack/keystoneauth/blob/9e010b995ba2f19fcc63b14cf5048cedd5ff1e36/keystoneauth1/session.py#L511-L513 | |
| 21:09:39 | mriedem | i'm not following what that has to do with 'internal' as a default | |
| 21:10:06 | sdague | mriedem: I'm trying to figure out if you send down None what it is going to do | |
| 21:10:29 | sdague | I guess it gets converted to public here - https://github.com/openstack/keystoneauth/blob/9e010b995ba2f19fcc63b14cf5048cedd5ff1e36/keystoneauth1/identity/base.py#L209-L210 | |
| 21:10:39 | mriedem | yeah that's what i pointed out above | |
| 21:11:08 | sdague | yeh, sorry, I was thinking that it jumped into service_catalog.py get_endpoints directly | |
| 21:11:20 | mriedem | well, there are certainly plenty of spaghetti hoops in here | |
| 21:11:24 | sdague | given that there are similar named functions in a bunch of modules here | |
| 21:11:24 | mriedem | and plugins and such | |
| 21:11:28 | mriedem | right | |
| 21:11:33 | mriedem | i could have totally broken everything | |
| 21:11:40 | mriedem | i was hoping devstack would tell me | |
| 21:15:12 | mriedem | cdent: also on that unit test thing, it constructs a new object each time, so i'm not sure why i had to move it into __init__ but i blame python | |
| 21:16:47 | cdent | mriedem: probably the joys of global conf getting your face | |
| 21:17:39 | cdent | but yeah, *shrug* | |
| 21:24:16 | openstackgerrit | STEW TY proposed openstack/nova master: Complete verification of servers-action-fixed-ip.inc https://review.openstack.org/338606 | |
| 21:30:16 | cdent | sigh, I'm clearly in the wrong time zone, miss all the cool shit. oh well. | |
| 21:37:35 | openstackgerrit | STEW TY proposed openstack/nova master: Complete verification of servers-action-fixed-ip.inc https://review.openstack.org/338606 | |
| 21:45:09 | openstack | Launchpad bug 1635008 in OpenStack Compute (nova) "rbd credentials in nova.conf overwrite connection_info from cinder" [Low,Fix released] - Assigned to Matt Riedemann (mriedem) | |
| 21:45:09 | knikolla | mriedem: hi. would it be possible to backport the fix for this to newton? https://bugs.launchpad.net/nova/+bug/1635008 | |
| 21:45:45 | mriedem | knikolla: no because it's a behavior change | |
| 21:46:23 | knikolla | mriedem: i see. | |
| 21:46:28 | knikolla | thanks | |
| 21:46:32 | mriedem | sorry, np | |
| 21:51:38 | jamielennox | mriedem, sdague: figure out your ksa issue? | |
| 21:52:12 | sdague | jamielennox: yeh, it was mostly just making sure we didn't encode too much keystone schema into nova. | |