Earlier  
Later
New Search
Posted Nick Remark
#openstack-sdks - 2020-05-08
16:27:45 gtema entered 1 hour for API-SIG June 2nd 16 - 17 UTC, and for SDK/CLI: June 1st 15-17 UTC and 3rd 15-17 UTC
16:32:06 diablo_rojo_phon gtema: make sure to fill out the survey too and not just the ethercalc :)
16:32:16 gtema done already, thans
16:32:18 gtema thanks
16:43:26 diablo_rojo_phon Thank you!
16:45:13 elmiko gtema: thanks for taking the lead on that =)
17:56:35 dtroyer mordred, gtema: Setting validate_checksum=False fixed the image create issue with the vmware cloud… It is defaulted True in 3 places in the SDK, changing only BaseImageProxy.create_image is sufficient, or of course turning it off in OSC would work too. Do you guys have a preference?
17:56:35 dtroyer mordred, gtema: Setting validate_checksum=False fixed the image create issue with the vmware cloud… It is defaulted True in 3 places in the SDK, changing only BaseImageProxy.create_image is sufficient, or of course turning it off in OSC would work too. Do you guys have a preference?
18:08:55 mordred dtroyer: I think changing it in BaseImageProxy.create_image should be fine, yeah? I think we should just do that - best I can tell it's not super useful
19:35:37 openstackgerrit Dean Troyer proposed openstack/openstacksdk master: Set BaseImageProxy.create_image validate_checksum default to False https://review.opendev.org/726465
19:37:26 dtroyer mordred: ^^^ only covers the unit testing updates
#openstack-sdks - 2020-05-09
01:34:04 rm_work mordred / dtroyer: found one more weird thing... the "properties" shown on `show image` are slightly different
01:35:01 rm_work the new client using SDK doesn't return `owner_id` and DOES return `self` which contains the relative URL to the image
01:35:13 rm_work which messes with some code we had in our deployment pipeline
01:51:11 rm_work (if you try to copy every property from an `image show` into a new `image create`, passing self is not valid
01:51:14 rm_work )
01:56:35 rm_work in the meantime i think i will strip out the `self` in our code, but ... i wonder if others will see this issue, and what (if anything) we should do about it... I guess `owner_id` should be added in the SDK
05:39:15 AJaeger mordred: https://opendev.org/openstack/openstackclient/src/branch/master/playbooks/openstackclient-check-plugins/run.yaml#L13 uses pbrx - do you want to rewrite that or should we stop retiring pbrx?
10:35:57 openstackgerrit Sagi Shnaidman proposed openstack/ansible-collections-openstack master: Ensure modules work with queens devstack https://review.opendev.org/726421
14:36:12 mordred AJaeger: oh! good find. yeah, let's fix that in osc
14:37:08 mordred rm_work: yeah - let's fix sdk. let's add owner_id - and then for self, rather than stripping it (not sure if people need it) - let's update sdk to know not to try to send self when we create an image
14:44:35 AJaeger mordred: could you do the fix in osc, please?
14:57:10 openstackgerrit Monty Taylor proposed openstack/ansible-collections-openstack master: WIP Remove all of the os_ prefixes https://review.opendev.org/713056
14:57:18 openstackgerrit Monty Taylor proposed openstack/ansible-collections-openstack master: WIP Remove all of the os_ prefixes https://review.opendev.org/713056
15:44:47 openstackgerrit Monty Taylor proposed openstack/ansible-collections-openstack master: Remove all of the os_ prefixes https://review.opendev.org/713056
15:44:48 openstackgerrit Monty Taylor proposed openstack/ansible-collections-openstack master: Rename all of the modules https://review.opendev.org/726538
15:45:03 mordred AJaeger: yes - I will do it
16:07:30 AJaeger thanks, mordred
22:31:27 rm_work mordred: hmm yeah that'd work
#openstack-sdks - 2020-05-10
00:27:21 openstackgerrit Adam Harwell proposed openstack/openstacksdk master: Show owner_id AND owner as properties https://review.opendev.org/726562
00:30:04 openstackgerrit Adam Harwell proposed openstack/python-openstackclient master: Ignore `self` property if passed on image create https://review.opendev.org/726563
00:33:16 rm_work mordred: ^^ fixed.
00:33:54 rm_work any idea when https://review.opendev.org/#/c/725427/ might merge? Are you the only core reviewer really merging things at this point? T_T
01:04:39 openstackgerrit Adam Harwell proposed openstack/openstacksdk master: Show owner_id AND owner as properties https://review.opendev.org/726562
02:16:50 openstackgerrit Adam Harwell proposed openstack/python-openstackclient master: Ignore `self` property if passed on image create https://review.opendev.org/726563
07:06:39 rm_work mordred: so i don't really understand why the one tox-py36-tips test would have the failures it does
07:06:41 rm_work in https://review.opendev.org/#/c/726562/
11:03:35 sshnaidm|off need an opinion of SDK devs - are there possible problems when using latest SDK to manage openstack old release, like Queens for example?
12:24:03 mordred sshnaidm|off: no, it should 100% work and is explicitly supported
12:44:15 mordred rm_work: looking at it
12:51:48 openstackgerrit Victor Coutellier proposed openstack/openstacksdk master: Add name query filter to keystone service https://review.opendev.org/726621
12:54:33 sshnaidm|off mordred, great, so modules should work too
13:01:53 mordred sshnaidm|off: yes. if they don't it's a bug
13:02:13 mordred sshnaidm|off: imo, there is no reason to ever use any release of openstacksdk other than the most recent one
13:03:03 mordred rm_work: ok - looking in to this - I think this is a slightly different/worse issue :(
13:03:48 mordred rm_work: "owner_id" should never have existed - that's an sdk-side API break. the glance value is owner, the sdk value has been owner for a very long time, and it looks like the osc value was owner before the update
13:04:14 mordred rm_work: I'm going to see if I can't figure out how to fix it without things completely sucking
13:07:59 openstackgerrit Sagi Shnaidman proposed openstack/ansible-collections-openstack master: Ensure modules work with queens devstack https://review.opendev.org/726421
13:20:24 mordred rm_work: also, we're supposed to be stripping self from the image object in sdk - but we're apparently only doing it in list()
13:21:30 openstackgerrit Monty Taylor proposed openstack/openstacksdk master: Strip self from incoming glance properties https://review.opendev.org/726626
13:21:31 openstackgerrit Monty Taylor proposed openstack/openstacksdk master: Fix image owner field https://review.opendev.org/726627
13:27:47 openstackgerrit Monty Taylor proposed openstack/openstacksdk master: Remove some unneeded things from test-requirements https://review.opendev.org/715707
13:27:48 openstackgerrit Monty Taylor proposed openstack/openstacksdk master: Remove uses of from six.moves https://review.opendev.org/715712
13:29:48 openstackgerrit Monty Taylor proposed openstack/openstacksdk master: Stop subclassing object https://review.opendev.org/715714
13:29:48 openstackgerrit Monty Taylor proposed openstack/openstacksdk master: Remove use of six https://review.opendev.org/715713
14:21:02 openstackgerrit Merged openstack/ansible-collections-openstack master: Updated allocation pool checks https://review.opendev.org/723064
15:18:29 openstackgerrit Dean Troyer proposed openstack/openstacksdk master: Set BaseImageProxy.create_image validate_checksum default to False https://review.opendev.org/726465
15:43:11 openstackgerrit Merged openstack/openstacksdk master: Add "id" to Port's query parameters https://review.opendev.org/726050
17:03:07 openstackgerrit Dean Troyer proposed openstack/openstacksdk master: Set BaseImageProxy.create_image validate_checksum default to False https://review.opendev.org/726465
17:04:41 dtroyer ^^^ That should pass functional tests now
23:02:21 rm_work mordred: ok so we can do things in a slightly less silly way then, that's actually good?
23:02:41 rm_work I was afraid we COULDNT strip "self" because it might be relied on?
23:03:10 rm_work It's technically been published in a release where it does exist in the Show, are you sure we CAN remove it now?
23:04:06 rm_work And owner_id was shown in the OSC for a long time I thought, not just after the switch to SDK, so same deal
23:04:36 rm_work What I was seeing was "pre-update" owner_id in properties
23:05:23 rm_work I literally just have an older client (4.x series) and the new client (5.x series) installed side by side and was plugging json output from an "image show" into a jsondiff utility
23:05:43 rm_work And worked on the new one until the output was identical
#openstack-sdks - 2020-05-11
00:54:58 rm_work the way that owner_id/owner patch is done confuses the heck out of me, lol
00:55:21 rm_work owner alias owner_id + owner_id alias owner
04:50:17 rm_work mordred: also, again, still waiting on https://review.opendev.org/#/c/725427/ to merge -- are you good with that?
04:52:35 rm_work and what are merge guidelines on openstacksdk? we need two +2 reviews to workflow stuff?
09:49:13 nightmare_unreal how does OSC CLI determine which api version to use ? for e.g. use 2.15 or something or 2.60 etc etc.
13:01:30 openstackgerrit Merged openstack/ansible-collections-openstack master: Ensure modules work with queens devstack https://review.opendev.org/726421
13:27:39 mordred nightmare_unreal: it currently depends on the user setting an api version
13:28:10 nightmare_unreal like on openrc/localrc file ?
13:28:12 mordred nightmare_unreal: we have discussions about changing it to do discovery - but that's probably at least a cycle if not more away
13:28:28 nightmare_unreal ah okay cool :) Thanks for clarification
13:28:29 mordred nightmare_unreal: like OS_COMPUTE_API_VERSION= or --os-compute-api-version
13:28:45 nightmare_unreal understood.
13:38:57 mordred rm_work: nod. so - looking again, I think there is code in osc to map owner from sdk to owner_id in osc - we still need to bring back owner in sdk - so we might need an osc patch too
13:39:28 mordred rm_work: my biggest concern is that owner_id isn't a thing in glance, and if it's been showing up in properties that means it is likely it hasn't actually been set properly
14:44:55 frickler the behaviour of "openstack network agent add/remove router $agent $router" is weird, it is silently a no-op unless one adds the "--l3" option
14:45:22 openstackgerrit Monty Taylor proposed openstack/ansible-collections-openstack master: Remove all of the os_ prefixes https://review.opendev.org/713056
14:45:23 openstackgerrit Monty Taylor proposed openstack/ansible-collections-openstack master: Rename all of the modules https://review.opendev.org/726538
15:44:02 openstackgerrit Monty Taylor proposed openstack/ansible-collections-openstack master: Rename all of the modules https://review.opendev.org/726538
16:02:31 openstackgerrit Radosław Piliszek proposed openstack/js-openstack-lib master: CI: New jobs https://review.opendev.org/702132
16:02:31 openstackgerrit Radosław Piliszek proposed openstack/js-openstack-lib master: CI: New jobs https://review.opendev.org/702132
17:27:02 openstackgerrit Monty Taylor proposed openstack/ansible-collections-openstack master: Rename all of the modules https://review.opendev.org/726538
18:16:16 openstackgerrit Merged openstack/python-openstackclient master: Correct image lookup during server rebuild https://review.opendev.org/725427
18:16:21 openstackgerrit Merged openstack/openstacksdk master: Strip self from incoming glance properties https://review.opendev.org/726626
18:17:46 openstackgerrit Sagi Shnaidman proposed openstack/ansible-collections-openstack master: Rename all of the modules https://review.opendev.org/726538
18:18:42 openstackgerrit Sagi Shnaidman proposed openstack/ansible-collections-openstack master: Remove all of the os_ prefixes https://review.opendev.org/713056
18:23:52 openstackgerrit Sagi Shnaidman proposed openstack/ansible-collections-openstack master: Rename all of the modules https://review.opendev.org/726538
19:40:51 donnyd ```Error authenticating with application credential: Application credentials cannot request a scope```
19:40:51 donnyd when I try to use them with openstackclient - I get this error back
19:40:51 donnyd I am hoping someone can help me understand how application credentials work
20:29:28 openstackgerrit Merged openstack/openstacksdk master: Don't error if clouds.yaml is not readable https://review.opendev.org/726416
20:38:50 rm_work mordred: right that's what my patch did, that I abandoned already
20:39:15 rm_work Could bring it back, or could not
20:39:37 rm_work Or I wonder if it's just something that happened in my cloud because of something we set manually?

Earlier   Later