| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-sdks - 2019-01-17 | |||
| 17:07:15 | dtantsur | just a word of caution: obvious things like /status may clash with services that do not use major versions | |
| 17:07:18 | evrardjp | mugsie: agreed again | |
| 17:07:27 | mugsie | dtantsur: true | |
| 17:07:28 | evrardjp | cdent: ok | |
| 17:07:37 | aspiers | ah ok | |
| 17:07:56 | aspiers | Apache has mod_status.so which uses /status IIRC | |
| 17:07:58 | edleafe | mugsie: my only concern is when you run out of synonyms for 'healthcheck' :) | |
| 17:07:58 | dtantsur | so if we declare a standard endpoint, we may want it verbose. something like /openstack-status | |
| 17:08:02 | aspiers | although that is optional | |
| 17:08:06 | mugsie | /statuscheck /superhealthcheck | |
| 17:08:33 | dtantsur | just to make sure e.g. Placement never wants to introduce its own /status :) | |
| 17:08:37 | evrardjp | dtantsur: thanks for the advice here , I would totally have forgotten that | |
| 17:09:10 | dtantsur | now, if you do insist on major versions (we you shouldn't), it could be /openstack-status/v1 | |
| 17:09:39 | evrardjp | haha | |
| 17:09:42 | aspiers | there is some benefit to being somewhat consistent with the existing /healthcheck | |
| 17:09:48 | aspiers | /healthcheck-v2 ? | |
| 17:10:05 | dtantsur | what is this benefit? | |
| 17:10:08 | aspiers | and we want to leave room for v3 somehow :) | |
| 17:10:29 | dtantsur | if you want to leave room for large changes, use microversions | |
| 17:10:34 | mugsie | dont | |
| 17:10:35 | aspiers | dtantsur: so that people aren't confused about two totally different endpoints coming from the same oslo.middleware code | |
| 17:10:51 | elmiko | mugsie: ++ for /superhealthcheck XD | |
| 17:10:56 | mugsie | microversions will make it really hard for a lot of monitoring tools | |
| 17:10:59 | evrardjp | I think it would be fine to later add different path for different /superhealthchecks | |
| 17:11:11 | evrardjp | mugsie: I agree with you there | |
| 17:11:12 | dtantsur | mugsie: microversions are hard for everything, essentially | |
| 17:11:19 | evrardjp | we need the simplest thing for monitoring | |
| 17:11:30 | mugsie | personally, I am OK with /v<number>, but thats just me | |
| 17:11:43 | aspiers | I don't want to have to write a doc which says "for v1, use /healthcheck, for v2 use /openstack-status, and for v3 use /superawesomebunchofchecks" | |
| 17:11:55 | dtantsur | I don't see a problem with ^^ tbh | |
| 17:12:08 | dtantsur | especially if openstack-status is broader than healthcheck | |
| 17:12:17 | aspiers | OK I can try to privately deal with my OCD about inconsistency then :) | |
| 17:12:26 | edleafe | The problem is the repeated change of the API. | |
| 17:12:27 | dtantsur | I hear you, it can be painful | |
| 17:12:45 | elmiko | i'm more in favor of a commonly known path that could live outside of any path-based versioning scheme, but that's just my opinion | |
| 17:12:53 | dtantsur | hmm, we can do /healthcheck/v2 even while keeping /healthcheck | |
| 17:12:55 | elmiko | i don't have a strong technical argument | |
| 17:13:07 | aspiers | dtantsur: if that works, it sounds good | |
| 17:13:09 | evrardjp | elmiko: /healthcheck-v2.0 then /healthcheck-v3.0 ? | |
| 17:13:13 | mugsie | elmiko: this should be independant of the API version | |
| 17:13:16 | evrardjp | should that happen later? | |
| 17:13:17 | dtantsur | just make /healthcheck/(?!v2) redirect to /healthcheck/v1 and move the old stuff to /v1 | |
| 17:13:29 | elmiko | honestly, we should get this stuff written into the proposed spec/guideline for health checks | |
| 17:13:43 | elmiko | mugsie: right, that's why i like it to live on a consistent endpoint | |
| 17:13:44 | edleafe | dtantsur: that's the least terrible so far | |
| 17:13:49 | dtantsur | so e.g. /healthcheck/foo/bar redirects to /healthcheck/v1/foo/bar | |
| 17:13:51 | evrardjp | elmiko: it sounds like we're gonna get 10 different answers | |
| 17:13:56 | dtantsur | but /healthcheck/v2/foo/bar is just v2 | |
| 17:13:58 | aspiers | LOL, we're back where we were in the same bikeshed as 2 years ago XD | |
| 17:14:08 | elmiko | evrardjp: imo, /healthcheck/v{whatever} is preferable | |
| 17:14:18 | elmiko | evrardjp: yup, pretty much | |
| 17:14:23 | aspiers | I like /healthcheck/v$NUMBER | |
| 17:14:30 | dtantsur | I think we actually do it in ironic with our only major version (/nodes equivalent to /v1/nodes) | |
| 17:14:31 | mugsie | +1 | |
| 17:14:32 | aspiers | mugsie: that work for you? | |
| 17:14:35 | edleafe | Not to divert the conversation, but what is driving the need for new healthcheck versions? | |
| 17:14:50 | dtantsur | edleafe: it's a good question actually | |
| 17:14:53 | mugsie | edleafe: the old one misses some information, and the body changes | |
| 17:14:53 | aspiers | edleafe: https://storyboard.openstack.org/#!/story/2001439 | |
| 17:15:01 | aspiers | please read that first :) | |
| 17:15:06 | aspiers | there's a lot of history here | |
| 17:15:09 | aspiers | a *lot* | |
| 17:15:23 | aspiers | about 2+ years of bikeshedding | |
| 17:15:26 | aspiers | ;-0 | |
| 17:15:39 | dtantsur | "please read these 2 years of bikeshedding history first", thanks, so nice of you :D | |
| 17:15:56 | dtantsur | so, breaking changes? | |
| 17:15:56 | edleafe | dtantsur: it'll cure your insomnia :) | |
| 17:15:58 | evrardjp | edleafe: also check L105 around https://etherpad.openstack.org/p/BER-t-series-goals | |
| 17:16:11 | evrardjp | even if it's not enough for the context | |
| 17:17:47 | elmiko | imo aspiers, whoever is writing the initial draft spec/guideline you just pick a path and we can debate the wording in the pr | |
| 17:18:01 | elmiko | at least get a vote on record at that point | |
| 17:18:25 | elmiko | i'm fine to see my opinion lose in the end, but at least some sort of roll call on the pr would help drive the discussion | |
| 17:18:34 | elmiko | (unless this has already happened and i missed it all XD) | |
| 17:18:44 | edleafe | My feelings on API changes is to not release it until there is very little liklihood of it needing to be changed in the foreseeable future. IOW, it should not be an iterative process | |
| 17:19:15 | elmiko | ++ agreed | |
| 17:19:38 | elmiko | mind you, i am not proposing the release but the spec/guideline that proposes the usage | |
| 17:24:22 | dtantsur | yeah, a spec would be nice (I thought we had one?) | |
| 17:27:51 | elmiko | i thought we did too, but maybe mugsie did such a good job presenting it that i just didn't notice XD | |
| 17:28:01 | cdent | clearly the healthcheck can be written, tested, and nearly packaged without ever needing to choose its official name, yes? | |
| 17:28:11 | elmiko | oh definitely | |
| 17:28:19 | elmiko | /s | |
| 17:28:23 | cdent | in fact, ideally the middleware would be written with the name being a parameter | |
| 17:28:26 | cdent | (with a default) | |
| 17:28:41 | mugsie | cdent: I did think about that | |
| 17:28:56 | mugsie | But I like the idea that we have a single well known url | |
| 17:29:29 | elmiko | i do too mugsie | |
| 17:29:41 | mugsie | just make it part of the refstack tests with the good URL, and that should fix it :P | |
| 17:29:43 | cdent | mugsie: oh, yeah, I want there to be a single well known url too | |
| 17:29:53 | cdent | I'm just saying that the coding doesn't require that | |
| 17:29:55 | mugsie | in 2-5 years | |
| 17:30:02 | elmiko | heh, ++ | |
| 17:30:32 | elmiko | well see, we just add a new entry in the service catalog for healthcheck uris..... (kidding!) | |
| 17:31:34 | dtantsur | welll | |
| 17:31:42 | dtantsur | it's kind of these additional fields in DNS, right? | |
| 17:31:57 | elmiko | metadata all the things! \o/ | |
| 17:32:15 | dtantsur | so we probably could do it.. but then the monitoring tools will have to learn about the catalog | |
| 17:35:46 | elmiko | ok, i'm headed out for lunch. take care all o/ | |
| 17:36:59 | dtantsur | yeah, I should go as well | |
| #openstack-sdks - 2019-01-18 | |||
| 07:30:24 | openstackgerrit | Sundar Nadathur proposed openstack/service-types-authority master: Add Cyborg as accelerator service. https://review.openstack.org/631718 | |
| 17:09:42 | openstackgerrit | Sundar Nadathur proposed openstack/service-types-authority master: Add Cyborg as accelerator service. https://review.openstack.org/631718 | |