Earlier  
Later
New Search
Posted Nick Remark
#openstack-sdks - 2019-01-17
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
18:02:27 Shrews mordred: umm, since dtantsur|afk specifically had a note to NOT retry on conflict, I'd prefer he look at that
18:03:59 Shrews that change is a direct contradiction to that
18:11:27 mordred Shrews: that is a change from dtantsur|afk
18:12:21 Shrews mordred: HAHAHA
18:13:00 Shrews so creepy_owlet was dtantsur|afk ??
18:13:13 Shrews names are hard
18:14:45 mordred Shrews: yah. it's casual nick friday
21:43:42 openstackgerrit Merged openstack/openstacksdk master: Add baremetal Node fields from versions 1.47 - 1.49 https://review.openstack.org/631841
#openstack-sdks - 2019-01-19
13:17:16 openstackgerrit Merged openstack/openstacksdk master: Return retries on HTTP CONFLICT to baremetal.attach_vif_to_node https://review.openstack.org/631836
#openstack-sdks - 2019-01-21
09:45:07 openstackgerrit Artem Goncharov proposed openstack/openstacksdk master: WIP Add DNS support https://review.openstack.org/623009
#openstack-sdks - 2019-01-22
01:57:27 openstackgerrit caoyuan proposed openstack/os-client-config master: Update hacking version to latest https://review.openstack.org/628597
07:31:19 openstackgerrit zhouxinyong proposed openstack/api-sig master: Change openstack-dev to openstack-discuss in setup.cfg https://review.openstack.org/632255
08:26:07 openstackgerrit zhouxinyong proposed openstack/cliff master: Change openstack-dev to openstack-discuss in setup.cfg https://review.openstack.org/632295
09:00:14 openstackgerrit Dmitry Tantsur proposed openstack/openstacksdk master: Fixed incorrect exception raising in configdrive generation https://review.openstack.org/632326
09:20:01 openstackgerrit Dmitry Tantsur proposed openstack/openstacksdk master: Fixed incorrect exception raising in configdrive generation https://review.openstack.org/632326
11:16:06 openstackgerrit Jens Harbott (frickler) proposed openstack/openstacksdk master: Update cirros version for functional tests https://review.openstack.org/632415
11:16:59 frickler mordred: Shrews: ^^ we need to match devstack again
11:27:01 dtantsur ugh
11:35:27 openstackgerrit zhouxinyong proposed openstack/oaktree master: Change openstack-dev to openstack-discuss in setup.cfg https://review.openstack.org/632424
11:38:38 openstackgerrit zhouxinyong proposed openstack/oaktreemodel master: Change openstack-dev to openstack-discuss in setup.cfg https://review.openstack.org/632426
11:52:56 openstackgerrit zhouxinyong proposed openstack/openstackclient master: Change openstack-dev to openstack-discuss in setup.cfg https://review.openstack.org/632439
12:16:04 openstackgerrit zhouxinyong proposed openstack/osc-lib master: Fix author-email in setup.cfg https://review.openstack.org/632450

Earlier   Later