| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-sdks - 2017-08-14 | |||
| 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?? | |
| 14:12:43 | openstackgerrit | Eric Fried proposed openstack/os-service-types master: Support secondary services https://review.openstack.org/493325 | |
| 14:34:25 | mordred | efried: sorry - morning juggling of the things - I shall update the depend cycle in just a sec | |
| 14:34:37 | efried | mordred I did that ^^ | |
| 14:35:24 | efried | The commit message was on the tox one - I think you were wanting to mention that it was missed because your env was running py3 by default. | |
| 14:35:25 | efried | or something. | |
| 16:20:22 | openstackgerrit | Merged openstack/python-openstackclient master: Convert network segment functional tests to JSON https://review.openstack.org/491612 | |
| 17:57:08 | openstackgerrit | Rajath Agasthya proposed openstack/python-openstackclient master: Add flavor value options https://review.openstack.org/302795 | |
| 18:08:58 | openstackgerrit | Merged openstack/os-client-config master: Updated from global requirements https://review.openstack.org/491294 | |
| 18:52:18 | efried | mordred https://review.openstack.org/#/c/490750/ is not reflected in https://service-types.openstack.org/service-types.json - don't we have a bot that's supposed to republish? | |
| 19:02:10 | openstackgerrit | Eric Fried proposed openstack/service-types-authority master: Ensure git rev-parse output works in python3 https://review.openstack.org/493361 | |
| 19:02:38 | efried | mordred docs build appears to need to run under py2 ^^ | |
| 19:02:52 | openstackgerrit | Eric Fried proposed openstack/service-types-authority master: Use consistent url schemes https://review.openstack.org/493362 | |
| 19:03:08 | openstackgerrit | Eric Fried proposed openstack/service-types-authority master: Add flag to indicate a service is a secondary service https://review.openstack.org/493326 | |
| 19:03:24 | openstackgerrit | Eric Fried proposed openstack/service-types-authority master: Add placement service https://review.openstack.org/462140 | |
| 19:03:34 | openstackgerrit | Eric Fried proposed openstack/service-types-authority master: Only run json.dump once https://review.openstack.org/493363 | |
| 19:03:41 | openstackgerrit | Eric Fried proposed openstack/service-types-authority master: Add three more transformations https://review.openstack.org/493364 | |
| 19:12:35 | openstackgerrit | Merged openstack/cliff master: Updated from global requirements https://review.openstack.org/493298 | |
| 23:11:48 | efried | mordred Well, it worked locally, but jenkins still hates it. | |
| 23:13:50 | mordred | efried: docs jobs don't use docs environment - they use the venv env (sorry for the delay) | |
| 23:14:23 | efried | mordred oh, so the fact that tox -e docs worked for me locally was irrelevant. | |