<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, May 20, 2021 at 9:39 AM Artem Goncharov <<a href="mailto:artem.goncharov@gmail.com">artem.goncharov@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">Yes, absolutely. I would prefer us to implement those in feature branch and cherry-picking those to master.<br></blockquote><div><br></div><div>+1 Awesome. We have a number of manila patches in-flight that I wish to refresh, i'll retarget them to the r1 branch and cherry-pick into master when they merge. We don't yet use openstacksdk in manila-ui or python-manilaclient, or have our own ansible collections modules yet - so while we chase features, this may be a delayed concern for the manila folks. <br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
<br>
<br>
> On 20. May 2021, at 18:34, Michael Johnson <<a href="mailto:johnsomor@gmail.com" target="_blank">johnsomor@gmail.com</a>> wrote:<br>
> <br>
> Hi Artem,<br>
> <br>
> My one concern about new features only landing in the feature branch<br>
> is we have dependencies that may require new service project features<br>
> to land in the main branch.<br>
> I.e. The Octavia dashboard uses openstacksdk, so if we need to add a<br>
> new feature we need to land it in SDK at the same time.<br>
> <br>
> Can we consider that it is ok for project related new features to land<br>
> in both branches?<br>
> <br>
> Michael<br>
> <br>
> On Wed, May 19, 2021 at 3:40 AM Artem Goncharov<br>
> <<a href="mailto:artem.goncharov@gmail.com" target="_blank">artem.goncharov@gmail.com</a>> wrote:<br>
>> <br>
>> Hey all,<br>
>> <br>
>> 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" rel="noreferrer" target="_blank">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)<br>
>> <br>
>> Things to be done:<br>
>> <br>
>> - get rid of all direct REST calls in the cloud layer. Instead reuse corresponding proxies [must]<br>
>> - generalise tag, metadata, quota(set), limits [must]<br>
>> - clean the code from some deprecated things and py2 remaining (if any) [must]<br>
>> - review resource caching to be implemented on the resource layer [optional]<br>
>> - introduction of read-only resource properties [optional]<br>
>> - restructure documentation to make it more used friendly [optional]<br>
>> <br>
>> <br>
>> Planned R1 interface changes<br>
>> <br>
>> 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.<br>
>> 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.<br>
>> 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.<br>
>> <br>
>> <br>
>> 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.<br>
>> <br>
>> <br>
>> 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.<br>
>> <br>
>> <br>
>> Any concerns? Suggestions?<br>
>> <br>
>> <br>
>> Regards,<br>
>> Artem<br>
>> <br>
>> <br>
>> [1] <a href="https://review.opendev.org/q/project:openstack%252Fopenstacksdk+branch:feature%252Fr1" rel="noreferrer" target="_blank">https://review.opendev.org/q/project:openstack%252Fopenstacksdk+branch:feature%252Fr1</a><br>
>> [2] <a href="https://opendev.org/openstack/ansible-collections-openstack" rel="noreferrer" target="_blank">https://opendev.org/openstack/ansible-collections-openstack</a><br>
>> <br>
<br>
<br>
</blockquote></div></div>