Hey all, As we were discussing during the PTG preparation work for the openstacksdk R1.0 has been started. There is now feature branch “feature/r1” and a set of patches already in place ([1]). (While https://review.opendev.org/c/openstack/devstack/+/791541 <https://review.opendev.org/c/openstack/devstack/+/791541> is not merged there are no functional tests running, but that is not blocking from doing the main work) Things to be done: - get rid of all direct REST calls in the cloud layer. Instead reuse corresponding proxies [must] - generalise tag, metadata, quota(set), limits [must] - clean the code from some deprecated things and py2 remaining (if any) [must] - review resource caching to be implemented on the resource layer [optional] - introduction of read-only resource properties [optional] - restructure documentation to make it more used friendly [optional] Planned R1 interface changes Every cloud layer method (Connection.connection.***, and not i.e. Connection.connection.compute.***) will consistently return Resource objects. At the moment there is a mix of Munch and Resource types depending on the case. Resource class itself fulfil dict, Munch and attribute interface, so there should be no breaking changes for getting info out of it. The only known limitation is that compared to bare dict/Munch it might be not allowed to modify some properties directly on the object. Ansible collection modules [2] would be modified to explicitly convert return of sdk into dict (Resource.to_dict()) to further operate on it. This means that in some cases older Ansible modules (2.7-2.9) will not properly work with newer SDK. Zuul jobs and everybody stuck without possibility to use newer Ansible collection [2] are potential victims here (depends on the real usage pattern). Sadly there is no way around it, since historically ansible modules operate whatever SDK returns and Ansible sometimes decides to alter objects (i.e. no_log case) what we might want to forbid (read-only or virtual properties). Sorry about that. In some rare cases attribute naming (whatever returned by the cloud layer) might be affected (i.e. is_bootable vs bootable). We are going to strictly bring all names to the convention. Due to the big amount of changes touching lot of files here I propose to stop adding new features into the master branch directly and instead put them into feature/r1 branch. I want to keep master during this time more like a stable branch for bugfixes and other important things. Once r1 branch feel ready we will merge it into master and most likely release something like RC to be able to continue integration work with Ansible. Everybody interested in the future of sdk is welcome in doing reviews and code [1] to know what comes and to speed up the work. Any concerns? Suggestions? Regards, Artem [1] https://review.opendev.org/q/project:openstack%252Fopenstacksdk+branch:featu... <https://review.opendev.org/q/project:openstack%2Fopenstacksdk+branch:feature%2Fr1> [2] https://opendev.org/openstack/ansible-collections-openstack <https://opendev.org/openstack/ansible-collections-openstack>