| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-sdks - 2019-01-17 | |||
| 16:00:18 | tosky | those low-cost companies | |
| 16:00:20 | dtantsur | ah this low-cost world | |
| 16:00:29 | dtantsur | great minds think alike, yeah? | |
| 16:00:46 | edleafe | You'd think moving from a WG to a SIG would be a step up, right? | |
| 16:00:50 | tosky | :D | |
| 16:01:23 | elmiko | o/ | |
| 16:01:34 | elmiko | someone say drinks? | |
| 16:02:15 | dtantsur | lol | |
| 16:56:45 | elmiko | heads up edleafe dtantsur, i'll be on CET next week so i will most likely show up for the early session (gonna be at a conference) | |
| 16:56:55 | edleafe | elmiko: ack | |
| 17:03:07 | aspiers | hi... we have a question about what the path for the new version of the oslo.middleware healthcheck API should be | |
| 17:03:30 | aspiers | IIUC the current one is /healthcheck | |
| 17:04:14 | aspiers | no doubt I'm about to ask a stupid question as never worked with OpenStack API code before | |
| 17:04:18 | aspiers | but I guess /v2/healthcheck is a bad idea since that stomps on the whole microversion thing? | |
| 17:04:30 | edleafe | aspiers: I'm not familiar with the usage. Do users specify a version for the healthcheck call? | |
| 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 :) | |