| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-02-13 | |||
| 20:01:03 | cfriesen | mriedem: that's if you try to list the flavor | |
| 20:01:07 | cfriesen | show the flavor | |
| 20:01:35 | mriedem | cfriesen: i think that's fine when someone not authorized to that flavor specifically tries to show it | |
| 20:01:51 | mriedem | if i own the server by not the flavor, then show me what i can see about the flavor in general | |
| 20:01:59 | mriedem | extra specs are an admin thing by default | |
| 20:02:05 | cfriesen | mriedem: okay, but silently omit the extra_specs? | |
| 20:02:15 | mriedem | but i can certainly do nova flavor-show 1 as non-admin | |
| 20:02:17 | mriedem | yes | |
| 20:03:02 | EmilienM | sdague, mriedem: are you going to revert something in master? (context: https://review.openstack.org/#/c/432954/1/nova/conf/placement.py= | |
| 20:03:11 | cfriesen | mriedem: if you do " nova flavor-show 1" as non-admin, and there are extra-specs in the flavor, you get that error | |
| 20:03:17 | mriedem | EmilienM: trying to determine how much someone needs to control that interface | |
| 20:03:21 | mriedem | i thought it was a tripleo requirement | |
| 20:03:31 | EmilienM | it's not a "tripleo" requirements | |
| 20:03:44 | EmilienM | real deployments don't want nova-compute to reach public endpoint | |
| 20:04:10 | EmilienM | andymccr is from rackspace/ansible and has the same requirement as we have in tripleo. It just comes from real world | |
| 20:04:32 | mriedem | yeah i know we allow this when nova connects to other services, configuring which endpoint or url i mean | |
| 20:04:57 | sdague | EmilienM: I think it's a little bit of a misunderstanding of the meaning that field has | |
| 20:05:15 | EmilienM | I'm just interested to know if you'll keep this parameter in place or if we have to workaround by creating publicURL with an internal ip | |
| 20:06:08 | mriedem | sdague: i think we keep the config option in place but remove the choices restriction, yes? | |
| 20:06:26 | mriedem | i'm already working on a change to use this in nova-status since that was missed, along with tests | |
| 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 | |