Earlier  
Later
New Search
Posted Nick Remark
#openstack-sdks - 2023-01-31
11:41:00 whoami-rajat ok, sounds good
11:58:21 opendevreview suzhengwei proposed openstack/openstacksdk master: support notification vmoves for masakari https://review.opendev.org/c/openstack/openstacksdk/+/872080
12:18:55 lajoskatona stephenfin, gtema: thanks
12:41:00 opendevreview Merged openstack/python-openstackclient master: Move network trunk commands from python-neutronclient https://review.opendev.org/c/openstack/python-openstackclient/+/869447
12:43:34 opendevreview Merged openstack/python-openstackclient master: Add volume summary command https://review.opendev.org/c/openstack/python-openstackclient/+/869436
12:48:44 odyssey4me hi folks - I see https://review.opendev.org/q/project:openstack/python-openstackclient+branch:stable/wallaby has ~10 patches after the last tagged release... is there an intent to release a new tag at some point soon?
13:42:10 opendevreview Mridula Joshi proposed openstack/openstacksdk master: Add support for glance cache list https://review.opendev.org/c/openstack/openstacksdk/+/869710
14:10:10 odyssey4me never mind my query - wallaby is in extended maintenance, so I guess no more releases there
14:39:37 stephenfin odyssey4me: Yup, no more I'm afraid https://review.opendev.org/c/openstack/releases/+/847937
14:40:16 gtema I would say, now we can have a real party - https://pypi.org/project/openstacksdk/1.0.0/ is there
14:44:03 stephenfin #success openstacksdk 1.0.0 is out 🎉
14:44:03 stephenfin #success openstacksdk 1.0.0 is out 🎉
14:44:06 opendevstatus stephenfin: Added success to Success page (https://wiki.openstack.org/wiki/Successes)
14:44:33 odyssey4me w00t!
14:45:07 stephenfin gtema: did you merge more patches for the container orchestration layer?
14:45:14 gtema :)
14:45:15 gtema yes
14:45:23 gtema coe is also complete
14:48:49 opendevreview Stephen Finucane proposed openstack/openstacksdk master: Update README to indicate COE resource/proxy support https://review.opendev.org/c/openstack/openstacksdk/+/872283
14:49:15 stephenfin gtema: Probably want that so ^
14:49:22 stephenfin it's trivial
14:49:59 gtema ah, there are too many pages not built from sources. This should be target for R2.0 ;-)
15:15:32 opendevreview Mridula Joshi proposed openstack/openstacksdk master: Add support for glance cache list https://review.opendev.org/c/openstack/openstacksdk/+/869710
15:29:19 opendevreview Merged openstack/openstacksdk master: Update README to indicate COE resource/proxy support https://review.opendev.org/c/openstack/openstacksdk/+/872283
15:58:51 opendevreview Alfredo Moralejo proposed openstack/python-openstackclient stable/wallaby: Replace assertItemsEqual with assertCountEqual https://review.opendev.org/c/openstack/python-openstackclient/+/872327
16:46:52 timburke hi! i've got some concerns about the stable/xena openstacksdk-functional-devstack job: https://zuul.opendev.org/t/openstack/builds?job_name=openstacksdk-functional-devstack&branch=stable%2Fxena
16:48:12 timburke it looks like the recently-merged-to-master https://review.opendev.org/c/openstack/openstacksdk/+/865045 is getting picked up on the old stable branch (presumably because of https://github.com/openstack/openstacksdk/blob/master/.zuul.yaml#L34-L42)
16:49:59 timburke which is causing import errors down in python-openstackclient (which *is* using stable/xena) because it picked up an undeclared dependency on munch in https://opendev.org/openstack/python-openstackclient/commit/8b7a2c8d5931f15b69d1ef6baad994f4b9904579
17:13:37 gmann yeah, I also noticed this in devstack fix on stable/wallaby and openstacksdk-functional-devstack job is failing 100% on <=stable/wallaby https://zuul.openstack.org/builds?job_name=openstacksdk-functional-devstack&branch=stable%2Fxena&branch=stable%2Fwallaby&skip=0
17:14:06 gmann but If I am not wrong sdk master supposed to work for all supported stable branch ?
17:23:44 gtema gmann, the issue is apparently not the SDK itself, but rather old OSC which doesn't want to work good with new SDK. This looks bit weird for me
17:27:56 gtema installing munch lib there (with 5.6.1) helps to solve this, so most likely we need to extend requirements in old branches
17:29:47 gmann ok, so osc was relying on the munch being installed from sdks requirements.txt and with that removal from sdks it broke osc
17:30:01 gtema yes, apparently
17:30:01 gmann we should have that here https://opendev.org/openstack/python-openstackclient/src/branch/master/requirements.txt
17:30:11 gmann let me push change
17:30:36 gtema but only for xena, this is not required anywhere else
17:34:01 gmann right
17:34:46 gtema and interestingly stephenfin just today made release of OSC for xena, what a facepalm on a R1.0 day
17:35:12 gmann humm it worked there?
17:35:43 gtema well, as usual it all depend on the constellation
17:40:34 opendevreview Ghanshyam proposed openstack/python-openstackclient stable/xena: [stable-only] Add munch in requirements.txt https://review.opendev.org/c/openstack/python-openstackclient/+/872340
17:40:56 gmann gtema: stephenfin: ^^
17:41:06 gtema yes, I see. Thanks a lot gmann
17:41:18 stephenfin thanks
17:44:48 opendevreview Ghanshyam proposed openstack/python-openstackclient stable/wallaby: [stable-only] Add munch in requirements.txt https://review.opendev.org/c/openstack/python-openstackclient/+/872341
18:51:23 opendevreview Jakob Meng proposed openstack/ansible-collections-openstack master: Added workaround for non-determinism in ansible-inventory output https://review.opendev.org/c/openstack/ansible-collections-openstack/+/872344
18:52:09 opendevreview Jakob Meng proposed openstack/ansible-collections-openstack master: Bump minimum required openstacksdk release to 1.0.0 https://review.opendev.org/c/openstack/ansible-collections-openstack/+/872066
18:52:27 opendevreview Jakob Meng proposed openstack/ansible-collections-openstack master: Refactored coe_cluster{,_template} modules again https://review.opendev.org/c/openstack/ansible-collections-openstack/+/872039
18:52:39 opendevreview Jakob Meng proposed openstack/ansible-collections-openstack master: Publish 2.0.0 release https://review.opendev.org/c/openstack/ansible-collections-openstack/+/872077
19:42:59 opendevreview Arvid Requate proposed openstack/keystoneauth master: New auth plugin v3oidcdeviceauthz https://review.opendev.org/c/openstack/keystoneauth/+/869876
20:30:58 opendevreview Merged openstack/python-openstackclient stable/xena: [stable-only] Add munch in requirements.txt https://review.opendev.org/c/openstack/python-openstackclient/+/872340
20:40:01 odyssey4me stephenfin when you have a moment, please take a look at https://review.opendev.org/c/openstack/python-openstackclient/+/872327 which helps to resolve some tests on CS9 for wallaby
21:39:10 opendevreview Merged openstack/ansible-collections-openstack master: Added workaround for non-determinism in ansible-inventory output https://review.opendev.org/c/openstack/ansible-collections-openstack/+/872344
21:45:26 opendevreview Merged openstack/ansible-collections-openstack master: Bump minimum required openstacksdk release to 1.0.0 https://review.opendev.org/c/openstack/ansible-collections-openstack/+/872066
22:03:03 opendevreview Merged openstack/ansible-collections-openstack master: Refactored coe_cluster{,_template} modules again https://review.opendev.org/c/openstack/ansible-collections-openstack/+/872039
22:03:04 opendevreview Merged openstack/ansible-collections-openstack master: Publish 2.0.0 release https://review.opendev.org/c/openstack/ansible-collections-openstack/+/872077
22:16:14 gmann stephenfin: please check sdks job fix for stable/wallaby also https://review.opendev.org/c/openstack/python-openstackclient/+/872341
23:59:02 opendevreview Merged openstack/python-openstackclient stable/wallaby: Replace assertItemsEqual with assertCountEqual https://review.opendev.org/c/openstack/python-openstackclient/+/872327
#openstack-sdks - 2023-02-01
00:03:56 timburke gmann, gtema, thanks for looking at the busted job -- unfortunately, looks like https://review.opendev.org/c/openstack/python-openstackclient/+/872340 wasn't sufficient. as best i can tell, the job is only installing python-openstackclient from a tagged release, not git?
00:04:41 timburke see https://zuul.opendev.org/t/openstack/build/4b92987487b44219953cbe90716f51c6/log/controller/logs/devstacklog.txt#10818 -- i'm assuming that the 5.6.0 (rather than recently-released 5.6.1) is just because of an out-of-date mirror
00:10:33 timburke i'm still trying to figure out just what the value is we're hoping to get out of the job -- do we actually expect anyone to ever run xena python-openstackclient with master openstacksdk?
00:55:34 gmann timburke: yeah, we need to wait until its released and upper constraints are updated.
00:56:10 gmann I think that is the goal of this job but gtema or stephenfin can correct
00:57:41 opendevreview suzhengwei proposed openstack/openstacksdk master: support notification vmoves for masakari https://review.opendev.org/c/openstack/openstacksdk/+/872080
01:10:16 timburke particularly given the infrequent releases on stable branches, i would've thought it'd make more sense to run those xena tests on openstacksdk's master branch then, no?
05:24:21 gtema timburke, this is alsoy assumption now. It does feel logical that both SDK and OSC are added explicitly though Zuul project requirements, and still released OSC is used
07:12:55 opendevreview Merged openstack/python-openstackclient stable/wallaby: [stable-only] Add munch in requirements.txt https://review.opendev.org/c/openstack/python-openstackclient/+/872341
08:25:22 opendevreview Artem Goncharov proposed openstack/openstacksdk master: Implement acceptance test job https://review.opendev.org/c/openstack/openstacksdk/+/860399
09:39:08 opendevreview Rajat Dhasmana proposed openstack/python-openstackclient master: Add block storage work cleanup command https://review.opendev.org/c/openstack/python-openstackclient/+/872390
10:03:51 opendevreview Shnaidman Sagi (Sergey) proposed openstack/ansible-collections-openstack master: Fix issue with multiple records in recordset https://review.opendev.org/c/openstack/ansible-collections-openstack/+/872392
10:04:34 opendevreview Shnaidman Sagi (Sergey) proposed openstack/ansible-collections-openstack master: Fix issue with multiple records in recordset https://review.opendev.org/c/openstack/ansible-collections-openstack/+/872392
15:23:47 opendevreview Artom Lifshitz proposed openstack/python-openstackclient master: Add func test for compute 2.94 https://review.opendev.org/c/openstack/python-openstackclient/+/872420
15:55:56 gmann gtema: as you know osc cannot be released in stable/wallaby https://review.opendev.org/c/openstack/releases/+/872382
15:56:13 gtema yes, I already figured this out
15:56:42 gmann gtema: we have two option to unblock stable/wallaby gate 1. remove the sdk testing 2. test with old sdk removing master branch from here https://github.com/openstack/openstacksdk/blob/stable/wallaby/.zuul.yaml#L40
15:56:42 gtema don't know what to do though
15:56:54 gmann 2nd one seems conflict with the notes there
15:59:04 gtema 1st option is not good. On the other side if we are not able to have any releases there I see honestly absolutely no reason to keep this testing
16:02:33 gmann gtema: humm, but testing with old sdk version does not make sense if I am not wrong
16:03:48 gtema it makes as much sense as it was 1 week ago till the change. But What I am saying is that if we can not even release any bugfix - what is the sense of testing?
16:07:06 gtema I mean I tend rather to option 1) and stop testing on wallaby completely
17:02:08 gmann gtema: I think I agree with you. let's go for that and stop testing. we do have same recommendation for any other testing on EM branch if they stop working then stop testing like grenade, tempest master etc
17:02:55 gtema Ok
19:26:35 opendevreview Shnaidman Sagi (Sergey) proposed openstack/ansible-collections-openstack master: Fix issue with multiple records in recordset https://review.opendev.org/c/openstack/ansible-collections-openstack/+/872392
19:42:34 opendevreview Rajat Dhasmana proposed openstack/python-openstackclient master: Add block storage log level {list, set} commands https://review.opendev.org/c/openstack/python-openstackclient/+/869811
20:00:43 opendevreview Rajat Dhasmana proposed openstack/python-openstackclient master: Add block storage log level {list, set} commands https://review.opendev.org/c/openstack/python-openstackclient/+/869811
20:08:07 opendevreview Rajat Dhasmana proposed openstack/python-openstackclient master: Add block storage work cleanup command https://review.opendev.org/c/openstack/python-openstackclient/+/872390
#openstack-sdks - 2023-02-02
09:08:18 opendevreview Polina Gubina proposed openstack/ansible-collections-openstack master: The following modules will be added: - vpn service - vpn ike policy - vpn ipsec policy https://review.opendev.org/c/openstack/ansible-collections-openstack/+/872516
16:28:57 eest just to report back for the people trying to help me with my openstacksdk code not doing version detection earlier, it turns out the servers were not patched for https://opendev.org/openstack/nova/commit/1e907602e37fb55bbe5a20164db6d074f87369af
16:29:20 eest so this explains why i got some things to work by configuring compute_api_version: "2.79" etc
16:29:32 eest but things seems to work well now
16:31:52 gtema eest - this is a great facepalm. I am through billions of similar things. I feel you ;-)
16:34:51 eest :)
17:09:07 umbSublime Question about `openstack.connect()`. I have a clouds.yaml file that defines a cloud names 'pci' in that cloud I have multiple regions(my_region1, my_region2. If I set my envvars to OS_CLOUD=pci OS_REGION_NAME=my_region2. And run openstack.connect(), it loads the cloud properly, but ignores my OS_REGION_NAME instead using the first from the clouds.yaml file. Is this expected
17:09:10 umbSublime behaviour? Should I explicitely connect(region_name='my_region2') ?
17:09:22 umbSublime For reference using those 2 envvars work as expected with using the openstackclient
17:11:17 gtema umbSublime: it is always recommended to be explicit. afair once sdk finds entry in clouds.yaml it does not merge env vars into it
17:12:52 umbSublime gtema: good to know, since the envvar OS_CLOUD would need to read the config, I was expecting OS_REGION_NAME to be merged after. This appears to be how the openstackclient works. Would there be additional logic in the osc to handle this ?
17:14:15 umbSublime gtema: I agree explicit is always better, but having openstack.connect() work as I was expecting saves me from adding logic to handle those from argparse (or other).

Earlier   Later