Earlier  
Posted Nick Remark
#openstack-sdks - 2019-10-01
15:26:24 gtema those clear requirements were lost
15:32:03 efried mordred: Is sdk *supposed* to be getting the newest rather than the oldest microversion by default? (by design)
15:32:15 mordred nope
15:32:34 efried okay, reread your first message, got it.
15:32:44 mordred so - you know - bugs all around :)
15:32:49 efried Though I would imagine specific operations would explicitly use newer microversions under the covers.
15:32:55 mordred yes - absolutely!
15:33:02 mordred and for those it should absolutely use them
15:33:37 efried but, like, something where /foo changes payload formats with different microversions, and we have a foos() method, I guess we would need you to tell us which shape you wanted the response to take.
15:33:42 mordred we just might need to take additional action sdk-side to keep the sdk api consistent, so we want to opt-in to microversion changes (which is one of the reasons I've become an ardent supporter of microversions)
15:33:52 efried unless we obscure all of that by objectifying the response
15:34:06 efried but there again, some fields might be present/absent depending
15:34:32 mordred yah- in the normal shade and sdk layer, we obscure by objectifying. if you want the REST layer and know what you're doing, requesting like 2.latest should be fine
15:35:02 efried presumably the microversion kwarg passes through request() seamlessly still?
15:35:07 mordred yup
15:35:19 efried yeah, it must, because we're using it for placement from nova
15:35:34 mordred fields being different, specifically flavor, is what caused the tests to catch that the ksa 401 fix had unbroken a discovery thing that was accidentally keeping sdk working properly :)
15:35:40 efried ...unless we're getting the latest, which would also be working without us knowing...
15:36:04 efried yeesh, so we have to fix ksa and then blacklist the fix from sdk until we fix sdk?
15:36:19 mordred no - we can fix sdk before we fix ksa
15:36:21 efried I had a mentor early in my career who called this RBB
15:36:25 efried Revoked Bug Benefit
15:36:28 mordred yah
15:36:36 mordred it's a good term
15:37:13 efried mordred: well, in other news, I think I got compute versioned discovery unauthed working: https://review.opendev.org/685181
15:37:41 mordred \o/
15:37:50 efried question is whether the change in NoAuthMiddleware is going to be acceptable. I would hope that's not being used outside of our own testing, but it seems technically supported by our conf, so I'm not sure.
15:37:57 mordred I'm glad it was broken though - look at all the other stuff we get to fix
15:38:01 efried Unfortunately, people who would know or care seem to be sparse.
15:38:02 efried yeah
15:52:45 openstackgerrit Monty Taylor proposed openstack/keystoneauth master: Fetch discovery documents with auth when needed https://review.opendev.org/685042
15:54:02 openstackgerrit Monty Taylor proposed openstack/openstacksdk master: Use has_service in functional test's require_service https://review.opendev.org/685995
15:59:15 mordred efried, gtema: I *think* that should handle all the things except for the nova microversion issue
15:59:27 gtema cool
16:00:18 efried ack
16:04:18 openstackgerrit Monty Taylor proposed openstack/keystoneauth master: Fetch discovery documents with auth when needed https://review.opendev.org/685042
16:11:42 mordred gtema, efried: BWAHAHAHAHA. it's "not a bug" that we're requesting a later microversion from nova - we actually bumped the sdk layer microversion for the server resource
16:12:08 mordred but - because of the other bug, we never actually were getting 2.72 payloads in devstack and didn't notice we needed to update our flavor support
16:12:33 gtema life is perfect
16:12:48 gtema (unless one touches anything)
16:12:55 mordred yeah
16:14:04 gtema discovery and microversions are voodoo things in OpenStack
16:23:42 openstackgerrit Monty Taylor proposed openstack/openstacksdk master: Fix server for later microversion https://review.opendev.org/685999
16:24:42 mordred gtema: yah. although they wouldn't have been if the client libraries hadn't hardcoded around them and if people hadn't put versioned endpoints in the catalog for the last 9 years. like - there was this whole system that literally nobody actually used :(
16:24:59 gtema sure
16:25:27 gtema hope we will fix it now with Nova switched to SDK and others using it deeper
16:27:21 mordred gtema: or we've just opened ourselves to a new kind of pain
16:35:11 gtema that's of course as well
#openstack-sdks - 2019-10-02
09:17:24 openstackgerrit Artem Goncharov proposed openstack/python-openstackclient master: Switch image to use SDK https://review.opendev.org/650374
12:39:54 openstackgerrit Artem Goncharov proposed openstack/python-openstackclient master: Switch image to use SDK https://review.opendev.org/650374
15:38:01 openstackgerrit Stephen Finucane proposed openstack/cliff master: Blacklist bandit 1.6.0 due to directory exclusion bug https://review.opendev.org/658522
15:39:35 tosky stephenfin: I think also 1.6.1 and 1.6.2 are buggy, I had to stick to <1.6.0 in sahara
15:41:47 openstackgerrit Stephen Finucane proposed openstack/cliff master: Switch to stestr https://review.opendev.org/581564
15:41:57 stephenfin tosky: Hmm, really? That was just a rebase of amotoki's patch
15:42:35 tosky stephenfin: that was proposed in May, when 1.6.{1,2} have not been released yet
17:25:09 openstackgerrit Merged openstack/cliff master: Modify the help message of `-c`/`--column` parameter https://review.opendev.org/672852
19:34:33 openstackgerrit Merged openstack/cliff master: Add an errexit attribute to InteractiveApp to exit on command errors https://review.opendev.org/511971
19:36:48 openstackgerrit Merged openstack/cliff master: Allow finding command by partial name https://review.opendev.org/552970
#openstack-sdks - 2019-10-03
09:26:31 stephenfin amotoki: Morning. Could I ask you to look at this change for me, please? https://review.opendev.org/#/c/664393/ It's been around for some time and is blocking some doc rework I want to do in nova
09:27:16 mordred hey stephenfin
09:27:18 mordred looking
09:27:30 stephenfin mordred: Yo. Thanks :)
09:28:04 mordred stephenfin: done
09:28:16 stephenfin \o/ Appreciate it
09:28:38 mordred stephenfin: you know things ...
09:28:55 stephenfin don't you do it
09:28:59 mordred stephenfin: what's the python2 story for U again? support goes away, right?
09:29:20 stephenfin phew, thought you were threatening me with core on something I didn't want for a second
09:29:23 stephenfin Yup, kill it
09:29:53 stephenfin We haven't started removing stuff in nova yet and probably won't until Train GA
09:29:55 stephenfin but after that...
09:30:11 mordred stephenfin: cool. I have someone interested in adding some type annotations - which obviously need 2 to go away
09:30:32 stephenfin mordred: https://review.opendev.org/#/c/676209/
09:30:41 stephenfin ignore all the failures - I rushed it :)
09:30:45 mordred nice!
09:31:10 stephenfin We might want to put this in openstack-zuul-jobs though https://review.opendev.org/#/c/676210/
09:31:19 mordred stephenfin: zuul projects are already py3 - this one: https://review.opendev.org/#/c/686249/ added annotations but had to put in an ignore on the "import openstack" line
09:32:04 mordred yeah - probably so. we've actually caught bugs with mypy in zuul
09:32:09 stephenfin mordred: That's because we're using an old version of flake8 because hacking hasn't been updated. New versions support type hints
09:32:19 stephenfin or rather, detect that an import is necessary due to type hints
09:32:50 stephenfin alas, updating hacking to work with flake8 3.x is easier said that done because it was completely rewritten. I've tried and failed a few times :(
09:32:51 mordred oh - no - I mean we had to mypy ignore it becuase there's no type information from openstack I think
09:32:55 stephenfin ohhh
09:33:06 mordred oh goodie
09:33:31 mordred stephenfin: yeah - line 17: https://review.opendev.org/#/c/686249/3/zuul_registry/swift.py
09:33:46 stephenfin mordred: This should do the same thing, I think https://review.opendev.org/#/c/676208/1/setup.cfg@91
09:34:16 stephenfin but maybe not. I'm at about 3/10 on the "understanding how mypy works" scale rn
09:34:22 mordred stephenfin: ignore_missing_imports? or follow_imports=skip?
09:34:32 stephenfin ignore_missing_imports
09:34:50 stephenfin hmm, maybe not actually
09:35:04 mordred ah - no, follow_imports=skip
09:35:07 mordred https://mypy.readthedocs.io/en/latest/running_mypy.html#follow-imports
09:36:23 stephenfin Hmm, worth experimenting with those flags, I imagine
09:36:26 stephenfin That's cool though
09:37:04 mordred yeah
09:37:13 stephenfin I'd like to see them in most of oslo too, though I think I'll need to request help from the mypy folks for o.v.o. That's a weird one
09:37:19 stephenfin zuul doesn't use oslo though, does it?
09:37:24 mordred that said - it would be nice to add the annotations so that you could annotate things with signatures of the imported objects
09:37:35 mordred stephenfin: that's right - zuul does not use oslo
09:37:49 stephenfin cool. probably won't affect you much so :)

Earlier   Later