Earlier  
Later
New Search
Posted Nick Remark
#openstack-sdks - 2017-08-18
22:38:36 openstackgerrit Michael Johnson proposed openstack/python-openstacksdk master: Introduce L7Rule for Octavia (load balancing) https://review.openstack.org/452832
23:02:34 juliandemille Does anyone know how to deal with "__init__() got an unexpected keyword argument 'user_domain_name'" in the Python client?
#openstack-sdks - 2017-08-19
00:20:11 openstackgerrit Rajath Agasthya proposed openstack/cliff master: Move comments up in [extras] section of setup.cfg https://review.openstack.org/495460
00:20:23 openstackgerrit Rajath Agasthya proposed openstack/cliff master: Updated from global requirements https://review.openstack.org/494775
02:03:49 openstackgerrit TingtingYu proposed openstack/python-openstacksdk master: fix the bug that cannot create a listener by openstacksdk https://review.openstack.org/493449
02:59:12 openstackgerrit ShangXiao proposed openstack/cliff master: Fix typos and replace http with https for doc links in cliff https://review.openstack.org/495477
05:42:33 openstackgerrit Reedip proposed openstack/python-openstackclient master: [WIP]Allow for Bulk Floating IP creation https://review.openstack.org/405145
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 cdent sta has plenty of examples, yes?
16:33:09 mordred cool! are there?
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

Earlier   Later