Earlier  
Later
New Search
Posted Nick Remark
#openstack-sdks - 2019-08-03
20:22:38 openstackgerrit Merged openstack/os-client-config master: Add Python 3 Train unit tests https://review.opendev.org/669450
#openstack-sdks - 2019-08-04
12:56:44 openstackgerrit norman shen proposed openstack/python-openstackclient master: support create domain project https://review.opendev.org/674487
#openstack-sdks - 2019-08-05
07:57:13 openstackgerrit Merged openstack/openstacksdk master: Fix DeprecationWarning for using logger.warn https://review.opendev.org/674401
08:58:08 openstackgerrit Bence Romsics proposed openstack/python-openstackclient master: Add command: router add/remove route --route https://review.opendev.org/674325
10:18:34 openstackgerrit Vishakha Agarwal proposed openstack/openstacksdk master: Add application credential CRUD support https://review.opendev.org/669331
12:10:25 gtema dtantsur, mordred, Shrews: https://review.opendev.org/#/c/674333/ is really important (event as a hotfix), since without it Ansible can't get/create keypairs
12:10:44 gtema dtantsur, can you please have a look, whether ironic failure in the tests is related or not
12:11:20 gtema this change also includes switching Ansible tests to Py3, since the problem is visible only there and more and more Platforms are delivering py3 only ansible
13:21:40 mordred dtantsur|afk, Shrews: yeah - I recommend looking at that patch from gtema - and when it lands let's cut a bugfix release with it
13:22:01 mordred being broken for ansible on python3 is a bad thing
13:22:17 mordred should we add a second run of the ansible tests to cover python2?
13:26:59 efried mordred: should I nack https://review.opendev.org/#/c/674515/ on the theory that that placement placeholder will be in place soon?
14:09:08 gtema mordred: yeah, adding ansible py2 would be likely good
14:15:26 mordred efried: yeah - I'll get you one today
14:22:17 openstackgerrit Monty Taylor proposed openstack/openstacksdk master: Add empty placement proxy https://review.opendev.org/674620
14:22:18 mordred efried: there's the first stab at it
14:23:36 openstackgerrit Monty Taylor proposed openstack/openstacksdk master: Add empty placement proxy https://review.opendev.org/674620
14:31:45 efried \o/ Thanks mordred
15:38:12 Shrews dtantsur|afk: FYI, looks like the asserts in openstack.tests.functional.baremetal.test_baremetal_node compare lists (node.traits) in unsorted order and randomly fail (see https://logs.opendev.org/33/674333/3/check/openstacksdk-functional-devstack-ironic/0e8be8d/testr_results.html.gz)
15:39:34 Shrews mordred: do you remember who added magnum support to sdk?
15:40:51 mordred Shrews: I do not
15:40:58 Shrews oh, maybe yolanda
15:41:03 mordred oh - yeah - I think so
15:55:35 openstackgerrit David Shrewsbury proposed openstack/openstacksdk master: Fix bm tests: sort lists being compared https://review.opendev.org/674640
15:55:43 Shrews dtantsur|afk: ^^
16:05:35 mordred Shrews: ++
16:14:04 corvus when i use the interactive form of the cli, i get this exception: http://paste.openstack.org/show/755535/
16:14:34 corvus same command works fine non-interactively
16:27:10 mordred dtroyer: ^^?
16:30:33 frickler seems related to cmd2>=0.9.0, if I install cmd==0.8.9 things work fine
16:30:44 mordred frickler: "neat"
16:33:20 frickler the newer ones also give errors when doing interactive mode with options, like "openstack --os-cloud mycloud", which also works fine with older cmd2
16:38:50 dtroyer yeah, we've not kept up with cmd2… I thought we capped it somewhere?
16:38:53 mordred frickler: so should we be pinning cmd2 for now?
16:38:56 mordred dtroyer: jinx
16:39:21 dtroyer maybe not in stable branches, or far enough back in them?
16:40:07 mordred corvus: what version of osc are you using there?
16:41:12 corvus openstack 3.19.0
16:43:27 mordred corvus: and, if you don't mind, what version of cliff is installed in that venv?
16:44:48 corvus cliff==2.15.0
16:45:44 mordred thanks
16:47:57 frickler I tested some older versions of cliff with no effect, versions 0.9.x of cmd2 give varying errors, so based on that short test list, I'd advise to cap cmd2<0.9 for now
16:52:14 mordred frickler: I don't know why it's not capped
16:52:58 mordred OH
16:53:00 mordred it's because I can't read
16:54:06 openstackgerrit Monty Taylor proposed openstack/cliff master: Pin cmd2 on python3 as well https://review.opendev.org/674652
16:54:10 mordred frickler, dtroyer: ^&
17:01:05 efried [2] https://opendev.org/openstack/nova/src/branch/master/nova/tests/fixtures.py#L2125
17:01:05 efried [1] https://logs.opendev.org/25/674625/1/check/nova-tox-functional-py36/27b16b6/testr_results.html.gz
17:01:05 efried mordred: This [1] is likely because of the way we're (not) fixturing [2], which was pretty weak to begin with. I suspect I can get moving by adding a mock for get_endpoint_from_catalog, and then possibly also get_session_client... but I'm kinda not sure I should keep chasing fixtures for sdk internals like that. Thoughts?
17:13:26 mordred efried: hrm. you're making my brain do work
17:13:44 mordred efried: I agree - I don't think you should need to chase fixtures for internals lke that
17:14:11 efried I did open a story for sdk to publish fixtures for this purpose, but people are busy
17:14:22 mordred yeah. and I really want to publish those
17:14:46 efried perhaps initially it's as simple as moving the one from nova into sdk, and it can get better refined later.
17:14:51 mordred efried: maybe for today just adding in a get_endpoint_from_catalog mock - but let's elevate the priority of getting you a real fixture
17:15:19 efried okay, I'll try that on the nova test patch and see what shakes out.
17:15:55 mordred efried: cool. and I'll see if I can sort out something WRT workable long-term exported fixture status
17:16:45 efried thanks mordred
17:24:54 openstackgerrit Merged openstack/openstacksdk master: Enable ansible module test for keypair to check return data https://review.opendev.org/674333
17:28:05 tosky mordred: hi, is there any update on version handling in SDK (and then microversioning in osc)? I happened to discuss about https://review.opendev.org/#/c/590807/ a few days ago with some cinder developers
17:58:24 mordred tosky: well - sdk handles versions and microversions - but I think to take advantage of that in osc we need to make progress on osc4
17:58:44 mordred and then start using sdk methods instead of python-cinderclient methods for cinder operations - it's not going to be a QUICK process
18:01:40 tosky mordred: so it does not match that "a couple of weeks" from that comment, I guess? Can you share there (or some public place) what is missing? Because this was one of the blockers for cinder to even start considering OSC as proper replacement
18:01:50 tosky or so I understood
18:02:10 tosky and maybe other people could help with the porting effort
18:02:26 mordred tosky: I just replied on the change - I think we need to circle with dtroyer on plans here - but yes, I totally agree it would be best if we get people to help with the porting effort
18:09:49 tosky mordred: slightly different question - I noticed that the openstackclient functional tests implements their own base classes; have you considered using CLIClient from tempest.lib?
18:10:18 tosky It can be used without the rest of tempest; that's what the python-cinderclient functional tests do (stestr run and that's it)
19:01:14 openstackgerrit Eric Fried proposed openstack/openstacksdk master: Allow limiting Connection service_types from oslo.config https://review.opendev.org/674675
19:01:24 efried mordred: howza ^
21:14:33 mordred efried: awesome
21:43:21 openstackgerrit Merged openstack/openstacksdk master: Fix bm tests: sort lists being compared https://review.opendev.org/674640
23:53:45 openstackgerrit Christian Berendt proposed openstack/openstacksdk master: Update betacloud vendor entry https://review.opendev.org/674715
#openstack-sdks - 2019-08-06
08:24:43 dtantsur Shrews, mordred: there was an existing patch for the traits problem, but thanks for fixing it anyway
10:22:17 openstackgerrit Merged openstack/openstacksdk master: Update betacloud vendor entry https://review.opendev.org/674715
10:22:18 openstackgerrit Merged openstack/openstacksdk master: Add Python 3 Train unit tests https://review.opendev.org/667494
10:32:13 dtantsur mordred: we don't support global_request_id in SDK, do we?
10:36:55 dtantsur also it seems that the Volume support it very basic, right?
12:10:11 mordred dtantsur: I'm not sure what global_request_id is? so probably not - but maybe we do via keystoneauth?
12:11:09 mordred dtantsur: and yeah - the openstack.block_storage layer could use more love for sure.
12:25:46 dtantsur oh, yeah, global_request_id is a keystoneauth thing. I just need to know how to pass it to a Connectin..
12:44:33 mordred dtantsur: ok. I just read the global_request_id stuff in ksa
12:45:08 mordred this is going to be a fun one ... because it's supposed to be set per-request, but the individual requests aren't partcularly exposed
12:46:58 mordred dtantsur: I almost think we should make a $something like a context manager or something, so you coudl say with conn.global_request_id(the_id) as req_conn: req_conn.baremetal.machines() ... or something similar
12:48:08 mordred (because a Connection can be used from a multi-threaded context, so just setting a global_request_id attribute on the Connection object so that it picked it up and passed it in to the request arguments would be a step, but it wouldnt' be the full picture)
12:48:44 dtantsur Ironic currently creates a connection per request (may end up in 1-10 sdk requests, but still)
12:49:04 dtantsur but I like the idea with a context manager
12:50:34 mordred dtantsur: let me poke for just a sec - I think I can make you a patch real quick
13:04:08 openstackgerrit Monty Taylor proposed openstack/openstacksdk master: Add support for global_request_id https://review.opendev.org/674807
13:04:13 mordred dtantsur: ^^ how about that?
13:04:22 dtantsur lemme see
13:04:52 mordred dtantsur: (it should also let you just set it in the constructor in ironic since you're only doing connection per request anyway)
13:23:58 rm_work dtroyer: apparently here
13:24:13 dtroyer rm_work: +1
13:25:34 rm_work dtroyer: barbican meeting happening right now and there's some discussion of the right direction for client work, like ... python-Xclient, openstack-sdk, and interfacing with openstackclient etc
13:25:56 rm_work i dunno if they want to spend meeting time on it or if we might just follow up after, but i know you had some thoughts on this from the last time we talked at the PTG I think?
13:27:10 rm_work they're considering deprecating their python-barbicanclient and moving to openstacksdk only? is that right right direction?
13:27:22 rm_work and then would they write in openstack-client support via the SDK code?
13:27:25 dtroyer rm_work: I'm in another meeting at the moment but everything is basically converging on SDK, so I'd support tha

Earlier   Later