| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-02-13 | |||
| 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. | |
| 21:53:05 | jamielennox | great | |
| 21:53:17 | jamielennox | although out of interest what is keystone schema in this cnotext? | |
| 21:53:37 | jamielennox | from highlights it seems to be mostly interface related | |
| 21:53:54 | mriedem | jamielennox: yeah, | |
| 21:54:05 | sdague | jamielennox: yeh, the interface list | |
| 21:54:09 | mriedem | there was a change to encode the admin/internal/public endpoint interfaces in nova.conf | |
| 21:54:16 | mriedem | ksa also allows 'auth', | |
| 21:54:30 | mriedem | and keystone v2 doesn't restrict the interface it looks like, but the v3 api does | |
| 21:54:51 | sdague | especially because I know when we were talking about service catalog improvements that list was very much an oddity for a lot of ops | |
| 21:55:17 | sdague | so I didn't want to force encode that beyond keystone, which would prevent it evolving in the future | |
| 21:55:55 | jamielennox | i *think* keystone v2 restricts that interface because in v2 'publicURL', 'adminURL' etc are actual fields where in v3 it's just like {'url': ..., 'interface': ...} | |
| 21:56:03 | jamielennox | but i would want to double check that | |
| 21:56:15 | jamielennox | but there's no validation of that in ksa | |
| 21:56:53 | jamielennox | the way cinder and others do this is with a : seperated string, which isn't great but more flexibility than most provide | |
| 21:57:41 | jamielennox | mriedem: i'm not sure what you mean with ksa allows 'auth' - auth is a plugin so something that will be loaded at a very different time | |
| 21:58:36 | mriedem | jamielennox: https://github.com/openstack/keystoneauth/blob/master/keystoneauth1/identity/base.py#L198 | |
| 21:59:11 | mriedem | oh i thought that meant it could be "auth" | |
| 21:59:15 | jamielennox | oh, right | |
| 21:59:19 | mriedem | which meant lookup the endpoint via auth_url config | |
| 21:59:33 | mriedem | it's not really doc'ed from what i can tell | |
| 21:59:43 | jamielennox | that's mostly a special case when you want to look back to the auth_url provided to the plugin and used for some discovery | |
| 21:59:57 | jamielennox | from nova and services perspective you would always expect to be actually looking at the catalog | |