Earlier  
Later
New Search
Posted Nick Remark
#openstack-sdks - 2017-08-08
16:34:30 cdent sdague, dhellmann : however I think much of what is said there is confusion over how placement and nova are nearby
16:34:57 sdague yeh
16:35:56 sdague it also doesn't seem to mention developer.openstack.org, as this would implicitely remove that
16:36:16 sdague however the developer experience folks were very very strongly in the camp that it was important that that was a top level construct
16:38:42 sdague and, actually, that ends up making the api-ref versioned per release, which is something we very much don't want to do
16:38:55 cdent very good point
16:42:40 sdague I left a post hoc comment in https://review.openstack.org/#/c/472275/13
16:45:50 cdent sdague: cool. I’m going to push up a new gate job, which will make note of some of the conversation here and refer back to the abandoned one
17:01:29 cdent sdague: i made a new job, because i was nearly all the way done before I found the abandoned one: https://review.openstack.org/491860
17:03:01 cdent thanks
17:39:10 mordred cdent, sdague: I haven't read the whole backscroll yet - but one of the issues is that osme of hte tooling currently expects to be able to find "the project" for a given service-type ... and also expects to be able to find the service-type for a given project (the verficiation that docs are going to the right place)
17:39:51 mordred I had punted on sorting that out in my brain a bit - but if we need to sort it out I can re-prioritize my internal ring-buffer ...
17:41:47 cdent Even if we set aside the problem that placement presents in that model, it seems bad to limit a project to just one service-type?
17:42:17 cdent it seem we _can_ have multiple types per project but it sounds like the mental model isn’t that?
17:48:12 openstackgerrit Merged openstack/osc-lib feature/osc4: Revert "Update UPPER_CONSTRAINTS_FILE for feature/osc4" https://review.openstack.org/489664
18:27:06 dhellmann cdent, sdague : I expect the topic of the api ref stuff to come up at the ptg on mon/tue with the docs team. I hope you can participate in that conversation.
18:27:34 dhellmann that move was originally supposed to be part of phase 2 of the migration, so if we decide to skip it it's less work for most everyone
19:02:42 sdague dhellmann: sure. I think in some of the docs migration there were missing bits of what's per release and what's master only. And you can't mix those in a single doc tree
19:03:17 dhellmann well, we did acknowledge that, we just didn't necessarily think we "couldn't" mix them
19:03:46 dhellmann huge amounts of the docs don't change from cycle to cycle; this is just one area
19:04:32 sdague but it means you'd have a published pike tree linking to pike version docs that should only have a master existing
19:04:45 dhellmann why "should only"?
19:04:58 sdague because some docs only are supposed to exist on master
19:05:00 sdague like api-ref
19:05:08 sdague by design
19:05:09 dhellmann you're arguing with a tautology
19:05:31 dhellmann what's special about api docs that makes it invalid to publish from branches?
19:05:46 sdague because there should only ever be one copy and it should cover all released api
19:05:53 cdent a microversioned api just exists as a whole
19:06:01 cdent there is no pike, ocata, newton
19:06:08 sdague and if there is more than one copy then you need to backport fixes or have multiple clocks saying different things
19:06:24 dhellmann ok
19:06:52 dhellmann I don't see the big deal in saying "there may be newer docs than this, check your API version" but it's not a big deal to me -- not combining those builds means less work next cycle
19:07:15 dhellmann I'm optimizing for the fact that our doc contributor base is decimated; you have other priorities.
19:07:35 sdague dhellmann: the reason for that was optimizing for small contributor bases
19:07:52 sdague because it removes the need to backport corrections on docs
19:08:05 sdague as there is a single source of truth, and only one publish point
19:08:09 dhellmann I guess I don't agree with the premise that there's any reason to backport doc fixes that are not related to code fixes.
19:08:16 dhellmann but I see your point
19:08:21 sdague dhellmann: because the docs aren't 100% accurate
19:08:29 dhellmann yes, well, welcome to this universe
19:08:48 dhellmann I don't actually care about the api docs myself, so as I said, I'm happy to leave all of that alone.
19:08:52 sdague ok
19:09:03 dhellmann that is, I don't care so much about integrating them that I actually want to have the argument
19:11:44 cdent I think, at least for microversioned systems and for people who are talking to multiple different cloud where they don’t necessarily know the version of the cloud, the main isssue is the multiple clocks. We dont want that in api-ref docs. The bit about backports is less relevant.
20:24:40 openstackgerrit Eric Fried proposed openstack/keystoneauth master: WIP: Adapter.get_conf_options(deprecated_opts) https://review.openstack.org/490895
20:57:33 openstackgerrit Eric Fried proposed openstack/keystoneauth master: Adapter.get_conf_options(deprecated_opts) https://review.openstack.org/490895
21:32:07 openstackgerrit Eric Fried proposed openstack/keystoneauth master: Protect against missing interface attribute https://review.openstack.org/488568
21:48:35 openstackgerrit Eric Fried proposed openstack/keystoneauth master: Protect against missing interface attribute https://review.openstack.org/488568
21:48:36 openstackgerrit Eric Fried proposed openstack/keystoneauth master: Adapter.get_conf_options(deprecated_opts) https://review.openstack.org/490895
22:43:30 openstackgerrit Eric Fried proposed openstack/keystoneauth master: WIP: Return the endpoint_override from EndpointData https://review.openstack.org/491947
#openstack-sdks - 2017-08-09
01:22:09 openstackgerrit OpenStack Proposal Bot proposed openstack/os-client-config master: Updated from global requirements https://review.openstack.org/491294
04:21:13 openstackgerrit Artur Basiak proposed openstack/service-types-authority master: Add monasca-events-api project https://review.openstack.org/490750
04:50:52 openstackgerrit Merged openstack/python-openstackclient master: Add new commands for karbor osc plugin https://review.openstack.org/491416
14:09:36 openstackgerrit liyi proposed openstack/python-openstacksdk master: Add profile type ops cli https://review.openstack.org/492048
14:22:42 openstackgerrit Eric Fried proposed openstack/service-types-authority master: Change default swift name to object-storage https://review.openstack.org/462138
14:25:24 openstackgerrit Merged openstack/service-types-authority master: Add and rename monitoring services https://review.openstack.org/487484
14:25:48 openstackgerrit Merged openstack/service-types-authority master: Add monasca-events-api project https://review.openstack.org/490750
14:38:02 openstackgerrit Eric Fried proposed openstack/service-types-authority master: Add placement service https://review.openstack.org/462140
15:40:06 cmurphy mordred: efried I had a customer report https://bugs.launchpad.net/keystoneauth/+bug/1709658 to me, it seems like there was some surprising behavior in ksa 2.x that was fixed in a backwards incompatible way
15:40:07 openstack Launchpad bug 1709658 in keystoneauth ""Could not find requested endpoint in Service Catalog" when requesting unavailable identity endpoint" [Undecided,New]
15:41:06 cmurphy I will try to look into it later tonight or tomorrow morning if it doesn't nerdsnipe you sooner
15:41:08 efried cmurphy Looking. But given what I was playing around with yesterday, I'm probably not going to be surprised...
15:42:21 efried cmurphy Oh, okay, this has nothing to do with what I saw yesterday. But yeah, this looks like RBB to me.
16:40:12 mordred cmurphy: yay nerdsniping
16:42:41 mordred cmurphy: oh - fun. so - I haven't started digging in to the code yet, but there's an additional weirdness in there, which is OS_IDENTITY_API_VERSION and how that's getting set or not via python-openstackclient
16:45:19 mordred cmurphy: I asked for some additional informatoin in the bug
18:14:16 cdent mordred: you might know this, but anyone else feel free to chime in: Is there a canonical doc somewhere on what the service catalog is and is for?
18:15:46 cdent there’s plenty of stuff near to that, but what I’ve been able to find so far glances off being what I’m looking for
18:54:37 mordred cdent: maybe? can you say that same thing maybe in different words though, I may misunderstand the question
18:54:57 cdent mordred: I can link you to why it matters, one moment
18:55:17 cdent mordred: see the discussion with edleafe here: https://review.openstack.org/#/c/491611/
18:57:02 mordred cdent: hrm. this is deeper and more philosophical
18:57:09 mordred cdent: (and important, obvs)
18:58:52 mordred cdent: I do not believe there is a document that explains service catalog intent at a high level
18:59:02 mordred cdent: but I do believe having such a document would be helpful
19:00:26 cdent “service catalog intent” is the right phrase
19:01:21 mordred yah. I mean, it has a very specific purpose in openstack, but is also completely posible for a deployer to stick other things in it too.sticking other things in it wn't neccessarily mean any tools will know what to do with those things
19:01:32 mordred cdent: also, I'd suggest that we write https://review.openstack.org/#/c/491611/ as more of a sliding scale of recommendations to accomodate things that provide capabilities discovery ... but maybe I should, you know, leave a review comment
19:02:33 cdent a) maybe, b) yes, c) I really wanted to keep this thing as simple as possible and while we don’t currently have a standard for capabilities the “safe” strategy is NO
19:11:13 mordred cdent: totally - and I agree with that broadly - I mostly worry that if we published an API-WG recommendation that is wildly contrary to widespread practice without including accomodation in some manner for how people are doing things today that we run the risk of being disregarded which would be bad
19:11:40 mordred aw. cdent missed my response
19:59:50 openstackgerrit Merged openstack/keystoneauth master: Parameter to tune mutual authentication in kerberos https://review.openstack.org/455330
21:22:48 mordred efried: I was working a patch a few seconds ago using the new ksa stuff - and the Adapter _would_not_ actually consume the version arg I was passing it and I was starting to freak out that we'd released a completely broken thing ...
21:23:07 mordred efried: turns out I was overwriting the object due to copy-pasta acouple of lines below. WHOOPS
21:23:28 efried mordred Phew.
21:23:34 efried Wait.
21:23:37 mordred right?
21:23:59 efried Not phew, you're saying you overwrote the object in your consuming patch, or you found a real bug in ksa?
21:24:05 mordred no - in my consuming patch
21:24:13 efried phew, I say again.
21:24:13 mordred totally just dumb PEBKAC on my part
21:24:20 mordred but WOW did I have print statements EVERYWHERE
21:24:26 efried hahaha
21:24:31 mordred *why is this not using the right url????*
21:24:46 efried I'm experiencing an interesting oslo_config possible-bug.
21:25:02 efried As I'm deprecating old opts with new adapter ones...
21:25:07 mordred ooh. that sounds like fun
21:25:15 efried The option comes through to the real code correctly, but in UT when we do CONF.set_override, it doesn't.
21:25:39 mordred I love it when there's a bug in unittests that is just a bug in unittests

Earlier   Later