Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-02-13
20:06:27 EmilienM mriedem: maybe keep documentation of what users can configure
20:06:28 cdent the original intent when we established some patterns in placement was that we'd only only ever have one endpoint for service, not use ports in the service catalog and generally do the tidy-service-catalog stuff we've been talking about for a long time. That intent has had some collisions with reality, which is to be expected.
20:07:20 cdent i'd vote for keep config, remove choices restriction
20:07:30 EmilienM and document what users can configure
20:07:58 sdague mriedem: it's possible, but I also feel like this is a reasonable place to actually try to hold the line on the fact that interface is meaningless. Because there was some desire to actually come up with better ways to describe what that was going for.
20:08:49 sdague Honestly, ideally, keystoneauth would default to None, and just use whatever is specified if there was only one.
20:08:55 mriedem i thought the point of the interface on the different endpoints was so you could expose the APIs on different networks?
20:09:18 mriedem i.e. internal vs public
20:10:47 sdague mriedem: ok, but in the case of the placement API, what are those?
20:11:11 mriedem idk, they're all admin as far as i know
20:11:25 sdague so I get that public might be an "internal" ip here, but I actually am not sure I udnerstand the usecase for 2 different bindings of placement API
20:11:31 mriedem the only things talking to it are nova, neutron (routed networks), and the admin scripting stuff for shared storage and other things at some point
20:11:39 mriedem sdague: also https://github.com/openstack/keystone/blob/master/keystone/catalog/schema.py#L94
20:11:44 cdent so far
20:11:54 cdent plans for things like horizon-like dashboards of usage
20:12:02 mriedem sdague: the keystone api schema seems to enforce those 3 values
20:12:11 sdague mriedem: gah
20:12:23 sdague sigh
20:12:52 sdague when we dug through the service catalog issues a year ago, it was pretty clear these were all meaningless
20:13:10 mriedem https://github.com/openstack/keystone/blob/master/keystone/catalog/controllers.py#L366
20:13:14 sdague mriedem: I guess on v3 the imposed a schema
20:13:39 sdague mriedem: right, that's on the v3 side, if v2 is still turned on I'm pretty sure it's all freeform
20:13:47 mriedem yeah https://github.com/openstack/keystone/commit/8ef267c3ee3f0f1e6bdb74da7ed68aeb958e5567
20:14:22 mriedem and keystone v2 is deprecated
20:14:25 mriedem since mitaka i think
20:15:02 sdague ok, well, lets at least not enforce these in nova
20:15:41 mriedem but what happens when i set os_interface=pubic?
20:15:43 mriedem :P
20:15:46 sdague because if anyone wants to actually address adding real meaning to that field instead of what exists in a few deployments
20:15:46 cdent sdague: I'm not sure I understand. Didn't we just establish that v3 has imposed these models
20:15:53 sdague cdent: on add
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

Earlier   Later