| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-02-13 | |||
| 20:15:58 | cdent | and those models are an enum that maps to the choices limitations? | |
| 20:16:19 | sdague | cdent: they are validated on create | |
| 20:16:29 | mriedem | sdague: to translate, don't further encode this in nova | |
| 20:16:30 | mriedem | right? | |
| 20:16:34 | sdague | mriedem: yes | |
| 20:16:45 | mriedem | since we could hypothetically microversion this out of keystone v3 | |
| 20:16:50 | sdague | mriedem: right | |
| 20:16:52 | cdent | ah, so you're saying what about the situation where someone installs placement in an environment with keystone v2? | |
| 20:17:12 | sdague | cdent: or any time in the future if these change | |
| 20:17:17 | mriedem | if someone is installing placement in ocata with a keystone v2, and keystone v2 was deprecated in mitaka, that seems bad | |
| 20:17:28 | cdent | mriedem: yes, that's where I was getting to | |
| 20:17:41 | mriedem | but yeah, we shouldn't encode a list that's already validated on the keystone side, and could possibly change | |
| 20:17:51 | sdague | validation of data that's meaningful to 1 service shouldn't be encoded in another service | |
| 20:18:03 | cdent | sdague: my point is that nothing in the keystone stack wants us to provide anything other than the three choices, so presumably we are doing the nova deployer a favor by not allowing them anything else? | |
| 20:18:15 | mriedem | cdent: unless that changes | |
| 20:18:29 | mriedem | and if it does change in a year from now, no one will have remembered that we did this in nova | |
| 20:18:36 | cdent | meh | |
| 20:18:54 | cdent | then it would be ideal if we could pull a config in from keystoneauth intead of using our own... | |
| 20:18:59 | sdague | cdent: yeh, you are mr microservices, I'm not sure why are you are argueing for split validation across such a boundary between services | |
| 20:19:14 | sdague | cdent: right, but *nothing* in keystoneauth validates that | |
| 20:19:33 | mriedem | cdent: and actually, | |
| 20:19:39 | mriedem | from what i see in ksa, 'auth' is a valid choice | |
| 20:19:41 | cdent | sdague: I'm saying that once such a split brain situation already exists | |
| 20:19:47 | mriedem | meaning bypass the service catalog and use auth_url | |
| 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 | |