| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-sdks - 2019-01-17 | |||
| 17:04:38 | evrardjp | edleafe: not right nwo | |
| 17:04:41 | aspiers | I think the idea was to specify it in the path | |
| 17:04:47 | aspiers | but we're open to recommendations | |
| 17:04:59 | aspiers | https://review.openstack.org/#/c/617924/1/oslo_middleware/healthcheck/__init__.py | |
| 17:05:09 | aspiers | is the WIP prototype from mugsie | |
| 17:05:14 | edleafe | Generally a header is preferred over mangling the path with version info | |
| 17:05:17 | aspiers | I'm just polishing it up now | |
| 17:05:20 | dtantsur | elmiko: cool! | |
| 17:05:32 | aspiers | edleafe: OK, but this would be a different header to the normal microversion? | |
| 17:05:52 | dtantsur | "normal microversion"? :D | |
| 17:05:52 | elmiko | dtantsur: you gonna be at devconf? | |
| 17:05:59 | dtantsur | elmiko: devconf.cz - yep | |
| 17:06:02 | evrardjp | aspiers: it could technically be the same header, it's a different path | |
| 17:06:20 | mugsie | in this case, there is a pre-existing URL, so it should be something like /status - move away from the /healthcheck that v1 uses | |
| 17:06:22 | dtantsur | OpenStack-Api-Version: compute 2.42, healthcheck 1.1\ | |
| 17:06:24 | dtantsur | or something | |
| 17:06:25 | elmiko | dtantsur: \o/ | |
| 17:06:28 | aspiers | right, that one | |
| 17:06:40 | edleafe | aspiers: microversions are per-call | |
| 17:06:40 | evrardjp | mugsie: I like that idea | |
| 17:06:51 | aspiers | edleafe: sure | |
| 17:06:58 | aspiers | evrardjp: me too | |
| 17:07:04 | aspiers | status can be about more than just health | |
| 17:07:09 | mugsie | and microversions make it unusable for a lot of monitoring application uses - so we should avodi it if possible | |
| 17:07:09 | cdent | I think if we want the middleware to be super easy, all it should be is a path | |
| 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 | dtantsur | so if we declare a standard endpoint, we may want it verbose. something like /openstack-status | |
| 17:07:58 | edleafe | mugsie: my only concern is when you run out of synonyms for 'healthcheck' :) | |
| 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 | aspiers | edleafe: https://storyboard.openstack.org/#!/story/2001439 | |
| 17:14:53 | mugsie | edleafe: the old one misses some information, and the body changes | |
| 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 | edleafe | dtantsur: it'll cure your insomnia :) | |
| 17:15:56 | dtantsur | so, breaking changes? | |
| 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 | |