Earlier  
Later
New Search
Posted Nick Remark
#openstack-sdks - 2020-06-09
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 mordred :)
15:02:41 gtema thanks
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
12:25:12 mordred I'll try to look in a little bit and see if I can make better suggestions
12:40:31 openstackgerrit Monty Taylor proposed openstack/ansible-collections-openstack master: Fix idempotency with server security groups https://review.opendev.org/734810
13:45:58 openstackgerrit Sagi Shnaidman proposed openstack/ansible-collections-openstack master: Fix idempotency with server security groups https://review.opendev.org/734810
13:46:34 openstackgerrit Sagi Shnaidman proposed openstack/ansible-collections-openstack master: DNM test jobs https://review.opendev.org/732100
13:49:39 dtroyer mordred, nightmare_unreal: solving the general problem of nested structured output in cliff is the right place, however you may find that you still need to address individual situations in OSC too that don't fit the general solution.
13:51:06 nightmare_unreal yeah , makes sense. I will update . Thanks
14:04:13 dtroyer Dang, you guys have been busy! I can't wait to see what the command structure change does for startup times :)
14:04:36 gtema will be lightning fast :D
14:09:38 openstackgerrit Andreas Jaeger proposed openstack/service-types-authority master: Switch to newer openstackdocstheme version https://review.opendev.org/734852
14:11:15 mordred dtroyer: me either! :)

Earlier   Later