Earlier  
Later
New Search
Posted Nick Remark
#openstack-sdks - 2019-10-28
19:57:59 openstackgerrit Merged openstack/openstacksdk master: CI: add ironic-python-agent-builder to the ironic job https://review.opendev.org/691630
20:36:25 openstackgerrit Eric Fried proposed openstack/python-openstackclient master: Use autoprogram-cliff for remaining plugin docs https://review.opendev.org/690387
20:37:04 openstackgerrit Eric Fried proposed openstack/openstackclient master: Add docs build to openstackclient-plugin-jobs template https://review.opendev.org/691751
20:37:04 openstackgerrit Eric Fried proposed openstack/openstackclient master: Copy in python-openstackclient docs https://review.opendev.org/691750
20:46:16 openstackgerrit Eric Fried proposed openstack/openstackclient master: Add docs build to openstackclient-plugin-jobs template https://review.opendev.org/691751
20:46:16 openstackgerrit Eric Fried proposed openstack/openstackclient master: Copy in python-openstackclient docs https://review.opendev.org/691750
21:00:22 efried - copies over all the docs from python-openstackclient https://review.opendev.org/691750
21:00:22 efried - updates the index https://review.opendev.org/691728
21:00:22 efried - I pushed up the openstackclient series above, which
21:00:22 efried - those reqs bumps merged, so this patch ought to be ready for review (python-openstackclient, autodocs the last five plugins): https://review.opendev.org/#/c/690387/
21:00:22 efried dtroyer: Update:
21:00:23 efried - tries to make the openstack-plugin-jobs template build docs (but I did it way wrong, need to rework) https://review.opendev.org/691751
21:02:08 efried oh, and trying to do autoprogram-cliff:: openstack doesn't work. It needs to match the entry point exactly.
21:02:25 efried the granularity is accomplished via that :command: syntax - but is optional.
22:31:24 openstackgerrit Eric Fried proposed openstack/python-openstackclient master: WIP: neutron: autogenerate docs https://review.opendev.org/691767
22:31:46 efried dtroyer: FYI, I'm at least starting to go through and replace hardcoded content with autogen ^
#openstack-sdks - 2019-10-29
10:16:47 openstackgerrit Riccardo Pittau proposed openstack/openstacksdk master: Add reset_interfaces argument to patch_node https://review.opendev.org/689414
10:18:10 openstackgerrit Riccardo Pittau proposed openstack/openstacksdk master: Add reset_interfaces argument to patch_node https://review.opendev.org/689414
10:54:40 openstackgerrit Dirk Mueller proposed openstack/cliff master: Revert "Pin cmd2 back to <0.9 on all versions" https://review.opendev.org/691841
11:55:11 openstackgerrit Merged openstack/openstacksdk master: Increase dogpile version for Py3.7 compatibility https://review.opendev.org/691680
13:57:35 openstackgerrit Eric Fried proposed openstack/python-openstackclient master: Remove redundant OpenStackShell.prepare_to_run_command https://review.opendev.org/691865
13:57:51 efried dtroyer, mordred: Easy one ^
14:22:57 dtroyer efried: not necessarily easy, there were reasons that exists, and at the moment I don't recall if all of those reasons are gone yet. They should be but I wouldn't bet dinner on it right now
14:23:21 efried dtroyer: I linked the superclass impl in there
14:23:58 efried But anyway, this is why we have reviews...
14:23:58 efried At least from what I can tell, it's doing the same thing. And you said yourself (in the TODO) that it could be removed after 1.4.0 :P
14:24:17 dtroyer Then it should be good, but consider the author
14:24:26 efried hehe
15:44:54 umbSublime with a connection object is it possible to specify the api microversion. Something equivalent to conn.compute.get('/os-hypervisors?with_servers=true', microversion='2.53')
15:49:45 efried umbSublime: Yes, all the methods (including the REST primitives like .get(), .put(), etc.) should take a microversion kwarg. Let me double check how it's spelled...
15:51:53 umbSublime efried: sorry I wasn't really clear, my example works
15:52:16 efried oh, you want to specify the default microversion for the connection so you don't have to put in the kwarg every time?
15:52:19 umbSublime My question was more, is this possible with for example conn.compute.hypervisors()
15:55:43 efried umbSublime: I was wrong, the non-primitives don't take a microversion. You can set the default microversion on the proxy though.
15:56:39 umbSublime Is that something I setup when creating the connection
15:56:57 efried Sorry, conn.compute is the proxy
15:57:05 efried conn.compute.default_microversion = XXX
15:57:05 efried So it should definitely work like:
15:57:22 efried But there's probably a prettier way to do it, via config or something.
15:57:24 umbSublime Ahh I see, thanks
15:58:10 efried dtantsur: do you have that answer off the top ^ ?
15:58:13 umbSublime and what about the 'with_servers=True', I see it works with .get, but with .hypervisors() it get's ingored.
15:58:34 umbSublime I pass it as a kwarg on .hypervisors()
15:58:57 dtantsur I suspect something like default_compute_microversions
15:59:16 dtantsur however, if you need to set it for e.g. conn.compute.hypervisors, then somebody is doing it wrong: other we or you :)
15:59:36 dtantsur openstacksdk is expected to use the latest microversions it knows. if it doesn't - it's a bug.
15:59:46 dtantsur if it does, then changing the default won't help you
15:59:57 efried dtantsur: Didn't mordred just fix something for that?
16:00:27 dtantsur maybe, I haven't been following closely the last couple of weeks
16:00:38 dtantsur (relocation)
16:00:39 umbSublime "somebody is doing it wrong" -> most likely me
16:00:56 dtantsur umbSublime: it may help if you describe the problem you're facing
16:01:16 efried https://review.opendev.org/#/c/685999/ implies we weren't getting the compute microversion we were expecting.
16:01:57 umbSublime dtantsur: I have a meeting coming, up but I'll be back with the deets
16:02:11 efried umbSublime: What version of keystoneauth are you using?
16:04:18 efried it's possible that without https://review.opendev.org/#/c/685042/ you're getting 2.1 instead of 'latest'.
16:04:21 efried dtantsur: ^
16:05:29 dtantsur yeah, this may be the cause
16:05:43 dtantsur these microversions, never liked them :)
16:06:23 efried umbSublime: So you may want to make sure you have ksa 3.18.0 (it looks like the Train fix hasn't merged yet)
16:06:34 efried and see if that fixes the issue
16:07:37 efried umbSublime: As for `with_servers`, that was added in the 2.53 microversion of the compute API, but we might not have brought SDK up to parity yet.
16:12:50 efried yeah.
16:13:00 efried umbSublime: You should propose a patch to add that :P
16:23:05 openstackgerrit Eric Fried proposed openstack/python-openstackclient master: DNM: CI check https://review.opendev.org/691910
16:41:46 openstackgerrit Merged openstack/openstacksdk master: Add support for Node tainted field https://review.opendev.org/690755
17:13:59 umbSublime efried: I'm using keystone v3. As for the microversion I get from the proxy how can i check this? i can only see 'version=2' in vars(conn.compute)
17:14:58 umbSublime v3.11 for ksa
18:40:01 mriedem dtroyer: can we get this simple osc change in https://review.opendev.org/#/c/691039/ to unblock novaclient 16.0.0 from being in u-c https://review.opendev.org/#/c/690097/
20:38:01 efried mriedem: something changed between then and now, osc isn't building: https://review.opendev.org/#/c/691910/
20:38:11 efried so your patch won't clear the gate, is my point.
20:38:47 mriedem but not just mine, any you're saying
20:38:52 efried And btw, I have no idea what's going on there. I can't repro "locally"
20:39:04 efried yes, noticed it on one of mine, seemed unrelated, so I put that up to confirm.
20:39:19 efried mebbe you can do your logstash thing and find the culprit?
20:40:28 mriedem my guess is some py2/3 thing was dropped/released
20:42:00 mriedem http://logstash.openstack.org/#dashboard/file/logstash.json?query=message%3A%5C%22TypeError%3A%20Unicode-objects%20must%20be%20encoded%20before%20hashing%5C%22%20AND%20tags%3A%5C%22console%5C%22&from=7d isn't super useful
20:43:38 efried I guess it wouldn't be, since nobody's been building anything in osc except for me.
20:43:51 mriedem well, could be openstack-requirements for a dependency
20:43:55 mriedem but i'm not seeing anything obvious
20:44:03 efried but it shows that whatever it is only affects python-openstackclient.
20:44:13 mriedem this hashlib library that's blowing up here https://github.com/openstack/python-openstackclient/blob/4bde9af89251431791fc8d69fe09d5e17a8fba8f/openstackclient/tests/functional/compute/v2/test_agent.py#L24 hasn't changed in forever on pyi
20:44:15 mriedem *pypi
20:44:40 mriedem https://zuul.opendev.org/t/openstack/build/49ff6a5645554095b3fb51bce497aff5/log/tox/functional-0.log hmm is that in the standard lib now?
20:45:01 mriedem this job must use py36?
20:45:04 efried did that job recently cut over to py3?
20:45:14 mriedem that's my guess
20:45:40 efried well, its incarnation in python-openstackclient didn't, so unless it has an ancestor that did...
20:45:46 mriedem https://docs.python.org/3.6/library/hashlib.html#hashlib.hash.update
20:46:01 mriedem that's entirely possible, parent projects are moving to py3 in ussuri
20:46:16 efried devstack-tox-functional
20:47:27 mriedem seems ok https://opendev.org/openstack/devstack/src/branch/master/.zuul.yaml#L566
20:48:03 mriedem parent: multinode
20:49:46 efried ...which is abstract, whatever that means.
20:49:56 mriedem means it just has to be extended i think
20:50:10 efried well, yeah
20:50:33 efried btw, attempting to run simply tox -e functional on my devstack node deadlocks.
20:50:46 mriedem i don't see anything recent in openstack-zuul-jobs that looks related
20:50:49 mriedem or devstack
20:51:03 efried yeah

Earlier   Later