Earlier  
Later
New Search
Posted Nick Remark
#openstack-sdks - 2020-06-09
10:17:53 openstackgerrit Vishakha Agarwal proposed openstack/openstacksdk master: Add access rule CRUD support https://review.opendev.org/734549
11:10:52 openstackgerrit subham rai proposed openstack/openstacksdk master: baremetal: support for volume connectors API https://review.opendev.org/718746
12:09:13 openstackgerrit Sagi Shnaidman proposed openstack/ansible-collections-openstack master: Add notes to README about deps and versions https://review.opendev.org/734557
12:41:26 iurygregory mordred, dtantsur https://review.opendev.org/#/c/718746/ finally the functional tests for volume connectors are passing https://storage.bhs.cloud.ovh.net/v1/AUTH_dcaab5e32b234d56b626f72581e3644c/zuul_opendev_logs_96f/718746/14/check/openstacksdk-functional-devstack-ironic/96fb7a5/testr_results.html , so when you have a chance please review the patch =)
12:42:28 dtantsur I will, not promising about today
12:42:50 iurygregory sure =) don't need to be today
13:31:46 openstackgerrit Merged openstack/cliff master: drop mock from lower-constraints and requirements https://review.opendev.org/734326
13:32:50 openstackgerrit Artem Goncharov proposed openstack/python-openstackclient master: [POC] project cleanup https://review.opendev.org/734485
13:58:40 mordred iurygregory: woot!
13:59:31 iurygregory yup! sad that CI failed in openstack-tox-py37 D:
14:02:39 mordred iurygregory: well, we can't have everything :)
14:03:34 iurygregory mordred, it's CI we know the jobs have a chat to decide which one should fail =)
14:13:16 dtantsur so true
14:23:57 mordred the jobs have come alive
14:32:43 gtema_ mordred, dtantsur: first thoughts on https://review.opendev.org/#/c/734485/ are welcome (it's a mess with dependent changes on SDK, therefore currently not set at all)
14:33:33 gtema_ it's only about starting the "interface" in the OSC, and not about SDK implementation
14:33:44 dtantsur the first thought: I have no clue what the difference between "cleanup" and "purge" is
14:33:46 openstackgerrit Sagi Shnaidman proposed openstack/ansible-collections-openstack master: Add notes to README about deps and versions https://review.opendev.org/734557
14:34:00 gtema_ purge will be dropped
14:35:33 gtema_ it's a old implementation of the project_cleanup, which will not be as "powerful" as my cleanup :D
14:36:32 dtantsur why not reuse the old command?
14:37:17 iurygregory they were always alive, know they can talk (this is the problem)
14:37:19 iurygregory XD
14:48:57 gtema_ dtantsur - we can reuse the command, but I would suggest to do this when cleanup is ready. Currently I don't want to break somebody who use master (or if we need to do interim release)
14:54:55 mordred gtema_: I'd think auth-project should default to true if project isn't given, no?
14:55:16 gtema_ agree. I just for the moment took the I/F from the purge
14:55:47 mordred ++
14:56:13 gtema_ on the other hand - if you run accidentally with admin - having auth_project will perhaps help avoid
14:57:46 mordred gtema_: that is a good point
14:58:36 mordred openstack cleanup --yes-I-mean-it<accidental enter>
14:59:03 mordred gtema: if only you had access to a public cloud, you could run a bouncer in a vm ;)
14:59:06 gtema yupp, something like that
14:59:13 gtema sure
15:00:18 gtema for the --yes-I-mean-it we can do a dry run, print results and have a countdown to allow aborting (giggle)
15:01:16 mordred gtema: make it like 2fa - you have to respond to a text to proceed
15:01:33 gtema hmm
15:01:36 gtema nice idea
15:01:38 mordred "we have sent a message to your mother, please call her to find out the code"
15:02:06 mordred gtema: but overall I think that's looking good
15:02:34 gtema sorry, I'm laying on the floor laughing out loud
15:02:41 gtema thanks
15:02:41 mordred :)
15:03:04 mordred gtema: when you are able to get off the floor - could I get you to review https://review.opendev.org/#/c/733964/
15:03:09 gtema sure, greetings
15:03:18 gtema yes, you could
15:04:42 gtema btw, last friday I was in the manila team discussing the "common" commands of OSC. I suggest implementing __quota__ and other similar stuff in the cloud layer
15:05:04 gtema so that anyone can "inject" it's code without really needing OSC plugins for that
15:07:00 tbarron gtema: just sayin' thanks from the manila folks
15:07:10 gtema welcome tbarron
15:10:23 gtema mordred dtantsur: are we ok to pass a simple dict between project_cleanup threads for some needs, or should we better have a thread-safe wrapper
15:10:56 gtema this dry_run is making me crazy and I would need to analyze in the service, which other resources were identified by other service
15:11:30 gtema to be able to "assume", whether in the real mode this resource will stay or not
15:15:13 dtantsur gtema_: depends on what you're trying to do with the dict?
15:15:46 gtema_ well, it's mostly just to see, whether there is entry with resource_id identified for being dropped by other service
15:16:15 gtema_ so: set and get, but nothing really critical
15:16:21 openstackgerrit Monty Taylor proposed openstack/cliff master: Fix compatibility with new cmd2 https://review.opendev.org/712591
15:17:06 gtema_ what is in my mind is okay wrt GIL, but who knows
15:19:31 dtantsur I don't think get-then-set is necessary safe
15:20:10 gtema_ it's not get-then-set, it's more set in one thread, and only get in other
15:20:24 gtema_ unconditional set
15:21:15 gtema_ queue, that I have now is not giving easy possibility to loop through items there
15:21:50 gtema_ I mean without extracting element and putting it back
15:23:06 mordred gtema_: yes - I think quota and simlar should be in the cloud layer - for sure
15:23:51 gtema_ mordred - thks, will do so as break from cleanup later :D
15:24:36 mordred gtema_: and my read of dict is that it is thread-safe for gets and sets
15:25:10 gtema_ it's same for me, wanted just to check with you whether you think otherwise
15:26:27 gtema_ and this is really "not critical" - will not be there in the real run, who cares.
15:26:47 gtema_ Perhaps message in the cleanup should be "at least those resources will be deleted"
15:30:02 openstackgerrit Merged openstack/osc-lib master: Stop configuring install_command in tox and stop use pip. https://review.opendev.org/694510
16:36:12 openstackgerrit Merged openstack/cliff master: Import command group support from osc-lib https://review.opendev.org/733964
18:11:12 openstackgerrit Merged openstack/openstacksdk master: Fix AttributeError exception during authorization https://review.opendev.org/728077
18:43:10 openstackgerrit Gabriel Ramirez proposed openstack/python-openstackclient master: Allow openstack flavor set to update flavor description using name https://review.opendev.org/733688
19:20:04 openstackgerrit Monty Taylor proposed openstack/cliff master: Fix compatibility with new cmd2 https://review.opendev.org/712591
19:34:22 mordred TheJulia: heya - iurygregory was just asing in #openstack-ansible-sig about an issue that turns out to be about running bifrost from a virtualenv and then not finding libs ... are there any bifrost docs/recommendations about that usage pattern?
19:34:52 iurygregory mordred, im using the bifrost docs hehe
19:35:33 iurygregory https://docs.openstack.org/bifrost/latest/install/index.html and https://docs.openstack.org/bifrost/latest/user/howto.html
19:35:38 mordred heh. well - ansible+virtualenv is always special - so I figured maybe it was a chance to learn or improve the docs or something
19:37:38 iurygregory well so far what I can say is that for me on Fedora30 i need to set variables inside the venv so things will work
22:34:09 TheJulia iurygregory: Interesting :(
#openstack-sdks - 2020-06-10
06:33:15 openstackgerrit Vishakha Agarwal proposed openstack/openstacksdk master: Add access rule CRUD support https://review.opendev.org/734549
07:03:28 openstackgerrit Vishakha Agarwal proposed openstack/openstacksdk master: Add access rule CRUD support https://review.opendev.org/734549
07:09:10 openstackgerrit Vishakha Agarwal proposed openstack/openstacksdk master: NIT: Fix application credential https://review.opendev.org/734756
08:49:01 openstackgerrit Merged openstack/cliff master: Fix compatibility with new cmd2 https://review.opendev.org/712591
11:12:58 nightmare_unreal where should I discuss cliff related stuff ?
11:13:13 nightmare_unreal is this channel right for it
11:16:24 dtantsur nightmare_unreal: probably yes
11:17:43 nightmare_unreal okay so I have submitted this patch : https://review.opendev.org/#/c/733573/ . It's regarding the json output format in osc cli. I found out that it's cliff that actually manages/handles the output (tables, json, bash etc)
11:18:07 nightmare_unreal so should I abandon this patch and create one for cliff ?
11:18:59 nightmare_unreal in the above patch I made the changes to correct the json but because of it other formats are messed up. Like mentioned by frickler in the comment that I need to do it in a way where the format is processed.
11:19:15 nightmare_unreal I hope I am able to express myself clearly .
11:24:57 openstackgerrit Hervé Beraud proposed openstack/keystoneauth master: drop mock from lower-constraints https://review.opendev.org/734359
11:24:58 openstackgerrit Hervé Beraud proposed openstack/keystoneauth master: fix reno lower-constraints for py35 https://review.opendev.org/734799
11:43:00 openstackgerrit Sean McGinnis proposed openstack/keystoneauth master: Update lower-constraints versions https://review.opendev.org/734803
12:20:34 mordred nightmare_unreal: yes - I think that is a thing that needs to be fixed in cliff
12:21:55 nightmare_unreal thanks mordred . I will create new patch and submit it to cliff :)
12:22:39 mordred nightmare_unreal: cool! I'm not 100% sure what the answer will be - the nested data types have always been a little wonky
12:23:52 nightmare_unreal i am trying it. but I am not sure if it will be right way. I am currently looking at the keys that are formatted wrongly and just fix them up
12:24:09 nightmare_unreal but I think cliff is more generic so adding a specific code will be bad
12:24:15 nightmare_unreal not sure I will submit though
12:24:59 mordred yeah - it's possible this can't be solved in cliff and we still might need to fix it somehow in osc

Earlier   Later