
<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Hey all,<div class=""><br class=""></div><div class="">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 <a href="https://review.opendev.org/c/openstack/devstack/+/791541" class="">https://review.opendev.org/c/openstack/devstack/+/791541</a> is not merged there are no functional tests running, but that is not blocking from doing the main work)</div><div class=""><br class=""></div><div class=""><span style="font-size: 14px;" class="">Things to be done:</span></div><div class=""><span style="font-size: 14px;" class=""><br class=""></span></div><div class=""> - get rid of all direct REST calls in the cloud layer. Instead reuse corresponding proxies [must]</div> - generalise tag, metadata, quota(set), limits [must]<br class=""> - clean the code from some deprecated things and py2 remaining (if any) [must]<br class=""> - review resource caching to be implemented on the resource layer [optional]<br class=""><div class=""> - introduction of read-only resource properties [optional]</div><div class=""> - restructure documentation to make it more used friendly [optional]</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><span style="font-size: 14px;" class="">Planned R1 interface changes</span></div><div class=""><span style="font-size: 14px;" class=""><br class=""></span></div><div class="">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.</div><div class="">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.</div><div class="">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.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">Any concerns? Suggestions?</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">Regards,</div><div class="">Artem</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">[1] <a href="https://review.opendev.org/q/project:openstack%2Fopenstacksdk+branch:feature%2Fr1" class="">https://review.opendev.org/q/project:openstack%252Fopenstacksdk+branch:feature%252Fr1</a></div><div class="">[2] <a href="https://opendev.org/openstack/ansible-collections-openstack" class="">https://opendev.org/openstack/ansible-collections-openstack</a></div><div class=""><br class=""></div></body></html>