| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-sdks - 2017-08-14 | |||
| 08:28:54 | openstackgerrit | Colleen Murphy proposed openstack/keystoneauth master: Allow discovery URLs to have trailing slashes https://review.openstack.org/492484 | |
| 10:33:11 | openstackgerrit | Qearl proposed openstack/python-openstacksdk master: fix the bug that cannot create a listener by openstacksdk https://review.openstack.org/493449 | |
| 13:01:57 | efried | mordred Okay. It ain't pretty, but it's better than breaking compatibility I suppose. | |
| 13:02:13 | efried | Though then you went and did that with https://review.openstack.org/#/c/493366 | |
| 13:11:03 | openstackgerrit | Merged openstack/keystoneauth master: Allow discovery URLs to have trailing slashes https://review.openstack.org/492484 | |
| 13:19:24 | efried | mordred Why is jenkins ignoring https://review.openstack.org/#/c/493365/ ? | |
| 13:22:08 | mordred | efried: I broke compat in 493366? | |
| 13:22:30 | mordred | efried: and good question | |
| 13:22:45 | efried | mordred Yeah, jenkins is ignoring that whole series. | |
| 13:23:28 | efried | mordred The compat question... If my os-service-types is using a local mirror that's not current? | |
| 13:23:39 | efried | local mirror of sta data, that is. | |
| 13:24:06 | efried | I suppose that's not terribly likely. | |
| 13:24:52 | mordred | efried: yah. but I do believe we could put in a check for that and at least give an "update your local mirror" error - or fallback to builtin data witha warning | |
| 13:25:34 | mordred | I mean, the only reason to not use builtin data is in case the builtin data is stale - so if the lib discovers that the builtin data is newer than locally mirrored data, it should use builtin | |
| 13:25:39 | mordred | efried: I'll follow up with that | |
| 13:27:40 | efried | mordred So how is a guy supposed to use the new method, anyway? In the case of my nova patch to load up the right ksa adapter, I think it's really not terribly useful. | |
| 13:28:50 | mordred | efried: you have a project and want to get a service-type right? | |
| 13:29:16 | efried | mordred I have a service type and want to get a conf section name. | |
| 13:29:19 | efried | in the case of placement. | |
| 13:29:36 | efried | mordred So I have 'placement' and want to get 'placement' :) | |
| 13:29:43 | efried | without hardcoding that specific mapping. | |
| 13:30:19 | mordred | right. well, you're likely going ot need to hardcode that specific mapping, because nova has a naming convention internally that it is breaking with placement | |
| 13:30:21 | mordred | BUT | |
| 13:30:23 | mordred | that new method isn't for you | |
| 13:30:48 | efried | mordred I actually did it without hardcoding: https://review.openstack.org/#/c/492247/5/nova/utils.py | |
| 13:31:19 | mordred | awesome. that's great logic | |
| 13:31:36 | efried | ...unless nova puts a [nova] section in their conf. Then I'm effed. | |
| 13:31:50 | mordred | well, that would be nova poking itself in the eye :) | |
| 13:32:03 | mordred | for the other bit, the new method doesn't help you - you have always been able to get the project name for a service given the service type | |
| 13:32:24 | mordred | in the other direction though, for documentation publication validation, one starts with project name and needs to go to service-type | |
| 13:32:39 | mordred | so that you can verify "did this git repo publish docs to the correct url" | |
| 13:33:23 | efried | mordred ...and enables us to add the placement service to sta at all. | |
| 13:33:27 | mordred | yah | |
| 13:35:29 | mordred | exactly. adding placement without adding the secondary flag breaks that question - but by making placement not show up in "what is the service-type for nova" - a user interested in knowing that both compute and placement come from nova has a hard time - that's what the new method is for (honestly not sure if anyone has that use, but the secondary flag removed it whereas your "return a list" patch | |
| 13:35:31 | mordred | would have provided that info - so it seemed like a compromise) | |
| 13:35:46 | openstackgerrit | liyi proposed openstack/python-openstacksdk master: Support node-adopt/preview CLI https://review.openstack.org/493542 | |
| 13:37:24 | cdent | why would someone looking up nova want to know about placement? | |
| 13:37:42 | cdent | presumably someone who needs/wants placement would look up placeent | |
| 13:37:45 | cdent | placement | |
| 13:37:57 | mordred | no clue -but we have the data, so adding "get_all_service_data_for_project" was fairly easy | |
| 13:37:57 | cdent | and if they haven’t heard of placement, there’s no need to look it up | |
| 13:38:16 | cdent | yes, but I don’t get it. Why is “for project” meaningful? | |
| 13:38:28 | mordred | meta-validation - things like docs validation jobs | |
| 13:38:55 | mordred | "I have the nova repo, it made docs for /compute - is that correct?" | |
| 13:38:57 | cdent | yeah, I’m semi-disappointed that we’ve added all that cruft on top of something that was supposed to be really simple | |
| 13:39:13 | mordred | well - I mean - the data mapping was already there | |
| 13:39:17 | cdent | we’ve gone from service types authority | |
| 13:39:30 | cdent | to authority for several things | |
| 13:39:33 | cdent | which is fine | |
| 13:39:44 | mordred | you need to know that 'image' and 'glance' are related for multiple reasons | |
| 13:39:49 | cdent | but soon it will have emacs, a kitchen sink, and book my flight reservations | |
| 13:40:27 | mordred | it really won't - and we really haven't added all that much | |
| 13:40:42 | mordred | the registry has always containe a mapping between service-type and project | |
| 13:41:05 | mordred | because it's needed in some places for computer consumption (like nova config which uses "glance" for image config rather than "image") | |
| 13:41:31 | cdent | (I was being sarcky, I’m not too disappointed with the changes, I’m more disappointed with the reality that requires them) | |
| 13:41:42 | mordred | cdent: ok. sorry - I'm still on first coffee :) | |
| 13:41:42 | cdent | right, and nova is wrong! | |
| 13:41:55 | mordred | and yes - I totally agree about with the disappointment in reality | |
| 13:42:13 | mordred | I need a tattoo "I'm disappointed in the reality that makes this thing necessary" | |
| 13:42:52 | cdent | in 3-d | |
| 13:43:19 | mordred | efried: oh - your local-cache case can't happen (yet) | |
| 13:43:34 | mordred | efried: we have not provided a way to allow someone to override the URL from which data is fetched | |
| 13:43:44 | efried | mordred Yeah, thought that might be the case. | |
| 13:43:47 | mordred | efried: when we do, I believe the case you raised is an important one for us to handle | |
| 13:43:55 | mordred | efried: and I had not considered it - so yay! | |
| 13:43:58 | efried | hadn't followed the thought all the way through. | |
| 13:44:32 | mordred | efried: I had just written the patch to fix it and was writing an exception message when I realized it was going to be "the data at https://service-types.openstack.org/service-types.json is stale" :) | |
| 13:47:05 | efried | mordred So here's a weird thing that happened with https://review.openstack.org/#/c/493361 | |
| 13:49:25 | mordred | efried: https://review.openstack.org/#/c/462140/ is a dependency loop I made, which is why t's not testing | |
| 13:50:47 | mordred | efried: (also, what's the weird thing?) | |
| 13:51:06 | mordred | efried: or just that that happened? | |
| 13:51:26 | efried | Sorry, got an interrupt | |
| 13:51:41 | efried | mordred The published output is identical except for the version string (expected, cause it's a time stamp)... and the sha. | |
| 13:51:47 | efried | The sha should be identical | |
| 13:51:54 | efried | Cause it doesn't use the version. | |
| 13:52:21 | efried | So I guess it's calculating the sha pre-decode, eh? | |
| 13:52:48 | efried | or rather, it was; and now it's not. | |
| 13:55:11 | efried | mordred Oh. | |
| 13:55:18 | efried | It has nothing to do with the content. | |
| 13:55:24 | efried | It's the commit hash. | |
| 13:55:28 | efried | <sheepish> | |
| 13:55:50 | efried | Hm, I'm not sure I love that idea, tbh. | |
| 13:56:02 | efried | I mean, we could very well commit a change that doesn't affect the JSON itself. | |
| 13:56:05 | efried | Like this one :) | |
| 14:01:46 | mordred | efried: it's purely a utf-8 encoding json reading change | |
| 14:02:16 | efried | mordred Not even json related. | |
| 14:02:18 | mordred | efried: the commit hash isn't strictly important - but the logic is there to prevent us publishing a new json file when we make changes like this one | |
| 14:02:20 | efried | Swhat confused me at first. | |
| 14:02:40 | efried | mordred Right - which doesn't work. | |
| 14:02:41 | mordred | efried: yah - sorry, that's what I mean. it's really a "we thought we were using python3 but weren't actually" | |
| 14:03:23 | efried | mordred But it won't prevent us from republishing when we make changes like this one. Because the git commit hash will always change. And that's what we're stuffing into the 'sha'. | |
| 14:03:23 | mordred | efried: it doesn't? why not? ... oh, sorry, there's another piece to this puzzle (I should write a better commit message) | |
| 14:03:45 | mordred | right. we always put sha into the json - the "is the data different" check is elsewhere and it ignores sha | |
| 14:04:14 | efried | mordred Oh. Ignores the sha, rather than using the sha to tell whether we've changed :) | |
| 14:04:17 | mordred | efried: the problem here surfaced because my tox installation is a python3 installation, which means I got a python3 virtualenv even though our config was broken | |
| 14:04:33 | mordred | so when I ran "tox -epublish" locally to validate, it broke | |
| 14:04:40 | efried | mordred Yeah, I get it. It just led me down this (apparently unrelated) rathole. | |
| 14:04:43 | mordred | yah. :) | |
| 14:04:51 | mordred | it's a good rathole - welcome to the rats! | |
| 14:07:57 | efried | mordred You gonna update the commit message anyway? So may be jenkins will pick it up?? | |