May 2021 - openstack-discuss - lists.openstack.org

[mistral] glance image upload
by Arnaud Morin 21 May '21

21 May '21

Hey team, Is there any way to upload/download an image to/from glance using a mistral workflow? I am seeing the glance.images_upload and glance.images_data, but I cant figure out how it works, I was thinking that we could provide some sort of swift URL to download/upload from. Is there any example available somewhere or maybe it's not yet implemented? Thanks

3 2

[Senlin][Octavia] Health policy - LB_STATUS_POLLING detection mode
by Giacomo Lanciano 21 May '21

21 May '21

Hi folks, I'd like to know what is the status of making the LB_STATUS_POLLING detection mode available for the Senlin Health Policy [1]. According to the docs and this patch [2], the implementation of this feature is blocked by some issue on LBaaS/Octavia side, but I could not find any details on what this issue really is. As the docs state, it would be really useful to have this detection mode available, as it is much more reliable than the others at evaluating the status of an application. If I can be of any help, I would be willing to contribute. Thanks in advance. Kind regards. Giacomo [1] https://docs.openstack.org/senlin/latest/contributor/policies/health_v1.htm… [2] https://review.opendev.org/c/openstack/senlin/+/423012 -- Giacomo Lanciano Ph.D. Student in Data Science Scuola Normale Superiore, Pisa, Italy https://www.linkedin.com/in/giacomolanciano

2 2

[neutron][stadium][stable] Proposal to make stable/ocata and stable/pike branches EOL
by Slawek Kaplonski 20 May '21

20 May '21

Hi, I checked today that stable/ocata and stable/pike branches in both Neutron and neutron stadium projects are pretty inactive since long time. * according to [1], last patch merged patch in Neutron for stable/pike was in July 2020 and in ocata October 2019, * for stadium projects, according to [2] it was September 2020. According to [3] and [4] there are no opened patches for any of those branches for Neutron and any stadium project except neutron-lbaas. So based on that info I want to propose that we will close both those branches are EOL now and before doing that, I would like to know if anyone would like to keep those branches to be open still. [1] https://review.opendev.org/q/project:%255Eopenstack/neutron+(branch:stable/ ocata+OR+branch:stable/pike)+status:merged[1] [2] https://review.opendev.org/q/(project:openstack/ovsdbapp+OR+project:opensta… +(branch:stable/ocata+OR+branch:stable/pike)+status:merged[2] [3] https://review.opendev.org/q/project:%255Eopenstack/neutron+(branch:stable/ ocata+OR+branch:stable/pike)+status:open[3] [4] https://review.opendev.org/q/(project:openstack/ovsdbapp+OR+project:opensta… +(branch:stable/ocata+OR+branch:stable/pike)+status:open[4] -- Slawek Kaplonski Principal Software Engineer Red Hat -------- [1] https://review.opendev.org/q/project:%255Eopenstack/neutron+(branch:stable/ ocata+OR+branch:stable/pike)+status:merged [2] https://review.opendev.org/q/(project:openstack/ovsdbapp+OR+project:opensta… +(branch:stable/ocata+OR+branch:stable/pike)+status:merged [3] https://review.opendev.org/q/project:%255Eopenstack/neutron+(branch:stable/ ocata+OR+branch:stable/pike)+status:open [4] https://review.opendev.org/q/(project:openstack/ovsdbapp+OR+project:opensta… +(branch:stable/ocata+OR+branch:stable/pike)+status:open

6 11

OVN ovsdb clustering question
by Satish Patel 20 May '21

20 May '21

Folks, I have 3 controller nodes and am trying to setup clustering for OVN deployment, but lack enough documentation and have some issues and questions regarding it. I found this document but again its little confusing and very old - https://mail.openvswitch.org/pipermail/ovs-discuss/2018-March/046470.html # controller 1 /usr/share/ovn/scripts/ovn-ctl --db-nb-addr=172.30.40.93 \ --db-nb-create-insecure-remote=yes \ --db-sb-addr=172.30.40.93 \ --db-sb-create-insecure-remote=yes \ --db-nb-cluster-local-addr=172.30.40.93 \ --db-sb-cluster-local-addr=172.30.40.93 \ --ovn-northd-nb-db=tcp:172.30.40.93:6641,tcp:172.30.40.25:6641,tcp:172.30.40.177:6641 \ --ovn-northd-sb-db=tcp:172.30.40.93:6642,tcp:172.30.40.25:6642,tcp:172.30.40.177:6642 \ start_northd # controller 2 /usr/share/ovn/scripts/ovn-ctl --db-nb-addr=172.30.40.25 \ --db-nb-create-insecure-remote=yes \ --db-sb-addr=172.30.40.25 \ --db-sb-create-insecure-remote=yes \ --db-nb-cluster-local-addr=172.30.40.25 \ --db-sb-cluster-local-addr=172.30.40.25 \ --db-nb-cluster-remote-addr=172.30.40.93 \ --db-sb-cluster-remote-addr=172.30.40.93 \ --ovn-northd-nb-db=tcp:172.30.40.93:6641,tcp:172.30.40.25:6641,tcp:172.30.40.177:6641 \ --ovn-northd-sb-db=tcp:172.30.40.93:6642,tcp:172.30.40.25:6642,tcp:172.30.40.177:6642 \ start_northd # controller 3 /usr/share/ovn/scripts/ovn-ctl --db-nb-addr=172.30.40.177 \ --db-nb-create-insecure-remote=yes \ --db-nb-cluster-local-addr=172.30.40.177 \ --db-sb-addr=172.30.40.177 \ --db-sb-create-insecure-remote=yes \ --db-sb-cluster-local-addr=172.30.40.177 \ --db-nb-cluster-remote-addr=172.30.40.93 \ --db-sb-cluster-remote-addr=172.30.40.93 \ --ovn-northd-nb-db=tcp:172.30.40.93:6641,tcp:172.30.40.25:6641,tcp:172.30.40.177:6641 \ --ovn-northd-sb-db=tcp:172.30.40.93:6642,tcp:172.30.40.25:6642,tcp:172.30.40.177:6642 \ start_northd ## Validation steps controller-2# export\ remote="tcp:172.30.40.93:6641,tcp:172.30.40.25:6641,tcp:172.30.40.177:6641" controller-2# ovn-nbctl --db=$remote show controller-2# In the above command i am seeing output only when it hit controller-1 node, but for node-2 and note-3 giving me empty output that means data replication doesn't work. what is the command to verify synchronization working between all 3 nodes? Do I need to restart any other services?

1 0

[sdk] R1.0 preparation work
by Artem Goncharov 20 May '21

20 May '21

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:feat… <https://review.opendev.org/q/project:openstack%2Fopenstacksdk+branch:featur…> [2] https://opendev.org/openstack/ansible-collections-openstack <https://opendev.org/openstack/ansible-collections-openstack>

3 5

[TripleO] next irc meeting Tuesday 25 May @ 1400 UTC in #tripleo
by Marios Andreou 20 May '21

20 May '21

Reminder that the next TripleO irc meeting is: ** Tuesday 25 May 1400 UTC in freenode irc channel: #tripleo ** ** https://wiki.openstack.org/wiki/Meetings/TripleO ** ** https://etherpad.opendev.org/p/tripleo-meeting-items ** Please add anything you want to highlight at https://etherpad.opendev.org/p/tripleo-meeting-items This can be recently completed things, ongoing review requests, blocking issues, or anything else tripleo you want to share. Our last meeting was on May 11 - you can find the logs there http://eavesdrop.openstack.org/meetings/tripleo/2021/tripleo.2021-05-11-14.… Hope you can make it on Tuesday, regards, marios

1 0

[neutron] Drivers meeting 21.05.2021 and 28.05.2021 cancelled
by Slawek Kaplonski 20 May '21

20 May '21

Hi, We don't have any new RFEs to discuss [1] so let's cancel tomorrow's drivers meeting. Next week (28.05.2021) we have Recharge Day in Red Hat so we will probably not have quorum on the drivers meeting and I will also be offline so let's cancel it too. See You on the drivers meeting in 2 weeks (4.06.2021). Have a great weekend :) [1] https://wiki.openstack.org/wiki/Meetings/NeutronDrivers[1] -- Slawek Kaplonski Principal Software Engineer Red Hat -------- [1] https://wiki.openstack.org/wiki/Meetings/NeutronDrivers

2 1

[horizon] Cross-domain user/role/project management
by Martin Chlumsky 20 May '21

20 May '21

Hello, We run a cloud service with multiple keystone domains (Default domain and later we added a federated domain (AzureAD)). We are giving "federated domain users" roles on the projects in the Default domain which existed before the integration with AureAD. Is there a way to manage cross-domain role assignments in Horizon? A horizon setting I missed? I tried as admin and only users and projects of one domain at a time ever show up (I tried switching the domain context to Default and the federated domain). Thank you, Martin

1 0

[ussuri][tripleo][ironic][tftp] add --blocksize to tftp during installation
by Ruslanas Gžibovskis 20 May '21

20 May '21

Hi all, I wanted to ask, is there an option in tripleO to deploy undercloud tftp server with additional option, I had to add it to /usr/share/openstack-tripleo-heat-templates/deployment/ironic/ironic-pxe-container-puppet.yaml, so my container start cmd looks like this now: tripleoussuri/centos-binary-ironic-pxe:current-tripleo /bin/bash -c BIND_HOST=$(hiera ironic::pxe::tftp_bind_host -c /etc/puppet/hiera.yaml); /usr/sbin/in.tftpd --foreground --user root --address $BIND_HOST:69 --blocksize 1399 --m ap-file /var/lib/ironic/tftpboot/map-file /var/lib/ironic/tftpboot ironic_pxe_tftp But I believe it should be possibility with ExtraConfigUndercloud? I know, our network better should be fixed, but it will take several decades :) and while it will be fixed I want to automate deployment and it should be upgrade resistant :) Thanks for the advice in advance. -- Ruslanas Gžibovskis +370 6030 7030

1 0

[TripleO] tripleo-ci-centos-8-containers-multinode now using ephemeral Heat for master/wallaby
by James Slagle 20 May '21

20 May '21

For awareness, I wanted to point out that tripleo-ci-centos-8-containers-multinode is now using ephemeral Heat on the master and wallaby branches. This change[1] merged yesterday that made the switch. Of note, the Heat logs for the overcloud deployment are now under the directory undercloud/home/zuul/overcloud-deploy/overcloud/heat-launcher/log in the job logs. There is also a pending docs patch that covers a bit more how the feature works: https://review.opendev.org/c/openstack/tripleo-docs/+/783008 [1] https://review.opendev.org/c/openstack/tripleo-quickstart/+/777108 -- -- James Slagle --

1 0