Earlier  
Later
New Search
Posted Nick Remark
#openstack-sdks - 2019-01-17
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
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
17:16:22 openstackgerrit Dmitry Tantsur proposed openstack/openstacksdk master: Return retries on HTTP CONFLICT to baremetal.attach_vif_to_node https://review.openstack.org/631836
17:16:23 creepy_owlet mordred: bugs, bugs everywhere ^^^
17:17:21 mordred creepy_owlet: oh wow
17:17:38 mordred Shrews: you wanna look at that? ^
17:17:51 creepy_owlet why wouldn't you use the same HTTP code for user's error and for an unforeseeable internal condition? >_<
17:27:04 mordred creepy_owlet: no good reason I can see :)
17:27:09 creepy_owlet heh
17:28:09 openstackgerrit Dmitry Tantsur proposed openstack/openstacksdk master: Add baremetal Node fields from versions 1.47 - 1.49 https://review.openstack.org/631841
17:38:11 openstackgerrit Merged openstack/service-types-authority master: Add Cyborg as accelerator service. https://review.openstack.org/631718
17:53:05 openstackgerrit OpenStack Proposal Bot proposed openstack/os-service-types master: Updated from OpenStack Service Type Authority https://review.openstack.org/631850
18:00:54 Shrews mordred: looking

Earlier   Later