Earlier  
Later
New Search
Posted Nick Remark
#openstack-sdks - 2019-11-05
15:15:42 gtema so, it seems to me now, that in clouds.yaml it should really be system_scope under auth section
15:16:19 gtema can be even a boolean, important that neither of project_xxx nor domain_xxx are present
15:18:54 gtema so when I have 'system_scope: true' in my clouds.yaml the KSA get's really system_scope.
15:19:32 gtema Problem is that in my case I get empty catalog from keystone back and KSA/SDK doesn't know what to do with it
15:24:31 gtema mnasiadka: you should try it first without ansible at all, whether you can really login with system scope. This requires also a heavy admin user privileges, from what I understand
16:04:31 yoctozepto gtema: this is admin user, with role admin on system all
16:04:54 openstackgerrit Artem Goncharov proposed openstack/python-openstackclient master: Switch image to use SDK https://review.opendev.org/650374
16:05:11 yoctozepto we just could not get the ansible module to work in the new environ
16:05:36 gtema I know, I mean I can't verify whether this works at all, since I do not have access currently to admin user
16:07:17 gtema if you could prepare clouds.yaml config with your admin user and system_scope: true, and then try execute http://paste.openstack.org/show/785811/
16:23:24 yoctozepto gtema: I see, I'll try to set it up later, thanks
19:37:11 openstackgerrit Eric Fried proposed openstack/python-openstackclient master: Refactor AggregateTests https://review.opendev.org/693073
21:32:18 openstackgerrit Eric Fried proposed openstack/python-openstackclient master: Refactor AggregateTests https://review.opendev.org/693073
23:07:17 openstackgerrit Merged openstack/python-openstackclient master: Update a stale doc reference to use :neutron-doc: https://review.opendev.org/692605
#openstack-sdks - 2019-11-06
00:02:12 mordred mnasiadka, yoctozepto: we should also likely do something in sdk so that calls to create_endpoint get a system-scoped token for you for their calls so that you don't have to have a separate clouds.yaml entry
00:02:44 mordred (the separate entry is a good way to ensure this all works for now - but that seems like a pretty terrible UI to ask you to do for this)
00:33:11 openstackgerrit Merged openstack/python-openstackclient master: common: autogenerate docs https://review.opendev.org/691989
00:33:13 openstackgerrit Merged openstack/python-openstackclient master: openstack.cli: autogenerate docs https://review.opendev.org/692914
00:34:49 openstackgerrit Merged openstack/python-openstackclient master: compute: autogenerate docs https://review.opendev.org/692916
01:27:43 openstackgerrit Bence Romsics proposed openstack/openstacksdk master: Add router add/remove route operations https://review.opendev.org/674324
01:27:57 openstackgerrit Bence Romsics proposed openstack/openstacksdk master: Handle HTTP errors in add/remove router interface calls https://review.opendev.org/687304
03:30:34 openstackgerrit Bence Romsics proposed openstack/python-openstackclient master: Add command: router add/remove route --route https://review.opendev.org/674325
03:55:03 openstackgerrit Merged openstack/python-openstackclient master: Add redirect testing https://review.opendev.org/692929
03:55:04 openstackgerrit Merged openstack/python-openstackclient master: Deflate .htaccess https://review.opendev.org/692930
05:59:25 openstackgerrit Merged openstack/python-openstackclient master: Refactor AggregateTests https://review.opendev.org/693073
06:24:36 mnasiadka mordred: agreed, now it doesn't really work at all - when I do not supply domain in clouds.yaml - keystone complains it needs one, if I do - the token is not system scoped. So I guess in both cases it doesn't really do a system scoped token... I'll raise a bug.
11:37:15 frickler python-novaclient 16.0 seems to be breaking heat and therefore sdk testing https://zuul.opendev.org/t/openstack/build/2c83d0168fda4384837b676d336694ed/log/controller/logs/screen-h-eng.txt.gz#1379-1410
11:38:20 frickler https://zuul.opendev.org/t/openstack/builds?job_name=openstacksdk-functional-devstack
13:28:06 efried frickler: anything I can do about that novaclient breakage?
13:29:06 efried (I haven't looked at it yet, but I was following the steps that led up to that requirements patch being mergeable)
14:43:35 openstackgerrit Pedro Henrique Pereira Martins proposed openstack/keystoneauth master: Fixes OIDC authentication with multiple IdPs https://review.opendev.org/692140
15:01:42 frickler efried: there's a fix proposed in heat now https://review.opendev.org/693165 but I see you already reviewed it
15:01:57 efried yup
15:02:13 efried if a quicker fix were needed, I guess I would suggest capping the novaclient requirement there
15:02:18 efried but that fix seems straightforward enough.
15:04:31 frickler efried: yes, I think I'd be fine waiting a couple of days for heat to get this merged, but it would be good to add some test/job into reqs to prevent this from happening again
15:05:00 efried getting novaclient to gate on all possible consumers though...
15:05:06 mriedem the reqs job failed on horizon and i fixed osc since i noticed it was going to break but assumed the reqs job tested heat
15:05:30 efried oh, you're talking about getting reqs to gate on heat
15:05:40 mriedem yeah
15:05:46 efried that's probably not a bad plan.
15:05:48 mriedem https://review.opendev.org/#/c/690097/
15:06:27 mriedem it's definitely a slippery slope, because watcher, designate, senlin, blazar, etc
15:06:32 efried would heat's CI have caught this though? I thought we first noticed when sdk was running heat running novaclient...
15:06:38 efried yeah, that
15:06:47 frickler efried: heat func tests are broken now, too
15:06:59 efried okay.
15:07:00 mriedem heat's ci is gating on upper-constraints using novaclient
15:07:05 mriedem and the reqs for u-c just recently merged
15:07:23 efried I mean, if it wasn't, that would point to a hole in heat's CI
15:07:38 frickler see e.g. https://review.opendev.org/#/c/693134/
15:07:50 efried okay, so is someone going to propose a reqs zuul.yaml change to make it run some heat?
15:07:52 frickler heat might install some -tips job for their deps
15:08:12 frickler so they notice upcoming breakage earlier
15:08:36 efried also not a terrible plan
15:08:48 frickler the other option would be to drop heat tests from the sdk jobs and transitively from devstack
15:09:10 efried wouldn't that just lead to field escapes?
15:09:11 frickler or move them into a seperate non-voting jobs at least
15:09:37 frickler what does "field escapes" mean in this context?
15:09:49 efried "we don't notice the problem until a customer hits it"
15:10:04 efried i.e. "bug escapes to the field"
15:10:31 efried maybe I'm misunderstanding, but the point isn't for us to be able to continue to merge heat code despite a broken dep. The point is to avoid the broken dep, as early as possible.
15:12:10 frickler for me the point would be to be able to merge sdk and devstack patches even while heat isn't keeping up with things. though I admit I'm slightly biased on this because it's also heat blocking my pet "drop identity admin endpoint" project
15:12:58 mriedem ha
15:13:01 mriedem the truth comes out
15:15:20 frickler but o.k., I can propose to add some heat job, or maybe even better the same sdk job that is also running on devstack, to reqs, then see what comes out of that
15:22:05 frickler if you want to watch or comment: https://review.opendev.org/693197 Add openstacksdk-functional-devstack job
17:29:33 openstackgerrit Pedro Henrique Pereira Martins proposed openstack/keystoneauth master: Fixes OIDC authentication with multiple IdPs https://review.opendev.org/692140
18:23:33 umbSublime Hi again, would this be the right place to discuss about ospurge ?
19:10:30 openstackgerrit Pedro Henrique Pereira Martins proposed openstack/python-openstackclient master: Add documentation about login with federation https://review.opendev.org/693232
20:06:09 openstackgerrit Rodolfo Alonso Hernandez proposed openstack/openstacksdk master: "qos_network_policy_id" attribute added to port resource https://review.opendev.org/693247
20:26:59 efried umbSublime: Shanghai would probably be the right place this week
20:27:20 umbSublime efried: I wish I was there
20:27:29 efried that makes one of us
20:27:50 umbSublime Last summit I was too was the one in Boston
20:28:30 efried that might have been my first one
20:28:43 efried no, that can't be right
20:29:19 efried Austin or Boston
21:50:09 openstackgerrit Michael Johnson proposed openstack/python-openstackclient master: Switch to using osc_lib.utils.tags https://review.opendev.org/662864
21:51:00 johnsom Would really be good to merge ^^^^ as changes are being made to the old _tag.py that this removes.
21:55:25 johnsom efried So, I see your change to _tag merged that added the "enhance_help parameter to some of the tags methods. I am guessing those need to be added to the new osc_lib version?
21:56:15 johnsom https://www.irccloud.com/pastebin/Gj2aSRX5/
21:56:17 efried johnsom: ugh, that's an ugly enough hack kept buried in python-openstackclient, I would hate for it to have to bleed over to a different repo
21:56:49 johnsom efried I had removed _tag.py from pythonclient, it has just been sitting for review for a while.
21:56:49 efried I didn't know about that moving to osc-lib
21:57:06 johnsom We moved all of that code to osc_lib/utils/tags.py
21:57:14 johnsom So that other projects could use it
21:57:29 efried Out of curiosity, what other projects would need to use it?
21:57:36 efried Since it's you talking, I'm guessing octavia :P
21:57:44 johnsom Octavia wants it for example
21:58:07 johnsom It would be nice if we all implemented --tags the same... grin
21:59:12 johnsom FYI: https://review.opendev.org/#/c/662859/
22:00:26 johnsom I'm not sure I quite understand why the lambda is needed, but I just found that the removal patch was in conflict
22:05:52 johnsom This is the patch I just rebased that will likely fail as osc_lib doesn't have the "enhance_help" param: https://review.opendev.org/#/c/662864/
22:08:54 efried johnsom: I can at least explain how this came about.
22:09:40 efried The networking commands are kind of a mess. The commands and options for neutron and nova-network are interleaved.
22:09:46 johnsom Ok. I am guessing it is part of getting the docs working
22:10:02 johnsom Joy
22:10:05 efried When you're running on the CLI, the client tries to detect which network you're running by looking for the neutron service.
22:10:13 efried and if it doesn't find it, assumes you're running nova-net

Earlier   Later