October 2020 - openstack-discuss - lists.openstack.org

[elections][tc][telemetry] Wallaby Cycle PTL and TC polling stats
by Jeremy Stanley 15 Oct '20

15 Oct '20

Find attached historical analysis of election turnout (electorate size and number of ballots returned) updated with the data from the Wallaby Cycle TC and Telemetry PTL polls. I'm happy to answer any questions folks may have about these, or dig into additional related statistics anyone may be interested in seeing. -- Jeremy Stanley

2 1

Re: [cinder][manila][swift] Edge discussions at the upcoming PTG
by Tom Barron 15 Oct '20

15 Oct '20

[adding the list address back end, I was the one who dropped it by accident] On 14/10/20 08:42 +0200, Ildiko Vancsa wrote: >Hi Tom, > >Sounds good! I think that topic would resonate well with people in the edge wg and it would be an interesting discussion especially when it comes to the containers part. > >Adjusting to what Brian was saying in his mail if that works for you too we could start with storage discussions on Monday to see how the landscape looks and what the needs and thoughts are. On top of that if needed we could go into cross-project sync with Manila to sync on the project specific roadmaps and action items if any on Wednesday. Does that make sense? > >Thanks, >Ildikó > > >> On Oct 13, 2020, at 23:14, Tom Barron <tpb(a)dyncloud.net> wrote: >> >> On 13/10/20 16:48 -0400, Brian Rosmaita wrote: >>> On 10/7/20 11:27 AM, Ildiko Vancsa wrote: >>>> Hi, >>>> >>>> We’ve started to have discussions in the area of object storage needs and solutions for edge use cases at the last PTG in June. I’m reaching out with the intention to continue this chat at the upcoming PTG in a few weeks. >>>> >>>> The OSF Edge Computing Group is meeting during the first three days of the PTG like last time. We are planning to have edge reference architecture models and testing type of discussions in the first two days (October 26-27) and have a cross-project and cross-community day on Wednesday (October 28). We would like to have a dedicated section for storage either on Monday or Tuesday. >>>> >>>> I think it might also be time to revisit other storage options as well if there’s interest. >>>> >>>> What do people think? >>> >>> I asked around the Cinder community a bit, and we don't have any particular topics to discuss at this point. But if you scheduled the storage discussion on Monday, some of us would be interested in attending just to hear what edge people are currently talking about storage-wise. (Cinder is meeting Tuesday-Friday.) >>> >>> If something does come up that the Edge group would like to talk over with the Cinder team, we can make time for that on Wednesday. >>> >>> >>> cheers, >>> brian >>> >>>> >>>> For reference: >>>> * Our planning etherpad is here: https://etherpad.opendev.org/p/ecg-vptg-october-2020 >>>> * Notes from the previous PTG is here: https://etherpad.opendev.org/p/ecg_virtual_ptg_planning_june_2020 >>>> >>>> Thanks, >>>> Ildikó >> >> Ildiko, >> >> We in Manila have discussed Edge deployment of shared file system service quite a bit. Currently we think of the problem primarily as how to provide safe, multi-tenant shared file system infrastructure local to each Edge site so that the data path remains available to consumers at the Edge site even when it is disconnected from the core. >> We'd like the storage to be available both to workloads running in VMs and to workloads running in containers at the edge (whether the containers reside in VMs or on bare metal edge hosts). >> >> I'm interested in calibrating this view of the problem set with actual Edge use cases and deployment perspectives and I'm sure Manila folks (like our PTL Goutham Pacha Ravi) would be happy to join in a cross-project session. >> >> -- Tom Barron >> >

1 0

[cinder][manila][swift] Edge discussions at the upcoming PTG
by Ildiko Vancsa 15 Oct '20

15 Oct '20

Hi, We’ve started to have discussions in the area of object storage needs and solutions for edge use cases at the last PTG in June. I’m reaching out with the intention to continue this chat at the upcoming PTG in a few weeks. The OSF Edge Computing Group is meeting during the first three days of the PTG like last time. We are planning to have edge reference architecture models and testing type of discussions in the first two days (October 26-27) and have a cross-project and cross-community day on Wednesday (October 28). We would like to have a dedicated section for storage either on Monday or Tuesday. I think it might also be time to revisit other storage options as well if there’s interest. What do people think? For reference: * Our planning etherpad is here: https://etherpad.opendev.org/p/ecg-vptg-october-2020 * Notes from the previous PTG is here: https://etherpad.opendev.org/p/ecg_virtual_ptg_planning_june_2020 Thanks, Ildikó

3 4

Multiple backend for Openstack
by Deepa KR 15 Oct '20

15 Oct '20

Hi All Good Day >From documentation we are able to understand that we can configure multiple backends for cinder (Ceph ,External Storage device or NFS etc) Is there any way we can choose the backend while instance launching .Say instance1 backend should be from an external storage device like EMC and instance2 to launch and have backend volume from ceph .Can this be achieved using cinder availability zone implementation or any other way? I have gone through below link (*section Configure Block Storage scheduler multi back end)* https://docs.openstack.org/cinder/latest/admin/blockstorage-multi-backend.h… Suggestions please .. Regards, Deepa K R

4 4

[all][elections][tc] Technical Committee Election Results
by Jeremy Stanley 15 Oct '20

15 Oct '20

Please join me in congratulating the 4 newly elected members of the Technical Committe (TC). Dan Smith Ghanshyam Mann (gmann) Jay Bryant (jungleboyj) Kendall Nelson (diablo_rojo) Full results: https://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_f3d92f86f4254553 Election process details and results are also available here: https://governance.openstack.org/election/ Thank you to all of the candidates, having a good group of candidates helps engage the community in our democratic process. Thank you to all who voted and who encouraged others to vote. We need to ensure your voice is heard. Thank you for another great round. -- Jeremy Stanley on behalf of the OpenStack Technical Election Officials

3 2

[kolla] Reversing deprecation of VMware integration
by Mark Goddard 15 Oct '20

15 Oct '20

Hi, In the Ussuri release we deprecated support for VMware due to Nova deprecating their VMware driver, a lack of CI, and a lack of interest from the community. Since then, Nova has reversed the deprecation, and we know of at least one interested user. We are therefore reversing our deprecation of VMware support in Kolla. If you are interested in this driver, please help out with maintenance since we are unable to verify changes without CI. Regards, Mark

1 0

OpenStack Victoria is officially released!
by Sean McGinnis 15 Oct '20

15 Oct '20

The official OpenStack Victoria release announcement has been sent out: http://lists.openstack.org/pipermail/openstack-announce/2020-October/002041… Thanks to all who were a part of the Victoria development cycle! This marks the official opening of the releases repo for Wallaby, and freezes are now lifted. Victoria is now a fully normal stable branch, and the normal stable policy now applies. Thanks! Sean

3 2

[ops][cinder] brocade fczm driver situation update
by Brian Rosmaita 14 Oct '20

14 Oct '20

Happy Victoria Release Day! This is a follow-up to my 26 June 2020 email concerning the proposed removal from cinder of the Brocade Fibre Channel Zone Manager driver [0], which, you may recall, the vendor no longer supports after the Train release and which was not operational in a Python 3 environment. The Cinder community has decided to assume the maintenance of this driver on a best-effort basis. See the "Known Issues" and "Other Notes" sections of the cinder victoria release notes [1] and the statement in the driver documentation [2] for what exactly this means. Special thanks to Cinder core Gorka Eguileor for driving this effort. Gorka fixed the bugs that hitherto prevented the driver from operating in Python 3, and these fixes have been backported to stable/ussuri and stable/train. Gorka also ran CI on driver against cinder victoria RC-1. The Brocade FCZM driver does not have ongoing third-party CI. If you use this driver, and would be interested in running third-party CI for it, please contact the Cinder project team. And if you have a relationship with the vendor, you may wish to ask them to reconsider their stance on this driver. [0] http://lists.openstack.org/pipermail/openstack-discuss/2020-June/015692.html [1] https://docs.openstack.org/releasenotes/cinder/victoria.html [2] https://docs.openstack.org/cinder/victoria/configuration/block-storage/fc-z… [3] https://review.opendev.org/#/q/topic:brocade+(status:open+OR+status:merged)

1 0

Re: [Ussuri] [openstack-ansible] [cinder] Can't attach volumes to instances
by Oliver Wenz 14 Oct '20

14 Oct '20

> I recommend you run the attach request with the --debug flag to get the > request id, that way you can easily track the request and see where it > failed. > > Then you check the logs like Dmitriy mentions and see where things > failed. Running with the --debug flag returned the following ``` Starting new HTTP connection (1): 192.168.110.201:8774 http://192.168.110.201:8774 "GET /v2.1/servers/2fd482ac-7a93-4626-955f-77b78f783d54 HTTP/1.1" 200 1781 RESP: [200] Connection: close Content-Length: 1781 Content-Type: application/json OpenStack-API-Version: compute 2.1 Vary: OpenStack-API-Version, X-OpenStack-Nova-API-Version X-OpenStack-Nova-API-Version: 2.1 x-compute-request-id: req-56b2bf8f-f338-4d25-a54e-ce9cfb4e71d6 x-openstack-request-id: req-56b2bf8f-f338-4d25-a54e-ce9cfb4e71d6 RESP BODY: {"server": {"id": "2fd482ac-7a93-4626-955f-77b78f783d54", "name": "ubuntu_test", "status": "ACTIVE", "tenant_id": "5fbba868d04b47fa87a72b9dd821ee12", "user_id": "f78c008ff22d40d2870f1c34919c93ad", "metadata": {}, "hostId": "7d7e25a2fe22479152026feff6bd71cf32a46ea2ee78ec841c5973f8", "image": {"id": "84e94029-c737-4bb6-84a7-195002e6dbe9", "links": [{"rel": "bookmark", "href": "http://192.168.110.201:8774/images/84e94029-c737-4bb6-84a7-195002e6dbe9"}]}, "flavor": {"id": "94b75111-dfa2-4565-af5b-64e25e220861", "links": [{"rel": "bookmark", "href": "http://192.168.110.201:8774/flavors/94b75111-dfa2-4565-af5b-64e25e220861"}]}, "created": "2020-10-07T09:48:09Z", "updated": "2020-10-07T10:03:23Z", "addresses": {"test-001": [{"version": 4, "addr": "192.168.32.170", "OS-EXT-IPS:type": "fixed", "OS-EXT-IPS-MAC:mac_addr": "fa:16:3e:9b:a5:fe"}, {"version": 4, "addr": "192.168.113.29", "OS-EXT-IPS:type": "floating", "OS-EXT-IPS-MAC:mac_addr": "fa:16:3e:9b:a5:fe"}]}, "accessIPv4": "", "accessIPv6": "", "links": [{"rel": "self", "href": "http://192.168.110.201:8774/v2.1/servers/2fd482ac-7a93-4626-955f-77b78f783d…"}, {"rel": "bookmark", "href": "http://192.168.110.201:8774/servers/2fd482ac-7a93-4626-955f-77b78f783d54"}], "OS-DCF:diskConfig": "AUTO", "progress": 0, "OS-EXT-AZ:availability_zone": "nova", "config_drive": "", "key_name": "hiwi-PC", "OS-SRV-USG:launched_at": "2020-10-07T10:03:22.000000", "OS-SRV-USG:terminated_at": null, "security_groups": [{"name": "default"}], "OS-EXT-SRV-ATTR:host": "bc1blade14", "OS-EXT-SRV-ATTR:instance_name": "instance-00000007", "OS-EXT-SRV-ATTR:hypervisor_hostname": "bc1blade14.openstack.local", "OS-EXT-STS:task_state": null, "OS-EXT-STS:vm_state": "active", "OS-EXT-STS:power_state": 1, "os-extended-volumes:volumes_attached": []}} GET call to compute for http://192.168.110.201:8774/v2.1/servers/2fd482ac-7a93-4626-955f-77b78f783d… used request id req-56b2bf8f-f338-4d25-a54e-ce9cfb4e71d6 REQ: curl -g -i -X GET http://192.168.110.201:8776/v3/5fbba868d04b47fa87a72b9dd821ee12/volumes/a9e… -H "Accept: application/json" -H "User-Agent: python-cinderclient" -H "X-Auth-Token: {SHA256}7fa6e3ac57b32176603c393dd97a5ea04813739efb0d1d4bff4f9680ede427c1" Starting new HTTP connection (1): 192.168.110.201:8776 http://192.168.110.201:8776 "GET /v3/5fbba868d04b47fa87a72b9dd821ee12/volumes/a9e188a4-7981-4174-a31d-a258de2a7b3d HTTP/1.1" 200 1033 RESP: [200] Connection: close Content-Length: 1033 Content-Type: application/json OpenStack-API-Version: volume 3.0 Vary: OpenStack-API-Version x-compute-request-id: req-3d35fab2-88b2-46cf-a39a-f8942f3ee1c1 x-openstack-request-id: req-3d35fab2-88b2-46cf-a39a-f8942f3ee1c1 RESP BODY: {"volume": {"id": "a9e188a4-7981-4174-a31d-a258de2a7b3d", "status": "available", "size": 30, "availability_zone": "nova", "created_at": "2020-10-07T11:38:01.000000", "updated_at": "2020-10-12T09:57:53.000000", "attachments": [], "name": "test_volume_002", "description": "", "volume_type": "lvm", "snapshot_id": null, "source_volid": null, "metadata": {}, "links": [{"rel": "self", "href": "http://192.168.110.201:8776/v3/5fbba868d04b47fa87a72b9dd821ee12/volumes/a9e…"}, {"rel": "bookmark", "href": "http://192.168.110.201:8776/5fbba868d04b47fa87a72b9dd821ee12/volumes/a9e188…"}], "user_id": "f78c008ff22d40d2870f1c34919c93ad", "bootable": "false", "encrypted": false, "replication_status": null, "consistencygroup_id": null, "multiattach": false, "migration_status": null, "os-vol-tenant-attr:tenant_id": "5fbba868d04b47fa87a72b9dd821ee12", "os-vol-host-attr:host": "bc1bl10@lvm#LVM_iSCSI", "os-vol-mig-status-attr:migstat": null, "os-vol-mig-status-attr:name_id": null}} GET call to volumev3 for http://192.168.110.201:8776/v3/5fbba868d04b47fa87a72b9dd821ee12/volumes/a9e… used request id req-3d35fab2-88b2-46cf-a39a-f8942f3ee1c1 REQ: curl -g -i -X POST http://192.168.110.201:8774/v2.1/servers/2fd482ac-7a93-4626-955f-77b78f783d… -H "Accept: application/json" -H "Content-Type: application/json" -H "User-Agent: python-novaclient" -H "X-Auth-Token: {SHA256}7fa6e3ac57b32176603c393dd97a5ea04813739efb0d1d4bff4f9680ede427c1" -H "X-OpenStack-Nova-API-Version: 2.1" -d '{"volumeAttachment": {"volumeId": "a9e188a4-7981-4174-a31d-a258de2a7b3d", "device": "/dev/vdb"}}' Resetting dropped connection: 192.168.110.201 http://192.168.110.201:8774 "POST /v2.1/servers/2fd482ac-7a93-4626-955f-77b78f783d54/os-volume_attachments HTTP/1.1" 200 194 RESP: [200] Connection: close Content-Length: 194 Content-Type: application/json OpenStack-API-Version: compute 2.1 Vary: OpenStack-API-Version, X-OpenStack-Nova-API-Version X-OpenStack-Nova-API-Version: 2.1 x-compute-request-id: req-87ba31ae-3511-41be-a2b9-f6a0ccdb092a x-openstack-request-id: req-87ba31ae-3511-41be-a2b9-f6a0ccdb092a RESP BODY: {"volumeAttachment": {"id": "a9e188a4-7981-4174-a31d-a258de2a7b3d", "serverId": "2fd482ac-7a93-4626-955f-77b78f783d54", "volumeId": "a9e188a4-7981-4174-a31d-a258de2a7b3d", "device": "/dev/vdb"}} POST call to compute for http://192.168.110.201:8774/v2.1/servers/2fd482ac-7a93-4626-955f-77b78f783d… used request id req-87ba31ae-3511-41be-a2b9-f6a0ccdb092a clean_up AddServerVolume: END return value: 0 ``` However, I could not read the logs the way Dmitriy suggested, it simply returns -- Logs begin at Mon 2020-10-05 14:30:22 UTC, end at Mon 2020-10-12 11:17:20 UTC. -- -- No entries -- so I couldn't investigate the request. ( I tried this on both utility and cinder api containers on the management node and on the storage and respective compute node to be sure) > It's important that the target_ip_address can be accessed from the Nova > compute using the interface for the IP defined in my_ip in nova.conf my_ip in nova.conf seems to be the address of the nova_api container on the management node, target_ip_address from cinder.conf seems to be the (storage-net) address of the cinder-api container on the management node (the value is different from the iscsi_ip_address specified in the playbook). > IIRC, for lvm storage, cinder-volumes should be launched on every nova > compute node in order to attach volumes > to instances, since it's not shared storage. I did not try this yet since the documentation didn't mention it and for our current production system (mitaka, which someone else set up ages ago) this doesn't seem to be the case but volumes can still be attached. Kind regards, Oliver

2 1

[tripleo] deprecating Mistral service
by Emilien Macchi 14 Oct '20

14 Oct '20

Hi folks, In our long term goal to simplify TripleO and deprecate the services that aren't used by our community anymore, I propose that we deprecate Mistral services. Mistral was used on the Undercloud in the previous cycles but not anymore. While the service could be deployed on the Overcloud, we haven't seen any of our users doing it. If that would be the case, please let us know as soon as possible. Removing it from TripleO will help us with maintenance (container images, THT/puppet integration, CI, etc). Maybe we could deprecate it in Victoria and remove it in Wallaby? Thanks, -- Emilien Macchi

11 12