| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-sdks - 2017-08-19 | |||
| 20:38:16 | openstackgerrit | Michael Johnson proposed openstack/python-openstacksdk master: Introduce L7Rule for Octavia (load balancing) https://review.openstack.org/452832 | |
| #openstack-sdks - 2017-08-20 | |||
| 06:02:20 | openstackgerrit | Merged openstack/python-openstacksdk master: Introduce L7Policy for Octavia (load balancing) https://review.openstack.org/451980 | |
| 06:03:39 | openstackgerrit | Merged openstack/python-openstacksdk master: Introduce L7Rule for Octavia (load balancing) https://review.openstack.org/452832 | |
| #openstack-sdks - 2017-08-21 | |||
| 02:11:13 | openstackgerrit | TingtingYu proposed openstack/python-openstacksdk master: fix the bug that cannot create a listener by openstacksdk https://review.openstack.org/493449 | |
| 02:12:07 | openstackgerrit | TingtingYu proposed openstack/python-openstacksdk master: fix the bug that cannot create a listener by openstacksdk https://review.openstack.org/493449 | |
| 03:12:44 | openstackgerrit | Merged openstack/python-openstacksdk master: fix the bug that cannot create a listener by openstacksdk https://review.openstack.org/493449 | |
| 14:25:36 | openstackgerrit | Eric Fried proposed openstack/service-types-authority master: Generate standard api_reference https://review.openstack.org/495887 | |
| 14:31:34 | efried | mordred ^ | |
| 14:31:55 | cdent | efried: is there a “why” for that, or just cuz it’s tidy? | |
| 14:32:17 | efried | cdent See argument... ahem, "discussion" here: https://review.openstack.org/#/c/495326/1 | |
| 14:33:58 | cdent | so, there are plenty of projects that don’t publish their api-ref to … /api-ref | |
| 14:34:11 | cdent | they put it somewhere in docs | |
| 14:34:16 | cdent | (docs.o.o) | |
| 14:36:51 | efried | cdent Right, left the ability to customize. | |
| 14:37:21 | cdent | efried: in your change, yeah, but in monty’s change, it appears to be making an assumption | |
| 14:37:44 | cdent | and using only the service type, not the doc info | |
| 14:38:13 | efried | cdent Right. | |
| 14:38:44 | efried | Though to be fair, it's only redirecting from certain URLs involving service type aliases. | |
| 14:39:37 | efried | So my opinion was that we should always redirect from /api-ref/{alias or service type} to {the api_reference from sta, whatever that may be} | |
| 14:39:43 | cdent | efried: sure, but after redirecting to the actual service type it’s still possible to get a 404 | |
| 14:39:51 | efried | cdent Totally. | |
| 14:39:55 | cdent | yeah, that’s what I think too | |
| 14:40:11 | efried | Because theoretically not possible to get a 404 from whatever's in the api_reference fierd in sta | |
| 14:40:13 | efried | field | |
| 14:41:02 | efried | thanks for the backup :) Helps me to know that I'm not crazy (or, if I am, I've got company) | |
| 14:41:41 | cdent | i’m totally crazy | |
| 16:25:19 | mordred | efried, cdent: I believe the effort dhellmann has been undertaking is to enforce that projects publish their api docs to /api-ref/{service-type} | |
| 16:25:53 | mordred | there's gate jobs in project-config to ensure api doc publication goes to the correct place | |
| 16:26:16 | mordred | so while I agree that up until now there has not been consistency, my understand (which might be wrong) is that the intent is to fix that | |
| 16:26:54 | efried | mordred Seems like a good interim solution to allow overrides from sta, so we can immediately start using api_reference from https://review.openstack.org/#/c/495326/ et al; then as projects become conformant, we just have to remove their overrides from sta. | |
| 16:27:15 | efried | And when they're all done, we could (but don't have to) even remove the override ability from sta. | |
| 16:28:28 | mordred | efried: yah - for sure | |
| 16:29:03 | mordred | efried: I think that's a great plan - mostly just wanted to get on the same page WRT end-goal | |
| 16:29:06 | cdent | it would be useful if we could have exactly one source of authority for this stuff; which is why I was nervous about including anything other than services in sta | |
| 16:29:33 | cdent | so if we’ve got a path to migrating away from including the doc info, I’m into that, but agree with efried that we need the overrides for now | |
| 16:29:44 | mordred | agree | |
| 16:30:25 | efried | mordred cdent My main goal here was to avoid having multiple disparate sources of the official API reference URL. | |
| 16:30:26 | mordred | themost important thing for sta to be the authority on is "this is the service-type name for this project and it used to be called these things" | |
| 16:31:33 | mordred | efried: yup | |
| 16:31:42 | efried | That is, I didn't want sta to be saying "the API reference is <result of some calculation, or this override>" and then api-site to be saying "the API reference is <result of some calculation whose logic might sort of duplicate what's in sta, but might diverge at some point if we forget or aren't careful>" | |
| 16:31:53 | mordred | efried: +1000 | |
| 16:32:00 | mordred | efried: we share the same goal :) | |
| 16:32:05 | efried | Sweet. | |
| 16:32:06 | cdent | I’ll see that 1000 and raise 10000 | |
| 16:32:54 | mordred | so - I thnk honestly step 1 is to verify whether there are actually any non-compliant api-ref docs | |
| 16:33:00 | efried | mordred Did that. | |
| 16:33:09 | mordred | cool! are there? | |
| 16:33:09 | cdent | sta has plenty of examples, yes? | |
| 16:33:18 | mordred | sta is, I think, out of date | |
| 16:33:24 | efried | mordred The ones that are still in https://review.openstack.org/#/c/495887/ are non-compliant | |
| 16:33:46 | efried | Because I checked the "official" constructed URL for all of those and it's 404. | |
| 16:33:48 | cdent | “out of date” :) some authority ;) | |
| 16:34:07 | mordred | ah. awesome | |
| 16:34:39 | efried | Well, I didn't check the URLs that are in there to make sure they're *not* 404 :) | |
| 16:34:48 | efried | 13 of 'em, I think. | |
| 16:37:13 | efried | They're all good except for https://developer.openstack.org/api-ref/monitoring-events-api/ - which I think we knew was still in the works. (Also, https://git.openstack.org/cgit/openstack/zun/tree/api-ref/source is a source tree.) | |
| 16:40:11 | efried | I can't tell from https://review.openstack.org/#/c/482443/ where those docs are going to land. | |
| 16:49:47 | mordred | efried: - api-ref-jobs: | |
| 16:49:49 | mordred | service: monitoring-events | |
| 16:50:06 | mordred | efried: that's what's in jenkins/jobs/projects.yaml | |
| 16:50:26 | efried | mordred Then we should whack that guy's override from https://review.openstack.org/#/c/495887/ | |
| 16:51:00 | mordred | it doens't look like thaturl exists though - so maybe no docs have published since that job definition landed? | |
| 16:51:14 | efried | mordred The above change set hasn't merged yet. | |
| 16:51:40 | efried | Point is, both URLs are 404, but once https://review.openstack.org/#/c/482443/ lands, it'll be the right one, so we should remove the override. | |
| 16:52:35 | mordred | agree | |
| 16:52:40 | openstackgerrit | Eric Fried proposed openstack/service-types-authority master: Generate standard api_reference https://review.openstack.org/495887 | |
| 16:52:44 | efried | Cool. ^^ | |
| #openstack-sdks - 2017-08-22 | |||
| 00:35:08 | openstackgerrit | OpenStack Proposal Bot proposed openstack/cliff master: Updated from global requirements https://review.openstack.org/494775 | |
| 01:45:39 | openstackgerrit | liuxiaoyang proposed openstack/python-openstacksdk master: Add doc8 rule and check doc/source files https://review.openstack.org/496058 | |
| 05:35:19 | openstackgerrit | Vitalii Kulanov proposed openstack/cliff master: Update doc on Sphinx integration process https://review.openstack.org/493869 | |
| 08:09:28 | openstackgerrit | lidong proposed openstack/python-openstacksdk master: Update links in README https://review.openstack.org/496145 | |
| 08:59:18 | openstackgerrit | Chris Dent proposed openstack/microversion-parse master: Provide a helper method to get headers from environ https://review.openstack.org/495356 | |
| 09:45:32 | openstackgerrit | Shinya Tsunematsu proposed openstack/python-openstackclient master: enable glance client to support client cert https://review.openstack.org/496178 | |
| 09:55:10 | openstackgerrit | Shinya Tsunematsu proposed openstack/python-openstackclient master: enable glance client to support client cert https://review.openstack.org/496178 | |
| 10:17:26 | openstackgerrit | Stephen Finucane proposed openstack/cliff master: sphinxext: Correct issues with usage formatting https://review.openstack.org/496189 | |
| 11:34:11 | openstackgerrit | Merged openstack/python-openstacksdk master: Update links in README https://review.openstack.org/496145 | |
| 11:53:35 | openstackgerrit | Chris Dent proposed openstack/microversion-parse master: Import functions from placement https://review.openstack.org/496212 | |
| 11:53:44 | cdent | elmiko: ^ | |
| 12:32:21 | elmiko | cdent: ack | |
| 16:33:30 | openstackgerrit | Merged openstack/cliff master: sphinxext: Correct issues with usage formatting https://review.openstack.org/496189 | |
| 17:08:31 | openstackgerrit | Harry Rybacki proposed openstack/python-openstackclient master: Implied Roles https://review.openstack.org/290253 | |
| 17:53:21 | openstackgerrit | Akihiro Motoki proposed openstack/cliff master: Fix regexp for detecting long options https://review.openstack.org/486562 | |
| 17:53:41 | amotoki | stephenfin: stevemar: more cliff regexp fix ^^ | |
| 18:20:58 | openstackgerrit | Vitalii Kulanov proposed openstack/cliff master: Update doc on Sphinx integration process https://review.openstack.org/493869 | |
| 19:24:45 | cdent | efried, mordred : you two may have input on https://review.openstack.org/#/c/496321/ (governance change fixing api-doc links) | |
| 19:25:32 | efried | cdent Looking... | |
| 19:31:58 | efried | cdent Thanks for the heads up. Not sure how that yaml is used, but I assume it's parsed/converted somewhere. And that somewhere ought to use sta to populate those api links. | |
| 19:32:25 | efried | servce-types-authority should be authoritative; swhy it's called 'authority'. | |
| 19:32:48 | cdent | well, yes and no. Originally it was authoritative service types. And that’s it. | |
| 19:33:00 | cdent | It’s only recently that it arrogated authority for lots of other stuff | |
| 19:33:10 | cdent | which is probably good and just, but shouldn’t be assumed (yet) | |
| 19:39:56 | efried | fair enough | |
| 20:45:04 | cdent | edleafe: i’m working on your comments on https://review.openstack.org/#/c/496212/1/microversion_parse/tests/test_extract_version.py,unified and I’m not sure how to make you happy | |
| 20:54:17 | openstackgerrit | Chris Dent proposed openstack/microversion-parse master: Provide a helper method to get headers from environ https://review.openstack.org/495356 | |
| 20:54:17 | openstackgerrit | Chris Dent proposed openstack/microversion-parse master: Import functions from placement https://review.openstack.org/496212 | |
| 21:08:42 | edleafe | Nothing makes me happy! | |
| 21:11:04 | edleafe | cdent: it's things like 'test_version_is_tuple' that checks that it's equal to '1.5' | |
| 21:12:00 | edleafe | Maybe rename the class 'TestVersion1_5' or something :) | |
| 21:12:28 | cdent | I’m still not grokking what you want instead | |
| 21:13:30 | edleafe | it's the "action at a distance" feeling | |