Earlier  
Posted Nick Remark
#openstack-sdks - 2019-01-15
15:43:53 samueldmq more especifically on refstack's gaps
15:48:40 mordred samueldmq: yes - but today is probably not the right day for it - I'm in a very strange fog of jetlag, so I'm likely to say very dumb things :)
15:51:03 samueldmq mordred: sure - I will tell you so you think/remember about it. I just want a example of one of refstack's lacunae in interop (we said it has no consensus on some things, but no e.g.)
15:53:18 samueldmq mordred: we talk about it in the week when you recover, see ya
15:55:52 mordred samueldmq: yay! see ya ...
#openstack-sdks - 2019-01-16
05:34:48 openstackgerrit lijunjie proposed openstack/python-openstackclient master: Fix the misspelling of "required" https://review.openstack.org/631135
19:34:03 openstackgerrit Dean Troyer proposed openstack/python-openstackclient master: fix multiple server delete produce multiple new lines https://review.openstack.org/627493
22:39:56 openstackgerrit Merged openstack/python-openstackclient master: fix multiple server delete produce multiple new lines https://review.openstack.org/627493
#openstack-sdks - 2019-01-17
01:07:37 openstackgerrit Duc Truong proposed openstack/openstacksdk master: Change Resource location type to Header https://review.openstack.org/631362
15:31:21 openstackgerrit Monty Taylor proposed openstack/openstacksdk master: Add class to override clustering delete responses https://review.openstack.org/631362
15:58:34 edleafe API-SIG Office Hour starts in 2 minutes. Buckle your seat belts!
15:59:25 dtantsur do they serve drinks in this flight?
15:59:42 edleafe Yes, but they're cash-only
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 elmiko dtantsur: you gonna be at devconf?
17:05:52 dtantsur "normal microversion"? :D
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 evrardjp mugsie: I like that idea
17:06:40 edleafe aspiers: microversions are per-call
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 cdent I think if we want the middleware to be super easy, all it should be is a path
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: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

Earlier   Later