opendevreview | Jakob Meng proposed openstack/ansible-collections-openstack master: Warn users about us breaking backward compatibility https://review.opendev.org/c/openstack/ansible-collections-openstack/+/843419 | 06:07 |
---|---|---|
opendevreview | Jakob 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/+/843569 | 06:28 |
opendevreview | Jan 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/+/839776 | 07:16 |
opendevreview | Jakob 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/+/843569 | 07:38 |
opendevreview | Jakob Meng proposed openstack/openstacksdk master: [DNM] Added generic resource filtering by name_or_id, jmespath and dicts https://review.opendev.org/c/openstack/openstacksdk/+/843587 | 09:31 |
jm1 | gtema: moin :) filters proof of concept for discussion https://review.opendev.org/c/openstack/openstacksdk/+/843587 | 09:32 |
jm1 | gtema: is this similar to what you had in mind? | 09:33 |
gtema | yes, the direction is right | 09:34 |
gtema | we might need to think how to deal with whichever filters are supported or not | 09:34 |
gtema | and list should never get name_or_id argument | 09:35 |
jm1 | gtema: name_or_id could be replaced with a jsonpath filter in "filters" or something similar | 09:39 |
gtema | well, the point is that you should not call list function when you expect single entry | 09:40 |
gtema | for us it was always: if name_or_id is given we invoke search, otherwise go to list with filters | 09:41 |
gtema | s/search/find/ | 09:41 |
jm1 | gtema: makes sense. so we drop name_or_id from Resource.list() in that patch. | 09:48 |
gtema | yeah, I would say we should | 09:48 |
gtema | we do not want to have even more breaking changes ;-) | 09:48 |
jm1 | gtema: 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 function | 09:49 |
jm1 | gtema: maybe let me code an example, hard to describe.. | 09:49 |
gtema | yes, we can do with cloud functions pretty much everything what we now need | 09:50 |
gtema | yupp | 09:50 |
jm1 | gtema: 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 |
gtema | not really | 09:51 |
gtema | we pass already query params as **params | 09:51 |
gtema | and those already implement most of the queries | 09:51 |
gtema | mean most of the params | 09:51 |
gtema | so we might want jmespath not to overtake everything | 09:52 |
gtema | filter on server side is better then on client | 09:52 |
gtema | so we might also "try" to parse jmsepath and whatever is supported as server-side filter pass it this way | 09:53 |
gtema | but maybe for beginning (just to improve broken backward compatibility) we can skip this for now | 09:53 |
gtema | so whatever is passed in query params is applied on server, whatever through jmes - on client side | 09:53 |
jm1 | gtema: 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 |
gtema | strategically this idea is better. We want to give user possibility to apply filters even if server side doesn't support this | 10:00 |
gtema | but it should be also disabled by default, since currently we through exception when user passes some unsupported query params | 10:00 |
jm1 | gtema: ack, let me updated the proc | 10:06 |
jm1 | *poc | 10:06 |
gtema | sure, thanks | 10:06 |
opendevreview | Merged openstack/ansible-collections-openstack master: Warn users about us breaking backward compatibility https://review.opendev.org/c/openstack/ansible-collections-openstack/+/843419 | 12:10 |
opendevreview | Jakob Meng proposed openstack/openstacksdk master: [DNM] Added generic resource filtering by name_or_id, jmespath and dicts https://review.opendev.org/c/openstack/openstacksdk/+/843587 | 12:43 |
jm1 | gtema: updated poc https://review.opendev.org/c/openstack/openstacksdk/+/843587 | 12:44 |
gtema | cool, will look deeper once I have some spare time | 12:44 |
jm1 | gtema: sure, np | 12:44 |
opendevreview | Jakob 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/+/843528 | 12:48 |
opendevreview | Jakob 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/+/843528 | 12:54 |
opendevreview | Merged openstack/cliff master: Update Python testing per Zed cycle testing runtime https://review.opendev.org/c/openstack/cliff/+/843312 | 13:29 |
opendevreview | Merged 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/+/843569 | 14:36 |
opendevreview | Merged openstack/ansible-collections-openstack stable/1.0.0: Warn users about us breaking backward compatibility https://review.opendev.org/c/openstack/ansible-collections-openstack/+/843528 | 14:37 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!