Friday, 2022-05-27

opendevreviewJakob Meng proposed openstack/ansible-collections-openstack master: Warn users about us breaking backward compatibility  https://review.opendev.org/c/openstack/ansible-collections-openstack/+/84341906:07
opendevreviewJakob Meng proposed openstack/ansible-collections-openstack stable/1.0.0: Use bifrost's stable/yoga branch for jobs with OpenStack SDK 0.x.x  https://review.opendev.org/c/openstack/ansible-collections-openstack/+/84356906:28
opendevreviewJan Horstmann proposed openstack/ansible-collections-openstack master: Return details in baremetal_node_info when iterating over all machines  https://review.opendev.org/c/openstack/ansible-collections-openstack/+/83977607:16
opendevreviewJakob Meng proposed openstack/ansible-collections-openstack stable/1.0.0: Use bifrost's stable/yoga branch for jobs with OpenStack SDK 0.x.x  https://review.opendev.org/c/openstack/ansible-collections-openstack/+/84356907:38
opendevreviewJakob Meng proposed openstack/openstacksdk master: [DNM] Added generic resource filtering by name_or_id, jmespath and dicts  https://review.opendev.org/c/openstack/openstacksdk/+/84358709:31
jm1gtema: moin :) filters proof of concept for discussion https://review.opendev.org/c/openstack/openstacksdk/+/84358709:32
jm1gtema: is this similar to what you had in mind?09:33
gtemayes, the direction is right09:34
gtemawe might need to think how to deal with whichever filters are supported or not09:34
gtemaand list should never get name_or_id argument09:35
jm1gtema: name_or_id could be replaced with a jsonpath filter in "filters" or something similar09:39
gtemawell, the point is that you should not call list function when you expect single entry09:40
gtemafor us it was always: if name_or_id is given we invoke search, otherwise go to list with filters09:41
gtemas/search/find/09:41
jm1gtema: makes sense. so we drop name_or_id from Resource.list() in that patch. 09:48
gtemayeah, I would say we should09:48
gtemawe do not want to have even more breaking changes ;-)09:48
jm1gtema: Cloud layer search_* functions always returned lists even with name_or_id given, unlike find functions. To keep this functionality we could add jsonpath expr. or similar things to filters in cloud function09:49
jm1gtema: maybe let me code an example, hard to describe..09:49
gtemayes, we can do with cloud functions pretty much everything what we now need09:50
gtemayupp09:50
jm1gtema: what did you mean "we might need to think how to deal with whichever filters are supported or not"? like dropping jmespath stuff or something?09:50
gtemanot really09:51
gtemawe pass already query params as **params09:51
gtemaand those already implement most of the queries09:51
gtemamean most of the params09:51
gtemaso we might want jmespath not to overtake everything 09:52
gtemafilter on server side is better then on client09:52
gtemaso we might also "try" to parse jmsepath and whatever is supported as server-side filter pass it this way09:53
gtemabut maybe for beginning (just to improve broken backward compatibility) we can skip this for now09:53
gtemaso whatever is passed in query params is applied on server, whatever through jmes - on client side09:53
jm1gtema: my first idea was to drop this "filters" argument and instead add a param like "use_unknown_params_as_filters=False". We know what params are query params, so we could use all non-query-params as postprocessing filters. But i dropped that idea because this would not allow us to implement name_or_id in Resource.list() and does not allow using jmespath exprs. like a dedicated "filters" param does. But maybe you like that idea more?09:57
gtemastrategically this idea is better. We want to give user possibility to apply filters even if server side doesn't support this10:00
gtemabut it should be also disabled by default, since currently we through exception when user passes some unsupported query params10:00
jm1gtema: ack, let me updated the proc10:06
jm1*poc10:06
gtemasure, thanks10:06
opendevreviewMerged openstack/ansible-collections-openstack master: Warn users about us breaking backward compatibility  https://review.opendev.org/c/openstack/ansible-collections-openstack/+/84341912:10
opendevreviewJakob Meng proposed openstack/openstacksdk master: [DNM] Added generic resource filtering by name_or_id, jmespath and dicts  https://review.opendev.org/c/openstack/openstacksdk/+/84358712:43
jm1gtema: updated poc https://review.opendev.org/c/openstack/openstacksdk/+/84358712:44
gtemacool, will look deeper once I have some spare time12:44
jm1gtema: sure, np12:44
opendevreviewJakob Meng proposed openstack/ansible-collections-openstack stable/1.0.0: Warn users about us breaking backward compatibility  https://review.opendev.org/c/openstack/ansible-collections-openstack/+/84352812:48
opendevreviewJakob Meng proposed openstack/ansible-collections-openstack stable/1.0.0: Warn users about us breaking backward compatibility  https://review.opendev.org/c/openstack/ansible-collections-openstack/+/84352812:54
opendevreviewMerged openstack/cliff master: Update Python testing per Zed cycle testing runtime  https://review.opendev.org/c/openstack/cliff/+/84331213:29
opendevreviewMerged openstack/ansible-collections-openstack stable/1.0.0: Use bifrost's stable/yoga branch for jobs with OpenStack SDK 0.x.x  https://review.opendev.org/c/openstack/ansible-collections-openstack/+/84356914:36
opendevreviewMerged openstack/ansible-collections-openstack stable/1.0.0: Warn users about us breaking backward compatibility  https://review.opendev.org/c/openstack/ansible-collections-openstack/+/84352814:37

Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!