From tkajinam at redhat.com Sat Jan 2 09:42:51 2021 From: tkajinam at redhat.com (Takashi Kajinami) Date: Sat, 2 Jan 2021 18:42:51 +0900 Subject: [puppet][neutron] Status of networking-cisco and networking-bigswitch Message-ID: Hello, While cleaning up outdated implementations in puppet-neutron, I noticed that the following 2 plugins are supported by puppet-neutron but the plugins are no longer maintained actively these days. 1) networking-cisco https://opendev.org/x/networking-cisco This repo has not got any updates for these 2 year except fo opendev migration and supports not Python 3.6 but only Python 2.7 and Python 3.5. 2) networking-bigswitch https://opendev.org/x/networking-bigswitch This repo was updated 10 months ago, but doesn't have ussuri and victoria branch created. If I don't hear any plan to keep maintaining these 2 repositories I'll deprecate support for these 2 plugins in this release and remove the support completely in the next cycle. Thank you, Takashi Kajinami -------------- next part -------------- An HTML attachment was scrubbed... URL: From tempjohnsmith1377 at gmail.com Sat Jan 2 17:41:00 2021 From: tempjohnsmith1377 at gmail.com (john smith) Date: Sat, 2 Jan 2021 21:11:00 +0330 Subject: failed to launch openstack instance when integrate with odl Message-ID: hello I tried to integrate Openstack train with Opendaylight magnesium and my references were [1] and [2] but after doing all the steps, the instance failed to launch. I changed port_binding_controller in [ml2_odl] section in the ml2_conf.ini file from pseudo-agentdb-binding to legacy-port-binding and then the instance launched but the status of router interfaces was still down. I have a controller node and a compute node. and Opendaylight runs on the controller node. nova-compute.log: INFO nova.virt.libvirt.driver [-] [instance: 975fa79e-6567-4385-be87-9d12a8eb3e94] Instance destroyed successfully. 2021-01-02 12:33:23.383 25919 ERROR vif_plug_ovs.ovsdb.impl_vsctl [req-a0a7ebf0-7e63-4c60-a8d2-07c05f1aa4f4 04c7685a2166481a9ace54eb5e71f6e5 ca28ee1038254649ad133d5f09f7a186 - default default] Unable to execute ['ovs-vsctl', '--timeout=120', '--oneline', '--format=json', '--db=tcp: 127.0.0.1:6640', '--', '--if-exists', 'del-port', 'br-int', 'tap50eb0b68-a4']. Exception: Unexpected error while running command. Command: ovs-vsctl --timeout=120 --oneline --format=json --db=tcp: 127.0.0.1:6640 -- --if-exists del-port br-int tap50eb0b68-a4 Exit code: 1 Stdout: '' Stderr: 'ovs-vsctl: tcp:127.0.0.1:6640: database connection failed (Connection refused)\n': oslo_concurrency.processutils.ProcessExecutionError: Unexpected error while running command. controller ovs: Manager "tcp:192.168.222.48:6640" is_connected: true Bridge br-int Controller "tcp:192.168.222.48:6653" is_connected: true fail_mode: secure Port tune52c5c73a50 Interface tune52c5c73a50 type: vxlan options: {key=flow, local_ip="10.0.0.31", remote_ip="10.0.0.11"} Port br-int Interface br-int type: internal Bridge br-ex Port br-ex Interface br-ex type: internal Port ens160 Interface ens160 ovs_version: "2.13.1" compute ovs: Manager "tcp:192.168.222.48:6640" is_connected: true Bridge br-int Controller "tcp:192.168.222.48:6653" is_connected: true fail_mode: secure Port br-int Interface br-int type: internal Port tun34b3712d975 Interface tun34b3712d975 type: vxlan options: {key=flow, local_ip="10.0.0.11", remote_ip="10.0.0.11"} Port tund5123ce5b8a Interface tund5123ce5b8a type: vxlan options: {key=flow, local_ip="10.0.0.11", remote_ip="10.0.0.31"} ovs_version: "2.13.1" -------------- next part -------------- An HTML attachment was scrubbed... URL: From eandersson at blizzard.com Sun Jan 3 00:54:58 2021 From: eandersson at blizzard.com (Erik Olof Gunnar Andersson) Date: Sun, 3 Jan 2021 00:54:58 +0000 Subject: [magnum][api] Error system library fopen too many open files with magnum-auto-healer In-Reply-To: References: <185a9715-4667-9610-0048-5434e6e2cd4e@catalyst.net.nz> , Message-ID: Are you sure you aren't just looking at the connection pool expanding? Each worker has a max number of connections it can use. Maybe look at lowering rpc_conn_pool_size. By default I believe each worker might create a pool of up to 30 connections. Looking at the code it could also be have something to do with the k8s client. Since it creates a new instance each time it does an health check. What version of the k8s client do you have installed? ________________________________ From: Ionut Biru Sent: Tuesday, December 29, 2020 2:20 PM To: feilong Cc: openstack-discuss Subject: Re: [magnum][api] Error system library fopen too many open files with magnum-auto-healer Hi, Not sure if my suspicion is true but I think for each update a new notifier is prepared and used without closing the connection but my understanding of oslo is nonexistent. https://opendev.org/openstack/magnum/src/branch/master/magnum/conductor/utils.py#L147 https://opendev.org/openstack/magnum/src/branch/master/magnum/common/rpc.py#L173 On Tue, Dec 29, 2020 at 11:52 PM Ionut Biru > wrote: Hi Feilong, I found out that each time the update_health_status periodic task is run, a new connection(for each uwsgi) is made to rabbitmq. root at ctrl1cj-magnum-container-7a7a412a:~# netstat -npt | grep 5672 | wc -l 229 root at ctrl1cj-magnum-container-7a7a412a:~# netstat -npt | grep 5672 | wc -l 234 root at ctrl1cj-magnum-container-7a7a412a:~# netstat -npt | grep 5672 | wc -l 238 root at ctrl1cj-magnum-container-7a7a412a:~# netstat -npt | grep 5672 | wc -l 241 root at ctrl1cj-magnum-container-7a7a412a:~# netstat -npt | grep 5672 | wc -l 244 Not sure Dec 29 21:51:22 ctrl1cj-magnum-container-7a7a412a magnum-conductor[262800]: 2020-12-29 21:51:22.024 262800 DEBUG magnum.service.periodic [req-3b495326-cf80-481e-b3c6-c741f05b7f0e - - - - -] Dec 29 21:51:22 ctrl1cj-magnum-container-7a7a412a magnum-conductor[262800]: 2020-12-29 21:51:22.024 262800 DEBUG oslo_service.periodic_task [-] Running periodic task MagnumPeriodicTasks.sync Dec 29 21:51:16 ctrl1cj-magnum-container-7a7a412a magnum-conductor[262804]: 2020-12-29 21:51:16.462 262804 DEBUG magnum.conductor.handlers.cluster_conductor [req-284ac12b-d76a-4e50-8e74-5bfb Dec 29 21:51:15 ctrl1cj-magnum-container-7a7a412a magnum-conductor[262800]: 2020-12-29 21:51:15.573 262800 DEBUG magnum.service.periodic [-] Status for cluster 118 updated to HEALTHY ({'api' Dec 29 21:51:15 ctrl1cj-magnum-container-7a7a412a magnum-conductor[262805]: 2020-12-29 21:51:15.572 262805 DEBUG magnum.conductor.handlers.cluster_conductor [req-3fc29ee9-4051-42e7-ae19-3a49 Dec 29 21:51:15 ctrl1cj-magnum-container-7a7a412a magnum-conductor[262800]: 2020-12-29 21:51:15.572 262800 DEBUG magnum.service.periodic [-] Status for cluster 121 updated to HEALTHY ({'api' Dec 29 21:51:15 ctrl1cj-magnum-container-7a7a412a magnum-conductor[262800]: 2020-12-29 21:51:15.572 262800 DEBUG magnum.service.periodic [-] Status for cluster 122 updated to HEALTHY ({'api' Dec 29 21:51:15 ctrl1cj-magnum-container-7a7a412a magnum-conductor[262800]: 2020-12-29 21:51:15.553 262800 DEBUG magnum.service.periodic [-] Updating health status for cluster 122 update_hea Dec 29 21:51:15 ctrl1cj-magnum-container-7a7a412a magnum-conductor[262800]: 2020-12-29 21:51:15.544 262800 DEBUG magnum.service.periodic [-] Updating health status for cluster 121 update_hea Dec 29 21:51:15 ctrl1cj-magnum-container-7a7a412a magnum-conductor[262800]: 2020-12-29 21:51:15.535 262800 DEBUG magnum.service.periodic [-] Updating health status for cluster 118 update_hea Dec 29 21:51:15 ctrl1cj-magnum-container-7a7a412a magnum-conductor[262800]: 2020-12-29 21:51:15.494 262800 DEBUG magnum.service.periodic [req-405b1fed-0b8a-4a60-b6ae-834f548b21d1 - - - 2020-12-29 21:51:14.082 [info] <0.953.1293> accepting AMQP connection <0.953.1293> (172.29.93.14:48474 -> 172.29.95.38:5672) 2020-12-29 21:51:14.083 [info] <0.953.1293> Connection <0.953.1293> (172.29.93.14:48474 -> 172.29.95.38:5672) has a client-provided name: uwsgi:262739:f86c0570-8739-4b74-8102-76b5357acd71 2020-12-29 21:51:14.084 [info] <0.953.1293> connection <0.953.1293> (172.29.93.14:48474 -> 172.29.95.38:5672 - uwsgi:262739:f86c0570-8739-4b74-8102-76b5357acd71): user 'magnum' authenticated and granted access to vhost '/magnum' 2020-12-29 21:51:15.560 [info] <0.1656.1283> accepting AMQP connection <0.1656.1283> (172.29.93.14:48548 -> 172.29.95.38:5672) 2020-12-29 21:51:15.561 [info] <0.1656.1283> Connection <0.1656.1283> (172.29.93.14:48548 -> 172.29.95.38:5672) has a client-provided name: uwsgi:262744:2c9792ab-9198-493a-970c-f6ccfd9947d3 2020-12-29 21:51:15.561 [info] <0.1656.1283> connection <0.1656.1283> (172.29.93.14:48548 -> 172.29.95.38:5672 - uwsgi:262744:2c9792ab-9198-493a-970c-f6ccfd9947d3): user 'magnum' authenticated and granted access to vhost '/magnum' On Tue, Dec 22, 2020 at 4:12 AM feilong > wrote: Hi Ionut, I didn't see this before on our production. Magnum auto healer just simply sends a POST request to Magnum api to update the health status. So I would suggest write a small script or even use curl to see if you can reproduce this firstly. On 19/12/20 2:27 am, Ionut Biru wrote: Hi again, I failed to mention that is stable/victoria with couples of patches from review. Ignore the fact that in logs it shows the 19.1.4 version in venv path. On Fri, Dec 18, 2020 at 3:22 PM Ionut Biru > wrote: Hi guys, I have an issue with magnum api returning an error after a while: Server-side error: "[('system library', 'fopen', 'Too many open files'), ('BIO routines', 'BIO_new_file', 'system lib'), ('x509 certificate routines', 'X509_load_cert_crl_file', 'system lib')]" Log file: https://paste.xinu.at/6djE/ This started to appear after I enabled the template auto_healing_controller = magnum-auto-healer, magnum_auto_healer_tag = v1.19.0. Currently, I only have 4 clusters. After that the API is in error state and doesn't work unless I restart it. -- Ionut Biru - https://fleio.com -- Ionut Biru - https://fleio.com -- Cheers & Best regards, Feilong Wang (王飞龙) ------------------------------------------------------ Senior Cloud Software Engineer Tel: +64-48032246 Email: flwang at catalyst.net.nz Catalyst IT Limited Level 6, Catalyst House, 150 Willis Street, Wellington ------------------------------------------------------ -- Ionut Biru - https://fleio.com -- Ionut Biru - https://fleio.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From eandersson at blizzard.com Sun Jan 3 01:06:07 2021 From: eandersson at blizzard.com (Erik Olof Gunnar Andersson) Date: Sun, 3 Jan 2021 01:06:07 +0000 Subject: [magnum][api] Error system library fopen too many open files with magnum-auto-healer In-Reply-To: References: <185a9715-4667-9610-0048-5434e6e2cd4e@catalyst.net.nz> , , Message-ID: Maybe something similar to this? https://github.com/kubernetes-client/python/issues/1158 What does lsof say? ________________________________ From: Erik Olof Gunnar Andersson Sent: Saturday, January 2, 2021 4:54 PM To: Ionut Biru ; feilong Cc: openstack-discuss Subject: Re: [magnum][api] Error system library fopen too many open files with magnum-auto-healer Are you sure you aren't just looking at the connection pool expanding? Each worker has a max number of connections it can use. Maybe look at lowering rpc_conn_pool_size. By default I believe each worker might create a pool of up to 30 connections. Looking at the code it could also be have something to do with the k8s client. Since it creates a new instance each time it does an health check. What version of the k8s client do you have installed? ________________________________ From: Ionut Biru Sent: Tuesday, December 29, 2020 2:20 PM To: feilong Cc: openstack-discuss Subject: Re: [magnum][api] Error system library fopen too many open files with magnum-auto-healer Hi, Not sure if my suspicion is true but I think for each update a new notifier is prepared and used without closing the connection but my understanding of oslo is nonexistent. https://opendev.org/openstack/magnum/src/branch/master/magnum/conductor/utils.py#L147 https://opendev.org/openstack/magnum/src/branch/master/magnum/common/rpc.py#L173 On Tue, Dec 29, 2020 at 11:52 PM Ionut Biru > wrote: Hi Feilong, I found out that each time the update_health_status periodic task is run, a new connection(for each uwsgi) is made to rabbitmq. root at ctrl1cj-magnum-container-7a7a412a:~# netstat -npt | grep 5672 | wc -l 229 root at ctrl1cj-magnum-container-7a7a412a:~# netstat -npt | grep 5672 | wc -l 234 root at ctrl1cj-magnum-container-7a7a412a:~# netstat -npt | grep 5672 | wc -l 238 root at ctrl1cj-magnum-container-7a7a412a:~# netstat -npt | grep 5672 | wc -l 241 root at ctrl1cj-magnum-container-7a7a412a:~# netstat -npt | grep 5672 | wc -l 244 Not sure Dec 29 21:51:22 ctrl1cj-magnum-container-7a7a412a magnum-conductor[262800]: 2020-12-29 21:51:22.024 262800 DEBUG magnum.service.periodic [req-3b495326-cf80-481e-b3c6-c741f05b7f0e - - - - -] Dec 29 21:51:22 ctrl1cj-magnum-container-7a7a412a magnum-conductor[262800]: 2020-12-29 21:51:22.024 262800 DEBUG oslo_service.periodic_task [-] Running periodic task MagnumPeriodicTasks.sync Dec 29 21:51:16 ctrl1cj-magnum-container-7a7a412a magnum-conductor[262804]: 2020-12-29 21:51:16.462 262804 DEBUG magnum.conductor.handlers.cluster_conductor [req-284ac12b-d76a-4e50-8e74-5bfb Dec 29 21:51:15 ctrl1cj-magnum-container-7a7a412a magnum-conductor[262800]: 2020-12-29 21:51:15.573 262800 DEBUG magnum.service.periodic [-] Status for cluster 118 updated to HEALTHY ({'api' Dec 29 21:51:15 ctrl1cj-magnum-container-7a7a412a magnum-conductor[262805]: 2020-12-29 21:51:15.572 262805 DEBUG magnum.conductor.handlers.cluster_conductor [req-3fc29ee9-4051-42e7-ae19-3a49 Dec 29 21:51:15 ctrl1cj-magnum-container-7a7a412a magnum-conductor[262800]: 2020-12-29 21:51:15.572 262800 DEBUG magnum.service.periodic [-] Status for cluster 121 updated to HEALTHY ({'api' Dec 29 21:51:15 ctrl1cj-magnum-container-7a7a412a magnum-conductor[262800]: 2020-12-29 21:51:15.572 262800 DEBUG magnum.service.periodic [-] Status for cluster 122 updated to HEALTHY ({'api' Dec 29 21:51:15 ctrl1cj-magnum-container-7a7a412a magnum-conductor[262800]: 2020-12-29 21:51:15.553 262800 DEBUG magnum.service.periodic [-] Updating health status for cluster 122 update_hea Dec 29 21:51:15 ctrl1cj-magnum-container-7a7a412a magnum-conductor[262800]: 2020-12-29 21:51:15.544 262800 DEBUG magnum.service.periodic [-] Updating health status for cluster 121 update_hea Dec 29 21:51:15 ctrl1cj-magnum-container-7a7a412a magnum-conductor[262800]: 2020-12-29 21:51:15.535 262800 DEBUG magnum.service.periodic [-] Updating health status for cluster 118 update_hea Dec 29 21:51:15 ctrl1cj-magnum-container-7a7a412a magnum-conductor[262800]: 2020-12-29 21:51:15.494 262800 DEBUG magnum.service.periodic [req-405b1fed-0b8a-4a60-b6ae-834f548b21d1 - - - 2020-12-29 21:51:14.082 [info] <0.953.1293> accepting AMQP connection <0.953.1293> (172.29.93.14:48474 -> 172.29.95.38:5672) 2020-12-29 21:51:14.083 [info] <0.953.1293> Connection <0.953.1293> (172.29.93.14:48474 -> 172.29.95.38:5672) has a client-provided name: uwsgi:262739:f86c0570-8739-4b74-8102-76b5357acd71 2020-12-29 21:51:14.084 [info] <0.953.1293> connection <0.953.1293> (172.29.93.14:48474 -> 172.29.95.38:5672 - uwsgi:262739:f86c0570-8739-4b74-8102-76b5357acd71): user 'magnum' authenticated and granted access to vhost '/magnum' 2020-12-29 21:51:15.560 [info] <0.1656.1283> accepting AMQP connection <0.1656.1283> (172.29.93.14:48548 -> 172.29.95.38:5672) 2020-12-29 21:51:15.561 [info] <0.1656.1283> Connection <0.1656.1283> (172.29.93.14:48548 -> 172.29.95.38:5672) has a client-provided name: uwsgi:262744:2c9792ab-9198-493a-970c-f6ccfd9947d3 2020-12-29 21:51:15.561 [info] <0.1656.1283> connection <0.1656.1283> (172.29.93.14:48548 -> 172.29.95.38:5672 - uwsgi:262744:2c9792ab-9198-493a-970c-f6ccfd9947d3): user 'magnum' authenticated and granted access to vhost '/magnum' On Tue, Dec 22, 2020 at 4:12 AM feilong > wrote: Hi Ionut, I didn't see this before on our production. Magnum auto healer just simply sends a POST request to Magnum api to update the health status. So I would suggest write a small script or even use curl to see if you can reproduce this firstly. On 19/12/20 2:27 am, Ionut Biru wrote: Hi again, I failed to mention that is stable/victoria with couples of patches from review. Ignore the fact that in logs it shows the 19.1.4 version in venv path. On Fri, Dec 18, 2020 at 3:22 PM Ionut Biru > wrote: Hi guys, I have an issue with magnum api returning an error after a while: Server-side error: "[('system library', 'fopen', 'Too many open files'), ('BIO routines', 'BIO_new_file', 'system lib'), ('x509 certificate routines', 'X509_load_cert_crl_file', 'system lib')]" Log file: https://paste.xinu.at/6djE/ This started to appear after I enabled the template auto_healing_controller = magnum-auto-healer, magnum_auto_healer_tag = v1.19.0. Currently, I only have 4 clusters. After that the API is in error state and doesn't work unless I restart it. -- Ionut Biru - https://fleio.com -- Ionut Biru - https://fleio.com -- Cheers & Best regards, Feilong Wang (王飞龙) ------------------------------------------------------ Senior Cloud Software Engineer Tel: +64-48032246 Email: flwang at catalyst.net.nz Catalyst IT Limited Level 6, Catalyst House, 150 Willis Street, Wellington ------------------------------------------------------ -- Ionut Biru - https://fleio.com -- Ionut Biru - https://fleio.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From skaplons at redhat.com Mon Jan 4 08:17:13 2021 From: skaplons at redhat.com (Slawek Kaplonski) Date: Mon, 4 Jan 2021 09:17:13 +0100 Subject: [neutron] Team meeting - Tuesday 05.01.2021 Message-ID: <20210104081713.o6lgldb577f6nsnx@p1.localdomain> Hi, I just found out that I have some internal training tomorrow and will not be able to chair our tomorrow's team meeting. As this is just second day after holidays season for many of us, lets cancel this one more meeting. See You all on the meeting next week. Happy New Year to all of You :) -- Slawek Kaplonski Principal Software Engineer Red Hat -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: not available URL: From skaplons at redhat.com Mon Jan 4 08:18:31 2021 From: skaplons at redhat.com (Slawek Kaplonski) Date: Mon, 4 Jan 2021 09:18:31 +0100 Subject: [neutron] CI meeting - Tuesday 05.01.2021 Message-ID: <20210104081831.5raqgjrvddjtleaf@p1.localdomain> Hi, I just found out that I have some internal training tomorrow and will not be able to chair our tomorrow's CI meeting. As this is just second day after holidays season for many of us, lets cancel this one more meeting. If there is anything urgent related to the CI, please ping me on IRC or send me an email about it. See You all on the meeting next week. -- Slawek Kaplonski Principal Software Engineer Red Hat -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: not available URL: From katonalala at gmail.com Mon Jan 4 08:44:44 2021 From: katonalala at gmail.com (Lajos Katona) Date: Mon, 4 Jan 2021 09:44:44 +0100 Subject: [neutron] Bug deputy report December 28th to January 3rd Message-ID: Hi, I was Neutron bug deputy for this week, and it was a really quiet week. Opinion: - https://bugs.launchpad.net/neutron/+bug/1909160 : high cpu usage when listing security groups - The issues is reported from Rocky - On openstack-discuss was some mail about slow security-group API on Stein for example: http://lists.openstack.org/pipermail/openstack-discuss/2020-December/019573.html - I checked some rally execution from latest master runs and haven't seen such Happy New Year! Lajos Katona (lajoskatona) -------------- next part -------------- An HTML attachment was scrubbed... URL: From deepa.kr at fingent.com Mon Jan 4 09:23:59 2021 From: deepa.kr at fingent.com (Deepa KR) Date: Mon, 4 Jan 2021 14:53:59 +0530 Subject: [Ussuri] Auto shutdown VM In-Reply-To: References: <158621605687826@mail.yandex.com> <14800219-BC67-4B94-88CE-81FE5D8A6AB2@fingent.com> Message-ID: Hi All Any suggestions highly appreciated. We are facing these issues very frequently now . On Mon, Nov 23, 2020 at 10:03 AM Deepa KR wrote: > Hi > > Can see only shutting down, reason=crashed in libvirt/qemu logs .Nothing > else . > Couldn't find anything else in neutron logs as well > > > On Wed, Nov 18, 2020 at 5:23 PM Deepa KR wrote: > >> Thanks for pointing out. Have 70 + vms and has issue with just 3 vms so i >> am really confused >> >> Sent from my iPhone >> >> On 18-Nov-2020, at 1:56 PM, rui zang wrote: >> >>  >> [instance: 28cd861c-ef15-444a-a902-9cac643c72b5] *Received unexpected >> event network-vif-unplugged-e97839a1-bbc4-4d26-af30-768ca3630ce9 for >> instance with vm_state active and task_state None.* >> >> >> Clearly the network virtual interface was somehow removed or unplugged. >> What you should look into is OVS or whatever the network solution you are >> using. >> >> >> 18.11.2020, 01:44, "Deepa KR" : >> >>  Hi All >> >> We have a Openstack setup with the *Ussuri Version* and I am *regularly >> facing auto shutdown of a few VMs (ubuntu16.04) randomly* . >> If I restart then the instance is back . >> >> From logs I was able to see the messages below . >> >> WARNING nova.compute.manager [req-2a21d455-ac04-44aa-b248-4776e5109013 >> 813f3fb52c434e38991bb90aa4771541 10b5279cb6f64ca19871f132a2cee1a3 - default >> default] [instance: 28cd861c-ef15-444a-a902-9cac643c72b5] *Received >> unexpected event network-vif-unplugged-e97839a1-bbc4-4d26-af30-768ca3630ce9 >> for instance with vm_state active and task_state None.* >> INFO nova.compute.manager [-] [instance: >> 28cd861c-ef15-444a-a902-9cac643c72b5] VM Stopped (Lifecycle Event) >> INFO nova.compute.manager [req-8261f607-4f1e-459d-85d4-e269694dd477 - - >> - - -] [instance: 28cd861c-ef15-444a-a902-9cac643c72b5] *During >> _sync_instance_power_state the DB power_state (1) does not match the >> vm_power_state from the hypervisor (4). Updating power_state in the DB to >> match the hypervisor.* >> syslog:Nov 13 07:01:07 fgshwbucehyp04 nova-compute[2680204]: 2020-11-13 >> 07:01:07.684 2680204 WARNING nova.compute.manager >> [req-8261f607-4f1e-459d-85d4-e269694dd477 - - - - -] [instance: >> 28cd861c-ef15-444a-a902-9cac643c72b5] *Instance shutdown by itself. >> Calling the stop API. Current vm_state: active, current task_state: None, >> original DB power_state: 1, current VM power_state: 4* >> nova.compute.manager [req-8261f607-4f1e-459d-85d4-e269694dd477 - - - - >> -] [instance: 28cd861c-ef15-444a-a902-9cac643c72b5] *Instance is already >> powered off in the hypervisor when stop is called.* >> nova.virt.libvirt.driver [req-8261f607-4f1e-459d-85d4-e269694dd477 - - - >> - -] [instance: 28cd861c-ef15-444a-a902-9cac643c72b5] *Instance already >> shutdown.* >> nova.virt.libvirt.driver [-] [instance: >> 28cd861c-ef15-444a-a902-9cac643c72b5] *Instance destroyed successfully.* >> nova.compute.manager [req-7a0a0d03-e286-42f0-9e36-38a432f236f3 >> d9ca03b9d0884d51a26a39b6c82f02eb 304d859c43df4de4944ca5623f7f455c - default >> default] [instance: 28cd861c-ef15-444a-a902-9cac643c72b5] Get console output >> nova.virt.libvirt.driver [-] [instance: >> 28cd861c-ef15-444a-a902-9cac643c72b5] *Instance destroyed successfully.* >> >> I searched a few blogs and forums but couldn't find a solution to it . >> >> Few mentioned to add s*ync_power_state_interval=-1 in * >> */etc/nova/nova.conf *.But understood that this will help only when nova >> stops vm. >> But in this case vm itself is shutting down (*Instance shutdown by >> itself. Calling the stop API*) >> Also no memory issue in VM nor the hypervisor. >> Also did apt-get upgrade . >> >> It would be great if anyone can shed light to this issue. >> >> Regards, >> Deepa K R >> >> Sent from my iPhone >> >> > > -- > > > Regards, > > Deepa K R | DevOps Team Lead > > > > USA | UAE | INDIA | AUSTRALIA > > > -- Regards, Deepa K R | DevOps Team Lead USA | UAE | INDIA | AUSTRALIA -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature-1.gif Type: image/gif Size: 566 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: logo_for_signature.png Type: image/png Size: 10509 bytes Desc: not available URL: From lyarwood at redhat.com Mon Jan 4 09:44:48 2021 From: lyarwood at redhat.com (Lee Yarwood) Date: Mon, 4 Jan 2021 09:44:48 +0000 Subject: [Ussuri] Auto shutdown VM In-Reply-To: References: <158621605687826@mail.yandex.com> <14800219-BC67-4B94-88CE-81FE5D8A6AB2@fingent.com> Message-ID: <20210104094448.7ukywqmrnasyufqm@lyarwood-laptop.usersys.redhat.com> On 04-01-21 14:53:59, Deepa KR wrote: > Hi All > > Any suggestions highly appreciated. > We are facing these issues very frequently now . Can you pastebin the domain QEMU log from /var/log/libvirt/qemu/$domain.log? That should detail why the domain is crashing. I'd also recommend reviewing the following docs from libvirt on how to enable debug logs etc: https://libvirt.org/kbase/debuglogs.html > On Mon, Nov 23, 2020 at 10:03 AM Deepa KR wrote: > > Hi > > > > Can see only shutting down, reason=crashed in libvirt/qemu logs .Nothing > > else . > > Couldn't find anything else in neutron logs as well > > > > > > On Wed, Nov 18, 2020 at 5:23 PM Deepa KR wrote: > > > >> Thanks for pointing out. Have 70 + vms and has issue with just 3 vms so i > >> am really confused > >> > >> Sent from my iPhone > >> > >> On 18-Nov-2020, at 1:56 PM, rui zang wrote: > >> > >>  > >> [instance: 28cd861c-ef15-444a-a902-9cac643c72b5] *Received unexpected > >> event network-vif-unplugged-e97839a1-bbc4-4d26-af30-768ca3630ce9 for > >> instance with vm_state active and task_state None.* > >> > >> > >> Clearly the network virtual interface was somehow removed or unplugged. > >> What you should look into is OVS or whatever the network solution you are > >> using. > >> > >> > >> 18.11.2020, 01:44, "Deepa KR" : > >> > >>  Hi All > >> > >> We have a Openstack setup with the *Ussuri Version* and I am *regularly > >> facing auto shutdown of a few VMs (ubuntu16.04) randomly* . > >> If I restart then the instance is back . > >> > >> From logs I was able to see the messages below . > >> > >> WARNING nova.compute.manager [req-2a21d455-ac04-44aa-b248-4776e5109013 > >> 813f3fb52c434e38991bb90aa4771541 10b5279cb6f64ca19871f132a2cee1a3 - default > >> default] [instance: 28cd861c-ef15-444a-a902-9cac643c72b5] *Received > >> unexpected event network-vif-unplugged-e97839a1-bbc4-4d26-af30-768ca3630ce9 > >> for instance with vm_state active and task_state None.* > >> INFO nova.compute.manager [-] [instance: > >> 28cd861c-ef15-444a-a902-9cac643c72b5] VM Stopped (Lifecycle Event) > >> INFO nova.compute.manager [req-8261f607-4f1e-459d-85d4-e269694dd477 - - > >> - - -] [instance: 28cd861c-ef15-444a-a902-9cac643c72b5] *During > >> _sync_instance_power_state the DB power_state (1) does not match the > >> vm_power_state from the hypervisor (4). Updating power_state in the DB to > >> match the hypervisor.* > >> syslog:Nov 13 07:01:07 fgshwbucehyp04 nova-compute[2680204]: 2020-11-13 > >> 07:01:07.684 2680204 WARNING nova.compute.manager > >> [req-8261f607-4f1e-459d-85d4-e269694dd477 - - - - -] [instance: > >> 28cd861c-ef15-444a-a902-9cac643c72b5] *Instance shutdown by itself. > >> Calling the stop API. Current vm_state: active, current task_state: None, > >> original DB power_state: 1, current VM power_state: 4* > >> nova.compute.manager [req-8261f607-4f1e-459d-85d4-e269694dd477 - - - - > >> -] [instance: 28cd861c-ef15-444a-a902-9cac643c72b5] *Instance is already > >> powered off in the hypervisor when stop is called.* > >> nova.virt.libvirt.driver [req-8261f607-4f1e-459d-85d4-e269694dd477 - - - > >> - -] [instance: 28cd861c-ef15-444a-a902-9cac643c72b5] *Instance already > >> shutdown.* > >> nova.virt.libvirt.driver [-] [instance: > >> 28cd861c-ef15-444a-a902-9cac643c72b5] *Instance destroyed successfully.* > >> nova.compute.manager [req-7a0a0d03-e286-42f0-9e36-38a432f236f3 > >> d9ca03b9d0884d51a26a39b6c82f02eb 304d859c43df4de4944ca5623f7f455c - default > >> default] [instance: 28cd861c-ef15-444a-a902-9cac643c72b5] Get console output > >> nova.virt.libvirt.driver [-] [instance: > >> 28cd861c-ef15-444a-a902-9cac643c72b5] *Instance destroyed successfully.* > >> > >> I searched a few blogs and forums but couldn't find a solution to it . > >> > >> Few mentioned to add s*ync_power_state_interval=-1 in * > >> */etc/nova/nova.conf *.But understood that this will help only when nova > >> stops vm. > >> But in this case vm itself is shutting down (*Instance shutdown by > >> itself. Calling the stop API*) > >> Also no memory issue in VM nor the hypervisor. > >> Also did apt-get upgrade . > >> > >> It would be great if anyone can shed light to this issue. > >> > >> Regards, > >> Deepa K R > >> > >> Sent from my iPhone > >> > >> > > > > -- > > > > > > Regards, > > > > Deepa K R | DevOps Team Lead > > > > > > > > USA | UAE | INDIA | AUSTRALIA > > > > > > > > -- > > > Regards, > > Deepa K R | DevOps Team Lead > > > > USA | UAE | INDIA | AUSTRALIA -- Lee Yarwood A5D1 9385 88CB 7E5F BE64 6618 BCA6 6E33 F672 2D76 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: not available URL: From pierre at stackhpc.com Mon Jan 4 10:14:47 2021 From: pierre at stackhpc.com (Pierre Riteau) Date: Mon, 4 Jan 2021 11:14:47 +0100 Subject: [Ussuri] Auto shutdown VM In-Reply-To: <9A9C606C-3658-473C-83DC-6305D496A6CD@fingent.com> References: <9A9C606C-3658-473C-83DC-6305D496A6CD@fingent.com> Message-ID: Hi Deepa, You mention checking dmesg *inside* the VM. But have you checked dmesg on the hypervisor? It's possible your qemu-kvm processes are terminated by the kernel out-of-memory (OOM) killer because they try to allocate more memory than available. Best wishes, Pierre Riteau (priteau) On Wed, 18 Nov 2020 at 03:44, Deepa KR wrote: > > Hello Mohammed > > Thanks for the response. > No error message inside vm. Have checked dmesg, syslog etc . > > I mentioned vm is shutting down itself because of error messages Instance shutdown by itself. Calling the stop API. Current vm_state: active, current task_state: None, original DB power_state: 1, current VM power_state: 4 from hypervisor. > > Sent from my iPhone > > > On 17-Nov-2020, at 11:35 PM, Mohammed Naser wrote: > > > > On Tue, Nov 17, 2020 at 12:46 PM Deepa KR wrote: > >> > >>  Hi All > >> > >> We have a Openstack setup with the Ussuri Version and I am regularly facing auto shutdown of a few VMs (ubuntu16.04) randomly . > >> If I restart then the instance is back . > >> > >> From logs I was able to see the messages below . > >> > >> WARNING nova.compute.manager [req-2a21d455-ac04-44aa-b248-4776e5109013 813f3fb52c434e38991bb90aa4771541 10b5279cb6f64ca19871f132a2cee1a3 - default default] [instance: 28cd861c-ef15-444a-a902-9cac643c72b5] Received unexpected event network-vif-unplugged-e97839a1-bbc4-4d26-af30-768ca3630ce9 for instance with vm_state active and task_state None. > >> INFO nova.compute.manager [-] [instance: 28cd861c-ef15-444a-a902-9cac643c72b5] VM Stopped (Lifecycle Event) > >> INFO nova.compute.manager [req-8261f607-4f1e-459d-85d4-e269694dd477 - - - - -] [instance: 28cd861c-ef15-444a-a902-9cac643c72b5] During _sync_instance_power_state the DB power_state (1) does not match the vm_power_state from the hypervisor (4). Updating power_state in the DB to match the hypervisor. > >> syslog:Nov 13 07:01:07 fgshwbucehyp04 nova-compute[2680204]: 2020-11-13 07:01:07.684 2680204 WARNING nova.compute.manager [req-8261f607-4f1e-459d-85d4-e269694dd477 - - - - -] [instance: 28cd861c-ef15-444a-a902-9cac643c72b5] Instance shutdown by itself. Calling the stop API. Current vm_state: active, current task_state: None, original DB power_state: 1, current VM power_state: 4 > >> nova.compute.manager [req-8261f607-4f1e-459d-85d4-e269694dd477 - - - - -] [instance: 28cd861c-ef15-444a-a902-9cac643c72b5] Instance is already powered off in the hypervisor when stop is called. > >> nova.virt.libvirt.driver [req-8261f607-4f1e-459d-85d4-e269694dd477 - - - - -] [instance: 28cd861c-ef15-444a-a902-9cac643c72b5] Instance already shutdown. > >> nova.virt.libvirt.driver [-] [instance: 28cd861c-ef15-444a-a902-9cac643c72b5] Instance destroyed successfully. > >> nova.compute.manager [req-7a0a0d03-e286-42f0-9e36-38a432f236f3 d9ca03b9d0884d51a26a39b6c82f02eb 304d859c43df4de4944ca5623f7f455c - default default] [instance: 28cd861c-ef15-444a-a902-9cac643c72b5] Get console output > >> nova.virt.libvirt.driver [-] [instance: 28cd861c-ef15-444a-a902-9cac643c72b5] Instance destroyed successfully. > >> > >> I searched a few blogs and forums but couldn't find a solution to it . > >> > >> Few mentioned to add sync_power_state_interval=-1 in /etc/nova/nova.conf .But understood that this will help only when nova stops vm. > >> But in this case vm itself is shutting down (Instance shutdown by itself. Calling the stop API) > >> Also no memory issue in VM nor the hypervisor. > >> Also did apt-get upgrade . > >> > >> It would be great if anyone can shed light to this issue. > > > > You should check and see if there is anything inside `dmesg` that > > shows the VM dying (any segfaults?). Also, it's possible that the VM > > itself is shutting off so maybe you should check ni its logs. > > > >> Regards, > >> Deepa K R > >> > >> Sent from my iPhone > > > > > > > > -- > > Mohammed Naser > > VEXXHOST, Inc. > From ionut at fleio.com Mon Jan 4 12:07:24 2021 From: ionut at fleio.com (Ionut Biru) Date: Mon, 4 Jan 2021 14:07:24 +0200 Subject: [magnum][api] Error system library fopen too many open files with magnum-auto-healer In-Reply-To: References: <185a9715-4667-9610-0048-5434e6e2cd4e@catalyst.net.nz> Message-ID: Hi Erik, Here is lsof of one uwsgi api. https://paste.xinu.at/5YUWf/ I have kubernetes 12.0.1 installed in env. On Sun, Jan 3, 2021 at 3:06 AM Erik Olof Gunnar Andersson < eandersson at blizzard.com> wrote: > Maybe something similar to this? > https://github.com/kubernetes-client/python/issues/1158 > > What does lsof say? > > ------------------------------ > *From:* Erik Olof Gunnar Andersson > *Sent:* Saturday, January 2, 2021 4:54 PM > *To:* Ionut Biru ; feilong > *Cc:* openstack-discuss > *Subject:* Re: [magnum][api] Error system library fopen too many open > files with magnum-auto-healer > > Are you sure you aren't just looking at the connection pool expanding? > Each worker has a max number of connections it can use. Maybe look at > lowering rpc_conn_pool_size. By default I believe each worker might > create a pool of up to 30 connections. > > Looking at the code it could also be have something to do with the k8s > client. Since it creates a new instance each time it does an health check. > What version of the k8s client do you have installed? > > > ------------------------------ > *From:* Ionut Biru > *Sent:* Tuesday, December 29, 2020 2:20 PM > *To:* feilong > *Cc:* openstack-discuss > *Subject:* Re: [magnum][api] Error system library fopen too many open > files with magnum-auto-healer > > Hi, > > Not sure if my suspicion is true but I think for each update a new > notifier is prepared and used without closing the connection but my > understanding of oslo is nonexistent. > > > https://opendev.org/openstack/magnum/src/branch/master/magnum/conductor/utils.py#L147 > > > https://opendev.org/openstack/magnum/src/branch/master/magnum/common/rpc.py#L173 > > > On Tue, Dec 29, 2020 at 11:52 PM Ionut Biru wrote: > > Hi Feilong, > > I found out that each time the update_health_status periodic task is run, > a new connection(for each uwsgi) is made to rabbitmq. > > root at ctrl1cj-magnum-container-7a7a412a:~# netstat -npt | grep 5672 | wc -l > 229 > root at ctrl1cj-magnum-container-7a7a412a:~# netstat -npt | grep 5672 | wc -l > 234 > root at ctrl1cj-magnum-container-7a7a412a:~# netstat -npt | grep 5672 | wc -l > 238 > root at ctrl1cj-magnum-container-7a7a412a:~# netstat -npt | grep 5672 | wc -l > 241 > root at ctrl1cj-magnum-container-7a7a412a:~# netstat -npt | grep 5672 | wc -l > 244 > > Not sure > > Dec 29 21:51:22 ctrl1cj-magnum-container-7a7a412a > magnum-conductor[262800]: 2020-12-29 21:51:22.024 262800 DEBUG > magnum.service.periodic [req-3b495326-cf80-481e-b3c6-c741f05b7f0e - - - - > -] > Dec 29 21:51:22 ctrl1cj-magnum-container-7a7a412a > magnum-conductor[262800]: 2020-12-29 21:51:22.024 262800 DEBUG > oslo_service.periodic_task [-] Running periodic task > MagnumPeriodicTasks.sync > Dec 29 21:51:16 ctrl1cj-magnum-container-7a7a412a > magnum-conductor[262804]: 2020-12-29 21:51:16.462 262804 DEBUG > magnum.conductor.handlers.cluster_conductor > [req-284ac12b-d76a-4e50-8e74-5bfb > Dec 29 21:51:15 ctrl1cj-magnum-container-7a7a412a > magnum-conductor[262800]: 2020-12-29 21:51:15.573 262800 DEBUG > magnum.service.periodic [-] Status for cluster 118 updated to HEALTHY > ({'api' > Dec 29 21:51:15 ctrl1cj-magnum-container-7a7a412a > magnum-conductor[262805]: 2020-12-29 21:51:15.572 262805 DEBUG > magnum.conductor.handlers.cluster_conductor > [req-3fc29ee9-4051-42e7-ae19-3a49 > Dec 29 21:51:15 ctrl1cj-magnum-container-7a7a412a > magnum-conductor[262800]: 2020-12-29 21:51:15.572 262800 DEBUG > magnum.service.periodic [-] Status for cluster 121 updated to HEALTHY > ({'api' > Dec 29 21:51:15 ctrl1cj-magnum-container-7a7a412a > magnum-conductor[262800]: 2020-12-29 21:51:15.572 262800 DEBUG > magnum.service.periodic [-] Status for cluster 122 updated to HEALTHY > ({'api' > Dec 29 21:51:15 ctrl1cj-magnum-container-7a7a412a > magnum-conductor[262800]: 2020-12-29 21:51:15.553 262800 DEBUG > magnum.service.periodic [-] Updating health status for cluster 122 > update_hea > Dec 29 21:51:15 ctrl1cj-magnum-container-7a7a412a > magnum-conductor[262800]: 2020-12-29 21:51:15.544 262800 DEBUG > magnum.service.periodic [-] Updating health status for cluster 121 > update_hea > Dec 29 21:51:15 ctrl1cj-magnum-container-7a7a412a > magnum-conductor[262800]: 2020-12-29 21:51:15.535 262800 DEBUG > magnum.service.periodic [-] Updating health status for cluster 118 > update_hea > Dec 29 21:51:15 ctrl1cj-magnum-container-7a7a412a > magnum-conductor[262800]: 2020-12-29 21:51:15.494 262800 DEBUG > magnum.service.periodic [req-405b1fed-0b8a-4a60-b6ae-834f548b21d1 - - - > > > 2020-12-29 21:51:14.082 [info] <0.953.1293> accepting AMQP connection > <0.953.1293> (172.29.93.14:48474 > > -> 172.29.95.38:5672 > > ) > 2020-12-29 21:51:14.083 [info] <0.953.1293> Connection <0.953.1293> ( > 172.29.93.14:48474 > > -> 172.29.95.38:5672 > ) > has a client-provided name: > uwsgi:262739:f86c0570-8739-4b74-8102-76b5357acd71 > 2020-12-29 21:51:14.084 [info] <0.953.1293> connection <0.953.1293> ( > 172.29.93.14:48474 > > -> 172.29.95.38:5672 > > - uwsgi:262739:f86c0570-8739-4b74-8102-76b5357acd71): user 'magnum' > authenticated and granted access to vhost '/magnum' > 2020-12-29 21:51:15.560 [info] <0.1656.1283> accepting AMQP connection > <0.1656.1283> (172.29.93.14:48548 > > -> 172.29.95.38:5672 > > ) > 2020-12-29 21:51:15.561 [info] <0.1656.1283> Connection <0.1656.1283> ( > 172.29.93.14:48548 > > -> 172.29.95.38:5672 > ) > has a client-provided name: > uwsgi:262744:2c9792ab-9198-493a-970c-f6ccfd9947d3 > 2020-12-29 21:51:15.561 [info] <0.1656.1283> connection <0.1656.1283> ( > 172.29.93.14:48548 > > -> 172.29.95.38:5672 > > - uwsgi:262744:2c9792ab-9198-493a-970c-f6ccfd9947d3): user 'magnum' > authenticated and granted access to vhost '/magnum' > > On Tue, Dec 22, 2020 at 4:12 AM feilong wrote: > > Hi Ionut, > > I didn't see this before on our production. Magnum auto healer just simply > sends a POST request to Magnum api to update the health status. So I would > suggest write a small script or even use curl to see if you can reproduce > this firstly. > > > On 19/12/20 2:27 am, Ionut Biru wrote: > > Hi again, > > I failed to mention that is stable/victoria with couples of patches from > review. Ignore the fact that in logs it shows the 19.1.4 version in venv > path. > > On Fri, Dec 18, 2020 at 3:22 PM Ionut Biru wrote: > > Hi guys, > > I have an issue with magnum api returning an error after a while: > Server-side error: "[('system library', 'fopen', 'Too many open files'), > ('BIO routines', 'BIO_new_file', 'system lib'), ('x509 certificate > routines', 'X509_load_cert_crl_file', 'system lib')]" > > Log file: https://paste.xinu.at/6djE/ > > > This started to appear after I enabled the > template auto_healing_controller = magnum-auto-healer, > magnum_auto_healer_tag = v1.19.0. > > Currently, I only have 4 clusters. > > After that the API is in error state and doesn't work unless I restart it. > > > -- > Ionut Biru - https://fleio.com > > > > > -- > Ionut Biru - https://fleio.com > > > -- > Cheers & Best regards, > Feilong Wang (王飞龙) > ------------------------------------------------------ > Senior Cloud Software Engineer > Tel: +64-48032246 > Email: flwang at catalyst.net.nz > Catalyst IT Limited > Level 6, Catalyst House, 150 Willis Street, Wellington > ------------------------------------------------------ > > > > -- > Ionut Biru - https://fleio.com > > > > > -- > Ionut Biru - https://fleio.com > > -- Ionut Biru - https://fleio.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From ikatzir at infinidat.com Mon Jan 4 13:31:12 2021 From: ikatzir at infinidat.com (Igal Katzir) Date: Mon, 4 Jan 2021 15:31:12 +0200 Subject: [tripleO] Customised Cinder-Volume fails at 'Paunch 5' during overcloud deployment In-Reply-To: References: <2D1F2693-49C0-4CA2-8F8E-F9E837D6A232@infinidat.com> Message-ID: Hello Alan, Thanks for your reply! I am afraid that the reason for my deployment failure might be concerned with the environment file I use to configure my cinder backend. The configuration is quite similar to https://github.com/Infinidat/tripleo-deployment-configs/blob/dev/RHOSP15/cinder-infinidat-config.yaml So I wonder if it is possible to run a deployment where I tell 'TripleO' to use my customize container, using containers-prepare-parameter.yaml, but without the environment file =cinder-infinidat-config.yaml, and configure the backend / start cinder-volume services manually? Or I must have a minimum config as I find in: '/usr/share/openstack-tripleo-heat-templates/deployment/cinder/' (for other vendors)? If I do need such a cinder-volume-VENDOR-puppet.yaml config to be integrated during overcloud deployment, where is documentation that explains how to construct this? Do I need to use cinder-base.yaml as a template? When looking at the web for "cinder-volume-container-puppet.yaml" I found the Git Page of overcloud-resource-registry-puppet.j2.yaml and found also https://opendev.org/openstack/tripleo-heat-templates/../deployment but it is not so explanatory. I have opened a case with RedHat as well and they are checking who from their R&D could help since it's out of the scope of support. Regards, Igal On Thu, Dec 31, 2020 at 9:15 PM Alan Bishop wrote: > > > On Thu, Dec 31, 2020 at 5:26 AM Igal Katzir wrote: > >> Hello all, >> >> I am trying to deploy RHOSP16.1 (based on ‘*train’ *distribution) for Certification >> purposes. >> I have build a container for our cinder driver and trying to deploy it. >> Deployment runs almost till the end and fails at stage when it tries to >> configure Pacemaker; >> Here is the last message: >> >> "Info: Applying configuration version '1609231063'", "Notice: /Stage[main]/Pacemaker::Corosync/File_line[pcsd_bind_addr]/ensure: created", "Info: /Stage[main]/Pacemaker::Corosync/File_line[pcsd_bind_addr]: Scheduling refresh of Service[pcsd]", "Info: /Stage[main]/Pacemaker::Service/Service[pcsd]: Unscheduling all events on Service[pcsd]", "Info: Class[Pacemaker::Corosync]: Unscheduling all events on Class[Pacemaker::Corosync]", "Notice: /Stage[main]/Tripleo::Profile::Pacemaker::Cinder::Volume_bundle/Pacemaker::Resource::Bundle[openstack-cinder-volume]/Pcmk_bundle[openstack-cinder-volume]: Dependency Pcmk_property[property-overcloud-controller-0-cinder-volume-role] has failures: true", "Info: Creating state file /var/lib/puppet/state/state.yaml", "Notice: Applied catalog in 382.92 seconds", "Changes:", " Total: 1", "Events:", " Success: 1", " Failure: 2", " Total: 3", >> >> >> I have verified that all packages on my container-image >> (Pacemaker,Corosync, libqb,and pcs) are installed with same versions as >> the overcloud-controller. >> > > Hi Igal, > > Thank you for checking these package versions and stating they match the > ones installed on the overcloud node. This rules out one of the common > reasons for failures when trying to run a customized cinder-volume > container image. > > But seems that something is still missing, because deployment with the >> default openstack-cinder-volume image completes successfully. >> > > This is also good to know. > > Can anyone help with debugging this? Let me know if more info needed. >> > > More info is needed, but it's hard to predict exactly where to look for > the root cause of the failure. I'd start by looking for something at the > cinder log file > to determine whether the cinder-volume service is even trying to start. > Look for /var/log/containers/cinder/cinder-volume.log on the node where > pacemaker is trying to run the service. Are there logs indicating the > service is trying to start? Or maybe the service is launched, but fails > early during startup? > > Another possibility is podman fails to launch the container itself. If > that's happening then check for errors in /var/log/messages. One source of > this type of failure is you've specified a container bind mount, but the > source directory doesn't exist (docker would auto-create the source > directory, but podman does not). > > You specifically mentioned RHOSP, so if you need additional support then I > recommend opening a support case with Red Hat. That will provide a forum > for posting private data, such as details of your overcloud deployment and > full sosreports. > > Alan > > >> >> Thanks in advance, >> Igal >> > -- Regards, *Igal Katzir* Cell +972-54-5597086 Interoperability Team *INFINIDAT* -------------- next part -------------- An HTML attachment was scrubbed... URL: From hrhosseini at hotmail.com Mon Jan 4 13:37:58 2021 From: hrhosseini at hotmail.com (Hamidreza Hosseini) Date: Mon, 4 Jan 2021 13:37:58 +0000 Subject: [swift] Openstack controller/keystone cause not uploading file to swift storage Message-ID: Hi, I've installed swift storage and swift-proxy and keystone for object storage I'm using memcached for caching keystone's data But suddenly in some moments my cpu of keystone servers goes up till 50% (it is apache and keystone proccess) and the swift proxies wouldn't upload anything!!! As I said servers have free cpu and ram and kernel tuned well which parameter should I check for my problem? How can I solve this strange problem? -------------- next part -------------- An HTML attachment was scrubbed... URL: From elfosardo at gmail.com Mon Jan 4 09:44:37 2021 From: elfosardo at gmail.com (Riccardo Pittau) Date: Mon, 4 Jan 2021 10:44:37 +0100 Subject: some error abount ironic-python-agent-builder In-Reply-To: References: Message-ID: Hello Ankele, The IPA_SOURCE_DIR variable is used to set the location of the ironic-python-agent source code that will be installed in the ironic-python-agent tinycore-based image (tinyipa). It defaults to /opt/stack/ironic-python-agent but you can use any other dir as far as you set the correct path in the environment variable. You need to have that populated before trying to build the image. FYI tinyipa is a test-oriented image thought specifically to be used in CI, and should not be used in production environments. If you need an image suited for production on real hardware, I suggest to build one based on diskimage-builder https://docs.openstack.org/ironic-python-agent-builder/latest/admin/dib.html Cheers, Riccardo On Mon, Dec 28, 2020 at 4:59 PM Ankele zhang wrote: > Hi~ > I have an OpenStack platform in Rocky version. > I use ironic-python-agent-builder to build a tinyipa image to customing > HardwareManager for 'RAID configuration' in Ironic cleaning steps. > While I follow the steps ' > https://docs.openstack.org/ironic-python-agent-builder/latest/admin/tinyipa.html#building-ramdisk' > to build tinyipa image, it occurs error as following: > > [image: image.png] > > [image: image.png] > > so, what the IPA_SOURCE_DIR means? Do I need to download the source code > of the ironic-python-agent and copy it to /opt/stack/ before this? > > Looking forward to your reply. > > Ankele > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 11770 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 63866 bytes Desc: not available URL: From marios at redhat.com Mon Jan 4 14:58:49 2021 From: marios at redhat.com (Marios Andreou) Date: Mon, 4 Jan 2021 16:58:49 +0200 Subject: [tripleo] next irc meeting Tuesday Jan 05 @ 1400 UTC in #tripleo Message-ID: The next TripleO irc meeting is: ** Tuesday 05th January at 1400 UTC in #tripleo. ** ** https://wiki.openstack.org/wiki/Meetings/TripleO ** ** https://etherpad.opendev.org/p/tripleo-meeting-items ** Please add any one-off items you want to hilight at https://etherpad.opendev.org/p/tripleo-meeting-items This can include review requests, blocking issues or to socialise ongoing or planned work, or anything else you want to share. Our last meeting was held on Dec 22nd - you can find the logs there http://eavesdrop.openstack.org/meetings/tripleo/2020/tripleo.2020-12-22-14.00.html Hope to see you there! -------------- next part -------------- An HTML attachment was scrubbed... URL: From hberaud at redhat.com Mon Jan 4 15:15:45 2021 From: hberaud at redhat.com (Herve Beraud) Date: Mon, 4 Jan 2021 16:15:45 +0100 Subject: [release] Status: RED - pip resolver issue with publish-openstack-releasenotes-python3 Message-ID: Dear release managers, We are currently experiencing an issue with the new pip resolver in our release job (publish-openstack-releasenotes-python3), so, please hold all the release's validations for now. Indeed, today we faced an issue [1][2] during the releasing tripleo-image-elements [3]. The problem here is that this repos haven't doc/requirements.txt file and by default in this case zuul will use the test-requirements.txt file to pull requirements [4] This requirements file contains extra requirements like flake8 that collided with those allowed in our job environment and so the new pip resolver fails to install these requirements and the job exits in error. All the repo who fit the same conditions (no doc/requirements.txt available) will fail too. We've almost identified all of these repos [5], I'll get the full list to you in a while. In parallel, fungi (Jeremy Stanley) will bring this topic on the zuul side too, to see if we can add something there to override this rule (test-requirements.txt as the default case). Thanks for reading [1] https://zuul.opendev.org/t/openstack/build/d82e8c8db7754394907459895f3f58fa [2} http://paste.openstack.org/show/801385/ [3] https://review.opendev.org/c/openstack/releases/+/768237 [4] https://opendev.org/zuul/zuul-jobs/src/branch/master/roles/ensure-sphinx/tasks/main.yaml#L36 [5] http://paste.openstack.org/show/801396/ -- Hervé Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/ https://twitter.com/4383hberaud -----BEGIN PGP SIGNATURE----- wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O v6rDpkeNksZ9fFSyoY2o =ECSj -----END PGP SIGNATURE----- -------------- next part -------------- An HTML attachment was scrubbed... URL: From hberaud at redhat.com Mon Jan 4 15:34:06 2021 From: hberaud at redhat.com (Herve Beraud) Date: Mon, 4 Jan 2021 16:34:06 +0100 Subject: [release] Status: RED - pip resolver issue with publish-openstack-releasenotes-python3 In-Reply-To: References: Message-ID: Here is the filtered list of projects that meet the conditions leading to the bug, and who should be fixed to completely solve our issue: adjutant-ui api-site blazar blazar-nova blazar-tempest-plugin ceilometermiddleware cinder-tempest-plugin cloudkitty cloudkitty-tempest-plugin contributor-guide cyborg-tempest-plugin debtcollector designate-tempest-plugin etcd3gw freezer-api freezer-dr glance-tempest-plugin governance governance-sigs governance-website i18n ideas ironic-python-agent-builder kuryr-libnetwork manila-image-elements manila-tempest-plugin molteniron monasca-api monasca-events-api monasca-log-api monasca-persister monasca-statsd monasca-tempest-plugin murano-dashboard networking-baremetal networking-hyperv neutron-dynamic-routing neutron-tempest-plugin neutron-vpnaas openstack-manuals openstack-virtual-baremetal openstack-zuul-roles os-apply-config os-collect-config os-refresh-config os-service-types osprofiler ossa pycadf pyeclib pymod2pkg python-cyborgclient python-masakariclient python-monascaclient release-test security-analysis security-doc senlin-tempest-plugin solum-dashboard sushy sushy-tools telemetry-tempest-plugin tempest-lib tempest-stress training-guides tripleo-common tripleo-common-tempest-plugin tripleo-heat-templates tripleo-image-elements tripleo-puppet-elements tripleo-quickstart-extras tripleo-repos tripleo-upgrade trove-dashboard virtualbmc vitrage-tempest-plugin whereto workload-ref-archs zaqar-tempest-plugin zun-tempest-plugin Notice that some of these projects aren't deliverables but if possible it could be worth fixing them too. These projects have an incompatibility between entries in their test-requirements.txt, and they're missing a doc/requirements.txt file. The more straightforward path to unlock our job " publish-openstack-releasenotes-python3" is to create a doc/requirements.txt file that only contains the needed dependencies to reduce the possibility of pip resolver issues. I personally think that we could use the latest allowed version of requirements (sphinx, reno, etc...). I propose to track the related advancement by using the "fix-relmgt-pip-doc" gerrit topic, when all the projects will be fixed we would be able to update our status. Also it could be worth fixing test-requirements.txt incompatibilities but this task is more on the projects teams sides and this task could be done with a follow up patch. Thoughts? Le lun. 4 janv. 2021 à 16:15, Herve Beraud a écrit : > Dear release managers, > > We are currently experiencing an issue with the new pip resolver in our > release job (publish-openstack-releasenotes-python3), so, please hold all > the release's validations for now. > > Indeed, today we faced an issue [1][2] during the releasing > tripleo-image-elements [3]. > > The problem here is that this repos haven't doc/requirements.txt file and > by default in this case zuul will use the test-requirements.txt file to > pull requirements [4] > > This requirements file contains extra requirements like flake8 that > collided with those allowed in our job environment and so the new pip > resolver fails to install these requirements and the job exits in error. > > All the repo who fit the same conditions (no doc/requirements.txt > available) will fail too. We've almost identified all of these repos [5], I'll > get the full list to you in a while. > > In parallel, fungi (Jeremy Stanley) will bring this topic on the zuul side > too, to see if we can add something there to override this rule > (test-requirements.txt as the default case). > > Thanks for reading > > [1] > https://zuul.opendev.org/t/openstack/build/d82e8c8db7754394907459895f3f58fa > [2} http://paste.openstack.org/show/801385/ > [3] https://review.opendev.org/c/openstack/releases/+/768237 > [4] > https://opendev.org/zuul/zuul-jobs/src/branch/master/roles/ensure-sphinx/tasks/main.yaml#L36 > [5] http://paste.openstack.org/show/801396/ > > > -- > Hervé Beraud > Senior Software Engineer at Red Hat > irc: hberaud > https://github.com/4383/ > https://twitter.com/4383hberaud > -----BEGIN PGP SIGNATURE----- > > wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ > Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ > RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP > F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G > 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g > glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw > m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ > hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 > qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y > F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 > B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O > v6rDpkeNksZ9fFSyoY2o > =ECSj > -----END PGP SIGNATURE----- > > -- Hervé Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/ https://twitter.com/4383hberaud -----BEGIN PGP SIGNATURE----- wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O v6rDpkeNksZ9fFSyoY2o =ECSj -----END PGP SIGNATURE----- -------------- next part -------------- An HTML attachment was scrubbed... URL: From fungi at yuggoth.org Mon Jan 4 15:54:05 2021 From: fungi at yuggoth.org (Jeremy Stanley) Date: Mon, 4 Jan 2021 15:54:05 +0000 Subject: [release] Status: RED - pip resolver issue with publish-openstack-releasenotes-python3 In-Reply-To: References: Message-ID: <20210104155404.elmbglroodeihbwv@yuggoth.org> On 2021-01-04 16:15:45 +0100 (+0100), Herve Beraud wrote: [...] > In parallel, fungi (Jeremy Stanley) will bring this topic on the zuul side > too, to see if we can add something there to override this rule > (test-requirements.txt as the default case). [...] Well, what I was originally suggesting was that we'd want some way to have it use doc/requirements.txt instead of test-requirements.txt, but on closer reading of the role it already actually does that automatically, so I'm not sure there's much else to be done on the Zuul end of things. Really as you point out this needs to be fixed in the individual projects by either correcting these incompatibilities between intentionally unconstrained linters/static analyzers in their test-requirements.txt files, or by following OpenStack's long-standing docs PTI recommendations (and ideally doing both): "List python dependencies needed for documentation in doc/requirements.txt" https://governance.openstack.org/tc/reference/project-testing-interface.html#documentation -- Jeremy Stanley -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From abishop at redhat.com Mon Jan 4 16:44:15 2021 From: abishop at redhat.com (Alan Bishop) Date: Mon, 4 Jan 2021 08:44:15 -0800 Subject: [tripleO] Customised Cinder-Volume fails at 'Paunch 5' during overcloud deployment In-Reply-To: References: <2D1F2693-49C0-4CA2-8F8E-F9E837D6A232@infinidat.com> Message-ID: On Mon, Jan 4, 2021 at 5:31 AM Igal Katzir wrote: > Hello Alan, > Thanks for your reply! > > I am afraid that the reason for my deployment failure might be concerned > with the environment file I use to configure my cinder backend. > The configuration is quite similar to > https://github.com/Infinidat/tripleo-deployment-configs/blob/dev/RHOSP15/cinder-infinidat-config.yaml > So I wonder if it is possible to run a deployment where I tell 'TripleO' > to use my customize container, using containers-prepare-parameter.yaml, but > without the environment file =cinder-infinidat-config.yaml, and configure > the backend / start cinder-volume services manually? > No, your cinder-infinidat-config.yaml file looks fine. It's responsible for getting TripleO to configure cinder to use your driver, and that phase was completed successfully prior to the deployment failure. > Or I must have a minimum config as I find in: > '/usr/share/openstack-tripleo-heat-templates/deployment/cinder/' (for other > vendors)? > If I do need such a cinder-volume-VENDOR-puppet.yaml config to be > integrated during overcloud deployment, where is documentation that > explains how to construct this? Do I need to use cinder-base.yaml as a > template? > When looking at the web for "cinder-volume-container-puppet.yaml" I found > the Git Page of overcloud-resource-registry-puppet.j2.yaml > > > and found also > https://opendev.org/openstack/tripleo-heat-templates/../deployment > > but it is not so explanatory. > Your cinder-infinidat-config.yaml uses a low-level puppet mechanism for configuring what's referred to as a "custom" block storage backend. This is perfectly fine. If you want better integration with TripleO (and puppet) then you'll need to develop 3 separate patches, 1 each in puppet-cinder, puppet-tripleo and tripleo-heat-templates. Undertaking that would be a good future goal, but isn't necessary in order for you to get past your current deployment issue. > I have opened a case with RedHat as well and they are checking who from > their R&D could help since it's out of the scope of support. > I think you're starting to see responses from Red Hat that should help identify and resolve the problem. Alan > > Regards, > Igal > > On Thu, Dec 31, 2020 at 9:15 PM Alan Bishop wrote: > >> >> >> On Thu, Dec 31, 2020 at 5:26 AM Igal Katzir >> wrote: >> >>> Hello all, >>> >>> I am trying to deploy RHOSP16.1 (based on ‘*train’ *distribution) for Certification >>> purposes. >>> I have build a container for our cinder driver and trying to deploy it. >>> Deployment runs almost till the end and fails at stage when it tries to >>> configure Pacemaker; >>> Here is the last message: >>> >>> "Info: Applying configuration version '1609231063'", "Notice: /Stage[main]/Pacemaker::Corosync/File_line[pcsd_bind_addr]/ensure: created", "Info: /Stage[main]/Pacemaker::Corosync/File_line[pcsd_bind_addr]: Scheduling refresh of Service[pcsd]", "Info: /Stage[main]/Pacemaker::Service/Service[pcsd]: Unscheduling all events on Service[pcsd]", "Info: Class[Pacemaker::Corosync]: Unscheduling all events on Class[Pacemaker::Corosync]", "Notice: /Stage[main]/Tripleo::Profile::Pacemaker::Cinder::Volume_bundle/Pacemaker::Resource::Bundle[openstack-cinder-volume]/Pcmk_bundle[openstack-cinder-volume]: Dependency Pcmk_property[property-overcloud-controller-0-cinder-volume-role] has failures: true", "Info: Creating state file /var/lib/puppet/state/state.yaml", "Notice: Applied catalog in 382.92 seconds", "Changes:", " Total: 1", "Events:", " Success: 1", " Failure: 2", " Total: 3", >>> >>> >>> I have verified that all packages on my container-image >>> (Pacemaker,Corosync, libqb,and pcs) are installed with same versions as >>> the overcloud-controller. >>> >> >> Hi Igal, >> >> Thank you for checking these package versions and stating they match the >> ones installed on the overcloud node. This rules out one of the common >> reasons for failures when trying to run a customized cinder-volume >> container image. >> >> But seems that something is still missing, because deployment with the >>> default openstack-cinder-volume image completes successfully. >>> >> >> This is also good to know. >> >> Can anyone help with debugging this? Let me know if more info needed. >>> >> >> More info is needed, but it's hard to predict exactly where to look for >> the root cause of the failure. I'd start by looking for something at the >> cinder log file >> to determine whether the cinder-volume service is even trying to start. >> Look for /var/log/containers/cinder/cinder-volume.log on the node where >> pacemaker is trying to run the service. Are there logs indicating the >> service is trying to start? Or maybe the service is launched, but fails >> early during startup? >> >> Another possibility is podman fails to launch the container itself. If >> that's happening then check for errors in /var/log/messages. One source of >> this type of failure is you've specified a container bind mount, but the >> source directory doesn't exist (docker would auto-create the source >> directory, but podman does not). >> >> You specifically mentioned RHOSP, so if you need additional support then >> I recommend opening a support case with Red Hat. That will provide a forum >> for posting private data, such as details of your overcloud deployment and >> full sosreports. >> >> Alan >> >> >>> >>> Thanks in advance, >>> Igal >>> >> > > -- > Regards, > > *Igal Katzir* > Cell +972-54-5597086 > Interoperability Team > *INFINIDAT* > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From radoslaw.piliszek at gmail.com Mon Jan 4 17:02:23 2021 From: radoslaw.piliszek at gmail.com (=?UTF-8?Q?Rados=C5=82aw_Piliszek?=) Date: Mon, 4 Jan 2021 18:02:23 +0100 Subject: [release] Status: RED - pip resolver issue with publish-openstack-releasenotes-python3 In-Reply-To: References: Message-ID: On Mon, Jan 4, 2021 at 4:34 PM Herve Beraud wrote: > > Here is the filtered list of projects that meet the conditions leading to the bug, and who should be fixed to completely solve our issue: > > ... > etcd3gw > ... > python-masakariclient > ... > > Notice that some of these projects aren't deliverables but if possible it could be worth fixing them too. > > These projects have an incompatibility between entries in their test-requirements.txt, and they're missing a doc/requirements.txt file. > > The more straightforward path to unlock our job "publish-openstack-releasenotes-python3" is to create a doc/requirements.txt file that only contains the needed dependencies to reduce the possibility of pip resolver issues. I personally think that we could use the latest allowed version of requirements (sphinx, reno, etc...). > > I propose to track the related advancement by using the "fix-relmgt-pip-doc" gerrit topic, when all the projects will be fixed we would be able to update our status. > > Also it could be worth fixing test-requirements.txt incompatibilities but this task is more on the projects teams sides and this task could be done with a follow up patch. > > Thoughts? Thanks, Hervé! Done for python-masakariclient in [1]. etcd3gw needs more love in general but I will have this split in mind. [1] https://review.opendev.org/c/openstack/python-masakariclient/+/769163 -yoctozepto From hberaud at redhat.com Mon Jan 4 17:23:18 2021 From: hberaud at redhat.com (Herve Beraud) Date: Mon, 4 Jan 2021 18:23:18 +0100 Subject: [release] Status: RED - pip resolver issue with publish-openstack-releasenotes-python3 In-Reply-To: References: Message-ID: Thanks all! Here we can track our advancement: https://review.opendev.org/q/topic:%22fix-relmgt-pip-doc%22+(status:open%20OR%20status:merged) Le lun. 4 janv. 2021 à 18:02, Radosław Piliszek a écrit : > On Mon, Jan 4, 2021 at 4:34 PM Herve Beraud wrote: > > > > Here is the filtered list of projects that meet the conditions leading > to the bug, and who should be fixed to completely solve our issue: > > > > ... > > etcd3gw > > ... > > python-masakariclient > > ... > > > > Notice that some of these projects aren't deliverables but if possible > it could be worth fixing them too. > > > > These projects have an incompatibility between entries in their > test-requirements.txt, and they're missing a doc/requirements.txt file. > > > > The more straightforward path to unlock our job > "publish-openstack-releasenotes-python3" is to create a > doc/requirements.txt file that only contains the needed dependencies to > reduce the possibility of pip resolver issues. I personally think that we > could use the latest allowed version of requirements (sphinx, reno, etc...). > > > > I propose to track the related advancement by using the > "fix-relmgt-pip-doc" gerrit topic, when all the projects will be fixed we > would be able to update our status. > > > > Also it could be worth fixing test-requirements.txt incompatibilities > but this task is more on the projects teams sides and this task could be > done with a follow up patch. > > > > Thoughts? > > Thanks, Hervé! > > Done for python-masakariclient in [1]. > > etcd3gw needs more love in general but I will have this split in mind. > > [1] https://review.opendev.org/c/openstack/python-masakariclient/+/769163 > > -yoctozepto > > -- Hervé Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/ https://twitter.com/4383hberaud -----BEGIN PGP SIGNATURE----- wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O v6rDpkeNksZ9fFSyoY2o =ECSj -----END PGP SIGNATURE----- -------------- next part -------------- An HTML attachment was scrubbed... URL: From pierre at stackhpc.com Mon Jan 4 17:41:06 2021 From: pierre at stackhpc.com (Pierre Riteau) Date: Mon, 4 Jan 2021 18:41:06 +0100 Subject: [infra][magnum][ci] Issues installing bashate and coverage In-Reply-To: <20201208171248.6dffedoymqj7dgkr@yuggoth.org> References: <20201208171248.6dffedoymqj7dgkr@yuggoth.org> Message-ID: On Tue, 8 Dec 2020 at 18:24, Jeremy Stanley wrote: > > On 2020-12-08 13:36:09 +0100 (+0100), Spyros Trigazis wrote: > > openstack-tox-lower-constraints fails for bashate and coverage. > > (Maybe more, I bumped bashate and it failed for coverage. I don;t > > want to waste more resources on our CI) > > eg https://review.opendev.org/c/openstack/magnum/+/765881 > > https://review.opendev.org/c/openstack/magnum/+/765979 > > > > Do we miss something? > > Pip 20.3.0, released 8 days ago, turned on a new and much more > thorough dependency resolver. Earlier versions of pip did not try > particularly hard to make sure the dependencies claimed by packages > were all satisfied. Virtualenv 20.2.2 released yesterday and > increased the version of pip it's vendoring to a version which uses > the new solver as well. These changes mean that latent version > conflicts are now being correctly identified as bugs, and these jobs > will do a far better job of actually confirming the declared > versions of dependencies are able to be tested. > > One thing which looks really weird and completely contradictory to > me is that your lower-constraints job on change 765881 is applying > both upper and lower constraints lists to the pip install command. > Maybe the lower constraints list is expected to override the earlier > upper constraints, but is that really going to represent a > compatible set? That aside, trying to reproduce locally I run into > yet a third error: > > Could not find a version that satisfies the requirement > warlock!=1.3.0,<2,>=1.0.1 (from python-glanceclient) > > And indeed, python-glanceclient insists warlock 1.3.0 should be > skipped, while magnum's lower-constraints.txt says you must install > warlock==1.3.0 so that's a clear contradiction as well. > > My recommendation is to work on reproducing this locally first and > play a bit of whack-a-mole with the entries in your > lower-constraints.txt to find versions of things which will actually > be coinstallable with current versions of pip. You don't need to run > the full tox testenv, just try installing your constrainted deps > into a venv with upgraded pip like so: > > python3.8 -m venv foo > foo/bin/pip install -U pip > foo/bin/pip install -c lower-constraints.txt \ > -r test-requirements.txt -r requirements.txt > > You'll also likely want to delete and recreate the venv each time > you try, since pip will now also try to take the requirements of > already installed packages into account, and that might further > change the behavior you see. Hope that helps! > -- > Jeremy Stanley Hi Jeremy, Sorry for hijacking this thread, but I am dealing with the same sort of issues in blazar. The lower-constraints job is failing [1], which has broken our gate. However, I cannot reproduce the issue locally: `tox -e lower-constraints` works fine, and so do your recommended commands with the foo venv. I've tried on multiple operating systems, including Ubuntu 20.04 (with Python 3.8 and pip 20.3.3). So I have been playing whack-a-mole [2] from Zuul logs based on whichever package fails to install, but it's a very slow process. Do you know what I could be missing for reproducing this locally? Thanks, Pierre [1] https://zuul.opendev.org/t/openstack/build/34897587cf954016b8027670117213f6 [2] https://review.opendev.org/c/openstack/blazar/+/767593/ From fungi at yuggoth.org Mon Jan 4 18:08:16 2021 From: fungi at yuggoth.org (Jeremy Stanley) Date: Mon, 4 Jan 2021 18:08:16 +0000 Subject: [infra][magnum][ci] Issues installing bashate and coverage In-Reply-To: References: <20201208171248.6dffedoymqj7dgkr@yuggoth.org> Message-ID: <20210104180816.prb2x3oyuxi4jpkq@yuggoth.org> On 2021-01-04 18:41:06 +0100 (+0100), Pierre Riteau wrote: [...] > I cannot reproduce the issue locally: `tox -e lower-constraints` > works fine, and so do your recommended commands with the foo venv. > I've tried on multiple operating systems, including Ubuntu 20.04 > (with Python 3.8 and pip 20.3.3). [...] > Do you know what I could be missing for reproducing this locally? [...] At this point it may be easier to reproduce with the latest version of virtualenv (20.2.2 at time of writing) since it started pulling in pip 20.3.1 on its own. Just upgrade virtualenv and try your tox command again and see if things are any different for you. It reproduces exactly on my workstation with latest tox/virtualenv just running `tox -e lower-constraints` in a current blazar repo master branch checkout. As for the doubled-constraints I mentioned in the earlier post, looks like blazar is hitting that as well. To correct it you need to move your upper-constraints addition into the default testenv deps list rather than adding it to the default install_command string. Right now it's getting inherited in testenv:lower-constraints too which can't be a good thing. Compare the approach in blazar with that of nova: https://opendev.org/openstack/blazar/src/commit/cb7c142a890e84a2b3171395832d9839b2d66a63/tox.ini#L11 https://opendev.org/openstack/nova/src/commit/b0f241e5425c99866223bae4b404a4aa1abdfddf/tox.ini#L27 Changing it in my local blazar checkout gets farther, though it looks like the old version of markupsafe you're trying to use may not work with latest versions of setuptools (ImportError: cannot import name 'Feature' from 'setuptools'). Hope that helps! -- Jeremy Stanley -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From eandersson at blizzard.com Mon Jan 4 19:49:16 2021 From: eandersson at blizzard.com (Erik Olof Gunnar Andersson) Date: Mon, 4 Jan 2021 19:49:16 +0000 Subject: [magnum][api] Error system library fopen too many open files with magnum-auto-healer In-Reply-To: References: <185a9715-4667-9610-0048-5434e6e2cd4e@catalyst.net.nz> Message-ID: Sure looks like RabbitMQ. How many workers do have you configured? Could you try to change it to workers=1 (or processes=1) and then see if it goes beyond 30 connections to amqp. Best Regards, Erik Olof Gunnar Andersson Technical Lead, Senior Cloud Engineer From: Ionut Biru Sent: Monday, January 4, 2021 4:07 AM To: Erik Olof Gunnar Andersson Cc: feilong ; openstack-discuss Subject: Re: [magnum][api] Error system library fopen too many open files with magnum-auto-healer Hi Erik, Here is lsof of one uwsgi api. https://paste.xinu.at/5YUWf/ I have kubernetes 12.0.1 installed in env. On Sun, Jan 3, 2021 at 3:06 AM Erik Olof Gunnar Andersson > wrote: Maybe something similar to this? https://github.com/kubernetes-client/python/issues/1158 What does lsof say? ________________________________ From: Erik Olof Gunnar Andersson > Sent: Saturday, January 2, 2021 4:54 PM To: Ionut Biru >; feilong > Cc: openstack-discuss > Subject: Re: [magnum][api] Error system library fopen too many open files with magnum-auto-healer Are you sure you aren't just looking at the connection pool expanding? Each worker has a max number of connections it can use. Maybe look at lowering rpc_conn_pool_size. By default I believe each worker might create a pool of up to 30 connections. Looking at the code it could also be have something to do with the k8s client. Since it creates a new instance each time it does an health check. What version of the k8s client do you have installed? ________________________________ From: Ionut Biru > Sent: Tuesday, December 29, 2020 2:20 PM To: feilong > Cc: openstack-discuss > Subject: Re: [magnum][api] Error system library fopen too many open files with magnum-auto-healer Hi, Not sure if my suspicion is true but I think for each update a new notifier is prepared and used without closing the connection but my understanding of oslo is nonexistent. https://opendev.org/openstack/magnum/src/branch/master/magnum/conductor/utils.py#L147 https://opendev.org/openstack/magnum/src/branch/master/magnum/common/rpc.py#L173 On Tue, Dec 29, 2020 at 11:52 PM Ionut Biru > wrote: Hi Feilong, I found out that each time the update_health_status periodic task is run, a new connection(for each uwsgi) is made to rabbitmq. root at ctrl1cj-magnum-container-7a7a412a:~# netstat -npt | grep 5672 | wc -l 229 root at ctrl1cj-magnum-container-7a7a412a:~# netstat -npt | grep 5672 | wc -l 234 root at ctrl1cj-magnum-container-7a7a412a:~# netstat -npt | grep 5672 | wc -l 238 root at ctrl1cj-magnum-container-7a7a412a:~# netstat -npt | grep 5672 | wc -l 241 root at ctrl1cj-magnum-container-7a7a412a:~# netstat -npt | grep 5672 | wc -l 244 Not sure Dec 29 21:51:22 ctrl1cj-magnum-container-7a7a412a magnum-conductor[262800]: 2020-12-29 21:51:22.024 262800 DEBUG magnum.service.periodic [req-3b495326-cf80-481e-b3c6-c741f05b7f0e - - - - -] Dec 29 21:51:22 ctrl1cj-magnum-container-7a7a412a magnum-conductor[262800]: 2020-12-29 21:51:22.024 262800 DEBUG oslo_service.periodic_task [-] Running periodic task MagnumPeriodicTasks.sync Dec 29 21:51:16 ctrl1cj-magnum-container-7a7a412a magnum-conductor[262804]: 2020-12-29 21:51:16.462 262804 DEBUG magnum.conductor.handlers.cluster_conductor [req-284ac12b-d76a-4e50-8e74-5bfb Dec 29 21:51:15 ctrl1cj-magnum-container-7a7a412a magnum-conductor[262800]: 2020-12-29 21:51:15.573 262800 DEBUG magnum.service.periodic [-] Status for cluster 118 updated to HEALTHY ({'api' Dec 29 21:51:15 ctrl1cj-magnum-container-7a7a412a magnum-conductor[262805]: 2020-12-29 21:51:15.572 262805 DEBUG magnum.conductor.handlers.cluster_conductor [req-3fc29ee9-4051-42e7-ae19-3a49 Dec 29 21:51:15 ctrl1cj-magnum-container-7a7a412a magnum-conductor[262800]: 2020-12-29 21:51:15.572 262800 DEBUG magnum.service.periodic [-] Status for cluster 121 updated to HEALTHY ({'api' Dec 29 21:51:15 ctrl1cj-magnum-container-7a7a412a magnum-conductor[262800]: 2020-12-29 21:51:15.572 262800 DEBUG magnum.service.periodic [-] Status for cluster 122 updated to HEALTHY ({'api' Dec 29 21:51:15 ctrl1cj-magnum-container-7a7a412a magnum-conductor[262800]: 2020-12-29 21:51:15.553 262800 DEBUG magnum.service.periodic [-] Updating health status for cluster 122 update_hea Dec 29 21:51:15 ctrl1cj-magnum-container-7a7a412a magnum-conductor[262800]: 2020-12-29 21:51:15.544 262800 DEBUG magnum.service.periodic [-] Updating health status for cluster 121 update_hea Dec 29 21:51:15 ctrl1cj-magnum-container-7a7a412a magnum-conductor[262800]: 2020-12-29 21:51:15.535 262800 DEBUG magnum.service.periodic [-] Updating health status for cluster 118 update_hea Dec 29 21:51:15 ctrl1cj-magnum-container-7a7a412a magnum-conductor[262800]: 2020-12-29 21:51:15.494 262800 DEBUG magnum.service.periodic [req-405b1fed-0b8a-4a60-b6ae-834f548b21d1 - - - 2020-12-29 21:51:14.082 [info] <0.953.1293> accepting AMQP connection <0.953.1293> (172.29.93.14:48474 -> 172.29.95.38:5672) 2020-12-29 21:51:14.083 [info] <0.953.1293> Connection <0.953.1293> (172.29.93.14:48474 -> 172.29.95.38:5672) has a client-provided name: uwsgi:262739:f86c0570-8739-4b74-8102-76b5357acd71 2020-12-29 21:51:14.084 [info] <0.953.1293> connection <0.953.1293> (172.29.93.14:48474 -> 172.29.95.38:5672 - uwsgi:262739:f86c0570-8739-4b74-8102-76b5357acd71): user 'magnum' authenticated and granted access to vhost '/magnum' 2020-12-29 21:51:15.560 [info] <0.1656.1283> accepting AMQP connection <0.1656.1283> (172.29.93.14:48548 -> 172.29.95.38:5672) 2020-12-29 21:51:15.561 [info] <0.1656.1283> Connection <0.1656.1283> (172.29.93.14:48548 -> 172.29.95.38:5672) has a client-provided name: uwsgi:262744:2c9792ab-9198-493a-970c-f6ccfd9947d3 2020-12-29 21:51:15.561 [info] <0.1656.1283> connection <0.1656.1283> (172.29.93.14:48548 -> 172.29.95.38:5672 - uwsgi:262744:2c9792ab-9198-493a-970c-f6ccfd9947d3): user 'magnum' authenticated and granted access to vhost '/magnum' On Tue, Dec 22, 2020 at 4:12 AM feilong > wrote: Hi Ionut, I didn't see this before on our production. Magnum auto healer just simply sends a POST request to Magnum api to update the health status. So I would suggest write a small script or even use curl to see if you can reproduce this firstly. On 19/12/20 2:27 am, Ionut Biru wrote: Hi again, I failed to mention that is stable/victoria with couples of patches from review. Ignore the fact that in logs it shows the 19.1.4 version in venv path. On Fri, Dec 18, 2020 at 3:22 PM Ionut Biru > wrote: Hi guys, I have an issue with magnum api returning an error after a while: Server-side error: "[('system library', 'fopen', 'Too many open files'), ('BIO routines', 'BIO_new_file', 'system lib'), ('x509 certificate routines', 'X509_load_cert_crl_file', 'system lib')]" Log file: https://paste.xinu.at/6djE/ This started to appear after I enabled the template auto_healing_controller = magnum-auto-healer, magnum_auto_healer_tag = v1.19.0. Currently, I only have 4 clusters. After that the API is in error state and doesn't work unless I restart it. -- Ionut Biru - https://fleio.com -- Ionut Biru - https://fleio.com -- Cheers & Best regards, Feilong Wang (王飞龙) ------------------------------------------------------ Senior Cloud Software Engineer Tel: +64-48032246 Email: flwang at catalyst.net.nz Catalyst IT Limited Level 6, Catalyst House, 150 Willis Street, Wellington ------------------------------------------------------ -- Ionut Biru - https://fleio.com -- Ionut Biru - https://fleio.com -- Ionut Biru - https://fleio.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From eandersson at blizzard.com Mon Jan 4 19:52:58 2021 From: eandersson at blizzard.com (Erik Olof Gunnar Andersson) Date: Mon, 4 Jan 2021 19:52:58 +0000 Subject: [magnum][api] Error system library fopen too many open files with magnum-auto-healer In-Reply-To: References: <185a9715-4667-9610-0048-5434e6e2cd4e@catalyst.net.nz> Message-ID: Sure looks like RabbitMQ. How many workers do have you configured? Could you try to changing the uwsgi configuration to workers=1 (or processes=1) and then see if it goes beyond 30 connections to amqp. From: Ionut Biru Sent: Monday, January 4, 2021 4:07 AM To: Erik Olof Gunnar Andersson Cc: feilong ; openstack-discuss Subject: Re: [magnum][api] Error system library fopen too many open files with magnum-auto-healer Hi Erik, Here is lsof of one uwsgi api. https://paste.xinu.at/5YUWf/ I have kubernetes 12.0.1 installed in env. On Sun, Jan 3, 2021 at 3:06 AM Erik Olof Gunnar Andersson > wrote: Maybe something similar to this? https://github.com/kubernetes-client/python/issues/1158 What does lsof say? -------------- next part -------------- An HTML attachment was scrubbed... URL: From mnaser at vexxhost.com Mon Jan 4 21:24:07 2021 From: mnaser at vexxhost.com (Mohammed Naser) Date: Mon, 4 Jan 2021 16:24:07 -0500 Subject: [tc] weekly meeting Message-ID: Hi there, Hope everyone enjoyed the holidays! Here's an update on what happened in the OpenStack TC these past few days. You can get more information by checking for changes in openstack/governance repository. # Patches ## Open Reviews - Add Resolution of TC stance on the OpenStackClient | https://review.opendev.org/c/openstack/governance/+/759904 - Remove Karbor project team | https://review.opendev.org/c/openstack/governance/+/767056 - Add glance-tempest-plugin to Glance | https://review.opendev.org/c/openstack/governance/+/767666 ## Other Reminders - Our next TC Weekly meeting is scheduled for January 7th at 1500 UTC. If you would like to add topics for discussion, please go to https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting and fill out your suggestions by Wednesday, January 6th, at 2100 UTC. Thanks for reading! Mohammed & Kendall -- Mohammed Naser VEXXHOST, Inc. From kennelson11 at gmail.com Mon Jan 4 22:32:13 2021 From: kennelson11 at gmail.com (Kendall Nelson) Date: Mon, 4 Jan 2021 14:32:13 -0800 Subject: [SIG] [First Contact] First Meeting of the Year! Message-ID: Hello! We will be holding our meeting tomorrow (at 00:00 UTC in #openstack-upstream-institute) with a pretty short agenda[1] so feel free to add as you see fit! One thing I do want to try is to set some concrete goal or two for this year to work towards. So if you're new to the SIG this is the perfect time to come meet us and get involved! -Kendall (diablo_rojo) [1] https://wiki.openstack.org/wiki/First_Contact_SIG#Meeting_Agenda -------------- next part -------------- An HTML attachment was scrubbed... URL: From deepa.kr at fingent.com Tue Jan 5 06:41:10 2021 From: deepa.kr at fingent.com (Deepa KR) Date: Tue, 5 Jan 2021 12:11:10 +0530 Subject: [Ussuri] Auto shutdown VM In-Reply-To: <20210104094448.7ukywqmrnasyufqm@lyarwood-laptop.usersys.redhat.com> References: <158621605687826@mail.yandex.com> <14800219-BC67-4B94-88CE-81FE5D8A6AB2@fingent.com> <20210104094448.7ukywqmrnasyufqm@lyarwood-laptop.usersys.redhat.com> Message-ID: Hello Lee Below is the only information from qemu logs. 2020-12-22T07:20:10.251883Z qemu-system-x86_64: warning: host doesn't support requested feature: MSR(48CH).vmx-invept-single-context -noglobals [bit 43] 2020-12-22T07:20:10.251887Z qemu-system-x86_64: warning: host doesn't support requested feature: MSR(480H).vmx-ins-outs [bit 54] 2020-12-22T07:20:10.251890Z qemu-system-x86_64: warning: host doesn't support requested feature: MSR(480H).vmx-true-ctls [bit 55] 2020-12-22T07:20:10.251894Z qemu-system-x86_64: warning: host doesn't support requested feature: MSR(491H).vmx-eptp-switching [bit 0 ] *2021-01-05 01:39:20.896+0000: shutting down, reason=crashed <<< no logs before or after this from Timestamp* 2021-01-05 06:21:37.682+0000: starting up libvirt version: 6.0.0, package: 0ubuntu8~cloud0 (Openstack Ubuntu Testing Bot Mon, 20 Apr 2020 18:44:06 +0000), qemu version: 4.2.0Debian 1:4.2-3ubuntu6~cloud0, kernel: 4.15.0-106-generi c, hostname: fgshwbucehyp02.maas LC_ALL=C \ PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin \ HOME=/var/lib/libvirt/qemu/domain-147-instance-0000057b \ XDG_DATA_HOME=/var/lib/libvirt/qemu/domain-147-instance-0000057b/.local/share \ XDG_CACHE_HOME=/var/lib/libvirt/qemu/domain-147-instance-0000057b/.cache \ XDG_CONFIG_HOME=/var/lib/libvirt/qemu/domain-147-instance-0000057b/.config \ These VMs are migrated from VMware to Openstack (if this tip helps in someway) May VMs get auto shutdown randomly instance-0000032c.log:2021-01-03 17:30:32.980+0000: shutting down, reason=crashed instance-000004d3.log:2020-12-10 21:20:45.807+0000: shutting down, reason=crashed instance-000004d3.log:2020-12-13 21:06:43.683+0000: shutting down, reason=crashed instance-000004d3.log:2020-12-18 23:02:30.727+0000: shutting down, reason=crashed instance-000004d3.log:2020-12-23 16:39:22.194+0000: shutting down, reason=crashed instance-000004d3.log:2020-12-29 23:43:03.554+0000: shutting down, reason=crashed instance-000004d3.log:2021-01-03 19:13:08.850+0000: shutting down, reason=crashed instance-0000057b.log:2020-12-07 04:20:44.540+0000: shutting down, reason=crashed instance-0000057b.log:2020-12-09 18:22:08.652+0000: shutting down, reason=crashed instance-0000057b.log:2020-12-12 19:37:34.824+0000: shutting down, reason=crashed instance-0000057b.log:2020-12-15 16:38:50.268+0000: shutting down, reason=crashed instance-0000057b.log:2020-12-16 17:31:29.975+0000: shutting down, reason=crashed instance-0000057b.log:2020-12-21 18:55:58.644+0000: shutting down, reason=crashed instance-0000057b.log:2021-01-05 01:39:20.896+0000: shutting down, reason=crashed Not sure what could i do more to prevent the auto shutdown On Mon, Jan 4, 2021 at 3:14 PM Lee Yarwood wrote: > On 04-01-21 14:53:59, Deepa KR wrote: > > Hi All > > > > Any suggestions highly appreciated. > > We are facing these issues very frequently now . > > Can you pastebin the domain QEMU log from > /var/log/libvirt/qemu/$domain.log? That should detail why the domain is > crashing. > > I'd also recommend reviewing the following docs from libvirt on how to > enable debug logs etc: > > https://libvirt.org/kbase/debuglogs.html > > > On Mon, Nov 23, 2020 at 10:03 AM Deepa KR wrote: > > > Hi > > > > > > Can see only shutting down, reason=crashed in libvirt/qemu logs > .Nothing > > > else . > > > Couldn't find anything else in neutron logs as well > > > > > > > > > On Wed, Nov 18, 2020 at 5:23 PM Deepa KR wrote: > > > > > >> Thanks for pointing out. Have 70 + vms and has issue with just 3 vms > so i > > >> am really confused > > >> > > >> Sent from my iPhone > > >> > > >> On 18-Nov-2020, at 1:56 PM, rui zang wrote: > > >> > > >>  > > >> [instance: 28cd861c-ef15-444a-a902-9cac643c72b5] *Received unexpected > > >> event network-vif-unplugged-e97839a1-bbc4-4d26-af30-768ca3630ce9 for > > >> instance with vm_state active and task_state None.* > > >> > > >> > > >> Clearly the network virtual interface was somehow removed or > unplugged. > > >> What you should look into is OVS or whatever the network solution you > are > > >> using. > > >> > > >> > > >> 18.11.2020, 01:44, "Deepa KR" : > > >> > > >>  Hi All > > >> > > >> We have a Openstack setup with the *Ussuri Version* and I am > *regularly > > >> facing auto shutdown of a few VMs (ubuntu16.04) randomly* . > > >> If I restart then the instance is back . > > >> > > >> From logs I was able to see the messages below . > > >> > > >> WARNING nova.compute.manager > [req-2a21d455-ac04-44aa-b248-4776e5109013 > > >> 813f3fb52c434e38991bb90aa4771541 10b5279cb6f64ca19871f132a2cee1a3 - > default > > >> default] [instance: 28cd861c-ef15-444a-a902-9cac643c72b5] *Received > > >> unexpected event > network-vif-unplugged-e97839a1-bbc4-4d26-af30-768ca3630ce9 > > >> for instance with vm_state active and task_state None.* > > >> INFO nova.compute.manager [-] [instance: > > >> 28cd861c-ef15-444a-a902-9cac643c72b5] VM Stopped (Lifecycle Event) > > >> INFO nova.compute.manager [req-8261f607-4f1e-459d-85d4-e269694dd477 > - - > > >> - - -] [instance: 28cd861c-ef15-444a-a902-9cac643c72b5] *During > > >> _sync_instance_power_state the DB power_state (1) does not match the > > >> vm_power_state from the hypervisor (4). Updating power_state in the > DB to > > >> match the hypervisor.* > > >> syslog:Nov 13 07:01:07 fgshwbucehyp04 nova-compute[2680204]: > 2020-11-13 > > >> 07:01:07.684 2680204 WARNING nova.compute.manager > > >> [req-8261f607-4f1e-459d-85d4-e269694dd477 - - - - -] [instance: > > >> 28cd861c-ef15-444a-a902-9cac643c72b5] *Instance shutdown by itself. > > >> Calling the stop API. Current vm_state: active, current task_state: > None, > > >> original DB power_state: 1, current VM power_state: 4* > > >> nova.compute.manager [req-8261f607-4f1e-459d-85d4-e269694dd477 - - > - - > > >> -] [instance: 28cd861c-ef15-444a-a902-9cac643c72b5] *Instance is > already > > >> powered off in the hypervisor when stop is called.* > > >> nova.virt.libvirt.driver [req-8261f607-4f1e-459d-85d4-e269694dd477 - > - - > > >> - -] [instance: 28cd861c-ef15-444a-a902-9cac643c72b5] *Instance > already > > >> shutdown.* > > >> nova.virt.libvirt.driver [-] [instance: > > >> 28cd861c-ef15-444a-a902-9cac643c72b5] *Instance destroyed > successfully.* > > >> nova.compute.manager [req-7a0a0d03-e286-42f0-9e36-38a432f236f3 > > >> d9ca03b9d0884d51a26a39b6c82f02eb 304d859c43df4de4944ca5623f7f455c - > default > > >> default] [instance: 28cd861c-ef15-444a-a902-9cac643c72b5] Get console > output > > >> nova.virt.libvirt.driver [-] [instance: > > >> 28cd861c-ef15-444a-a902-9cac643c72b5] *Instance destroyed > successfully.* > > >> > > >> I searched a few blogs and forums but couldn't find a solution to it . > > >> > > >> Few mentioned to add s*ync_power_state_interval=-1 in * > > >> */etc/nova/nova.conf *.But understood that this will help only when > nova > > >> stops vm. > > >> But in this case vm itself is shutting down (*Instance shutdown by > > >> itself. Calling the stop API*) > > >> Also no memory issue in VM nor the hypervisor. > > >> Also did apt-get upgrade . > > >> > > >> It would be great if anyone can shed light to this issue. > > >> > > >> Regards, > > >> Deepa K R > > >> > > >> Sent from my iPhone > > >> > > >> > > > > > > -- > > > > > > > > > Regards, > > > > > > Deepa K R | DevOps Team Lead > > > > > > > > > > > > USA | UAE | INDIA | AUSTRALIA > > > > > > > > > > > > > -- > > > > > > Regards, > > > > Deepa K R | DevOps Team Lead > > > > > > > > USA | UAE | INDIA | AUSTRALIA > > > > > -- > Lee Yarwood A5D1 9385 88CB 7E5F BE64 6618 BCA6 6E33 F672 > 2D76 > -- Regards, Deepa K R | DevOps Team Lead USA | UAE | INDIA | AUSTRALIA -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature-1.gif Type: image/gif Size: 566 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: logo_for_signature.png Type: image/png Size: 10509 bytes Desc: not available URL: From deepa.kr at fingent.com Tue Jan 5 07:25:31 2021 From: deepa.kr at fingent.com (Deepa KR) Date: Tue, 5 Jan 2021 12:55:31 +0530 Subject: [Ussuri] Auto shutdown VM In-Reply-To: References: <9A9C606C-3658-473C-83DC-6305D496A6CD@fingent.com> Message-ID: Hello Pierre Yeah have checked hypervisor too ..No error related to kernel out-of-memory (OOM) in hypervisor On Mon, Jan 4, 2021 at 3:45 PM Pierre Riteau wrote: > Hi Deepa, > > You mention checking dmesg *inside* the VM. But have you checked dmesg > on the hypervisor? It's possible your qemu-kvm processes are > terminated by the kernel out-of-memory (OOM) killer because they try > to allocate more memory than available. > > Best wishes, > Pierre Riteau (priteau) > > > On Wed, 18 Nov 2020 at 03:44, Deepa KR wrote: > > > > Hello Mohammed > > > > Thanks for the response. > > No error message inside vm. Have checked dmesg, syslog etc . > > > > I mentioned vm is shutting down itself because of error messages > Instance shutdown by itself. Calling the stop API. Current vm_state: > active, current task_state: None, original DB power_state: 1, current VM > power_state: 4 from hypervisor. > > > > Sent from my iPhone > > > > > On 17-Nov-2020, at 11:35 PM, Mohammed Naser > wrote: > > > > > > On Tue, Nov 17, 2020 at 12:46 PM Deepa KR > wrote: > > >> > > >>  Hi All > > >> > > >> We have a Openstack setup with the Ussuri Version and I am regularly > facing auto shutdown of a few VMs (ubuntu16.04) randomly . > > >> If I restart then the instance is back . > > >> > > >> From logs I was able to see the messages below . > > >> > > >> WARNING nova.compute.manager > [req-2a21d455-ac04-44aa-b248-4776e5109013 813f3fb52c434e38991bb90aa4771541 > 10b5279cb6f64ca19871f132a2cee1a3 - default default] [instance: > 28cd861c-ef15-444a-a902-9cac643c72b5] Received unexpected event > network-vif-unplugged-e97839a1-bbc4-4d26-af30-768ca3630ce9 for instance > with vm_state active and task_state None. > > >> INFO nova.compute.manager [-] [instance: > 28cd861c-ef15-444a-a902-9cac643c72b5] VM Stopped (Lifecycle Event) > > >> INFO nova.compute.manager [req-8261f607-4f1e-459d-85d4-e269694dd477 - > - - - -] [instance: 28cd861c-ef15-444a-a902-9cac643c72b5] During > _sync_instance_power_state the DB power_state (1) does not match the > vm_power_state from the hypervisor (4). Updating power_state in the DB to > match the hypervisor. > > >> syslog:Nov 13 07:01:07 fgshwbucehyp04 nova-compute[2680204]: > 2020-11-13 07:01:07.684 2680204 WARNING nova.compute.manager > [req-8261f607-4f1e-459d-85d4-e269694dd477 - - - - -] [instance: > 28cd861c-ef15-444a-a902-9cac643c72b5] Instance shutdown by itself. Calling > the stop API. Current vm_state: active, current task_state: None, original > DB power_state: 1, current VM power_state: 4 > > >> nova.compute.manager [req-8261f607-4f1e-459d-85d4-e269694dd477 - - - > - -] [instance: 28cd861c-ef15-444a-a902-9cac643c72b5] Instance is already > powered off in the hypervisor when stop is called. > > >> nova.virt.libvirt.driver [req-8261f607-4f1e-459d-85d4-e269694dd477 - > - - - -] [instance: 28cd861c-ef15-444a-a902-9cac643c72b5] Instance already > shutdown. > > >> nova.virt.libvirt.driver [-] [instance: > 28cd861c-ef15-444a-a902-9cac643c72b5] Instance destroyed successfully. > > >> nova.compute.manager [req-7a0a0d03-e286-42f0-9e36-38a432f236f3 > d9ca03b9d0884d51a26a39b6c82f02eb 304d859c43df4de4944ca5623f7f455c - default > default] [instance: 28cd861c-ef15-444a-a902-9cac643c72b5] Get console output > > >> nova.virt.libvirt.driver [-] [instance: > 28cd861c-ef15-444a-a902-9cac643c72b5] Instance destroyed successfully. > > >> > > >> I searched a few blogs and forums but couldn't find a solution to it . > > >> > > >> Few mentioned to add sync_power_state_interval=-1 in > /etc/nova/nova.conf .But understood that this will help only when nova > stops vm. > > >> But in this case vm itself is shutting down (Instance shutdown by > itself. Calling the stop API) > > >> Also no memory issue in VM nor the hypervisor. > > >> Also did apt-get upgrade . > > >> > > >> It would be great if anyone can shed light to this issue. > > > > > > You should check and see if there is anything inside `dmesg` that > > > shows the VM dying (any segfaults?). Also, it's possible that the VM > > > itself is shutting off so maybe you should check ni its logs. > > > > > >> Regards, > > >> Deepa K R > > >> > > >> Sent from my iPhone > > > > > > > > > > > > -- > > > Mohammed Naser > > > VEXXHOST, Inc. > > > -- Regards, Deepa K R | DevOps Team Lead USA | UAE | INDIA | AUSTRALIA -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature-1.gif Type: image/gif Size: 566 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: logo_for_signature.png Type: image/png Size: 10509 bytes Desc: not available URL: From cjeanner at redhat.com Tue Jan 5 07:43:05 2021 From: cjeanner at redhat.com (=?UTF-8?Q?C=c3=a9dric_Jeanneret?=) Date: Tue, 5 Jan 2021 08:43:05 +0100 Subject: [tripleo] Package dependencies, podman, dnf modules Message-ID: <6ab7507a-b5b8-c124-3e04-c3d410de6ff7@redhat.com> Hello there, Since we introduced Podman instead of Docker in tripleo, we are running after the right version. For now, the version we should use is provided by a specific container-tools module stream (container-tools:2.0). The default stream being container-tools:rhel8, we might end with a deployed undercloud running the wrong podman version, leading to some nice issues, especially in a SELinux-enabled environment. Currently, the main dependency tree is: python3-tripleoclient requires podman That's mostly all. While we can, of course, edit the python3-tripleoclient spec file in order to pin the precise podman version (or, at least, set upper and lower constraints) in order to target the version provided by the right stream, it's not ideal: - package install error will lead to more questions (since ppl might skip doc for #reason) - if we change the target version, we'll need to ensure it's present in a stream (and, well, update the doc if we need to switch the stream) - and probably some other reasons. Since we can NOT depend on a specific stream in rpm (for instance, we can't put "Requires @container-tools:2.0/podman" like we might in ansible), we're a bit stuck. An ugly hack is tested in the spec file[1], using a bash thing in order to check the activated stream, but this is not ideal either, especially since it makes the whole package building/checking fail during the "mock" stage. In order to make it pass, we'd need to modify the whole RDO in order to take into account stream switching. This isn't impossible, but it leads to other concerns, especially when it comes to "hey we need to switch the stream for ". And I'm pretty sure no one will want to dig into it, for good reasons ;). This leads to a last possibility: drop the "Requires podman" from tripleo dependency tree, and rely on tripleo-ansible to actually enable the correct module, and install podman. This means podman will be installed during the undercloud deploy, for instance as a host_prep_tasks (step_0). While I'm not that happy with this idea, it's probably not as bad as the other hacks we've tested so far, and would, at last, prevent once for all the usual "it's not working" due to a wrong podman version (and, yes, we get plenty of them, especially in the OSP version). What do you think? Any other way of solving this issue? Remember, we're talking about "ensuring we get the right version, coming from a specific stream" and, especially, "ensure operator can't install the wrong one" (if they don't follow the doc, of if they are using automation that doesn't check actual requirements in the doc"... Thank you for your thoughts! Cheers, C. [1] https://review.rdoproject.org/r/#/c/31411/ -- Cédric Jeanneret (He/Him/His) Sr. Software Engineer - OpenStack Platform Deployment Framework TC Red Hat EMEA https://www.redhat.com/ -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature Type: application/pgp-signature Size: 840 bytes Desc: OpenPGP digital signature URL: From ionut at fleio.com Tue Jan 5 08:35:42 2021 From: ionut at fleio.com (Ionut Biru) Date: Tue, 5 Jan 2021 10:35:42 +0200 Subject: [magnum][api] Error system library fopen too many open files with magnum-auto-healer In-Reply-To: References: <185a9715-4667-9610-0048-5434e6e2cd4e@catalyst.net.nz> Message-ID: Hi, I tried with process=1 and it reached 1016 connections to rabbitmq. lsof https://paste.xinu.at/jGg/ i think it goes into error when it reaches 1024 file descriptors. I'm out of ideas of how to resolve this. I only have 3 clusters available and it's kinda weird and It doesn't scale. On Mon, Jan 4, 2021 at 9:53 PM Erik Olof Gunnar Andersson < eandersson at blizzard.com> wrote: > Sure looks like RabbitMQ. How many workers do have you configured? > > > > Could you try to changing the uwsgi configuration to workers=1 (or > processes=1) and then see if it goes beyond 30 connections to amqp. > > > > *From:* Ionut Biru > *Sent:* Monday, January 4, 2021 4:07 AM > *To:* Erik Olof Gunnar Andersson > *Cc:* feilong ; openstack-discuss < > openstack-discuss at lists.openstack.org> > *Subject:* Re: [magnum][api] Error system library fopen too many open > files with magnum-auto-healer > > > > Hi Erik, > > > > Here is lsof of one uwsgi api. https://paste.xinu.at/5YUWf/ > > > > > I have kubernetes 12.0.1 installed in env. > > > > > > On Sun, Jan 3, 2021 at 3:06 AM Erik Olof Gunnar Andersson < > eandersson at blizzard.com> wrote: > > Maybe something similar to this? > https://github.com/kubernetes-client/python/issues/1158 > > > What does lsof say? > > > > > -- Ionut Biru - https://fleio.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From marios at redhat.com Tue Jan 5 08:56:47 2021 From: marios at redhat.com (Marios Andreou) Date: Tue, 5 Jan 2021 10:56:47 +0200 Subject: [tripleo] Package dependencies, podman, dnf modules In-Reply-To: <6ab7507a-b5b8-c124-3e04-c3d410de6ff7@redhat.com> References: <6ab7507a-b5b8-c124-3e04-c3d410de6ff7@redhat.com> Message-ID: On Tue, Jan 5, 2021 at 9:44 AM Cédric Jeanneret wrote: > Hello there, > > Since we introduced Podman instead of Docker in tripleo, we are running > after the right version. > For now, the version we should use is provided by a specific > container-tools module stream (container-tools:2.0). The default stream > being container-tools:rhel8, we might end with a deployed undercloud > running the wrong podman version, leading to some nice issues, > especially in a SELinux-enabled environment. > o/ Tengu thanks for socialising that issue, it's a fun one for sure... first question is _where_ is that the default and it is mostly rhetorical as I can guess. In general though i think it's worth filing a LP bug with some of these details so we can also track whatever is decided as a fix here. > Currently, the main dependency tree is: > python3-tripleoclient requires podman > That's mostly all. > > While we can, of course, edit the python3-tripleoclient spec file in > order to pin the precise podman version (or, at least, set upper and > lower constraints) in order to target the version provided by the right > stream, it's not ideal: > - package install error will lead to more questions (since ppl might > skip doc for #reason) > - if we change the target version, we'll need to ensure it's present in > a stream (and, well, update the doc if we need to switch the stream) > - and probably some other reasons. > > Since we can NOT depend on a specific stream in rpm (for instance, we > can't put "Requires @container-tools:2.0/podman" like we might in > ansible), we're a bit stuck. > > An ugly hack is tested in the spec file[1], using a bash thing in order > to check the activated stream, but this is not ideal either, especially > since it makes the whole package building/checking fail during the > "mock" stage. In order to make it pass, we'd need to modify the whole > RDO in order to take into account stream switching. This isn't > impossible, but it leads to other concerns, especially when it comes to > "hey we need to switch the stream for ". And I'm pretty sure no > one will want to dig into it, for good reasons ;). > > This leads to a last possibility: > drop the "Requires podman" from tripleo dependency tree, and rely on > so how does that work in practice though I mean what about python-tripleoclient. Quick grep just now tells me at least the heat-launcher is directly using podman. How do we drop that requirement. > tripleo-ansible to actually enable the correct module, and install podman. > This means podman will be installed during the undercloud deploy, for > instance as a host_prep_tasks (step_0). > > I am missing how using tripleo-ansible helps us with the stream question. Do you mean add logic in tripleo-ansible that tests the stream and sets the correct version ? While I'm not that happy with this idea, it's probably not as bad as the > other hacks we've tested so far, and would, at last, prevent once for > all the usual "it's not working" due to a wrong podman version (and, > yes, we get plenty of them, especially in the OSP version). > > What do you think? Any other way of solving this issue? Remember, we're > talking about "ensuring we get the right version, coming from a specific > stream" and, especially, "ensure operator can't install the wrong one" > (if they don't follow the doc, of if they are using automation that > doesn't check actual requirements in the doc"... > in general i lean more towards 'ansible tasks' rather than 'bash thing in the specfile' to solve that. Either way though this is us reacting (with some fix/hack/workaround) to a problem that isn't anything to do with TripleO or even OpenStack but rather an OS/packaging issue. So do we have any longer term plans on what you mentioned on IRC just now regarding getting module support for RPM deps (do you mean something in the spec file here?) or is that a complete dead end? thanks, marios > Thank you for your thoughts! > > Cheers, > > C. > > > [1] https://review.rdoproject.org/r/#/c/31411/ > > > -- > Cédric Jeanneret (He/Him/His) > Sr. Software Engineer - OpenStack Platform > Deployment Framework TC > Red Hat EMEA > https://www.redhat.com/ > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From strigazi at gmail.com Tue Jan 5 08:59:47 2021 From: strigazi at gmail.com (Spyros Trigazis) Date: Tue, 5 Jan 2021 09:59:47 +0100 Subject: [magnum][api] Error system library fopen too many open files with magnum-auto-healer In-Reply-To: References: <185a9715-4667-9610-0048-5434e6e2cd4e@catalyst.net.nz> Message-ID: On Tue, Jan 5, 2021 at 9:36 AM Ionut Biru wrote: > Hi, > > I tried with process=1 and it reached 1016 connections to rabbitmq. > lsof > https://paste.xinu.at/jGg/ > > i think it goes into error when it reaches 1024 file descriptors. > > I'm out of ideas of how to resolve this. I only have 3 clusters available > and it's kinda weird and It doesn't scale. > No issues here with 100s of clusters. Not sure what doesn't scale. * Maybe your rabbit is flooded with notifications that are not consumed? * You can use way more than 1024 file descriptors, maybe 2^10? Spyros > > On Mon, Jan 4, 2021 at 9:53 PM Erik Olof Gunnar Andersson < > eandersson at blizzard.com> wrote: > >> Sure looks like RabbitMQ. How many workers do have you configured? >> >> >> >> Could you try to changing the uwsgi configuration to workers=1 (or >> processes=1) and then see if it goes beyond 30 connections to amqp. >> >> >> >> *From:* Ionut Biru >> *Sent:* Monday, January 4, 2021 4:07 AM >> *To:* Erik Olof Gunnar Andersson >> *Cc:* feilong ; openstack-discuss < >> openstack-discuss at lists.openstack.org> >> *Subject:* Re: [magnum][api] Error system library fopen too many open >> files with magnum-auto-healer >> >> >> >> Hi Erik, >> >> >> >> Here is lsof of one uwsgi api. https://paste.xinu.at/5YUWf/ >> >> >> >> >> I have kubernetes 12.0.1 installed in env. >> >> >> >> >> >> On Sun, Jan 3, 2021 at 3:06 AM Erik Olof Gunnar Andersson < >> eandersson at blizzard.com> wrote: >> >> Maybe something similar to this? >> https://github.com/kubernetes-client/python/issues/1158 >> >> >> What does lsof say? >> >> >> >> >> > > > -- > Ionut Biru - https://fleio.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: From eandersson at blizzard.com Tue Jan 5 09:22:57 2021 From: eandersson at blizzard.com (Erik Olof Gunnar Andersson) Date: Tue, 5 Jan 2021 09:22:57 +0000 Subject: [magnum][api] Error system library fopen too many open files with magnum-auto-healer In-Reply-To: References: <185a9715-4667-9610-0048-5434e6e2cd4e@catalyst.net.nz> , Message-ID: Yea - tested locally as well and wasn't able to reproduce it either. I changed the health service job to run every second and maxed out at about 42 connections to RabbitMQ with two conductor workers. /etc/magnum/magnun.conf [conductor] workers = 2 ________________________________ From: Spyros Trigazis Sent: Tuesday, January 5, 2021 12:59 AM To: Ionut Biru Cc: Erik Olof Gunnar Andersson ; feilong ; openstack-discuss Subject: Re: [magnum][api] Error system library fopen too many open files with magnum-auto-healer On Tue, Jan 5, 2021 at 9:36 AM Ionut Biru > wrote: Hi, I tried with process=1 and it reached 1016 connections to rabbitmq. lsof https://paste.xinu.at/jGg/ i think it goes into error when it reaches 1024 file descriptors. I'm out of ideas of how to resolve this. I only have 3 clusters available and it's kinda weird and It doesn't scale. No issues here with 100s of clusters. Not sure what doesn't scale. * Maybe your rabbit is flooded with notifications that are not consumed? * You can use way more than 1024 file descriptors, maybe 2^10? Spyros On Mon, Jan 4, 2021 at 9:53 PM Erik Olof Gunnar Andersson > wrote: Sure looks like RabbitMQ. How many workers do have you configured? Could you try to changing the uwsgi configuration to workers=1 (or processes=1) and then see if it goes beyond 30 connections to amqp. From: Ionut Biru > Sent: Monday, January 4, 2021 4:07 AM To: Erik Olof Gunnar Andersson > Cc: feilong >; openstack-discuss > Subject: Re: [magnum][api] Error system library fopen too many open files with magnum-auto-healer Hi Erik, Here is lsof of one uwsgi api. https://paste.xinu.at/5YUWf/ I have kubernetes 12.0.1 installed in env. On Sun, Jan 3, 2021 at 3:06 AM Erik Olof Gunnar Andersson > wrote: Maybe something similar to this? https://github.com/kubernetes-client/python/issues/1158 What does lsof say? -- Ionut Biru - https://fleio.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From ionut at fleio.com Tue Jan 5 09:50:54 2021 From: ionut at fleio.com (Ionut Biru) Date: Tue, 5 Jan 2021 11:50:54 +0200 Subject: [magnum][api] Error system library fopen too many open files with magnum-auto-healer In-Reply-To: References: <185a9715-4667-9610-0048-5434e6e2cd4e@catalyst.net.nz> Message-ID: Hi, Here is my config. maybe something is fishy. I did have around 300 messages in the queue in notification.info and notification.err and I purged them. https://paste.xinu.at/woMt/ On Tue, Jan 5, 2021 at 11:23 AM Erik Olof Gunnar Andersson < eandersson at blizzard.com> wrote: > Yea - tested locally as well and wasn't able to reproduce it either. I > changed the health service job to run every second and maxed out at about > 42 connections to RabbitMQ with two conductor workers. > > /etc/magnum/magnun.conf > > [conductor] > workers = 2 > > > ------------------------------ > *From:* Spyros Trigazis > *Sent:* Tuesday, January 5, 2021 12:59 AM > *To:* Ionut Biru > *Cc:* Erik Olof Gunnar Andersson ; feilong < > feilong at catalyst.net.nz>; openstack-discuss < > openstack-discuss at lists.openstack.org> > *Subject:* Re: [magnum][api] Error system library fopen too many open > files with magnum-auto-healer > > > > On Tue, Jan 5, 2021 at 9:36 AM Ionut Biru wrote: > > Hi, > > I tried with process=1 and it reached 1016 connections to rabbitmq. > lsof > https://paste.xinu.at/jGg/ > > > i think it goes into error when it reaches 1024 file descriptors. > > I'm out of ideas of how to resolve this. I only have 3 clusters available > and it's kinda weird and It doesn't scale. > > > No issues here with 100s of clusters. Not sure what doesn't scale. > > * Maybe your rabbit is flooded with notifications that are not consumed? > * You can use way more than 1024 file descriptors, maybe 2^10? > > Spyros > > > On Mon, Jan 4, 2021 at 9:53 PM Erik Olof Gunnar Andersson < > eandersson at blizzard.com> wrote: > > Sure looks like RabbitMQ. How many workers do have you configured? > > > > Could you try to changing the uwsgi configuration to workers=1 (or > processes=1) and then see if it goes beyond 30 connections to amqp. > > > > *From:* Ionut Biru > *Sent:* Monday, January 4, 2021 4:07 AM > *To:* Erik Olof Gunnar Andersson > *Cc:* feilong ; openstack-discuss < > openstack-discuss at lists.openstack.org> > *Subject:* Re: [magnum][api] Error system library fopen too many open > files with magnum-auto-healer > > > > Hi Erik, > > > > Here is lsof of one uwsgi api. https://paste.xinu.at/5YUWf/ > > > > > I have kubernetes 12.0.1 installed in env. > > > > > > On Sun, Jan 3, 2021 at 3:06 AM Erik Olof Gunnar Andersson < > eandersson at blizzard.com> wrote: > > Maybe something similar to this? > https://github.com/kubernetes-client/python/issues/1158 > > > What does lsof say? > > > > > > > > -- > Ionut Biru - https://fleio.com > > > -- Ionut Biru - https://fleio.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From pierre at stackhpc.com Tue Jan 5 10:12:56 2021 From: pierre at stackhpc.com (Pierre Riteau) Date: Tue, 5 Jan 2021 11:12:56 +0100 Subject: [infra][magnum][ci] Issues installing bashate and coverage In-Reply-To: <20210104180816.prb2x3oyuxi4jpkq@yuggoth.org> References: <20201208171248.6dffedoymqj7dgkr@yuggoth.org> <20210104180816.prb2x3oyuxi4jpkq@yuggoth.org> Message-ID: On Mon, 4 Jan 2021 at 19:18, Jeremy Stanley wrote: > > On 2021-01-04 18:41:06 +0100 (+0100), Pierre Riteau wrote: > [...] > > I cannot reproduce the issue locally: `tox -e lower-constraints` > > works fine, and so do your recommended commands with the foo venv. > > I've tried on multiple operating systems, including Ubuntu 20.04 > > (with Python 3.8 and pip 20.3.3). > [...] > > Do you know what I could be missing for reproducing this locally? > [...] > > At this point it may be easier to reproduce with the latest version > of virtualenv (20.2.2 at time of writing) since it started pulling > in pip 20.3.1 on its own. Just upgrade virtualenv and try your tox > command again and see if things are any different for you. It > reproduces exactly on my workstation with latest tox/virtualenv just > running `tox -e lower-constraints` in a current blazar repo master > branch checkout. > > As for the doubled-constraints I mentioned in the earlier post, > looks like blazar is hitting that as well. To correct it you need to > move your upper-constraints addition into the default testenv deps > list rather than adding it to the default install_command string. > Right now it's getting inherited in testenv:lower-constraints too > which can't be a good thing. Compare the approach in blazar with > that of nova: > > https://opendev.org/openstack/blazar/src/commit/cb7c142a890e84a2b3171395832d9839b2d66a63/tox.ini#L11 > > https://opendev.org/openstack/nova/src/commit/b0f241e5425c99866223bae4b404a4aa1abdfddf/tox.ini#L27 > > Changing it in my local blazar checkout gets farther, though it > looks like the old version of markupsafe you're trying to use may > not work with latest versions of setuptools (ImportError: cannot > import name 'Feature' from 'setuptools'). Hope that helps! > -- > Jeremy Stanley Hi Jeremy, Thank you very much, this helped a lot. Combining the install_command fix with the latest virtualenv, I managed to reproduce the job failure locally and updated outdated lower constraints. Somehow my patch was working locally while still failing in Zuul with "oslo-db 4.40.0 depends on alembic>=0.9.6", but after bumping alembic it now succeeds. Cheers, Pierre From marios at redhat.com Tue Jan 5 10:13:42 2021 From: marios at redhat.com (Marios Andreou) Date: Tue, 5 Jan 2021 12:13:42 +0200 Subject: [release] Status: RED - pip resolver issue with publish-openstack-releasenotes-python3 In-Reply-To: References: Message-ID: On Mon, Jan 4, 2021 at 7:25 PM Herve Beraud wrote: > Thanks all! > > Here we can track our advancement: > > https://review.opendev.org/q/topic:%22fix-relmgt-pip-doc%22+(status:open%20OR%20status:merged) > > Herve thanks very much for your efforts - I was just getting caught up on this to post the tripleo changes but I see you already beat me to it. I'll check your list to see if there are any more and will post. I'll bring this to the tripleo irc meeting today as well so we can get help merging those asap. thank you marios > Le lun. 4 janv. 2021 à 18:02, Radosław Piliszek < > radoslaw.piliszek at gmail.com> a écrit : > >> On Mon, Jan 4, 2021 at 4:34 PM Herve Beraud wrote: >> > >> > Here is the filtered list of projects that meet the conditions leading >> to the bug, and who should be fixed to completely solve our issue: >> > >> > ... >> > etcd3gw >> > ... >> > python-masakariclient >> > ... >> > >> > Notice that some of these projects aren't deliverables but if possible >> it could be worth fixing them too. >> > >> > These projects have an incompatibility between entries in their >> test-requirements.txt, and they're missing a doc/requirements.txt file. >> > >> > The more straightforward path to unlock our job >> "publish-openstack-releasenotes-python3" is to create a >> doc/requirements.txt file that only contains the needed dependencies to >> reduce the possibility of pip resolver issues. I personally think that we >> could use the latest allowed version of requirements (sphinx, reno, etc...). >> > >> > I propose to track the related advancement by using the >> "fix-relmgt-pip-doc" gerrit topic, when all the projects will be fixed we >> would be able to update our status. >> > >> > Also it could be worth fixing test-requirements.txt incompatibilities >> but this task is more on the projects teams sides and this task could be >> done with a follow up patch. >> > >> > Thoughts? >> >> Thanks, Hervé! >> >> Done for python-masakariclient in [1]. >> >> etcd3gw needs more love in general but I will have this split in mind. >> >> [1] https://review.opendev.org/c/openstack/python-masakariclient/+/769163 >> >> -yoctozepto >> >> > > -- > Hervé Beraud > Senior Software Engineer at Red Hat > irc: hberaud > https://github.com/4383/ > https://twitter.com/4383hberaud > -----BEGIN PGP SIGNATURE----- > > wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ > Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ > RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP > F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G > 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g > glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw > m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ > hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 > qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y > F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 > B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O > v6rDpkeNksZ9fFSyoY2o > =ECSj > -----END PGP SIGNATURE----- > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From eandersson at blizzard.com Tue Jan 5 10:21:22 2021 From: eandersson at blizzard.com (Erik Olof Gunnar Andersson) Date: Tue, 5 Jan 2021 10:21:22 +0000 Subject: [magnum][api] Error system library fopen too many open files with magnum-auto-healer In-Reply-To: References: <185a9715-4667-9610-0048-5434e6e2cd4e@catalyst.net.nz> , Message-ID: Sorry, being repetitive here, but maybe try adding this to your magnum config as well. If you have A LOT of cores it could add up to a crazy amount of connections. [conductor] workers = 2 ________________________________ From: Ionut Biru Sent: Tuesday, January 5, 2021 1:50 AM To: Erik Olof Gunnar Andersson Cc: Spyros Trigazis ; feilong ; openstack-discuss Subject: Re: [magnum][api] Error system library fopen too many open files with magnum-auto-healer Hi, Here is my config. maybe something is fishy. I did have around 300 messages in the queue in notification.info and notification.err and I purged them. https://paste.xinu.at/woMt/ On Tue, Jan 5, 2021 at 11:23 AM Erik Olof Gunnar Andersson > wrote: Yea - tested locally as well and wasn't able to reproduce it either. I changed the health service job to run every second and maxed out at about 42 connections to RabbitMQ with two conductor workers. /etc/magnum/magnun.conf [conductor] workers = 2 ________________________________ From: Spyros Trigazis > Sent: Tuesday, January 5, 2021 12:59 AM To: Ionut Biru > Cc: Erik Olof Gunnar Andersson >; feilong >; openstack-discuss > Subject: Re: [magnum][api] Error system library fopen too many open files with magnum-auto-healer On Tue, Jan 5, 2021 at 9:36 AM Ionut Biru > wrote: Hi, I tried with process=1 and it reached 1016 connections to rabbitmq. lsof https://paste.xinu.at/jGg/ i think it goes into error when it reaches 1024 file descriptors. I'm out of ideas of how to resolve this. I only have 3 clusters available and it's kinda weird and It doesn't scale. No issues here with 100s of clusters. Not sure what doesn't scale. * Maybe your rabbit is flooded with notifications that are not consumed? * You can use way more than 1024 file descriptors, maybe 2^10? Spyros On Mon, Jan 4, 2021 at 9:53 PM Erik Olof Gunnar Andersson > wrote: Sure looks like RabbitMQ. How many workers do have you configured? Could you try to changing the uwsgi configuration to workers=1 (or processes=1) and then see if it goes beyond 30 connections to amqp. From: Ionut Biru > Sent: Monday, January 4, 2021 4:07 AM To: Erik Olof Gunnar Andersson > Cc: feilong >; openstack-discuss > Subject: Re: [magnum][api] Error system library fopen too many open files with magnum-auto-healer Hi Erik, Here is lsof of one uwsgi api. https://paste.xinu.at/5YUWf/ I have kubernetes 12.0.1 installed in env. On Sun, Jan 3, 2021 at 3:06 AM Erik Olof Gunnar Andersson > wrote: Maybe something similar to this? https://github.com/kubernetes-client/python/issues/1158 What does lsof say? -- Ionut Biru - https://fleio.com -- Ionut Biru - https://fleio.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From cjeanner at redhat.com Tue Jan 5 10:48:09 2021 From: cjeanner at redhat.com (=?UTF-8?Q?C=c3=a9dric_Jeanneret?=) Date: Tue, 5 Jan 2021 11:48:09 +0100 Subject: [tripleo] Package dependencies, podman, dnf modules In-Reply-To: References: <6ab7507a-b5b8-c124-3e04-c3d410de6ff7@redhat.com> Message-ID: <2f0efe53-be85-b9d7-4f77-68b665cb50b5@redhat.com> On 1/5/21 9:56 AM, Marios Andreou wrote: > > > On Tue, Jan 5, 2021 at 9:44 AM Cédric Jeanneret > wrote: > > Hello there, > > Since we introduced Podman instead of Docker in tripleo, we are running > after the right version. > For now, the version we should use is provided by a specific > container-tools module stream (container-tools:2.0). The default stream > being container-tools:rhel8, we might end with a deployed undercloud > running the wrong podman version, leading to some nice issues, > especially in a SELinux-enabled environment. > > > o/ Tengu thanks for socialising that issue, it's a fun one for sure... > > first question is _where_ is that the default and it is mostly > rhetorical as I can guess. In general though i think it's worth filing a > LP bug with some of these details so we can also track whatever is > decided as a fix here. Right - always hard to find the right starting point ;). Though a mail would be a nice thing in order to get directions/ideas - and, hey, you just pointed some already! Here's the LP: https://bugs.launchpad.net/tripleo/+bug/1910217 > > > Currently, the main dependency tree is: > python3-tripleoclient requires podman > That's mostly all. > > While we can, of course, edit the python3-tripleoclient spec file in > order to pin the precise podman version (or, at least, set upper and > lower constraints) in order to target the version provided by the right > stream, it's not ideal: > - package install error will lead to more questions (since ppl might > skip doc for #reason) > - if we change the target version, we'll need to ensure it's present in > a stream (and, well, update the doc if we need to switch the stream) > - and probably some other reasons. > > Since we can NOT depend on a specific stream in rpm (for instance, we > can't put "Requires @container-tools:2.0/podman" like we might in > ansible), we're a bit stuck. > > An ugly hack is tested in the spec file[1], using a bash thing in order > to check the activated stream, but this is not ideal either, especially > since it makes the whole package building/checking fail during the > "mock" stage. In order to make it pass, we'd need to modify the whole > RDO in order to take into account stream switching. This isn't > impossible, but it leads to other concerns, especially when it comes to > "hey we need to switch the stream for ". And I'm pretty sure no > one will want to dig into it, for good reasons ;). > > This leads to a last possibility: > drop the "Requires podman" from tripleo dependency tree, and rely on > > > so how does that work in practice though I mean what about > python-tripleoclient. Quick grep just now tells me at least the > heat-launcher is directly using podman. How do we drop that requirement. Good catch. Maybe by ordering a bit things and calling the podman install bit before calling the heat-launcher? Might be ugly and, well, against some of the common practices, but at least it would ensure we get what we actually want regarding versions and sources. >   > > tripleo-ansible to actually enable the correct module, and install > podman. > This means podman will be installed during the undercloud deploy, for > instance as a host_prep_tasks (step_0). > > > I am missing how using tripleo-ansible helps us with the stream > question. Do you mean add logic in tripleo-ansible that tests the stream > and sets the correct version ? exactly. Ansible is able to switch module streams, and install packages. Basically, we'd "just" need to extend a bit this role/task: https://opendev.org/openstack/tripleo-ansible/src/branch/master/tripleo_ansible/roles/tripleo_podman/tasks/tripleo_podman_install.yml That would make things cleaner, nicer, and more reliable. > > While I'm not that happy with this idea, it's probably not as bad as the > other hacks we've tested so far, and would, at last, prevent once for > all the usual "it's not working" due to a wrong podman version (and, > yes, we get plenty of them, especially in the OSP version). > > What do you think? Any other way of solving this issue? Remember, we're > talking about "ensuring we get the right version, coming from a specific > stream" and, especially, "ensure operator can't install the wrong one" > (if they don't follow the doc, of if they are using automation that > doesn't check actual requirements in the doc"... > > > in general i lean more towards 'ansible tasks' rather than 'bash thing > in the specfile' to solve that. Either way though this is us reacting > (with some fix/hack/workaround) to a problem that isn't anything to do > with TripleO or even OpenStack but rather an OS/packaging issue. So do > we have any longer term plans on what you mentioned on IRC just now > regarding  getting module support for RPM deps (do you mean something in > the spec file here?) or is that a complete dead end? AFAIK, module support within RPM spec file as a standard thing is not in the roadmap. Apparently, the ppl behind this "module" concept aren't willing to add any sort of support. I've worked with Lon (Red Hat side) for the patch in the spec file, we've tried multiple ways and, well...... it's really not something I'm happy with. One idea I just got was about rpm hooks - iirc there's a thing in dnf that might help, have to read some more things about that. But I have the feeling this is still the wrong way - unless it's considered as a "last security net just to be really-really sure", instead of the current usage we have (which is, basically, ensure ppl do read the doc and follow it). So the main thing: it's not a TripleO issue per se - we're just using a feature that has a weak support in some cases, and, well, we happen to hit one of those cases. As usuall I'd say ;). Cheers, C. > > thanks, marios > > > Thank you for your thoughts! > > Cheers, > > C. > > > [1] https://review.rdoproject.org/r/#/c/31411/ > > > > -- > Cédric Jeanneret (He/Him/His) > Sr. Software Engineer - OpenStack Platform > Deployment Framework TC > Red Hat EMEA > https://www.redhat.com/ > -- Cédric Jeanneret (He/Him/His) Sr. Software Engineer - OpenStack Platform Deployment Framework TC Red Hat EMEA https://www.redhat.com/ -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature Type: application/pgp-signature Size: 840 bytes Desc: OpenPGP digital signature URL: From cjeanner at redhat.com Tue Jan 5 11:02:52 2021 From: cjeanner at redhat.com (=?UTF-8?Q?C=c3=a9dric_Jeanneret?=) Date: Tue, 5 Jan 2021 12:02:52 +0100 Subject: [tripleo] Package dependencies, podman, dnf modules In-Reply-To: <2f0efe53-be85-b9d7-4f77-68b665cb50b5@redhat.com> References: <6ab7507a-b5b8-c124-3e04-c3d410de6ff7@redhat.com> <2f0efe53-be85-b9d7-4f77-68b665cb50b5@redhat.com> Message-ID: <11ff7da7-e6ec-ceff-06f1-90ea6f8e7305@redhat.com> On 1/5/21 11:48 AM, Cédric Jeanneret wrote: > > > On 1/5/21 9:56 AM, Marios Andreou wrote: >> >> >> On Tue, Jan 5, 2021 at 9:44 AM Cédric Jeanneret > > wrote: >> >> Hello there, >> >> Since we introduced Podman instead of Docker in tripleo, we are running >> after the right version. >> For now, the version we should use is provided by a specific >> container-tools module stream (container-tools:2.0). The default stream >> being container-tools:rhel8, we might end with a deployed undercloud >> running the wrong podman version, leading to some nice issues, >> especially in a SELinux-enabled environment. >> >> >> o/ Tengu thanks for socialising that issue, it's a fun one for sure... >> >> first question is _where_ is that the default and it is mostly >> rhetorical as I can guess. In general though i think it's worth filing a >> LP bug with some of these details so we can also track whatever is >> decided as a fix here. > > Right - always hard to find the right starting point ;). Though a mail > would be a nice thing in order to get directions/ideas - and, hey, you > just pointed some already! > Here's the LP: > https://bugs.launchpad.net/tripleo/+bug/1910217 > >> >> >> Currently, the main dependency tree is: >> python3-tripleoclient requires podman >> That's mostly all. >> >> While we can, of course, edit the python3-tripleoclient spec file in >> order to pin the precise podman version (or, at least, set upper and >> lower constraints) in order to target the version provided by the right >> stream, it's not ideal: >> - package install error will lead to more questions (since ppl might >> skip doc for #reason) >> - if we change the target version, we'll need to ensure it's present in >> a stream (and, well, update the doc if we need to switch the stream) >> - and probably some other reasons. >> >> Since we can NOT depend on a specific stream in rpm (for instance, we >> can't put "Requires @container-tools:2.0/podman" like we might in >> ansible), we're a bit stuck. >> >> An ugly hack is tested in the spec file[1], using a bash thing in order >> to check the activated stream, but this is not ideal either, especially >> since it makes the whole package building/checking fail during the >> "mock" stage. In order to make it pass, we'd need to modify the whole >> RDO in order to take into account stream switching. This isn't >> impossible, but it leads to other concerns, especially when it comes to >> "hey we need to switch the stream for ". And I'm pretty sure no >> one will want to dig into it, for good reasons ;). >> >> This leads to a last possibility: >> drop the "Requires podman" from tripleo dependency tree, and rely on >> >> >> so how does that work in practice though I mean what about >> python-tripleoclient. Quick grep just now tells me at least the >> heat-launcher is directly using podman. How do we drop that requirement. > > Good catch. Maybe by ordering a bit things and calling the podman > install bit before calling the heat-launcher? Might be ugly and, well, > against some of the common practices, but at least it would ensure we > get what we actually want regarding versions and sources. > >>   >> >> tripleo-ansible to actually enable the correct module, and install >> podman. >> This means podman will be installed during the undercloud deploy, for >> instance as a host_prep_tasks (step_0). >> >> >> I am missing how using tripleo-ansible helps us with the stream >> question. Do you mean add logic in tripleo-ansible that tests the stream >> and sets the correct version ? > > exactly. Ansible is able to switch module streams, and install packages. > Basically, we'd "just" need to extend a bit this role/task: > https://opendev.org/openstack/tripleo-ansible/src/branch/master/tripleo_ansible/roles/tripleo_podman/tasks/tripleo_podman_install.yml > > That would make things cleaner, nicer, and more reliable. Maybe we can keep the dependency as-is, and "just" ensure tripleo-ansible "tripleo_podman" role sets the right things during the deploy time? For instance, we can add a task ensuring we're using the right stream, then install podman (and buildah). That means heat-launcher might use the wrong podman version (bleh...) but the finished undercloud should be fine? Not 100% sure it's really possible, especially since module switching might fail under some conditions when a package is installed :/. Guess some testing will be needed as well. > > >> >> While I'm not that happy with this idea, it's probably not as bad as the >> other hacks we've tested so far, and would, at last, prevent once for >> all the usual "it's not working" due to a wrong podman version (and, >> yes, we get plenty of them, especially in the OSP version). >> >> What do you think? Any other way of solving this issue? Remember, we're >> talking about "ensuring we get the right version, coming from a specific >> stream" and, especially, "ensure operator can't install the wrong one" >> (if they don't follow the doc, of if they are using automation that >> doesn't check actual requirements in the doc"... >> >> >> in general i lean more towards 'ansible tasks' rather than 'bash thing >> in the specfile' to solve that. Either way though this is us reacting >> (with some fix/hack/workaround) to a problem that isn't anything to do >> with TripleO or even OpenStack but rather an OS/packaging issue. So do >> we have any longer term plans on what you mentioned on IRC just now >> regarding  getting module support for RPM deps (do you mean something in >> the spec file here?) or is that a complete dead end? > > AFAIK, module support within RPM spec file as a standard thing is not in > the roadmap. Apparently, the ppl behind this "module" concept aren't > willing to add any sort of support. > I've worked with Lon (Red Hat side) for the patch in the spec file, > we've tried multiple ways and, well...... it's really not something I'm > happy with. One idea I just got was about rpm hooks - iirc there's a > thing in dnf that might help, have to read some more things about that. > But I have the feeling this is still the wrong way - unless it's > considered as a "last security net just to be really-really sure", > instead of the current usage we have (which is, basically, ensure ppl do > read the doc and follow it). > > So the main thing: it's not a TripleO issue per se - we're just using a > feature that has a weak support in some cases, and, well, we happen to > hit one of those cases. As usuall I'd say ;). > > Cheers, > > C. > >> >> thanks, marios >> >> >> Thank you for your thoughts! >> >> Cheers, >> >> C. >> >> >> [1] https://review.rdoproject.org/r/#/c/31411/ >> >> >> >> -- >> Cédric Jeanneret (He/Him/His) >> Sr. Software Engineer - OpenStack Platform >> Deployment Framework TC >> Red Hat EMEA >> https://www.redhat.com/ >> > -- Cédric Jeanneret (He/Him/His) Sr. Software Engineer - OpenStack Platform Deployment Framework TC Red Hat EMEA https://www.redhat.com/ -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature Type: application/pgp-signature Size: 840 bytes Desc: OpenPGP digital signature URL: From chacon.piza at gmail.com Tue Jan 5 11:05:28 2021 From: chacon.piza at gmail.com (Martin Chacon Piza) Date: Tue, 5 Jan 2021 12:05:28 +0100 Subject: [release] Status: RED - pip resolver issue with publish-openstack-releasenotes-python3 In-Reply-To: References: Message-ID: Hi Herve, I have added this topic to the Monasca irc meeting today. Thank you, Martin (chaconpiza) El lun, 4 de ene. de 2021 a la(s) 18:30, Herve Beraud (hberaud at redhat.com) escribió: > Thanks all! > > Here we can track our advancement: > > https://review.opendev.org/q/topic:%22fix-relmgt-pip-doc%22+(status:open%20OR%20status:merged) > > Le lun. 4 janv. 2021 à 18:02, Radosław Piliszek < > radoslaw.piliszek at gmail.com> a écrit : > >> On Mon, Jan 4, 2021 at 4:34 PM Herve Beraud wrote: >> > >> > Here is the filtered list of projects that meet the conditions leading >> to the bug, and who should be fixed to completely solve our issue: >> > >> > ... >> > etcd3gw >> > ... >> > python-masakariclient >> > ... >> > >> > Notice that some of these projects aren't deliverables but if possible >> it could be worth fixing them too. >> > >> > These projects have an incompatibility between entries in their >> test-requirements.txt, and they're missing a doc/requirements.txt file. >> > >> > The more straightforward path to unlock our job >> "publish-openstack-releasenotes-python3" is to create a >> doc/requirements.txt file that only contains the needed dependencies to >> reduce the possibility of pip resolver issues. I personally think that we >> could use the latest allowed version of requirements (sphinx, reno, etc...). >> > >> > I propose to track the related advancement by using the >> "fix-relmgt-pip-doc" gerrit topic, when all the projects will be fixed we >> would be able to update our status. >> > >> > Also it could be worth fixing test-requirements.txt incompatibilities >> but this task is more on the projects teams sides and this task could be >> done with a follow up patch. >> > >> > Thoughts? >> >> Thanks, Hervé! >> >> Done for python-masakariclient in [1]. >> >> etcd3gw needs more love in general but I will have this split in mind. >> >> [1] https://review.opendev.org/c/openstack/python-masakariclient/+/769163 >> >> -yoctozepto >> >> > > -- > Hervé Beraud > Senior Software Engineer at Red Hat > irc: hberaud > https://github.com/4383/ > https://twitter.com/4383hberaud > -----BEGIN PGP SIGNATURE----- > > wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ > Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ > RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP > F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G > 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g > glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw > m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ > hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 > qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y > F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 > B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O > v6rDpkeNksZ9fFSyoY2o > =ECSj > -----END PGP SIGNATURE----- > > -- *Martín Chacón Pizá* *chacon.piza at gmail.com * -------------- next part -------------- An HTML attachment was scrubbed... URL: From bdobreli at redhat.com Tue Jan 5 11:45:24 2021 From: bdobreli at redhat.com (Bogdan Dobrelya) Date: Tue, 5 Jan 2021 12:45:24 +0100 Subject: [tripleo] Package dependencies, podman, dnf modules In-Reply-To: <11ff7da7-e6ec-ceff-06f1-90ea6f8e7305@redhat.com> References: <6ab7507a-b5b8-c124-3e04-c3d410de6ff7@redhat.com> <2f0efe53-be85-b9d7-4f77-68b665cb50b5@redhat.com> <11ff7da7-e6ec-ceff-06f1-90ea6f8e7305@redhat.com> Message-ID: <6495030f-0af7-f68e-23a6-5f72f469fabb@redhat.com> On 1/5/21 12:02 PM, Cédric Jeanneret wrote: > > > On 1/5/21 11:48 AM, Cédric Jeanneret wrote: >> >> >> On 1/5/21 9:56 AM, Marios Andreou wrote: >>> >>> >>> On Tue, Jan 5, 2021 at 9:44 AM Cédric Jeanneret >> > wrote: >>> >>> Hello there, >>> >>> Since we introduced Podman instead of Docker in tripleo, we are running >>> after the right version. >>> For now, the version we should use is provided by a specific >>> container-tools module stream (container-tools:2.0). The default stream >>> being container-tools:rhel8, we might end with a deployed undercloud >>> running the wrong podman version, leading to some nice issues, >>> especially in a SELinux-enabled environment. >>> >>> >>> o/ Tengu thanks for socialising that issue, it's a fun one for sure... >>> >>> first question is _where_ is that the default and it is mostly >>> rhetorical as I can guess. In general though i think it's worth filing a >>> LP bug with some of these details so we can also track whatever is >>> decided as a fix here. >> >> Right - always hard to find the right starting point ;). Though a mail >> would be a nice thing in order to get directions/ideas - and, hey, you >> just pointed some already! >> Here's the LP: >> https://bugs.launchpad.net/tripleo/+bug/1910217 >> >>> >>> >>> Currently, the main dependency tree is: >>> python3-tripleoclient requires podman >>> That's mostly all. >>> >>> While we can, of course, edit the python3-tripleoclient spec file in >>> order to pin the precise podman version (or, at least, set upper and >>> lower constraints) in order to target the version provided by the right >>> stream, it's not ideal: >>> - package install error will lead to more questions (since ppl might >>> skip doc for #reason) >>> - if we change the target version, we'll need to ensure it's present in >>> a stream (and, well, update the doc if we need to switch the stream) >>> - and probably some other reasons. >>> >>> Since we can NOT depend on a specific stream in rpm (for instance, we >>> can't put "Requires @container-tools:2.0/podman" like we might in >>> ansible), we're a bit stuck. >>> >>> An ugly hack is tested in the spec file[1], using a bash thing in order >>> to check the activated stream, but this is not ideal either, especially >>> since it makes the whole package building/checking fail during the >>> "mock" stage. In order to make it pass, we'd need to modify the whole >>> RDO in order to take into account stream switching. This isn't >>> impossible, but it leads to other concerns, especially when it comes to >>> "hey we need to switch the stream for ". And I'm pretty sure no >>> one will want to dig into it, for good reasons ;). >>> >>> This leads to a last possibility: >>> drop the "Requires podman" from tripleo dependency tree, and rely on >>> >>> >>> so how does that work in practice though I mean what about >>> python-tripleoclient. Quick grep just now tells me at least the >>> heat-launcher is directly using podman. How do we drop that requirement. >> >> Good catch. Maybe by ordering a bit things and calling the podman >> install bit before calling the heat-launcher? Might be ugly and, well, >> against some of the common practices, but at least it would ensure we >> get what we actually want regarding versions and sources. >> >>> >>> >>> tripleo-ansible to actually enable the correct module, and install >>> podman. >>> This means podman will be installed during the undercloud deploy, for >>> instance as a host_prep_tasks (step_0). >>> >>> >>> I am missing how using tripleo-ansible helps us with the stream >>> question. Do you mean add logic in tripleo-ansible that tests the stream >>> and sets the correct version ? >> >> exactly. Ansible is able to switch module streams, and install packages. >> Basically, we'd "just" need to extend a bit this role/task: >> https://opendev.org/openstack/tripleo-ansible/src/branch/master/tripleo_ansible/roles/tripleo_podman/tasks/tripleo_podman_install.yml >> >> That would make things cleaner, nicer, and more reliable. > > Maybe we can keep the dependency as-is, and "just" ensure > tripleo-ansible "tripleo_podman" role sets the right things during the > deploy time? > For instance, we can add a task ensuring we're using the right stream, > then install podman (and buildah). That means heat-launcher might use > the wrong podman version (bleh...) but the finished undercloud should be > fine? Not 100% sure it's really possible, especially since module > switching might fail under some conditions when a package is installed :/. I propose to use in RPM specs Requires: podman Conflicts: podman < some_lower_constraint_version that would allow to fail early if, a wrong version is going to be installed via existing repos and streams. And failing early is much better than waiting up to the moment it starts running ansible IMHO. And at that later point it would only re-ensure the wanted version. > > Guess some testing will be needed as well. > > >> >> >>> >>> While I'm not that happy with this idea, it's probably not as bad as the >>> other hacks we've tested so far, and would, at last, prevent once for >>> all the usual "it's not working" due to a wrong podman version (and, >>> yes, we get plenty of them, especially in the OSP version). >>> >>> What do you think? Any other way of solving this issue? Remember, we're >>> talking about "ensuring we get the right version, coming from a specific >>> stream" and, especially, "ensure operator can't install the wrong one" >>> (if they don't follow the doc, of if they are using automation that >>> doesn't check actual requirements in the doc"... >>> >>> >>> in general i lean more towards 'ansible tasks' rather than 'bash thing >>> in the specfile' to solve that. Either way though this is us reacting >>> (with some fix/hack/workaround) to a problem that isn't anything to do >>> with TripleO or even OpenStack but rather an OS/packaging issue. So do >>> we have any longer term plans on what you mentioned on IRC just now >>> regarding  getting module support for RPM deps (do you mean something in >>> the spec file here?) or is that a complete dead end? >> >> AFAIK, module support within RPM spec file as a standard thing is not in >> the roadmap. Apparently, the ppl behind this "module" concept aren't >> willing to add any sort of support. >> I've worked with Lon (Red Hat side) for the patch in the spec file, >> we've tried multiple ways and, well...... it's really not something I'm >> happy with. One idea I just got was about rpm hooks - iirc there's a >> thing in dnf that might help, have to read some more things about that. >> But I have the feeling this is still the wrong way - unless it's >> considered as a "last security net just to be really-really sure", >> instead of the current usage we have (which is, basically, ensure ppl do >> read the doc and follow it). >> >> So the main thing: it's not a TripleO issue per se - we're just using a >> feature that has a weak support in some cases, and, well, we happen to >> hit one of those cases. As usuall I'd say ;). >> >> Cheers, >> >> C. >> >>> >>> thanks, marios >>> >>> >>> Thank you for your thoughts! >>> >>> Cheers, >>> >>> C. >>> >>> >>> [1] https://review.rdoproject.org/r/#/c/31411/ >>> >>> >>> >>> -- >>> Cédric Jeanneret (He/Him/His) >>> Sr. Software Engineer - OpenStack Platform >>> Deployment Framework TC >>> Red Hat EMEA >>> https://www.redhat.com/ >>> >> > -- Best regards, Bogdan Dobrelya, Irc #bogdando From cjeanner at redhat.com Tue Jan 5 12:33:01 2021 From: cjeanner at redhat.com (=?UTF-8?Q?C=c3=a9dric_Jeanneret?=) Date: Tue, 5 Jan 2021 13:33:01 +0100 Subject: [tripleo] Package dependencies, podman, dnf modules In-Reply-To: <6495030f-0af7-f68e-23a6-5f72f469fabb@redhat.com> References: <6ab7507a-b5b8-c124-3e04-c3d410de6ff7@redhat.com> <2f0efe53-be85-b9d7-4f77-68b665cb50b5@redhat.com> <11ff7da7-e6ec-ceff-06f1-90ea6f8e7305@redhat.com> <6495030f-0af7-f68e-23a6-5f72f469fabb@redhat.com> Message-ID: <59ffb8f5-d0a9-3fd6-1e12-dd72e8a8f2a4@redhat.com> On 1/5/21 12:45 PM, Bogdan Dobrelya wrote: > On 1/5/21 12:02 PM, Cédric Jeanneret wrote: >> >> >> On 1/5/21 11:48 AM, Cédric Jeanneret wrote: >>> >>> >>> On 1/5/21 9:56 AM, Marios Andreou wrote: >>>> >>>> >>>> On Tue, Jan 5, 2021 at 9:44 AM Cédric Jeanneret >>> > wrote: >>>> >>>>      Hello there, >>>> >>>>      Since we introduced Podman instead of Docker in tripleo, we are >>>> running >>>>      after the right version. >>>>      For now, the version we should use is provided by a specific >>>>      container-tools module stream (container-tools:2.0). The >>>> default stream >>>>      being container-tools:rhel8, we might end with a deployed >>>> undercloud >>>>      running the wrong podman version, leading to some nice issues, >>>>      especially in a SELinux-enabled environment. >>>> >>>> >>>> o/ Tengu thanks for socialising that issue, it's a fun one for sure... >>>> >>>> first question is _where_ is that the default and it is mostly >>>> rhetorical as I can guess. In general though i think it's worth >>>> filing a >>>> LP bug with some of these details so we can also track whatever is >>>> decided as a fix here. >>> >>> Right - always hard to find the right starting point ;). Though a mail >>> would be a nice thing in order to get directions/ideas - and, hey, you >>> just pointed some already! >>> Here's the LP: >>> https://bugs.launchpad.net/tripleo/+bug/1910217 >>> >>>> >>>> >>>>      Currently, the main dependency tree is: >>>>      python3-tripleoclient requires podman >>>>      That's mostly all. >>>> >>>>      While we can, of course, edit the python3-tripleoclient spec >>>> file in >>>>      order to pin the precise podman version (or, at least, set >>>> upper and >>>>      lower constraints) in order to target the version provided by >>>> the right >>>>      stream, it's not ideal: >>>>      - package install error will lead to more questions (since ppl >>>> might >>>>      skip doc for #reason) >>>>      - if we change the target version, we'll need to ensure it's >>>> present in >>>>      a stream (and, well, update the doc if we need to switch the >>>> stream) >>>>      - and probably some other reasons. >>>> >>>>      Since we can NOT depend on a specific stream in rpm (for >>>> instance, we >>>>      can't put "Requires @container-tools:2.0/podman" like we might in >>>>      ansible), we're a bit stuck. >>>> >>>>      An ugly hack is tested in the spec file[1], using a bash thing >>>> in order >>>>      to check the activated stream, but this is not ideal either, >>>> especially >>>>      since it makes the whole package building/checking fail during the >>>>      "mock" stage. In order to make it pass, we'd need to modify the >>>> whole >>>>      RDO in order to take into account stream switching. This isn't >>>>      impossible, but it leads to other concerns, especially when it >>>> comes to >>>>      "hey we need to switch the stream for ". And I'm pretty >>>> sure no >>>>      one will want to dig into it, for good reasons ;). >>>> >>>>      This leads to a last possibility: >>>>      drop the "Requires podman" from tripleo dependency tree, and >>>> rely on >>>> >>>> >>>> so how does that work in practice though I mean what about >>>> python-tripleoclient. Quick grep just now tells me at least the >>>> heat-launcher is directly using podman. How do we drop that >>>> requirement. >>> >>> Good catch. Maybe by ordering a bit things and calling the podman >>> install bit before calling the heat-launcher? Might be ugly and, well, >>> against some of the common practices, but at least it would ensure we >>> get what we actually want regarding versions and sources. >>> >>>>   >>>>      tripleo-ansible to actually enable the correct module, and install >>>>      podman. >>>>      This means podman will be installed during the undercloud >>>> deploy, for >>>>      instance as a host_prep_tasks (step_0). >>>> >>>> >>>> I am missing how using tripleo-ansible helps us with the stream >>>> question. Do you mean add logic in tripleo-ansible that tests the >>>> stream >>>> and sets the correct version ? >>> >>> exactly. Ansible is able to switch module streams, and install packages. >>> Basically, we'd "just" need to extend a bit this role/task: >>> https://opendev.org/openstack/tripleo-ansible/src/branch/master/tripleo_ansible/roles/tripleo_podman/tasks/tripleo_podman_install.yml >>> >>> >>> That would make things cleaner, nicer, and more reliable. >> >> Maybe we can keep the dependency as-is, and "just" ensure >> tripleo-ansible "tripleo_podman" role sets the right things during the >> deploy time? >> For instance, we can add a task ensuring we're using the right stream, >> then install podman (and buildah). That means heat-launcher might use >> the wrong podman version (bleh...) but the finished undercloud should be >> fine? Not 100% sure it's really possible, especially since module >> switching might fail under some conditions when a package is installed >> :/. > > I propose to use in RPM specs > > Requires: podman > Conflicts: podman < some_lower_constraint_version > > that would allow to fail early if, a wrong version is going to be > installed via existing repos and streams. And failing early is much > better than waiting up to the moment it starts running ansible IMHO. And > at that later point it would only re-ensure the wanted version. We'll need to set an upper constraint - in some conditions, the default version is newer than the one we actually want. This is already done, more or less, downstream with an OSP specific package. While it sounds appealing, I still see issues when it comes to version changes. I'd rather ensure we have the proper stream activated, especially since your proposal will lead to more LP/BZ being opened by ppl that don't read the doc© - resulting in endless bounces and more complains about the non-user-friendliness of this approach :(. Ah, also.... we seem to have the same kind of constrain with some "virt" module - default is "rhel" but we apparently need another one (iirc "8") - though this seems to be downstream-only, and only for the overcloud (or standalone)... So the issue isn't "just" for podman, and a better, generic thing would be really nice :). Cheers, C. > >> >> Guess some testing will be needed as well. >> >> >>> >>> >>>> >>>>      While I'm not that happy with this idea, it's probably not as >>>> bad as the >>>>      other hacks we've tested so far, and would, at last, prevent >>>> once for >>>>      all the usual "it's not working" due to a wrong podman version >>>> (and, >>>>      yes, we get plenty of them, especially in the OSP version). >>>> >>>>      What do you think? Any other way of solving this issue? >>>> Remember, we're >>>>      talking about "ensuring we get the right version, coming from a >>>> specific >>>>      stream" and, especially, "ensure operator can't install the >>>> wrong one" >>>>      (if they don't follow the doc, of if they are using automation >>>> that >>>>      doesn't check actual requirements in the doc"... >>>> >>>> >>>> in general i lean more towards 'ansible tasks' rather than 'bash thing >>>> in the specfile' to solve that. Either way though this is us reacting >>>> (with some fix/hack/workaround) to a problem that isn't anything to do >>>> with TripleO or even OpenStack but rather an OS/packaging issue. So do >>>> we have any longer term plans on what you mentioned on IRC just now >>>> regarding  getting module support for RPM deps (do you mean >>>> something in >>>> the spec file here?) or is that a complete dead end? >>> >>> AFAIK, module support within RPM spec file as a standard thing is not in >>> the roadmap. Apparently, the ppl behind this "module" concept aren't >>> willing to add any sort of support. >>> I've worked with Lon (Red Hat side) for the patch in the spec file, >>> we've tried multiple ways and, well...... it's really not something I'm >>> happy with. One idea I just got was about rpm hooks - iirc there's a >>> thing in dnf that might help, have to read some more things about that. >>> But I have the feeling this is still the wrong way - unless it's >>> considered as a "last security net just to be really-really sure", >>> instead of the current usage we have (which is, basically, ensure ppl do >>> read the doc and follow it). >>> >>> So the main thing: it's not a TripleO issue per se - we're just using a >>> feature that has a weak support in some cases, and, well, we happen to >>> hit one of those cases. As usuall I'd say ;). >>> >>> Cheers, >>> >>> C. >>> >>>> >>>> thanks, marios >>>> >>>> >>>>      Thank you for your thoughts! >>>> >>>>      Cheers, >>>> >>>>      C. >>>> >>>> >>>>      [1] https://review.rdoproject.org/r/#/c/31411/ >>>>      >>>> >>>> >>>>      -- >>>>      Cédric Jeanneret (He/Him/His) >>>>      Sr. Software Engineer - OpenStack Platform >>>>      Deployment Framework TC >>>>      Red Hat EMEA >>>>      https://www.redhat.com/ >>>> >>> >> > > -- Cédric Jeanneret (He/Him/His) Sr. Software Engineer - OpenStack Platform Deployment Framework TC Red Hat EMEA https://www.redhat.com/ -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature Type: application/pgp-signature Size: 840 bytes Desc: OpenPGP digital signature URL: From mkopec at redhat.com Tue Jan 5 14:25:05 2021 From: mkopec at redhat.com (Martin Kopec) Date: Tue, 5 Jan 2021 15:25:05 +0100 Subject: [qa][tempest] Update language in tempest code base In-Reply-To: <175fbcdda1f.11b0cc28f634324.3835419687523632284@ghanshyammann.com> References: <173344b91ec.122943da3630997.4524106110681904507@ghanshyammann.com> <2383106.3VsfAaAtOV@whitebase.usersys.redhat.com> <173348b1df7.b5898c11633886.9175405555090897907@ghanshyammann.com> <175fbcdda1f.11b0cc28f634324.3835419687523632284@ghanshyammann.com> Message-ID: Hi, following the stestr's example I proposed a change in Tempest: https://review.opendev.org/c/openstack/tempest/+/768583 Feel free to review and comment. See also other proposed changes by following the 'inclusive_jargon' topic: https://review.opendev.org/q/topic:inclusive_jargon+(status:open OR status:merged) Kind regards, On Tue, 24 Nov 2020 at 20:56, Ghanshyam Mann wrote: > ---- On Tue, 24 Nov 2020 12:58:47 -0600 Matthew Treinish < > mtreinish at kortar.org> wrote ---- > > On Thu, Jul 09, 2020 at 12:06:39PM -0500, Ghanshyam Mann wrote: > > > ---- On Thu, 09 Jul 2020 11:45:19 -0500 Arx Cruz > wrote ---- > > > > Yes, that's the idea. > > > > We can keep the old interface for a few cycles, with warning > deprecation message advertising to use the new one, and then remove in the > future. > > > > > > Deprecating things leads to two situations which really need some > good reason before doing it: > > > > > > - If we keep the deprecated interfaces working along with new > interfaces then it is confusion for users > > > as well as maintenance effort. In my experience, very less migration > happen to new things if old keep working. > > > > Just a heads up the recent stestr 3.1.0 release > > (https://github.com/mtreinish/stestr/releases/tag/3.1.0) did this > first step > > and deprecated things with: > > > > https://github.com/mtreinish/stestr/pull/297 > > > > There were multiple recent user requests to start this process sooner > rather > > than later. So regardless of what timetable and decision we make for > tempest's > > interfaces we should probably update tempest's internal stestr api > usage to > > reflect the new interface sooner rather than later (it will require > bumping the > > min stestr version to 3.1.0 when that change is made). > > > > > - If we remove them in future then it is breaking change. > > > > For stestr my plan is to make this breaking change eventually as part > of 4.0.0 > > release. The exact timetable for that I'm not clear on yet since we try > to avoid > > making breaking changes. The previous 2 backwards incompatible changes > were > > removing python 2 support (which was 3.0.0) and switching to cliff for > the cli, > > which wasn't strictly backwards incompatible we just made it 2.0.0 as a > > precaution because there were potential edge cases with cliff we were > worried > > about. So there really isn't a established pattern for this kind of > deprecation > > removal. I don't expect it to be a quick process though. > > Thanks matt for the updates and providing new interfaces in stestr, It > will surely help Tempest to > move towards those new deprecate these interface/wording. As discussed in > PTG/Forum for > overall direction in OpenStack, I am ok to do similar changes in Tempest. > > For branchless Tempest, as you mentioned we need to bump the min stestr > version to 3.1.0 > for all supported stable branches which are stein onwards for now. Hope > that is fine from a requirement > perspective. > > We can move Tempest to new stestr 3.1.0 soon and project side usage of > stestr in unit/functional > tests runner is also not much. Seems only two repo: > - > https://codesearch.opendev.org/?q=stestr%20run%20--black&i=nope&files=tox.ini&excludeFiles=&repos= > > -gmann > > > > > > > -Matt Treinish > > > > > IMO, we need to first ask/analyse whether name changes are worth to > do with above things as results. Or in other > > > team we should first define what is 'outdated naming conventions' and > how worth to fix those. > > > > > > -gmann > > > > > > > > > > Kind regards, > > > > > > > > On Thu, Jul 9, 2020 at 6:15 PM Luigi Toscano > wrote: > > > > > > > > > > > > -- > > > > Arx Cruz > > > > Software Engineer > > > > Red Hat EMEA > > > > arxcruz at redhat.com > > > > > @RedHat > Red Hat Red Hat > > > > > On Thursday, 9 July 2020 17:57:14 CEST Ghanshyam Mann > wrote: > > > > > ---- On Thu, 09 Jul 2020 10:14:58 -0500 Arx Cruz < > arxcruz at redhat.com> wrote > > > > > ---- > > > > > > Hello, > > > > > > I would like to start a discussion regarding the topic. > > > > > > At this moment in time we have an opportunity to be a more > open and > > > > > > inclusive project by eliminating outdated naming conventions > from > > > > > > tempest codebase, such as blacklist, whitelist.We should take > the > > > > > > opportunity and do our best to replace outdated terms with > their more > > > > > > inclusive alternatives.As you can see in [1] the TripleO > project is > > > > > > already working on this initiative, and I would like to work > on this as > > > > > > well on the tempest side. > > > > > Thanks Arx for raising it. > > > > > > > > > > I always have hard time to understand the definition of > 'outdated naming > > > > > conventions ' are they outdated from coding language perspective > or > > > > > outdated as English language perspective? I do not see naming > used in > > > > > coding language should be matched with English as > grammar/outdated/new > > > > > style language. As long as they are not so bad (hurt anyone > culture, > > > > > abusing word etc) it is fine to keep them as it is and start > adopting new > > > > > names for new things we code. > > > > > > > > > > For me, naming convention are the things which always can be > improved over > > > > > time, none of the name is best suited for everyone in open > source. But we > > > > > need to understand whether it is worth to do in term of 1. > effort of > > > > > changing those 2. un- comfortness of adopting new names 3. again > changing > > > > > in future. > > > > > > > > > > At least from Tempest perspective, blacklist is very known > common word used > > > > > for lot of interfaces and dependent testing tool. I cannot > debate on how > > > > > good it is or bad but i can debate on not-worth to change now. > For new > > > > > interface, we can always use best-suggested name as per that > > > > > time/culture/maintainers. We have tried few of such improvement > in past but > > > > > end up not-successful. Example: - > > > > > > https://opendev.org/openstack/tempest/src/commit/e1eebfa8451d4c28bef0669e4a > > > > > 7f493b6086cab9/tempest/test.py#L43 > > > > > > > > > > > > > That's not the only used terminology for list of things, though. > We could > > > > always add new interfaces and keep the old ones are deprecated > (but not > > > > advertised) for the foreseable future. The old code won't be > broken and the > > > > new one would use the new terminology, I'd say it's a good > solution. > > > > > > > > > > > > -- > > > > Luigi > > > > > > > > > > > > > > > > > > > -- Martin Kopec Software Quality Engineer Red Hat EMEA -------------- next part -------------- An HTML attachment was scrubbed... URL: From aschultz at redhat.com Tue Jan 5 14:57:19 2021 From: aschultz at redhat.com (Alex Schultz) Date: Tue, 5 Jan 2021 07:57:19 -0700 Subject: [tripleo] Package dependencies, podman, dnf modules In-Reply-To: <6ab7507a-b5b8-c124-3e04-c3d410de6ff7@redhat.com> References: <6ab7507a-b5b8-c124-3e04-c3d410de6ff7@redhat.com> Message-ID: On Tue, Jan 5, 2021 at 12:53 AM Cédric Jeanneret wrote: > > Hello there, > > Since we introduced Podman instead of Docker in tripleo, we are running > after the right version. > For now, the version we should use is provided by a specific > container-tools module stream (container-tools:2.0). The default stream > being container-tools:rhel8, we might end with a deployed undercloud > running the wrong podman version, leading to some nice issues, > especially in a SELinux-enabled environment. > > Currently, the main dependency tree is: > python3-tripleoclient requires podman > That's mostly all. > > While we can, of course, edit the python3-tripleoclient spec file in > order to pin the precise podman version (or, at least, set upper and > lower constraints) in order to target the version provided by the right > stream, it's not ideal: > - package install error will lead to more questions (since ppl might > skip doc for #reason) > - if we change the target version, we'll need to ensure it's present in > a stream (and, well, update the doc if we need to switch the stream) > - and probably some other reasons. > So as mentioned we did this and it leads to poor UX because the conflict message doesn't help direct people to fixing their container-tools module. > Since we can NOT depend on a specific stream in rpm (for instance, we > can't put "Requires @container-tools:2.0/podman" like we might in > ansible), we're a bit stuck. > IMHO This really needs to be in the RPM spec ASAP to make modules viable in the long term but that's not an OpenStack issue. > An ugly hack is tested in the spec file[1], using a bash thing in order > to check the activated stream, but this is not ideal either, especially > since it makes the whole package building/checking fail during the > "mock" stage. In order to make it pass, we'd need to modify the whole > RDO in order to take into account stream switching. This isn't > impossible, but it leads to other concerns, especially when it comes to > "hey we need to switch the stream for ". And I'm pretty sure no > one will want to dig into it, for good reasons ;). > > This leads to a last possibility: > drop the "Requires podman" from tripleo dependency tree, and rely on > tripleo-ansible to actually enable the correct module, and install podman. > This means podman will be installed during the undercloud deploy, for > instance as a host_prep_tasks (step_0). > Since we may or may not consume podman in code we're packaging we likely should not drop the requirement. > While I'm not that happy with this idea, it's probably not as bad as the > other hacks we've tested so far, and would, at last, prevent once for > all the usual "it's not working" due to a wrong podman version (and, > yes, we get plenty of them, especially in the OSP version). > > What do you think? Any other way of solving this issue? Remember, we're > talking about "ensuring we get the right version, coming from a specific > stream" and, especially, "ensure operator can't install the wrong one" > (if they don't follow the doc, of if they are using automation that > doesn't check actual requirements in the doc"... > IMHO, as mentioned on IRC, we need to improve the initial setup process to reduce the likelihood of a misconfiguration. I had chatted with the CI folks on the best way to solve this in a single place that would be useful for users and in CI. We generally agreed to combine the efforts into tripleo-repos because it can be installed independently of everything else and can be a single source of truth for version info. I proposed a WIP for a version information structure so we can have a single source of truth for repo and version information. https://review.opendev.org/c/openstack/tripleo-repos/+/767214 Today we require the user to manually setup repositories and module versions prior to installing the packages. I think it's best if we work on reducing the errors that occur during this process. We could add something into the validation bits, but we will still need a single source of truth for the required versions so we're not duplicating the version information. Thanks, -Alex > Thank you for your thoughts! > > Cheers, > > C. > > > [1] https://review.rdoproject.org/r/#/c/31411/ > > > -- > Cédric Jeanneret (He/Him/His) > Sr. Software Engineer - OpenStack Platform > Deployment Framework TC > Red Hat EMEA > https://www.redhat.com/ > From knikolla at bu.edu Tue Jan 5 15:15:51 2021 From: knikolla at bu.edu (Nikolla, Kristi) Date: Tue, 5 Jan 2021 15:15:51 +0000 Subject: [keystone] No meeting Jan 5 Message-ID: <4626967D-ED2C-4152-B8C7-4FD1403330F9@bu.edu> Hi all, There will be no keystone IRC meeting on Jan 5. Best, Kristi Nikolla From ankelezhang at gmail.com Tue Jan 5 03:22:52 2021 From: ankelezhang at gmail.com (Ankele zhang) Date: Tue, 5 Jan 2021 11:22:52 +0800 Subject: tinyipa cannot boot OS of baremetal node Message-ID: Hi~ My Rocky OpenStack platform deployed with official documents, includes Keystone/Cinder/Neutron/Nova and Ironic. I used to boot my baremetal nodes by CoreOS downloaded on https://tarballs.opendev.org/openstack/ironic-python-agent/coreos/files/ Since I want to customize my own HardwareManager for configuring RAID, I have build TinyIPA image tinyipa.tar.gz and tinyipa.vmlinuz with ironic-python-agent-builder(master branch) and ironic-python-agent(rocky branch). Here are all the products of the build process. [image: image.png] Then I used these two images to create the baremetal node, and boot nova server, but I didn't get the results I wanted, it couldn't enter the ramdisk and always in 'wait call-back' state. as following [image: image.png] I got nothing in /var/log/ironic/ironig-conductor.log and /var/log/nova/nova-compute.log I don't know if these two image (tinyipa.tar.gz and tinyipa.vmlinuz) are valid for Ironic. If not, how can I customize HardwareManager? Looking forward to hearing from you. Ankele -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 126537 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 27968 bytes Desc: not available URL: From jxfu at 163.com Tue Jan 5 14:27:16 2021 From: jxfu at 163.com (=?GBK?B?uLbWvruq?=) Date: Tue, 5 Jan 2021 22:27:16 +0800 (CST) Subject: [Nova]ask for help: how to plug vif to ovs when ovs is not together with nova-compute Message-ID: <77980c77.716f.176d2f1e342.Coremail.jxfu@163.com> hello， I encountered some problems in deploying the smart network interface card（SmartNIC）where Nova-compute is not together with OVS. For example, OVS is deployed on the SmartNIC and Nova-compute is on the Host(Compute Node), how does Nova plug the virtual interface of VM to OVS bridge? Does the latest version of openstack support this? Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ionut at fleio.com Tue Jan 5 16:36:28 2021 From: ionut at fleio.com (Ionut Biru) Date: Tue, 5 Jan 2021 18:36:28 +0200 Subject: [magnum][api] Error system library fopen too many open files with magnum-auto-healer In-Reply-To: References: <185a9715-4667-9610-0048-5434e6e2cd4e@catalyst.net.nz> Message-ID: Hi, I found this story: https://storyboard.openstack.org/#!/story/2008308 regarding disabling cluster update notifications in rabbitmq. I think this will help me. On Tue, Jan 5, 2021 at 12:21 PM Erik Olof Gunnar Andersson < eandersson at blizzard.com> wrote: > Sorry, being repetitive here, but maybe try adding this to your magnum > config as well. If you have A LOT of cores it could add up to a crazy > amount of connections. > > [conductor] > workers = 2 > > ------------------------------ > *From:* Ionut Biru > *Sent:* Tuesday, January 5, 2021 1:50 AM > *To:* Erik Olof Gunnar Andersson > *Cc:* Spyros Trigazis ; feilong < > feilong at catalyst.net.nz>; openstack-discuss < > openstack-discuss at lists.openstack.org> > *Subject:* Re: [magnum][api] Error system library fopen too many open > files with magnum-auto-healer > > Hi, > > Here is my config. maybe something is fishy. > > I did have around 300 messages in the queue in notification.info > > and notification.err and I purged them. > > https://paste.xinu.at/woMt/ > > > > > On Tue, Jan 5, 2021 at 11:23 AM Erik Olof Gunnar Andersson < > eandersson at blizzard.com> wrote: > > Yea - tested locally as well and wasn't able to reproduce it either. I > changed the health service job to run every second and maxed out at about > 42 connections to RabbitMQ with two conductor workers. > > /etc/magnum/magnun.conf > > [conductor] > workers = 2 > > > ------------------------------ > *From:* Spyros Trigazis > *Sent:* Tuesday, January 5, 2021 12:59 AM > *To:* Ionut Biru > *Cc:* Erik Olof Gunnar Andersson ; feilong < > feilong at catalyst.net.nz>; openstack-discuss < > openstack-discuss at lists.openstack.org> > *Subject:* Re: [magnum][api] Error system library fopen too many open > files with magnum-auto-healer > > > > On Tue, Jan 5, 2021 at 9:36 AM Ionut Biru wrote: > > Hi, > > I tried with process=1 and it reached 1016 connections to rabbitmq. > lsof > https://paste.xinu.at/jGg/ > > > i think it goes into error when it reaches 1024 file descriptors. > > I'm out of ideas of how to resolve this. I only have 3 clusters available > and it's kinda weird and It doesn't scale. > > > No issues here with 100s of clusters. Not sure what doesn't scale. > > * Maybe your rabbit is flooded with notifications that are not consumed? > * You can use way more than 1024 file descriptors, maybe 2^10? > > Spyros > > > On Mon, Jan 4, 2021 at 9:53 PM Erik Olof Gunnar Andersson < > eandersson at blizzard.com> wrote: > > Sure looks like RabbitMQ. How many workers do have you configured? > > > > Could you try to changing the uwsgi configuration to workers=1 (or > processes=1) and then see if it goes beyond 30 connections to amqp. > > > > *From:* Ionut Biru > *Sent:* Monday, January 4, 2021 4:07 AM > *To:* Erik Olof Gunnar Andersson > *Cc:* feilong ; openstack-discuss < > openstack-discuss at lists.openstack.org> > *Subject:* Re: [magnum][api] Error system library fopen too many open > files with magnum-auto-healer > > > > Hi Erik, > > > > Here is lsof of one uwsgi api. https://paste.xinu.at/5YUWf/ > > > > > I have kubernetes 12.0.1 installed in env. > > > > > > On Sun, Jan 3, 2021 at 3:06 AM Erik Olof Gunnar Andersson < > eandersson at blizzard.com> wrote: > > Maybe something similar to this? > https://github.com/kubernetes-client/python/issues/1158 > > > What does lsof say? > > > > > > > > -- > Ionut Biru - https://fleio.com > > > > > -- > Ionut Biru - https://fleio.com > > -- Ionut Biru - https://fleio.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From smooney at redhat.com Tue Jan 5 17:02:06 2021 From: smooney at redhat.com (Sean Mooney) Date: Tue, 05 Jan 2021 17:02:06 +0000 Subject: [Nova]ask for help: how to plug vif to ovs when ovs is not together with nova-compute In-Reply-To: <77980c77.716f.176d2f1e342.Coremail.jxfu@163.com> References: <77980c77.716f.176d2f1e342.Coremail.jxfu@163.com> Message-ID: On Tue, 2021-01-05 at 22:27 +0800, 付志华 wrote: > hello， >     I encountered some problems in deploying the smart network interface card（SmartNIC）where Nova-compute is not together with OVS. For example, OVS is deployed on the SmartNIC and Nova-compute is on the Host(Compute Node), how does Nova plug the virtual interface of VM to OVS bridge? >     Does the latest version of openstack support this? no it does not. there are ways that you coudl attepmt to make this work namely you could change [os_vif_ovs]/ovsdb_connection https://github.com/openstack/os-vif/blob/master/vif_plug_ovs/ovs.py#L59-L64 so that os-vif could talk to ovs on the smart nic but that would not work for cases where libvirt plugggs the interface. even in case where os-vif pluggs the interface qemu/libvirt will create the vm tap device on the host not on the smart nic so ovs will not be able to see it to manage it. running ovs on a smart nic instead of the host cpu would require other chagne as well so this is a non tirival change. there were some propoals to allow the neutron l2 agent to mange remote ovs instance but that was not accepted. as it stands without a lot of work there is no easy way to deploy openstack in that topology and at this point in the cycle im not sure its something that could be completed this cycle even if we wanted too. its certenly somethign that can be discussed buti would suggest that any work to enable this should proably take place in X at the earliest. >     Thanks. > > >     > > > > > >     > > > From rodrigo.barbieri2010 at gmail.com Tue Jan 5 17:17:58 2021 From: rodrigo.barbieri2010 at gmail.com (Rodrigo Barbieri) Date: Tue, 5 Jan 2021 14:17:58 -0300 Subject: [nova] workarounds and operator experience around bug 1522307/1908133 Message-ID: Hi Nova folks and OpenStack operators! I have had some trouble recently where while using the "images_type = rbd" libvirt option my ceph cluster got filled up without I noticing and froze all my nova services and instances. I started digging and investigating why and how I could prevent or workaround this issue, but I didn't find a very reliable clean way. I documented all my steps and investigation in bug 1908133 [0]. It has been marked as a duplicate of 1522307 [1] which has been around for quite some time, so I am wondering if any operators have been using nova + ceph in production with "images_type = rbd" config set and how you have been handling/working around the issue. Thanks in advance! [0] https://bugs.launchpad.net/nova/+bug/1908133 [1] https://bugs.launchpad.net/nova/+bug/1522307 -- Rodrigo Barbieri MSc Computer Scientist OpenStack Manila Core Contributor Federal University of São Carlos -------------- next part -------------- An HTML attachment was scrubbed... URL: From smooney at redhat.com Tue Jan 5 18:38:14 2021 From: smooney at redhat.com (Sean Mooney) Date: Tue, 05 Jan 2021 18:38:14 +0000 Subject: [nova] workarounds and operator experience around bug 1522307/1908133 In-Reply-To: References: Message-ID: <7b4f6f10e682698dfaed22a86397f5b174fed7e8.camel@redhat.com> On Tue, 2021-01-05 at 14:17 -0300, Rodrigo Barbieri wrote: > Hi Nova folks and OpenStack operators! > > I have had some trouble recently where while using the "images_type = rbd" > libvirt option my ceph cluster got filled up without I noticing and froze > all my nova services and instances. > > I started digging and investigating why and how I could prevent or > workaround this issue, but I didn't find a very reliable clean way. > > I documented all my steps and investigation in bug 1908133 [0]. It has been > marked as a duplicate of 1522307 [1] which has been around for quite some > time, so I am wondering if any operators have been using nova + ceph in > production with "images_type = rbd" config set and how you have been > handling/working around the issue. this is indeed a know issue and the long term plan to fix it was to track shared storae as a sharing resouce provide in plamcent. that never happend so there si currenlty no mechanium available to prevent this explcitly in nova. the disk filter which is nolonger used could prevnet the boot of a vm that would fill the ceph pool but it could not protect against two concurrent request form filling the pool. placement can protect against that due to the transational nature of allocations which serialise all resouce useage however since each host reports the total size of the ceph pool as its local storage that wont work out of the box. as a quick hack what you can do is set the [DEFAULT]/disk_allocation_ratio=(1/number of compute nodes) https://docs.openstack.org/nova/latest/configuration/config.html#DEFAULT.disk_allocation_ratio on each of your compute agents configs. that will prevent over subscription however it has other negitve sidefects. mainly that you will fail to scudle instance that could boot if a host exced its 1/n usage so unless you have perfectly blanced consumtion this is not a good approch. a better appoch but one that requires external scripting is to have a chron job that will update the resrved usaage of each of the disk_gb inventores to the actull amount of of stoarge allocated form the pool. the real fix however is for nova to tack its shared usage in placment correctly as a sharing resouce provide. its possible you might be able to do that via the porvider.yaml file by overriding the local disk_gb to 0 on all comupte nodes then creating a singel haring resouce provider of disk_gb that models the ceph pool. https://specs.openstack.org/openstack/nova-specs/specs/ussuri/approved/provider-config-file.html currently that does not support the addtion of providers to placment agggreate so while it could be used to 0 out the comptue node disk inventoies and to create a sharing provider it with the MISC_SHARES_VIA_AGGREGATE trait it cant do the final step of mapping which compute nodes can consume form sharing provider via the agggrate but you could do that form. that assume that "sharing resouce provdiers" actully work. bacialy what it comes down to today is you need to monitor the avaiable resouce yourslef externally and ensure you never run out of space. that sucks but untill we proably track things in plamcent there is nothign we can really do. the two approch i suggested above might work for a subset of usecasue but really this is a feature that need native suport in nova to adress properly. > > Thanks in advance! > > [0] https://bugs.launchpad.net/nova/+bug/1908133 > [1] https://bugs.launchpad.net/nova/+bug/1522307 > From pierre at stackhpc.com Tue Jan 5 21:32:58 2021 From: pierre at stackhpc.com (Pierre Riteau) Date: Tue, 5 Jan 2021 22:32:58 +0100 Subject: [all][tc] Thoughts on Python 3.7 support Message-ID: Hello, There have been many patches submitted to drop the Python 3.7 classifier from setup.cfg: https://review.opendev.org/q/%2522remove+py37%2522 The justification is that Wallaby tested runtimes only include 3.6 and 3.8. Most projects are merging these patches, but I've seen a couple of objections from ironic and horizon: - https://review.opendev.org/c/openstack/python-ironicclient/+/769044 - https://review.opendev.org/c/openstack/horizon/+/769237 What are the thoughts of the TC and of the overall community on this? Should we really drop these classifiers when there are no corresponding CI jobs, even though more Python versions may well be supported? Best wishes, Pierre Riteau (priteau) From fungi at yuggoth.org Tue Jan 5 21:51:08 2021 From: fungi at yuggoth.org (Jeremy Stanley) Date: Tue, 5 Jan 2021 21:51:08 +0000 Subject: [all][tc] Thoughts on Python 3.7 support In-Reply-To: References: Message-ID: <20210105215107.jap2c5evbkpu2u7n@yuggoth.org> On 2021-01-05 22:32:58 +0100 (+0100), Pierre Riteau wrote: > There have been many patches submitted to drop the Python 3.7 > classifier from setup.cfg: > https://review.opendev.org/q/%2522remove+py37%2522 > The justification is that Wallaby tested runtimes only include 3.6 and 3.8. > > Most projects are merging these patches, but I've seen a couple of > objections from ironic and horizon: > > - https://review.opendev.org/c/openstack/python-ironicclient/+/769044 > - https://review.opendev.org/c/openstack/horizon/+/769237 > > What are the thoughts of the TC and of the overall community on this? > Should we really drop these classifiers when there are no > corresponding CI jobs, even though more Python versions may well be > supported? My recollection of the many discussions we held was that the runtime document would recommend the default python3 available in our targeted platforms, but that we would also make a best effort to test with the latest python3 available to us at the start of the cycle as well. It was suggested more than once that we should test all minor versions in between, but this was ruled out based on the additional CI resources it would consume for minimal gain. Instead we deemed that testing our target version and the latest available would give us sufficient confidence that, if those worked, the versions in between them were likely fine as well. Based on that, I think the versions projects claim to work with should be contiguous ranges, not contiguous lists of the exact versions tested (noting that those aren't particularly *exact* versions to begin with). Apologies for the lack of references to old discussions, I can probably dig some up from the ML and TC meetings several years back of folks think it will help inform this further. -- Jeremy Stanley -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From fungi at yuggoth.org Tue Jan 5 22:08:15 2021 From: fungi at yuggoth.org (Jeremy Stanley) Date: Tue, 5 Jan 2021 22:08:15 +0000 Subject: [all][tc] Thoughts on Python 3.7 support In-Reply-To: <20210105215107.jap2c5evbkpu2u7n@yuggoth.org> References: <20210105215107.jap2c5evbkpu2u7n@yuggoth.org> Message-ID: <20210105220815.66kggyddjnwjyoi6@yuggoth.org> On 2021-01-05 21:51:08 +0000 (+0000), Jeremy Stanley wrote: [...] > not contiguous lists of the exact versions tested [...] Er, sorry, "not INcontiguous lists" is what I meant to type. -- Jeremy Stanley -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From janders at redhat.com Wed Jan 6 00:36:22 2021 From: janders at redhat.com (Jacob Anders) Date: Wed, 6 Jan 2021 10:36:22 +1000 Subject: [ironic] inspector auto-discovery disabled by default in bifrost Message-ID: Hi Ironicers, The Ironic team recently decided to change the default inspector auto-discovery behavior in bifrost. In the past, this feature was enabled by default. However, this was causing issues in deployments where the operators had no intention of using auto-discovery but the IPA somehow booted anyway, causing port conflicts and creating failure modes which were particularly tricky to debug. For this reason, inspector auto-discovery has been disabled by default with this change which merged yesterday: https://review.opendev.org/c/openstack/bifrost/+/762998 This is to make sure that the operators utilising inspector auto-discovery in bifrost are aware of this change and can re-enable inspector discovery if desired. Best regards, Jacob -------------- next part -------------- An HTML attachment was scrubbed... URL: From emiller at genesishosting.com Wed Jan 6 01:44:37 2021 From: emiller at genesishosting.com (Eric K. Miller) Date: Tue, 5 Jan 2021 19:44:37 -0600 Subject: [kolla-ansible] Upgrading and skipping a release? Message-ID: <046E9C0290DD9149B106B72FC9156BEA04814FB6@gmsxchsvr01.thecreation.com> Hi, We're working on some upgrades of OpenStack deployed with Kolla Ansible (Stein and later), and wasn't sure if it was practical or possible to upgrade, say, from Stein to Victoria, or Train to Victoria, directly, instead of upgrading in 3 steps from Stein->Train->Ussuri->Victoria. Any reason skipping a release will cause any known harm? Anybody done this successfully? Thanks! Eric -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark at stackhpc.com Wed Jan 6 08:58:36 2021 From: mark at stackhpc.com (Mark Goddard) Date: Wed, 6 Jan 2021 08:58:36 +0000 Subject: [kolla-ansible] Upgrading and skipping a release? In-Reply-To: <046E9C0290DD9149B106B72FC9156BEA04814FB6@gmsxchsvr01.thecreation.com> References: <046E9C0290DD9149B106B72FC9156BEA04814FB6@gmsxchsvr01.thecreation.com> Message-ID: On Wed, 6 Jan 2021 at 01:45, Eric K. Miller wrote: > > Hi, > > > > We're working on some upgrades of OpenStack deployed with Kolla Ansible (Stein and later), and wasn't sure if it was practical or possible to upgrade, say, from Stein to Victoria, or Train to Victoria, directly, instead of upgrading in 3 steps from Stein->Train->Ussuri->Victoria. Any reason skipping a release will cause any known harm? Anybody done this successfully? Hi Eric. What you're referring to is a fast-forward upgrade [1]. This is not officially supported by Kolla Ansible, and not something we test upstream. There was an effort a few years ago to implement it, but it stalled. The test matrix does increase somewhat when you allow FFUs, which is why I believe many projects such as Tripleo define supported FFU jumps. One thing in particular that may catch you out is some DB migrations or cleanup processes that happen at runtime may not get executed. In short, I'd suggest going one release at a time. It's a pain, but upgrades in Kolla are relatively sane. [1] https://wiki.openstack.org/wiki/Fast_forward_upgrades#:~:text=9%20Gotchas-,What%20is%20a%20Fast%20Forward%20Upgrade%3F,to%20your%20desired%20final%20version. Mark > > Thanks! > > > Eric > > From eandersson at blizzard.com Wed Jan 6 10:23:25 2021 From: eandersson at blizzard.com (Erik Olof Gunnar Andersson) Date: Wed, 6 Jan 2021 10:23:25 +0000 Subject: [magnum][api] Error system library fopen too many open files with magnum-auto-healer In-Reply-To: References: <185a9715-4667-9610-0048-5434e6e2cd4e@catalyst.net.nz> , Message-ID: I pushed a couple of patches that you can try out. This is the most likely culprit. https://review.opendev.org/c/openstack/magnum/+/769471 - Re-use rpc client I also created this one, but doubt this is an issue as the implementation here is the same as I use in Designate https://review.opendev.org/c/openstack/magnum/+/769457 - [WIP] Singleton notifier Finally I also created a PR to add magnum-api testing using uwsgi. https://review.opendev.org/c/openstack/magnum/+/769450 Let me know if any of these patches help! ________________________________ From: Ionut Biru Sent: Tuesday, January 5, 2021 8:36 AM To: Erik Olof Gunnar Andersson Cc: Spyros Trigazis ; feilong ; openstack-discuss Subject: Re: [magnum][api] Error system library fopen too many open files with magnum-auto-healer Hi, I found this story: https://storyboard.openstack.org/#!/story/2008308 regarding disabling cluster update notifications in rabbitmq. I think this will help me. On Tue, Jan 5, 2021 at 12:21 PM Erik Olof Gunnar Andersson > wrote: Sorry, being repetitive here, but maybe try adding this to your magnum config as well. If you have A LOT of cores it could add up to a crazy amount of connections. [conductor] workers = 2 ________________________________ From: Ionut Biru > Sent: Tuesday, January 5, 2021 1:50 AM To: Erik Olof Gunnar Andersson > Cc: Spyros Trigazis >; feilong >; openstack-discuss > Subject: Re: [magnum][api] Error system library fopen too many open files with magnum-auto-healer Hi, Here is my config. maybe something is fishy. I did have around 300 messages in the queue in notification.info and notification.err and I purged them. https://paste.xinu.at/woMt/ On Tue, Jan 5, 2021 at 11:23 AM Erik Olof Gunnar Andersson > wrote: Yea - tested locally as well and wasn't able to reproduce it either. I changed the health service job to run every second and maxed out at about 42 connections to RabbitMQ with two conductor workers. /etc/magnum/magnun.conf [conductor] workers = 2 ________________________________ From: Spyros Trigazis > Sent: Tuesday, January 5, 2021 12:59 AM To: Ionut Biru > Cc: Erik Olof Gunnar Andersson >; feilong >; openstack-discuss > Subject: Re: [magnum][api] Error system library fopen too many open files with magnum-auto-healer On Tue, Jan 5, 2021 at 9:36 AM Ionut Biru > wrote: Hi, I tried with process=1 and it reached 1016 connections to rabbitmq. lsof https://paste.xinu.at/jGg/ i think it goes into error when it reaches 1024 file descriptors. I'm out of ideas of how to resolve this. I only have 3 clusters available and it's kinda weird and It doesn't scale. No issues here with 100s of clusters. Not sure what doesn't scale. * Maybe your rabbit is flooded with notifications that are not consumed? * You can use way more than 1024 file descriptors, maybe 2^10? Spyros On Mon, Jan 4, 2021 at 9:53 PM Erik Olof Gunnar Andersson > wrote: Sure looks like RabbitMQ. How many workers do have you configured? Could you try to changing the uwsgi configuration to workers=1 (or processes=1) and then see if it goes beyond 30 connections to amqp. From: Ionut Biru > Sent: Monday, January 4, 2021 4:07 AM To: Erik Olof Gunnar Andersson > Cc: feilong >; openstack-discuss > Subject: Re: [magnum][api] Error system library fopen too many open files with magnum-auto-healer Hi Erik, Here is lsof of one uwsgi api. https://paste.xinu.at/5YUWf/ I have kubernetes 12.0.1 installed in env. On Sun, Jan 3, 2021 at 3:06 AM Erik Olof Gunnar Andersson > wrote: Maybe something similar to this? https://github.com/kubernetes-client/python/issues/1158 What does lsof say? -- Ionut Biru - https://fleio.com -- Ionut Biru - https://fleio.com -- Ionut Biru - https://fleio.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From dtantsur at redhat.com Wed Jan 6 10:34:03 2021 From: dtantsur at redhat.com (Dmitry Tantsur) Date: Wed, 6 Jan 2021 11:34:03 +0100 Subject: [all][tc] Thoughts on Python 3.7 support In-Reply-To: <20210105215107.jap2c5evbkpu2u7n@yuggoth.org> References: <20210105215107.jap2c5evbkpu2u7n@yuggoth.org> Message-ID: On Tue, Jan 5, 2021 at 10:53 PM Jeremy Stanley wrote: > On 2021-01-05 22:32:58 +0100 (+0100), Pierre Riteau wrote: > > There have been many patches submitted to drop the Python 3.7 > > classifier from setup.cfg: > > https://review.opendev.org/q/%2522remove+py37%2522 > > The justification is that Wallaby tested runtimes only include 3.6 and > 3.8. > > > > Most projects are merging these patches, but I've seen a couple of > > objections from ironic and horizon: > > > > - https://review.opendev.org/c/openstack/python-ironicclient/+/769044 > > - https://review.opendev.org/c/openstack/horizon/+/769237 > > > > What are the thoughts of the TC and of the overall community on this? > > Should we really drop these classifiers when there are no > > corresponding CI jobs, even though more Python versions may well be > > supported? > > My recollection of the many discussions we held was that the runtime > document would recommend the default python3 available in our > targeted platforms, but that we would also make a best effort to > test with the latest python3 available to us at the start of the > cycle as well. It was suggested more than once that we should test > all minor versions in between, but this was ruled out based on the > additional CI resources it would consume for minimal gain. Instead > we deemed that testing our target version and the latest available > would give us sufficient confidence that, if those worked, the > versions in between them were likely fine as well. Based on that, I > think the versions projects claim to work with should be contiguous > ranges, not contiguous lists of the exact versions tested (noting > that those aren't particularly *exact* versions to begin with). > This is precisely my expectation: if we support 3.6 and 3.8, it's reasonable to suggest we support 3.7. Not supporting it gains us nothing. Dmitry > > Apologies for the lack of references to old discussions, I can > probably dig some up from the ML and TC meetings several years back > of folks think it will help inform this further. > -- > Jeremy Stanley > -- Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill -------------- next part -------------- An HTML attachment was scrubbed... URL: From radoslaw.piliszek at gmail.com Wed Jan 6 11:26:35 2021 From: radoslaw.piliszek at gmail.com (=?UTF-8?Q?Rados=C5=82aw_Piliszek?=) Date: Wed, 6 Jan 2021 12:26:35 +0100 Subject: [all][tc] Thoughts on Python 3.7 support In-Reply-To: References: <20210105215107.jap2c5evbkpu2u7n@yuggoth.org> Message-ID: Sorry for top posting but just a general remark: Do note Debian 10 is using Python 3.7 and that is what Kolla is testing too. I know Debian is not considered a tested platform but people use it successfully. My opinion is, therefore, that we should keep 3.7 in classifiers. -yoctozepto On Wed, Jan 6, 2021 at 11:37 AM Dmitry Tantsur wrote: > > > > On Tue, Jan 5, 2021 at 10:53 PM Jeremy Stanley wrote: >> >> On 2021-01-05 22:32:58 +0100 (+0100), Pierre Riteau wrote: >> > There have been many patches submitted to drop the Python 3.7 >> > classifier from setup.cfg: >> > https://review.opendev.org/q/%2522remove+py37%2522 >> > The justification is that Wallaby tested runtimes only include 3.6 and 3.8. >> > >> > Most projects are merging these patches, but I've seen a couple of >> > objections from ironic and horizon: >> > >> > - https://review.opendev.org/c/openstack/python-ironicclient/+/769044 >> > - https://review.opendev.org/c/openstack/horizon/+/769237 >> > >> > What are the thoughts of the TC and of the overall community on this? >> > Should we really drop these classifiers when there are no >> > corresponding CI jobs, even though more Python versions may well be >> > supported? >> >> My recollection of the many discussions we held was that the runtime >> document would recommend the default python3 available in our >> targeted platforms, but that we would also make a best effort to >> test with the latest python3 available to us at the start of the >> cycle as well. It was suggested more than once that we should test >> all minor versions in between, but this was ruled out based on the >> additional CI resources it would consume for minimal gain. Instead >> we deemed that testing our target version and the latest available >> would give us sufficient confidence that, if those worked, the >> versions in between them were likely fine as well. Based on that, I >> think the versions projects claim to work with should be contiguous >> ranges, not contiguous lists of the exact versions tested (noting >> that those aren't particularly *exact* versions to begin with). > > > This is precisely my expectation: if we support 3.6 and 3.8, it's reasonable to suggest we support 3.7. Not supporting it gains us nothing. > > Dmitry > >> >> >> Apologies for the lack of references to old discussions, I can >> probably dig some up from the ML and TC meetings several years back >> of folks think it will help inform this further. >> -- >> Jeremy Stanley > > > > -- > Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn, > Commercial register: Amtsgericht Muenchen, HRB 153243, > Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill From ionut at fleio.com Wed Jan 6 11:37:23 2021 From: ionut at fleio.com (Ionut Biru) Date: Wed, 6 Jan 2021 13:37:23 +0200 Subject: [magnum][api] Error system library fopen too many open files with magnum-auto-healer In-Reply-To: References: <185a9715-4667-9610-0048-5434e6e2cd4e@catalyst.net.nz> Message-ID: Hi Erik, Thanks a lot for the patch. Indeed 769471 fixes my problem at first glance. I'll let it run for a couple of days. On Wed, Jan 6, 2021 at 12:23 PM Erik Olof Gunnar Andersson < eandersson at blizzard.com> wrote: > I pushed a couple of patches that you can try out. > > This is the most likely culprit. > https://review.opendev.org/c/openstack/magnum/+/769471 - Re-use rpc client > > I also created this one, but doubt this is an issue as the implementation > here is the same as I use in Designate > https://review.opendev.org/c/openstack/magnum/+/769457 - [WIP] Singleton > notifier > > Finally I also created a PR to add magnum-api testing using uwsgi. > https://review.opendev.org/c/openstack/magnum/+/769450 > > Let me know if any of these patches help! > > ------------------------------ > *From:* Ionut Biru > *Sent:* Tuesday, January 5, 2021 8:36 AM > *To:* Erik Olof Gunnar Andersson > *Cc:* Spyros Trigazis ; feilong < > feilong at catalyst.net.nz>; openstack-discuss < > openstack-discuss at lists.openstack.org> > *Subject:* Re: [magnum][api] Error system library fopen too many open > files with magnum-auto-healer > > Hi, > > I found this story: https://storyboard.openstack.org/#!/story/2008308 > > regarding disabling cluster update notifications in rabbitmq. > > I think this will help me. > > On Tue, Jan 5, 2021 at 12:21 PM Erik Olof Gunnar Andersson < > eandersson at blizzard.com> wrote: > > Sorry, being repetitive here, but maybe try adding this to your magnum > config as well. If you have A LOT of cores it could add up to a crazy > amount of connections. > > [conductor] > workers = 2 > > ------------------------------ > *From:* Ionut Biru > *Sent:* Tuesday, January 5, 2021 1:50 AM > *To:* Erik Olof Gunnar Andersson > *Cc:* Spyros Trigazis ; feilong < > feilong at catalyst.net.nz>; openstack-discuss < > openstack-discuss at lists.openstack.org> > *Subject:* Re: [magnum][api] Error system library fopen too many open > files with magnum-auto-healer > > Hi, > > Here is my config. maybe something is fishy. > > I did have around 300 messages in the queue in notification.info > > and notification.err and I purged them. > > https://paste.xinu.at/woMt/ > > > > > On Tue, Jan 5, 2021 at 11:23 AM Erik Olof Gunnar Andersson < > eandersson at blizzard.com> wrote: > > Yea - tested locally as well and wasn't able to reproduce it either. I > changed the health service job to run every second and maxed out at about > 42 connections to RabbitMQ with two conductor workers. > > /etc/magnum/magnun.conf > > [conductor] > workers = 2 > > > ------------------------------ > *From:* Spyros Trigazis > *Sent:* Tuesday, January 5, 2021 12:59 AM > *To:* Ionut Biru > *Cc:* Erik Olof Gunnar Andersson ; feilong < > feilong at catalyst.net.nz>; openstack-discuss < > openstack-discuss at lists.openstack.org> > *Subject:* Re: [magnum][api] Error system library fopen too many open > files with magnum-auto-healer > > > > On Tue, Jan 5, 2021 at 9:36 AM Ionut Biru wrote: > > Hi, > > I tried with process=1 and it reached 1016 connections to rabbitmq. > lsof > https://paste.xinu.at/jGg/ > > > i think it goes into error when it reaches 1024 file descriptors. > > I'm out of ideas of how to resolve this. I only have 3 clusters available > and it's kinda weird and It doesn't scale. > > > No issues here with 100s of clusters. Not sure what doesn't scale. > > * Maybe your rabbit is flooded with notifications that are not consumed? > * You can use way more than 1024 file descriptors, maybe 2^10? > > Spyros > > > On Mon, Jan 4, 2021 at 9:53 PM Erik Olof Gunnar Andersson < > eandersson at blizzard.com> wrote: > > Sure looks like RabbitMQ. How many workers do have you configured? > > > > Could you try to changing the uwsgi configuration to workers=1 (or > processes=1) and then see if it goes beyond 30 connections to amqp. > > > > *From:* Ionut Biru > *Sent:* Monday, January 4, 2021 4:07 AM > *To:* Erik Olof Gunnar Andersson > *Cc:* feilong ; openstack-discuss < > openstack-discuss at lists.openstack.org> > *Subject:* Re: [magnum][api] Error system library fopen too many open > files with magnum-auto-healer > > > > Hi Erik, > > > > Here is lsof of one uwsgi api. https://paste.xinu.at/5YUWf/ > > > > > I have kubernetes 12.0.1 installed in env. > > > > > > On Sun, Jan 3, 2021 at 3:06 AM Erik Olof Gunnar Andersson < > eandersson at blizzard.com> wrote: > > Maybe something similar to this? > https://github.com/kubernetes-client/python/issues/1158 > > > What does lsof say? > > > > > > > > -- > Ionut Biru - https://fleio.com > > > > > -- > Ionut Biru - https://fleio.com > > > > > -- > Ionut Biru - https://fleio.com > > -- Ionut Biru - https://fleio.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From hberaud at redhat.com Wed Jan 6 11:47:08 2021 From: hberaud at redhat.com (Herve Beraud) Date: Wed, 6 Jan 2021 12:47:08 +0100 Subject: [release] Status: RED - pip resolver issue with publish-openstack-releasenotes-python3 In-Reply-To: References: Message-ID: @release mangaers: For now I think we can restart validating projects that aren't present in the previous list (c.f http://lists.openstack.org/pipermail/openstack-discuss/2021-January/019612.html ). Normally they aren't impacted by this problem. I'll move to the "Orange" state when all the projects of list will be patched or at least when a related patch will be present in the list (c.f https://review.opendev.org/q/topic:%2522fix-relmgt-pip-doc%2522+(status:open+OR+status:merged)). For now my monitoring indicates that ~50 projects still need related changes. So, for now, please, ensure that the repos aren't listed here before validate a patch http://lists.openstack.org/pipermail/openstack-discuss/2021-January/019612.html Thanks to everyone who helped here! Much appreciated! Le mar. 5 janv. 2021 à 12:05, Martin Chacon Piza a écrit : > Hi Herve, > > I have added this topic to the Monasca irc meeting today. > > Thank you, > Martin (chaconpiza) > > > > El lun, 4 de ene. de 2021 a la(s) 18:30, Herve Beraud (hberaud at redhat.com) > escribió: > >> Thanks all! >> >> Here we can track our advancement: >> >> https://review.opendev.org/q/topic:%22fix-relmgt-pip-doc%22+(status:open%20OR%20status:merged) >> >> Le lun. 4 janv. 2021 à 18:02, Radosław Piliszek < >> radoslaw.piliszek at gmail.com> a écrit : >> >>> On Mon, Jan 4, 2021 at 4:34 PM Herve Beraud wrote: >>> > >>> > Here is the filtered list of projects that meet the conditions leading >>> to the bug, and who should be fixed to completely solve our issue: >>> > >>> > ... >>> > etcd3gw >>> > ... >>> > python-masakariclient >>> > ... >>> > >>> > Notice that some of these projects aren't deliverables but if possible >>> it could be worth fixing them too. >>> > >>> > These projects have an incompatibility between entries in their >>> test-requirements.txt, and they're missing a doc/requirements.txt file. >>> > >>> > The more straightforward path to unlock our job >>> "publish-openstack-releasenotes-python3" is to create a >>> doc/requirements.txt file that only contains the needed dependencies to >>> reduce the possibility of pip resolver issues. I personally think that we >>> could use the latest allowed version of requirements (sphinx, reno, etc...). >>> > >>> > I propose to track the related advancement by using the >>> "fix-relmgt-pip-doc" gerrit topic, when all the projects will be fixed we >>> would be able to update our status. >>> > >>> > Also it could be worth fixing test-requirements.txt incompatibilities >>> but this task is more on the projects teams sides and this task could be >>> done with a follow up patch. >>> > >>> > Thoughts? >>> >>> Thanks, Hervé! >>> >>> Done for python-masakariclient in [1]. >>> >>> etcd3gw needs more love in general but I will have this split in mind. >>> >>> [1] >>> https://review.opendev.org/c/openstack/python-masakariclient/+/769163 >>> >>> -yoctozepto >>> >>> >> >> -- >> Hervé Beraud >> Senior Software Engineer at Red Hat >> irc: hberaud >> https://github.com/4383/ >> https://twitter.com/4383hberaud >> -----BEGIN PGP SIGNATURE----- >> >> wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ >> Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ >> RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP >> F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G >> 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g >> glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw >> m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ >> hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 >> qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y >> F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 >> B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O >> v6rDpkeNksZ9fFSyoY2o >> =ECSj >> -----END PGP SIGNATURE----- >> >> > > -- > *Martín Chacón Pizá* > *chacon.piza at gmail.com * > -- Hervé Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/ https://twitter.com/4383hberaud -----BEGIN PGP SIGNATURE----- wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O v6rDpkeNksZ9fFSyoY2o =ECSj -----END PGP SIGNATURE----- -------------- next part -------------- An HTML attachment was scrubbed... URL: From hberaud at redhat.com Wed Jan 6 12:00:31 2021 From: hberaud at redhat.com (Herve Beraud) Date: Wed, 6 Jan 2021 13:00:31 +0100 Subject: [oslo][TC] Dropping lower-constraints testing In-Reply-To: References: <1767687c4ad.10b9514f7310538.2670005890023858557@ghanshyammann.com> Message-ID: Hello everyone, Here is an email to officialize our position on Olso concerning our lower-constraints testing policy. Indeed we reached a consensus during our last meeting and all the Oslo cores who spoke agreed with this decision to drop the L.C tests [1]. So we already started to drop lower-constraints jobs on Oslo to unlock our gates. Thanks to everyone who joined the discussion and thanks for reading! [1] http://eavesdrop.openstack.org/meetings/oslo/2021/oslo.2021-01-04-16.00.log.txt #topic Dropping lower-constraints testing Le ven. 18 déc. 2020 à 20:34, Moises Guimaraes de Medeiros < moguimar at redhat.com> a écrit : > +1 > > On Fri, Dec 18, 2020 at 4:46 PM Ghanshyam Mann > wrote: > >> ---- On Fri, 18 Dec 2020 08:54:26 -0600 hberaud >> wrote ---- >> > Hello, >> > As you already surely know, we (the openstack project) currently face >> some issues with our lower-constraints jobs due to pip's latest resolver >> feature. >> > By discussing this topic with Thierry Carrez (ttx) from an oslo point >> of view, we reached the same conclusion that it is more appropriate to drop >> this kind of tests because the complexity and recurring pain neededto >> maintain them now exceeds the benefits provided by this mechanismes. >> > Also we should notice that the number of active maintainers is >> declining, so we think that this is the shortest path to solve this problem >> on oslo for now and for the future too. >> > >> > In a first time I tried to fix our gates by fixing our >> lower-constraints project by project but with around ~36 projects to >> maintain this is a painful task, especially due to nested oslo layers >> inside oslo himself... I saw the face of the hell of dependencies. >> > >> > So, in a second time I submitted a series of patches to drop these >> tests [1]. >> > But before moving further with that we would appreciate discussing >> this with the TC. For now the patches are ready and we just have to push >> the good button accordingly to our choices (+W or abandon). >> > >> > Normally all the oslo projects that need to be fixed are covered by >> [1]. >> > >> > Thoughts? >> >> +1, I think it's not worth to keep maintaining them which is taking too >> much effort. >> >> -gmann >> >> > >> > Thanks for reading. >> > >> > [1] >> https://review.opendev.org/q/topic:%22oslo_lc_drop%22+(status:open%20OR%20status:merged) >> > -- >> > Hervé BeraudSenior Software Engineer at Red Hatirc: hberaudhttps:// >> github.com/4383/https://twitter.com/4383hberaud >> > -----BEGIN PGP SIGNATURE----- >> > >> > wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ >> > Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ >> > RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP >> > F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G >> > 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g >> > glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw >> > m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ >> > hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 >> > qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y >> > F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 >> > B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O >> > v6rDpkeNksZ9fFSyoY2o >> > =ECSj >> > -----END PGP SIGNATURE----- >> > >> > >> >> > > -- > > Moisés Guimarães > > Software Engineer > > Red Hat > > > -- Hervé Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/ https://twitter.com/4383hberaud -----BEGIN PGP SIGNATURE----- wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O v6rDpkeNksZ9fFSyoY2o =ECSj -----END PGP SIGNATURE----- -------------- next part -------------- An HTML attachment was scrubbed... URL: From skaplons at redhat.com Wed Jan 6 12:43:18 2021 From: skaplons at redhat.com (Slawek Kaplonski) Date: Wed, 06 Jan 2021 13:43:18 +0100 Subject: [oslo][TC] Dropping lower-constraints testing In-Reply-To: References: Message-ID: <7679064.EuSn42jlT6@p1> Hi, Dnia środa, 6 stycznia 2021 13:00:31 CET Herve Beraud pisze: > Hello everyone, > > Here is an email to officialize our position on Olso concerning our > lower-constraints testing policy. > Indeed we reached a consensus during our last meeting and all the Oslo > cores who spoke agreed with this decision to drop the L.C tests [1]. > > So we already started to drop lower-constraints jobs on Oslo to unlock our > gates. Sorry if my question shouldn't be in that thread but does that mean that other projects should/can drop lower constraints jobs too? Is it some general, OpenStack wide decision or it depends on the project? > > Thanks to everyone who joined the discussion and thanks for reading! > > [1] > http://eavesdrop.openstack.org/meetings/oslo/2021/oslo.2021-01-04-16.00.log. > txt #topic Dropping lower-constraints testing > > Le ven. 18 déc. 2020 à 20:34, Moises Guimaraes de Medeiros < > > moguimar at redhat.com> a écrit : > > +1 > > > > On Fri, Dec 18, 2020 at 4:46 PM Ghanshyam Mann > > > > wrote: > >> ---- On Fri, 18 Dec 2020 08:54:26 -0600 hberaud > >> > >> wrote ---- > >> > >> > Hello, > >> > As you already surely know, we (the openstack project) currently face > >> > >> some issues with our lower-constraints jobs due to pip's latest resolver > >> feature. > >> > >> > By discussing this topic with Thierry Carrez (ttx) from an oslo point > >> > >> of view, we reached the same conclusion that it is more appropriate to > >> drop > >> this kind of tests because the complexity and recurring pain neededto > >> maintain them now exceeds the benefits provided by this mechanismes. > >> > >> > Also we should notice that the number of active maintainers is > >> > >> declining, so we think that this is the shortest path to solve this > >> problem > >> on oslo for now and for the future too. > >> > >> > In a first time I tried to fix our gates by fixing our > >> > >> lower-constraints project by project but with around ~36 projects to > >> maintain this is a painful task, especially due to nested oslo layers > >> inside oslo himself... I saw the face of the hell of dependencies. > >> > >> > So, in a second time I submitted a series of patches to drop these > >> > >> tests [1]. > >> > >> > But before moving further with that we would appreciate discussing > >> > >> this with the TC. For now the patches are ready and we just have to push > >> the good button accordingly to our choices (+W or abandon). > >> > >> > Normally all the oslo projects that need to be fixed are covered by > >> > >> [1]. > >> > >> > Thoughts? > >> > >> +1, I think it's not worth to keep maintaining them which is taking too > >> much effort. > >> > >> -gmann > >> > >> > Thanks for reading. > >> > > >> > [1] > >> > >> https://review.opendev.org/q/topic:%22oslo_lc_drop%22+(status:open%20OR%2 > >> 0status:merged)>> > >> > -- > >> > Hervé BeraudSenior Software Engineer at Red Hatirc: hberaudhttps:// > >> > >> github.com/4383/https://twitter.com/4383hberaud > >> > >> > -----BEGIN PGP SIGNATURE----- > >> > > >> > wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ > >> > Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ > >> > RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP > >> > F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G > >> > 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g > >> > glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw > >> > m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ > >> > hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 > >> > qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y > >> > F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 > >> > B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O > >> > v6rDpkeNksZ9fFSyoY2o > >> > =ECSj > >> > -----END PGP SIGNATURE----- > > > > -- > > > > Moisés Guimarães > > > > Software Engineer > > > > Red Hat > > > > > > -- > Hervé Beraud > Senior Software Engineer at Red Hat > irc: hberaud > https://github.com/4383/ > https://twitter.com/4383hberaud -- Slawek Kaplonski Principal Software Engineer Red Hat -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: This is a digitally signed message part. URL: From victoria at vmartinezdelacruz.com Wed Jan 6 12:46:09 2021 From: victoria at vmartinezdelacruz.com (=?UTF-8?Q?Victoria_Mart=C3=ADnez_de_la_Cruz?=) Date: Wed, 6 Jan 2021 09:46:09 -0300 Subject: [all][tc] Thoughts on Python 3.7 support In-Reply-To: References: <20210105215107.jap2c5evbkpu2u7n@yuggoth.org> Message-ID: +1 I don't see good reasons for removing py3.7 Thanks! On Wed, Jan 6, 2021 at 8:28 AM Radosław Piliszek < radoslaw.piliszek at gmail.com> wrote: > Sorry for top posting but just a general remark: > > Do note Debian 10 is using Python 3.7 and that is what Kolla is testing > too. > I know Debian is not considered a tested platform but people use it > successfully. > > My opinion is, therefore, that we should keep 3.7 in classifiers. > > -yoctozepto > > On Wed, Jan 6, 2021 at 11:37 AM Dmitry Tantsur > wrote: > > > > > > > > On Tue, Jan 5, 2021 at 10:53 PM Jeremy Stanley > wrote: > >> > >> On 2021-01-05 22:32:58 +0100 (+0100), Pierre Riteau wrote: > >> > There have been many patches submitted to drop the Python 3.7 > >> > classifier from setup.cfg: > >> > https://review.opendev.org/q/%2522remove+py37%2522 > >> > The justification is that Wallaby tested runtimes only include 3.6 > and 3.8. > >> > > >> > Most projects are merging these patches, but I've seen a couple of > >> > objections from ironic and horizon: > >> > > >> > - https://review.opendev.org/c/openstack/python-ironicclient/+/769044 > >> > - https://review.opendev.org/c/openstack/horizon/+/769237 > >> > > >> > What are the thoughts of the TC and of the overall community on this? > >> > Should we really drop these classifiers when there are no > >> > corresponding CI jobs, even though more Python versions may well be > >> > supported? > >> > >> My recollection of the many discussions we held was that the runtime > >> document would recommend the default python3 available in our > >> targeted platforms, but that we would also make a best effort to > >> test with the latest python3 available to us at the start of the > >> cycle as well. It was suggested more than once that we should test > >> all minor versions in between, but this was ruled out based on the > >> additional CI resources it would consume for minimal gain. Instead > >> we deemed that testing our target version and the latest available > >> would give us sufficient confidence that, if those worked, the > >> versions in between them were likely fine as well. Based on that, I > >> think the versions projects claim to work with should be contiguous > >> ranges, not contiguous lists of the exact versions tested (noting > >> that those aren't particularly *exact* versions to begin with). > > > > > > This is precisely my expectation: if we support 3.6 and 3.8, it's > reasonable to suggest we support 3.7. Not supporting it gains us nothing. > > > > Dmitry > > > >> > >> > >> Apologies for the lack of references to old discussions, I can > >> probably dig some up from the ML and TC meetings several years back > >> of folks think it will help inform this further. > >> -- > >> Jeremy Stanley > > > > > > > > -- > > Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn, > > Commercial register: Amtsgericht Muenchen, HRB 153243, > > Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael > O'Neill > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From smooney at redhat.com Wed Jan 6 13:21:07 2021 From: smooney at redhat.com (Sean Mooney) Date: Wed, 06 Jan 2021 13:21:07 +0000 Subject: [oslo][TC] Dropping lower-constraints testing In-Reply-To: <7679064.EuSn42jlT6@p1> References: <7679064.EuSn42jlT6@p1> Message-ID: <2f450b85dae98c9c5ae7d14cd2e734036bf78889.camel@redhat.com> On Wed, 2021-01-06 at 13:43 +0100, Slawek Kaplonski wrote: > Hi, > > Dnia środa, 6 stycznia 2021 13:00:31 CET Herve Beraud pisze: > > Hello everyone, > > > > Here is an email to officialize our position on Olso concerning our > > lower-constraints testing policy. > > Indeed we reached a consensus during our last meeting and all the Oslo > > cores who spoke agreed with this decision to drop the L.C tests [1]. > > > > So we already started to drop lower-constraints jobs on Oslo to unlock our > > gates. > > Sorry if my question shouldn't be in that thread but does that mean that other > projects should/can drop lower constraints jobs too? Is it some general, > OpenStack wide decision or it depends on the project? lower constratis is not a required part fo the PTI https://governance.openstack.org/tc/reference/pti/python.html https://governance.openstack.org/tc/reference/project-testing-interface.html so its technially a per project desision as far as i am aware. while project were encouraged to adopt lower constratit testing we did not require all project to provide it and i belive there are some that dont unless im mistaken. so neutron could drop lc testing too i belive if it desired too. unless im misinterperting things > > > > > Thanks to everyone who joined the discussion and thanks for reading! > > > > [1] > > http://eavesdrop.openstack.org/meetings/oslo/2021/oslo.2021-01-04-16.00.log. > > txt #topic Dropping lower-constraints testing > > > > Le ven. 18 déc. 2020 à 20:34, Moises Guimaraes de Medeiros < > > > > moguimar at redhat.com> a écrit : > > > +1 > > > > > > On Fri, Dec 18, 2020 at 4:46 PM Ghanshyam Mann > > > > > > wrote: > > > >  ---- On Fri, 18 Dec 2020 08:54:26 -0600 hberaud > > > > > > > > wrote ---- > > > > > > > >  > Hello, > > > >  > As you already surely know, we (the openstack project) currently face > > > > > > > > some issues with our lower-constraints jobs due to pip's latest resolver > > > > feature. > > > > > > > >  > By discussing this topic with Thierry Carrez (ttx) from an oslo point > > > > > > > > of view, we reached the same conclusion that it is more appropriate to > > > > drop > > > > this kind of tests because the complexity and recurring pain neededto > > > > maintain them now exceeds the benefits provided by this mechanismes. > > > > > > > >  > Also we should notice that the number of active maintainers is > > > > > > > > declining, so we think that this is the shortest path to solve this > > > > problem > > > > on oslo for now and for the future too. > > > > > > > >  > In a first time I tried to fix our gates by fixing our > > > > > > > > lower-constraints project by project but with around ~36 projects to > > > > maintain this is a painful task, especially due to nested oslo layers > > > > inside oslo himself... I saw the face of the hell of dependencies. > > > > > > > >  > So, in a second time I submitted a series of patches to drop these > > > > > > > > tests [1]. > > > > > > > >  > But before moving further with that we would appreciate discussing > > > > > > > > this with the TC. For now the patches are ready and we just have to push > > > > the good button accordingly to our choices (+W or abandon). > > > > > > > >  > Normally all the oslo projects that need to be fixed are covered by > > > > > > > > [1]. > > > > > > > >  > Thoughts? > > > > > > > > +1, I think it's not worth to keep maintaining them which is taking too > > > > much effort. > > > > > > > > -gmann > > > > > > > >  > Thanks for reading. > > > >  > > > > >  > [1] > > > > > > > > https://review.opendev.org/q/topic:%22oslo_lc_drop%22+(status:open%20OR%2 > > > > 0status:merged)>> > > > >  > -- > > > >  > Hervé BeraudSenior Software Engineer at Red Hatirc: hberaudhttps:// > > > > > > > > github.com/4383/https://twitter.com/4383hberaud > > > > > > > >  > -----BEGIN PGP SIGNATURE----- > > > >  > > > > >  > wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ > > > >  > Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ > > > >  > RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP > > > >  > F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G > > > >  > 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g > > > >  > glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw > > > >  > m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ > > > >  > hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 > > > >  > qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y > > > >  > F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 > > > >  > B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O > > > >  > v6rDpkeNksZ9fFSyoY2o > > > >  > =ECSj > > > >  > -----END PGP SIGNATURE----- > > > > > > -- > > > > > > Moisés Guimarães > > > > > > Software Engineer > > > > > > Red Hat > > > > > > > > > > -- > > Hervé Beraud > > Senior Software Engineer at Red Hat > > irc: hberaud > > https://github.com/4383/ > > https://twitter.com/4383hberaud > > From smooney at redhat.com Wed Jan 6 13:27:28 2021 From: smooney at redhat.com (Sean Mooney) Date: Wed, 06 Jan 2021 13:27:28 +0000 Subject: [all][tc] Thoughts on Python 3.7 support In-Reply-To: References: <20210105215107.jap2c5evbkpu2u7n@yuggoth.org> Message-ID: On Wed, 2021-01-06 at 09:46 -0300, Victoria Martínez de la Cruz wrote: > +1 > > I don't see good reasons for removing py3.7 based on teh agreed testing runtimes for wallaby https://github.com/openstack/governance/blob/master/reference/runtimes/wallaby.rst there is no requiremetn for project to maintain testing for py 3.7 but that does not mean the cant elect to test it as an option addtional runtime provided they test teh minium reuiqred vers which are python 3.6 and 3.8 py 3.7 could be maintined as an optional runtime as we do for python 3.9 but i think part of the motivation of droping the 3.7 jobs is to conserve ci bandwith in general and ensure we have enough to test with 3.9 were we can. > > Thanks! > > On Wed, Jan 6, 2021 at 8:28 AM Radosław Piliszek < > radoslaw.piliszek at gmail.com> wrote: > > > Sorry for top posting but just a general remark: > > > > Do note Debian 10 is using Python 3.7 and that is what Kolla is testing > > too. > > I know Debian is not considered a tested platform but people use it > > successfully. > > > > My opinion is, therefore, that we should keep 3.7 in classifiers. > > > > -yoctozepto > > > > On Wed, Jan 6, 2021 at 11:37 AM Dmitry Tantsur > > wrote: > > > > > > > > > > > > On Tue, Jan 5, 2021 at 10:53 PM Jeremy Stanley > > wrote: > > > > > > > > On 2021-01-05 22:32:58 +0100 (+0100), Pierre Riteau wrote: > > > > > There have been many patches submitted to drop the Python 3.7 > > > > > classifier from setup.cfg: > > > > > https://review.opendev.org/q/%2522remove+py37%2522 > > > > > The justification is that Wallaby tested runtimes only include 3.6 > > and 3.8. > > > > > > > > > > Most projects are merging these patches, but I've seen a couple of > > > > > objections from ironic and horizon: > > > > > > > > > > - https://review.opendev.org/c/openstack/python-ironicclient/+/769044 > > > > > - https://review.opendev.org/c/openstack/horizon/+/769237 > > > > > > > > > > What are the thoughts of the TC and of the overall community on this? > > > > > Should we really drop these classifiers when there are no > > > > > corresponding CI jobs, even though more Python versions may well be > > > > > supported? > > > > > > > > My recollection of the many discussions we held was that the runtime > > > > document would recommend the default python3 available in our > > > > targeted platforms, but that we would also make a best effort to > > > > test with the latest python3 available to us at the start of the > > > > cycle as well. It was suggested more than once that we should test > > > > all minor versions in between, but this was ruled out based on the > > > > additional CI resources it would consume for minimal gain. Instead > > > > we deemed that testing our target version and the latest available > > > > would give us sufficient confidence that, if those worked, the > > > > versions in between them were likely fine as well. Based on that, I > > > > think the versions projects claim to work with should be contiguous > > > > ranges, not contiguous lists of the exact versions tested (noting > > > > that those aren't particularly *exact* versions to begin with). > > > > > > > > > This is precisely my expectation: if we support 3.6 and 3.8, it's > > reasonable to suggest we support 3.7. Not supporting it gains us nothing. > > > > > > Dmitry > > > > > > > > > > > > > > > Apologies for the lack of references to old discussions, I can > > > > probably dig some up from the ML and TC meetings several years back > > > > of folks think it will help inform this further. > > > > -- > > > > Jeremy Stanley > > > > > > > > > > > > -- > > > Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn, > > > Commercial register: Amtsgericht Muenchen, HRB 153243, > > > Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael > > O'Neill > > > > From eblock at nde.ag Wed Jan 6 13:48:22 2021 From: eblock at nde.ag (Eugen Block) Date: Wed, 06 Jan 2021 13:48:22 +0000 Subject: [nova] workarounds and operator experience around bug 1522307/1908133 In-Reply-To: <7b4f6f10e682698dfaed22a86397f5b174fed7e8.camel@redhat.com> References: <7b4f6f10e682698dfaed22a86397f5b174fed7e8.camel@redhat.com> Message-ID: <20210106134822.Horde.dGo06NkPF_G8_AogeK9L2i7@webmail.nde.ag> Hi, we're using OpenStack with Ceph in production and also have customers doing that. From my point of view fixing nova to be able to deal with shared storage of course would improve many things, but it doesn't liberate you from monitoring your systems. Filling up a ceph cluster should be avoided and therefore proper monitoring is required. I assume you were able to resolve the frozen instances? Regards, Eugen Zitat von Sean Mooney : > On Tue, 2021-01-05 at 14:17 -0300, Rodrigo Barbieri wrote: >> Hi Nova folks and OpenStack operators! >> >> I have had some trouble recently where while using the "images_type = rbd" >> libvirt option my ceph cluster got filled up without I noticing and froze >> all my nova services and instances. >> >> I started digging and investigating why and how I could prevent or >> workaround this issue, but I didn't find a very reliable clean way. >> >> I documented all my steps and investigation in bug 1908133 [0]. It has been >> marked as a duplicate of 1522307 [1] which has been around for quite some >> time, so I am wondering if any operators have been using nova + ceph in >> production with "images_type = rbd" config set and how you have been >> handling/working around the issue. > > this is indeed a know issue and the long term plan to fix it was to > track shared storae > as a sharing resouce provide in plamcent. that never happend so > there si currenlty no mechanium > available to prevent this explcitly in nova. > > the disk filter which is nolonger used could prevnet the boot of a > vm that would fill the ceph pool but > it could not protect against two concurrent request form filling the pool. > > placement can protect against that due to the transational nature of > allocations which serialise > all resouce useage however since each host reports the total size of > the ceph pool as its local storage that wont work out of the box. > > as a quick hack what you can do is set the > [DEFAULT]/disk_allocation_ratio=(1/number of compute nodes) > https://docs.openstack.org/nova/latest/configuration/config.html#DEFAULT.disk_allocation_ratio > on each of your compute agents configs. > > > that will prevent over subscription however it has other negitve sidefects. > mainly that you will fail to scudle instance that could boot if a > host exced its 1/n usage > so unless you have perfectly blanced consumtion this is not a good approch. > > a better appoch but one that requires external scripting is to have > a chron job that will update the resrved > usaage of each of the disk_gb inventores to the actull amount of of > stoarge allocated form the pool. > > the real fix however is for nova to tack its shared usage in > placment correctly as a sharing resouce provide. > > its possible you might be able to do that via the porvider.yaml file > > by overriding the local disk_gb to 0 on all comupte nodes > then creating a singel haring resouce provider of disk_gb that > models the ceph pool. > > https://specs.openstack.org/openstack/nova-specs/specs/ussuri/approved/provider-config-file.html > currently that does not support the addtion of providers to placment > agggreate so while it could be used to 0 out the comptue node > disk inventoies and to create a sharing provider it with the > MISC_SHARES_VIA_AGGREGATE trait it cant do the final step of mapping > which compute nodes can consume form sharing provider via the > agggrate but you could do that form. > that assume that "sharing resouce provdiers" actully work. > > > bacialy what it comes down to today is you need to monitor the > avaiable resouce yourslef externally and ensure you never run out of > space. > that sucks but untill we proably track things in plamcent there is > nothign we can really do. > the two approch i suggested above might work for a subset of > usecasue but really this is a feature that need native suport in > nova to adress properly. > >> >> Thanks in advance! >> >> [0] https://bugs.launchpad.net/nova/+bug/1908133 >> [1] https://bugs.launchpad.net/nova/+bug/1522307 >> From fungi at yuggoth.org Wed Jan 6 15:11:42 2021 From: fungi at yuggoth.org (Jeremy Stanley) Date: Wed, 6 Jan 2021 15:11:42 +0000 Subject: [all][tc] Thoughts on Python 3.7 support In-Reply-To: References: <20210105215107.jap2c5evbkpu2u7n@yuggoth.org> Message-ID: <20210106151141.iqeedudrfkogwnka@yuggoth.org> On 2021-01-06 13:27:28 +0000 (+0000), Sean Mooney wrote: [...] > there is no requiremetn for project to maintain testing for py 3.7 > but that does not mean the cant elect to test it as an option > addtional runtime provided they test teh minium reuiqred vers > which are python 3.6 and 3.8 > > py 3.7 could be maintined as an optional runtime as we do for > python 3.9 but i think part of the motivation of droping the 3.7 > jobs is to conserve ci bandwith in general and ensure we have > enough to test with 3.9 were we can. [...] Sure, but that wasn't the question, it was in fact: On 2021-01-05 22:32:58 +0100 (+0100), Pierre Riteau wrote: > There have been many patches submitted to drop the Python 3.7 > classifier from setup.cfg: > https://review.opendev.org/q/%2522remove+py37%2522 The > justification is that Wallaby tested runtimes only include 3.6 and > 3.8. [...] > Should we really drop these classifiers when there are no > corresponding CI jobs, even though more Python versions may well > be supported? [...] -- Jeremy Stanley -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From emiller at genesishosting.com Wed Jan 6 15:48:19 2021 From: emiller at genesishosting.com (Eric K. Miller) Date: Wed, 6 Jan 2021 09:48:19 -0600 Subject: [kolla-ansible] Upgrading and skipping a release? In-Reply-To: References: <046E9C0290DD9149B106B72FC9156BEA04814FB6@gmsxchsvr01.thecreation.com> Message-ID: <046E9C0290DD9149B106B72FC9156BEA04814FBF@gmsxchsvr01.thecreation.com> > Hi Eric. What you're referring to is a fast-forward upgrade [1]. This > is not officially supported by Kolla Ansible, and not something we > test upstream. There was an effort a few years ago to implement it, > but it stalled. The test matrix does increase somewhat when you allow > FFUs, which is why I believe many projects such as Tripleo define > supported FFU jumps. One thing in particular that may catch you out is > some DB migrations or cleanup processes that happen at runtime may not > get executed. > > In short, I'd suggest going one release at a time. It's a pain, but > upgrades in Kolla are relatively sane. Thank you mark! Much appreciated. We were hoping to avoid any potential pitfalls with the Python 2.x to 3.x transition, but it looks like we need to simply test quick upgrades from one to the next. Regarding the QEMU/KVM kernel module version on the host, I'm assuming we need to plan for VM shutdown/restart since I "think" we may need a newer version for Ussuri or Victoria. Looks like we're running: (on CentOS 7) Compiled against library: libvirt 4.5.0 Using library: libvirt 4.5.0 Using API: QEMU 4.5.0 Running hypervisor: QEMU 2.12.0 Out of curiosity, have you used CloudLinux' KernelCare or any other hot-swap kernel module components to avoid downtime of a KVM host? Eric From hberaud at redhat.com Wed Jan 6 15:56:54 2021 From: hberaud at redhat.com (Herve Beraud) Date: Wed, 6 Jan 2021 16:56:54 +0100 Subject: [oslo][TC] Dropping lower-constraints testing In-Reply-To: <2f450b85dae98c9c5ae7d14cd2e734036bf78889.camel@redhat.com> References: <7679064.EuSn42jlT6@p1> <2f450b85dae98c9c5ae7d14cd2e734036bf78889.camel@redhat.com> Message-ID: Concerning Oslo this is a team decision/position and for now this isn't something general, so, you can still continue to test LC if it works for you. The TC still needs to decide if we should continue with that or not in an official manner. Sorry if my precedent message is misleading some of you. Le mer. 6 janv. 2021 à 14:25, Sean Mooney a écrit : > On Wed, 2021-01-06 at 13:43 +0100, Slawek Kaplonski wrote: > > Hi, > > > > Dnia środa, 6 stycznia 2021 13:00:31 CET Herve Beraud pisze: > > > Hello everyone, > > > > > > Here is an email to officialize our position on Olso concerning our > > > lower-constraints testing policy. > > > Indeed we reached a consensus during our last meeting and all the Oslo > > > cores who spoke agreed with this decision to drop the L.C tests [1]. > > > > > > So we already started to drop lower-constraints jobs on Oslo to unlock > our > > > gates. > > > > Sorry if my question shouldn't be in that thread but does that mean that > other > > projects should/can drop lower constraints jobs too? Is it some general, > > OpenStack wide decision or it depends on the project? > lower constratis is not a required part fo the PTI > https://governance.openstack.org/tc/reference/pti/python.html > > https://governance.openstack.org/tc/reference/project-testing-interface.html > so its technially a per project desision as far as i am aware. > > while project were encouraged to adopt lower constratit testing we did not > require all project > to provide it and i belive there are some that dont unless im mistaken. > > so neutron could drop lc testing too i belive if it desired too. > unless im misinterperting things > > > > > > > > > Thanks to everyone who joined the discussion and thanks for reading! > > > > > > [1] > > > > http://eavesdrop.openstack.org/meetings/oslo/2021/oslo.2021-01-04-16.00.log > . > > > txt #topic Dropping lower-constraints testing > > > > > > Le ven. 18 déc. 2020 à 20:34, Moises Guimaraes de Medeiros < > > > > > > moguimar at redhat.com> a écrit : > > > > +1 > > > > > > > > On Fri, Dec 18, 2020 at 4:46 PM Ghanshyam Mann < > gmann at ghanshyammann.com> > > > > > > > > wrote: > > > > > ---- On Fri, 18 Dec 2020 08:54:26 -0600 hberaud < > hberaud at redhat.com> > > > > > > > > > > wrote ---- > > > > > > > > > > > Hello, > > > > > > As you already surely know, we (the openstack project) > currently face > > > > > > > > > > some issues with our lower-constraints jobs due to pip's latest > resolver > > > > > feature. > > > > > > > > > > > By discussing this topic with Thierry Carrez (ttx) from an oslo > point > > > > > > > > > > of view, we reached the same conclusion that it is more > appropriate to > > > > > drop > > > > > this kind of tests because the complexity and recurring pain > neededto > > > > > maintain them now exceeds the benefits provided by this > mechanismes. > > > > > > > > > > > Also we should notice that the number of active maintainers is > > > > > > > > > > declining, so we think that this is the shortest path to solve this > > > > > problem > > > > > on oslo for now and for the future too. > > > > > > > > > > > In a first time I tried to fix our gates by fixing our > > > > > > > > > > lower-constraints project by project but with around ~36 projects > to > > > > > maintain this is a painful task, especially due to nested oslo > layers > > > > > inside oslo himself... I saw the face of the hell of dependencies. > > > > > > > > > > > So, in a second time I submitted a series of patches to drop > these > > > > > > > > > > tests [1]. > > > > > > > > > > > But before moving further with that we would appreciate > discussing > > > > > > > > > > this with the TC. For now the patches are ready and we just have > to push > > > > > the good button accordingly to our choices (+W or abandon). > > > > > > > > > > > Normally all the oslo projects that need to be fixed are > covered by > > > > > > > > > > [1]. > > > > > > > > > > > Thoughts? > > > > > > > > > > +1, I think it's not worth to keep maintaining them which is > taking too > > > > > much effort. > > > > > > > > > > -gmann > > > > > > > > > > > Thanks for reading. > > > > > > > > > > > > [1] > > > > > > > > > > > https://review.opendev.org/q/topic:%22oslo_lc_drop%22+(status:open%20OR%2 > > > > > 0status:merged)>> > > > > > > -- > > > > > > Hervé BeraudSenior Software Engineer at Red Hatirc: > hberaudhttps:// > > > > > > > > > > github.com/4383/https://twitter.com/4383hberaud > > > > > > > > > > > -----BEGIN PGP SIGNATURE----- > > > > > > > > > > > > wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ > > > > > > Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ > > > > > > RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP > > > > > > F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G > > > > > > 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g > > > > > > glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw > > > > > > m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ > > > > > > hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 > > > > > > qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y > > > > > > F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 > > > > > > B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O > > > > > > v6rDpkeNksZ9fFSyoY2o > > > > > > =ECSj > > > > > > -----END PGP SIGNATURE----- > > > > > > > > -- > > > > > > > > Moisés Guimarães > > > > > > > > Software Engineer > > > > > > > > Red Hat > > > > > > > > > > > > > > -- > > > Hervé Beraud > > > Senior Software Engineer at Red Hat > > > irc: hberaud > > > https://github.com/4383/ > > > https://twitter.com/4383hberaud > > > > > > > > -- Hervé Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/ https://twitter.com/4383hberaud -----BEGIN PGP SIGNATURE----- wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O v6rDpkeNksZ9fFSyoY2o =ECSj -----END PGP SIGNATURE----- -------------- next part -------------- An HTML attachment was scrubbed... URL: From openstack at nemebean.com Wed Jan 6 16:30:52 2021 From: openstack at nemebean.com (Ben Nemec) Date: Wed, 6 Jan 2021 10:30:52 -0600 Subject: [oslo][TC] Dropping lower-constraints testing In-Reply-To: References: <7679064.EuSn42jlT6@p1> <2f450b85dae98c9c5ae7d14cd2e734036bf78889.camel@redhat.com> Message-ID: <67f45735-6270-3c33-62d4-ea07ea9285b6@nemebean.com> On 1/6/21 9:56 AM, Herve Beraud wrote: > Concerning Oslo this is a team decision/position and for now this isn't > something general, so, you can still continue to test LC if it works for > you. The only issue I see is that based on our discussions, the big problem with lower-constraints testing is that it requires all of your dependencies to have compatible l-c too, so if Oslo drops testing of that it's going to make it extremely difficult for any other OpenStack projects to maintain it. > > The TC still needs to  decide if we should continue with that or not in > an official manner. > > Sorry if my precedent message is misleading some of you. > > Le mer. 6 janv. 2021 à 14:25, Sean Mooney > a écrit : > > On Wed, 2021-01-06 at 13:43 +0100, Slawek Kaplonski wrote: > > Hi, > > > > Dnia środa, 6 stycznia 2021 13:00:31 CET Herve Beraud pisze: > > > Hello everyone, > > > > > > Here is an email to officialize our position on Olso concerning our > > > lower-constraints testing policy. > > > Indeed we reached a consensus during our last meeting and all > the Oslo > > > cores who spoke agreed with this decision to drop the L.C tests > [1]. > > > > > > So we already started to drop lower-constraints jobs on Oslo to > unlock our > > > gates. > > > > Sorry if my question shouldn't be in that thread but does that > mean that other > > projects should/can drop lower constraints jobs too? Is it some > general, > > OpenStack wide decision or it depends on the project? > lower constratis is not a required part fo the PTI > https://governance.openstack.org/tc/reference/pti/python.html > https://governance.openstack.org/tc/reference/project-testing-interface.html > so its technially a per project desision as far as i am aware. > > while project were encouraged to adopt lower constratit testing we > did not require all project > to provide it and i belive there are some that dont unless im mistaken. > > so neutron could drop lc testing too i belive if it desired too. > unless im misinterperting things > > > > > > > > > Thanks to everyone who joined the discussion and thanks for > reading! > > > > > > [1] > > > > http://eavesdrop.openstack.org/meetings/oslo/2021/oslo.2021-01-04-16.00.log. > > > txt #topic Dropping lower-constraints testing > > > > > > Le ven. 18 déc. 2020 à 20:34, Moises Guimaraes de Medeiros < > > > > > > moguimar at redhat.com > a écrit : > > > > +1 > > > > > > > > On Fri, Dec 18, 2020 at 4:46 PM Ghanshyam Mann > > > > > > > > > > wrote: > > > > >  ---- On Fri, 18 Dec 2020 08:54:26 -0600 hberaud > > > > > > > > > > > > wrote ---- > > > > > > > > > >  > Hello, > > > > >  > As you already surely know, we (the openstack project) > currently face > > > > > > > > > > some issues with our lower-constraints jobs due to pip's > latest  resolver > > > > > feature. > > > > > > > > > >  > By discussing this topic with Thierry Carrez (ttx) from > an oslo point > > > > > > > > > > of view, we reached the same conclusion that it is more > appropriate to > > > > > drop > > > > > this kind of tests because the complexity and recurring > pain neededto > > > > > maintain them now exceeds the benefits provided by this > mechanismes. > > > > > > > > > >  > Also we should notice that the number of active > maintainers is > > > > > > > > > > declining, so we think that this is the shortest path to > solve this > > > > > problem > > > > > on oslo for now and for the future too. > > > > > > > > > >  > In a first time I tried to fix our gates by fixing our > > > > > > > > > > lower-constraints project by project but with around ~36 > projects to > > > > > maintain this is a painful task, especially due to nested > oslo layers > > > > > inside oslo himself... I saw the face of the hell of > dependencies. > > > > > > > > > >  > So, in a second time I submitted a series of patches to > drop these > > > > > > > > > > tests [1]. > > > > > > > > > >  > But before moving further with that we would appreciate > discussing > > > > > > > > > > this with the TC. For now the patches are ready and we just > have to push > > > > > the good button accordingly to our choices (+W or abandon). > > > > > > > > > >  > Normally all the oslo projects that need to be fixed are > covered by > > > > > > > > > > [1]. > > > > > > > > > >  > Thoughts? > > > > > > > > > > +1, I think it's not worth to keep maintaining them which > is taking too > > > > > much effort. > > > > > > > > > > -gmann > > > > > > > > > >  > Thanks for reading. > > > > >  > > > > > >  > [1] > > > > > > > > > > > https://review.opendev.org/q/topic:%22oslo_lc_drop%22+(status:open%20OR%2 > > > > > 0status:merged)>> > > > > >  > -- > > > > >  > Hervé BeraudSenior Software Engineer at Red Hatirc: > hberaudhttps:// > > > > > > > > > > github.com/4383/https://twitter.com/4383hberaud > > > > > > > > > > >  > -----BEGIN PGP SIGNATURE----- > > > > >  > > > > > >  > > wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ > > > > >  > > Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ > > > > >  > > RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP > > > > >  > > F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G > > > > >  > > 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g > > > > >  > > glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw > > > > >  > > m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ > > > > >  > > hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 > > > > >  > > qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y > > > > >  > > F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 > > > > >  > > B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O > > > > >  > v6rDpkeNksZ9fFSyoY2o > > > > >  > =ECSj > > > > >  > -----END PGP SIGNATURE----- > > > > > > > > -- > > > > > > > > Moisés Guimarães > > > > > > > > Software Engineer > > > > > > > > Red Hat > > > > > > > > > > > > > > -- > > > Hervé Beraud > > > Senior Software Engineer at Red Hat > > > irc: hberaud > > > https://github.com/4383/ > > > https://twitter.com/4383hberaud > > > > > > > > > > -- > Hervé Beraud > Senior Software Engineer at Red Hat > irc: hberaud > https://github.com/4383/ > https://twitter.com/4383hberaud > -----BEGIN PGP SIGNATURE----- > > wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ > Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ > RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP > F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G > 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g > glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw > m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ > hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 > qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y > F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 > B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O > v6rDpkeNksZ9fFSyoY2o > =ECSj > -----END PGP SIGNATURE----- > From openstack at nemebean.com Wed Jan 6 16:34:35 2021 From: openstack at nemebean.com (Ben Nemec) Date: Wed, 6 Jan 2021 10:34:35 -0600 Subject: [all][tc] Thoughts on Python 3.7 support In-Reply-To: <20210105215107.jap2c5evbkpu2u7n@yuggoth.org> References: <20210105215107.jap2c5evbkpu2u7n@yuggoth.org> Message-ID: <68d4b804-5729-e313-7f29-6c7b14166c5c@nemebean.com> On 1/5/21 3:51 PM, Jeremy Stanley wrote: > On 2021-01-05 22:32:58 +0100 (+0100), Pierre Riteau wrote: >> There have been many patches submitted to drop the Python 3.7 >> classifier from setup.cfg: >> https://review.opendev.org/q/%2522remove+py37%2522 >> The justification is that Wallaby tested runtimes only include 3.6 and 3.8. >> >> Most projects are merging these patches, but I've seen a couple of >> objections from ironic and horizon: >> >> - https://review.opendev.org/c/openstack/python-ironicclient/+/769044 >> - https://review.opendev.org/c/openstack/horizon/+/769237 >> >> What are the thoughts of the TC and of the overall community on this? >> Should we really drop these classifiers when there are no >> corresponding CI jobs, even though more Python versions may well be >> supported? > > My recollection of the many discussions we held was that the runtime > document would recommend the default python3 available in our > targeted platforms, but that we would also make a best effort to > test with the latest python3 available to us at the start of the > cycle as well. It was suggested more than once that we should test > all minor versions in between, but this was ruled out based on the > additional CI resources it would consume for minimal gain. Instead > we deemed that testing our target version and the latest available > would give us sufficient confidence that, if those worked, the > versions in between them were likely fine as well. Based on that, I > think the versions projects claim to work with should be contiguous > ranges, not contiguous lists of the exact versions tested (noting > that those aren't particularly *exact* versions to begin with). > > Apologies for the lack of references to old discussions, I can > probably dig some up from the ML and TC meetings several years back > of folks think it will help inform this further. > For what little it's worth, that jives with my hazy memories of the discussion too. The assumption was that if we tested the upper and lower bounds of our Python versions then the ones in the middle would be unlikely to break. It was a compromise to support multiple versions of Python without spending a ton of testing resources on it. From fungi at yuggoth.org Wed Jan 6 17:21:39 2021 From: fungi at yuggoth.org (Jeremy Stanley) Date: Wed, 6 Jan 2021 17:21:39 +0000 Subject: [oslo][TC] Dropping lower-constraints testing In-Reply-To: <67f45735-6270-3c33-62d4-ea07ea9285b6@nemebean.com> References: <7679064.EuSn42jlT6@p1> <2f450b85dae98c9c5ae7d14cd2e734036bf78889.camel@redhat.com> <67f45735-6270-3c33-62d4-ea07ea9285b6@nemebean.com> Message-ID: <20210106172138.33smfj3ba45nse57@yuggoth.org> On 2021-01-06 10:30:52 -0600 (-0600), Ben Nemec wrote: [...] > The only issue I see is that based on our discussions, the big > problem with lower-constraints testing is that it requires all of > your dependencies to have compatible l-c too, so if Oslo drops > testing of that it's going to make it extremely difficult for any > other OpenStack projects to maintain it. [...] I hardly see how projects could ever expect this to be the case anyway, as the vast majority of OpenStack dependencies are maintained outside the OpenStack community and don't maintain any lower-bounds testing of their own. -- Jeremy Stanley -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From gmann at ghanshyammann.com Wed Jan 6 17:49:34 2021 From: gmann at ghanshyammann.com (Ghanshyam Mann) Date: Wed, 06 Jan 2021 11:49:34 -0600 Subject: [all][tc] Thoughts on Python 3.7 support In-Reply-To: <68d4b804-5729-e313-7f29-6c7b14166c5c@nemebean.com> References: <20210105215107.jap2c5evbkpu2u7n@yuggoth.org> <68d4b804-5729-e313-7f29-6c7b14166c5c@nemebean.com> Message-ID: <176d8d1747f.e25ad718873974.5391430581306589135@ghanshyammann.com> ---- On Wed, 06 Jan 2021 10:34:35 -0600 Ben Nemec wrote ---- > > > On 1/5/21 3:51 PM, Jeremy Stanley wrote: > > On 2021-01-05 22:32:58 +0100 (+0100), Pierre Riteau wrote: > >> There have been many patches submitted to drop the Python 3.7 > >> classifier from setup.cfg: > >> https://review.opendev.org/q/%2522remove+py37%2522 > >> The justification is that Wallaby tested runtimes only include 3.6 and 3.8. > >> > >> Most projects are merging these patches, but I've seen a couple of > >> objections from ironic and horizon: > >> > >> - https://review.opendev.org/c/openstack/python-ironicclient/+/769044 > >> - https://review.opendev.org/c/openstack/horizon/+/769237 > >> > >> What are the thoughts of the TC and of the overall community on this? > >> Should we really drop these classifiers when there are no > >> corresponding CI jobs, even though more Python versions may well be > >> supported? > > > > My recollection of the many discussions we held was that the runtime > > document would recommend the default python3 available in our > > targeted platforms, but that we would also make a best effort to > > test with the latest python3 available to us at the start of the > > cycle as well. It was suggested more than once that we should test > > all minor versions in between, but this was ruled out based on the > > additional CI resources it would consume for minimal gain. Instead > > we deemed that testing our target version and the latest available > > would give us sufficient confidence that, if those worked, the > > versions in between them were likely fine as well. Based on that, I > > think the versions projects claim to work with should be contiguous > > ranges, not contiguous lists of the exact versions tested (noting > > that those aren't particularly *exact* versions to begin with). > > > > Apologies for the lack of references to old discussions, I can > > probably dig some up from the ML and TC meetings several years back > > of folks think it will help inform this further. > > > > For what little it's worth, that jives with my hazy memories of the > discussion too. The assumption was that if we tested the upper and lower > bounds of our Python versions then the ones in the middle would be > unlikely to break. It was a compromise to support multiple versions of > Python without spending a ton of testing resources on it. Exactly, py3.7 is not broken for OpenStack so declaring it not supported is not the right thing. I remember the discussion when we declared the wallaby (probably from Victoria) testing runtime, we decided if we test py3.6 and py3.8 it means we are not going to break py3.7 support so indirectly it is tested and supported. And testing runtime does not mean we have to drop everything else testing means projects are all welcome to keep running the py3.7 testing job on the gate there is no harm in that. In both cases, either project has an explicit py3.7 job or not we should not remove it from classifiers. -gmann > > From gmann at ghanshyammann.com Wed Jan 6 17:59:24 2021 From: gmann at ghanshyammann.com (Ghanshyam Mann) Date: Wed, 06 Jan 2021 11:59:24 -0600 Subject: [all][tc] Dropping lower-constraints testing from all projects Message-ID: <176d8da769b.b6edb13b874337.4809906168220534198@ghanshyammann.com> Hello Everyone, You might have seen the discussion around dropping the lower constraints testing as it becomes more challenging than the current value of doing it. Few of the ML thread around this discussion: - http://lists.openstack.org/pipermail/openstack-discuss/2020-December/019521.html - http://lists.openstack.org/pipermail/openstack-discuss/2020-December/019390.html As Oslo and many other project dropping or already dropped it, we should decide it for all other projects also otherwise it can be more changing than it is currently. We have not defined it in PTI or testing runtime so it is always up to projects if they still want to keep it but we should decide a general recommendation here. -gmann From gmann at ghanshyammann.com Wed Jan 6 18:00:12 2021 From: gmann at ghanshyammann.com (Ghanshyam Mann) Date: Wed, 06 Jan 2021 12:00:12 -0600 Subject: [oslo][TC] Dropping lower-constraints testing In-Reply-To: <7679064.EuSn42jlT6@p1> References: <7679064.EuSn42jlT6@p1> Message-ID: <176d8db30c5.11e87476b874375.1651955499533176435@ghanshyammann.com> ---- On Wed, 06 Jan 2021 06:43:18 -0600 Slawek Kaplonski wrote ---- > Hi, > > Dnia środa, 6 stycznia 2021 13:00:31 CET Herve Beraud pisze: > > Hello everyone, > > > > Here is an email to officialize our position on Olso concerning our > > lower-constraints testing policy. > > Indeed we reached a consensus during our last meeting and all the Oslo > > cores who spoke agreed with this decision to drop the L.C tests [1]. > > > > So we already started to drop lower-constraints jobs on Oslo to unlock our > > gates. > > Sorry if my question shouldn't be in that thread but does that mean that other > projects should/can drop lower constraints jobs too? Is it some general, > OpenStack wide decision or it depends on the project? Yeah this is a good question till now we have been discussing specific project wise dropping like oslo in this thread and Ironic and other projects in another discussion. I am starting a separate thread to discuss it for all the projects as a general recommendation. -http://lists.openstack.org/pipermail/openstack-discuss/2021-January/019672.html -gmann > > > > > Thanks to everyone who joined the discussion and thanks for reading! > > > > [1] > > http://eavesdrop.openstack.org/meetings/oslo/2021/oslo.2021-01-04-16.00.log. > > txt #topic Dropping lower-constraints testing > > > > Le ven. 18 déc. 2020 à 20:34, Moises Guimaraes de Medeiros < > > > > moguimar at redhat.com> a écrit : > > > +1 > > > > > > On Fri, Dec 18, 2020 at 4:46 PM Ghanshyam Mann > > > > > > wrote: > > >> ---- On Fri, 18 Dec 2020 08:54:26 -0600 hberaud > > >> > > >> wrote ---- > > >> > > >> > Hello, > > >> > As you already surely know, we (the openstack project) currently face > > >> > > >> some issues with our lower-constraints jobs due to pip's latest resolver > > >> feature. > > >> > > >> > By discussing this topic with Thierry Carrez (ttx) from an oslo point > > >> > > >> of view, we reached the same conclusion that it is more appropriate to > > >> drop > > >> this kind of tests because the complexity and recurring pain neededto > > >> maintain them now exceeds the benefits provided by this mechanismes. > > >> > > >> > Also we should notice that the number of active maintainers is > > >> > > >> declining, so we think that this is the shortest path to solve this > > >> problem > > >> on oslo for now and for the future too. > > >> > > >> > In a first time I tried to fix our gates by fixing our > > >> > > >> lower-constraints project by project but with around ~36 projects to > > >> maintain this is a painful task, especially due to nested oslo layers > > >> inside oslo himself... I saw the face of the hell of dependencies. > > >> > > >> > So, in a second time I submitted a series of patches to drop these > > >> > > >> tests [1]. > > >> > > >> > But before moving further with that we would appreciate discussing > > >> > > >> this with the TC. For now the patches are ready and we just have to push > > >> the good button accordingly to our choices (+W or abandon). > > >> > > >> > Normally all the oslo projects that need to be fixed are covered by > > >> > > >> [1]. > > >> > > >> > Thoughts? > > >> > > >> +1, I think it's not worth to keep maintaining them which is taking too > > >> much effort. > > >> > > >> -gmann > > >> > > >> > Thanks for reading. > > >> > > > >> > [1] > > >> > > >> https://review.opendev.org/q/topic:%22oslo_lc_drop%22+(status:open%20OR%2 > > >> 0status:merged)>> > > >> > -- > > >> > Hervé BeraudSenior Software Engineer at Red Hatirc: hberaudhttps:// > > >> > > >> github.com/4383/https://twitter.com/4383hberaud > > >> > > >> > -----BEGIN PGP SIGNATURE----- > > >> > > > >> > wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ > > >> > Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ > > >> > RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP > > >> > F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G > > >> > 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g > > >> > glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw > > >> > m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ > > >> > hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 > > >> > qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y > > >> > F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 > > >> > B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O > > >> > v6rDpkeNksZ9fFSyoY2o > > >> > =ECSj > > >> > -----END PGP SIGNATURE----- > > > > > > -- > > > > > > Moisés Guimarães > > > > > > Software Engineer > > > > > > Red Hat > > > > > > > > > > -- > > Hervé Beraud > > Senior Software Engineer at Red Hat > > irc: hberaud > > https://github.com/4383/ > > https://twitter.com/4383hberaud > > > -- > Slawek Kaplonski > Principal Software Engineer > Red Hat From strigazi at gmail.com Wed Jan 6 18:22:48 2021 From: strigazi at gmail.com (Spyros Trigazis) Date: Wed, 6 Jan 2021 19:22:48 +0100 Subject: [all][tc] Dropping lower-constraints testing from all projects In-Reply-To: <176d8da769b.b6edb13b874337.4809906168220534198@ghanshyammann.com> References: <176d8da769b.b6edb13b874337.4809906168220534198@ghanshyammann.com> Message-ID: Should it also be dropped from stable branches? eg in magnum, it blocks the gate for stable/victoria atm. Cheers, Spyros On Wed, Jan 6, 2021 at 7:00 PM Ghanshyam Mann wrote: > Hello Everyone, > > You might have seen the discussion around dropping the lower constraints > testing as it becomes more challenging than the current value of doing it. > > Few of the ML thread around this discussion: > > - > http://lists.openstack.org/pipermail/openstack-discuss/2020-December/019521.html > - > http://lists.openstack.org/pipermail/openstack-discuss/2020-December/019390.html > > As Oslo and many other project dropping or already dropped it, we should > decide it for all > other projects also otherwise it can be more changing than it is > currently. > > We have not defined it in PTI or testing runtime so it is always up to > projects if they still > want to keep it but we should decide a general recommendation here. > > -gmann > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From fungi at yuggoth.org Wed Jan 6 18:33:42 2021 From: fungi at yuggoth.org (Jeremy Stanley) Date: Wed, 6 Jan 2021 18:33:42 +0000 Subject: [all][tc] Dropping lower-constraints testing from all projects In-Reply-To: References: <176d8da769b.b6edb13b874337.4809906168220534198@ghanshyammann.com> Message-ID: <20210106183342.x53p5vbf5sw4nxz7@yuggoth.org> On 2021-01-06 19:22:48 +0100 (+0100), Spyros Trigazis wrote: > Should it also be dropped from stable branches? > eg in magnum, it blocks the gate for stable/victoria atm. [...] If it's broken, I'd say you have three choices: 1. fix the job on those branches 2. drop the job from those branches 3. EOL those branches It's a bit soon to be considering #3 for stable/victoria, so you're really left with options #1 and #2 there. -- Jeremy Stanley -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From mighani6406 at gmail.com Wed Jan 6 07:08:19 2021 From: mighani6406 at gmail.com (mohammad mighani) Date: Wed, 6 Jan 2021 10:38:19 +0330 Subject: failed to launch openstack instance when integrating with odl Message-ID: Hi everyone I tried to integrate Openstack train with Opendaylight magnesium and my references were [1] and [2] but after doing all the steps, the instance failed to launch. I changed port_binding_controller in [ml2_odl] section in the ml2_conf.ini file from pseudo-agentdb-binding to legacy-port-binding and then the instance launched but the status of router interfaces was still down. I have a controller node and a compute node. and Opendaylight runs on the controller node. nova-compute.log: INFO nova.virt.libvirt.driver [-] [instance: 975fa79e-6567-4385-be87-9d12a8eb3e94] Instance destroyed successfully. 2021-01-02 12:33:23.383 25919 ERROR vif_plug_ovs.ovsdb.impl_vsctl [req-a0a7ebf0-7e63-4c60-a8d2-07c05f1aa4f4 04c7685a2166481a9ace54eb5e71f6e5 ca28ee1038254649ad133d5f09f7a186 - default default] Unable to execute ['ovs-vsctl', '--timeout=120', '--oneline', '--format=json', '--db=tcp: 127.0.0.1:6640', '--', '--if-exists', 'del-port', 'br-int', 'tap50eb0b68-a4']. Exception: Unexpected error while running command. Command: ovs-vsctl --timeout=120 --oneline --format=json --db=tcp: 127.0.0.1:6640 -- --if-exists del-port br-int tap50eb0b68-a4 Exit code: 1 Stdout: '' Stderr: 'ovs-vsctl: tcp:127.0.0.1:6640: database connection failed (Connection refused)\n': oslo_concurrency.processutils.ProcessExecutionError: Unexpected error while running command. controller ovs: Manager "tcp:192.168.222.48:6640" is_connected: true Bridge br-int Controller "tcp:192.168.222.48:6653" is_connected: true fail_mode: secure Port tune52c5c73a50 Interface tune52c5c73a50 type: vxlan options: {key=flow, local_ip="10.0.0.31", remote_ip="10.0.0.11"} Port br-int Interface br-int type: internal Bridge br-ex Port br-ex Interface br-ex type: internal Port ens160 Interface ens160 ovs_version: "2.13.1" compute ovs: Manager "tcp:192.168.222.48:6640" is_connected: true Bridge br-int Controller "tcp:192.168.222.48:6653" is_connected: true fail_mode: secure Port br-int Interface br-int type: internal Port tun34b3712d975 Interface tun34b3712d975 type: vxlan options: {key=flow, local_ip="10.0.0.11", remote_ip="10.0.0.11"} Port tund5123ce5b8a Interface tund5123ce5b8a type: vxlan options: {key=flow, local_ip="10.0.0.11", remote_ip="10.0.0.31"} ovs_version: "2.13.1" -------------- next part -------------- An HTML attachment was scrubbed... URL: From elfosardo at gmail.com Wed Jan 6 09:09:56 2021 From: elfosardo at gmail.com (Riccardo Pittau) Date: Wed, 6 Jan 2021 10:09:56 +0100 Subject: tinyipa cannot boot OS of baremetal node In-Reply-To: References: Message-ID: Hello Ankele, if you're using ironic on production servers I suggest you to build and use ironic-python-agent images based on diskimage-builder as explained here: https://docs.openstack.org/ironic-python-agent-builder/latest/admin/dib.html The tinyipa image is best suited for testing and development and not recommended for production usage. Thanks, Riccardo On Tue, Jan 5, 2021 at 5:45 PM Ankele zhang wrote: > Hi~ > > My Rocky OpenStack platform deployed with official documents, includes > Keystone/Cinder/Neutron/Nova and Ironic. > > I used to boot my baremetal nodes by CoreOS downloaded on > https://tarballs.opendev.org/openstack/ironic-python-agent/coreos/files/ > > > Since I want to customize my own HardwareManager for configuring RAID, I > have build TinyIPA image tinyipa.tar.gz and tinyipa.vmlinuz with > ironic-python-agent-builder(master branch) and ironic-python-agent(rocky > branch). Here are all the products of the build process. > [image: image.png] > Then I used these two images to create the baremetal node, and boot nova > server, but I didn't get the results I wanted, it couldn't enter the > ramdisk and always in 'wait call-back' state. as following > > [image: image.png] > I got nothing in /var/log/ironic/ironig-conductor.log and > /var/log/nova/nova-compute.log > > I don't know if these two image (tinyipa.tar.gz and tinyipa.vmlinuz) are > valid for Ironic. If not, how can I customize HardwareManager? > > Looking forward to hearing from you. > > Ankele > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 126537 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 27968 bytes Desc: not available URL: From dtantsur at redhat.com Wed Jan 6 17:08:57 2021 From: dtantsur at redhat.com (Dmitry Tantsur) Date: Wed, 6 Jan 2021 18:08:57 +0100 Subject: tinyipa cannot boot OS of baremetal node In-Reply-To: References: Message-ID: Hi, TinyIPA may not work for real hardware, you need to either build a custom CoreOS image or a DIB-based image. Dmitry On Tue, Jan 5, 2021 at 5:39 PM Ankele zhang wrote: > Hi~ > > My Rocky OpenStack platform deployed with official documents, includes > Keystone/Cinder/Neutron/Nova and Ironic. > > I used to boot my baremetal nodes by CoreOS downloaded on > https://tarballs.opendev.org/openstack/ironic-python-agent/coreos/files/ > > > Since I want to customize my own HardwareManager for configuring RAID, I > have build TinyIPA image tinyipa.tar.gz and tinyipa.vmlinuz with > ironic-python-agent-builder(master branch) and ironic-python-agent(rocky > branch). Here are all the products of the build process. > [image: image.png] > Then I used these two images to create the baremetal node, and boot nova > server, but I didn't get the results I wanted, it couldn't enter the > ramdisk and always in 'wait call-back' state. as following > > [image: image.png] > I got nothing in /var/log/ironic/ironig-conductor.log and > /var/log/nova/nova-compute.log > > I don't know if these two image (tinyipa.tar.gz and tinyipa.vmlinuz) are > valid for Ironic. If not, how can I customize HardwareManager? > > Looking forward to hearing from you. > > Ankele > > -- Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 126537 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 27968 bytes Desc: not available URL: From gmann at ghanshyammann.com Wed Jan 6 18:55:15 2021 From: gmann at ghanshyammann.com (Ghanshyam Mann) Date: Wed, 06 Jan 2021 12:55:15 -0600 Subject: [all][tc] Dropping lower-constraints testing from all projects In-Reply-To: <20210106183342.x53p5vbf5sw4nxz7@yuggoth.org> References: <176d8da769b.b6edb13b874337.4809906168220534198@ghanshyammann.com> <20210106183342.x53p5vbf5sw4nxz7@yuggoth.org> Message-ID: <176d90d9718.b0b2e245876074.7056276878731396330@ghanshyammann.com> ---- On Wed, 06 Jan 2021 12:33:42 -0600 Jeremy Stanley wrote ---- > On 2021-01-06 19:22:48 +0100 (+0100), Spyros Trigazis wrote: > > Should it also be dropped from stable branches? > > eg in magnum, it blocks the gate for stable/victoria atm. > [...] > > If it's broken, I'd say you have three choices: > > 1. fix the job on those branches > > 2. drop the job from those branches > > 3. EOL those branches > > It's a bit soon to be considering #3 for stable/victoria, so you're > really left with options #1 and #2 there. I will suggest dropping the job as it can end up spending the same amount of effort to fix the job on stable or master. If we keep fixing on stable then we can fix on the master and backport so it is better to drop from all gates including the stable branch. -gmann > -- > Jeremy Stanley > From strigazi at gmail.com Wed Jan 6 19:01:50 2021 From: strigazi at gmail.com (Spyros Trigazis) Date: Wed, 6 Jan 2021 20:01:50 +0100 Subject: [all][tc] Dropping lower-constraints testing from all projects In-Reply-To: <176d90d9718.b0b2e245876074.7056276878731396330@ghanshyammann.com> References: <176d8da769b.b6edb13b874337.4809906168220534198@ghanshyammann.com> <20210106183342.x53p5vbf5sw4nxz7@yuggoth.org> <176d90d9718.b0b2e245876074.7056276878731396330@ghanshyammann.com> Message-ID: Let's decide on a topic and/or story to track it? eg lc_drop Spyros On Wed, Jan 6, 2021 at 7:55 PM Ghanshyam Mann wrote: > ---- On Wed, 06 Jan 2021 12:33:42 -0600 Jeremy Stanley > wrote ---- > > On 2021-01-06 19:22:48 +0100 (+0100), Spyros Trigazis wrote: > > > Should it also be dropped from stable branches? > > > eg in magnum, it blocks the gate for stable/victoria atm. > > [...] > > > > If it's broken, I'd say you have three choices: > > > > 1. fix the job on those branches > > > > 2. drop the job from those branches > > > > 3. EOL those branches > > > > It's a bit soon to be considering #3 for stable/victoria, so you're > > really left with options #1 and #2 there. > > I will suggest dropping the job as it can end up spending the same amount > of > effort to fix the job on stable or master. If we keep fixing on stable then > we can fix on the master and backport so it is better to drop from all > gates > including the stable branch. > > -gmann > > > -- > > Jeremy Stanley > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From zigo at debian.org Wed Jan 6 20:32:43 2021 From: zigo at debian.org (Thomas Goirand) Date: Wed, 6 Jan 2021 21:32:43 +0100 Subject: [neutron] Next step for BGP routed networks over segmented provider infrastructure segments Message-ID: Hi Ryan, and all of the Neutron team, Today, I'm happy to let you know that I've been able to finish the patch and that it's merged: https://review.opendev.org/c/openstack/neutron/+/669395 I also managed to add some docs to Neutron about it: https://docs.openstack.org/neutron/latest/admin/config-bgp-floating-ip-over-l2-segmented-network.html We've used it in a pre-production environment, and it just works as expected, it's kind of great. However, there's some feature gaps that would need to be addressed. Namely: - external-gateway of routers aren't advertized - we can't do direct attach of public IPs to VMs - I failed adding IPv6 dual stack to this setup Let me go into more details for each of these 3 points. 1/ No BGP advertizing for the router default gateways When doing: openstack router set --external-gateway we then get this type of port: # openstack port show -c binding_vif_details -c binding_vif_type +---------------------+-------------------------------------------------------------------------------------------------------------+ | Field | Value | +---------------------+-------------------------------------------------------------------------------------------------------------+ | binding_vif_details | bridge_name='br-int', connectivity='l2', datapath_type='system', ovs_hybrid_plug='True', port_filter='True' | | binding_vif_type | ovs | +---------------------+-------------------------------------------------------------------------------------------------------------+ which doesn't match the type of port we have for floating IPs: # openstack port show -c binding_vif_details -c binding_vif_type +---------------------+---------+ | Field | Value | +---------------------+---------+ | binding_vif_details | | | binding_vif_type | unbound | +---------------------+---------+ and then, the next HOP for the router gateway isn't advertized over BGP. Do you know how we could get neutron-dynamic-routing to do that advertizing, with the next HOP on the network node(s)? Where should that code be patch? Inside Neutron, or in neutron-dynamic-routing? Is this really related to the port type as I've showed above? 2/ No direct attach to VM ports We can't attach a port with an IP network:routed directly to a VM. I tried to add the subnet type "compute:nova" to the floating IP subnet, but that didn't do it: Neutron refuses to attach the port to a VM. Do you know why? How and what and where should we patch Neutron to fix this? 3/ IPv6 dual stack I tried to setup a dual-stack network, and failed. How should this be done? Should we add v6 subnets to segments and one subnet with the type --service-type 'network:router_gateway' as well? This is what I tried but it didn't work for me. Should tenants create their own v6 subnet out of the v6 subnet pool I provisioned as admin? Cheers, Thomas Goirand (zigo) P.S: Please keep my Infomaniak colleagues as Cc. From zigo at debian.org Wed Jan 6 20:54:22 2021 From: zigo at debian.org (Thomas Goirand) Date: Wed, 6 Jan 2021 21:54:22 +0100 Subject: [all][tc] Thoughts on Python 3.7 support In-Reply-To: References: <20210105215107.jap2c5evbkpu2u7n@yuggoth.org> Message-ID: <8d1356d3-7836-19d1-860e-cdad80be71f0@debian.org> On 1/6/21 12:26 PM, Radosław Piliszek wrote: > Sorry for top posting but just a general remark: > > Do note Debian 10 is using Python 3.7 and that is what Kolla is testing too. > I know Debian is not considered a tested platform but people use it > successfully. > > My opinion is, therefore, that we should keep 3.7 in classifiers. > > -yoctozepto I also confirm that I do run Debian 10 in production with all versions of OpenStack from Rocky to Wallaby, and that I will report if I see anything that doesn't work. I also would like to remind everyone that Bullseye is currently running Python 3.9, and that we should switch the upper bound to at least that... Cheers, Thomas Goirand (zigo) From zigo at debian.org Wed Jan 6 20:58:03 2021 From: zigo at debian.org (Thomas Goirand) Date: Wed, 6 Jan 2021 21:58:03 +0100 Subject: [oslo][TC] Dropping lower-constraints testing In-Reply-To: References: Message-ID: <5755ea96-5cc7-2756-970e-dcbf5184b2a2@debian.org> On 12/18/20 3:54 PM, hberaud wrote: > In a first time I tried to fix our gates by fixing our lower-constraints > project by project but with around ~36 projects to maintain this is a > painful task, especially due to nested oslo layers inside oslo > himself... I saw the face of the hell of dependencies. Welcome to my world! > Thoughts? Couldn't someone address the dependency loops in Oslo? It's IMO anyway needed. Just my 2 cents, not sure if that helps... Cheers, Thomas Goirand (zigo) From zigo at debian.org Wed Jan 6 21:04:34 2021 From: zigo at debian.org (Thomas Goirand) Date: Wed, 6 Jan 2021 22:04:34 +0100 Subject: [all][tc] Dropping lower-constraints testing from all projects In-Reply-To: <176d8da769b.b6edb13b874337.4809906168220534198@ghanshyammann.com> References: <176d8da769b.b6edb13b874337.4809906168220534198@ghanshyammann.com> Message-ID: <3c223c99-929e-ab6d-2268-10d361f76349@debian.org> Hi, On 1/6/21 6:59 PM, Ghanshyam Mann wrote: > Hello Everyone, > > You might have seen the discussion around dropping the lower constraints > testing as it becomes more challenging than the current value of doing it. As a downstream distribution package maintainer, I see this as a major regression of the code quality that upstream is shipping. Without l-c tests, there's no assurance of the reality of a lower-bound dependency. So then we're back to 5 years ago, when OpenStack just artificially was setting very high lower bound because we just didn't know... Please don't do it. Cheers, Thomas Goirand (zigo) From dhana.sys at gmail.com Wed Jan 6 21:20:48 2021 From: dhana.sys at gmail.com (Dhanasekar Kandasamy) Date: Thu, 7 Jan 2021 02:50:48 +0530 Subject: [neutron] Performance impact for attaching Security Group with more number of rules Message-ID: Hi, We have an OpenStack Environment with 5000+ VMs running currently. I want to apply some common Security Group to all my running VMs. - Common Security Group (SEC_GRP_COMMON) has around 700 rules. - This Security Group (SEC_GRP_COMMON) has been shared to all the OpenStack Projects using Role-Based Access Control (RBAC). - Wanted to apply this Security Group (SEC_GRP_COMMON) to all the running VMs in the Cloud *Question 1*: With the above scenario, what will happen if I attach this Security Group(with 700+ rules) to all the 5000+ VMs? Will there be any performance issue/impact for the same (CPU utilization, Memory etc. in the Compute Server or Performance issues in application running in the VMs) *Question 2*: Is there any recommendations or benchmark data for maximum number of rules in the Security Group in OpenStack cloud? Thanks, Dhana -------------- next part -------------- An HTML attachment was scrubbed... URL: From pierre at stackhpc.com Wed Jan 6 21:23:56 2021 From: pierre at stackhpc.com (Pierre Riteau) Date: Wed, 6 Jan 2021 22:23:56 +0100 Subject: [all][tc] Thoughts on Python 3.7 support In-Reply-To: <176d8d1747f.e25ad718873974.5391430581306589135@ghanshyammann.com> References: <20210105215107.jap2c5evbkpu2u7n@yuggoth.org> <68d4b804-5729-e313-7f29-6c7b14166c5c@nemebean.com> <176d8d1747f.e25ad718873974.5391430581306589135@ghanshyammann.com> Message-ID: On Wed, 6 Jan 2021 at 18:58, Ghanshyam Mann wrote: > > ---- On Wed, 06 Jan 2021 10:34:35 -0600 Ben Nemec wrote ---- > > > > > > On 1/5/21 3:51 PM, Jeremy Stanley wrote: > > > On 2021-01-05 22:32:58 +0100 (+0100), Pierre Riteau wrote: > > >> There have been many patches submitted to drop the Python 3.7 > > >> classifier from setup.cfg: > > >> https://review.opendev.org/q/%2522remove+py37%2522 > > >> The justification is that Wallaby tested runtimes only include 3.6 and 3.8. > > >> > > >> Most projects are merging these patches, but I've seen a couple of > > >> objections from ironic and horizon: > > >> > > >> - https://review.opendev.org/c/openstack/python-ironicclient/+/769044 > > >> - https://review.opendev.org/c/openstack/horizon/+/769237 > > >> > > >> What are the thoughts of the TC and of the overall community on this? > > >> Should we really drop these classifiers when there are no > > >> corresponding CI jobs, even though more Python versions may well be > > >> supported? > > > > > > My recollection of the many discussions we held was that the runtime > > > document would recommend the default python3 available in our > > > targeted platforms, but that we would also make a best effort to > > > test with the latest python3 available to us at the start of the > > > cycle as well. It was suggested more than once that we should test > > > all minor versions in between, but this was ruled out based on the > > > additional CI resources it would consume for minimal gain. Instead > > > we deemed that testing our target version and the latest available > > > would give us sufficient confidence that, if those worked, the > > > versions in between them were likely fine as well. Based on that, I > > > think the versions projects claim to work with should be contiguous > > > ranges, not contiguous lists of the exact versions tested (noting > > > that those aren't particularly *exact* versions to begin with). > > > > > > Apologies for the lack of references to old discussions, I can > > > probably dig some up from the ML and TC meetings several years back > > > of folks think it will help inform this further. > > > > > > > For what little it's worth, that jives with my hazy memories of the > > discussion too. The assumption was that if we tested the upper and lower > > bounds of our Python versions then the ones in the middle would be > > unlikely to break. It was a compromise to support multiple versions of > > Python without spending a ton of testing resources on it. > > > Exactly, py3.7 is not broken for OpenStack so declaring it not supported is not the right thing. > I remember the discussion when we declared the wallaby (probably from Victoria) testing runtime, > we decided if we test py3.6 and py3.8 it means we are not going to break py3.7 support so indirectly > it is tested and supported. > > And testing runtime does not mean we have to drop everything else testing means projects are all > welcome to keep running the py3.7 testing job on the gate there is no harm in that. > > In both cases, either project has an explicit py3.7 job or not we should not remove it from classifiers. > > > -gmann Thanks everyone for your input. Then should we request that those patches dropping the 3.7 classifier are abandoned, or reverted if already merged? From pierre at stackhpc.com Wed Jan 6 21:33:38 2021 From: pierre at stackhpc.com (Pierre Riteau) Date: Wed, 6 Jan 2021 22:33:38 +0100 Subject: [all][tc] Dropping lower-constraints testing from all projects In-Reply-To: <176d8da769b.b6edb13b874337.4809906168220534198@ghanshyammann.com> References: <176d8da769b.b6edb13b874337.4809906168220534198@ghanshyammann.com> Message-ID: On Wed, 6 Jan 2021 at 19:07, Ghanshyam Mann wrote: > > Hello Everyone, > > You might have seen the discussion around dropping the lower constraints > testing as it becomes more challenging than the current value of doing it. > > Few of the ML thread around this discussion: > > - http://lists.openstack.org/pipermail/openstack-discuss/2020-December/019521.html > - http://lists.openstack.org/pipermail/openstack-discuss/2020-December/019390.html > > As Oslo and many other project dropping or already dropped it, we should decide it for all > other projects also otherwise it can be more changing than it is currently. > > We have not defined it in PTI or testing runtime so it is always up to projects if they still > want to keep it but we should decide a general recommendation here. I would suggest dropping the lower-constraints job only in projects where it becomes too difficult to maintain. I fixed those jobs in Blazar yesterday. It was a bit painful, but in the process I discovered several requirements were incorrectly defined, as we were using features not available in the minimum version required… From fungi at yuggoth.org Wed Jan 6 21:40:49 2021 From: fungi at yuggoth.org (Jeremy Stanley) Date: Wed, 6 Jan 2021 21:40:49 +0000 Subject: [all][tc] Dropping lower-constraints testing from all projects In-Reply-To: <3c223c99-929e-ab6d-2268-10d361f76349@debian.org> References: <176d8da769b.b6edb13b874337.4809906168220534198@ghanshyammann.com> <3c223c99-929e-ab6d-2268-10d361f76349@debian.org> Message-ID: <20210106214048.3gau2fzexn5ivdek@yuggoth.org> On 2021-01-06 22:04:34 +0100 (+0100), Thomas Goirand wrote: [...] > As a downstream distribution package maintainer, I see this as a major > regression of the code quality that upstream is shipping. Without l-c > tests, there's no assurance of the reality of a lower-bound dependency. > > So then we're back to 5 years ago, when OpenStack just artificially was > setting very high lower bound because we just didn't know... > > Please don't do it. The tidbit you're missing here is that we never actually had working lower-bounds checks. The recent update to make pip correctly confirm requested versions of packages get installed, which has caused these jobs to all fall over, proves that. So it's not a regression. I'm personally in favor of doing lower-bounds checking of our software, always have been, but nobody's done the work to correctly implement it. The old jobs we had punted on it, and now we can see clearly that they weren't actually testing what people thought. Properly calculating transitive dependency lower-bounds requires a modified dependency solver with consistent inverse sorting, and that doesn't presently exist. -- Jeremy Stanley -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From jp.methot at planethoster.info Wed Jan 6 23:26:24 2021 From: jp.methot at planethoster.info (=?utf-8?Q?Jean-Philippe_M=C3=A9thot?=) Date: Wed, 6 Jan 2021 18:26:24 -0500 Subject: [nova] Nova evacuate issue Message-ID: Hi, We’re running Openstack Rocky on a high-availability setup with neutron openvswitch. The setup has roughly 50 compute nodes and 2 controller nodes. We’ve run into an issue when we’re trying to evacuate a dead compute node where the first instance evacuate goes through, but the second one fails (we evacuate our instances one by one). The reason why the second one fails seems to be because Neutron is trying to plug the port back on the dead compute, as nova instructs it to do. Here’s an example of nova-api log output after compute22 died and we’ve been trying to evacuate an instance. f3839ca64f58ac779f6f810758c0 61e62a49d34a44f9b1161a338a7f1fdd - default default] Creating event network-vif-unplugged:80371c01-930d-4ea2-9d28-14438e948b65 for instance 4aeb7761-cb23-4c51-93dd-79b55afbc7dc on compute22 2021-01-06 13:31:31.750 2858 INFO nova.osapi_compute.wsgi.server [req-4f9b3e17-1a9d-48f0-961a-bbabdf922ad6 0d0ef3839ca64f58ac779f6f810758c0 61e62a49d34a44f9b1161a338a7f1fdd - default default] 10.30.1.224 "POST /v2.1/os-server-external-events HTTP/1.1" status: 200 len: 1091 time: 0.4987640 2021-01-06 13:31:40.145 2863 INFO nova.osapi_compute.wsgi.server [req-abaac9df-7338-4d10-9326-4006021ff54d 6cb55894e59c47b3800f97a27c9c4ee9 ccfa9d8d76b8409f8c5a8d71ce32625a - default default] 10.30.1.224 "GET /v2.1 HTTP/1.1" status: 302 len: 318 time: 0.0072701 2021-01-06 13:31:40.156 2863 INFO nova.osapi_compute.wsgi.server [req-c393e74b-a118-4a98-8a83-be6007913dc0 6cb55894e59c47b3800f97a27c9c4ee9 ccfa9d8d76b8409f8c5a8d71ce32625a - default default] 10.30.1.224 "GET /v2.1/ HTTP/1.1" status: 200 len: 789 time: 0.0070350 2021-01-06 13:31:43.289 2865 INFO nova.osapi_compute.wsgi.server [req-b87268b7-a673-44c1-9162-f9564647ec33 6cb55894e59c47b3800f97a27c9c4ee9 ccfa9d8d76b8409f8c5a8d71ce32625a - default default] 10.30.1.224 "GET /v2.1/servers/4aeb7761-cb23-4c51-93dd-79b55afbc7dc HTTP/1.1" status: 200 len: 5654 time: 2.7543190 2021-01-06 13:31:43.413 2863 INFO nova.osapi_compute.wsgi.server [req-4cab23ba-c5cb-4dda-bf42-bc452d004783 6cb55894e59c47b3800f97a27c9c4ee9 ccfa9d8d76b8409f8c5a8d71ce32625a - default default] 10.30.1.224 "GET /v2.1/servers/4aeb7761-cb23-4c51-93dd-79b55afbc7dc/os-volume_attachments HTTP/1.1" status: 200 len: 770 time: 0.1135709 2021-01-06 13:31:43.883 2865 INFO nova.osapi_compute.wsgi.server [req-f5e5a586-65f3-4798-b03b-98e01326a00b 6cb55894e59c47b3800f97a27c9c4ee9 ccfa9d8d76b8409f8c5a8d71ce32625a - default default] 10.30.1.224 "GET /v2.1/flavors/574a7152-f079-4337-b1eb-b7eca4370b73 HTTP/1.1" status: 200 len: 877 time: 0.5751688 2021-01-06 13:31:47.194 2864 INFO nova.api.openstack.compute.server_external_events [req-7e639b1f-8408-4e8e-9bb8-54588290edfe 0d0ef3839ca64f58ac779f6f810758c0 61e62a49d34a44f9b1161a338a7f1fdd - default default] Creating event network-vif-plugged:80371c01-930d-4ea2-9d28-14438e948b65 for instance 4aeb7761-cb23-4c51-93dd-79b55afbc7dc on compute22 As you can see, Nova "creates an event" as the virtual interface is unplugged but then immediately creates another event to plug the virtual interface in the same compute node that is dead. However, at the same time, the instance is being created on another compute node. Is this a known bug? I have not found anything about this in the bug database. Additionally, I am not able to reproduce in our staging environment which is smaller and running on Stein. Jean-Philippe Méthot Senior Openstack system administrator Administrateur système Openstack sénior PlanetHoster inc. 4414-4416 Louis B Mayer Laval, QC, H7P 0G1, Canada TEL : +1.514.802.1644 - Poste : 2644 FAX : +1.514.612.0678 CA/US : 1.855.774.4678 FR : 01 76 60 41 43 UK : 0808 189 0423 -------------- next part -------------- An HTML attachment was scrubbed... URL: From eandersson at blizzard.com Thu Jan 7 03:12:10 2021 From: eandersson at blizzard.com (Erik Olof Gunnar Andersson) Date: Thu, 7 Jan 2021 03:12:10 +0000 Subject: [magnum][api] Error system library fopen too many open files with magnum-auto-healer In-Reply-To: References: <185a9715-4667-9610-0048-5434e6e2cd4e@catalyst.net.nz> , Message-ID: Glad it helped . Going to work with the magnum team to get it merged. Would it be possible for you to document the issue and create a bug here https://storyboard.openstack.org/#!/project/openstack/magnum ________________________________ From: Ionut Biru Sent: Wednesday, January 6, 2021 3:37 AM To: Erik Olof Gunnar Andersson Cc: Spyros Trigazis ; feilong ; openstack-discuss Subject: Re: [magnum][api] Error system library fopen too many open files with magnum-auto-healer Hi Erik, Thanks a lot for the patch. Indeed 769471 fixes my problem at first glance. I'll let it run for a couple of days. On Wed, Jan 6, 2021 at 12:23 PM Erik Olof Gunnar Andersson > wrote: I pushed a couple of patches that you can try out. This is the most likely culprit. https://review.opendev.org/c/openstack/magnum/+/769471 - Re-use rpc client I also created this one, but doubt this is an issue as the implementation here is the same as I use in Designate https://review.opendev.org/c/openstack/magnum/+/769457 - [WIP] Singleton notifier Finally I also created a PR to add magnum-api testing using uwsgi. https://review.opendev.org/c/openstack/magnum/+/769450 Let me know if any of these patches help! ________________________________ From: Ionut Biru > Sent: Tuesday, January 5, 2021 8:36 AM To: Erik Olof Gunnar Andersson > Cc: Spyros Trigazis >; feilong >; openstack-discuss > Subject: Re: [magnum][api] Error system library fopen too many open files with magnum-auto-healer Hi, I found this story: https://storyboard.openstack.org/#!/story/2008308 regarding disabling cluster update notifications in rabbitmq. I think this will help me. On Tue, Jan 5, 2021 at 12:21 PM Erik Olof Gunnar Andersson > wrote: Sorry, being repetitive here, but maybe try adding this to your magnum config as well. If you have A LOT of cores it could add up to a crazy amount of connections. [conductor] workers = 2 ________________________________ From: Ionut Biru > Sent: Tuesday, January 5, 2021 1:50 AM To: Erik Olof Gunnar Andersson > Cc: Spyros Trigazis >; feilong >; openstack-discuss > Subject: Re: [magnum][api] Error system library fopen too many open files with magnum-auto-healer Hi, Here is my config. maybe something is fishy. I did have around 300 messages in the queue in notification.info and notification.err and I purged them. https://paste.xinu.at/woMt/ On Tue, Jan 5, 2021 at 11:23 AM Erik Olof Gunnar Andersson > wrote: Yea - tested locally as well and wasn't able to reproduce it either. I changed the health service job to run every second and maxed out at about 42 connections to RabbitMQ with two conductor workers. /etc/magnum/magnun.conf [conductor] workers = 2 ________________________________ From: Spyros Trigazis > Sent: Tuesday, January 5, 2021 12:59 AM To: Ionut Biru > Cc: Erik Olof Gunnar Andersson >; feilong >; openstack-discuss > Subject: Re: [magnum][api] Error system library fopen too many open files with magnum-auto-healer On Tue, Jan 5, 2021 at 9:36 AM Ionut Biru > wrote: Hi, I tried with process=1 and it reached 1016 connections to rabbitmq. lsof https://paste.xinu.at/jGg/ i think it goes into error when it reaches 1024 file descriptors. I'm out of ideas of how to resolve this. I only have 3 clusters available and it's kinda weird and It doesn't scale. No issues here with 100s of clusters. Not sure what doesn't scale. * Maybe your rabbit is flooded with notifications that are not consumed? * You can use way more than 1024 file descriptors, maybe 2^10? Spyros On Mon, Jan 4, 2021 at 9:53 PM Erik Olof Gunnar Andersson > wrote: Sure looks like RabbitMQ. How many workers do have you configured? Could you try to changing the uwsgi configuration to workers=1 (or processes=1) and then see if it goes beyond 30 connections to amqp. From: Ionut Biru > Sent: Monday, January 4, 2021 4:07 AM To: Erik Olof Gunnar Andersson > Cc: feilong >; openstack-discuss > Subject: Re: [magnum][api] Error system library fopen too many open files with magnum-auto-healer Hi Erik, Here is lsof of one uwsgi api. https://paste.xinu.at/5YUWf/ I have kubernetes 12.0.1 installed in env. On Sun, Jan 3, 2021 at 3:06 AM Erik Olof Gunnar Andersson > wrote: Maybe something similar to this? https://github.com/kubernetes-client/python/issues/1158 What does lsof say? -- Ionut Biru - https://fleio.com -- Ionut Biru - https://fleio.com -- Ionut Biru - https://fleio.com -- Ionut Biru - https://fleio.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From ionut at fleio.com Thu Jan 7 07:15:07 2021 From: ionut at fleio.com (Ionut Biru) Date: Thu, 7 Jan 2021 09:15:07 +0200 Subject: [magnum][api] Error system library fopen too many open files with magnum-auto-healer In-Reply-To: References: <185a9715-4667-9610-0048-5434e6e2cd4e@catalyst.net.nz> Message-ID: Hi Erik, Here is the story: https://storyboard.openstack.org/#!/story/2008494 On Thu, Jan 7, 2021 at 5:12 AM Erik Olof Gunnar Andersson < eandersson at blizzard.com> wrote: > Glad it helped . Going to work with the magnum team to get it merged. > > Would it be possible for you to document the issue and create a bug here > https://storyboard.openstack.org/#!/project/openstack/magnum > > ------------------------------ > *From:* Ionut Biru > *Sent:* Wednesday, January 6, 2021 3:37 AM > *To:* Erik Olof Gunnar Andersson > *Cc:* Spyros Trigazis ; feilong < > feilong at catalyst.net.nz>; openstack-discuss < > openstack-discuss at lists.openstack.org> > *Subject:* Re: [magnum][api] Error system library fopen too many open > files with magnum-auto-healer > > Hi Erik, > > Thanks a lot for the patch. Indeed 769471 fixes my problem at first glance. > > I'll let it run for a couple of days. > > > On Wed, Jan 6, 2021 at 12:23 PM Erik Olof Gunnar Andersson < > eandersson at blizzard.com> wrote: > > I pushed a couple of patches that you can try out. > > This is the most likely culprit. > https://review.opendev.org/c/openstack/magnum/+/769471 > > - Re-use rpc client > > I also created this one, but doubt this is an issue as the implementation > here is the same as I use in Designate > https://review.opendev.org/c/openstack/magnum/+/769457 > > - [WIP] Singleton notifier > > Finally I also created a PR to add magnum-api testing using uwsgi. > https://review.opendev.org/c/openstack/magnum/+/769450 > > > Let me know if any of these patches help! > > ------------------------------ > *From:* Ionut Biru > *Sent:* Tuesday, January 5, 2021 8:36 AM > *To:* Erik Olof Gunnar Andersson > *Cc:* Spyros Trigazis ; feilong < > feilong at catalyst.net.nz>; openstack-discuss < > openstack-discuss at lists.openstack.org> > *Subject:* Re: [magnum][api] Error system library fopen too many open > files with magnum-auto-healer > > Hi, > > I found this story: https://storyboard.openstack.org/#!/story/2008308 > > regarding disabling cluster update notifications in rabbitmq. > > I think this will help me. > > On Tue, Jan 5, 2021 at 12:21 PM Erik Olof Gunnar Andersson < > eandersson at blizzard.com> wrote: > > Sorry, being repetitive here, but maybe try adding this to your magnum > config as well. If you have A LOT of cores it could add up to a crazy > amount of connections. > > [conductor] > workers = 2 > > ------------------------------ > *From:* Ionut Biru > *Sent:* Tuesday, January 5, 2021 1:50 AM > *To:* Erik Olof Gunnar Andersson > *Cc:* Spyros Trigazis ; feilong < > feilong at catalyst.net.nz>; openstack-discuss < > openstack-discuss at lists.openstack.org> > *Subject:* Re: [magnum][api] Error system library fopen too many open > files with magnum-auto-healer > > Hi, > > Here is my config. maybe something is fishy. > > I did have around 300 messages in the queue in notification.info > > and notification.err and I purged them. > > https://paste.xinu.at/woMt/ > > > > > On Tue, Jan 5, 2021 at 11:23 AM Erik Olof Gunnar Andersson < > eandersson at blizzard.com> wrote: > > Yea - tested locally as well and wasn't able to reproduce it either. I > changed the health service job to run every second and maxed out at about > 42 connections to RabbitMQ with two conductor workers. > > /etc/magnum/magnun.conf > > [conductor] > workers = 2 > > > ------------------------------ > *From:* Spyros Trigazis > *Sent:* Tuesday, January 5, 2021 12:59 AM > *To:* Ionut Biru > *Cc:* Erik Olof Gunnar Andersson ; feilong < > feilong at catalyst.net.nz>; openstack-discuss < > openstack-discuss at lists.openstack.org> > *Subject:* Re: [magnum][api] Error system library fopen too many open > files with magnum-auto-healer > > > > On Tue, Jan 5, 2021 at 9:36 AM Ionut Biru wrote: > > Hi, > > I tried with process=1 and it reached 1016 connections to rabbitmq. > lsof > https://paste.xinu.at/jGg/ > > > i think it goes into error when it reaches 1024 file descriptors. > > I'm out of ideas of how to resolve this. I only have 3 clusters available > and it's kinda weird and It doesn't scale. > > > No issues here with 100s of clusters. Not sure what doesn't scale. > > * Maybe your rabbit is flooded with notifications that are not consumed? > * You can use way more than 1024 file descriptors, maybe 2^10? > > Spyros > > > On Mon, Jan 4, 2021 at 9:53 PM Erik Olof Gunnar Andersson < > eandersson at blizzard.com> wrote: > > Sure looks like RabbitMQ. How many workers do have you configured? > > > > Could you try to changing the uwsgi configuration to workers=1 (or > processes=1) and then see if it goes beyond 30 connections to amqp. > > > > *From:* Ionut Biru > *Sent:* Monday, January 4, 2021 4:07 AM > *To:* Erik Olof Gunnar Andersson > *Cc:* feilong ; openstack-discuss < > openstack-discuss at lists.openstack.org> > *Subject:* Re: [magnum][api] Error system library fopen too many open > files with magnum-auto-healer > > > > Hi Erik, > > > > Here is lsof of one uwsgi api. https://paste.xinu.at/5YUWf/ > > > > > I have kubernetes 12.0.1 installed in env. > > > > > > On Sun, Jan 3, 2021 at 3:06 AM Erik Olof Gunnar Andersson < > eandersson at blizzard.com> wrote: > > Maybe something similar to this? > https://github.com/kubernetes-client/python/issues/1158 > > > What does lsof say? > > > > > > > > -- > Ionut Biru - https://fleio.com > > > > > -- > Ionut Biru - https://fleio.com > > > > > -- > Ionut Biru - https://fleio.com > > > > > -- > Ionut Biru - https://fleio.com > > -- Ionut Biru - https://fleio.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From skaplons at redhat.com Thu Jan 7 08:17:59 2021 From: skaplons at redhat.com (Slawek Kaplonski) Date: Thu, 7 Jan 2021 09:17:59 +0100 Subject: [neutron] Performance impact for attaching Security Group with more number of rules In-Reply-To: References: Message-ID: <20210107081759.igz5skypxaahlvlf@p1.localdomain> Hi, On Thu, Jan 07, 2021 at 02:50:48AM +0530, Dhanasekar Kandasamy wrote: > Hi, > > We have an OpenStack Environment with 5000+ VMs running currently. I want > to apply some common Security Group to all my running VMs. > > - Common Security Group (SEC_GRP_COMMON) has around 700 rules. > - This Security Group (SEC_GRP_COMMON) has been shared to all the > OpenStack Projects using Role-Based Access Control (RBAC). > - Wanted to apply this Security Group (SEC_GRP_COMMON) to all the > running VMs in the Cloud > > *Question 1*: With the above scenario, what will happen if I attach this > Security Group(with 700+ rules) to all the 5000+ VMs? Will there be any > performance issue/impact for the same (CPU utilization, Memory etc. in the > Compute Server or Performance issues in application running in the VMs) It all depends on what plugin and agents You are using. E.g. if You are using ML2 plugin with openvswitch agents on compute nodes, for sure You will see issues with performance of agent as it will take some time to apply those rules to all ports on the compute nodes. Of course if You have many compute nodes and only few VMs on each of them, then it should be pretty fast. If You have compute nodes with e.g. 100-200 VMs on one compute, it can take more than 10 minutes to apply those SG to all ports. Another question is what firewall driver You are using. In case of ML2/OVS it can be iptables_hybrid or openvswitch driver and performance of both can be different. You can find some comparisons and benchmarks in the Internet. For example [1] or [2]. IIRC there were also some talks about that on summits so You can look for some recordings too. > > *Question 2*: Is there any recommendations or benchmark data for maximum > number of rules in the Security Group in OpenStack cloud? > > > Thanks, > > Dhana [1] https://thesaitech.wordpress.com/2019/02/15/a-comparative-study-of-openstack-networking-architectures/ [2] https://software.intel.com/content/www/us/en/develop/articles/implementing-an-openstack-security-group-firewall-driver-using-ovs-learn-actions.html?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+ISNMain+%28Intel+Developer+Zone+Articles+Feed%29 -- Slawek Kaplonski Principal Software Engineer Red Hat -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: not available URL: From mark at stackhpc.com Thu Jan 7 08:59:49 2021 From: mark at stackhpc.com (Mark Goddard) Date: Thu, 7 Jan 2021 08:59:49 +0000 Subject: [kolla-ansible] Upgrading and skipping a release? In-Reply-To: <046E9C0290DD9149B106B72FC9156BEA04814FBF@gmsxchsvr01.thecreation.com> References: <046E9C0290DD9149B106B72FC9156BEA04814FB6@gmsxchsvr01.thecreation.com> <046E9C0290DD9149B106B72FC9156BEA04814FBF@gmsxchsvr01.thecreation.com> Message-ID: On Wed, 6 Jan 2021 at 15:48, Eric K. Miller wrote: > > > Hi Eric. What you're referring to is a fast-forward upgrade [1]. This > > is not officially supported by Kolla Ansible, and not something we > > test upstream. There was an effort a few years ago to implement it, > > but it stalled. The test matrix does increase somewhat when you allow > > FFUs, which is why I believe many projects such as Tripleo define > > supported FFU jumps. One thing in particular that may catch you out is > > some DB migrations or cleanup processes that happen at runtime may not > > get executed. > > > > In short, I'd suggest going one release at a time. It's a pain, but > > upgrades in Kolla are relatively sane. > > Thank you mark! Much appreciated. We were hoping to avoid any potential pitfalls with the Python 2.x to 3.x transition, but it looks like we need to simply test quick upgrades from one to the next. > > Regarding the QEMU/KVM kernel module version on the host, I'm assuming we need to plan for VM shutdown/restart since I "think" we may need a newer version for Ussuri or Victoria. Looks like we're running: > > (on CentOS 7) > Compiled against library: libvirt 4.5.0 > Using library: libvirt 4.5.0 > Using API: QEMU 4.5.0 > Running hypervisor: QEMU 2.12.0 If you are running CentOS then the CentOS 8 upgrade is quite involved. See https://docs.openstack.org/kolla-ansible/train/user/centos8.html. You won't need to worry about qemu/kvm versions if you migrate VMs from CentOS 7 to 8 host as you go. > > Out of curiosity, have you used CloudLinux' KernelCare or any other hot-swap kernel module components to avoid downtime of a KVM host? Haven't tried it. > > Eric > From stephenfin at redhat.com Thu Jan 7 10:15:59 2021 From: stephenfin at redhat.com (Stephen Finucane) Date: Thu, 07 Jan 2021 10:15:59 +0000 Subject: [all][tc] Dropping lower-constraints testing from all projects In-Reply-To: <176d8da769b.b6edb13b874337.4809906168220534198@ghanshyammann.com> References: <176d8da769b.b6edb13b874337.4809906168220534198@ghanshyammann.com> Message-ID: <1c2ec93642e847aa6650f9e9af34a6fae5f9278b.camel@redhat.com> On Wed, 2021-01-06 at 11:59 -0600, Ghanshyam Mann wrote: > Hello Everyone, > > You might have seen the discussion around dropping the lower constraints > testing as it becomes more challenging than the current value of doing it. > > Few of the ML thread around this discussion: > > - http://lists.openstack.org/pipermail/openstack-discuss/2020-December/019521.html > - http://lists.openstack.org/pipermail/openstack-discuss/2020-December/019390.html > > As Oslo and many other project dropping or already dropped it, we should decide it for all > other projects also otherwise it can be more changing than it is currently. > > We have not defined it in PTI or testing runtime so it is always up to projects if they still > want to keep it but we should decide a general recommendation here. Out of curiosity, would limiting the list in lower-constraints to the set of requirements listed in 'requirements.txt' help matters? That would at least ensure the lower version of our explicit dependencies worked. The main issue I could see with this is potentially a lot of thrashing from pip as it attempts to find versions of implicit dependencies that satisfy the various constraints, but I guess we'll have to address that when we come to it. Stephen From martin.golasowski at vsb.cz Thu Jan 7 12:20:29 2021 From: martin.golasowski at vsb.cz (Golasowski Martin) Date: Thu, 7 Jan 2021 12:20:29 +0000 Subject: OpenStack Ansible - Telemetry Message-ID: <2A904BE8-8679-4C8A-89C3-DF9D7AF89E44@vsb.cz> Dear All, I would like to know which monitoring solution is currently supported by OSA? We are operating a small cloud (~ 6 nodes) and we are interested in collecting performance metrics, events and logs. So, as far as I know, the official OSA solution is ceilometer/aodh/panko with Gnocchi as DB backend. However Gnocchi project seems abandoned at the moment and the grafana plugin is not compatible with latest Grafana. Then there is solution based on collectd with this plugin (https://github.com/signalfx/collectd-openstack ) with Graphite or InfluxDB as backend. This supports only performance metrics and not the events. Then there are also some Prometheus exporters available, again, metrics only. What do you guys use these days? What would you recommend? Thanks! Best regards, Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3632 bytes Desc: not available URL: From skaplons at redhat.com Thu Jan 7 12:30:04 2021 From: skaplons at redhat.com (Slawek Kaplonski) Date: Thu, 7 Jan 2021 13:30:04 +0100 Subject: [neutron] Drivers team meeting agenda Message-ID: <20210107123004.aeahdzu4a3zro2gj@p1.localdomain> Hi, Agenda for first drivers team meeting in 2021 is available at [1] We have 3 RFEs to discuss: * https://bugs.launchpad.net/neutron/+bug/1909100 * https://bugs.launchpad.net/neutron/+bug/1900934 For that one there is also spec proposed https://review.opendev.org/c/openstack/neutron-specs/+/768588 and we already discussed that few times. So I think it's time to decide if we want to go with that solution or not :) * https://bugs.launchpad.net/neutron/+bug/1910533 Thx and see You tomorrow on the meeting. [1] https://wiki.openstack.org/wiki/Meetings/NeutronDrivers#Agenda -- Slawek Kaplonski Principal Software Engineer Red Hat -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: not available URL: From dtantsur at redhat.com Thu Jan 7 13:28:45 2021 From: dtantsur at redhat.com (Dmitry Tantsur) Date: Thu, 7 Jan 2021 14:28:45 +0100 Subject: [ironic] SPUC in 2021 Message-ID: Hi folks! I feel like SPUC (our Sanity Preserving Un-Conference) has been very successful in 2020, what do you think about continuing it as before: Friday, 10am UTC (in https://bluejeans.com/643711802) Friday, 5pm UTC (in https://bluejeans.com/313987753) ? Dmitry -- Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill -------------- next part -------------- An HTML attachment was scrubbed... URL: From lyarwood at redhat.com Thu Jan 7 14:26:38 2021 From: lyarwood at redhat.com (Lee Yarwood) Date: Thu, 7 Jan 2021 14:26:38 +0000 Subject: [nova] Nova evacuate issue In-Reply-To: References: Message-ID: <20210107142638.3u2duxgdsrj5fe5y@lyarwood-laptop.usersys.redhat.com> On 06-01-21 18:26:24, Jean-Philippe Méthot wrote: > Hi, > > We’re running Openstack Rocky on a high-availability setup with > neutron openvswitch. The setup has roughly 50 compute nodes and 2 > controller nodes. We’ve run into an issue when we’re trying to > evacuate a dead compute node where the first instance evacuate goes > through, but the second one fails (we evacuate our instances one by > one). The reason why the second one fails seems to be because Neutron > is trying to plug the port back on the dead compute, as nova instructs > it to do. Here’s an example of nova-api log output after compute22 > died and we’ve been trying to evacuate an instance. > > f3839ca64f58ac779f6f810758c0 61e62a49d34a44f9b1161a338a7f1fdd - default default] Creating event network-vif-unplugged:80371c01-930d-4ea2-9d28-14438e948b65 for instance 4aeb7761-cb23-4c51-93dd-79b55afbc7dc on compute22 > 2021-01-06 13:31:31.750 2858 INFO nova.osapi_compute.wsgi.server [req-4f9b3e17-1a9d-48f0-961a-bbabdf922ad6 0d0ef3839ca64f58ac779f6f810758c0 61e62a49d34a44f9b1161a338a7f1fdd - default default] 10.30.1.224 "POST /v2.1/os-server-external-events HTTP/1.1" status: 200 len: 1091 time: 0.4987640 > 2021-01-06 13:31:40.145 2863 INFO nova.osapi_compute.wsgi.server [req-abaac9df-7338-4d10-9326-4006021ff54d 6cb55894e59c47b3800f97a27c9c4ee9 ccfa9d8d76b8409f8c5a8d71ce32625a - default default] 10.30.1.224 "GET /v2.1 HTTP/1.1" status: 302 len: 318 time: 0.0072701 > 2021-01-06 13:31:40.156 2863 INFO nova.osapi_compute.wsgi.server [req-c393e74b-a118-4a98-8a83-be6007913dc0 6cb55894e59c47b3800f97a27c9c4ee9 ccfa9d8d76b8409f8c5a8d71ce32625a - default default] 10.30.1.224 "GET /v2.1/ HTTP/1.1" status: 200 len: 789 time: 0.0070350 > 2021-01-06 13:31:43.289 2865 INFO nova.osapi_compute.wsgi.server [req-b87268b7-a673-44c1-9162-f9564647ec33 6cb55894e59c47b3800f97a27c9c4ee9 ccfa9d8d76b8409f8c5a8d71ce32625a - default default] 10.30.1.224 "GET /v2.1/servers/4aeb7761-cb23-4c51-93dd-79b55afbc7dc HTTP/1.1" status: 200 len: 5654 time: 2.7543190 > 2021-01-06 13:31:43.413 2863 INFO nova.osapi_compute.wsgi.server [req-4cab23ba-c5cb-4dda-bf42-bc452d004783 6cb55894e59c47b3800f97a27c9c4ee9 ccfa9d8d76b8409f8c5a8d71ce32625a - default default] 10.30.1.224 "GET /v2.1/servers/4aeb7761-cb23-4c51-93dd-79b55afbc7dc/os-volume_attachments HTTP/1.1" status: 200 len: 770 time: 0.1135709 > 2021-01-06 13:31:43.883 2865 INFO nova.osapi_compute.wsgi.server [req-f5e5a586-65f3-4798-b03b-98e01326a00b 6cb55894e59c47b3800f97a27c9c4ee9 ccfa9d8d76b8409f8c5a8d71ce32625a - default default] 10.30.1.224 "GET /v2.1/flavors/574a7152-f079-4337-b1eb-b7eca4370b73 HTTP/1.1" status: 200 len: 877 time: 0.5751688 > 2021-01-06 13:31:47.194 2864 INFO nova.api.openstack.compute.server_external_events [req-7e639b1f-8408-4e8e-9bb8-54588290edfe 0d0ef3839ca64f58ac779f6f810758c0 61e62a49d34a44f9b1161a338a7f1fdd - default default] Creating event network-vif-plugged:80371c01-930d-4ea2-9d28-14438e948b65 for instance 4aeb7761-cb23-4c51-93dd-79b55afbc7dc on compute22 > > As you can see, Nova "creates an event" as the virtual interface is > unplugged but then immediately creates another event to plug the > virtual interface in the same compute node that is dead. However, at > the same time, the instance is being created on another compute node. > Is this a known bug? I have not found anything about this in the bug > database. Additionally, I am not able to reproduce in our staging > environment which is smaller and running on Stein. Would you be able to trace an example evacuation request fully and pastebin it somewhere using `openstack server event list $instance [1]` output to determine the request-id etc? Feel free to also open a bug about this and we can just triage there instead of the ML. The fact that q-api has sent the network-vif-plugged:80371c01-930d-4ea2-9d28-14438e948b65 to n-api suggests that the q-agt is actually alive on compute22, was that the case? Note that a pre-condition of calling the evacuation API is that the source host has been fenced [2]. That all said I wonder if this is somehow related too the following stein change: https://review.opendev.org/c/openstack/nova/+/603844 Cheers, Lee [1] https://docs.openstack.org/python-openstackclient/rocky/cli/command-objects/server-event.html#server-event-list [2] https://docs.openstack.org/api-ref/compute/?expanded=evacuate-server-evacuate-action-detail#evacuate-server-evacuate-action -- Lee Yarwood A5D1 9385 88CB 7E5F BE64 6618 BCA6 6E33 F672 2D76 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: not available URL: From ralonsoh at redhat.com Thu Jan 7 14:45:22 2021 From: ralonsoh at redhat.com (Rodolfo Alonso Hernandez) Date: Thu, 7 Jan 2021 15:45:22 +0100 Subject: [neutron] SR-IOV mechanism driver configuration, plugin.ini In-Reply-To: <3641168.yvBDRoByMW@p1> References: <3641168.yvBDRoByMW@p1> Message-ID: Hello: You need to specify two config files: the neutron.conf and the ML2 plugin one; in this case /etc/neutron/plugins/ml2/ml2_conf.ini. Other installers create a ML2 plugin config file per backend but this is not necessary. Regards. On Wed, Dec 30, 2020 at 8:29 AM Slawek Kaplonski wrote: > Hi, > > Dnia środa, 30 grudnia 2020 01:07:42 CET Gabriel Omar Gamero Montenegro > pisze: > > Dear all, > > > > I'm following the OpenStack guide for > > the implementation of SR-IOV mechanism driver. > > I'm planning to incorporate this driver to > > my current OpenStack deployment (Queens). > > > > Config SR-IOV Guide: > > https://docs.openstack.org/neutron/queens/admin/config-sriov.html > > > > At point 2, section "Configure neutron-server (Controller)" > > they said that I have to add the 'plugin.ini' file > > as a parameter to the neutron-server service. > > To do this they require to > > < > neutron-server service to load the plugin configuration file>>: > > --config-file /etc/neutron/neutron.conf > > --config-file /etc/neutron/plugin.ini > > > > I'd like to know a few things: > > > > (1) Which plugin.ini file are talking about? > > That is IMO good question. I see this file for the first time now :) > Looking at the commit [1] and commits which this patch reference to I > think > that this may be some old leftover which should be cleaned. > But maybe Rodolfo will know more as he s our SR-IOV expert in the team. > > > (2) How to set up the neutron-server initialization script > > to add the plugin.ini file? > > I understand that this varies between OS distro > > (I'm currently using Ubuntu 16.04 LTS server) > > > > Here are some things I tried... > > > > I got the following results executing this command: > > > > systemctl status neutron-server.service > > ● neutron-server.service - OpenStack Neutron Server > > Loaded: loaded (/lib/systemd/system/neutron-server.service; > > enabled; vendor preset: enabled) > > Active: active (running) since Tue 2020-12-29 18:13:50 -05 > > Main PID: 38590 (neutron-server) > > Tasks: 44 > > Memory: 738.8M > > CPU: 29.322s > > CGroup: /system.slice/neutron-server.service > > ├─38590 /usr/bin/python2 /usr/bin/neutron-server > > --config-file=/etc/neutron/neutron.conf > > --config-file=/etc/neutron/plugins/ml2/ml2_conf.ini > > --log-file=/var/log/neutron/neutron-server.log > > ... > > > > I see 2 things: > > > > (i) When neutron-server is exectured, > > the following parameters are passed: > > --config-file=/etc/neutron/neutron.conf > > --config-file=/etc/neutron/plugins/ml2/ml2_conf.ini > > --log-file=/var/log/neutron/neutron-server.log > > > > (ii) The file '/lib/systemd/system/neutron-server.service' > > is loaded and it has the following content: > > ... > > ExecStart=/etc/init.d/neutron-server systemd-start > > ... > > > > This indicates me that it's executing > > '/etc/init.d/neutron-server' script. > > So I suppose this is the file indicated to add the parameters > > of the SR-IOV OpenStack documentation, > > but I have no idea where to put them. > > > > For Red-Hat distros I found this documentation > > with the following configuration: > > https://access.redhat.com/documentation/en-us/ > > red_hat_enterprise_linux_openstack_platform/7/html/networking_guide > > /sr-iov-support-for-virtual-networking > > > > vi /usr/lib/systemd/system/neutron-server.service > > ... > > ExecStart=/usr/bin/neutron-server > > --config-file /usr/share/neutron/neutron-dist.conf > > --config-file /etc/neutron/neutron.conf > > --config-file /etc/neutron/plugin.ini > > --config-file /etc/neutron/plugins/ml2/ml2_conf_sriov.ini > > --log-file /var/log/neutron/server.log > > > > Thanks in advance, > > Gabriel Gamero > > [1] https://github.com/openstack/neutron/commit/ > c4e76908ae0d8c1e5bcb7f839df5e22094805299 > > -- > Slawek Kaplonski > Principal Software Engineer > Red Hat -------------- next part -------------- An HTML attachment was scrubbed... URL: From gmann at ghanshyammann.com Thu Jan 7 15:26:23 2021 From: gmann at ghanshyammann.com (Ghanshyam Mann) Date: Thu, 07 Jan 2021 09:26:23 -0600 Subject: [stable][grenade][qa][nova][swift] s-proxy unable to start due to missing runtime deps In-Reply-To: <20201223095407.jdlkppm66t7gizye@lyarwood-laptop.usersys.redhat.com> References: <20201222170602.bqlwjlikjwdhoc7c@lyarwood-laptop.usersys.redhat.com> <1768bc057cf.f1a8241c453709.6689913672331717101@ghanshyammann.com> <1768c8071d4.1064de03a458204.3580547345653933493@ghanshyammann.com> <20201223095407.jdlkppm66t7gizye@lyarwood-laptop.usersys.redhat.com> Message-ID: <176dd74bb72.ea0374eb914568.5337396488943512176@ghanshyammann.com> ---- On Wed, 23 Dec 2020 03:54:07 -0600 Lee Yarwood wrote ---- > On 22-12-20 16:09:56, Ghanshyam Mann wrote: > > ---- On Tue, 22 Dec 2020 12:40:07 -0600 Ghanshyam Mann wrote ---- > > > ---- On Tue, 22 Dec 2020 11:06:02 -0600 Lee Yarwood wrote ---- > > > > Hello all, > > > > > > > > I wanted to raise awareness of the following issue and to seek some > > > > feedback on my approach to workaround it: > > > > > > > > ImportError: No module named keystonemiddleware.auth_token > > > > https://bugs.launchpad.net/swift/+bug/1909018 > > > > > > > > This was introduced after I landed the following devstack backport > > > > stopping projects from installing their test-requirements.txt deps: > > > > > > > > Stop installing test-requirements with projects > > > > https://review.opendev.org/q/I8f24b839bf42e2fb9803dc7df3a30ae20cf264eb > > > > > > > > For the time being to workaround this in various other gates I've > > > > suggested that we disable Swift in Grenade on stable/train: > > > > > > > > zuul: Disable swift services until bug #1909018 is resolved > > > > https://review.opendev.org/c/openstack/grenade/+/768224 > > > > > > > > This finally allowed openstack/nova to pass on stable/train with the > > > > following changes to lower-constraints.txt and test-requirements.txt: > > > > > > > > [stable-only] Cap bandit to 1.6.2 and raise hacking, flake8 and stestr > > > > https://review.opendev.org/c/openstack/nova/+/766171/ > > > > > > > > Are there any objections to disabling Swift in Grenade for the time > > > > being on stable/train? > > > > > > > > Would anyone have any objections to also disabling it on stable/stein > > > > via devstack-gate? > > > > > > Thanks, Lee for reporting this. > > > > > > keystonemiddleware is listed as an extras requirement in swift > > > - https://github.com/openstack/swift/blob/e0d46d77fa740768f1dd5b989a63be85ff1fec20/setup.cfg#L79 > > > > > > But devstack does not install any extras requirement for swift. I am trying to install > > > the swift's keystone extras and see if it work fine. > > > > > > - https://review.opendev.org/q/I02c692e95d70017eea03d82d75ae6c5e87bde8b1 > > > > This fix working fine tested in https://review.opendev.org/c/openstack/swift/+/766214 > > > > grenade job will be working once we merge the devstack fixes in stable branches > > ACK thanks, I hope you don't mind but I've addressed some nits raised in > the review this morning. I'll repropose backports once it's in the gate. Devstack fixes until stable/stein are merged. This is not occurring on stable/rocky and queens so I will abandon the fix for those branches. - https://review.opendev.org/q/topic:%22bug%252F1909018%22+(status:open%20OR%20status:merged) -gmann > > -- > Lee Yarwood A5D1 9385 88CB 7E5F BE64 6618 BCA6 6E33 F672 2D76 > From ikatzir at infinidat.com Thu Jan 7 15:33:49 2021 From: ikatzir at infinidat.com (Igal Katzir) Date: Thu, 7 Jan 2021 17:33:49 +0200 Subject: [tripleO] Customised Cinder-Volume fails at 'Paunch 5' during overcloud deployment In-Reply-To: References: <2D1F2693-49C0-4CA2-8F8E-F9E837D6A232@infinidat.com> Message-ID: Just an update on this issue; The problem was fixed after I removed the following line from my Dockerfile- 'RUN pip install --no-cache-dir -U setuptools' Apparently, This caused a problem to run /usr/sbin/pcs command which is required during overcloud deployment. Another question I have is about re-starting a container, if I have re-built the openstack-cinder-volume image on my overcloud-controller and want to test something, how can I start the container from the new image? Do I need to redeploy the entire overcloud? (it doesn't make sense) Thanks for the help, Igal On Mon, Jan 4, 2021 at 6:44 PM Alan Bishop wrote: > > On Mon, Jan 4, 2021 at 5:31 AM Igal Katzir wrote: > >> Hello Alan, >> Thanks for your reply! >> >> I am afraid that the reason for my deployment failure might be concerned >> with the environment file I use to configure my cinder backend. >> The configuration is quite similar to >> https://github.com/Infinidat/tripleo-deployment-configs/blob/dev/RHOSP15/cinder-infinidat-config.yaml >> So I wonder if it is possible to run a deployment where I tell 'TripleO' >> to use my customize container, using containers-prepare-parameter.yaml, but >> without the environment file =cinder-infinidat-config.yaml, and configure >> the backend / start cinder-volume services manually? >> > > No, your cinder-infinidat-config.yaml file looks fine. It's responsible > for getting TripleO to configure cinder to use your driver, and that phase > was completed successfully prior to the deployment failure. > > >> Or I must have a minimum config as I find in: >> '/usr/share/openstack-tripleo-heat-templates/deployment/cinder/' (for other >> vendors)? >> If I do need such a cinder-volume-VENDOR-puppet.yaml config to be >> integrated during overcloud deployment, where is documentation that >> explains how to construct this? Do I need to use cinder-base.yaml as a >> template? >> When looking at the web for "cinder-volume-container-puppet.yaml" I found >> the Git Page of overcloud-resource-registry-puppet.j2.yaml >> >> >> and found also >> https://opendev.org/openstack/tripleo-heat-templates/../deployment >> >> but it is not so explanatory. >> > > Your cinder-infinidat-config.yaml uses a low-level puppet mechanism for > configuring what's referred to as a "custom" block storage backend. This is > perfectly fine. If you want better integration with TripleO (and puppet) > then you'll need to develop 3 separate patches, 1 each in puppet-cinder, > puppet-tripleo and tripleo-heat-templates. Undertaking that would be a > good future goal, but isn't necessary in order for you to get past your > current deployment issue. > > >> I have opened a case with RedHat as well and they are checking who from >> their R&D could help since it's out of the scope of support. >> > > I think you're starting to see responses from Red Hat that should help > identify and resolve the problem. > > Alan > > >> >> Regards, >> Igal >> >> On Thu, Dec 31, 2020 at 9:15 PM Alan Bishop wrote: >> >>> >>> >>> On Thu, Dec 31, 2020 at 5:26 AM Igal Katzir >>> wrote: >>> >>>> Hello all, >>>> >>>> I am trying to deploy RHOSP16.1 (based on ‘*train’ *distribution) for Certification >>>> purposes. >>>> I have build a container for our cinder driver and trying to deploy it. >>>> Deployment runs almost till the end and fails at stage when it tries to >>>> configure Pacemaker; >>>> Here is the last message: >>>> >>>> "Info: Applying configuration version '1609231063'", "Notice: /Stage[main]/Pacemaker::Corosync/File_line[pcsd_bind_addr]/ensure: created", "Info: /Stage[main]/Pacemaker::Corosync/File_line[pcsd_bind_addr]: Scheduling refresh of Service[pcsd]", "Info: /Stage[main]/Pacemaker::Service/Service[pcsd]: Unscheduling all events on Service[pcsd]", "Info: Class[Pacemaker::Corosync]: Unscheduling all events on Class[Pacemaker::Corosync]", "Notice: /Stage[main]/Tripleo::Profile::Pacemaker::Cinder::Volume_bundle/Pacemaker::Resource::Bundle[openstack-cinder-volume]/Pcmk_bundle[openstack-cinder-volume]: Dependency Pcmk_property[property-overcloud-controller-0-cinder-volume-role] has failures: true", "Info: Creating state file /var/lib/puppet/state/state.yaml", "Notice: Applied catalog in 382.92 seconds", "Changes:", " Total: 1", "Events:", " Success: 1", " Failure: 2", " Total: 3", >>>> >>>> >>>> I have verified that all packages on my container-image >>>> (Pacemaker,Corosync, libqb,and pcs) are installed with same versions as >>>> the overcloud-controller. >>>> >>> >>> Hi Igal, >>> >>> Thank you for checking these package versions and stating they match the >>> ones installed on the overcloud node. This rules out one of the common >>> reasons for failures when trying to run a customized cinder-volume >>> container image. >>> >>> But seems that something is still missing, because deployment with the >>>> default openstack-cinder-volume image completes successfully. >>>> >>> >>> This is also good to know. >>> >>> Can anyone help with debugging this? Let me know if more info needed. >>>> >>> >>> More info is needed, but it's hard to predict exactly where to look for >>> the root cause of the failure. I'd start by looking for something at the >>> cinder log file >>> to determine whether the cinder-volume service is even trying to start. >>> Look for /var/log/containers/cinder/cinder-volume.log on the node where >>> pacemaker is trying to run the service. Are there logs indicating the >>> service is trying to start? Or maybe the service is launched, but fails >>> early during startup? >>> >>> Another possibility is podman fails to launch the container itself. If >>> that's happening then check for errors in /var/log/messages. One source of >>> this type of failure is you've specified a container bind mount, but the >>> source directory doesn't exist (docker would auto-create the source >>> directory, but podman does not). >>> >>> You specifically mentioned RHOSP, so if you need additional support then >>> I recommend opening a support case with Red Hat. That will provide a forum >>> for posting private data, such as details of your overcloud deployment and >>> full sosreports. >>> >>> Alan >>> >>> >>>> >>>> Thanks in advance, >>>> Igal >>>> >>> >> >> -- >> Regards, >> >> *Igal Katzir* >> Cell +972-54-5597086 >> Interoperability Team >> *INFINIDAT* >> >> >> >> >> -- Regards, *Igal Katzir* Cell +972-54-5597086 Interoperability Team *INFINIDAT* -------------- next part -------------- An HTML attachment was scrubbed... URL: From fungi at yuggoth.org Thu Jan 7 16:34:21 2021 From: fungi at yuggoth.org (Jeremy Stanley) Date: Thu, 7 Jan 2021 16:34:21 +0000 Subject: [all][tc] Dropping lower-constraints testing from all projects In-Reply-To: <1c2ec93642e847aa6650f9e9af34a6fae5f9278b.camel@redhat.com> References: <176d8da769b.b6edb13b874337.4809906168220534198@ghanshyammann.com> <1c2ec93642e847aa6650f9e9af34a6fae5f9278b.camel@redhat.com> Message-ID: <20210107163421.oxslpa27b6fis5up@yuggoth.org> On 2021-01-07 10:15:59 +0000 (+0000), Stephen Finucane wrote: [...] > Out of curiosity, would limiting the list in lower-constraints to > the set of requirements listed in 'requirements.txt' help matters? > That would at least ensure the lower version of our explicit > dependencies worked. The main issue I could see with this is > potentially a lot of thrashing from pip as it attempts to find > versions of implicit dependencies that satisfy the various > constraints, but I guess we'll have to address that when we come > to it. You can try it locally easily enough, but my recollections from before is that what you'll find for larger projects is old releases of some dependencies don't pin upper bounds of their own dependencies and wind up not being usable because they drag in something newer than they can actually use, so it'll be an iterative effort to figure those out. Which has essentially been my problem with that lower bounds testing model, it's a manual effort to figure out what versions of modules in the transitive set will actually be compatible with one another, and then you basically get to redo that work any time you want to adjust a lower bound for something. But do give it a shot and let us know if it winds up being easier than all that. -- Jeremy Stanley -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From dtantsur at redhat.com Thu Jan 7 16:39:09 2021 From: dtantsur at redhat.com (Dmitry Tantsur) Date: Thu, 7 Jan 2021 17:39:09 +0100 Subject: [ironic] SPUC in 2021 In-Reply-To: References: Message-ID: Okay, in case somebody still wants to do it, "thanks" to Bluejeans I need to change meeting IDs: Friday, 10am UTC: https://bluejeans.com/772893798 Friday, 5pm UTC: https://bluejeans.com/250125662 Dmitry On Thu, Jan 7, 2021 at 2:28 PM Dmitry Tantsur wrote: > Hi folks! > > I feel like SPUC (our Sanity Preserving Un-Conference) has been very > successful in 2020, what do you think about continuing it as before: > Friday, 10am UTC (in https://bluejeans.com/643711802) > Friday, 5pm UTC (in https://bluejeans.com/313987753) > ? > > Dmitry > -- > Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn, > Commercial register: Amtsgericht Muenchen, HRB 153243, > Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael > O'Neill > -- Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill -------------- next part -------------- An HTML attachment was scrubbed... URL: From gmann at ghanshyammann.com Thu Jan 7 16:52:50 2021 From: gmann at ghanshyammann.com (Ghanshyam Mann) Date: Thu, 07 Jan 2021 10:52:50 -0600 Subject: [all][tc] Dropping lower-constraints testing from all projects In-Reply-To: <20210107163421.oxslpa27b6fis5up@yuggoth.org> References: <176d8da769b.b6edb13b874337.4809906168220534198@ghanshyammann.com> <1c2ec93642e847aa6650f9e9af34a6fae5f9278b.camel@redhat.com> <20210107163421.oxslpa27b6fis5up@yuggoth.org> Message-ID: <176ddc3e162.b89daf27919574.878082988451964097@ghanshyammann.com> ---- On Thu, 07 Jan 2021 10:34:21 -0600 Jeremy Stanley wrote ---- > On 2021-01-07 10:15:59 +0000 (+0000), Stephen Finucane wrote: > [...] > > Out of curiosity, would limiting the list in lower-constraints to > > the set of requirements listed in 'requirements.txt' help matters? > > That would at least ensure the lower version of our explicit > > dependencies worked. The main issue I could see with this is > > potentially a lot of thrashing from pip as it attempts to find > > versions of implicit dependencies that satisfy the various > > constraints, but I guess we'll have to address that when we come > > to it. > > You can try it locally easily enough, but my recollections from > before is that what you'll find for larger projects is old releases > of some dependencies don't pin upper bounds of their own > dependencies and wind up not being usable because they drag in > something newer than they can actually use, so it'll be an iterative > effort to figure those out. Which has essentially been my problem > with that lower bounds testing model, it's a manual effort to figure > out what versions of modules in the transitive set will actually be > compatible with one another, and then you basically get to redo that > work any time you want to adjust a lower bound for something. > > But do give it a shot and let us know if it winds up being easier > than all that. I have not tested it yet but from past testing observation, I remember I end up adding some implicit deps in l-c as they were not compatible with project explicit deps and their deps compatibility so it has to be in l-c explicitly. So I am not sure if restricting the l-c with requirements.txt deps can work or not but good to try. -gmann > -- > Jeremy Stanley > From hberaud at redhat.com Thu Jan 7 16:53:44 2021 From: hberaud at redhat.com (Herve Beraud) Date: Thu, 7 Jan 2021 17:53:44 +0100 Subject: [release] Status: ORANGE - pip resolver issue with publish-openstack-releasenotes-python3 In-Reply-To: References: Message-ID: Hello everyone, @release managers: all impacted projects now have fixes submitted, so before validating a patch you only have to ensure that the released projects aren't in the list of opened patches: https://review.opendev.org/q/topic:%2522fix-relmgt-pip-doc%2522+(status:open) I move our status to ORANGE as the situation seems improving for now and also because we can easily monitor the state. @all: Notice that some projects have been ignored here because they aren't released, here is the list: i18n ideas openstack-manuals openstack-zuul-roles os-apply-config os-collect-config os-refresh-config ossa pyeclib security-analysis security-doc tempest-lib tempest-stress training-guides workload-ref-archs However it could be worth it to uniformize them, but we leave it to the teams to update them. Also notice that we proposed to add the capabilities to zuul to retrieve requirements from a dedicated place: https://review.opendev.org/c/zuul/zuul-jobs/+/769292 It will help projects that haven't documentation but that produce release notes to split their requirements more properly. If you've questions do not hesitate to ping us on #openstack-release Thanks for your reading Le mer. 6 janv. 2021 à 12:47, Herve Beraud a écrit : > @release mangaers: For now I think we can restart validating projects that > aren't present in the previous list (c.f > http://lists.openstack.org/pipermail/openstack-discuss/2021-January/019612.html > ). > Normally they aren't impacted by this problem. > > I'll move to the "Orange" state when all the projects of list will be > patched or at least when a related patch will be present in the list (c.f > https://review.opendev.org/q/topic:%2522fix-relmgt-pip-doc%2522+(status:open+OR+status:merged)). > For now my monitoring indicates that ~50 projects still need related > changes. > > So, for now, please, ensure that the repos aren't listed here before > validate a patch > http://lists.openstack.org/pipermail/openstack-discuss/2021-January/019612.html > > Thanks to everyone who helped here! Much appreciated! > > Le mar. 5 janv. 2021 à 12:05, Martin Chacon Piza > a écrit : > >> Hi Herve, >> >> I have added this topic to the Monasca irc meeting today. >> >> Thank you, >> Martin (chaconpiza) >> >> >> >> El lun, 4 de ene. de 2021 a la(s) 18:30, Herve Beraud (hberaud at redhat.com) >> escribió: >> >>> Thanks all! >>> >>> Here we can track our advancement: >>> >>> https://review.opendev.org/q/topic:%22fix-relmgt-pip-doc%22+(status:open%20OR%20status:merged) >>> >>> Le lun. 4 janv. 2021 à 18:02, Radosław Piliszek < >>> radoslaw.piliszek at gmail.com> a écrit : >>> >>>> On Mon, Jan 4, 2021 at 4:34 PM Herve Beraud wrote: >>>> > >>>> > Here is the filtered list of projects that meet the conditions >>>> leading to the bug, and who should be fixed to completely solve our issue: >>>> > >>>> > ... >>>> > etcd3gw >>>> > ... >>>> > python-masakariclient >>>> > ... >>>> > >>>> > Notice that some of these projects aren't deliverables but if >>>> possible it could be worth fixing them too. >>>> > >>>> > These projects have an incompatibility between entries in their >>>> test-requirements.txt, and they're missing a doc/requirements.txt file. >>>> > >>>> > The more straightforward path to unlock our job >>>> "publish-openstack-releasenotes-python3" is to create a >>>> doc/requirements.txt file that only contains the needed dependencies to >>>> reduce the possibility of pip resolver issues. I personally think that we >>>> could use the latest allowed version of requirements (sphinx, reno, etc...). >>>> > >>>> > I propose to track the related advancement by using the >>>> "fix-relmgt-pip-doc" gerrit topic, when all the projects will be fixed we >>>> would be able to update our status. >>>> > >>>> > Also it could be worth fixing test-requirements.txt incompatibilities >>>> but this task is more on the projects teams sides and this task could be >>>> done with a follow up patch. >>>> > >>>> > Thoughts? >>>> >>>> Thanks, Hervé! >>>> >>>> Done for python-masakariclient in [1]. >>>> >>>> etcd3gw needs more love in general but I will have this split in mind. >>>> >>>> [1] >>>> https://review.opendev.org/c/openstack/python-masakariclient/+/769163 >>>> >>>> -yoctozepto >>>> >>>> >>> >>> -- >>> Hervé Beraud >>> Senior Software Engineer at Red Hat >>> irc: hberaud >>> https://github.com/4383/ >>> https://twitter.com/4383hberaud >>> -----BEGIN PGP SIGNATURE----- >>> >>> wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ >>> Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ >>> RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP >>> F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G >>> 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g >>> glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw >>> m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ >>> hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 >>> qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y >>> F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 >>> B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O >>> v6rDpkeNksZ9fFSyoY2o >>> =ECSj >>> -----END PGP SIGNATURE----- >>> >>> >> >> -- >> *Martín Chacón Pizá* >> *chacon.piza at gmail.com * >> > > > -- > Hervé Beraud > Senior Software Engineer at Red Hat > irc: hberaud > https://github.com/4383/ > https://twitter.com/4383hberaud > -----BEGIN PGP SIGNATURE----- > > wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ > Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ > RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP > F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G > 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g > glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw > m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ > hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 > qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y > F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 > B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O > v6rDpkeNksZ9fFSyoY2o > =ECSj > -----END PGP SIGNATURE----- > > -- Hervé Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/ https://twitter.com/4383hberaud -----BEGIN PGP SIGNATURE----- wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O v6rDpkeNksZ9fFSyoY2o =ECSj -----END PGP SIGNATURE----- -------------- next part -------------- An HTML attachment was scrubbed... URL: From radoslaw.piliszek at gmail.com Thu Jan 7 16:55:44 2021 From: radoslaw.piliszek at gmail.com (=?UTF-8?Q?Rados=C5=82aw_Piliszek?=) Date: Thu, 7 Jan 2021 17:55:44 +0100 Subject: [all][tc] Dropping lower-constraints testing from all projects In-Reply-To: <20210107163421.oxslpa27b6fis5up@yuggoth.org> References: <176d8da769b.b6edb13b874337.4809906168220534198@ghanshyammann.com> <1c2ec93642e847aa6650f9e9af34a6fae5f9278b.camel@redhat.com> <20210107163421.oxslpa27b6fis5up@yuggoth.org> Message-ID: On Thu, Jan 7, 2021 at 5:42 PM Jeremy Stanley wrote: > > On 2021-01-07 10:15:59 +0000 (+0000), Stephen Finucane wrote: > [...] > > Out of curiosity, would limiting the list in lower-constraints to > > the set of requirements listed in 'requirements.txt' help matters? > > That would at least ensure the lower version of our explicit > > dependencies worked. The main issue I could see with this is > > potentially a lot of thrashing from pip as it attempts to find > > versions of implicit dependencies that satisfy the various > > constraints, but I guess we'll have to address that when we come > > to it. > > You can try it locally easily enough, but my recollections from > before is that what you'll find for larger projects is old releases > of some dependencies don't pin upper bounds of their own > dependencies and wind up not being usable because they drag in > something newer than they can actually use This is also why we can't really have a smart-enough solver trying to minimize dep versions as some have no bounds on either side. What would the verdict then be? If it was to install the oldest version ever, I bet it would fail most of the time. For me, lower constraints are well too complicated to really get right, and, moreover, checking only unit tests with them is likely not useful enough to warrant that they result in working deployments. I don't envy distro packagers but really the only thing they can bet on is deciding on a set of packaged deps and running tempest against the curated deployment (plus unit tests as they are much cheaper anyhow). Thanks to upper-constraints we know there is at least one combination of deps that will work. We can't really ensure any other in a simple manner. -yoctozepto From fungi at yuggoth.org Thu Jan 7 17:22:24 2021 From: fungi at yuggoth.org (Jeremy Stanley) Date: Thu, 7 Jan 2021 17:22:24 +0000 Subject: [all][tc] Dropping lower-constraints testing from all projects In-Reply-To: References: <176d8da769b.b6edb13b874337.4809906168220534198@ghanshyammann.com> <1c2ec93642e847aa6650f9e9af34a6fae5f9278b.camel@redhat.com> <20210107163421.oxslpa27b6fis5up@yuggoth.org> Message-ID: <20210107172224.vvm7fur2fnpdl2fk@yuggoth.org> On 2021-01-07 17:55:44 +0100 (+0100), Radosław Piliszek wrote: [...] > This is also why we can't really have a smart-enough solver trying to > minimize dep versions as some have no bounds on either side. What > would the verdict then be? If it was to install the oldest version > ever, I bet it would fail most of the time. Yes, I expect that too would require some manual tweaking to find appropriate versions to override with, however that wouldn't need to be redone nearly as often as what you end up with when you're fighting tools which always want to install the most recent available version. > For me, lower constraints are well too complicated to really get > right, and, moreover, checking only unit tests with them is likely not > useful enough to warrant that they result in working deployments. [...] This I agree with. I think lower bounds checking is theoretically possible with appropriate tools (which don't currently exist), but would still involve filling in yourself for the authors of less rigorously maintained projects in your transitive dependency set. More generally, basically nothing in the Python packaging ecosystem is designed with the idea of supporting a solution to this, and there's very little to encourage a project to even list much less keep up minimum versions of dependencies, except in order to force an upgrade. -- Jeremy Stanley -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From juliaashleykreger at gmail.com Thu Jan 7 17:42:04 2021 From: juliaashleykreger at gmail.com (Julia Kreger) Date: Thu, 7 Jan 2021 09:42:04 -0800 Subject: [ironic] SPUC in 2021 In-Reply-To: References: Message-ID: Sounds like a perfect way to enjoy Friday :) Thanks Dmitry! On Thu, Jan 7, 2021 at 8:47 AM Dmitry Tantsur wrote: > > Okay, in case somebody still wants to do it, "thanks" to Bluejeans I need to change meeting IDs: > > Friday, 10am UTC: https://bluejeans.com/772893798 > Friday, 5pm UTC: https://bluejeans.com/250125662 > > Dmitry > > On Thu, Jan 7, 2021 at 2:28 PM Dmitry Tantsur wrote: >> >> Hi folks! >> >> I feel like SPUC (our Sanity Preserving Un-Conference) has been very successful in 2020, what do you think about continuing it as before: >> Friday, 10am UTC (in https://bluejeans.com/643711802) >> Friday, 5pm UTC (in https://bluejeans.com/313987753) >> ? >> >> Dmitry >> -- >> Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn, >> Commercial register: Amtsgericht Muenchen, HRB 153243, >> Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill > > > > -- > Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn, > Commercial register: Amtsgericht Muenchen, HRB 153243, > Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill From jp.methot at planethoster.info Thu Jan 7 16:58:05 2021 From: jp.methot at planethoster.info (=?utf-8?Q?Jean-Philippe_M=C3=A9thot?=) Date: Thu, 7 Jan 2021 11:58:05 -0500 Subject: [nova] Nova evacuate issue In-Reply-To: <20210107142638.3u2duxgdsrj5fe5y@lyarwood-laptop.usersys.redhat.com> References: <20210107142638.3u2duxgdsrj5fe5y@lyarwood-laptop.usersys.redhat.com> Message-ID: Considering that this issue happened in our production environment, it’s not exactly possible to try to reproduce without shutting down servers that are currently in use. That said, If the current logs I have are enough, I will try opening a bug on the bugtracker. Compute22, the source host, was completely dead. It refused to boot up through IPMI. It is possible that that stein fix prevented me from reproducing the problem in my staging environment (production is on rocky, staging is on stein). Also, it may be important to note that our neutron is split, as we use neutron-rpc-server to answer rpc calls. It’s also HA, as we have two controllers with neutron-rpc-server and the api running (and that won’t work anymore when we upgrade production to stein, but that’s another problem entirely and probably off-topic here). Jean-Philippe Méthot Senior Openstack system administrator Administrateur système Openstack sénior PlanetHoster inc. 4414-4416 Louis B Mayer Laval, QC, H7P 0G1, Canada > Le 7 janv. 2021 à 09:26, Lee Yarwood a écrit : > > Would you be able to trace an example evacuation request fully and > pastebin it somewhere using `openstack server event list $instance [1]` > output to determine the request-id etc? Feel free to also open a bug > about this and we can just triage there instead of the ML. > > The fact that q-api has sent the > network-vif-plugged:80371c01-930d-4ea2-9d28-14438e948b65 to n-api > suggests that the q-agt is actually alive on compute22, was that the > case? Note that a pre-condition of calling the evacuation API is that > the source host has been fenced [2]. > > That all said I wonder if this is somehow related too the following > stein change: > > https://review.opendev.org/c/openstack/nova/+/603844 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mrunge at matthias-runge.de Thu Jan 7 18:57:34 2021 From: mrunge at matthias-runge.de (Matthias Runge) Date: Thu, 7 Jan 2021 19:57:34 +0100 Subject: OpenStack Ansible - Telemetry In-Reply-To: <2A904BE8-8679-4C8A-89C3-DF9D7AF89E44@vsb.cz> References: <2A904BE8-8679-4C8A-89C3-DF9D7AF89E44@vsb.cz> Message-ID: <148a3fde-c75f-ed9b-e2d0-84cca2519683@matthias-runge.de> On 07/01/2021 13:20, Golasowski Martin wrote: > Dear All, > I would like to know which monitoring solution is currently supported by > OSA? We are operating a small cloud (~ 6 nodes) and we are interested in > collecting performance metrics, events and logs. > > So, as far as I know, the official OSA solution is ceilometer/aodh/panko > with Gnocchi as DB backend. However Gnocchi project seems abandoned at > the moment and the grafana plugin is not compatible with latest Grafana. > > Then there is solution based on collectd with this plugin > (https://github.com/signalfx/collectd-openstack > ) with Graphite or > InfluxDB as backend. This supports only performance metrics and not the > events. > > Then there are also some Prometheus exporters available, again, metrics > only. > > What do you guys use these days? What would you recommend? > Hi there, with my telemetry hat on: we're working on the gnocchi issue, but gnocchi is only a metrics store anyways. Personally, I wouldn't want to store any events in panko. If you use such things like autoscaling for instances, you definitely want gnocchi and aodh. With my collectd hat on: collectd supports collecting and sending metrics and events to multiple write endpoints. It is not designed to collect additional metadata, such as project or user data. You'll mostly get infrastructure related data (from baremetal nodes). The con side with using graphite or influxdb in the Open Source variant is, that you don't get HA. There is the Service Telemetry Framework[1], but it is integrated with TripleO, not with OSA, it uses both collectd and ceilometer for collection; metrics are stored in prometheus, events in elasticsearch, which is also used for log aggregation. I am unsure if this solution is not a bit too heavy for your use case. The best interest (in this community here): put some man-power on gnocchi. Matthias [1] https://infrawatch.github.io/documentation/ From martin.golasowski at vsb.cz Thu Jan 7 20:39:45 2021 From: martin.golasowski at vsb.cz (Golasowski Martin) Date: Thu, 7 Jan 2021 20:39:45 +0000 Subject: OpenStack Ansible - Telemetry In-Reply-To: <148a3fde-c75f-ed9b-e2d0-84cca2519683@matthias-runge.de> References: <2A904BE8-8679-4C8A-89C3-DF9D7AF89E44@vsb.cz> <148a3fde-c75f-ed9b-e2d0-84cca2519683@matthias-runge.de> Message-ID: <7547C949-1A4C-435C-927A-6869F25ED849@vsb.cz> Thanks! So, in that case, “builtin” ceilometer with gnocchi is the way to go. In fact, it works when deployed with OSA, the only problem is incompatible Grafana plugin. Would you recommend some other tool to visualise gnocchi metrics? We can always downgrade Grafana to the last version which was compatible with the plugin, but that may break other telemetry. Regards, Martin > On 7. 1. 2021, at 19:57, Matthias Runge wrote: > > On 07/01/2021 13:20, Golasowski Martin wrote: >> Dear All, >> I would like to know which monitoring solution is currently supported by OSA? We are operating a small cloud (~ 6 nodes) and we are interested in collecting performance metrics, events and logs. >> So, as far as I know, the official OSA solution is ceilometer/aodh/panko with Gnocchi as DB backend. However Gnocchi project seems abandoned at the moment and the grafana plugin is not compatible with latest Grafana. >> Then there is solution based on collectd with this plugin (https://github.com/signalfx/collectd-openstack ) with Graphite or InfluxDB as backend. This supports only performance metrics and not the events. >> Then there are also some Prometheus exporters available, again, metrics only. >> What do you guys use these days? What would you recommend? > > Hi there, > > with my telemetry hat on: we're working on the gnocchi issue, but gnocchi is only a metrics store anyways. Personally, I wouldn't want to store any events in panko. If you use such things like autoscaling for instances, you definitely want gnocchi and aodh. > > With my collectd hat on: collectd supports collecting and sending metrics and events to multiple write endpoints. It is not designed to collect additional metadata, such as project or user data. You'll mostly get infrastructure related data (from baremetal nodes). > The con side with using graphite or influxdb in the Open Source variant is, that you don't get HA. > > There is the Service Telemetry Framework[1], but it is integrated with TripleO, not with OSA, it uses both collectd and ceilometer for collection; metrics are stored in prometheus, events in elasticsearch, which is also used for log aggregation. I am unsure if this solution is not a bit too heavy for your use case. > > > The best interest (in this community here): put some man-power on gnocchi. > > Matthias > > > [1] https://infrawatch.github.io/documentation/ > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3632 bytes Desc: not available URL: From dvd at redhat.com Thu Jan 7 20:49:25 2021 From: dvd at redhat.com (David Vallee Delisle) Date: Thu, 7 Jan 2021 15:49:25 -0500 Subject: [nova] Nova evacuate issue In-Reply-To: References: <20210107142638.3u2duxgdsrj5fe5y@lyarwood-laptop.usersys.redhat.com> Message-ID: That would be great to have debug log level, it's easier to troubleshoot migration issues. DVD - written my phone, please ignore the tpyos On Thu., Jan. 7, 2021, 1:27 p.m. Jean-Philippe Méthot, < jp.methot at planethoster.info> wrote: > Considering that this issue happened in our production environment, it’s > not exactly possible to try to reproduce without shutting down servers that > are currently in use. That said, If the current logs I have are enough, I > will try opening a bug on the bugtracker. > > Compute22, the source host, was completely dead. It refused to boot up > through IPMI. > > It is possible that that stein fix prevented me from reproducing the > problem in my staging environment (production is on rocky, staging is on > stein). > > Also, it may be important to note that our neutron is split, as we use > neutron-rpc-server to answer rpc calls. It’s also HA, as we have two > controllers with neutron-rpc-server and the api running (and that won’t > work anymore when we upgrade production to stein, but that’s another > problem entirely and probably off-topic here). > > Jean-Philippe Méthot > Senior Openstack system administrator > Administrateur système Openstack sénior > PlanetHoster inc. > 4414-4416 Louis B Mayer > Laval, QC, H7P 0G1, Canada > > > > > > Le 7 janv. 2021 à 09:26, Lee Yarwood a écrit : > > Would you be able to trace an example evacuation request fully and > pastebin it somewhere using `openstack server event list $instance [1]` > output to determine the request-id etc? Feel free to also open a bug > about this and we can just triage there instead of the ML. > > The fact that q-api has sent the > network-vif-plugged:80371c01-930d-4ea2-9d28-14438e948b65 to n-api > suggests that the q-agt is actually alive on compute22, was that the > case? Note that a pre-condition of calling the evacuation API is that > the source host has been fenced [2]. > > That all said I wonder if this is somehow related too the following > stein change: > > https://review.opendev.org/c/openstack/nova/+/603844 > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ankelezhang at gmail.com Thu Jan 7 00:40:30 2021 From: ankelezhang at gmail.com (Ankele zhang) Date: Thu, 7 Jan 2021 08:40:30 +0800 Subject: tinyipa cannot boot OS of baremetal node In-Reply-To: References: Message-ID: Thanks for the tip! I have make images based on dib of ironic-python-agent-builder, and it's really useful. Ankele Riccardo Pittau 于2021年1月6日周三 下午5:10写道： > Hello Ankele, > > if you're using ironic on production servers I suggest you to build and > use ironic-python-agent images based on diskimage-builder as explained here: > > https://docs.openstack.org/ironic-python-agent-builder/latest/admin/dib.html > > The tinyipa image is best suited for testing and development and not > recommended for production usage. > > Thanks, > > Riccardo > > > On Tue, Jan 5, 2021 at 5:45 PM Ankele zhang wrote: > >> Hi~ >> >> My Rocky OpenStack platform deployed with official documents, includes >> Keystone/Cinder/Neutron/Nova and Ironic. >> >> I used to boot my baremetal nodes by CoreOS downloaded on >> https://tarballs.opendev.org/openstack/ironic-python-agent/coreos/files/ >> >> >> Since I want to customize my own HardwareManager for configuring RAID, I >> have build TinyIPA image tinyipa.tar.gz and tinyipa.vmlinuz with >> ironic-python-agent-builder(master branch) and ironic-python-agent(rocky >> branch). Here are all the products of the build process. >> [image: image.png] >> Then I used these two images to create the baremetal node, and boot nova >> server, but I didn't get the results I wanted, it couldn't enter the >> ramdisk and always in 'wait call-back' state. as following >> >> [image: image.png] >> I got nothing in /var/log/ironic/ironig-conductor.log and >> /var/log/nova/nova-compute.log >> >> I don't know if these two image (tinyipa.tar.gz and tinyipa.vmlinuz) are >> valid for Ironic. If not, how can I customize HardwareManager? >> >> Looking forward to hearing from you. >> >> Ankele >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 126537 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 27968 bytes Desc: not available URL: From ryan at messagecloud.com Thu Jan 7 17:14:12 2021 From: ryan at messagecloud.com (Ryan Price-King) Date: Thu, 7 Jan 2021 17:14:12 +0000 Subject: Cannot login to Built trovestack image Message-ID: Hi, I am having problems with the image being deployed correctly with nova, but the communication to the guestagent is timing out and i am stuck in build stage. ./trovestack build-image ubuntu bionic true ubuntu Also with that, I dont know which mysql version it is building. I am assuming it is 5.7.29. I cannot diagnose as i cannot login to the guest image instance. I assume the user is ubuntu, but i cannot login with any password that i have tried. Can you tell me what username/password to login to the instance by console in openstack please. Regards, Ryan -------------- next part -------------- An HTML attachment was scrubbed... URL: From ryan at messagecloud.com Thu Jan 7 17:15:39 2021 From: ryan at messagecloud.com (Ryan Price-King) Date: Thu, 7 Jan 2021 17:15:39 +0000 Subject: Cannot login to Built trovestack image In-Reply-To: References: Message-ID: Hi, Sorry I meant the instance is being deployed in nova correctly and entering running state and console gives me login screen. Regards, Ryan On Thu, 7 Jan 2021 at 17:14, Ryan Price-King wrote: > Hi, > > I am having problems with the image being deployed correctly with nova, > but the communication to the guestagent is timing out and i am stuck in > build stage. > > ./trovestack build-image ubuntu bionic true ubuntu > > > Also with that, I dont know which mysql version it is building. > > I am assuming it is 5.7.29. > > I cannot diagnose as i cannot login to the guest image instance. > > I assume the user is ubuntu, but i cannot login with any password that i > have tried. > > Can you tell me what username/password to login to the instance by > console in openstack please. > > Regards, > Ryan > -------------- next part -------------- An HTML attachment was scrubbed... URL: From SSelf at performair.com Thu Jan 7 21:20:54 2021 From: SSelf at performair.com (SSelf at performair.com) Date: Thu, 7 Jan 2021 21:20:54 +0000 Subject: [cinder] Cinder & Ceph Integration Error: No Valid Backend Message-ID: All; We're having problems with our Openstack/Ceph integration. The versions we're using are Ussuri & Nautilus. When trying to create a volume, the volume is created, though the status is stuck at 'ERROR'. This appears to be the most relevant line from the Cinder scheduler.log: 2021-01-07 14:00:38.473 140686 ERROR cinder.scheduler.flows.create_volume [req-f86556b5-cb2e-4b2d-b556-ed07e632289d 824c26c133b34d8b8e84a7acabbe6f91 a983323b5ffc47e18660794cd9344869 - default default] Failed to run task cinder.scheduler.flows.create_volume.ScheduleCreateVolumeTask;volume:create: No valid backend was found. No weighed backends available: cinder.exception.NoValidBackend: No valid backend was found. No weighed backends available Here is the 'cinder.conf' from our Controller Node: [DEFAULT] # define own IP address my_ip = 10.0.80.40 log_dir = /var/log/cinder state_path = /var/lib/cinder auth_strategy = keystone enabled_backends = ceph glance_api_version = 2 debug = true # RabbitMQ connection info transport_url = rabbit://openstack:@10.0.80.40:5672 enable_v3_api = True # MariaDB connection info [database] connection = mysql+pymysql://cinder:@10.0.80.40/cinder # Keystone auth info [keystone_authtoken] www_authenticate_uri = http://10.0.80.40:5000 auth_url = http://10.0.80.40:5000 memcached_servers = 10.0.80.40:11211 auth_type = password project_domain_name = default user_domain_name = default project_name = service username = cinder password = [oslo_concurrency] lock_path = $state_path/tmp [ceph] volume_driver = cinder.volume.drivers.rbd.RBDDriver volume_backend_name = ceph rbd_pool = rbd_os_volumes rbd_ceph_conf = /etc/ceph/463/ceph.conf rbd_flatten_volume_from_snapshot = false rbd_max_clone_depth = 5 rbd_store_chunk_size = 4 rados_connect_timeout = -1 rbd_user = cinder rbd_exclusive_cinder_pool = true backup_driver = cinder.backup.drivers.ceph backup_ceph_conf = /etc/ceph/300/ceph.conf backup_ceph_user = cinder-backup backup_ceph_chunk_size = 134217728 backup_ceph_pool = rbd_os_backups backup_ceph_stripe_unit = 0 backup_ceph_stripe_count = 0 restore_discard_excess_bytes = true Does anyone have any ideas as to what is going wrong? Thank you, Stephen Self IT Manager Perform Air International sself at performair.com www.performair.com From SSelf at performair.com Thu Jan 7 23:28:10 2021 From: SSelf at performair.com (SSelf at performair.com) Date: Thu, 7 Jan 2021 23:28:10 +0000 Subject: [cinder] Cinder & Ceph Integration Error: No Valid Backend In-Reply-To: References: Message-ID: All; The overall issue has been resolved. There were two major causes: Misplacement of keyring(s) (they were not within /etc/ceph/) 'openstack-cinder-volume' service was not started/enabled Thank you, Stephen Self IT Manager sself at performair.com 463 South Hamilton Court Gilbert, Arizona 85233 Phone: (480) 610-3500 Fax: (480) 610-3501 www.performair.com -----Original Message----- From: SSelf at performair.com [mailto:SSelf at performair.com] Sent: Thursday, January 7, 2021 2:21 PM To: ceph-users at ceph.io; openstack-discuss at lists.openstack.org Subject: [ceph-users] [cinder] Cinder & Ceph Integration Error: No Valid Backend All; We're having problems with our Openstack/Ceph integration. The versions we're using are Ussuri & Nautilus. When trying to create a volume, the volume is created, though the status is stuck at 'ERROR'. This appears to be the most relevant line from the Cinder scheduler.log: 2021-01-07 14:00:38.473 140686 ERROR cinder.scheduler.flows.create_volume [req-f86556b5-cb2e-4b2d-b556-ed07e632289d 824c26c133b34d8b8e84a7acabbe6f91 a983323b5ffc47e18660794cd9344869 - default default] Failed to run task cinder.scheduler.flows.create_volume.ScheduleCreateVolumeTask;volume:create: No valid backend was found. No weighed backends available: cinder.exception.NoValidBackend: No valid backend was found. No weighed backends available Here is the 'cinder.conf' from our Controller Node: [DEFAULT] # define own IP address my_ip = 10.0.80.40 log_dir = /var/log/cinder state_path = /var/lib/cinder auth_strategy = keystone enabled_backends = ceph glance_api_version = 2 debug = true # RabbitMQ connection info transport_url = rabbit://openstack:@10.0.80.40:5672 enable_v3_api = True # MariaDB connection info [database] connection = mysql+pymysql://cinder:@10.0.80.40/cinder # Keystone auth info [keystone_authtoken] www_authenticate_uri = http://10.0.80.40:5000 auth_url = http://10.0.80.40:5000 memcached_servers = 10.0.80.40:11211 auth_type = password project_domain_name = default user_domain_name = default project_name = service username = cinder password = [oslo_concurrency] lock_path = $state_path/tmp [ceph] volume_driver = cinder.volume.drivers.rbd.RBDDriver volume_backend_name = ceph rbd_pool = rbd_os_volumes rbd_ceph_conf = /etc/ceph/463/ceph.conf rbd_flatten_volume_from_snapshot = false rbd_max_clone_depth = 5 rbd_store_chunk_size = 4 rados_connect_timeout = -1 rbd_user = cinder rbd_exclusive_cinder_pool = true backup_driver = cinder.backup.drivers.ceph backup_ceph_conf = /etc/ceph/300/ceph.conf backup_ceph_user = cinder-backup backup_ceph_chunk_size = 134217728 backup_ceph_pool = rbd_os_backups backup_ceph_stripe_unit = 0 backup_ceph_stripe_count = 0 restore_discard_excess_bytes = true Does anyone have any ideas as to what is going wrong? Thank you, Stephen Self IT Manager Perform Air International sself at performair.com www.performair.com _______________________________________________ ceph-users mailing list -- ceph-users at ceph.io To unsubscribe send an email to ceph-users-leave at ceph.io From anlin.kong at gmail.com Fri Jan 8 00:16:35 2021 From: anlin.kong at gmail.com (Lingxian Kong) Date: Fri, 8 Jan 2021 13:16:35 +1300 Subject: Cannot login to Built trovestack image In-Reply-To: References: Message-ID: Hi, Have you read https://docs.openstack.org/trove/latest/admin/building_guest_images.html? --- Lingxian Kong Senior Software Engineer Catalyst Cloud www.catalystcloud.nz On Fri, Jan 8, 2021 at 10:09 AM Ryan Price-King wrote: > Hi, > > Sorry I meant the instance is being deployed in nova correctly and > entering running state and console gives me login screen. > > Regards, > Ryan > > On Thu, 7 Jan 2021 at 17:14, Ryan Price-King > wrote: > >> Hi, >> >> I am having problems with the image being deployed correctly with nova, >> but the communication to the guestagent is timing out and i am stuck in >> build stage. >> >> ./trovestack build-image ubuntu bionic true ubuntu >> >> >> Also with that, I dont know which mysql version it is building. >> >> I am assuming it is 5.7.29. >> >> I cannot diagnose as i cannot login to the guest image instance. >> >> I assume the user is ubuntu, but i cannot login with any password that i >> have tried. >> >> Can you tell me what username/password to login to the instance by >> console in openstack please. >> >> Regards, >> Ryan >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From anlin.kong at gmail.com Fri Jan 8 02:25:32 2021 From: anlin.kong at gmail.com (Lingxian Kong) Date: Fri, 8 Jan 2021 15:25:32 +1300 Subject: Cannot login to Built trovestack image In-Reply-To: References: Message-ID: In this case, we need to check the trove-guestagent log. For how to ssh into the guest instance, https://docs.openstack.org/trove/latest/admin/troubleshooting.html You can also jump into #openstack-trove IRC channel we could have a chat there. --- Lingxian Kong Senior Software Engineer Catalyst Cloud www.catalystcloud.nz On Fri, Jan 8, 2021 at 1:34 PM Ryan Price-King wrote: > Hi, > > Sorry I should have clarified. The build step I am stuck on is while > spinning up the trove database on openstack horizon. I have built the qcow > image fine. Also, I can view the login prompt of the trove instance that > was created when creating a trove database. So it seems the agent is not > running in the instance properly. > > I have read that document lots and need to login to the image to see the > files and Ubuntu Ubuntu doesnt work. > > Regards, > Ryan > > On 8 Jan 2021 at 00:16, Lingxian Kong wrote: > > Hi, > > Have you read > https://docs.openstack.org/trove/latest/admin/building_guest_images.html? > > --- > Lingxian Kong > Senior Software Engineer > Catalyst Cloud > www.catalystcloud.nz > > > On Fri, Jan 8, 2021 at 10:09 AM Ryan Price-King > wrote: > >> Hi, >> >> Sorry I meant the instance is being deployed in nova correctly and >> entering running state and console gives me login screen. >> >> Regards, >> Ryan >> >> On Thu, 7 Jan 2021 at 17:14, Ryan Price-King >> wrote: >> >>> Hi, >>> >>> I am having problems with the image being deployed correctly with nova, >>> but the communication to the guestagent is timing out and i am stuck in >>> build stage. >>> >>> ./trovestack build-image ubuntu bionic true ubuntu >>> >>> >>> Also with that, I dont know which mysql version it is building. >>> >>> I am assuming it is 5.7.29. >>> >>> I cannot diagnose as i cannot login to the guest image instance. >>> >>> I assume the user is ubuntu, but i cannot login with any password that i >>> have tried. >>> >>> Can you tell me what username/password to login to the instance by >>> console in openstack please. >>> >>> Regards, >>> Ryan >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From rosmaita.fossdev at gmail.com Fri Jan 8 03:02:37 2021 From: rosmaita.fossdev at gmail.com (Brian Rosmaita) Date: Thu, 7 Jan 2021 22:02:37 -0500 Subject: [cinder] review priorities for the next 2 weeks Message-ID: <09e56f20-6961-e663-644e-4b72c4c3e19f@gmail.com> As discussed at yesterday's cinder weekly meeting, the new driver merge deadline will soon be upon us at the Wallaby-2 milestone in two weeks [0]. Thus, all members of the cinder community should make driver reviews the top priority over the next 2 weeks. There are four drivers proposed for Wallaby that haven't merged yet: 1 - Ceph ISCSI driver https://review.opendev.org/c/openstack/cinder/+/662829 2 - Dell/EMC PowerVault ME Series driver: https://review.opendev.org/c/openstack/cinder/+/758684/ 3 - TOYOU ACS5000 driver: https://review.opendev.org/c/openstack/cinder/+/767290/ 4 - Kioxia KumoScale NVMeoF volume driver: https://review.opendev.org/c/openstack/cinder/+/768574 nvmeof connector mdraid support: https://review.opendev.org/c/openstack/os-brick/+/768575 healing agent: https://review.opendev.org/c/openstack/os-brick/+/768576 Don't forget that the cinder docs contain a helpful checklist for reviewing drivers: https://docs.openstack.org/cinder/latest/contributor/new_driver_checklist.html If you are waiting for reviews of your driver, it will be helpful for you to review other drivers. You may notice something that you missed or could code differently in your driver, or you may be able to suggest changes based on issues you've come across implementing your driver. Happy reviewing! brian [0] https://releases.openstack.org/wallaby/schedule.html#w-cinder-driver-deadline From hberaud at redhat.com Fri Jan 8 08:26:47 2021 From: hberaud at redhat.com (Herve Beraud) Date: Fri, 8 Jan 2021 09:26:47 +0100 Subject: [Release-job-failures] Release of openstack/kolla for ref refs/tags/9.3.0 failed In-Reply-To: References: Message-ID: Hello, FYI it seems that kolla met docker's new limitation during its release jobs, especially with your publish jobs, I saw that you (the kolla team) already discussed this limitation [1] on the ML. ``` 2021-01-07 17:21:03.396355 | primary | ERROR:kolla.common.utils.base:Error'd with the following message 2021-01-07 17:21:03.396465 | primary | ERROR:kolla.common.utils.base:toomanyrequests: You have reached your pull rate limit. You may increase ``` Three jobs here failed for the same reason. I don't think that reenqueue the failing jobs without a specific action to manage this limitation will help us here. Let us know if we can help us in some manner. [1] http://lists.openstack.org/pipermail/openstack-discuss/2020-December/019148.html Le jeu. 7 janv. 2021 à 20:41, a écrit : > Build failed. > > - openstack-upload-github-mirror > https://zuul.opendev.org/t/openstack/build/a64b4c4bc398481f9afffa2ad465a012 > : SUCCESS in 1m 03s > - release-openstack-python > https://zuul.opendev.org/t/openstack/build/2ed64dfcbcaf483abf003cfdf4f25837 > : SUCCESS in 3m 11s > - announce-release > https://zuul.opendev.org/t/openstack/build/84d803d496a2485c983f6233dafcfd71 > : SUCCESS in 4m 07s > - propose-update-constraints > https://zuul.opendev.org/t/openstack/build/d0cac6a077054bc8ba9eb92e56c21799 > : SUCCESS in 4m 15s > - kolla-publish-centos-source > https://zuul.opendev.org/t/openstack/build/5e8f6aa2f56940a7be77a8dfe1c8ecc6 > : SUCCESS in 2h 20m 47s > - kolla-publish-centos-binary > https://zuul.opendev.org/t/openstack/build/8a8a021d9f9c4ca79755b06309710cc7 > : SUCCESS in 1h 56m 32s (non-voting) > - kolla-publish-centos8-source > https://zuul.opendev.org/t/openstack/build/fb6891d3f5e4493b880fce263a92e086 > : SUCCESS in 1h 50m 57s > - kolla-publish-centos8-binary > https://zuul.opendev.org/t/openstack/build/c312c05e5d084fdbb3f372755221f186 > : SUCCESS in 1h 13m 12s (non-voting) > - kolla-publish-debian-source > https://zuul.opendev.org/t/openstack/build/e24c12751b8c4aba881adb6c9ae8dc07 > : SUCCESS in 1h 27m 27s (non-voting) > - kolla-publish-debian-source-aarch64 > https://zuul.opendev.org/t/openstack/build/1ff3b02df53847d0aa54bf12ea7fa666 > : FAILURE in 1h 51m 49s (non-voting) > - kolla-publish-debian-binary > https://zuul.opendev.org/t/openstack/build/012c2de475fe45ea83f1cd8a7420aa6d > : SUCCESS in 1h 15m 15s (non-voting) > - kolla-publish-ubuntu-source > https://zuul.opendev.org/t/openstack/build/88ca21d972514cce954ecb586324fa29 > : FAILURE in 4m 14s > - kolla-publish-ubuntu-binary > https://zuul.opendev.org/t/openstack/build/f3d44e4d1b6c4e9799161b156290b238 > : FAILURE in 4m 19s (non-voting) > > _______________________________________________ > Release-job-failures mailing list > Release-job-failures at lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/release-job-failures > -- Hervé Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/ https://twitter.com/4383hberaud -----BEGIN PGP SIGNATURE----- wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O v6rDpkeNksZ9fFSyoY2o =ECSj -----END PGP SIGNATURE----- -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark at stackhpc.com Fri Jan 8 08:45:02 2021 From: mark at stackhpc.com (Mark Goddard) Date: Fri, 8 Jan 2021 08:45:02 +0000 Subject: [Release-job-failures] Release of openstack/kolla for ref refs/tags/9.3.0 failed In-Reply-To: References: Message-ID: Hi Herve, Thanks for noticing this. The pull rate limit refreshes every 6 hours, is specific to the IP used by the job, and in the case of the build/publish jobs we only require pulling a single image - the base OS image - per job. I suggest we reenqueue the failing jobs. For build/publish jobs we have discussed using the infra Docker registry mirrors, which should avoid hitting Dockerhub too often. Cheers, Mark On Fri, 8 Jan 2021 at 08:28, Herve Beraud wrote: > Hello, > > FYI it seems that kolla met docker's new limitation during its release > jobs, especially with your publish jobs, I saw that you (the kolla team) > already discussed this limitation [1] on the ML. > > ``` > > 2021-01-07 17:21:03.396355 | primary | ERROR:kolla.common.utils.base:Error'd with the following message > > 2021-01-07 17:21:03.396465 | primary | ERROR:kolla.common.utils.base:toomanyrequests: You have reached your pull rate limit. You may increase > ``` > > Three jobs here failed for the same reason. > > I don't think that reenqueue the failing jobs without a specific action to manage this limitation will help us here. > > Let us know if we can help us in some manner. > > > [1] http://lists.openstack.org/pipermail/openstack-discuss/2020-December/019148.html > > > Le jeu. 7 janv. 2021 à 20:41, a écrit : > >> Build failed. >> >> - openstack-upload-github-mirror >> https://zuul.opendev.org/t/openstack/build/a64b4c4bc398481f9afffa2ad465a012 >> : SUCCESS in 1m 03s >> - release-openstack-python >> https://zuul.opendev.org/t/openstack/build/2ed64dfcbcaf483abf003cfdf4f25837 >> : SUCCESS in 3m 11s >> - announce-release >> https://zuul.opendev.org/t/openstack/build/84d803d496a2485c983f6233dafcfd71 >> : SUCCESS in 4m 07s >> - propose-update-constraints >> https://zuul.opendev.org/t/openstack/build/d0cac6a077054bc8ba9eb92e56c21799 >> : SUCCESS in 4m 15s >> - kolla-publish-centos-source >> https://zuul.opendev.org/t/openstack/build/5e8f6aa2f56940a7be77a8dfe1c8ecc6 >> : SUCCESS in 2h 20m 47s >> - kolla-publish-centos-binary >> https://zuul.opendev.org/t/openstack/build/8a8a021d9f9c4ca79755b06309710cc7 >> : SUCCESS in 1h 56m 32s (non-voting) >> - kolla-publish-centos8-source >> https://zuul.opendev.org/t/openstack/build/fb6891d3f5e4493b880fce263a92e086 >> : SUCCESS in 1h 50m 57s >> - kolla-publish-centos8-binary >> https://zuul.opendev.org/t/openstack/build/c312c05e5d084fdbb3f372755221f186 >> : SUCCESS in 1h 13m 12s (non-voting) >> - kolla-publish-debian-source >> https://zuul.opendev.org/t/openstack/build/e24c12751b8c4aba881adb6c9ae8dc07 >> : SUCCESS in 1h 27m 27s (non-voting) >> - kolla-publish-debian-source-aarch64 >> https://zuul.opendev.org/t/openstack/build/1ff3b02df53847d0aa54bf12ea7fa666 >> : FAILURE in 1h 51m 49s (non-voting) >> - kolla-publish-debian-binary >> https://zuul.opendev.org/t/openstack/build/012c2de475fe45ea83f1cd8a7420aa6d >> : SUCCESS in 1h 15m 15s (non-voting) >> - kolla-publish-ubuntu-source >> https://zuul.opendev.org/t/openstack/build/88ca21d972514cce954ecb586324fa29 >> : FAILURE in 4m 14s >> - kolla-publish-ubuntu-binary >> https://zuul.opendev.org/t/openstack/build/f3d44e4d1b6c4e9799161b156290b238 >> : FAILURE in 4m 19s (non-voting) >> >> _______________________________________________ >> Release-job-failures mailing list >> Release-job-failures at lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/release-job-failures >> > > > -- > Hervé Beraud > Senior Software Engineer at Red Hat > irc: hberaud > https://github.com/4383/ > https://twitter.com/4383hberaud > -----BEGIN PGP SIGNATURE----- > > wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ > Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ > RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP > F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G > 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g > glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw > m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ > hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 > qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y > F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 > B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O > v6rDpkeNksZ9fFSyoY2o > =ECSj > -----END PGP SIGNATURE----- > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hberaud at redhat.com Fri Jan 8 09:40:43 2021 From: hberaud at redhat.com (Herve Beraud) Date: Fri, 8 Jan 2021 10:40:43 +0100 Subject: [cinder][tripleo][release] Victoria Cycle-Trailing Release Deadline Message-ID: Hello teams with trailing projects, Next week is the Victoria cycle-trailing release deadline [1], and all projects following the cycle-trailing release model must release their Victoria deliverables by 14 January, 2021. The following trailing projects haven't been yet released for Victoria. Cinder: - cinderlib Tripleo: - os-collect-config - os-refresh-config - tripleo-ipsec This is just a friendly reminder to allow you to release these projects in time. Do not hesitate to ping us if you have any questions or concerns. [1] https://releases.openstack.org/wallaby/schedule.html#w-cycle-trail Hervé Beraud (hberaud) and the Release Management Team -- Hervé Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/ https://twitter.com/4383hberaud -----BEGIN PGP SIGNATURE----- wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O v6rDpkeNksZ9fFSyoY2o =ECSj -----END PGP SIGNATURE----- -------------- next part -------------- An HTML attachment was scrubbed... URL: From hberaud at redhat.com Fri Jan 8 09:58:44 2021 From: hberaud at redhat.com (Herve Beraud) Date: Fri, 8 Jan 2021 10:58:44 +0100 Subject: [cinder][tripleo][release] Victoria Cycle-Trailing Release Deadline In-Reply-To: References: Message-ID: @Cinder: In my previous email I missed this patch ( https://review.opendev.org/c/openstack/releases/+/768766) , so sorry, please ignore my previous communication. Le ven. 8 janv. 2021 à 10:40, Herve Beraud a écrit : > Hello teams with trailing projects, > > Next week is the Victoria cycle-trailing release deadline [1], and all > projects following the cycle-trailing release model must release their > Victoria deliverables by 14 January, 2021. > > The following trailing projects haven't been yet released for Victoria. > > Cinder: > - cinderlib > > Tripleo: > - os-collect-config > - os-refresh-config > - tripleo-ipsec > > This is just a friendly reminder to allow you to release these projects in > time. > > Do not hesitate to ping us if you have any questions or concerns. > > [1] https://releases.openstack.org/wallaby/schedule.html#w-cycle-trail > > Hervé Beraud (hberaud) and the Release Management Team > > -- > Hervé Beraud > Senior Software Engineer at Red Hat > irc: hberaud > https://github.com/4383/ > https://twitter.com/4383hberaud > -----BEGIN PGP SIGNATURE----- > > wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ > Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ > RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP > F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G > 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g > glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw > m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ > hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 > qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y > F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 > B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O > v6rDpkeNksZ9fFSyoY2o > =ECSj > -----END PGP SIGNATURE----- > > -- Hervé Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/ https://twitter.com/4383hberaud -----BEGIN PGP SIGNATURE----- wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O v6rDpkeNksZ9fFSyoY2o =ECSj -----END PGP SIGNATURE----- -------------- next part -------------- An HTML attachment was scrubbed... URL: From marios at redhat.com Fri Jan 8 11:08:04 2021 From: marios at redhat.com (Marios Andreou) Date: Fri, 8 Jan 2021 13:08:04 +0200 Subject: [cinder][tripleo][release] Victoria Cycle-Trailing Release Deadline In-Reply-To: References: Message-ID: On Fri, Jan 8, 2021 at 11:42 AM Herve Beraud wrote: > Hello teams with trailing projects, > > Next week is the Victoria cycle-trailing release deadline [1], and all > projects following the cycle-trailing release model must release their > Victoria deliverables by 14 January, 2021. > > The following trailing projects haven't been yet released for Victoria. > > Cinder: > - cinderlib > > Tripleo: > - os-collect-config > - os-refresh-config > - tripleo-ipsec > > This is just a friendly reminder to allow you to release these projects in > time. > > many thanks for the reminder I will look into this regards > Do not hesitate to ping us if you have any questions or concerns. > > [1] https://releases.openstack.org/wallaby/schedule.html#w-cycle-trail > > Hervé Beraud (hberaud) and the Release Management Team > > -- > Hervé Beraud > Senior Software Engineer at Red Hat > irc: hberaud > https://github.com/4383/ > https://twitter.com/4383hberaud > -----BEGIN PGP SIGNATURE----- > > wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ > Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ > RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP > F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G > 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g > glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw > m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ > hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 > qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y > F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 > B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O > v6rDpkeNksZ9fFSyoY2o > =ECSj > -----END PGP SIGNATURE----- > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From balazs.gibizer at est.tech Fri Jan 8 12:58:53 2021 From: balazs.gibizer at est.tech (Balazs Gibizer) Date: Fri, 08 Jan 2021 13:58:53 +0100 Subject: [nova] unit testing on ppc64le Message-ID: <5E9MMQ.3INH7FY465VR3@est.tech> Hi, We have a bugreport[1] showing that our unit tests are not passing on ppc. In the upstream CI we don't have test capability to run our tests on ppc. But we have the IBM Power KVM CI[2] that runs integration tests on ppc. I'm wondering if IBM could extend the CI to run nova unit and functional tests too. I've added Michael Turek (mjturek at us.ibm.com) to CC. Michael is listed as the contact person for the CI. Cheers, gibi [1]https://bugs.launchpad.net/nova/+bug/1909972 [2]https://wiki.openstack.org/wiki/ThirdPartySystems/IBMPowerKVMCI From C-Albert.Braden at charter.com Fri Jan 8 13:02:04 2021 From: C-Albert.Braden at charter.com (Braden, Albert) Date: Fri, 8 Jan 2021 13:02:04 +0000 Subject: [kolla] [train] Changing default quotas Message-ID: <3c8f6754aeb14df38ed059c0b6eb47f8@NCEMEXGP009.CORP.CHARTERCOM.com> I'm trying to change default quotas on a Train kolla POC, and I can change compute, but when I try to change a network quota such as subnets I get an error: (openstack) [root at adjutant-poc openstack]# openstack quota set --class --subnets 2 default Network quotas are ignored since quota class is not supported. When I google around I find some old documents talking about setting neutron quotas in /etc/neutron/neutron.conf but I can't find anything recent, and I don't see any mention of quotas when I look at /etc/neutron/neutron.conf in our neutron_server containers. What is the best way to change neutron default quotas in kolla? I apologize for the nonsense below. So far I have not been able to stop it from being attached to my external emails. I'm working on it. E-MAIL CONFIDENTIALITY NOTICE: The contents of this e-mail message and any attachments are intended solely for the addressee(s) and may contain confidential and/or legally privileged information. If you are not the intended recipient of this message or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message and any attachments. If you are not the intended recipient, you are notified that any use, dissemination, distribution, copying, or storage of this message or any attachment is strictly prohibited. -------------- next part -------------- An HTML attachment was scrubbed... URL: From lyarwood at redhat.com Fri Jan 8 13:05:31 2021 From: lyarwood at redhat.com (Lee Yarwood) Date: Fri, 8 Jan 2021 13:05:31 +0000 Subject: [nova] Nova evacuate issue In-Reply-To: References: <20210107142638.3u2duxgdsrj5fe5y@lyarwood-laptop.usersys.redhat.com> Message-ID: <20210108130531.3p7u6qb24o47wdcp@lyarwood-laptop.usersys.redhat.com> On 07-01-21 11:58:05, Jean-Philippe Méthot wrote: > Considering that this issue happened in our production environment, > it’s not exactly possible to try to reproduce without shutting down > servers that are currently in use. That said, If the current logs I > have are enough, I will try opening a bug on the bugtracker. Yup appreciate that, if you still have logs then using the event list to determine the request-id for the evacuation and then providing any n-api/n-cpu logs referencing that request-id in the bug would be great. Lots more detail in the following doc: https://docs.openstack.org/api-guide/compute/faults.html > Compute22, the source host, was completely dead. It refused to boot up > through IPMI. ACK. > It is possible that that stein fix prevented me from reproducing the > problem in my staging environment (production is on rocky, staging is > on stein). > > Also, it may be important to note that our neutron is split, as we use > neutron-rpc-server to answer rpc calls. It’s also HA, as we have two > controllers with neutron-rpc-server and the api running (and that > won’t work anymore when we upgrade production to stein, but that’s > another problem entirely and probably off-topic here). I doubt that played a part, we've fixed many many bugs with Nova's evacuation logic over the releases so for now I'm going to assume it's something within Nova. > > Le 7 janv. 2021 à 09:26, Lee Yarwood a écrit : > > > > Would you be able to trace an example evacuation request fully and > > pastebin it somewhere using `openstack server event list $instance [1]` > > output to determine the request-id etc? Feel free to also open a bug > > about this and we can just triage there instead of the ML. > > > > The fact that q-api has sent the > > network-vif-plugged:80371c01-930d-4ea2-9d28-14438e948b65 to n-api > > suggests that the q-agt is actually alive on compute22, was that the > > case? Note that a pre-condition of calling the evacuation API is that > > the source host has been fenced [2]. > > > > That all said I wonder if this is somehow related too the following > > stein change: > > > > https://review.opendev.org/c/openstack/nova/+/603844 -- Lee Yarwood A5D1 9385 88CB 7E5F BE64 6618 BCA6 6E33 F672 2D76 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: not available URL: From hberaud at redhat.com Fri Jan 8 13:42:14 2021 From: hberaud at redhat.com (Herve Beraud) Date: Fri, 8 Jan 2021 14:42:14 +0100 Subject: [Release-job-failures] Release of openstack/kolla for ref refs/tags/9.3.0 failed In-Reply-To: References: Message-ID: Also notice that yesterday we met an AFS issue [1] during the merge of the following patches: - https://review.opendev.org/c/openstack/releases/+/769325 - https://review.opendev.org/c/openstack/releases/+/769322 - https://review.opendev.org/c/openstack/releases/+/769324 The problem was that afs an server got stuck in a pathological way from 05:50 utc today until 16:10 utc when we hard rebooted the server instance. The consequence of this is that the related tarballs haven't been published: - https://tarballs.opendev.org/openstack/kolla/?C=M;O=D - https://tarballs.opendev.org/openstack/kolla-ansible/?C=M;O=D - https://tarballs.opendev.org/openstack/kayobe/?C=M;O=D And so the RDO CI fail to build them for train, ussuri and victoria: - https://review.rdoproject.org/r/#/c/31499/ - https://review.rdoproject.org/r/#/c/31498/ - https://review.rdoproject.org/r/#/c/31497/ So I think we need to reenqueue these jobs too. Thanks for reading [1] http://eavesdrop.openstack.org/irclogs/%23openstack-release/%23openstack-release.2021-01-07.log.html#t2021-01-07T16:48:57 Le ven. 8 janv. 2021 à 09:45, Mark Goddard a écrit : > Hi Herve, > > Thanks for noticing this. The pull rate limit refreshes every 6 hours, is > specific to the IP used by the job, and in the case of the build/publish > jobs we only require pulling a single image - the base OS image - per job. > I suggest we reenqueue the failing jobs. > > For build/publish jobs we have discussed using the infra Docker registry > mirrors, which should avoid hitting Dockerhub too often. > > Cheers, > Mark > > On Fri, 8 Jan 2021 at 08:28, Herve Beraud wrote: > >> Hello, >> >> FYI it seems that kolla met docker's new limitation during its release >> jobs, especially with your publish jobs, I saw that you (the kolla team) >> already discussed this limitation [1] on the ML. >> >> ``` >> >> 2021-01-07 17:21:03.396355 | primary | ERROR:kolla.common.utils.base:Error'd with the following message >> >> 2021-01-07 17:21:03.396465 | primary | ERROR:kolla.common.utils.base:toomanyrequests: You have reached your pull rate limit. You may increase >> ``` >> >> Three jobs here failed for the same reason. >> >> I don't think that reenqueue the failing jobs without a specific action to manage this limitation will help us here. >> >> Let us know if we can help us in some manner. >> >> >> [1] http://lists.openstack.org/pipermail/openstack-discuss/2020-December/019148.html >> >> >> Le jeu. 7 janv. 2021 à 20:41, a écrit : >> >>> Build failed. >>> >>> - openstack-upload-github-mirror >>> https://zuul.opendev.org/t/openstack/build/a64b4c4bc398481f9afffa2ad465a012 >>> : SUCCESS in 1m 03s >>> - release-openstack-python >>> https://zuul.opendev.org/t/openstack/build/2ed64dfcbcaf483abf003cfdf4f25837 >>> : SUCCESS in 3m 11s >>> - announce-release >>> https://zuul.opendev.org/t/openstack/build/84d803d496a2485c983f6233dafcfd71 >>> : SUCCESS in 4m 07s >>> - propose-update-constraints >>> https://zuul.opendev.org/t/openstack/build/d0cac6a077054bc8ba9eb92e56c21799 >>> : SUCCESS in 4m 15s >>> - kolla-publish-centos-source >>> https://zuul.opendev.org/t/openstack/build/5e8f6aa2f56940a7be77a8dfe1c8ecc6 >>> : SUCCESS in 2h 20m 47s >>> - kolla-publish-centos-binary >>> https://zuul.opendev.org/t/openstack/build/8a8a021d9f9c4ca79755b06309710cc7 >>> : SUCCESS in 1h 56m 32s (non-voting) >>> - kolla-publish-centos8-source >>> https://zuul.opendev.org/t/openstack/build/fb6891d3f5e4493b880fce263a92e086 >>> : SUCCESS in 1h 50m 57s >>> - kolla-publish-centos8-binary >>> https://zuul.opendev.org/t/openstack/build/c312c05e5d084fdbb3f372755221f186 >>> : SUCCESS in 1h 13m 12s (non-voting) >>> - kolla-publish-debian-source >>> https://zuul.opendev.org/t/openstack/build/e24c12751b8c4aba881adb6c9ae8dc07 >>> : SUCCESS in 1h 27m 27s (non-voting) >>> - kolla-publish-debian-source-aarch64 >>> https://zuul.opendev.org/t/openstack/build/1ff3b02df53847d0aa54bf12ea7fa666 >>> : FAILURE in 1h 51m 49s (non-voting) >>> - kolla-publish-debian-binary >>> https://zuul.opendev.org/t/openstack/build/012c2de475fe45ea83f1cd8a7420aa6d >>> : SUCCESS in 1h 15m 15s (non-voting) >>> - kolla-publish-ubuntu-source >>> https://zuul.opendev.org/t/openstack/build/88ca21d972514cce954ecb586324fa29 >>> : FAILURE in 4m 14s >>> - kolla-publish-ubuntu-binary >>> https://zuul.opendev.org/t/openstack/build/f3d44e4d1b6c4e9799161b156290b238 >>> : FAILURE in 4m 19s (non-voting) >>> >>> _______________________________________________ >>> Release-job-failures mailing list >>> Release-job-failures at lists.openstack.org >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/release-job-failures >>> >> >> >> -- >> Hervé Beraud >> Senior Software Engineer at Red Hat >> irc: hberaud >> https://github.com/4383/ >> https://twitter.com/4383hberaud >> -----BEGIN PGP SIGNATURE----- >> >> wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ >> Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ >> RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP >> F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G >> 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g >> glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw >> m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ >> hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 >> qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y >> F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 >> B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O >> v6rDpkeNksZ9fFSyoY2o >> =ECSj >> -----END PGP SIGNATURE----- >> >> -- Hervé Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/ https://twitter.com/4383hberaud -----BEGIN PGP SIGNATURE----- wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O v6rDpkeNksZ9fFSyoY2o =ECSj -----END PGP SIGNATURE----- -------------- next part -------------- An HTML attachment was scrubbed... URL: From marios at redhat.com Fri Jan 8 14:02:10 2021 From: marios at redhat.com (Marios Andreou) Date: Fri, 8 Jan 2021 16:02:10 +0200 Subject: [cinder][tripleo][release] Victoria Cycle-Trailing Release Deadline In-Reply-To: References: Message-ID: On Fri, Jan 8, 2021 at 1:08 PM Marios Andreou wrote: > > > On Fri, Jan 8, 2021 at 11:42 AM Herve Beraud wrote: > >> Hello teams with trailing projects, >> >> Next week is the Victoria cycle-trailing release deadline [1], and all >> projects following the cycle-trailing release model must release their >> Victoria deliverables by 14 January, 2021. >> >> The following trailing projects haven't been yet released for Victoria. >> >> Cinder: >> - cinderlib >> >> Tripleo: >> - os-collect-config >> - os-refresh-config >> - tripleo-ipsec >> >> This is just a friendly reminder to allow you to release these projects >> in time. >> >> > many thanks for the reminder I will look into this > > regards > > there is discussion between me and Herve at https://review.opendev.org/c/openstack/releases/+/769915 if you are interested in this topic thanks, marios > > >> Do not hesitate to ping us if you have any questions or concerns. >> >> [1] https://releases.openstack.org/wallaby/schedule.html#w-cycle-trail >> >> Hervé Beraud (hberaud) and the Release Management Team >> >> -- >> Hervé Beraud >> Senior Software Engineer at Red Hat >> irc: hberaud >> https://github.com/4383/ >> https://twitter.com/4383hberaud >> -----BEGIN PGP SIGNATURE----- >> >> wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ >> Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ >> RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP >> F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G >> 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g >> glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw >> m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ >> hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 >> qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y >> F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 >> B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O >> v6rDpkeNksZ9fFSyoY2o >> =ECSj >> -----END PGP SIGNATURE----- >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From rosmaita.fossdev at gmail.com Fri Jan 8 15:21:51 2021 From: rosmaita.fossdev at gmail.com (Brian Rosmaita) Date: Fri, 8 Jan 2021 10:21:51 -0500 Subject: [all][tc] Dropping lower-constraints testing from all projects In-Reply-To: <176d8da769b.b6edb13b874337.4809906168220534198@ghanshyammann.com> References: <176d8da769b.b6edb13b874337.4809906168220534198@ghanshyammann.com> Message-ID: On 1/6/21 12:59 PM, Ghanshyam Mann wrote: > Hello Everyone, > > You might have seen the discussion around dropping the lower constraints > testing as it becomes more challenging than the current value of doing it. I think the TC needs to discuss this explicitly (at a meeting or two, not just on the ML) and give the projects some guidance. I agree that there's little point in maintaining the l-c if they're not actually useful to anyone in their current state, but if their helpfulness (or potential helpfulness) outweighs the maintenance burden, then we should keep them. (How's that for a profound statement?) Maybe someone can point me to where I can RTFM to get a clearer picture, but my admittedly vague idea of what the l-c are for is that it has something to do with making packaging easier. If that's the case, it would be good for the TC to reach out to some openstack packagers/distributors to find outline how they use l-c (if at all) and what changes could be done to make them actually useful, and then we can re-assess the maintenance burden. This whole experience with the new pip resolver has been painful, I think, because it hit all projects and all branches at once. My experience, however, is that if I'd been updating the minimum versions for all the cinder deliverables in their requirements.txt and l-c.txt files every cycle to reflect a pip freeze at Milestone-3 it would have been a lot easier. What do other projects do about this? In Cinder, we've just been updating the requirements on-demand, not proactively, and as a result for some dependencies we claimed that foo>=0.9.0 is OK -- but except for unit tests in the l-c job, cinder deliverables haven't been using anything other than foo>=16.0 since rocky. So in master, I took advantage of having to revise requirements and l-c to make some major jumps in minimum versions. And I'm thinking of doing a pip-freeze requirements.txt minimum version update from now on at M-3 each cycle, which will force me to make an l-c.txt update too. (Maybe I was supposed to be doing that all along? Or maybe it's a bad idea? I could use some guidance here.) It would be good for the l-c to reflect reality, but on the other hand, updating the minimum versions in requirements.txt (and hence in l-c) too aggressively probably won't help packagers at all. (Or maybe it will, I don't know.) On the other hand, having the l-c is useful from the standpoint of letting you know when your minimum acceptable version in requirements.txt will break your unit tests. But if we're updating the minimum versions of dependencies every cycle to known good minimum versions, an l-c failure is going to be pretty rare, so maybe it's not worth the trouble of maintaining the l-c.txt and CI job. One other thing: if we do keep l-c, we need to have some guidance about what's actually supposed to be in there. (Or I need to RTFM.) I've noticed that as we've added new dependencies to cinder, we've included the dependency in l-c.txt, but not its indirect dependencies. I guess we should have been adding the indirect dependencies all along, too? (Spoiler alert: we haven't.) This email has gotten too long, so I will shut up now. cheers, brian > > Few of the ML thread around this discussion: > > - http://lists.openstack.org/pipermail/openstack-discuss/2020-December/019521.html > - http://lists.openstack.org/pipermail/openstack-discuss/2020-December/019390.html > > As Oslo and many other project dropping or already dropped it, we should decide it for all > other projects also otherwise it can be more changing than it is currently. > > We have not defined it in PTI or testing runtime so it is always up to projects if they still > want to keep it but we should decide a general recommendation here. > > -gmann > From pierre at stackhpc.com Fri Jan 8 15:29:21 2021 From: pierre at stackhpc.com (Pierre Riteau) Date: Fri, 8 Jan 2021 16:29:21 +0100 Subject: [kolla] [train] Changing default quotas In-Reply-To: <3c8f6754aeb14df38ed059c0b6eb47f8@NCEMEXGP009.CORP.CHARTERCOM.com> References: <3c8f6754aeb14df38ed059c0b6eb47f8@NCEMEXGP009.CORP.CHARTERCOM.com> Message-ID: Hi Albert, You can change your default Neutron quotas via neutron.conf. This is described in the latest Neutron documentation: https://docs.openstack.org/neutron/latest/admin/ops-quotas.html#basic-quota-configuration Kolla-Ansible doesn't provide a full configuration file for OpenStack services. Instead, it includes specific options that are changed from defaults. Create a /etc/kolla/config/neutron.conf file with your own [quotas] settings, which will be merged into the default configuration templated by Kolla-Ansible. For more details see https://docs.openstack.org/kolla-ansible/latest/admin/advanced-configuration.html#openstack-service-configuration-in-kolla Best wishes, Pierre On Fri, 8 Jan 2021 at 14:05, Braden, Albert wrote: > > I’m trying to change default quotas on a Train kolla POC, and I can change compute, but when I try to change a network quota such as subnets I get an error: > > > > (openstack) [root at adjutant-poc openstack]# openstack quota set --class --subnets 2 default > > Network quotas are ignored since quota class is not supported. > > > > When I google around I find some old documents talking about setting neutron quotas in /etc/neutron/neutron.conf but I can’t find anything recent, and I don’t see any mention of quotas when I look at /etc/neutron/neutron.conf in our neutron_server containers. What is the best way to change neutron default quotas in kolla? > > > > I apologize for the nonsense below. So far I have not been able to stop it from being attached to my external emails. I'm working on it. > > > > The contents of this e-mail message and > any attachments are intended solely for the > addressee(s) and may contain confidential > and/or legally privileged information. If you > are not the intended recipient of this message > or if this message has been addressed to you > in error, please immediately alert the sender > by reply e-mail and then delete this message > and any attachments. If you are not the > intended recipient, you are notified that > any use, dissemination, distribution, copying, > or storage of this message or any attachment > is strictly prohibited. From arne.wiebalck at cern.ch Fri Jan 8 15:39:59 2021 From: arne.wiebalck at cern.ch (Arne Wiebalck) Date: Fri, 8 Jan 2021 16:39:59 +0100 Subject: [baremetal-sig][ironic] Tue Jan 12, 2021, 2pm UTC: 'Multi-Tenancy in Ironic: Of Owners and Lessees' Message-ID: Dear all, Happy new year! The Bare Metal SIG will continue its monthly meetings and start again on Tue Jan 12, 2021, at 2pm UTC. This time there will be a 10 minute "topic-of-the-day" presentation by Tzu-Mainn Chen (tzumainn) on 'Multi-Tenancy in Ironic: Of Owners and Lessees' So, if you would like to learn how this relatively recent addition to Ironic works, you can find all the details for this meeting on the SIG's etherpad: https://etherpad.opendev.org/p/bare-metal-sig Everyone is welcome, don't miss out! Cheers, Arne From juliaashleykreger at gmail.com Fri Jan 8 16:01:32 2021 From: juliaashleykreger at gmail.com (Julia Kreger) Date: Fri, 8 Jan 2021 08:01:32 -0800 Subject: [ironic] Resuming meetings next week Message-ID: Greetings everyone, Now that the Holidays are over, it is time for us to resume meeting on a regular basis. Ironic will resume it's weekly meeting next Monday at 1500 UTC in #openstack-ironic on irc.freenode.net. The agenda can be found on the OpenStack wiki[0]. See you all there! -Julia [0]: https://wiki.openstack.org/wiki/Meetings/Ironic#Agenda_for_next_meeting From ryan at messagecloud.com Fri Jan 8 00:34:58 2021 From: ryan at messagecloud.com (Ryan Price-King) Date: Thu, 7 Jan 2021 16:34:58 -0800 Subject: Cannot login to Built trovestack image In-Reply-To: References: Message-ID: Hi, Sorry I should have clarified. The build step I am stuck on is while spinning up the trove database on openstack horizon. I have built the qcow image fine. Also, I can view the login prompt of the trove instance that was created when creating a trove database. So it seems the agent is not running in the instance properly. I have read that document lots and need to login to the image to see the files and Ubuntu Ubuntu doesnt work. Regards, Ryan On 8 Jan 2021 at 00:16, Lingxian Kong wrote: Hi, Have you read https://docs.openstack.org/trove/latest/admin/building_guest_images.html? --- Lingxian Kong Senior Software Engineer Catalyst Cloud www.catalystcloud.nz On Fri, Jan 8, 2021 at 10:09 AM Ryan Price-King wrote: > Hi, > > Sorry I meant the instance is being deployed in nova correctly and > entering running state and console gives me login screen. > > Regards, > Ryan > > On Thu, 7 Jan 2021 at 17:14, Ryan Price-King > wrote: > >> Hi, >> >> I am having problems with the image being deployed correctly with nova, >> but the communication to the guestagent is timing out and i am stuck in >> build stage. >> >> ./trovestack build-image ubuntu bionic true ubuntu >> >> >> Also with that, I dont know which mysql version it is building. >> >> I am assuming it is 5.7.29. >> >> I cannot diagnose as i cannot login to the guest image instance. >> >> I assume the user is ubuntu, but i cannot login with any password that i >> have tried. >> >> Can you tell me what username/password to login to the instance by >> console in openstack please. >> >> Regards, >> Ryan >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ankelezhang at gmail.com Fri Jan 8 06:17:45 2021 From: ankelezhang at gmail.com (Ankele zhang) Date: Fri, 8 Jan 2021 14:17:45 +0800 Subject: how to read ipa source code#ironic-python-agent Message-ID: Hi~ I have an OpenStack platform on Rocky, and I used Nova/Keystone/Cinder/Glance/Ceph/Ironic. Recently, I have build my own ironic-python-agent deployment ramdisk and kernel images by ironic-python-agent-builder, the following work is to add my customized raid configuration method to HardwareManager. Before this, I want to read the ipa's source code. But I don't know where is the 'main()' entry. Looking forward to your help. Ankele -------------- next part -------------- An HTML attachment was scrubbed... URL: From D.R.MacDonald at salford.ac.uk Fri Jan 8 14:57:09 2021 From: D.R.MacDonald at salford.ac.uk (Daniel Macdonald) Date: Fri, 8 Jan 2021 14:57:09 +0000 Subject: [octavia] problems configuring octavia Message-ID: Happy new year Openstack users and devs! I have been trying on and off for several months to get octavia working but I have yet to have it successfully create a loadbalancer. I have deployed OS bionic-train using the Charms telemetry bundle with the octavia overlay. Openstack is working for creating regular instances but I get various errors when trying to create a loadbalancer. The first issue I feel I should mention is that I am using bind running on our MAAS controller as a DNS server. juju doesn't work if I enable IPv6 under bind yet the octavia charm defaults to using IPv6 for its management network so I have tried creating a IPv4 management network but I'm still having problems. For more details on that please see the comments of this bug report: https://bugs.launchpad.net/charm-octavia/+bug/1897418 Bug #1897418 “feature request: have option to use ipv4 when sett...” : Bugs : OpenStack Octavia Charm By default, Octavia charm uses ipv6 for its lb-mgmt-subnet.[1] It would be nice to have the option to choose an ipv4 network from the start instead of deleting the ipv6 network and recreating the ipv4 subnet. Implementation - possible configuration option parameter when deploying. [1] https://opendev.org/openstack/charm-octavia/src/branch/master/src/lib/charm/openstack/api_crud.py#L560 bugs.launchpad.net Another notable issue I have is that after installing the charms telemetry bundle I have 2 projects call services. How do I know which is the correct one to use for Octavia? Is this following document going to be the best guide for me to follow to complete the final steps required to get Octavia (under Train) working: https://docs.openstack.org/octavia/latest/install/install-ubuntu.html#install-and-configure-components OpenStack Docs: Install and configure for Ubuntu Install and configure for Ubuntu¶. This section describes how to install and configure the Load-balancer service for Ubuntu 18.04 (LTS). docs.openstack.org I'm hoping someone has already written an easy to follow guide to using Octavia with an IPv4 management network using the Charms bundle to do most of the installation work? Thanks [University of Salford] DANIEL MACDONALD Specialist Technical Demonstrator School of Computing, Science & Engineering Room 145, Newton Building, University of Salford, Manchester M5 4WT T: +44(0) 0161 295 5242 D.R.MacDonald at salford.ac.uk / www.salford.ac.uk [CSE] -------------- next part -------------- An HTML attachment was scrubbed... URL: From fungi at yuggoth.org Fri Jan 8 16:22:32 2021 From: fungi at yuggoth.org (Jeremy Stanley) Date: Fri, 8 Jan 2021 16:22:32 +0000 Subject: [dev][ironic] how to read ipa source code#ironic-python-agent In-Reply-To: References: Message-ID: <20210108162231.wi3u7cqguv3euyqd@yuggoth.org> [Keeping you in Cc since you don't seem to be subscribed to this ML] On 2021-01-08 14:17:45 +0800 (+0800), Ankele zhang wrote: > I have an OpenStack platform on Rocky, and I used > Nova/Keystone/Cinder/Glance/Ceph/Ironic. Recently, I have build my > own ironic-python-agent deployment ramdisk and kernel images by > ironic-python-agent-builder, the following work is to add my > customized raid configuration method to HardwareManager. Before > this, I want to read the ipa's source code. But I don't know where > is the 'main()' entry. Looking forward to your help. You specifically want the stable/rocky version? The ironic-python-agent console script entrypoint (according to the setup.cfg at the top of that repository) calls the run() function from this file: https://opendev.org/openstack/ironic-python-agent/src/branch/stable/rocky/ironic_python_agent/cmd/agent.py Hope that helps! -- Jeremy Stanley -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From fungi at yuggoth.org Fri Jan 8 16:28:24 2021 From: fungi at yuggoth.org (Jeremy Stanley) Date: Fri, 8 Jan 2021 16:28:24 +0000 Subject: [Release-job-failures] Release of openstack/kolla for ref refs/tags/9.3.0 failed In-Reply-To: References: Message-ID: <20210108162824.fb7bszb33ncrnaiz@yuggoth.org> On 2021-01-08 14:42:14 +0100 (+0100), Herve Beraud wrote: > Also notice that yesterday we met an AFS issue [1] during the merge of the > following patches: > > - https://review.opendev.org/c/openstack/releases/+/769325 > - https://review.opendev.org/c/openstack/releases/+/769322 > - https://review.opendev.org/c/openstack/releases/+/769324 > > The problem was that afs an server got stuck in a pathological way from > 05:50 utc today until 16:10 utc when we hard rebooted the server instance. The patches you reference merged later, so wasn't directly impacted by write failures (the jobs actually succeeded). > The consequence of this is that the related tarballs haven't been published: > > - https://tarballs.opendev.org/openstack/kolla/?C=M;O=D > - https://tarballs.opendev.org/openstack/kolla-ansible/?C=M;O=D > - https://tarballs.opendev.org/openstack/kayobe/?C=M;O=D > > And so the RDO CI fail to build them for train, ussuri and victoria: > > - https://review.rdoproject.org/r/#/c/31499/ > - https://review.rdoproject.org/r/#/c/31498/ > - https://review.rdoproject.org/r/#/c/31497/ > > So I think we need to reenqueue these jobs too. [...] The files were written into the tarballs volume just fine, but the read-only replicas which back the tarballs.opendev.org site hadn't been synchronized. I found a stuck process (waiting since yesterday for a response from the server which had previously died) and killed it to get the periodic synchronization of the read-only volumes working again so, the site is no longer stale and has those releases on it now as of 15:15:40 UTC today. -- Jeremy Stanley -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From juliaashleykreger at gmail.com Fri Jan 8 17:03:47 2021 From: juliaashleykreger at gmail.com (Julia Kreger) Date: Fri, 8 Jan 2021 09:03:47 -0800 Subject: [dev][ironic] how to read ipa source code#ironic-python-agent In-Reply-To: <20210108162231.wi3u7cqguv3euyqd@yuggoth.org> References: <20210108162231.wi3u7cqguv3euyqd@yuggoth.org> Message-ID: Thanks for beating me to to reply Jeremy! With regards to Rocky, if you can consider a newer version, I would highly recommend it. A few different reasons: 1) Rocky is in extended maintenance. There will not be new releases from the Rocky branch to include new fixes. 2) There have been substantial improvements in interaction/support with Ussuri and Victoria releases. If you have any questions, please feel free to contact us. -Julia On Fri, Jan 8, 2021 at 8:29 AM Jeremy Stanley wrote: > > [Keeping you in Cc since you don't seem to be subscribed to this ML] > > On 2021-01-08 14:17:45 +0800 (+0800), Ankele zhang wrote: > > I have an OpenStack platform on Rocky, and I used > > Nova/Keystone/Cinder/Glance/Ceph/Ironic. Recently, I have build my > > own ironic-python-agent deployment ramdisk and kernel images by > > ironic-python-agent-builder, the following work is to add my > > customized raid configuration method to HardwareManager. Before > > this, I want to read the ipa's source code. But I don't know where > > is the 'main()' entry. Looking forward to your help. > > You specifically want the stable/rocky version? The > ironic-python-agent console script entrypoint (according to the > setup.cfg at the top of that repository) calls the run() function > from this file: > > https://opendev.org/openstack/ironic-python-agent/src/branch/stable/rocky/ironic_python_agent/cmd/agent.py > > Hope that helps! > -- > Jeremy Stanley From mthode at mthode.org Fri Jan 8 17:04:41 2021 From: mthode at mthode.org (Matthew Thode) Date: Fri, 8 Jan 2021 11:04:41 -0600 Subject: [all][tc] Dropping lower-constraints testing from all projects In-Reply-To: References: <176d8da769b.b6edb13b874337.4809906168220534198@ghanshyammann.com> Message-ID: <20210108170441.koyxpaxsse7qj645@mthode.org> On 21-01-08 10:21:51, Brian Rosmaita wrote: > On 1/6/21 12:59 PM, Ghanshyam Mann wrote: > > Hello Everyone, > > > > You might have seen the discussion around dropping the lower constraints > > testing as it becomes more challenging than the current value of doing it. > > I think the TC needs to discuss this explicitly (at a meeting or two, not > just on the ML) and give the projects some guidance. I agree that there's > little point in maintaining the l-c if they're not actually useful to anyone > in their current state, but if their helpfulness (or potential helpfulness) > outweighs the maintenance burden, then we should keep them. (How's that for > a profound statement?) > > Maybe someone can point me to where I can RTFM to get a clearer picture, but > my admittedly vague idea of what the l-c are for is that it has something to > do with making packaging easier. If that's the case, it would be good for > the TC to reach out to some openstack packagers/distributors to find outline > how they use l-c (if at all) and what changes could be done to make them > actually useful, and then we can re-assess the maintenance burden. > > This whole experience with the new pip resolver has been painful, I think, > because it hit all projects and all branches at once. My experience, > however, is that if I'd been updating the minimum versions for all the > cinder deliverables in their requirements.txt and l-c.txt files every cycle > to reflect a pip freeze at Milestone-3 it would have been a lot easier. > > What do other projects do about this? In Cinder, we've just been updating > the requirements on-demand, not proactively, and as a result for some > dependencies we claimed that foo>=0.9.0 is OK -- but except for unit tests > in the l-c job, cinder deliverables haven't been using anything other than > foo>=16.0 since rocky. So in master, I took advantage of having to revise > requirements and l-c to make some major jumps in minimum versions. And I'm > thinking of doing a pip-freeze requirements.txt minimum version update from > now on at M-3 each cycle, which will force me to make an l-c.txt update too. > (Maybe I was supposed to be doing that all along? Or maybe it's a bad idea? > I could use some guidance here.) > > It would be good for the l-c to reflect reality, but on the other hand, > updating the minimum versions in requirements.txt (and hence in l-c) too > aggressively probably won't help packagers at all. (Or maybe it will, I > don't know.) On the other hand, having the l-c is useful from the > standpoint of letting you know when your minimum acceptable version in > requirements.txt will break your unit tests. But if we're updating the > minimum versions of dependencies every cycle to known good minimum versions, > an l-c failure is going to be pretty rare, so maybe it's not worth the > trouble of maintaining the l-c.txt and CI job. > > One other thing: if we do keep l-c, we need to have some guidance about > what's actually supposed to be in there. (Or I need to RTFM.) I've noticed > that as we've added new dependencies to cinder, we've included the > dependency in l-c.txt, but not its indirect dependencies. I guess we should > have been adding the indirect dependencies all along, too? (Spoiler alert: > we haven't.) > > This email has gotten too long, so I will shut up now. > > cheers, > brian > > > > > Few of the ML thread around this discussion: > > > > - http://lists.openstack.org/pipermail/openstack-discuss/2020-December/019521.html > > - http://lists.openstack.org/pipermail/openstack-discuss/2020-December/019390.html > > > > As Oslo and many other project dropping or already dropped it, we should decide it for all > > other projects also otherwise it can be more changing than it is currently. > > > > We have not defined it in PTI or testing runtime so it is always up to projects if they still > > want to keep it but we should decide a general recommendation here. > > > > -gmann > > > > /requirements hat l-c was mainly promoted as a way to know when you are using a feature that is not in an old release. The way we generally test is with newer constraints, which don't test what we state we support (the range between the lower bound in requirements.txt and upper-contraints). While I do think it's useful to know that the range of versions of a library needs to be updated... I understand that it may not be useful, either because of the possible maintenance required by devs, the load on the testing infrastructure generated by testing lower-constraints or that downstream packagers do not use it. Search this for lower-constraints. https://docs.openstack.org/project-team-guide/dependency-management.html Indirect dependencies in lower-constraints were not encouraged iirc, both for maintenance reasons (lot of churn) and because 'hopefully' downstream deps are doing the same thing and testing their deps for changes they need. /downstream packager hat I do not look at lower-constraints, but I do look at lower-bounds in the requirements.txt file (from which lower-constraints are generated). I look for updates in the lower-bounds to know if a library that was already packaged needed updating, though I do try and target the version mentioned in upper-constraints.txt when updating. More and more I've just made sure that the entire dependency tree for openstack matches what is packaged. Even then though, if the minimum is not updated then this pushes it down on users. /user (deployer) perspective Why does $PROJECT not work, I'm going to report it as a bug to $distro, $deployment and $upstream. What they did was not update the version of pyroute2 (or something) because $project didn't update the lower bound to require it. -- Matthew Thode -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From mjturek at us.ibm.com Fri Jan 8 19:22:16 2021 From: mjturek at us.ibm.com (Michael J Turek) Date: Fri, 8 Jan 2021 19:22:16 +0000 Subject: [nova] unit testing on ppc64le In-Reply-To: <5E9MMQ.3INH7FY465VR3@est.tech> References: <5E9MMQ.3INH7FY465VR3@est.tech> Message-ID: An HTML attachment was scrubbed... URL: From rodrigo.barbieri2010 at gmail.com Fri Jan 8 21:27:39 2021 From: rodrigo.barbieri2010 at gmail.com (Rodrigo Barbieri) Date: Fri, 8 Jan 2021 18:27:39 -0300 Subject: [nova] workarounds and operator experience around bug 1522307/1908133 In-Reply-To: <20210106134822.Horde.dGo06NkPF_G8_AogeK9L2i7@webmail.nde.ag> References: <7b4f6f10e682698dfaed22a86397f5b174fed7e8.camel@redhat.com> <20210106134822.Horde.dGo06NkPF_G8_AogeK9L2i7@webmail.nde.ag> Message-ID: Thanks for the responses Eugen and Sean! The placement.yaml approach sounds good if it can prevent the compute host from reporting local_gb repeatedly, and then as you suggested use Placement Aggregates I can perhaps make that work for a subset of use cases. Too bad it is only available on Victoria+. I was looking for something that could work, even if partially, on Queens and Stein. The cron job updating the reservation, I'm not sure if it will clash with the host updates (being overriden, as I've described in the LP bug), but you actually gave me another idea. I may be able to create a fake allocation in the nodes to cancel out their reported values, and then rely only on the shared value through placement. Monitoring Ceph is only part of the problem. The second part, if you end up needing it (and you may if you're not very conservative in the monitoring parameters and have unpredictable workload) is to prevent new instances from being created, thus new data from being stored, to prevent it from filling up before you can react to it (think of an accidental DoS attack by running a certain storage-heavy workloads). @Eugen, yes. I was actually looking for more reliable ways to prevent it from happening. Overall, the shared placement + fake allocation sounded like the cleanest workaround for me. I will try that and report back. Thanks for the help! On Wed, Jan 6, 2021 at 10:57 AM Eugen Block wrote: > Hi, > > we're using OpenStack with Ceph in production and also have customers > doing that. > From my point of view fixing nova to be able to deal with shared > storage of course would improve many things, but it doesn't liberate > you from monitoring your systems. Filling up a ceph cluster should be > avoided and therefore proper monitoring is required. > > I assume you were able to resolve the frozen instances? > > Regards, > Eugen > > > Zitat von Sean Mooney : > > > On Tue, 2021-01-05 at 14:17 -0300, Rodrigo Barbieri wrote: > >> Hi Nova folks and OpenStack operators! > >> > >> I have had some trouble recently where while using the "images_type = > rbd" > >> libvirt option my ceph cluster got filled up without I noticing and > froze > >> all my nova services and instances. > >> > >> I started digging and investigating why and how I could prevent or > >> workaround this issue, but I didn't find a very reliable clean way. > >> > >> I documented all my steps and investigation in bug 1908133 [0]. It has > been > >> marked as a duplicate of 1522307 [1] which has been around for quite > some > >> time, so I am wondering if any operators have been using nova + ceph in > >> production with "images_type = rbd" config set and how you have been > >> handling/working around the issue. > > > > this is indeed a know issue and the long term plan to fix it was to > > track shared storae > > as a sharing resouce provide in plamcent. that never happend so > > there si currenlty no mechanium > > available to prevent this explcitly in nova. > > > > the disk filter which is nolonger used could prevnet the boot of a > > vm that would fill the ceph pool but > > it could not protect against two concurrent request form filling the > pool. > > > > placement can protect against that due to the transational nature of > > allocations which serialise > > all resouce useage however since each host reports the total size of > > the ceph pool as its local storage that wont work out of the box. > > > > as a quick hack what you can do is set the > > [DEFAULT]/disk_allocation_ratio=(1/number of compute nodes) > > > https://docs.openstack.org/nova/latest/configuration/config.html#DEFAULT.disk_allocation_ratio > > on each of your compute agents configs. > > > > > > that will prevent over subscription however it has other negitve > sidefects. > > mainly that you will fail to scudle instance that could boot if a > > host exced its 1/n usage > > so unless you have perfectly blanced consumtion this is not a good > approch. > > > > a better appoch but one that requires external scripting is to have > > a chron job that will update the resrved > > usaage of each of the disk_gb inventores to the actull amount of of > > stoarge allocated form the pool. > > > > the real fix however is for nova to tack its shared usage in > > placment correctly as a sharing resouce provide. > > > > its possible you might be able to do that via the porvider.yaml file > > > > by overriding the local disk_gb to 0 on all comupte nodes > > then creating a singel haring resouce provider of disk_gb that > > models the ceph pool. > > > > > https://specs.openstack.org/openstack/nova-specs/specs/ussuri/approved/provider-config-file.html > > currently that does not support the addtion of providers to placment > > agggreate so while it could be used to 0 out the comptue node > > disk inventoies and to create a sharing provider it with the > > MISC_SHARES_VIA_AGGREGATE trait it cant do the final step of mapping > > which compute nodes can consume form sharing provider via the > > agggrate but you could do that form. > > that assume that "sharing resouce provdiers" actully work. > > > > > > bacialy what it comes down to today is you need to monitor the > > avaiable resouce yourslef externally and ensure you never run out of > > space. > > that sucks but untill we proably track things in plamcent there is > > nothign we can really do. > > the two approch i suggested above might work for a subset of > > usecasue but really this is a feature that need native suport in > > nova to adress properly. > > > >> > >> Thanks in advance! > >> > >> [0] https://bugs.launchpad.net/nova/+bug/1908133 > >> [1] https://bugs.launchpad.net/nova/+bug/1522307 > >> > > > > > -- Rodrigo Barbieri MSc Computer Scientist OpenStack Manila Core Contributor Federal University of São Carlos -------------- next part -------------- An HTML attachment was scrubbed... URL: From smooney at redhat.com Fri Jan 8 22:07:09 2021 From: smooney at redhat.com (Sean Mooney) Date: Fri, 08 Jan 2021 22:07:09 +0000 Subject: [nova] workarounds and operator experience around bug 1522307/1908133 In-Reply-To: References: <7b4f6f10e682698dfaed22a86397f5b174fed7e8.camel@redhat.com> <20210106134822.Horde.dGo06NkPF_G8_AogeK9L2i7@webmail.nde.ag> Message-ID: <98fb643dc6ec0d0201c8e4aea114cd07cf46fef7.camel@redhat.com> On Fri, 2021-01-08 at 18:27 -0300, Rodrigo Barbieri wrote: > Thanks for the responses Eugen and Sean! > > The placement.yaml approach sounds good if it can prevent the compute host > from reporting local_gb repeatedly, and then as you suggested use Placement > Aggregates I can perhaps make that work for a subset of use cases. Too bad > it is only available on Victoria+. I was looking for something that could > work, even if partially, on Queens and Stein. > > The cron job updating the reservation, I'm not sure if it will clash with > the host updates (being overriden, as I've described in the LP bug), but > you actually gave me another idea. I may be able to create a fake > allocation in the nodes to cancel out their reported values, and then rely > only on the shared value through placement. well actully you could use the host reserved disk space config value to do that on older releases just set it equal to the pool size. https://docs.openstack.org/nova/latest/configuration/config.html#DEFAULT.reserved_host_disk_mb not sure why that is in MB it really should be GB but anyway if you set that then it will set the placement value. > > Monitoring Ceph is only part of the problem. The second part, if you end up > needing it (and you may if you're not very conservative in the monitoring > parameters and have unpredictable workload) is to prevent new instances > from being created, thus new data from being stored, to prevent it from > filling up before you can react to it (think of an accidental DoS attack by > running a certain storage-heavy workloads). > > @Eugen, yes. I was actually looking for more reliable ways to prevent it > from happening. > > Overall, the shared placement + fake allocation sounded like the cleanest > workaround for me. I will try that and report back. if i get time in the next week or two im hoping ot try and tweak our ceph ci job to test that toplogy in the upstream ci. but just looking a the placemnt funcitonal tests it should work. This covers the use of sharing resouce providers https://github.com/openstack/placement/blob/master/placement/tests/functional/gabbits/shared-resources.yaml the final section thes the allocation candiate endpoint and asserts we getan allocation for both providres https://github.com/openstack/placement/blob/master/placement/tests/functional/gabbits/shared-resources.yaml#L135-L143 its relitivly simple to read this file top to bottom and its only 143 lines long but it basically step through and constucte the topolgoy i was descifbing or at least a similar ones and shows step by step what the different behavior will be as the rps are created and aggreates are created exctra. the main issue with this approch is we dont really have a good way to upgrade existing deployments to this toplogy beyond live migrating everything one node at a time so that there allcoation will get reshaped as a side effect of the move operation. looking a tthe history of this file it was added 3 years ago https://github.com/openstack/placement/commit/caeae7a41ed41535195640dfa6c5bb58a7999a9b around stien although it may also have worked before thatim not sure when we added sharing providers. > > Thanks for the help! > > On Wed, Jan 6, 2021 at 10:57 AM Eugen Block wrote: > > > Hi, > > > > we're using OpenStack with Ceph in production and also have customers > > doing that. > >  From my point of view fixing nova to be able to deal with shared > > storage of course would improve many things, but it doesn't liberate > > you from monitoring your systems. Filling up a ceph cluster should be > > avoided and therefore proper monitoring is required. > > > > I assume you were able to resolve the frozen instances? > > > > Regards, > > Eugen > > > > > > Zitat von Sean Mooney : > > > > > On Tue, 2021-01-05 at 14:17 -0300, Rodrigo Barbieri wrote: > > > > Hi Nova folks and OpenStack operators! > > > > > > > > I have had some trouble recently where while using the "images_type = > > rbd" > > > > libvirt option my ceph cluster got filled up without I noticing and > > froze > > > > all my nova services and instances. > > > > > > > > I started digging and investigating why and how I could prevent or > > > > workaround this issue, but I didn't find a very reliable clean way. > > > > > > > > I documented all my steps and investigation in bug 1908133 [0]. It has > > been > > > > marked as a duplicate of 1522307 [1] which has been around for quite > > some > > > > time, so I am wondering if any operators have been using nova + ceph in > > > > production with "images_type = rbd" config set and how you have been > > > > handling/working around the issue. > > > > > > this is indeed a know issue and the long term plan to fix it was to > > > track shared storae > > > as a sharing resouce provide in plamcent. that never happend so > > > there si currenlty no mechanium > > > available to prevent this explcitly in nova. > > > > > > the disk filter which is nolonger used could prevnet the boot of a > > > vm that would fill the ceph pool but > > > it could not protect against two concurrent request form filling the > > pool. > > > > > > placement can protect against that due to the transational nature of > > > allocations which serialise > > > all resouce useage however since each host reports the total size of > > > the ceph pool as its local storage that wont work out of the box. > > > > > > as a quick hack what you can do is set the > > > [DEFAULT]/disk_allocation_ratio=(1/number of compute nodes) > > > > > https://docs.openstack.org/nova/latest/configuration/config.html#DEFAULT.disk_allocation_ratio > > > on each of your compute agents configs. > > > > > > > > > that will prevent over subscription however it has other negitve > > sidefects. > > > mainly that you will fail to scudle instance that could boot if a > > > host exced its 1/n usage > > > so unless you have perfectly blanced consumtion this is not a good > > approch. > > > > > > a better appoch but one that requires external scripting is to have > > > a chron job that will update the resrved > > >  usaage of each of the disk_gb inventores to the actull amount of of > > > stoarge allocated form the pool. > > > > > > the real fix however is for nova to tack its shared usage in > > > placment correctly as a sharing resouce provide. > > > > > > its possible you might be able to do that via the porvider.yaml file > > > > > > by overriding the local disk_gb to 0 on all comupte nodes > > > then creating a singel haring resouce provider of disk_gb that > > > models the ceph pool. > > > > > > > > https://specs.openstack.org/openstack/nova-specs/specs/ussuri/approved/provider-config-file.html > > > currently that does not support the addtion of providers to placment > > > agggreate so while it could be used to 0 out the comptue node > > > disk inventoies and to create a sharing provider it with the > > > MISC_SHARES_VIA_AGGREGATE trait it cant do the final step of mapping > > > which compute nodes can consume form sharing provider via the > > > agggrate but you could do that form. > > > that assume that "sharing resouce provdiers" actully work. > > > > > > > > > bacialy what it comes down to today is you need to monitor the > > > avaiable resouce yourslef externally and ensure you never run out of > > > space. > > > that sucks but untill we proably track things in plamcent there is > > > nothign we can really do. > > > the two approch i suggested above might work for a subset of > > > usecasue but really this is a feature that need native suport in > > > nova to adress properly. > > > > > > > > > > > Thanks in advance! > > > > > > > > [0] https://bugs.launchpad.net/nova/+bug/1908133 > > > > [1] https://bugs.launchpad.net/nova/+bug/1522307 > > > > > > > > > > > > > > > From jgoetz at teraswitch.com Fri Jan 8 22:19:25 2021 From: jgoetz at teraswitch.com (Justin Goetz) Date: Fri, 8 Jan 2021 17:19:25 -0500 Subject: [nova] [Ussuri] Unable to perform live block migrations on ephemeral VMs without shared storage Message-ID: Hello! Happy new year to everyone! I'm experiencing some trouble in my attempts to get live block migrations working on machines who's boot drives live on ephemeral (local) host storage. Offline (cold) migrations appear to work fine, however, I need live migrations to function with no downtime to the VMs. We're running on OpenStack Ussuri, with Ubuntu 18.04.5 LTS as our hypervisor OS, running libvirt 6.0.0. Below is the following command I'm utilizing to perform the live block migration: openstack server migrate --debug --verbose --live-migration --block-migration The verbose logging of the above command shows no obvious issues, however digging deeper on the hypervisor side, we see some libvirtd errors, and the most telling is this segment here: Jan 08 16:53:02 h5 libvirtd[4118]: Unsafe migration: Migration without shared storage is unsafe Jan 08 16:53:02 h5 nova-compute[130270]: 2021-01-08 16:53:02.860 130270 ERROR nova.virt.libvirt.driver [-] [instance: 72bc9feb-b8f0-45f2-bad4-9cb61c3abff3] Live Migration failure: Unsafe migration: Migration without shared storage is unsafe: libvirt.libvirtError: Unsafe migration: Migration without shared storage is unsafe Full log output is available here: http://paste.openstack.org/show/801525/ Perhaps I'm severely mistaken, but native libvirt should have no problem whatsoever performing live migrations without shared storage on it's own. I've dug into the libvirt side for hours to try and troubleshoot what the system is seeing as "unsafe" (I confirmed disk caching is disabled, as well as no strange custom settings are present), but was unsuccessful. The full output of my VM's QEMU XML file can be viewed here: http://paste.openstack.org/show/801526/ As I couldn't figure out why libvirtd was not seeing the migration as "safe", I attempted to override the libvirt message by attempting to utilize the live_migration_flag and block_migration_flag options in nova.conf to invoke the --unsafe parameter when running the libvirt commands (with the flags VIR_MIGRATE_UNDEFINE_SOURCE,VIR_MIGRATE_PEER2PEER,VIR_MIGRATE_LIVE,VIR_MIGRATE_UNSAFE,VIR_MIGRATE_NON_SHARED_INC), however I later learned from a previous developers thread on the mailing list from 2016 that both of these options have been depreciated in the later versions of Nova and replaced by the "live_migration_tunnelled" setting in nova.conf. I've ensured my nova.conf files have the live_migration_tunnelled parameter set to "True". However, I have not found any method for passing along the "--unsafe" flag (or any other libvirt flag, in this case) to libvirt from nova.conf from this point on after the depreciation of the live_migration_flag parameters. Any help would be greatly appreciated, from reading around online this seems to be a fairly common setup, I'm baffled at how I've run into this issue across several separate OpenStack clusters at this point. Thank you for reading. -- Justin Goetz Systems Engineer, TeraSwitch Inc. jgoetz at teraswitch.com 412-945-7045 (NOC) | 412-459-7945 (Direct) -------------- next part -------------- An HTML attachment was scrubbed... URL: From jungleboyj at gmail.com Sat Jan 9 18:45:02 2021 From: jungleboyj at gmail.com (Jay S. Bryant) Date: Sat, 9 Jan 2021 12:45:02 -0600 Subject: [all][tc] Dropping lower-constraints testing from all projects In-Reply-To: <20210108170441.koyxpaxsse7qj645@mthode.org> References: <176d8da769b.b6edb13b874337.4809906168220534198@ghanshyammann.com> <20210108170441.koyxpaxsse7qj645@mthode.org> Message-ID: On 1/8/2021 11:04 AM, Matthew Thode wrote: > On 21-01-08 10:21:51, Brian Rosmaita wrote: >> On 1/6/21 12:59 PM, Ghanshyam Mann wrote: >>> Hello Everyone, >>> >>> You might have seen the discussion around dropping the lower constraints >>> testing as it becomes more challenging than the current value of doing it. >> I think the TC needs to discuss this explicitly (at a meeting or two, not >> just on the ML) and give the projects some guidance. I agree that there's >> little point in maintaining the l-c if they're not actually useful to anyone >> in their current state, but if their helpfulness (or potential helpfulness) >> outweighs the maintenance burden, then we should keep them. (How's that for >> a profound statement?) >> >> Maybe someone can point me to where I can RTFM to get a clearer picture, but >> my admittedly vague idea of what the l-c are for is that it has something to >> do with making packaging easier. If that's the case, it would be good for >> the TC to reach out to some openstack packagers/distributors to find outline >> how they use l-c (if at all) and what changes could be done to make them >> actually useful, and then we can re-assess the maintenance burden. >> >> This whole experience with the new pip resolver has been painful, I think, >> because it hit all projects and all branches at once. My experience, >> however, is that if I'd been updating the minimum versions for all the >> cinder deliverables in their requirements.txt and l-c.txt files every cycle >> to reflect a pip freeze at Milestone-3 it would have been a lot easier. >> >> What do other projects do about this? In Cinder, we've just been updating >> the requirements on-demand, not proactively, and as a result for some >> dependencies we claimed that foo>=0.9.0 is OK -- but except for unit tests >> in the l-c job, cinder deliverables haven't been using anything other than >> foo>=16.0 since rocky. So in master, I took advantage of having to revise >> requirements and l-c to make some major jumps in minimum versions. And I'm >> thinking of doing a pip-freeze requirements.txt minimum version update from >> now on at M-3 each cycle, which will force me to make an l-c.txt update too. >> (Maybe I was supposed to be doing that all along? Or maybe it's a bad idea? >> I could use some guidance here.) >> >> It would be good for the l-c to reflect reality, but on the other hand, >> updating the minimum versions in requirements.txt (and hence in l-c) too >> aggressively probably won't help packagers at all. (Or maybe it will, I >> don't know.) On the other hand, having the l-c is useful from the >> standpoint of letting you know when your minimum acceptable version in >> requirements.txt will break your unit tests. But if we're updating the >> minimum versions of dependencies every cycle to known good minimum versions, >> an l-c failure is going to be pretty rare, so maybe it's not worth the >> trouble of maintaining the l-c.txt and CI job. >> >> One other thing: if we do keep l-c, we need to have some guidance about >> what's actually supposed to be in there. (Or I need to RTFM.) I've noticed >> that as we've added new dependencies to cinder, we've included the >> dependency in l-c.txt, but not its indirect dependencies. I guess we should >> have been adding the indirect dependencies all along, too? (Spoiler alert: >> we haven't.) >> >> This email has gotten too long, so I will shut up now. >> >> cheers, >> brian >> >>> Few of the ML thread around this discussion: >>> >>> - http://lists.openstack.org/pipermail/openstack-discuss/2020-December/019521.html >>> - http://lists.openstack.org/pipermail/openstack-discuss/2020-December/019390.html >>> >>> As Oslo and many other project dropping or already dropped it, we should decide it for all >>> other projects also otherwise it can be more changing than it is currently. >>> >>> We have not defined it in PTI or testing runtime so it is always up to projects if they still >>> want to keep it but we should decide a general recommendation here. >>> >>> -gmann >>> >> > /requirements hat > > l-c was mainly promoted as a way to know when you are using a feature > that is not in an old release. The way we generally test is with newer > constraints, which don't test what we state we support (the range > between the lower bound in requirements.txt and upper-contraints). > > While I do think it's useful to know that the range of versions of a > library needs to be updated... I understand that it may not be useful, > either because of the possible maintenance required by devs, the load on > the testing infrastructure generated by testing lower-constraints or > that downstream packagers do not use it. > > Search this for lower-constraints. > https://docs.openstack.org/project-team-guide/dependency-management.html I am in the same boat as Brian that the lower-constraints have never made much sense to me.  The documentation you share above is helpful to understand how everything works but I think it maybe needs to be enhanced as it isn't clear to me as a Cinder team member what I should do to avoid breakages. If we can add some documentation and guidance as to how to maintain these in the branches to avoid a major breakage like this in the future I think it would be a useful effort. Jay > Indirect dependencies in lower-constraints were not encouraged iirc, > both for maintenance reasons (lot of churn) and because 'hopefully' > downstream deps are doing the same thing and testing their deps for > changes they need. > > /downstream packager hat > > I do not look at lower-constraints, but I do look at lower-bounds in the > requirements.txt file (from which lower-constraints are generated). I > look for updates in the lower-bounds to know if a library that was > already packaged needed updating, though I do try and target the version > mentioned in upper-constraints.txt when updating. More and more I've > just made sure that the entire dependency tree for openstack matches > what is packaged. Even then though, if the minimum is not updated then > this pushes it down on users. > > /user (deployer) perspective > > Why does $PROJECT not work, I'm going to report it as a bug to $distro, > $deployment and $upstream. > > What they did was not update the version of pyroute2 (or something) > because $project didn't update the lower bound to require it. > From sean.mcginnis at gmx.com Sun Jan 10 19:40:59 2021 From: sean.mcginnis at gmx.com (Sean McGinnis) Date: Sun, 10 Jan 2021 13:40:59 -0600 Subject: [all][tc] Dropping lower-constraints testing from all projects In-Reply-To: References: <176d8da769b.b6edb13b874337.4809906168220534198@ghanshyammann.com> <20210108170441.koyxpaxsse7qj645@mthode.org> Message-ID: <20210110194059.GA1866794@sm-workstation> > > /requirements hat > > > > l-c was mainly promoted as a way to know when you are using a feature > > that is not in an old release. The way we generally test is with newer > > constraints, which don't test what we state we support (the range > > between the lower bound in requirements.txt and upper-contraints). > > > > While I do think it's useful to know that the range of versions of a > > library needs to be updated... I understand that it may not be useful, > > either because of the possible maintenance required by devs, the load on > > the testing infrastructure generated by testing lower-constraints or > > that downstream packagers do not use it. > > > > Search this for lower-constraints. > > https://docs.openstack.org/project-team-guide/dependency-management.html > > I am in the same boat as Brian that the lower-constraints have never made > much sense to me.  The documentation you share above is helpful to > understand how everything works but I think it maybe needs to be enhanced as > it isn't clear to me as a Cinder team member what I should do to avoid > breakages. > > If we can add some documentation and guidance as to how to maintain these in > the branches to avoid a major breakage like this in the future I think it > would be a useful effort. > > Jay > I agree documentation could really be improved here. But one thing to keep in mind that I think is worth pointing out is that the current breakages are really due to enhancements in pip. Our l-c jobs have been broken for a long time, and we are now just being made painfully aware of it. But now that pip actually enforces these things, theoretically at least, once we fix the problems we have in l-c it should be much easier to maintain going forward. We shouldn't have random stable branch failures, because once we fix our requirements they should remain stable going forward. // 2 cents From pangliye at inspur.com Sat Jan 9 06:26:05 2021 From: pangliye at inspur.com (=?gb2312?B?TGl5ZSBQYW5nKOXMwaLStSk=?=) Date: Sat, 9 Jan 2021 06:26:05 +0000 Subject: [all]Introduction to venus which is the project of log management and has been contributed to the OpenStack community Message-ID: Hello everyone, after feedback from a large number of operations and maintenance personnel in InCloud OpenStack, we developed the log management project “Venus” for the OpenStack projects and that has contributed to the OpenStack community. The following is an introduction to “Venus”. If there is interest in the community, we are interested in proposing it to become an official OpenStack project in the future. Background In the day-to-day operation and maintenance of large-scale cloud platform, the following problems are encountered： l Time-consuming for log querying while the server increasing to thousands. l Difficult to retrieve logs, since there are many modules in the platform, e.g. systems service, compute, storage, network and other platform services. l The large amount and dispersion of log make faults are difficult to be discovered. l Because of distributed and interaction between components of the cloud platform, and scattered logs between components, it will take more time to locate problems. About Venus According to the key requirements of OpenStack in log storage, retrieval, analysis and so on, we introduced Venus project, a unified log management module. This module can provide a one-stop solution to log collection, cleaning, indexing, analysis, alarm, visualization, report generation and other needs, which involves helping operator or maintainer to quickly solve retrieve problems, grasp the operational health of the platform, and improve the management capabilities of the cloud platform. Additionally, this module plans to use machine learning algorithms to quickly locate IT failures and root causes, and improve operation and maintenance efficiency. Application scenario Venus played a key role in the following scenarios： l Retrieval: Provide a simple and easy-to-use way to retrieve all log and the context. l Analysis: Realize log association, field value statistics, and provide multi-scene and multi-dimensional visual analysis reports. l Alerts：Convert retrieval into active alerts to realize the error finding in massive logs. l Issue location: Establish a chain relationship and knowledge graphs to quickly locate problems. Overall structure The architecture of log management system based on Venus and elastic search is as follows: Diagram 0: Architecture of Venus venus_api: API module，provide API、rest-api service. venus_manager: Internal timing task module to realize the core functions of the log system. Current progress The current progress of the Venus project is as follows: l Collection：Develop fluentd collection tasks based on collectd to read, filter, format and send plug-ins for OpenStack, operating systems, and platform services, etc. l Index：Dealing with multi-dimensional index data in elasticsearch, and provide more concise and comprehensive authentication interface to return query results. l Analysis：Analyzing and display the related module errors, Mariadb connection errors, and Rabbitmq connection errors. l Alerts：Develop alarm task code to set threshold for the number of error logs of different modules at different times, and provides alarm services and notification services. l Location：Develop the call chain analysis function based on global_requested series, which can show the execution sequence, time and error information, etc., and provide the export operation. l Management：Develop configuration management functions in the log system, such as alarm threshold setting, timing task management, and log saving time setting, etc. Application examples Two examples of Venus application scenarios are as follows. 1. The virtual machine creation operation was performed on the cloud platform and it was found that the virtual machine was not created successfully. First, we can find the request id of the operation and jump to the virtual machine creation call chain page. Then, we can query the calling process, view and download the details of the log of the call. 2. In the cloud platform, the error log of each module can be converted into alarms to remind the users. Further, we can retrieve the details of the error log and error log statistics. Next step The next step of the Venus project is as follows: * Collection：In addition to fluent, other collection plugins such as logstash will be integrated. * Analysis: Explore more operation and maintenance scenarios, and conduct statistical analysis and alarm on key data. * display: The configuration, analysis and alarm of Venus will be integrated into horizon in the form of plugin. * location: Form clustering log and construct knowledge map, and integrate algorithm class library to locate the root cause of the fault. Venus Project Registry Venus library: https://opendev.org/inspur/venus You can grab the source code using the following git command: git clone https://opendev.org/inspur/venus.git Venus Demo Youtu.be: https://youtu.be/mE2MoEx3awM -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 24507 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.jpg Type: image/jpeg Size: 3184 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image003.jpg Type: image/jpeg Size: 8136 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image004.jpg Type: image/jpeg Size: 15944 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image005.jpg Type: image/jpeg Size: 8405 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image006.jpg Type: image/jpeg Size: 3046 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image007.jpg Type: image/jpeg Size: 15175 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image008.jpg Type: image/jpeg Size: 8496 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3786 bytes Desc: not available URL: From balazs.gibizer at est.tech Mon Jan 11 08:09:54 2021 From: balazs.gibizer at est.tech (Balazs Gibizer) Date: Mon, 11 Jan 2021 09:09:54 +0100 Subject: [nova] unit testing on ppc64le In-Reply-To: References: <5E9MMQ.3INH7FY465VR3@est.tech> Message-ID: On Fri, Jan 8, 2021 at 19:22, Michael J Turek wrote: > Thanks for the heads up, > > We should have the capacity to add them. At one point I think we ran > unit tests for nova but the job may have been culled in the move to > zuul v3. I've CC'd the maintainers of the CI, Aditi Dukle and > Sajauddin Mohammad. Thanks! Let me know if you need help from upstream side. > > Aditi and Sajauddin, could we add a job to pkvmci to run unit tests > for nova? Could please you also make sure that the contact information for this CI is up to date on the wiki[1]? Thanks gibi [1] https://wiki.openstack.org/wiki/ThirdPartySystems/IBMPowerKVMCI > > Michael Turek > Software Engineer > Power Cloud Department > 1 845 433 1290 Office > mjturek at us.ibm.com > He/Him/His > > IBM > > > >> ----- Original message ----- >> From: Balazs Gibizer >> To: OpenStack Discuss >> Cc: mjturek at us.ibm.com >> Subject: [EXTERNAL] [nova] unit testing on ppc64le >> Date: Fri, Jan 8, 2021 7:59 AM >> >> Hi, >> >> We have a bugreport[1] showing that our unit tests are not passing on >> ppc. In the upstream CI we don't have test capability to run our >> tests >> on ppc. But we have the IBM Power KVM CI[2] that runs integration >> tests >> on ppc. I'm wondering if IBM could extend the CI to run nova unit and >> functional tests too. I've added Michael Turek (mjturek at us.ibm.com) >> to >> CC. Michael is listed as the contact person for the CI. >> >> Cheers, >> gibi >> >> [1]https://bugs.launchpad.net/nova/+bug/1909972 >> [2]https://wiki.openstack.org/wiki/ThirdPartySystems/IBMPowerKVMCI >> >> > > From thierry at openstack.org Mon Jan 11 11:18:16 2021 From: thierry at openstack.org (Thierry Carrez) Date: Mon, 11 Jan 2021 12:18:16 +0100 Subject: [largescale-sig] Next meeting: January 13, 15utc Message-ID: Hi everyone, We'll have our first 2021 Large Scale SIG meeting this Wednesday in #openstack-meeting-3 on IRC, at 15UTC. You can doublecheck how it translates locally at: https://www.timeanddate.com/worldclock/fixedtime.html?iso=20210113T15 Our main topic will be to reboot the Large Scale SIG in the new year and get a few work items and contributions planned. Feel free to add other topics to our agenda at: https://etherpad.openstack.org/p/large-scale-sig-meeting Talk to you all later, -- Thierry Carrez From marios at redhat.com Mon Jan 11 11:59:19 2021 From: marios at redhat.com (Marios Andreou) Date: Mon, 11 Jan 2021 13:59:19 +0200 Subject: [tripleo] move os-refresh-config, os-collect-config, tripleo-ipsec to 'release-management': none Message-ID: Hi TripleO, you may have seen the thread started by Herve at [1] around the deadline for making a victoria release for os-refresh-config, os-collect-config and tripleo-ipsec. This message is to ask if anyone is still using these? In particular would anyone mind if we stopped making tagged releases, as discussed at [2]. Would someone mind if there was no stable/victoria branch for these repos? For the os-refresh/collect-config I suspect the answer is NO - at least, we aren't using these any more in the 'normal' tripleo deployment for a good while now, since we switched to config download by default. We haven't even created an ussuri branch for these [3] and no one has shouted about that (or at least not loud enough I haven't heard anything). For tripleo-ipsec it *looks* like we're still using it in the sense that we carry the template and pass the parameters in tripleo-heat-templates [4]. However we aren't running that in any CI job as far as I can see, and we haven't created any branches there since Rocky. So is anyone using tripleo-ipsec? Depending on the answers here and as discussed at [2] I will move to make these as unreleased (release-management: none in openstack/governance reference/projects.yaml) and remove the release file altogether. For now however and given the deadline of this week for a victoria release I am proposing that we move forward with [2] and cut the victoria branch for these. thanks for reading and please speak up if any of the above are important to you! thanks, marios [1] http://lists.openstack.org/pipermail/openstack-discuss/2021-January/019730.html [2] https://review.opendev.org/c/openstack/releases/+/769915/1/deliverables/victoria/os-refresh-config.yaml [3] https://pastebin.com/raw/KJ0JxKPx [4] https://opendev.org/openstack/tripleo-heat-templates/src/commit/9fd709019fdd36d4c4821b2486e7151abf84bc3f/deployment/ipsec/ipsec-baremetal-ansible.yaml#L101-L106 -------------- next part -------------- An HTML attachment was scrubbed... URL: From thierry at openstack.org Mon Jan 11 13:12:29 2021 From: thierry at openstack.org (Thierry Carrez) Date: Mon, 11 Jan 2021 14:12:29 +0100 Subject: [all]Introduction to venus which is the project of log management and has been contributed to the OpenStack community In-Reply-To: References: Message-ID: Liye Pang(逄立业) wrote: > Hello everyone, after feedback from a large number of operations and > maintenance personnel in InCloud OpenStack, we developed the log > management project “Venus” for the OpenStack projects [...] OpenStack-aware centralized log management sounds very interesting to me... If others are interested in collaborating on producing that component, I personally think it would be a great fit for the "operations tooling" section of the OpenStack Map[1]. [1] https://www.openstack.org/software/ -- Thierry Carrez (ttx) From amy at demarco.com Mon Jan 11 13:49:09 2021 From: amy at demarco.com (Amy Marrich) Date: Mon, 11 Jan 2021 07:49:09 -0600 Subject: [Diversity] Diversity &Inclusion WG Meeting reminder Message-ID: The Diversity & Inclusion WG invites members of all OSF projects to our meeting today, at 17:00 UTC in the #openstack-diversity channel. The agenda can be found at https://etherpad.openstack.org/p/diversity-wg-agenda. Please feel free to add any other topics you wish to discuss at the meeting. Thanks, Amy (spotz) -------------- next part -------------- An HTML attachment was scrubbed... URL: From james.slagle at gmail.com Mon Jan 11 14:24:24 2021 From: james.slagle at gmail.com (James Slagle) Date: Mon, 11 Jan 2021 09:24:24 -0500 Subject: [Heat][tripleo] move os-refresh-config, os-collect-config, tripleo-ipsec to 'release-management': none In-Reply-To: References: Message-ID: On Mon, Jan 11, 2021 at 7:04 AM Marios Andreou wrote: > For the os-refresh/collect-config I suspect the answer is NO - at least, > we aren't using these any more in the 'normal' tripleo deployment for a > good while now, since we switched to config download by default. We haven't > even created an ussuri branch for these [3] and no one has shouted about > that (or at least not loud enough I haven't heard anything). > TripleO doesn't use them, but I think Heat still does for the support of SoftwareDeployment/StructuredDeployment. I've added [Heat] to the subject tags. It is as least still documented: https://docs.openstack.org/heat/latest/template_guide/software_deployment.html#software-deployment-resources which shows using the os-*-config elements from tripleo-image-elements to build an image with diskimage-builder. However, that doesn't mean we need to create stable branches or releases for these repos. The elements support installing from source, and RDO is packaging off of master it seems. -- -- James Slagle -- -------------- next part -------------- An HTML attachment was scrubbed... URL: From aschultz at redhat.com Mon Jan 11 14:26:34 2021 From: aschultz at redhat.com (Alex Schultz) Date: Mon, 11 Jan 2021 07:26:34 -0700 Subject: [tripleo] move os-refresh-config, os-collect-config, tripleo-ipsec to 'release-management': none In-Reply-To: References: Message-ID: On Mon, Jan 11, 2021 at 4:59 AM Marios Andreou wrote: > > Hi TripleO, > > you may have seen the thread started by Herve at [1] around the deadline for making a victoria release for os-refresh-config, os-collect-config and tripleo-ipsec. > > This message is to ask if anyone is still using these? In particular would anyone mind if we stopped making tagged releases, as discussed at [2]. Would someone mind if there was no stable/victoria branch for these repos? > > For the os-refresh/collect-config I suspect the answer is NO - at least, we aren't using these any more in the 'normal' tripleo deployment for a good while now, since we switched to config download by default. We haven't even created an ussuri branch for these [3] and no one has shouted about that (or at least not loud enough I haven't heard anything). Maybe switch to independent? That being said as James points out they are still used by Heat so maybe the ownership should be moved. > > For tripleo-ipsec it *looks* like we're still using it in the sense that we carry the template and pass the parameters in tripleo-heat-templates [4]. However we aren't running that in any CI job as far as I can see, and we haven't created any branches there since Rocky. So is anyone using tripleo-ipsec? > I think tripleo-ipsec is no longer needed as we now have proper tls-everywhere support. We might want to revisit this and deprecate/remove it. > Depending on the answers here and as discussed at [2] I will move to make these as unreleased (release-management: none in openstack/governance reference/projects.yaml) and remove the release file altogether. > > For now however and given the deadline of this week for a victoria release I am proposing that we move forward with [2] and cut the victoria branch for these. > > thanks for reading and please speak up if any of the above are important to you! > > thanks, marios > > [1] http://lists.openstack.org/pipermail/openstack-discuss/2021-January/019730.html > [2] https://review.opendev.org/c/openstack/releases/+/769915/1/deliverables/victoria/os-refresh-config.yaml > [3] https://pastebin.com/raw/KJ0JxKPx > [4] https://opendev.org/openstack/tripleo-heat-templates/src/commit/9fd709019fdd36d4c4821b2486e7151abf84bc3f/deployment/ipsec/ipsec-baremetal-ansible.yaml#L101-L106 > From akekane at redhat.com Mon Jan 11 14:44:04 2021 From: akekane at redhat.com (Abhishek Kekane) Date: Mon, 11 Jan 2021 20:14:04 +0530 Subject: [Glance] PTL on leaves Message-ID: Hi All, I'm going on leave from 13th January and will be back on 21st January to attend my sister's wedding. Please direct any issues to the rest of the core team. Thanks & Best Regards, Abhishek Kekane -------------- next part -------------- An HTML attachment was scrubbed... URL: From hberaud at redhat.com Mon Jan 11 15:07:31 2021 From: hberaud at redhat.com (Herve Beraud) Date: Mon, 11 Jan 2021 16:07:31 +0100 Subject: [tripleo] move os-refresh-config, os-collect-config, tripleo-ipsec to 'release-management': none In-Reply-To: References: Message-ID: Le lun. 11 janv. 2021 à 15:27, Alex Schultz a écrit : > On Mon, Jan 11, 2021 at 4:59 AM Marios Andreou wrote: > > > > Hi TripleO, > > > > you may have seen the thread started by Herve at [1] around the deadline > for making a victoria release for os-refresh-config, os-collect-config and > tripleo-ipsec. > > > > This message is to ask if anyone is still using these? In particular > would anyone mind if we stopped making tagged releases, as discussed at > [2]. Would someone mind if there was no stable/victoria branch for these > repos? > > > > For the os-refresh/collect-config I suspect the answer is NO - at least, > we aren't using these any more in the 'normal' tripleo deployment for a > good while now, since we switched to config download by default. We haven't > even created an ussuri branch for these [3] and no one has shouted about > that (or at least not loud enough I haven't heard anything). > > Maybe switch to independent? That being said as James points out they > are still used by Heat so maybe the ownership should be moved. > I agree, moving them to the independent model could be a solution, in this case the patch could be adapted to reflect that choice and we could ignore these repos from victoria deadline point of view. Concerning the "ownership" side of the question this is more an internal discussion between teams and eventually the TC, I don't think that that will impact us from a release management POV. > > > > For tripleo-ipsec it *looks* like we're still using it in the sense that > we carry the template and pass the parameters in tripleo-heat-templates > [4]. However we aren't running that in any CI job as far as I can see, and > we haven't created any branches there since Rocky. So is anyone using > tripleo-ipsec? > > > > I think tripleo-ipsec is no longer needed as we now have proper > tls-everywhere support. We might want to revisit this and > deprecate/remove it. > > > Depending on the answers here and as discussed at [2] I will move to > make these as unreleased (release-management: none in openstack/governance > reference/projects.yaml) and remove the release file altogether. > > > > For now however and given the deadline of this week for a victoria > release I am proposing that we move forward with [2] and cut the victoria > branch for these. > > > > thanks for reading and please speak up if any of the above are important > to you! > > > > thanks, marios > > > > [1] > http://lists.openstack.org/pipermail/openstack-discuss/2021-January/019730.html > > [2] > https://review.opendev.org/c/openstack/releases/+/769915/1/deliverables/victoria/os-refresh-config.yaml > > [3] https://pastebin.com/raw/KJ0JxKPx > > [4] > https://opendev.org/openstack/tripleo-heat-templates/src/commit/9fd709019fdd36d4c4821b2486e7151abf84bc3f/deployment/ipsec/ipsec-baremetal-ansible.yaml#L101-L106 > > > > -- Hervé Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/ https://twitter.com/4383hberaud -----BEGIN PGP SIGNATURE----- wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O v6rDpkeNksZ9fFSyoY2o =ECSj -----END PGP SIGNATURE----- -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark at stackhpc.com Mon Jan 11 15:07:53 2021 From: mark at stackhpc.com (Mark Goddard) Date: Mon, 11 Jan 2021 15:07:53 +0000 Subject: [all]Introduction to venus which is the project of log management and has been contributed to the OpenStack community In-Reply-To: References: Message-ID: On Mon, 11 Jan 2021 at 13:13, Thierry Carrez wrote: > > Liye Pang(逄立业) wrote: > > Hello everyone, after feedback from a large number of operations and > > maintenance personnel in InCloud OpenStack, we developed the log > > management project “Venus” for the OpenStack projects [...] > OpenStack-aware centralized log management sounds very interesting to me... > > If others are interested in collaborating on producing that component, I > personally think it would be a great fit for the "operations tooling" > section of the OpenStack Map[1]. > > [1] https://www.openstack.org/software/ Let's not forget that Monasca has a log aggregation API [1] [1] https://wiki.openstack.org/wiki/Monasca/Logging > > -- > Thierry Carrez (ttx) > From moguimar at redhat.com Mon Jan 11 15:57:09 2021 From: moguimar at redhat.com (Moises Guimaraes de Medeiros) Date: Mon, 11 Jan 2021 16:57:09 +0100 Subject: [barbican][oslo][nova][glance][cinder] cursive library status In-Reply-To: References: <35dfc43f-6613-757b-ed7b-b6530df21289@gmail.com> Message-ID: Hi Brian, During Oslo's last weekly meeting [1] we decided that Oslo can take cursive under its umbrella with collaboration of Barbican folks. I just waited a bit with this confirmation as the Barbican PTL was on PTO and I wanted to confirm with him. What are the next steps from here? [1]: http://eavesdrop.openstack.org/meetings/oslo/2021/oslo.2021-01-04-16.00.log.html#l-64 Thanks, Moisés On Fri, Dec 18, 2020 at 10:06 PM Douglas Mendizabal wrote: > On 12/16/20 12:50 PM, Ben Nemec wrote: > > > > > > On 12/16/20 12:02 PM, Brian Rosmaita wrote: > >> Hello Barbican team, > >> > >> Apologies for not including barbican in the previous thread on this > >> topic: > >> > >> > http://lists.openstack.org/pipermail/openstack-discuss/2020-December/019430.html > >> > >> > >> The situation is that cursive is used by Nova, Glance, and Cinder and > >> we'd like to move it out of the 'x' namespace into openstack > >> governance. The question is then what team would oversee it. It > >> seems like a good fit for Oslo, and the Oslo team seems OK with that, > >> but since barbican-core is currently included in cursive-core, it make > >> sense to give the Barbican team first dibs. > >> > >> From the consuming teams' side, I don't think we have a preference as > >> long as it's clear who we need to bother about approvals if a bugfix > >> is posted for review. > >> > >> Thus my ask is that the Barbican team indicate whether they'd like to > >> move cursive to the 'openstack' namespace under their governance, or > >> whether they'd prefer Oslo to oversee the library. > > > > Note that this is not necessarily an either/or thing. Castellan is under > > Oslo governance but is co-owned by the Oslo and Barbican teams. We could > > do a similar thing with Cursive. > > > > Hi Brian and Ben, > > Sorry I missed the original thread. Given that the end of the year is > around the corner, most of the Barbican team is out on PTO and we > haven't had a chance to discuss this in our weekly meeting. > > That said, I doubt anyone would object to moving cursive into the > openstack namespace. > > I personally do not mind the Oslo team taking over maintenace, and I am > also willing to help review patches if the Oslo team would like to > co-own this library just like we currently do for Castellan. > > - Douglas Mendizábal (redrobot) > > > -- Moisés Guimarães Software Engineer Red Hat -------------- next part -------------- An HTML attachment was scrubbed... URL: From openstack at nemebean.com Mon Jan 11 17:08:47 2021 From: openstack at nemebean.com (Ben Nemec) Date: Mon, 11 Jan 2021 11:08:47 -0600 Subject: [oslo][TC] Dropping lower-constraints testing In-Reply-To: <5755ea96-5cc7-2756-970e-dcbf5184b2a2@debian.org> References: <5755ea96-5cc7-2756-970e-dcbf5184b2a2@debian.org> Message-ID: On 1/6/21 2:58 PM, Thomas Goirand wrote: > On 12/18/20 3:54 PM, hberaud wrote: >> In a first time I tried to fix our gates by fixing our lower-constraints >> project by project but with around ~36 projects to maintain this is a >> painful task, especially due to nested oslo layers inside oslo >> himself... I saw the face of the hell of dependencies. > > Welcome to my world! > >> Thoughts? > > Couldn't someone address the dependency loops in Oslo? It's IMO anyway > needed. Which libraries have circular dependencies? It's something we've intentionally avoided, so if they exist I would consider it a bug. > > Just my 2 cents, not sure if that helps... > Cheers, > > Thomas Goirand (zigo) > From openstack at nemebean.com Mon Jan 11 17:09:35 2021 From: openstack at nemebean.com (Ben Nemec) Date: Mon, 11 Jan 2021 11:09:35 -0600 Subject: [all][tc] Thoughts on Python 3.7 support In-Reply-To: References: <20210105215107.jap2c5evbkpu2u7n@yuggoth.org> <68d4b804-5729-e313-7f29-6c7b14166c5c@nemebean.com> <176d8d1747f.e25ad718873974.5391430581306589135@ghanshyammann.com> Message-ID: On 1/6/21 3:23 PM, Pierre Riteau wrote: > On Wed, 6 Jan 2021 at 18:58, Ghanshyam Mann wrote: >> >> ---- On Wed, 06 Jan 2021 10:34:35 -0600 Ben Nemec wrote ---- >> > >> > >> > On 1/5/21 3:51 PM, Jeremy Stanley wrote: >> > > On 2021-01-05 22:32:58 +0100 (+0100), Pierre Riteau wrote: >> > >> There have been many patches submitted to drop the Python 3.7 >> > >> classifier from setup.cfg: >> > >> https://review.opendev.org/q/%2522remove+py37%2522 >> > >> The justification is that Wallaby tested runtimes only include 3.6 and 3.8. >> > >> >> > >> Most projects are merging these patches, but I've seen a couple of >> > >> objections from ironic and horizon: >> > >> >> > >> - https://review.opendev.org/c/openstack/python-ironicclient/+/769044 >> > >> - https://review.opendev.org/c/openstack/horizon/+/769237 >> > >> >> > >> What are the thoughts of the TC and of the overall community on this? >> > >> Should we really drop these classifiers when there are no >> > >> corresponding CI jobs, even though more Python versions may well be >> > >> supported? >> > > >> > > My recollection of the many discussions we held was that the runtime >> > > document would recommend the default python3 available in our >> > > targeted platforms, but that we would also make a best effort to >> > > test with the latest python3 available to us at the start of the >> > > cycle as well. It was suggested more than once that we should test >> > > all minor versions in between, but this was ruled out based on the >> > > additional CI resources it would consume for minimal gain. Instead >> > > we deemed that testing our target version and the latest available >> > > would give us sufficient confidence that, if those worked, the >> > > versions in between them were likely fine as well. Based on that, I >> > > think the versions projects claim to work with should be contiguous >> > > ranges, not contiguous lists of the exact versions tested (noting >> > > that those aren't particularly *exact* versions to begin with). >> > > >> > > Apologies for the lack of references to old discussions, I can >> > > probably dig some up from the ML and TC meetings several years back >> > > of folks think it will help inform this further. >> > > >> > >> > For what little it's worth, that jives with my hazy memories of the >> > discussion too. The assumption was that if we tested the upper and lower >> > bounds of our Python versions then the ones in the middle would be >> > unlikely to break. It was a compromise to support multiple versions of >> > Python without spending a ton of testing resources on it. >> >> >> Exactly, py3.7 is not broken for OpenStack so declaring it not supported is not the right thing. >> I remember the discussion when we declared the wallaby (probably from Victoria) testing runtime, >> we decided if we test py3.6 and py3.8 it means we are not going to break py3.7 support so indirectly >> it is tested and supported. >> >> And testing runtime does not mean we have to drop everything else testing means projects are all >> welcome to keep running the py3.7 testing job on the gate there is no harm in that. >> >> In both cases, either project has an explicit py3.7 job or not we should not remove it from classifiers. >> >> >> -gmann > > Thanks everyone for your input. Then should we request that those > patches dropping the 3.7 classifier are abandoned, or reverted if > already merged? > That would be my takeaway from this discussion, yes. From hberaud at redhat.com Mon Jan 11 17:57:37 2021 From: hberaud at redhat.com (Herve Beraud) Date: Mon, 11 Jan 2021 18:57:37 +0100 Subject: [oslo][TC] Dropping lower-constraints testing In-Reply-To: References: <5755ea96-5cc7-2756-970e-dcbf5184b2a2@debian.org> Message-ID: Le lun. 11 janv. 2021 à 18:11, Ben Nemec a écrit : > > > On 1/6/21 2:58 PM, Thomas Goirand wrote: > > On 12/18/20 3:54 PM, hberaud wrote: > >> In a first time I tried to fix our gates by fixing our lower-constraints > >> project by project but with around ~36 projects to maintain this is a > >> painful task, especially due to nested oslo layers inside oslo > >> himself... I saw the face of the hell of dependencies. > > > > Welcome to my world! > > > >> Thoughts? > > > > Couldn't someone address the dependency loops in Oslo? It's IMO anyway > > needed. > AFAIK nobody is volunteering on our side, feel free to send patches to fix them.... > > Which libraries have circular dependencies? It's something we've > intentionally avoided, so if they exist I would consider it a bug. > Concerning myself, I meant that by example to fix oslo.messaging its LC you should first address those of oslo.log and etc... This isn't a circular dependency but an order to follow in our patches to fix all our L.C. Also I didn't notice "real" circular dependencies, in other words I only noticed an order to apply to fix all the L.C, but over 36 projects that order is a bit annoying, that's all. > > > > > Just my 2 cents, not sure if that helps... > > Cheers, > > > > Thomas Goirand (zigo) > > > > -- Hervé Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/ https://twitter.com/4383hberaud -----BEGIN PGP SIGNATURE----- wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O v6rDpkeNksZ9fFSyoY2o =ECSj -----END PGP SIGNATURE----- -------------- next part -------------- An HTML attachment was scrubbed... URL: From mnaser at vexxhost.com Mon Jan 11 20:43:04 2021 From: mnaser at vexxhost.com (Mohammed Naser) Date: Mon, 11 Jan 2021 15:43:04 -0500 Subject: [tc] weekly update Message-ID: Hi there, Here's an update for what happened in the OpenStack TC this week. You can get more information by checking for changes in openstack/governance repository. # Patches ## Open Reviews - Setting Xinran Wang as Cyborg's PTL https://review.opendev.org/c/openstack/governance/+/770075 - molteniron does not make releases https://review.opendev.org/c/openstack/governance/+/769805 - Add Resolution of TC stance on the OpenStackClient https://review.opendev.org/c/openstack/governance/+/759904 - Add doc/requirements https://review.opendev.org/c/openstack/governance/+/769696 - Add link to Xena announcement https://review.opendev.org/c/openstack/governance/+/769620 - Add glance-tempest-plugin to Glance https://review.opendev.org/c/openstack/governance/+/767666 - Remove Karbor project team | https://review.opendev.org/c/openstack/governance/+/767056 ## Projects Updates - Deprecate neutron-fwaas and neutron-fwaas-dashboard master branch https://review.opendev.org/c/openstack/governance/+/735828 # Other Reminders - Our next [TC] Weekly meeting is scheduled on January 14th at 1500 UTC. If you would like to add topics for discussion, please go to https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting and fill out your suggestions by Wednesday, January 13th, at 2100 UTC. Thanks for reading! Mohammed & Kendall -- Mohammed Naser VEXXHOST, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From eandersson at blizzard.com Mon Jan 11 20:45:39 2021 From: eandersson at blizzard.com (Erik Olof Gunnar Andersson) Date: Mon, 11 Jan 2021 20:45:39 +0000 Subject: [magnum][api] Error system library fopen too many open files with magnum-auto-healer In-Reply-To: References: <185a9715-4667-9610-0048-5434e6e2cd4e@catalyst.net.nz> Message-ID: Thanks I added it to the commit. Could you share your uwsgi config as well. Best Regards, Erik Olof Gunnar Andersson Technical Lead, Senior Cloud Engineer From: Ionut Biru Sent: Tuesday, January 5, 2021 1:51 AM To: Erik Olof Gunnar Andersson Cc: Spyros Trigazis ; feilong ; openstack-discuss Subject: Re: [magnum][api] Error system library fopen too many open files with magnum-auto-healer Hi, Here is my config. maybe something is fishy. I did have around 300 messages in the queue in notification.info and notification.err and I purged them. https://paste.xinu.at/woMt/ On Tue, Jan 5, 2021 at 11:23 AM Erik Olof Gunnar Andersson > wrote: Yea - tested locally as well and wasn't able to reproduce it either. I changed the health service job to run every second and maxed out at about 42 connections to RabbitMQ with two conductor workers. /etc/magnum/magnun.conf [conductor] workers = 2 ________________________________ From: Spyros Trigazis > Sent: Tuesday, January 5, 2021 12:59 AM To: Ionut Biru > Cc: Erik Olof Gunnar Andersson >; feilong >; openstack-discuss > Subject: Re: [magnum][api] Error system library fopen too many open files with magnum-auto-healer On Tue, Jan 5, 2021 at 9:36 AM Ionut Biru > wrote: Hi, I tried with process=1 and it reached 1016 connections to rabbitmq. lsof https://paste.xinu.at/jGg/ i think it goes into error when it reaches 1024 file descriptors. I'm out of ideas of how to resolve this. I only have 3 clusters available and it's kinda weird and It doesn't scale. No issues here with 100s of clusters. Not sure what doesn't scale. * Maybe your rabbit is flooded with notifications that are not consumed? * You can use way more than 1024 file descriptors, maybe 2^10? Spyros On Mon, Jan 4, 2021 at 9:53 PM Erik Olof Gunnar Andersson > wrote: Sure looks like RabbitMQ. How many workers do have you configured? Could you try to changing the uwsgi configuration to workers=1 (or processes=1) and then see if it goes beyond 30 connections to amqp. From: Ionut Biru > Sent: Monday, January 4, 2021 4:07 AM To: Erik Olof Gunnar Andersson > Cc: feilong >; openstack-discuss > Subject: Re: [magnum][api] Error system library fopen too many open files with magnum-auto-healer Hi Erik, Here is lsof of one uwsgi api. https://paste.xinu.at/5YUWf/ I have kubernetes 12.0.1 installed in env. On Sun, Jan 3, 2021 at 3:06 AM Erik Olof Gunnar Andersson > wrote: Maybe something similar to this? https://github.com/kubernetes-client/python/issues/1158 What does lsof say? -- Ionut Biru - https://fleio.com -- Ionut Biru - https://fleio.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From gmann at ghanshyammann.com Mon Jan 11 21:48:55 2021 From: gmann at ghanshyammann.com (Ghanshyam Mann) Date: Mon, 11 Jan 2021 15:48:55 -0600 Subject: [all][tc] Dropping lower-constraints testing from all projects In-Reply-To: <20210108170441.koyxpaxsse7qj645@mthode.org> References: <176d8da769b.b6edb13b874337.4809906168220534198@ghanshyammann.com> <20210108170441.koyxpaxsse7qj645@mthode.org> Message-ID: <176f36c63fa.f6d7dcc91078291.3697415809509428960@ghanshyammann.com> ---- On Fri, 08 Jan 2021 11:04:41 -0600 Matthew Thode wrote ---- > On 21-01-08 10:21:51, Brian Rosmaita wrote: > > On 1/6/21 12:59 PM, Ghanshyam Mann wrote: > > > Hello Everyone, > > > > > > You might have seen the discussion around dropping the lower constraints > > > testing as it becomes more challenging than the current value of doing it. > > > > I think the TC needs to discuss this explicitly (at a meeting or two, not > > just on the ML) and give the projects some guidance. I agree that there's > > little point in maintaining the l-c if they're not actually useful to anyone > > in their current state, but if their helpfulness (or potential helpfulness) > > outweighs the maintenance burden, then we should keep them. (How's that for > > a profound statement?) > > > > Maybe someone can point me to where I can RTFM to get a clearer picture, but > > my admittedly vague idea of what the l-c are for is that it has something to > > do with making packaging easier. If that's the case, it would be good for > > the TC to reach out to some openstack packagers/distributors to find outline > > how they use l-c (if at all) and what changes could be done to make them > > actually useful, and then we can re-assess the maintenance burden. > > > > This whole experience with the new pip resolver has been painful, I think, > > because it hit all projects and all branches at once. My experience, > > however, is that if I'd been updating the minimum versions for all the > > cinder deliverables in their requirements.txt and l-c.txt files every cycle > > to reflect a pip freeze at Milestone-3 it would have been a lot easier. > > > > What do other projects do about this? In Cinder, we've just been updating > > the requirements on-demand, not proactively, and as a result for some > > dependencies we claimed that foo>=0.9.0 is OK -- but except for unit tests > > in the l-c job, cinder deliverables haven't been using anything other than > > foo>=16.0 since rocky. So in master, I took advantage of having to revise > > requirements and l-c to make some major jumps in minimum versions. And I'm > > thinking of doing a pip-freeze requirements.txt minimum version update from > > now on at M-3 each cycle, which will force me to make an l-c.txt update too. > > (Maybe I was supposed to be doing that all along? Or maybe it's a bad idea? > > I could use some guidance here.) > > > > It would be good for the l-c to reflect reality, but on the other hand, > > updating the minimum versions in requirements.txt (and hence in l-c) too > > aggressively probably won't help packagers at all. (Or maybe it will, I > > don't know.) On the other hand, having the l-c is useful from the > > standpoint of letting you know when your minimum acceptable version in > > requirements.txt will break your unit tests. But if we're updating the > > minimum versions of dependencies every cycle to known good minimum versions, > > an l-c failure is going to be pretty rare, so maybe it's not worth the > > trouble of maintaining the l-c.txt and CI job. > > > > One other thing: if we do keep l-c, we need to have some guidance about > > what's actually supposed to be in there. (Or I need to RTFM.) I've noticed > > that as we've added new dependencies to cinder, we've included the > > dependency in l-c.txt, but not its indirect dependencies. I guess we should > > have been adding the indirect dependencies all along, too? (Spoiler alert: > > we haven't.) > > > > This email has gotten too long, so I will shut up now. > > > > cheers, > > brian > > > > > > > > Few of the ML thread around this discussion: > > > > > > - http://lists.openstack.org/pipermail/openstack-discuss/2020-December/019521.html > > > - http://lists.openstack.org/pipermail/openstack-discuss/2020-December/019390.html > > > > > > As Oslo and many other project dropping or already dropped it, we should decide it for all > > > other projects also otherwise it can be more changing than it is currently. > > > > > > We have not defined it in PTI or testing runtime so it is always up to projects if they still > > > want to keep it but we should decide a general recommendation here. > > > > > > -gmann > > > > > > > > > /requirements hat > > l-c was mainly promoted as a way to know when you are using a feature > that is not in an old release. The way we generally test is with newer > constraints, which don't test what we state we support (the range > between the lower bound in requirements.txt and upper-contraints). > > While I do think it's useful to know that the range of versions of a > library needs to be updated... I understand that it may not be useful, > either because of the possible maintenance required by devs, the load on > the testing infrastructure generated by testing lower-constraints or > that downstream packagers do not use it. > > Search this for lower-constraints. > https://docs.openstack.org/project-team-guide/dependency-management.html > > Indirect dependencies in lower-constraints were not encouraged iirc, > both for maintenance reasons (lot of churn) and because 'hopefully' > downstream deps are doing the same thing and testing their deps for > changes they need. > > /downstream packager hat > > I do not look at lower-constraints, but I do look at lower-bounds in the > requirements.txt file (from which lower-constraints are generated). I > look for updates in the lower-bounds to know if a library that was > already packaged needed updating, though I do try and target the version > mentioned in upper-constraints.txt when updating. More and more I've > just made sure that the entire dependency tree for openstack matches > what is packaged. Even then though, if the minimum is not updated then > this pushes it down on users. I do not have downstream packager maintenance experience but in my local or deps resolver time I do look at the lower bound in requirements.txt The challenge with that will to keep req.txt lower bound up to date as our CI will be testing with u-c. -gmann > > /user (deployer) perspective > > Why does $PROJECT not work, I'm going to report it as a bug to $distro, > $deployment and $upstream. > > What they did was not update the version of pyroute2 (or something) > because $project didn't update the lower bound to require it. > > -- > Matthew Thode > From gmann at ghanshyammann.com Mon Jan 11 22:00:54 2021 From: gmann at ghanshyammann.com (Ghanshyam Mann) Date: Mon, 11 Jan 2021 16:00:54 -0600 Subject: [all][tc] Dropping lower-constraints testing from all projects In-Reply-To: References: <176d8da769b.b6edb13b874337.4809906168220534198@ghanshyammann.com> Message-ID: <176f3775a84.e963c2901078611.3413948910917368000@ghanshyammann.com> ---- On Fri, 08 Jan 2021 09:21:51 -0600 Brian Rosmaita wrote ---- > On 1/6/21 12:59 PM, Ghanshyam Mann wrote: > > Hello Everyone, > > > > You might have seen the discussion around dropping the lower constraints > > testing as it becomes more challenging than the current value of doing it. > > I think the TC needs to discuss this explicitly (at a meeting or two, > not just on the ML) and give the projects some guidance. I agree that > there's little point in maintaining the l-c if they're not actually > useful to anyone in their current state, but if their helpfulness (or > potential helpfulness) outweighs the maintenance burden, then we should > keep them. (How's that for a profound statement?) Yes, that is the plan. This ML thread is to get initial feedback and then discuss in meeting. I have added this to the next TC meeting on the 14th Jan agenda. - https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Agenda_Suggestions -gmann > > Maybe someone can point me to where I can RTFM to get a clearer picture, > but my admittedly vague idea of what the l-c are for is that it has > something to do with making packaging easier. If that's the case, it > would be good for the TC to reach out to some openstack > packagers/distributors to find outline how they use l-c (if at all) and > what changes could be done to make them actually useful, and then we can > re-assess the maintenance burden. > > This whole experience with the new pip resolver has been painful, I > think, because it hit all projects and all branches at once. My > experience, however, is that if I'd been updating the minimum versions > for all the cinder deliverables in their requirements.txt and l-c.txt > files every cycle to reflect a pip freeze at Milestone-3 it would have > been a lot easier. > > What do other projects do about this? In Cinder, we've just been > updating the requirements on-demand, not proactively, and as a result > for some dependencies we claimed that foo>=0.9.0 is OK -- but except for > unit tests in the l-c job, cinder deliverables haven't been using > anything other than foo>=16.0 since rocky. So in master, I took > advantage of having to revise requirements and l-c to make some major > jumps in minimum versions. And I'm thinking of doing a pip-freeze > requirements.txt minimum version update from now on at M-3 each cycle, > which will force me to make an l-c.txt update too. (Maybe I was > supposed to be doing that all along? Or maybe it's a bad idea? I could > use some guidance here.) > > It would be good for the l-c to reflect reality, but on the other hand, > updating the minimum versions in requirements.txt (and hence in l-c) too > aggressively probably won't help packagers at all. (Or maybe it will, I > don't know.) On the other hand, having the l-c is useful from the > standpoint of letting you know when your minimum acceptable version in > requirements.txt will break your unit tests. But if we're updating the > minimum versions of dependencies every cycle to known good minimum > versions, an l-c failure is going to be pretty rare, so maybe it's not > worth the trouble of maintaining the l-c.txt and CI job. > > One other thing: if we do keep l-c, we need to have some guidance about > what's actually supposed to be in there. (Or I need to RTFM.) I've > noticed that as we've added new dependencies to cinder, we've included > the dependency in l-c.txt, but not its indirect dependencies. I guess > we should have been adding the indirect dependencies all along, too? > (Spoiler alert: we haven't.) > > This email has gotten too long, so I will shut up now. > > cheers, > brian > > > > > Few of the ML thread around this discussion: > > > > - http://lists.openstack.org/pipermail/openstack-discuss/2020-December/019521.html > > - http://lists.openstack.org/pipermail/openstack-discuss/2020-December/019390.html > > > > As Oslo and many other project dropping or already dropped it, we should decide it for all > > other projects also otherwise it can be more changing than it is currently. > > > > We have not defined it in PTI or testing runtime so it is always up to projects if they still > > want to keep it but we should decide a general recommendation here. > > > > -gmann > > > > > From gmann at ghanshyammann.com Mon Jan 11 22:02:07 2021 From: gmann at ghanshyammann.com (Ghanshyam Mann) Date: Mon, 11 Jan 2021 16:02:07 -0600 Subject: [oslo][TC] Dropping lower-constraints testing In-Reply-To: References: <5755ea96-5cc7-2756-970e-dcbf5184b2a2@debian.org> Message-ID: <176f37878b6.d5a4f51b1078642.5636035119235474321@ghanshyammann.com> ---- On Mon, 11 Jan 2021 11:57:37 -0600 Herve Beraud wrote ---- > Le lun. 11 janv. 2021 à 18:11, Ben Nemec a écrit : > > > On 1/6/21 2:58 PM, Thomas Goirand wrote: > > On 12/18/20 3:54 PM, hberaud wrote: > >> In a first time I tried to fix our gates by fixing our lower-constraints > >> project by project but with around ~36 projects to maintain this is a > >> painful task, especially due to nested oslo layers inside oslo > >> himself... I saw the face of the hell of dependencies. > > > > Welcome to my world! > > > >> Thoughts? > > > > Couldn't someone address the dependency loops in Oslo? It's IMO anyway > > needed. > > AFAIK nobody is volunteering on our side, feel free to send patches to fix them.... > > Which libraries have circular dependencies? It's something we've > intentionally avoided, so if they exist I would consider it a bug. > > Concerning myself, I meant that by example to fix oslo.messaging its LC you should first address those of oslo.log and etc... > This isn't a circular dependency but an order to follow in our patches to fix all our L.C. > Also I didn't notice "real" circular dependencies, in other words I only noticed an order to apply to fix all the L.C, but over 36 projects that order is a bit annoying, that's all. I agree. I have added this topic to the next TC meeting on the 14th Jan agenda to get consensus for all the projects. - https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Agenda_Suggestions -gmann > > > > > Just my 2 cents, not sure if that helps... > > Cheers, > > > > Thomas Goirand (zigo) > > > > > > -- > Hervé BeraudSenior Software Engineer at Red Hatirc: hberaudhttps://github.com/4383/https://twitter.com/4383hberaud > -----BEGIN PGP SIGNATURE----- > > wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ > Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ > RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP > F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G > 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g > glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw > m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ > hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 > qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y > F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 > B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O > v6rDpkeNksZ9fFSyoY2o > =ECSj > -----END PGP SIGNATURE----- > > From johnsomor at gmail.com Mon Jan 11 23:43:37 2021 From: johnsomor at gmail.com (Michael Johnson) Date: Mon, 11 Jan 2021 15:43:37 -0800 Subject: [octavia] problems configuring octavia In-Reply-To: References: Message-ID: Hi Daniel, It might be helpful to use the [charms] in the subject as I think everything you mentioned here is related to the Ubuntu/juju/charms deployment tooling and not the Octavia project. I don't have any experience with doing a deployment with charms, so I can't be of much help there. That said, Octavia does not rely on DNS for any of its operations. This includes the lb-mgmt-net and for the load balancing elements. So, the lack of access to BIND for Octavia is not a problem. Michael On Fri, Jan 8, 2021 at 8:16 AM Daniel Macdonald wrote: > Happy new year Openstack users and devs! > > I have been trying on and off for several months to get octavia working > but I have yet to have it successfully create a loadbalancer. I have > deployed OS bionic-train using the Charms telemetry bundle with the octavia > overlay. Openstack is working for creating regular instances but I get > various errors when trying to create a loadbalancer. > > The first issue I feel I should mention is that I am using bind running on > our MAAS controller as a DNS server. juju doesn't work if I enable IPv6 > under bind yet the octavia charm defaults to using IPv6 for its management > network so I have tried creating a IPv4 management network but I'm still > having problems. For more details on that please see the comments of this > bug report: > > https://bugs.launchpad.net/charm-octavia/+bug/1897418 > Bug #1897418 “feature request: have option to use ipv4 when sett...” : > Bugs : OpenStack Octavia Charm > > By default, Octavia charm uses ipv6 for its lb-mgmt-subnet.[1] It would be > nice to have the option to choose an ipv4 network from the start instead of > deleting the ipv6 network and recreating the ipv4 subnet. Implementation - > possible configuration option parameter when deploying. [1] > https://opendev.org/openstack/charm-octavia/src/branch/master/src/lib/charm/openstack/api_crud.py#L560 > bugs.launchpad.net > > Another notable issue I have is that after installing the charms telemetry > bundle I have 2 projects call services. How do I know which is the correct > one to use for Octavia? > > > Is this following document going to be the best guide for me to follow to > complete the final steps required to get Octavia (under Train) working: > > > https://docs.openstack.org/octavia/latest/install/install-ubuntu.html#install-and-configure-components > OpenStack Docs: Install and configure for Ubuntu > > Install and configure for Ubuntu¶. This section describes how to install > and configure the Load-balancer service for Ubuntu 18.04 (LTS). > docs.openstack.org > > I'm hoping someone has already written an easy to follow guide to using > Octavia with an IPv4 management network using the Charms bundle to do most > of the installation work? > > Thanks > > > > > [image: University of Salford] > *DANIEL MACDONALD* > Specialist Technical Demonstrator > School of Computing, Science & Engineering > Room 145, Newton Building, University of Salford, Manchester M5 4WT > T: +44(0) 0161 295 5242 > D.R.MacDonald at salford.ac.uk > > */ *www.salford.ac.uk > > [image: CSE] > -------------- next part -------------- An HTML attachment was scrubbed... URL: From araragi222 at gmail.com Tue Jan 12 01:18:20 2021 From: araragi222 at gmail.com (=?UTF-8?B?5ZGC6Imv?=) Date: Tue, 12 Jan 2021 10:18:20 +0900 Subject: [tosca-parser][tacker] May I ask to push review process of patch 747516 : Support "Implementation" definition as Artifact Name Message-ID: Hi Bob, This is Liang from tacker team, in our patch: Implement SOL001 features to MgmtDriver (Ib4ad3eb9) · Gerrit Code Review (opendev.org) , we tried to implement in order to allow user use their script by defining 'interface' in vnfd file: …/vnflcm_driver.py · Gerrit Code Review (opendev.org) in the function above, changes in Support "Implementation" definition as Artifact Name (I192d3649) · Gerrit Code Review (opendev.org) , is needed for our implementation, may I ask you to help us push review for an early merge of this patch, appreciate for that! Best regards Liang Lu -------------- next part -------------- An HTML attachment was scrubbed... URL: From ramishra at redhat.com Tue Jan 12 07:40:45 2021 From: ramishra at redhat.com (Rabi Mishra) Date: Tue, 12 Jan 2021 13:10:45 +0530 Subject: [Heat][tripleo] move os-refresh-config, os-collect-config, tripleo-ipsec to 'release-management': none In-Reply-To: References: Message-ID: On Mon, Jan 11, 2021 at 8:01 PM James Slagle wrote: > > > On Mon, Jan 11, 2021 at 7:04 AM Marios Andreou wrote: > >> For the os-refresh/collect-config I suspect the answer is NO - at least, >> we aren't using these any more in the 'normal' tripleo deployment for a >> good while now, since we switched to config download by default. We haven't >> even created an ussuri branch for these [3] and no one has shouted about >> that (or at least not loud enough I haven't heard anything). >> > > TripleO doesn't use them, but I think Heat still does for the support of > SoftwareDeployment/StructuredDeployment. I've added [Heat] to the subject > tags. It is as least still documented: > > > https://docs.openstack.org/heat/latest/template_guide/software_deployment.html#software-deployment-resources > > which shows using the os-*-config elements from tripleo-image-elements to > build an image with diskimage-builder. > > Yeah, ideally os-collect-config/os-refresh-config should now be owned by heat team along with heat-agents (cycle-with-intermediary), as long as software deployments are supported by heat (though there were some discussions to deprecate/drop it some time back). > However, that doesn't mean we need to create stable branches or releases > for these repos. The elements support installing from source, and RDO is > packaging off of master it seems. > > -- > -- James Slagle > -- > -- Regards, Rabi Mishra -------------- next part -------------- An HTML attachment was scrubbed... URL: From zhangbailin at inspur.com Tue Jan 12 08:45:10 2021 From: zhangbailin at inspur.com (=?gb2312?B?QnJpbiBaaGFuZyjVxbDZwdYp?=) Date: Tue, 12 Jan 2021 08:45:10 +0000 Subject: =?gb2312?B?tPC4tDogW2FsbF1JbnRyb2R1Y3Rpb24gdG8gdmVudXMgd2hpY2ggaXMgdGhl?= =?gb2312?B?IHByb2plY3Qgb2YgbG9nIG1hbmFnZW1lbnQgYW5kIGhhcyBiZWVuIGNvbnRy?= =?gb2312?Q?ibuted_to_the_OpenStack_community?= In-Reply-To: References: Message-ID: <4220f2e3ab1641b493a3c0e8fb83e510@inspur.com> >-----邮件原件----- >发件人: Thierry Carrez [mailto:thierry at openstack.org] >发送时间: 2021年1月11日 21:12 >收件人: openstack-discuss at lists.openstack.org >主题: Re: [all]Introduction to venus which is the project of log management and has been contributed to the OpenStack community >Liye Pang(逄立业) wrote: >> Hello everyone, after feedback from a large number of operations and >> maintenance personnel in InCloud OpenStack, we developed the log >> management project “Venus” for the OpenStack projects [...] > OpenStack-aware centralized log management sounds very interesting to me... > If others are interested in collaborating on producing that component, I personally think it would be a great fit for the > "operations tooling" > section of the OpenStack Map[1]. Yes, after Inspur did a 1,000-nodes OpenStack single-cluster large-scale test, I was more convinced of the benefits Venus can bring to operation and maintenance. By Venus, we can quickly locate and find problems with the OpenStack platform, which can bring great convenience to operation and maintenance. https://mp.weixin.qq.com/s/RSrjjZjVFn086StNLV1Ivg This is the article of 1000-nodes test, but it's wrote by Chinese, don't worry ^^, we will publish the English article in future. This is the demo for Venus, hope that can help you to know what it can be done: https://youtu.be/mE2MoEx3awM> https://youtu.be/mE2MoEx3awM > [1] https://www.openstack.org/software/ > -- > Thierry Carrez (ttx) Original ML: http://lists.openstack.org/pipermail/openstack-discuss/2021-January/019748.html brinzhang From radoslaw.piliszek at gmail.com Tue Jan 12 09:56:25 2021 From: radoslaw.piliszek at gmail.com (=?UTF-8?Q?Rados=C5=82aw_Piliszek?=) Date: Tue, 12 Jan 2021 10:56:25 +0100 Subject: [masakari] Masakari Team Meeting - the schedule Message-ID: Hello, Folks! I have realised the Masakari Team Meeting is to run on even weeks [1]. However, anyone who created the meeting record in their calendar (including me) has likely gotten the meeting schedule in odd weeks this year (because last year finished with an odd week and obviously numbering also starts on odd: the 1). So I have run the first meeting this year the previous week but someone came for the meeting this week. :-) According to the "new wrong" schedule, the next meeting would be on Jan 19, but according to the "proper" one it would be on Jan 26. I am available both weeks the same so can run either term (or both as well, why not). The question is whether we don't want to simply move to the weekly meeting schedule. We usually don't have much to discuss but it might be less confusing and a better way to form a habit if we met every week. Please let me know your thoughts. [1] http://eavesdrop.openstack.org/#Masakari_Team_Meeting -yoctozepto From marios at redhat.com Tue Jan 12 10:07:14 2021 From: marios at redhat.com (Marios Andreou) Date: Tue, 12 Jan 2021 12:07:14 +0200 Subject: [tripleo] move os-refresh-config, os-collect-config, tripleo-ipsec to 'release-management': none In-Reply-To: References: Message-ID: On Mon, Jan 11, 2021 at 5:07 PM Herve Beraud wrote: > > > Le lun. 11 janv. 2021 à 15:27, Alex Schultz a > écrit : > >> On Mon, Jan 11, 2021 at 4:59 AM Marios Andreou wrote: >> > >> > Hi TripleO, >> > >> > you may have seen the thread started by Herve at [1] around the >> deadline for making a victoria release for os-refresh-config, >> os-collect-config and tripleo-ipsec. >> > >> > This message is to ask if anyone is still using these? In particular >> would anyone mind if we stopped making tagged releases, as discussed at >> [2]. Would someone mind if there was no stable/victoria branch for these >> repos? >> > >> > For the os-refresh/collect-config I suspect the answer is NO - at >> least, we aren't using these any more in the 'normal' tripleo deployment >> for a good while now, since we switched to config download by default. We >> haven't even created an ussuri branch for these [3] and no one has shouted >> about that (or at least not loud enough I haven't heard anything). >> >> Maybe switch to independent? That being said as James points out they >> are still used by Heat so maybe the ownership should be moved. >> > > I agree, moving them to the independent model could be a solution, in this > case the patch could be adapted to reflect that choice and we could ignore > these repos from victoria deadline point of view. > > Concerning the "ownership" side of the question this is more an internal > discussion between teams and eventually the TC, I don't think that that > will impact us from a release management POV. > > ack yes this makes sense thanks James, Alex, Herve and Rabi for your comments First I'll refactor https://review.opendev.org/c/openstack/releases/+/769915 to instead move them to independent (and i'll also include os-apply-config). Then I'll reach out to Heat PTL to see what they think about the transfer of ownership, thanks all > >> > >> > For tripleo-ipsec it *looks* like we're still using it in the sense >> that we carry the template and pass the parameters in >> tripleo-heat-templates [4]. However we aren't running that in any CI job as >> far as I can see, and we haven't created any branches there since Rocky. So >> is anyone using tripleo-ipsec? >> > >> >> I think tripleo-ipsec is no longer needed as we now have proper >> tls-everywhere support. We might want to revisit this and >> deprecate/remove it. >> >> > Depending on the answers here and as discussed at [2] I will move to >> make these as unreleased (release-management: none in openstack/governance >> reference/projects.yaml) and remove the release file altogether. >> > >> > For now however and given the deadline of this week for a victoria >> release I am proposing that we move forward with [2] and cut the victoria >> branch for these. >> > >> > thanks for reading and please speak up if any of the above are >> important to you! >> > >> > thanks, marios >> > >> > [1] >> http://lists.openstack.org/pipermail/openstack-discuss/2021-January/019730.html >> > [2] >> https://review.opendev.org/c/openstack/releases/+/769915/1/deliverables/victoria/os-refresh-config.yaml >> > [3] https://pastebin.com/raw/KJ0JxKPx >> > [4] >> https://opendev.org/openstack/tripleo-heat-templates/src/commit/9fd709019fdd36d4c4821b2486e7151abf84bc3f/deployment/ipsec/ipsec-baremetal-ansible.yaml#L101-L106 >> > >> >> > > -- > Hervé Beraud > Senior Software Engineer at Red Hat > irc: hberaud > https://github.com/4383/ > https://twitter.com/4383hberaud > -----BEGIN PGP SIGNATURE----- > > wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ > Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ > RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP > F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G > 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g > glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw > m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ > hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 > qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y > F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 > B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O > v6rDpkeNksZ9fFSyoY2o > =ECSj > -----END PGP SIGNATURE----- > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark at stackhpc.com Tue Jan 12 10:18:52 2021 From: mark at stackhpc.com (Mark Goddard) Date: Tue, 12 Jan 2021 10:18:52 +0000 Subject: [kolla] Victoria releases available Message-ID: Hi, I'm pleased to announce the availability of the first Victoria releases for all Kolla deliverables: * kolla 11.0.0 (https://docs.openstack.org/releasenotes/kolla/victoria.html#relnotes-11-0-0-stable-victoria) * kolla-ansible 11.0.0 (https://docs.openstack.org/releasenotes/kolla-ansible/victoria.html#relnotes-11-0-0-stable-victoria) * kayobe 9.0.0 (https://docs.openstack.org/releasenotes/kayobe/victoria.html#relnotes-9-0-0-stable-victoria) Thanks to everyone who contributed to these releases. And now onto Wallaby! Thanks, Mark From ionut at fleio.com Tue Jan 12 11:17:37 2021 From: ionut at fleio.com (Ionut Biru) Date: Tue, 12 Jan 2021 13:17:37 +0200 Subject: [magnum][api] Error system library fopen too many open files with magnum-auto-healer In-Reply-To: References: <185a9715-4667-9610-0048-5434e6e2cd4e@catalyst.net.nz> Message-ID: Hi Erik, Here it is: https://paste.xinu.at/LgH8dT/ On Mon, Jan 11, 2021 at 10:45 PM Erik Olof Gunnar Andersson < eandersson at blizzard.com> wrote: > Thanks I added it to the commit. > > > > Could you share your uwsgi config as well. > > > > Best Regards, Erik Olof Gunnar Andersson > > Technical Lead, Senior Cloud Engineer > > > > *From:* Ionut Biru > *Sent:* Tuesday, January 5, 2021 1:51 AM > *To:* Erik Olof Gunnar Andersson > *Cc:* Spyros Trigazis ; feilong < > feilong at catalyst.net.nz>; openstack-discuss < > openstack-discuss at lists.openstack.org> > *Subject:* Re: [magnum][api] Error system library fopen too many open > files with magnum-auto-healer > > > > Hi, > > > > Here is my config. maybe something is fishy. > > > > I did have around 300 messages in the queue in notification.info > > and notification.err and I purged them. > > > > https://paste.xinu.at/woMt/ > > > > > > > > > On Tue, Jan 5, 2021 at 11:23 AM Erik Olof Gunnar Andersson < > eandersson at blizzard.com> wrote: > > Yea - tested locally as well and wasn't able to reproduce it either. I > changed the health service job to run every second and maxed out at about > 42 connections to RabbitMQ with two conductor workers. > > /etc/magnum/magnun.conf > > [conductor] > > workers = 2 > > > ------------------------------ > > *From:* Spyros Trigazis > *Sent:* Tuesday, January 5, 2021 12:59 AM > *To:* Ionut Biru > *Cc:* Erik Olof Gunnar Andersson ; feilong < > feilong at catalyst.net.nz>; openstack-discuss < > openstack-discuss at lists.openstack.org> > *Subject:* Re: [magnum][api] Error system library fopen too many open > files with magnum-auto-healer > > > > > > > > On Tue, Jan 5, 2021 at 9:36 AM Ionut Biru wrote: > > Hi, > > > I tried with process=1 and it reached 1016 connections to rabbitmq. > > lsof > > https://paste.xinu.at/jGg/ > > > > > i think it goes into error when it reaches 1024 file descriptors. > > > > I'm out of ideas of how to resolve this. I only have 3 clusters available > and it's kinda weird and It doesn't scale. > > > > No issues here with 100s of clusters. Not sure what doesn't scale. > > > > * Maybe your rabbit is flooded with notifications that are not consumed? > > * You can use way more than 1024 file descriptors, maybe 2^10? > > > > Spyros > > > > On Mon, Jan 4, 2021 at 9:53 PM Erik Olof Gunnar Andersson < > eandersson at blizzard.com> wrote: > > Sure looks like RabbitMQ. How many workers do have you configured? > > > > Could you try to changing the uwsgi configuration to workers=1 (or > processes=1) and then see if it goes beyond 30 connections to amqp. > > > > *From:* Ionut Biru > *Sent:* Monday, January 4, 2021 4:07 AM > *To:* Erik Olof Gunnar Andersson > *Cc:* feilong ; openstack-discuss < > openstack-discuss at lists.openstack.org> > *Subject:* Re: [magnum][api] Error system library fopen too many open > files with magnum-auto-healer > > > > Hi Erik, > > > > Here is lsof of one uwsgi api. https://paste.xinu.at/5YUWf/ > > > > > I have kubernetes 12.0.1 installed in env. > > > > > > On Sun, Jan 3, 2021 at 3:06 AM Erik Olof Gunnar Andersson < > eandersson at blizzard.com> wrote: > > Maybe something similar to this? > https://github.com/kubernetes-client/python/issues/1158 > > > What does lsof say? > > > > > > > > > -- > > Ionut Biru - https://fleio.com > > > > > > -- > > Ionut Biru - https://fleio.com > > -- Ionut Biru - https://fleio.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From pangliye at inspur.com Tue Jan 12 11:40:39 2021 From: pangliye at inspur.com (=?utf-8?B?TGl5ZSBQYW5nKOmAhOeri+S4mik=?=) Date: Tue, 12 Jan 2021 11:40:39 +0000 Subject: =?utf-8?B?562U5aSNOiBbYWxsXUludHJvZHVjdGlvbiB0byB2ZW51cyB3aGljaCBpcyB0?= =?utf-8?B?aGUgcHJvamVjdCBvZiBsb2cgbWFuYWdlbWVudCBhbmQgaGFzIGJlZW4gY29u?= =?utf-8?Q?tributed_to_the_OpenStack_community?= In-Reply-To: References: Message-ID: <59d0d1ee43324038af46d658a3ca243c@inspur.com> On Mon, 11 Jan 2021 at 13:13, Thierry Carrez wrote: > > Liye Pang(逄立业) wrote: > >> Hello everyone, after feedback from a large number of operations and >> > maintenance personnel in InCloud OpenStack, we developed the log > >> management project “Venus” for the OpenStack projects [...] >> OpenStack-aware centralized log management sounds very interesting to me... >> >> If others are interested in collaborating on producing that component, >> I personally think it would be a great fit for the "operations tooling" >> section of the OpenStack Map[1]. >> >> [1] https://www.openstack.org/software/ > >Let's not forget that Monasca has a log aggregation API [1] > > [1] https://wiki.openstack.org/wiki/Monasca/Logging The major work of monasca project about logs is indexing logs for users to retrieve. The venus project is based on indexed data and provides more functions, such as correlation analysis, error alarms,problem location , etc. >> > >-- > >Thierry Carrez (ttx) >> -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3786 bytes Desc: not available URL: From marios at redhat.com Tue Jan 12 12:41:14 2021 From: marios at redhat.com (Marios Andreou) Date: Tue, 12 Jan 2021 14:41:14 +0200 Subject: [heat][tripleo] os-apply-config os-refresh-config os-collect-config project governance Message-ID: Hello Heat team o/ as discussed in the thread at [1] TripleO is no longer using os-collect-config, os-refresh-config and os-apply-config as part of the OpenStack deployment. As such we are considering moving these repos to the independent release model. However as pointed out in [1] it seems that Heat is still using these - documented at [2]. Is the Heat community interested in taking over the ownership of these? To be clear what the proposal here is, I posted [3] - i.e. move these projects under the Heat governance. Thanks for your time, thoughts and comments on this, either here or in [3]. If you are NOT interested in owning these then we will likely move them to independent, or possibly even unmaintained/eol (in due course). regards, marios [1] http://lists.openstack.org/pipermail/openstack-discuss/2021-January/019751.html [2] https://docs.openstack.org/heat/latest/template_guide/software_deployment.html#custom-image-script [3] https://review.opendev.org/c/openstack/governance/+/770285 -------------- next part -------------- An HTML attachment was scrubbed... URL: From marios at redhat.com Tue Jan 12 12:43:30 2021 From: marios at redhat.com (Marios Andreou) Date: Tue, 12 Jan 2021 14:43:30 +0200 Subject: [tripleo] move os-refresh-config, os-collect-config, tripleo-ipsec to 'release-management': none In-Reply-To: References: Message-ID: On Tue, Jan 12, 2021 at 12:07 PM Marios Andreou wrote: > > > On Mon, Jan 11, 2021 at 5:07 PM Herve Beraud wrote: > >> >> >> Le lun. 11 janv. 2021 à 15:27, Alex Schultz a >> écrit : >> >>> On Mon, Jan 11, 2021 at 4:59 AM Marios Andreou >>> wrote: >>> > >>> > Hi TripleO, >>> > >>> > you may have seen the thread started by Herve at [1] around the >>> deadline for making a victoria release for os-refresh-config, >>> os-collect-config and tripleo-ipsec. >>> > >>> > This message is to ask if anyone is still using these? In particular >>> would anyone mind if we stopped making tagged releases, as discussed at >>> [2]. Would someone mind if there was no stable/victoria branch for these >>> repos? >>> > >>> > For the os-refresh/collect-config I suspect the answer is NO - at >>> least, we aren't using these any more in the 'normal' tripleo deployment >>> for a good while now, since we switched to config download by default. We >>> haven't even created an ussuri branch for these [3] and no one has shouted >>> about that (or at least not loud enough I haven't heard anything). >>> >>> Maybe switch to independent? That being said as James points out they >>> are still used by Heat so maybe the ownership should be moved. >>> >> >> I agree, moving them to the independent model could be a solution, in >> this case the patch could be adapted to reflect that choice and we could >> ignore these repos from victoria deadline point of view. >> >> Concerning the "ownership" side of the question this is more an internal >> discussion between teams and eventually the TC, I don't think that that >> will impact us from a release management POV. >> >> > ack yes this makes sense thanks James, Alex, Herve and Rabi for your > comments > First I'll refactor > https://review.opendev.org/c/openstack/releases/+/769915 to instead move > them to independent (and i'll also include os-apply-config). Then I'll > reach out to Heat PTL to see what they think about the transfer of > ownership, > > thanks all > > me again ;) my apologies but I've spent some time staring at this and have changed my mind. IMO it is best if we go ahead and create the victoria bits for these right now whilst also moving forward on the proposed governance change. To be clear, I think we should merge [1] as is to create stable/victoria in time for the deadline. We already have a stable/victoria for os-apply-config and so let's be consistent and create it for os-refresh-config and os-collect-config too. I reached out to Heat with [2] and posted [3] to illustrate the proposal of moving the governance for these under Heat. If they want them then they can decide about moving to independent or not. Otherwise I will followup next week with a move to independent. [1] https://review.opendev.org/c/openstack/releases/+/769915 [2] http://lists.openstack.org/pipermail/openstack-discuss/2021-January/019777.html [3] https://review.opendev.org/c/openstack/governance/+/770285 > > >> >>> > >>> > For tripleo-ipsec it *looks* like we're still using it in the sense >>> that we carry the template and pass the parameters in >>> tripleo-heat-templates [4]. However we aren't running that in any CI job as >>> far as I can see, and we haven't created any branches there since Rocky. So >>> is anyone using tripleo-ipsec? >>> > >>> >>> I think tripleo-ipsec is no longer needed as we now have proper >>> tls-everywhere support. We might want to revisit this and >>> deprecate/remove it. >>> >>> > Depending on the answers here and as discussed at [2] I will move to >>> make these as unreleased (release-management: none in openstack/governance >>> reference/projects.yaml) and remove the release file altogether. >>> > >>> > For now however and given the deadline of this week for a victoria >>> release I am proposing that we move forward with [2] and cut the victoria >>> branch for these. >>> > >>> > thanks for reading and please speak up if any of the above are >>> important to you! >>> > >>> > thanks, marios >>> > >>> > [1] >>> http://lists.openstack.org/pipermail/openstack-discuss/2021-January/019730.html >>> > [2] >>> https://review.opendev.org/c/openstack/releases/+/769915/1/deliverables/victoria/os-refresh-config.yaml >>> > [3] https://pastebin.com/raw/KJ0JxKPx >>> > [4] >>> https://opendev.org/openstack/tripleo-heat-templates/src/commit/9fd709019fdd36d4c4821b2486e7151abf84bc3f/deployment/ipsec/ipsec-baremetal-ansible.yaml#L101-L106 >>> > >>> >>> >> >> -- >> Hervé Beraud >> Senior Software Engineer at Red Hat >> irc: hberaud >> https://github.com/4383/ >> https://twitter.com/4383hberaud >> -----BEGIN PGP SIGNATURE----- >> >> wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ >> Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ >> RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP >> F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G >> 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g >> glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw >> m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ >> hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 >> qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y >> F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 >> B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O >> v6rDpkeNksZ9fFSyoY2o >> =ECSj >> -----END PGP SIGNATURE----- >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From hberaud at redhat.com Tue Jan 12 12:54:42 2021 From: hberaud at redhat.com (Herve Beraud) Date: Tue, 12 Jan 2021 13:54:42 +0100 Subject: [tripleo] move os-refresh-config, os-collect-config, tripleo-ipsec to 'release-management': none In-Reply-To: References: Message-ID: LGTM Le mar. 12 janv. 2021 à 13:43, Marios Andreou a écrit : > > > On Tue, Jan 12, 2021 at 12:07 PM Marios Andreou wrote: > >> >> >> On Mon, Jan 11, 2021 at 5:07 PM Herve Beraud wrote: >> >>> >>> >>> Le lun. 11 janv. 2021 à 15:27, Alex Schultz a >>> écrit : >>> >>>> On Mon, Jan 11, 2021 at 4:59 AM Marios Andreou >>>> wrote: >>>> > >>>> > Hi TripleO, >>>> > >>>> > you may have seen the thread started by Herve at [1] around the >>>> deadline for making a victoria release for os-refresh-config, >>>> os-collect-config and tripleo-ipsec. >>>> > >>>> > This message is to ask if anyone is still using these? In particular >>>> would anyone mind if we stopped making tagged releases, as discussed at >>>> [2]. Would someone mind if there was no stable/victoria branch for these >>>> repos? >>>> > >>>> > For the os-refresh/collect-config I suspect the answer is NO - at >>>> least, we aren't using these any more in the 'normal' tripleo deployment >>>> for a good while now, since we switched to config download by default. We >>>> haven't even created an ussuri branch for these [3] and no one has shouted >>>> about that (or at least not loud enough I haven't heard anything). >>>> >>>> Maybe switch to independent? That being said as James points out they >>>> are still used by Heat so maybe the ownership should be moved. >>>> >>> >>> I agree, moving them to the independent model could be a solution, in >>> this case the patch could be adapted to reflect that choice and we could >>> ignore these repos from victoria deadline point of view. >>> >>> Concerning the "ownership" side of the question this is more an internal >>> discussion between teams and eventually the TC, I don't think that that >>> will impact us from a release management POV. >>> >>> >> ack yes this makes sense thanks James, Alex, Herve and Rabi for your >> comments >> First I'll refactor >> https://review.opendev.org/c/openstack/releases/+/769915 to instead move >> them to independent (and i'll also include os-apply-config). Then I'll >> reach out to Heat PTL to see what they think about the transfer of >> ownership, >> >> thanks all >> >> > > me again ;) > > my apologies but I've spent some time staring at this and have changed my > mind. IMO it is best if we go ahead and create the victoria bits for these > right now whilst also moving forward on the proposed governance change. > > To be clear, I think we should merge [1] as is to create stable/victoria > in time for the deadline. We already have a stable/victoria for > os-apply-config and so let's be consistent and create it for > os-refresh-config and os-collect-config too. > > I reached out to Heat with [2] and posted [3] to illustrate the proposal > of moving the governance for these under Heat. If they want them then they > can decide about moving to independent or not. > > Otherwise I will followup next week with a move to independent. > > [1] https://review.opendev.org/c/openstack/releases/+/769915 > [2] > http://lists.openstack.org/pipermail/openstack-discuss/2021-January/019777.html > [3] https://review.opendev.org/c/openstack/governance/+/770285 > > > > >> >> >>> >>>> > >>>> > For tripleo-ipsec it *looks* like we're still using it in the sense >>>> that we carry the template and pass the parameters in >>>> tripleo-heat-templates [4]. However we aren't running that in any CI job as >>>> far as I can see, and we haven't created any branches there since Rocky. So >>>> is anyone using tripleo-ipsec? >>>> > >>>> >>>> I think tripleo-ipsec is no longer needed as we now have proper >>>> tls-everywhere support. We might want to revisit this and >>>> deprecate/remove it. >>>> >>>> > Depending on the answers here and as discussed at [2] I will move to >>>> make these as unreleased (release-management: none in openstack/governance >>>> reference/projects.yaml) and remove the release file altogether. >>>> > >>>> > For now however and given the deadline of this week for a victoria >>>> release I am proposing that we move forward with [2] and cut the victoria >>>> branch for these. >>>> > >>>> > thanks for reading and please speak up if any of the above are >>>> important to you! >>>> > >>>> > thanks, marios >>>> > >>>> > [1] >>>> http://lists.openstack.org/pipermail/openstack-discuss/2021-January/019730.html >>>> > [2] >>>> https://review.opendev.org/c/openstack/releases/+/769915/1/deliverables/victoria/os-refresh-config.yaml >>>> > [3] https://pastebin.com/raw/KJ0JxKPx >>>> > [4] >>>> https://opendev.org/openstack/tripleo-heat-templates/src/commit/9fd709019fdd36d4c4821b2486e7151abf84bc3f/deployment/ipsec/ipsec-baremetal-ansible.yaml#L101-L106 >>>> > >>>> >>>> >>> >>> -- >>> Hervé Beraud >>> Senior Software Engineer at Red Hat >>> irc: hberaud >>> https://github.com/4383/ >>> https://twitter.com/4383hberaud >>> -----BEGIN PGP SIGNATURE----- >>> >>> wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ >>> Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ >>> RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP >>> F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G >>> 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g >>> glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw >>> m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ >>> hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 >>> qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y >>> F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 >>> B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O >>> v6rDpkeNksZ9fFSyoY2o >>> =ECSj >>> -----END PGP SIGNATURE----- >>> >>> -- Hervé Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/ https://twitter.com/4383hberaud -----BEGIN PGP SIGNATURE----- wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O v6rDpkeNksZ9fFSyoY2o =ECSj -----END PGP SIGNATURE----- -------------- next part -------------- An HTML attachment was scrubbed... URL: From james.slagle at gmail.com Tue Jan 12 13:23:10 2021 From: james.slagle at gmail.com (James Slagle) Date: Tue, 12 Jan 2021 08:23:10 -0500 Subject: [heat][tripleo] os-apply-config os-refresh-config os-collect-config project governance In-Reply-To: References: Message-ID: On Tue, Jan 12, 2021 at 7:47 AM Marios Andreou wrote: > Hello Heat team o/ > > as discussed in the thread at [1] TripleO is no longer using > os-collect-config, os-refresh-config and os-apply-config as part of the > OpenStack deployment. As such we are considering moving these repos to the > independent release model. > > However as pointed out in [1] it seems that Heat is still using these - > documented at [2]. Is the Heat community interested in taking over the > ownership of these? To be clear what the proposal here is, I posted [3] - > i.e. move these projects under the Heat governance. > > Thanks for your time, thoughts and comments on this, either here or in > [3]. If you are NOT interested in owning these then we will likely move > them to independent, or possibly even unmaintained/eol (in due course). > I realized a possible wrinkle with moving these to Heat governance. TripleO still relies on the stable/train branches given these projects are still used in train, and there exists a possibility that TripleO cores may need to backport patch(es) to the train branch in these projects. -- -- James Slagle -- -------------- next part -------------- An HTML attachment was scrubbed... URL: From amotoki at gmail.com Tue Jan 12 13:50:49 2021 From: amotoki at gmail.com (Akihiro Motoki) Date: Tue, 12 Jan 2021 22:50:49 +0900 Subject: [neutron] bug deputy report (week of Jan 4) Message-ID: Hi, This is a summary of neutron bugs last week. Sorry for late. It was generally a quiet week. Thanks, Akihiro # Undecided https://bugs.launchpad.net/neutron/+bug/1910474 some times rally test would fail at network scenario due to mysql data base error Undecided It was reported against the queens release and the detail log mentioned in the bug is not available. It looks related to a nested transaction in percona but we are waiting for more information from the reporter. # Unassigned gate failures https://bugs.launchpad.net/neutron/+bug/1910691 In "test_dvr_router_lifecycle_ha_with_snat_with_fips", the HA proxy PID file is not removed reported by ralonsoh. Hope someone interested in it can look into it. # Assigned or In Progress https://bugs.launchpad.net/neutron/+bug/1910213 Live migration doesn't work with OVN and DPDK assigned to jlibosva https://bugs.launchpad.net/neutron/+bug/1910717 "test_set_igmp_snooping_flood" fails because "ports_other_config" is None ralonsoh is working on the fix https://bugs.launchpad.net/bugs/1910334 [OVN]after create port forwarding, floating ip status is not running In Progress, a fix is under review From hberaud at redhat.com Tue Jan 12 14:09:49 2021 From: hberaud at redhat.com (Herve Beraud) Date: Tue, 12 Jan 2021 15:09:49 +0100 Subject: [heat][tripleo] os-apply-config os-refresh-config os-collect-config project governance In-Reply-To: References: Message-ID: Le mar. 12 janv. 2021 à 14:26, James Slagle a écrit : > > > On Tue, Jan 12, 2021 at 7:47 AM Marios Andreou wrote: > >> Hello Heat team o/ >> >> as discussed in the thread at [1] TripleO is no longer using >> os-collect-config, os-refresh-config and os-apply-config as part of the >> OpenStack deployment. As such we are considering moving these repos to the >> independent release model. >> >> However as pointed out in [1] it seems that Heat is still using these - >> documented at [2]. Is the Heat community interested in taking over the >> ownership of these? To be clear what the proposal here is, I posted [3] - >> i.e. move these projects under the Heat governance. >> >> Thanks for your time, thoughts and comments on this, either here or in >> [3]. If you are NOT interested in owning these then we will likely move >> them to independent, or possibly even unmaintained/eol (in due course). >> > > I realized a possible wrinkle with moving these to Heat governance. > TripleO still relies on the stable/train branches given these projects are > still used in train, and there exists a possibility that TripleO cores may > need to backport patch(es) to the train branch in these projects. > Maybe adding some tripleo cores as stable maintainers could help the both teams to converge, thoughts? Heat could be more the focused on the current series and tripleo cores could propose fixes and lead backports to stable branches. > -- > -- James Slagle > -- > -- Hervé Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/ https://twitter.com/4383hberaud -----BEGIN PGP SIGNATURE----- wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O v6rDpkeNksZ9fFSyoY2o =ECSj -----END PGP SIGNATURE----- -------------- next part -------------- An HTML attachment was scrubbed... URL: From ramishra at redhat.com Tue Jan 12 14:32:00 2021 From: ramishra at redhat.com (Rabi Mishra) Date: Tue, 12 Jan 2021 20:02:00 +0530 Subject: [heat][tripleo] os-apply-config os-refresh-config os-collect-config project governance In-Reply-To: References: Message-ID: On Tue, Jan 12, 2021 at 6:58 PM James Slagle wrote: > > > On Tue, Jan 12, 2021 at 7:47 AM Marios Andreou wrote: > >> Hello Heat team o/ >> >> as discussed in the thread at [1] TripleO is no longer using >> os-collect-config, os-refresh-config and os-apply-config as part of the >> OpenStack deployment. As such we are considering moving these repos to the >> independent release model. >> >> However as pointed out in [1] it seems that Heat is still using these - >> documented at [2]. Is the Heat community interested in taking over the >> ownership of these? To be clear what the proposal here is, I posted [3] - >> i.e. move these projects under the Heat governance. >> >> Thanks for your time, thoughts and comments on this, either here or in >> [3]. If you are NOT interested in owning these then we will likely move >> them to independent, or possibly even unmaintained/eol (in due course). >> > > I realized a possible wrinkle with moving these to Heat governance. > TripleO still relies on the stable/train branches given these projects are > still used in train, and there exists a possibility that TripleO cores may > need to backport patch(es) to the train branch in these projects. > I thought we switched to config-download by default from stable/rocky and disabled os-collect-config[1]. Not sure if anyone uses it beyond that with TripleO. Looking at the number of functional changes backported to stable/queens (AFICS only 3 of them)[2], probably it won't be a major bottleneck, assuming the heat community wants to own it. [1] https://review.opendev.org/plugins/gitiles/openstack/tripleo-puppet-elements/+/eaebed2ab92c65a1dce55a1d1945bdc47c1e5022 [2] https://bit.ly/3qeTqX2 > > -- > -- James Slagle > -- > -- Regards, Rabi Mishra -------------- next part -------------- An HTML attachment was scrubbed... URL: From tzumainn at redhat.com Tue Jan 12 14:42:51 2021 From: tzumainn at redhat.com (Tzu-Mainn Chen) Date: Tue, 12 Jan 2021 09:42:51 -0500 Subject: [ironic] question regarding attributes required for a non-admin to boot from volume Message-ID: Hi, I've been looking into what it would take to allow non-admins to boot from volume. It looks like they'd need to update a node's storage_interface; and if you'd like to boot from an iSCSI volume, then you also need to update a node's capabilities property. Are these fields that we want non-admins to be able to update? If not, is there an alternative that might be possible? Thanks, Tzu-Mainn Chen -------------- next part -------------- An HTML attachment was scrubbed... URL: From tpb at dyncloud.net Tue Jan 12 14:58:52 2021 From: tpb at dyncloud.net (Tom Barron) Date: Tue, 12 Jan 2021 09:58:52 -0500 Subject: [baremetal-sig][ironic] Tue Jan 12, 2021, 2pm UTC: 'Multi-Tenancy in Ironic: Of Owners and Lessees' In-Reply-To: References: Message-ID: <20210112145852.i3yyh2u7lnqonqjt@barron.net> On 08/01/21 16:39 +0100, Arne Wiebalck wrote: >Dear all, > >Happy new year! > >The Bare Metal SIG will continue its monthly meetings and >start again on > >Tue Jan 12, 2021, at 2pm UTC. > >This time there will be a 10 minute "topic-of-the-day" >presentation by Tzu-Mainn Chen (tzumainn) on > >'Multi-Tenancy in Ironic: Of Owners and Lessees' > >So, if you would like to learn how this relatively recent >addition to Ironic works, you can find all the details >for this meeting on the SIG's etherpad: > >https://etherpad.opendev.org/p/bare-metal-sig > >Everyone is welcome, don't miss out! > >Cheers, > Arne > Had to miss Multi-Tenancy presentation today but look forward to any artefacts (recording, minutes, slides) if these become available. -- Tom From arne.wiebalck at cern.ch Tue Jan 12 15:12:21 2021 From: arne.wiebalck at cern.ch (Arne Wiebalck) Date: Tue, 12 Jan 2021 16:12:21 +0100 Subject: [baremetal-sig][ironic] Tue Jan 12, 2021, 2pm UTC: 'Multi-Tenancy in Ironic: Of Owners and Lessees' In-Reply-To: <20210112145852.i3yyh2u7lnqonqjt@barron.net> References: <20210112145852.i3yyh2u7lnqonqjt@barron.net> Message-ID: <6a3c789f-1413-51c6-81ff-4755ccdbe26a@cern.ch> On 12.01.21 15:58, Tom Barron wrote: > On 08/01/21 16:39 +0100, Arne Wiebalck wrote: >> Dear all, >> >> Happy new year! >> >> The Bare Metal SIG will continue its monthly meetings and >> start again on >> >> Tue Jan 12, 2021, at 2pm UTC. >> >> This time there will be a 10 minute "topic-of-the-day" >> presentation by Tzu-Mainn Chen (tzumainn) on >> >> 'Multi-Tenancy in Ironic: Of Owners and Lessees' >> >> So, if you would like to learn how this relatively recent >> addition to Ironic works, you can find all the details >> for this meeting on the SIG's etherpad: >> >> https://etherpad.opendev.org/p/bare-metal-sig >> >> Everyone is welcome, don't miss out! >> >> Cheers, >> Arne >> > > Had to miss Multi-Tenancy presentation today but look forward to any > artefacts (recording, minutes, slides) if these become available. > > -- Tom > Hi Tom, We have recorded the presentation and will make it (and the ones of the previous presentations) available as soon as we find the time to edit the videos. The links will be made available on the bare metal SIG etherpad, and we will also send something to the list when they are ready! Cheers, Arne From gmann at ghanshyammann.com Tue Jan 12 15:36:24 2021 From: gmann at ghanshyammann.com (Ghanshyam Mann) Date: Tue, 12 Jan 2021 09:36:24 -0600 Subject: =?UTF-8?Q?Re:_=E7=AD=94=E5=A4=8D:_[all]Introduction_to_ve?= =?UTF-8?Q?nus_which_is_the_project_of_log?= =?UTF-8?Q?_management_and_has_been_contributed_to_the_OpenStack_community?= In-Reply-To: <4220f2e3ab1641b493a3c0e8fb83e510@inspur.com> References: <4220f2e3ab1641b493a3c0e8fb83e510@inspur.com> Message-ID: <176f73db0e0.ba0db5211128248.9112192436090806738@ghanshyammann.com> ---- On Tue, 12 Jan 2021 02:45:10 -0600 Brin Zhang(张百林) wrote ---- > >-----邮件原件----- > >发件人: Thierry Carrez [mailto:thierry at openstack.org] > >发送时间: 2021年1月11日 21:12 > >收件人: openstack-discuss at lists.openstack.org > >主题: Re: [all]Introduction to venus which is the project of log management > and has been contributed to the OpenStack community > > >Liye Pang(逄立业) wrote: > >> Hello everyone, after feedback from a large number of operations and > >> maintenance personnel in InCloud OpenStack, we developed the log > >> management project “Venus” for the OpenStack projects [...] > > OpenStack-aware centralized log management sounds very interesting to > me... > > > If others are interested in collaborating on producing that component, I > personally think it would be a great fit for the > > "operations tooling" > > section of the OpenStack Map[1]. > > Yes, after Inspur did a 1,000-nodes OpenStack single-cluster large-scale test, I was more convinced of the benefits Venus can bring to operation and maintenance. By Venus, we can quickly locate and find problems with the OpenStack platform, which can bring great convenience to operation and maintenance. > > https://mp.weixin.qq.com/s/RSrjjZjVFn086StNLV1Ivg This is the article of 1000-nodes test, but it's wrote by Chinese, don't worry ^^, we will publish the English article in future. > > This is the demo for Venus, hope that can help you to know what it can be done: https://youtu.be/mE2MoEx3awM> https://youtu.be/mE2MoEx3awM > > > [1] https://www.openstack.org/software/ Thanks Liye, Brin for the details, I also things this is a valuable project for day-to-day operation on a large-scale cloud or even small scale to automate the log to alter, etc. Just one question, can we configuration the particular error log msg string/pattern for raising alarm? and different levels of alarm (critical, high priority etc)? For example: If there is a known limitation on my cloud (due to RBAC or backend deps) and requests end up in error so I do not want to raise an alarm for those. -gmann > > > -- > > Thierry Carrez (ttx) > > Original ML: http://lists.openstack.org/pipermail/openstack-discuss/2021-January/019748.html > > brinzhang > > From dtantsur at redhat.com Tue Jan 12 16:18:38 2021 From: dtantsur at redhat.com (Dmitry Tantsur) Date: Tue, 12 Jan 2021 17:18:38 +0100 Subject: [ironic] question regarding attributes required for a non-admin to boot from volume In-Reply-To: References: Message-ID: Hi, On Tue, Jan 12, 2021 at 3:45 PM Tzu-Mainn Chen wrote: > Hi, > > I've been looking into what it would take to allow non-admins to boot from > volume. It looks like they'd need to update a node's storage_interface; and > if you'd like to boot from an iSCSI volume, then you also need to update a > node's capabilities property. > FWIW we have a similar situation with the ramdisk deploy and the necessity to update deploy_interface. In both cases I don't feel well about updating node.*_interface itself, because such changes are permanent and there is no code to un-do them before the node becomes available again. My plan (if I ever get to it) is to accept deploy_interface (and now storage_interface) in node.instance_info. This solves both problems: instance_info is writable by non-admins and is wiped automatically on tear down. As to capabilities, I think it's fine if you set the iscsi_boot capability for every node that supports it in advance. You don't need non-admins to do that. Otherwise, most capabilities can be overridden via instance_info[capabilities] (although not this one). Dmitry > > Are these fields that we want non-admins to be able to update? If not, is > there an alternative that might be possible? > > Thanks, > Tzu-Mainn Chen > -- Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill -------------- next part -------------- An HTML attachment was scrubbed... URL: From laurentfdumont at gmail.com Tue Jan 12 04:57:20 2021 From: laurentfdumont at gmail.com (Laurent Dumont) Date: Mon, 11 Jan 2021 23:57:20 -0500 Subject: [all]Introduction to venus which is the project of log management and has been contributed to the OpenStack community In-Reply-To: References: Message-ID: This seems really interesting. Tracing events with request-ids is something that is quite useful. What is the current state? Can it be deployed by a third party? On Sun, Jan 10, 2021 at 4:01 PM Liye Pang(逄立业) wrote: > Hello everyone, after feedback from a large number of operations and > maintenance personnel in InCloud OpenStack, we developed the log management > project “Venus” for the OpenStack projects and that has contributed to the > OpenStack community. The following is an introduction to “Venus”. If there > is interest in the community, we are interested in proposing it to become > an official OpenStack project in the future. > Background > > In the day-to-day operation and maintenance of large-scale cloud platform, > the following problems are encountered： > > l Time-consuming for log querying while the server increasing to > thousands. > > l Difficult to retrieve logs, since there are many modules in the > platform, e.g. systems service, compute, storage, network and other > platform services. > > l The large amount and dispersion of log make faults are difficult to be > discovered. > > l Because of distributed and interaction between components of the cloud > platform, and scattered logs between components, it will take more time to > locate problems. > About Venus > > According to the key requirements of OpenStack in log storage, retrieval, > analysis and so on, we introduced *Venus *project, a unified log > management module. This module can provide a one-stop solution to log > collection, cleaning, indexing, analysis, alarm, visualization, report > generation and other needs, which involves helping operator or maintainer > to quickly solve retrieve problems, grasp the operational health of the > platform, and improve the management capabilities of the cloud platform. > > Additionally, this module plans to use machine learning algorithms to > quickly locate IT failures and root causes, and improve operation and > maintenance efficiency. > Application scenario > > Venus played a key role in the following scenarios： > > l *Retrieval:* Provide a simple and easy-to-use way to retrieve all log > and the context. > > l *Analysis*: Realize log association, field value statistics, and > provide multi-scene and multi-dimensional visual analysis reports. > > l *Alerts*：Convert retrieval into active alerts to realize the error > finding in massive logs. > > l *Issue location*: Establish a chain relationship and knowledge graphs > to quickly locate problems. > Overall structure > > The architecture of log management system based on Venus and elastic > search is as follows: > > Diagram 0: Architecture of Venus > > *venus_api*: API module，provide API、rest-api service. > > *venus_manager*: Internal timing task module to realize the core > functions of the log system. > Current progress > > The current progress of the Venus project is as follows: > > l Collection：Develop *fluentd* collection tasks based on collectd to > read, filter, format and send plug-ins for OpenStack, operating systems, > and platform services, etc. > > l Index：Dealing with multi-dimensional index data in *elasticsearch*, > and provide more concise and comprehensive authentication interface to > return query results. > > l Analysis：Analyzing and display the related module errors, Mariadb > connection errors, and Rabbitmq connection errors. > > l Alerts：Develop alarm task code to set threshold for the number of > error logs of different modules at different times, and provides alarm > services and notification services. > > l Location：Develop the call chain analysis function based on > *global_requested* series, which can show the execution sequence, time > and error information, etc., and provide the export operation. > > l Management：Develop configuration management functions in the log > system, such as alarm threshold setting, timing task management, and log > saving time setting, etc. > Application examples > > Two examples of Venus application scenarios are as follows. > > 1. The virtual machine creation operation was performed on the > cloud platform and it was found that the virtual machine was not created > successfully. > > First, we can find the request id of the operation and jump to the virtual > machine creation call chain page. > > Then, we can query the calling process, view and download the details of > the log of the call. > > 2. In the cloud platform, the error log of each module can be > converted into alarms to remind the users. > > Further, we can retrieve the details of the error log and error log > statistics. > > Next step > > The next step of the Venus project is as follows: > > l *Collection*：In addition to fluent, other collection plugins such as > logstash will be integrated. > > l *Analysis*: Explore more operation and maintenance scenarios, and > conduct statistical analysis and alarm on key data. > > l *display*: The configuration, analysis and alarm of Venus will be > integrated into horizon in the form of plugin. > > l *location*: Form clustering log and construct knowledge map, and > integrate algorithm class library to locate the root cause of the fault. > Venus Project Registry > > *Venus library*: https://opendev.org/inspur/venus > > You can grab the source code using the following git command: > > git clone https://opendev.org/inspur/venus.git > > > Venus Demo > > *Youtu.be*: https://youtu.be/mE2MoEx3awM > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 24507 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.jpg Type: image/jpeg Size: 3184 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image003.jpg Type: image/jpeg Size: 8136 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image004.jpg Type: image/jpeg Size: 15944 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image005.jpg Type: image/jpeg Size: 8405 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image006.jpg Type: image/jpeg Size: 3046 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image007.jpg Type: image/jpeg Size: 15175 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image008.jpg Type: image/jpeg Size: 8496 bytes Desc: not available URL: From D.R.MacDonald at salford.ac.uk Tue Jan 12 11:03:22 2021 From: D.R.MacDonald at salford.ac.uk (Daniel Macdonald) Date: Tue, 12 Jan 2021 11:03:22 +0000 Subject: [octavia] problems configuring octavia In-Reply-To: References: , Message-ID: Hi Michael Thanks for your response. It is useful to know that DNS isn't causing my problems. I have a few more things I need to try, hopefully I'll get through it today then if I still have issues I will use the charms tag for my next post. ________________________________ From: Michael Johnson Sent: 11 January 2021 23:43 To: Daniel Macdonald Cc: openstack-discuss at lists.openstack.org ; Adekunbi Adewojo Subject: Re: [octavia] problems configuring octavia Hi Daniel, It might be helpful to use the [charms] in the subject as I think everything you mentioned here is related to the Ubuntu/juju/charms deployment tooling and not the Octavia project. I don't have any experience with doing a deployment with charms, so I can't be of much help there. That said, Octavia does not rely on DNS for any of its operations. This includes the lb-mgmt-net and for the load balancing elements. So, the lack of access to BIND for Octavia is not a problem. Michael On Fri, Jan 8, 2021 at 8:16 AM Daniel Macdonald > wrote: Happy new year Openstack users and devs! I have been trying on and off for several months to get octavia working but I have yet to have it successfully create a loadbalancer. I have deployed OS bionic-train using the Charms telemetry bundle with the octavia overlay. Openstack is working for creating regular instances but I get various errors when trying to create a loadbalancer. The first issue I feel I should mention is that I am using bind running on our MAAS controller as a DNS server. juju doesn't work if I enable IPv6 under bind yet the octavia charm defaults to using IPv6 for its management network so I have tried creating a IPv4 management network but I'm still having problems. For more details on that please see the comments of this bug report: https://bugs.launchpad.net/charm-octavia/+bug/1897418 Bug #1897418 “feature request: have option to use ipv4 when sett...” : Bugs : OpenStack Octavia Charm By default, Octavia charm uses ipv6 for its lb-mgmt-subnet.[1] It would be nice to have the option to choose an ipv4 network from the start instead of deleting the ipv6 network and recreating the ipv4 subnet. Implementation - possible configuration option parameter when deploying. [1] https://opendev.org/openstack/charm-octavia/src/branch/master/src/lib/charm/openstack/api_crud.py#L560 bugs.launchpad.net Another notable issue I have is that after installing the charms telemetry bundle I have 2 projects call services. How do I know which is the correct one to use for Octavia? Is this following document going to be the best guide for me to follow to complete the final steps required to get Octavia (under Train) working: https://docs.openstack.org/octavia/latest/install/install-ubuntu.html#install-and-configure-components OpenStack Docs: Install and configure for Ubuntu Install and configure for Ubuntu¶. This section describes how to install and configure the Load-balancer service for Ubuntu 18.04 (LTS). docs.openstack.org I'm hoping someone has already written an easy to follow guide to using Octavia with an IPv4 management network using the Charms bundle to do most of the installation work? Thanks [University of Salford] DANIEL MACDONALD Specialist Technical Demonstrator School of Computing, Science & Engineering Room 145, Newton Building, University of Salford, Manchester M5 4WT T: +44(0) 0161 295 5242 D.R.MacDonald at salford.ac.uk / www.salford.ac.uk [CSE] -------------- next part -------------- An HTML attachment was scrubbed... URL: From aditi.Dukle at ibm.com Tue Jan 12 12:11:48 2021 From: aditi.Dukle at ibm.com (aditi Dukle) Date: Tue, 12 Jan 2021 12:11:48 +0000 Subject: [nova] unit testing on ppc64le In-Reply-To: References: , <5E9MMQ.3INH7FY465VR3@est.tech> Message-ID: An HTML attachment was scrubbed... URL: From tpb at dyncloud.net Tue Jan 12 17:00:50 2021 From: tpb at dyncloud.net (Tom Barron) Date: Tue, 12 Jan 2021 12:00:50 -0500 Subject: [baremetal-sig][ironic] Tue Jan 12, 2021, 2pm UTC: 'Multi-Tenancy in Ironic: Of Owners and Lessees' In-Reply-To: <6a3c789f-1413-51c6-81ff-4755ccdbe26a@cern.ch> References: <20210112145852.i3yyh2u7lnqonqjt@barron.net> <6a3c789f-1413-51c6-81ff-4755ccdbe26a@cern.ch> Message-ID: <20210112170050.dxgydzlcb7jfuvly@barron.net> On 12/01/21 16:12 +0100, Arne Wiebalck wrote: >On 12.01.21 15:58, Tom Barron wrote: >>On 08/01/21 16:39 +0100, Arne Wiebalck wrote: >>>Dear all, >>> >>>Happy new year! >>> >>>The Bare Metal SIG will continue its monthly meetings and >>>start again on >>> >>>Tue Jan 12, 2021, at 2pm UTC. >>> >>>This time there will be a 10 minute "topic-of-the-day" >>>presentation by Tzu-Mainn Chen (tzumainn) on >>> >>>'Multi-Tenancy in Ironic: Of Owners and Lessees' >>> >>>So, if you would like to learn how this relatively recent >>>addition to Ironic works, you can find all the details >>>for this meeting on the SIG's etherpad: >>> >>>https://etherpad.opendev.org/p/bare-metal-sig >>> >>>Everyone is welcome, don't miss out! >>> >>>Cheers, >>>Arne >>> >> >>Had to miss Multi-Tenancy presentation today but look forward to any >>artefacts (recording, minutes, slides) if these become available. >> >>-- Tom >> >Hi Tom, > >We have recorded the presentation and will make it (and the >ones of the previous presentations) available as soon as we >find the time to edit the videos. > >The links will be made available on the bare metal SIG >etherpad, and we will also send something to the list when >they are ready! > >Cheers, > Arne > Thanks, Arne! From smooney at redhat.com Tue Jan 12 17:52:28 2021 From: smooney at redhat.com (Sean Mooney) Date: Tue, 12 Jan 2021 17:52:28 +0000 Subject: [nova] unit testing on ppc64le In-Reply-To: References: , <5E9MMQ.3INH7FY465VR3@est.tech> Message-ID: <902298832b49f91eb790e8de1e643d5223366423.camel@redhat.com> On Tue, 2021-01-12 at 12:11 +0000, aditi Dukle wrote: > Hi Mike, >   > I have created these unit test jobs - openstack-tox-py27, openstack-tox-py35, openstack-tox-py36, openstack-tox-py37, openstack-tox-py38, openstack- > tox-py39 > by referring to the upstream CI( https://opendev.org/openstack/openstack-zuul-jobs/src/branch/master/zuul.d/jobs.yaml) and these jobs are triggered > for every patchset in the Openstack CI.  > > I checked the code for old CI for Power, we didn't have any unit test jobs that were run for every patchset for nova. We had one "nova-python27" job > that was run in a periodic pipeline. So, I wanted to know if we need to run the unit test jobs on ppc for every patchset for nova? and If yes, > should these be reporting to the Openstack community? the request was to have the unit tests and ideally func tests run on ppc and report back to the comunity for every patch if you have the capasity to do that. if its not per patch then a way to manually trigger it per patch would be perfered in addtion to the periodic. what i would suggest is running just 1 python version per branch form the supporte python runtimes for that branch the supproted runtimes are defined here https://github.com/openstack/governance/tree/master/reference/runtimes so if you are unning this on a ubuntu image then master shoudl ideally use python 3.8 for both functional and unit tests. the problem we are trying to adress is currenlty we have some unit/fucntional tests that fail when running on ppc so we woudl like to use your third party ci to catch that the same way we us its tempest test to inform if we have broken compatiblity. if we took a perodic approch we would still need an ablity to trigger it manually so that we could test teh patchs that proport to fix a breakage in compatiablity. > > > Thanks, > Aditi Dukle > > ----- Original message ----- > > From: Michael J Turek/Poughkeepsie/IBM > > To: balazs.gibizer at est.tech, aditi Dukle/India/Contr/IBM at IBM, Sajauddin Mohammad/India/Contr/IBM at IBM > > Cc: openstack-discuss at lists.openstack.org > > Subject: Re: [EXTERNAL] [nova] unit testing on ppc64le > > Date: Sat, Jan 9, 2021 12:52 AM > >   > > Thanks for the heads up, > > > > We should have the capacity to add them. At one point I think we ran unit tests for nova but the job may have been culled in the move to zuul v3. > > I've CC'd the maintainers of the CI, Aditi Dukle and Sajauddin Mohammad. > > > > Aditi and Sajauddin, could we add a job to pkvmci to run unit tests for nova? > >   > > Michael Turek > > Software Engineer > > Power Cloud Department > > 1 845 433 1290 Office > > mjturek at us.ibm.com > > He/Him/His > >   > > IBM > >   > >   > >   > > > ----- Original message ----- > > > From: Balazs Gibizer > > > To: OpenStack Discuss > > > Cc: mjturek at us.ibm.com > > > Subject: [EXTERNAL] [nova] unit testing on ppc64le > > > Date: Fri, Jan 8, 2021 7:59 AM > > >   > > > Hi, > > > > > > We have a bugreport[1] showing that our unit tests are not passing on > > > ppc. In the upstream CI we don't have test capability to run our tests > > > on ppc. But we have the IBM Power KVM CI[2] that runs integration tests > > > on ppc. I'm wondering if IBM could extend the CI to run nova unit and > > > functional tests too. I've added Michael Turek (mjturek at us.ibm.com) to > > > CC. Michael is listed as the contact person for the CI. > > > > > > Cheers, > > > gibi > > > > > > [1]https://bugs.launchpad.net/nova/+bug/1909972  > > > [2]https://wiki.openstack.org/wiki/ThirdPartySystems/IBMPowerKVMCI  > > > > > >   > >   >   > From james.slagle at gmail.com Tue Jan 12 18:17:32 2021 From: james.slagle at gmail.com (James Slagle) Date: Tue, 12 Jan 2021 13:17:32 -0500 Subject: [heat][tripleo] os-apply-config os-refresh-config os-collect-config project governance In-Reply-To: References: Message-ID: On Tue, Jan 12, 2021 at 9:32 AM Rabi Mishra wrote: > > > On Tue, Jan 12, 2021 at 6:58 PM James Slagle > wrote: > >> >> >> On Tue, Jan 12, 2021 at 7:47 AM Marios Andreou wrote: >> >>> Hello Heat team o/ >>> >>> as discussed in the thread at [1] TripleO is no longer using >>> os-collect-config, os-refresh-config and os-apply-config as part of the >>> OpenStack deployment. As such we are considering moving these repos to the >>> independent release model. >>> >>> However as pointed out in [1] it seems that Heat is still using these - >>> documented at [2]. Is the Heat community interested in taking over the >>> ownership of these? To be clear what the proposal here is, I posted [3] - >>> i.e. move these projects under the Heat governance. >>> >>> Thanks for your time, thoughts and comments on this, either here or in >>> [3]. If you are NOT interested in owning these then we will likely move >>> them to independent, or possibly even unmaintained/eol (in due course). >>> >> >> I realized a possible wrinkle with moving these to Heat governance. >> TripleO still relies on the stable/train branches given these projects are >> still used in train, and there exists a possibility that TripleO cores may >> need to backport patch(es) to the train branch in these projects. >> > > I thought we switched to config-download by default from stable/rocky and > disabled os-collect-config[1]. Not sure if anyone uses it beyond that with > TripleO. Looking at the number of functional changes backported to > stable/queens (AFICS only 3 of them)[2], probably it won't be a major > bottleneck, assuming the heat community wants to own it. > You're right. I meant to say queens instead of train. -- -- James Slagle -- -------------- next part -------------- An HTML attachment was scrubbed... URL: From Arkady.Kanevsky at dell.com Tue Jan 12 23:25:36 2021 From: Arkady.Kanevsky at dell.com (Kanevsky, Arkady) Date: Tue, 12 Jan 2021 23:25:36 +0000 Subject: [baremetal-sig][ironic] Tue Jan 12, 2021, 2pm UTC: 'Multi-Tenancy in Ironic: Of Owners and Lessees' In-Reply-To: <6a3c789f-1413-51c6-81ff-4755ccdbe26a@cern.ch> References: <20210112145852.i3yyh2u7lnqonqjt@barron.net> <6a3c789f-1413-51c6-81ff-4755ccdbe26a@cern.ch> Message-ID: Thanks Arne. Looking forward to recording. -----Original Message----- From: Arne Wiebalck Sent: Tuesday, January 12, 2021 9:12 AM To: Tom Barron Cc: openstack-discuss Subject: Re: [baremetal-sig][ironic] Tue Jan 12, 2021, 2pm UTC: 'Multi-Tenancy in Ironic: Of Owners and Lessees' [EXTERNAL EMAIL] On 12.01.21 15:58, Tom Barron wrote: > On 08/01/21 16:39 +0100, Arne Wiebalck wrote: >> Dear all, >> >> Happy new year! >> >> The Bare Metal SIG will continue its monthly meetings and start again >> on >> >> Tue Jan 12, 2021, at 2pm UTC. >> >> This time there will be a 10 minute "topic-of-the-day" >> presentation by Tzu-Mainn Chen (tzumainn) on >> >> 'Multi-Tenancy in Ironic: Of Owners and Lessees' >> >> So, if you would like to learn how this relatively recent addition to >> Ironic works, you can find all the details for this meeting on the >> SIG's etherpad: >> >> https://etherpad.opendev.org/p/bare-metal-sig >> >> Everyone is welcome, don't miss out! >> >> Cheers, >> Arne >> > > Had to miss Multi-Tenancy presentation today but look forward to any > artefacts (recording, minutes, slides) if these become available. > > -- Tom > Hi Tom, We have recorded the presentation and will make it (and the ones of the previous presentations) available as soon as we find the time to edit the videos. The links will be made available on the bare metal SIG etherpad, and we will also send something to the list when they are ready! Cheers, Arne From pangliye at inspur.com Wed Jan 13 02:04:07 2021 From: pangliye at inspur.com (=?utf-8?B?TGl5ZSBQYW5nKOmAhOeri+S4mik=?=) Date: Wed, 13 Jan 2021 02:04:07 +0000 Subject: =?utf-8?B?562U5aSNOiBbbGlzdHMub3BlbnN0YWNrLm9yZ+S7o+WPkV1SZTog562U5aSN?= =?utf-8?B?OiBbYWxsXUludHJvZHVjdGlvbiB0byB2ZW51cyB3aGljaCBpcyB0aGUgcHJv?= =?utf-8?B?amVjdCBvZiBsb2cgbWFuYWdlbWVudCBhbmQgaGFzIGJlZW4gY29udHJpYnV0?= =?utf-8?Q?ed_to_the_OpenStack_community?= In-Reply-To: <176f73db0e0.ba0db5211128248.9112192436090806738@ghanshyammann.com> References: <09603c06ed48c77923781a3dcccbb4c6@sslemail.net> <176f73db0e0.ba0db5211128248.9112192436090806738@ghanshyammann.com> Message-ID: <494026c44e9f46c5b3560c17f602bfd9@inspur.com> ---- On Tue, 12 Jan 2021 02:45:10 -0600 Brin Zhang(张百林) wrote ---- > >-----邮件原件----- > > >发件人: Thierry Carrez [mailto:thierry at openstack.org] > >发送时间: 2021年1月11日 21:12 > >收件人: openstack-discuss at lists.openstack.org >> >主题: Re: [all]Introduction to venus which is the project of log management > and has been contributed to the OpenStack community > > >Liye Pang(逄立业) wrote: >> >> Hello everyone, after feedback from a large number of operations and > >> maintenance personnel in InCloud OpenStack, we developed the log > >> management project “Venus” for the OpenStack projects [...] > > OpenStack-aware centralized log management sounds very interesting to > me... >> >> > If others are interested in collaborating on producing that component, I > personally think it would be a great fit for the > > "operations tooling" >> > section of the OpenStack Map[1]. >> >> Yes, after Inspur did a 1,000-nodes OpenStack single-cluster large-scale test, I was more convinced of the benefits Venus can bring to operation and maintenance. By Venus, we can quickly locate and find problems with the OpenStack platform, which can bring great convenience to operation and maintenance. >> >> https://mp.weixin.qq.com/s/RSrjjZjVFn086StNLV1Ivg This is the article of 1000-nodes test, but it's wrote by Chinese, don't worry ^^, we will publish the English article in future. >> >> This is the demo for Venus, hope that can help you to know what it can be done: https://youtu.be/mE2MoEx3awM> https://youtu.be/mE2MoEx3awM > > > [1] https://www.openstack.org/software/ >Thanks Liye, Brin for the details, I also things this is a valuable project for day-to-day operation on a large-scale cloud or even small scale to automate the log to alter, etc. >Just one question, can we configuration the particular error log msg string/pattern for raising alarm? and different levels of alarm (critical, high priority etc)? >For example: If there is a known limitation on my cloud (due to RBAC or backend deps) and requests end up in error so I do not want to raise an alarm for those. >-gmann At present, the alarm task for the error log is placed in our monitoring system, and the data is obtained from venus. Only the alarms for the number of error logs and the regular matching of typical error log are realized,and alarm level can be defined by yourself. In the future, we will migrate the alarm notification function to venus, and at the same time, we will comprehensively organize the matching mode of the error log to form a configuration template. Everyone is welcome to join us. > >> >> > -- >> > Thierry Carrez (ttx) >> >> Original ML: http://lists.openstack.org/pipermail/openstack-discuss/2021-January/019748.html >> >> brinzhang >> >> -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3786 bytes Desc: not available URL: From licanwei_cn at 163.com Wed Jan 13 02:31:02 2021 From: licanwei_cn at 163.com (licanwei) Date: Wed, 13 Jan 2021 10:31:02 +0800 (GMT+08:00) Subject: [Watcher]stepping down as PTL Message-ID: <50e905b1.101f.176f99506f3.Coremail.licanwei_cn@163.com> Hi all, For personal reason, I have no time to continue the work for Watcher PTL. My colleage, Chen Ke(irc:chenke) will temporarily replace me as PTL, thank you for your support. thanks, | | licanwei_cn | | 邮箱：licanwei_cn at 163.com | 签名由 网易邮箱大师 定制 -------------- next part -------------- An HTML attachment was scrubbed... URL: From anost1986 at gmail.com Wed Jan 13 04:17:00 2021 From: anost1986 at gmail.com (Andrii Ostapenko) Date: Tue, 12 Jan 2021 22:17:00 -0600 Subject: [all][stackalytics] stackalytics.io Message-ID: Hi all! Since https://stackalytics.com is not operational for quite some time already, I exposed another instance on https://stackalytics.io It shares the same configuration and is kept updated. You're welcome to use it at least until stackalytics.com is up and running (just please be gentle). Sincerely, Andrii Ostapenko From smooney at redhat.com Wed Jan 13 04:34:33 2021 From: smooney at redhat.com (Sean Mooney) Date: Wed, 13 Jan 2021 04:34:33 +0000 Subject: [all][stackalytics] stackalytics.io In-Reply-To: References: Message-ID: On Tue, 2021-01-12 at 22:17 -0600, Andrii Ostapenko wrote: > Hi all! > > Since https://stackalytics.com is not operational for quite some time > already, I exposed another instance on https://stackalytics.io > It shares the same configuration and is kept updated. You're welcome > to use it at least until stackalytics.com is up and running (just > please be gentle). is there any documentaiton on how to deploy our own instance of it if we want too or either go offline in the future? > > Sincerely, > Andrii Ostapenko > From araragi222 at gmail.com Wed Jan 13 06:05:22 2021 From: araragi222 at gmail.com (=?UTF-8?B?5ZGC6Imv?=) Date: Wed, 13 Jan 2021 15:05:22 +0900 Subject: Ask for patch review Message-ID: Hi, Mr.Ogawa & other members of tacker team: This is Liang Lu, may I invite you to review my patch ? https://review.opendev.org/c/openstack/tacker/+/764138 (now it is retesting but no new patch sets in future) This is a tiny patch fix calling parameter of kubernetes_driver.instantiate_vnf(), however it affects FT(will continuously fail if not merge), so I want to push it and merge it soon. best regards -------------- next part -------------- An HTML attachment was scrubbed... URL: From yasufum.o at gmail.com Wed Jan 13 07:04:31 2021 From: yasufum.o at gmail.com (Yasufumi Ogawa) Date: Wed, 13 Jan 2021 16:04:31 +0900 Subject: [tacker] Ask for patch review In-Reply-To: References: Message-ID: <922a907d-385f-4229-87e3-1b65f0a13c72@gmail.com> Liang, (Added "[tacker]" in the title) Sure. I've already added myself and reviewed at once. I'd to like to check it again after the tests will be all green. Thanks, Yausufmi On 2021/01/13 15:05, 呂良 wrote: > Hi, Mr.Ogawa & other members of tacker team: > > This is Liang Lu, may I invite you to review my patch ? > https://review.opendev.org/c/openstack/tacker/+/764138 > > (now it is retesting but no new patch sets in future) > > This is a tiny patch fix calling parameter of > kubernetes_driver.instantiate_vnf(), > however it affects FT(will continuously fail if not merge), > so I want to push it and merge it soon. > > best regards From christian.rohmann at inovex.de Wed Jan 13 09:37:56 2021 From: christian.rohmann at inovex.de (Christian Rohmann) Date: Wed, 13 Jan 2021 10:37:56 +0100 Subject: [cinder] Review of tiny patch to add Ceph RBD fast-diff to cinder-backup Message-ID: Hey everyone, I wrote a tiny patch to add the Ceph RDB feature of fast-diff to backups created by cinder-backup:  * https://review.opendev.org/c/openstack/cinder/+/766856/ Could someone please take a peek and let me know of this is sufficient to be merged? Thanks and with kind regards, Christian From thierry at openstack.org Wed Jan 13 10:59:47 2021 From: thierry at openstack.org (Thierry Carrez) Date: Wed, 13 Jan 2021 11:59:47 +0100 Subject: [all]Introduction to venus which is the project of log management and has been contributed to the OpenStack community In-Reply-To: References: Message-ID: Laurent Dumont wrote: > This seems really interesting. Tracing events with request-ids is > something that is quite useful. > > What is the current state? Can it be deployed by a third party? I see code up at https://opendev.org/inspur/ but I haven't tried deploying it. If it gathers momentum, I suspect it will be proposed as a new official OpenStack project, and if the Technical Committee approves it, it will be moved under the openstack/ namespace on opendev.org. It already follows our usual repository structure (venus, python-venusclient, venus-tempest-plugin...) -- Thierry From rosmaita.fossdev at gmail.com Wed Jan 13 13:27:35 2021 From: rosmaita.fossdev at gmail.com (Brian Rosmaita) Date: Wed, 13 Jan 2021 08:27:35 -0500 Subject: [cinder] Review of tiny patch to add Ceph RBD fast-diff to cinder-backup In-Reply-To: References: Message-ID: <721b4405-b19f-5433-feff-d595442ce6e4@gmail.com> On 1/13/21 4:37 AM, Christian Rohmann wrote: > Hey everyone, > > I wrote a tiny patch to add the Ceph RDB feature of fast-diff to backups > created by cinder-backup: > >  * https://review.opendev.org/c/openstack/cinder/+/766856/ > > > Could someone please take a peek and let me know of this is sufficient > to be merged? Thanks for raising awareness of your patch. Right now, the cinder team is prioritizing new driver reviews in light of the impending merge deadline at wallaby milestone-2 next week: http://lists.openstack.org/pipermail/openstack-discuss/2021-January/019720.html So there may be a slight delay to your patch being reviewed. If you have some time, you can always help things along by reviewing some small patches by other authors. cheers, brian > > > > Thanks and with kind regards, > > > Christian > > > From rosmaita.fossdev at gmail.com Wed Jan 13 13:41:21 2021 From: rosmaita.fossdev at gmail.com (Brian Rosmaita) Date: Wed, 13 Jan 2021 08:41:21 -0500 Subject: [barbican][oslo][nova][glance][cinder] cursive library status In-Reply-To: References: <35dfc43f-6613-757b-ed7b-b6530df21289@gmail.com> Message-ID: On 1/11/21 10:57 AM, Moises Guimaraes de Medeiros wrote: > Hi Brian, > > During Oslo's last weekly meeting [1] we decided that Oslo can take > cursive under its umbrella with collaboration of Barbican folks. I just > waited a bit with this confirmation as the Barbican PTL was on PTO and I > wanted to confirm with him. > > What are the next steps from here? Thanks so much for following up! I think you need to do something like these patches from Ghanshyam to move devstack-plugin-nfs from x/ to openstack/ and bring it under QA governance: https://review.opendev.org/c/openstack/project-config/+/711834 https://review.opendev.org/c/openstack/governance/+/711835 LMK if you want me to propose the patches, my intent is to get this issue solved, not to make more work for you! cheers, brian > > [1]: > http://eavesdrop.openstack.org/meetings/oslo/2021/oslo.2021-01-04-16.00.log.html#l-64 > > > Thanks, > Moisés > > On Fri, Dec 18, 2020 at 10:06 PM Douglas Mendizabal > wrote: > > On 12/16/20 12:50 PM, Ben Nemec wrote: > > > > > > On 12/16/20 12:02 PM, Brian Rosmaita wrote: > >> Hello Barbican team, > >> > >> Apologies for not including barbican in the previous thread on this > >> topic: > >> > >> > http://lists.openstack.org/pipermail/openstack-discuss/2020-December/019430.html > > > >> > >> > >> The situation is that cursive is used by Nova, Glance, and > Cinder and > >> we'd like to move it out of the 'x' namespace into openstack > >> governance.   The question is then what team would oversee it.  It > >> seems like a good fit for Oslo, and the Oslo team seems OK with > that, > >> but since barbican-core is currently included in cursive-core, > it make > >> sense to give the Barbican team first dibs. > >> > >>  From the consuming teams' side, I don't think we have a > preference as > >> long as it's clear who we need to bother about approvals if a > bugfix > >> is posted for review. > >> > >> Thus my ask is that the Barbican team indicate whether they'd > like to > >> move cursive to the 'openstack' namespace under their > governance, or > >> whether they'd prefer Oslo to oversee the library. > > > > Note that this is not necessarily an either/or thing. Castellan > is under > > Oslo governance but is co-owned by the Oslo and Barbican teams. > We could > > do a similar thing with Cursive. > > > > Hi Brian and Ben, > > Sorry I missed the original thread.  Given that the end of the year is > around the corner, most of the Barbican team is out on PTO and we > haven't had a chance to discuss this in our weekly meeting. > > That said, I doubt anyone would object to moving cursive into the > openstack namespace. > > I personally do not mind the Oslo team taking over maintenace, and I am > also willing to help review patches if the Oslo team would like to > co-own this library just like we currently do for Castellan. > > - Douglas Mendizábal (redrobot) > > > > > -- > > Moisés Guimarães > > Software Engineer > > Red Hat > > > From thierry at openstack.org Wed Jan 13 15:26:38 2021 From: thierry at openstack.org (Thierry Carrez) Date: Wed, 13 Jan 2021 16:26:38 +0100 Subject: [largescale-sig] Next meeting: January 13, 15utc In-Reply-To: References: Message-ID: We held our meeting today, with a focus on rebooting the Large Scale SIG engine for the new year. From a Scaling Journey[1] perspective, amorin will focus on stage 1, genekuo will focus on stage 2, belmoreira will focus on stage 4 and 5, while I'll focus on stewarding the group and more janitorial tasks. [1] https://wiki.openstack.org/wiki/Large_Scale_SIG/ScaleUp Meeting logs at: http://eavesdrop.openstack.org/meetings/large_scale_sig/2021/large_scale_sig.2021-01-13-15.00.html Our next meeting will be Wednesday, January 27 at 15utc in #openstack-meeting-3 on Freenode IRC. Please join us if interested in helping make large scale openstack less scary! -- Thierry Carrez (ttx) From anost1986 at gmail.com Wed Jan 13 16:01:46 2021 From: anost1986 at gmail.com (Andrii Ostapenko) Date: Wed, 13 Jan 2021 10:01:46 -0600 Subject: [all][stackalytics] stackalytics.io In-Reply-To: References: Message-ID: On Tue, Jan 12, 2021 at 10:36 PM Sean Mooney wrote: > > On Tue, 2021-01-12 at 22:17 -0600, Andrii Ostapenko wrote: > > Hi all! > > > > Since https://stackalytics.com is not operational for quite some time > > already, I exposed another instance on https://stackalytics.io > > It shares the same configuration and is kept updated. You're welcome > > to use it at least until stackalytics.com is up and running (just > > please be gentle). > > is there any documentaiton on how to deploy our own instance of it if we want > too or either go offline in the future? I've started with https://wiki.openstack.org/wiki/Stackalytics/HowToRun Though addressed some blocking code issues and did a couple of enhancements. Will push them once have some time to make the code better. > > > > Sincerely, > > Andrii Ostapenko > > > > > From ankelezhang at gmail.com Wed Jan 13 05:54:08 2021 From: ankelezhang at gmail.com (Ankele zhang) Date: Wed, 13 Jan 2021 13:54:08 +0800 Subject: ironic-python-agent erase block device failed Message-ID: Hi, I have an Rocky OpenStack platform. I used ironic-python-agent-builder to build a ipa.initramfs image. I called the clean API to erase my baremetal node disk. But it was failed. I traced the ipa source code, and got it used 'hdparm -I /dev/sdx' to check if the device is frozen [image: image.png] my device is frozen, then I switched to another SSD, and it's not frozen but it was also failed, [image: image.png] I don't know if I need to erase my bare metal nodes' block devices in product environment. If so, how to make it successful? Ankele -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 12688 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 24678 bytes Desc: not available URL: From openinfradn at gmail.com Wed Jan 13 18:32:16 2021 From: openinfradn at gmail.com (open infra) Date: Thu, 14 Jan 2021 00:02:16 +0530 Subject: Enabling KVM on Openstack Inbox Message-ID: Hi (This mail has been sent to the community mailing list already, and I was suggested to reach out to this mailing list.) I have enabled KVM after deploying openstack single node setup. Following entries has been added to /etc/nova/nova.conf and then restart libvirtd.service and openstack-nova-compute.servic. compute_driver = libvirt.LibvirtDriver [libvirt] virt_type=kvm #virt_type=qemu # lsmod | grep kvm kvm_intel 188740 0 kvm 637289 1 kvm_intel irqbypass 13503 1 kvm I have disabled qemu in nova config and restarted the entire box (including the base OS and the VM where I deployed Openstack. But still no luck. $ openstack hypervisor list +----+------------------------+-----------------+----------------+-------+ | ID | Hypervisor Hostname | Hypervisor Type | Host IP | State | +----+------------------------+-----------------+----------------+-------+ | 1 | openstack.centos.local | QEMU | 192.168.122.63 | up | +----+------------------------+-----------------+----------------+-------+ I still can see Hypervisor Type as QEMU, when I issue openstack hypervisor list command. -------------- next part -------------- An HTML attachment was scrubbed... URL: From smooney at redhat.com Wed Jan 13 19:18:44 2021 From: smooney at redhat.com (Sean Mooney) Date: Wed, 13 Jan 2021 19:18:44 +0000 Subject: Enabling KVM on Openstack Inbox In-Reply-To: References: Message-ID: <5adeeecde601ab7d774d0bf4e09d50083efbaf68.camel@redhat.com> On Thu, 2021-01-14 at 00:02 +0530, open infra wrote: > Hi > > (This mail has been sent to the community mailing list already, and I was > suggested to reach out to this mailing list.) > > I have enabled KVM after deploying openstack single node setup. > Following entries has been added to /etc/nova/nova.conf and then restart > libvirtd.service and openstack-nova-compute.servic. > > compute_driver = libvirt.LibvirtDriver [libvirt] virt_type=kvm > #virt_type=qemu > > # lsmod | grep kvm > kvm_intel 188740 0 > kvm 637289 1 kvm_intel > irqbypass 13503 1 kvm > > > I have disabled qemu in nova config and restarted the entire box (including > the base OS and the VM where I deployed Openstack. > But still no luck. > > > $ openstack hypervisor list > +----+------------------------+-----------------+----------------+-------+ > > ID | Hypervisor Hostname | Hypervisor Type | Host IP | State | > +----+------------------------+-----------------+----------------+-------+ > >  1 | openstack.centos.local | QEMU | 192.168.122.63 | up | > +----+------------------------+-----------------+----------------+-------+ > > I still can see Hypervisor Type as QEMU, when I issue openstack hypervisor > list command. no that is expected enableing kvm does not change the hypervior type its still qemu its just using the kvm accleartion instead of the tsc backend. so that wont change but your vms should not change tehre domain type and be using kvm. From radoslaw.piliszek at gmail.com Wed Jan 13 19:36:06 2021 From: radoslaw.piliszek at gmail.com (=?UTF-8?Q?Rados=C5=82aw_Piliszek?=) Date: Wed, 13 Jan 2021 20:36:06 +0100 Subject: [all][dev] Beware how fun the new pip can be Message-ID: Hiya, Folks! Sharing what I have just learnt about the new pip's solver. pip install PROJECT no longer guarantees to install the latest version of PROJECT (or, well, giving you the ERROR that it cannot do it because something something :-) ). In fact, it will install the latest version *matching other constraints* and do it *silently*. Like it was recently only with Python version (i.e. py3-only would not get installed on py2 - that is cool) but now it moved into any-package territory. As an example, I can give you [1] where we are experimenting with getting some extracurricular package into our containers, notably fluent-logger. The only dep of fluent-logger is msgpack but the latest msgpack (as in upper constraints: 1.0.2, or any 1.x for that matter) is not compatible. However, the pin was introduced in fluent-logger in its 0.9.5 release (0.9.6 is the latest). Guess what pip does? Here is what it does: INFO:kolla.common.utils.openstack-base:Collecting fluent-logger INFO:kolla.common.utils.openstack-base: Downloading http://mirror-int.dfw.rax.opendev.org:8080/pypifiles/packages/1a/f5/e6c30ec7a81e9c32c652c684004334187db4cc09eccf78ae7b69e62c7b10/fluent_logger-0.9.6-py2.py3-none-any.whl (12 kB) INFO:kolla.common.utils.openstack-base: Downloading http://mirror-int.dfw.rax.opendev.org:8080/pypifiles/packages/d5/cb/19d838561ec210321aea24c496ec61930d6fdbb2f98d3f06cebab33c1331/fluent_logger-0.9.5-py2.py3-none-any.whl (12 kB) INFO:kolla.common.utils.openstack-base: Downloading http://mirror-int.dfw.rax.opendev.org:8080/pypifiles/packages/d1/d4/f9b3493f974cdac831bf707c3d9fec93b1a0ebd986eae4db4f101dd72378/fluent_logger-0.9.4-py2.py3-none-any.whl (12 kB) And that's it. Pip is happy, you got your "latest" version. In previous pip one would get the latest version AND a warning. Now just pip's view on what the "latest" version is. I am glad we have upper-constraints which save the day here (forcing the ERROR) but beware of this "in the wild". [1] https://review.opendev.org/c/openstack/kolla/+/759855 -yoctozepto From anost1986 at gmail.com Wed Jan 13 19:54:24 2021 From: anost1986 at gmail.com (Andrii Ostapenko) Date: Wed, 13 Jan 2021 13:54:24 -0600 Subject: [all][dev] Beware how fun the new pip can be In-Reply-To: References: Message-ID: On Wed, Jan 13, 2021 at 1:37 PM Radosław Piliszek wrote: > > Hiya, Folks! > > Sharing what I have just learnt about the new pip's solver. > pip install PROJECT no longer guarantees to install the latest version > of PROJECT (or, well, giving you the ERROR that it cannot do it > because something something :-) ). > In fact, it will install the latest version *matching other > constraints* and do it *silently*. > Like it was recently only with Python version (i.e. py3-only would not > get installed on py2 - that is cool) but now it moved into any-package > territory. > > As an example, I can give you [1] where we are experimenting with > getting some extracurricular package into our containers, notably > fluent-logger. > The only dep of fluent-logger is msgpack but the latest msgpack (as in > upper constraints: 1.0.2, or any 1.x for that matter) is not > compatible. However, the pin was introduced in fluent-logger in its > 0.9.5 release (0.9.6 is the latest). Guess what pip does? Here is what > it does: > > INFO:kolla.common.utils.openstack-base:Collecting fluent-logger > INFO:kolla.common.utils.openstack-base: Downloading > http://mirror-int.dfw.rax.opendev.org:8080/pypifiles/packages/1a/f5/e6c30ec7a81e9c32c652c684004334187db4cc09eccf78ae7b69e62c7b10/fluent_logger-0.9.6-py2.py3-none-any.whl > (12 kB) > INFO:kolla.common.utils.openstack-base: Downloading > http://mirror-int.dfw.rax.opendev.org:8080/pypifiles/packages/d5/cb/19d838561ec210321aea24c496ec61930d6fdbb2f98d3f06cebab33c1331/fluent_logger-0.9.5-py2.py3-none-any.whl > (12 kB) > INFO:kolla.common.utils.openstack-base: Downloading > http://mirror-int.dfw.rax.opendev.org:8080/pypifiles/packages/d1/d4/f9b3493f974cdac831bf707c3d9fec93b1a0ebd986eae4db4f101dd72378/fluent_logger-0.9.4-py2.py3-none-any.whl > (12 kB) > > And that's it. Pip is happy, you got your "latest" version. > In previous pip one would get the latest version AND a warning. Now > just pip's view on what the "latest" version is. > > I am glad we have upper-constraints which save the day here (forcing > the ERROR) but beware of this "in the wild". > > [1] https://review.opendev.org/c/openstack/kolla/+/759855 > > -yoctozepto > Really big change, no surprise it's full of bugs. I had a situation with an infinite loop of 'Requirement already satisfied' just yesterday. Can only suggest to file issues https://github.com/pypa/pip/issues and fall back to 20.2, i think virtualenv==20.2.1 is the latest that comes with 20.2 pip From radoslaw.piliszek at gmail.com Wed Jan 13 20:10:27 2021 From: radoslaw.piliszek at gmail.com (=?UTF-8?Q?Rados=C5=82aw_Piliszek?=) Date: Wed, 13 Jan 2021 21:10:27 +0100 Subject: [all][dev] Beware how fun the new pip can be In-Reply-To: References: Message-ID: A quick addendum after discussion with Clark (to make it easier to digest for everyone). The actors from PyPI: msgpack - the latest is 1.0.2 and that is what is in the upper-constraints that are being used fluent-logger - the latest is 0.9.6 and this is being installed *unconstrained* fluent-logger sets one dep: msgpack<1.0.0 since fluent-logger 0.9.5 The result: 1) old pip msgpack==1.0.2 fluent-logger==0.9.6 and a WARNING that fluent-logger 0.9.6 wants msgpack<1.0.0 2) new pip msgpack==1.0.2 fluent-logger==0.9.4 and no WARNINGs, no ERRORs, no anything, just happy silent "I got you your package, so what if it is not the latest, I am the smart one here" i.e. controlling *dependencies* controls *dependants* And don't get me wrong, pip did what it advertised - took a list of constraints and found a solution. The outtake is simple: beware! :-) -yoctozepto On Wed, Jan 13, 2021 at 8:36 PM Radosław Piliszek wrote: > > Hiya, Folks! > > Sharing what I have just learnt about the new pip's solver. > pip install PROJECT no longer guarantees to install the latest version > of PROJECT (or, well, giving you the ERROR that it cannot do it > because something something :-) ). > In fact, it will install the latest version *matching other > constraints* and do it *silently*. > Like it was recently only with Python version (i.e. py3-only would not > get installed on py2 - that is cool) but now it moved into any-package > territory. > > As an example, I can give you [1] where we are experimenting with > getting some extracurricular package into our containers, notably > fluent-logger. > The only dep of fluent-logger is msgpack but the latest msgpack (as in > upper constraints: 1.0.2, or any 1.x for that matter) is not > compatible. However, the pin was introduced in fluent-logger in its > 0.9.5 release (0.9.6 is the latest). Guess what pip does? Here is what > it does: > > INFO:kolla.common.utils.openstack-base:Collecting fluent-logger > INFO:kolla.common.utils.openstack-base: Downloading > http://mirror-int.dfw.rax.opendev.org:8080/pypifiles/packages/1a/f5/e6c30ec7a81e9c32c652c684004334187db4cc09eccf78ae7b69e62c7b10/fluent_logger-0.9.6-py2.py3-none-any.whl > (12 kB) > INFO:kolla.common.utils.openstack-base: Downloading > http://mirror-int.dfw.rax.opendev.org:8080/pypifiles/packages/d5/cb/19d838561ec210321aea24c496ec61930d6fdbb2f98d3f06cebab33c1331/fluent_logger-0.9.5-py2.py3-none-any.whl > (12 kB) > INFO:kolla.common.utils.openstack-base: Downloading > http://mirror-int.dfw.rax.opendev.org:8080/pypifiles/packages/d1/d4/f9b3493f974cdac831bf707c3d9fec93b1a0ebd986eae4db4f101dd72378/fluent_logger-0.9.4-py2.py3-none-any.whl > (12 kB) > > And that's it. Pip is happy, you got your "latest" version. > In previous pip one would get the latest version AND a warning. Now > just pip's view on what the "latest" version is. > > I am glad we have upper-constraints which save the day here (forcing > the ERROR) but beware of this "in the wild". > > [1] https://review.opendev.org/c/openstack/kolla/+/759855 > > -yoctozepto From gmann at ghanshyammann.com Wed Jan 13 20:16:33 2021 From: gmann at ghanshyammann.com (Ghanshyam Mann) Date: Wed, 13 Jan 2021 14:16:33 -0600 Subject: [tc][all][ptl] Encouraging projects to apply for tag 'assert:supports-api-interoperability' In-Reply-To: <17671275da9.121a655b1251298.6157149575252344776@ghanshyammann.com> References: <17671275da9.121a655b1251298.6157149575252344776@ghanshyammann.com> Message-ID: <176fd648bd6.126a9266a1208370.2628135282566323654@ghanshyammann.com> Bumping this email in case you missed this during holiday time. There are many projects that are eligible for this tag, requesting you to start the application review to governance. -gmann ---- On Thu, 17 Dec 2020 08:42:53 -0600 Ghanshyam Mann wrote ---- > Hello Everyone, > > TC defined a tag for API interoperability (cover both stable and compatible APIs) called > 'assert:supports-api-interoperability' which assert on API won’t break any users when they > upgrade a cloud or start using their code on a new OpenStack cloud. > > Basically, Projects will not change (or remove) an API in a way that will break existing users > of an API. We have updated the tag documentation to clarify its definition and requirements. > > If your projects follow the API interoperability guidelines[1] and some API versioning mechanism > that does not need to be microversion then you should start thinking to apply for this tag. The > complete requirements can be found here[2]. > > Currently, only nova has this tag but I am sure many projects are eligible for this, and TC encourage > them to apply for this. > > [1] https://specs.openstack.org/openstack/api-wg/guidelines/api_interoperability.html > [2] https://governance.openstack.org/tc/reference/tags/assert_supports-api-interoperability.html > > > -gmann > From fungi at yuggoth.org Wed Jan 13 20:19:14 2021 From: fungi at yuggoth.org (Jeremy Stanley) Date: Wed, 13 Jan 2021 20:19:14 +0000 Subject: [all][dev] Beware how fun the new pip can be In-Reply-To: References: Message-ID: <20210113201914.tqqgxz7s474ve2lh@yuggoth.org> On 2021-01-13 20:36:06 +0100 (+0100), Radosław Piliszek wrote: [...] > As an example, I can give you [1] where we are experimenting with > getting some extracurricular package into our containers, notably > fluent-logger. The only dep of fluent-logger is msgpack but the > latest msgpack (as in upper constraints: 1.0.2, or any 1.x for > that matter) is not compatible. However, the pin was introduced in > fluent-logger in its 0.9.5 release (0.9.6 is the latest). [...] So just to clarify, your concern is that because you've tried to install newer msgpack, pip is selecting an older version of fluent-logger which doesn't declare an incompatibility with that newer version of msgpack. This seems technically correct. I'm willing to bet if you insisted on installing fluent-logger>0.9.5 you would get the behavior you're expecting. The underlying problem is that the package ecosystem has long based dependency versioning choices on side effect behaviors of pip's (lack of coherent) dep resolution. From the user side of things, if you want to install more than one package explicitly, you need to start specifying how new you want those packages to be. However surprising it is, pip seems to be working as intended here. -- Jeremy Stanley -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From radoslaw.piliszek at gmail.com Wed Jan 13 20:27:59 2021 From: radoslaw.piliszek at gmail.com (=?UTF-8?Q?Rados=C5=82aw_Piliszek?=) Date: Wed, 13 Jan 2021 21:27:59 +0100 Subject: [all][dev] Beware how fun the new pip can be In-Reply-To: <20210113201914.tqqgxz7s474ve2lh@yuggoth.org> References: <20210113201914.tqqgxz7s474ve2lh@yuggoth.org> Message-ID: On Wed, Jan 13, 2021 at 9:22 PM Jeremy Stanley wrote: > > On 2021-01-13 20:36:06 +0100 (+0100), Radosław Piliszek wrote: > [...] > > As an example, I can give you [1] where we are experimenting with > > getting some extracurricular package into our containers, notably > > fluent-logger. The only dep of fluent-logger is msgpack but the > > latest msgpack (as in upper constraints: 1.0.2, or any 1.x for > > that matter) is not compatible. However, the pin was introduced in > > fluent-logger in its 0.9.5 release (0.9.6 is the latest). > [...] > > So just to clarify, your concern is that because you've tried to > install newer msgpack, pip is selecting an older version of > fluent-logger which doesn't declare an incompatibility with that > newer version of msgpack. This seems technically correct. I'm > willing to bet if you insisted on installing fluent-logger>0.9.5 you > would get the behavior you're expecting. > > The underlying problem is that the package ecosystem has long based > dependency versioning choices on side effect behaviors of pip's > (lack of coherent) dep resolution. From the user side of things, if > you want to install more than one package explicitly, you need to > start specifying how new you want those packages to be. > > However surprising it is, pip seems to be working as intended here. Yes, it does! See my addendum as well. I will recap once more that I am not saying pip is doing anything wrong. Just BEWARE because you are most likely used to a different behaviour, just like me. Trying to use two conflicting constraints will make pip ERROR out and this is great now. I like new pip for this reason. But, as you mention, the ecosystem is not prepared. -yoctozepto From jp.methot at planethoster.info Wed Jan 13 20:54:20 2021 From: jp.methot at planethoster.info (=?utf-8?Q?Jean-Philippe_M=C3=A9thot?=) Date: Wed, 13 Jan 2021 15:54:20 -0500 Subject: [nova] Nova evacuate issue In-Reply-To: <20210107142638.3u2duxgdsrj5fe5y@lyarwood-laptop.usersys.redhat.com> References: <20210107142638.3u2duxgdsrj5fe5y@lyarwood-laptop.usersys.redhat.com> Message-ID: I was not able to find anything in the event list, possibly because the instance was recreated so its ID doesn’t exist anymore? Anyway, I did just create a bug report with as much info as I could, which is not much more than what I already posted in this mail chain. Hopefully we can get somewhere with this : https://bugs.launchpad.net/nova/+bug/1911474 Jean-Philippe Méthot Senior Openstack system administrator Administrateur système Openstack sénior PlanetHoster inc. 4414-4416 Louis B Mayer Laval, QC, H7P 0G1, Canada -------------- next part -------------- An HTML attachment was scrubbed... URL: From gmann at ghanshyammann.com Wed Jan 13 21:39:28 2021 From: gmann at ghanshyammann.com (Ghanshyam Mann) Date: Wed, 13 Jan 2021 15:39:28 -0600 Subject: [Watcher]stepping down as PTL In-Reply-To: <50e905b1.101f.176f99506f3.Coremail.licanwei_cn@163.com> References: <50e905b1.101f.176f99506f3.Coremail.licanwei_cn@163.com> Message-ID: <176fdb0764f.bf3138361210922.8265496414053290356@ghanshyammann.com> Thanks licanwei for your contribution to the Watcher project. Please propose this change to openstack/governance repo. Example: https://review.opendev.org/c/openstack/governance/+/770075 -gmann ---- On Tue, 12 Jan 2021 20:31:02 -0600 licanwei wrote ---- > Hi all, > For personal reason, I have no time to continue the work for Watcher PTL. My colleage, Chen Ke(irc:chenke) will temporarily replace me as PTL, thank you for your support. > > thanks, licanwei_cn > 邮箱：licanwei_cn at 163.com > 签名由 网易邮箱大师 定制 > From allison at openstack.org Wed Jan 13 23:03:02 2021 From: allison at openstack.org (Allison Price) Date: Wed, 13 Jan 2021 17:03:02 -0600 Subject: Only a few hours left: 2021 Board elections and Bylaws amendments Message-ID: <5126098E-790F-4129-8591-5C603FD176B2@openstack.org> Hi everyone, The 2021 Individual Director elections are currently open. All members who are eligible to vote should have received an email ballot earlier this week. You can review the candidates here: https://www.openstack.org/election/2021-individual-director-election/CandidateList . If you are not currently a member of the Open Infrastructure Foundation, you can join here to vote in next year’s elections: https://openinfra.dev/join This year, the election includes a set of amendments to the Foundation’s Bylaws. The amendments were approved unanimously by the Foundation Board in 2020. As a member class, the Individual Members must also approve these amendments. You can find more information in this mailing list post by Jonathan Bryce: http://lists.openstack.org/pipermail/foundation/2021-January/002939.html The deadline to vote is this Friday, January 15 at 1800 UTC / 12pm CST. Please let me know if you have any questions. Allison Allison Price Open Infrastructure Foundation allison at openstack.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From v at prokofev.me Thu Jan 14 00:39:29 2021 From: v at prokofev.me (Vladimir Prokofev) Date: Thu, 14 Jan 2021 03:39:29 +0300 Subject: [cinder] Review of tiny patch to add Ceph RBD fast-diff to cinder-backup In-Reply-To: <721b4405-b19f-5433-feff-d595442ce6e4@gmail.com> References: <721b4405-b19f-5433-feff-d595442ce6e4@gmail.com> Message-ID: I apologise if this is not the place to ask, but this question was actually bugging me for a long time now. Is there any particular reason fast-diff was disabled for backup images in the first place? Like, any actual technical limitation, i.e. "don't enable it or it will break your backups"? Or is it only because earlier versions of CEPH did not support fast-diff, so it was disabled for compatibility reasons? ср, 13 янв. 2021 г. в 16:40, Brian Rosmaita : > On 1/13/21 4:37 AM, Christian Rohmann wrote: > > Hey everyone, > > > > I wrote a tiny patch to add the Ceph RDB feature of fast-diff to backups > > created by cinder-backup: > > > > * https://review.opendev.org/c/openstack/cinder/+/766856/ > > > > > > Could someone please take a peek and let me know of this is sufficient > > to be merged? > > Thanks for raising awareness of your patch. Right now, the cinder team > is prioritizing new driver reviews in light of the impending merge > deadline at wallaby milestone-2 next week: > > > http://lists.openstack.org/pipermail/openstack-discuss/2021-January/019720.html > > So there may be a slight delay to your patch being reviewed. If you > have some time, you can always help things along by reviewing some small > patches by other authors. > > cheers, > brian > > > > > > > > > Thanks and with kind regards, > > > > > > Christian > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From eandersson at blizzard.com Thu Jan 14 04:47:31 2021 From: eandersson at blizzard.com (Erik Olof Gunnar Andersson) Date: Thu, 14 Jan 2021 04:47:31 +0000 Subject: [magnum][api] Error system library fopen too many open files with magnum-auto-healer In-Reply-To: References: <185a9715-4667-9610-0048-5434e6e2cd4e@catalyst.net.nz> , Message-ID: Thanks Ionut. If you are able could you test this patch instead. I think I better understand what the issue was now. We were not only creating a new RPC Client for each HTTP request, but also a brand-new transport for each request. https://review.opendev.org/c/openstack/magnum/+/770707 ________________________________ From: Ionut Biru Sent: Tuesday, January 12, 2021 3:17 AM To: Erik Olof Gunnar Andersson Cc: Spyros Trigazis ; feilong ; openstack-discuss Subject: Re: [magnum][api] Error system library fopen too many open files with magnum-auto-healer Hi Erik, Here it is: https://paste.xinu.at/LgH8dT/ On Mon, Jan 11, 2021 at 10:45 PM Erik Olof Gunnar Andersson > wrote: Thanks I added it to the commit. Could you share your uwsgi config as well. Best Regards, Erik Olof Gunnar Andersson Technical Lead, Senior Cloud Engineer From: Ionut Biru > Sent: Tuesday, January 5, 2021 1:51 AM To: Erik Olof Gunnar Andersson > Cc: Spyros Trigazis >; feilong >; openstack-discuss > Subject: Re: [magnum][api] Error system library fopen too many open files with magnum-auto-healer Hi, Here is my config. maybe something is fishy. I did have around 300 messages in the queue in notification.info and notification.err and I purged them. https://paste.xinu.at/woMt/ On Tue, Jan 5, 2021 at 11:23 AM Erik Olof Gunnar Andersson > wrote: Yea - tested locally as well and wasn't able to reproduce it either. I changed the health service job to run every second and maxed out at about 42 connections to RabbitMQ with two conductor workers. /etc/magnum/magnun.conf [conductor] workers = 2 ________________________________ From: Spyros Trigazis > Sent: Tuesday, January 5, 2021 12:59 AM To: Ionut Biru > Cc: Erik Olof Gunnar Andersson >; feilong >; openstack-discuss > Subject: Re: [magnum][api] Error system library fopen too many open files with magnum-auto-healer On Tue, Jan 5, 2021 at 9:36 AM Ionut Biru > wrote: Hi, I tried with process=1 and it reached 1016 connections to rabbitmq. lsof https://paste.xinu.at/jGg/ i think it goes into error when it reaches 1024 file descriptors. I'm out of ideas of how to resolve this. I only have 3 clusters available and it's kinda weird and It doesn't scale. No issues here with 100s of clusters. Not sure what doesn't scale. * Maybe your rabbit is flooded with notifications that are not consumed? * You can use way more than 1024 file descriptors, maybe 2^10? Spyros On Mon, Jan 4, 2021 at 9:53 PM Erik Olof Gunnar Andersson > wrote: Sure looks like RabbitMQ. How many workers do have you configured? Could you try to changing the uwsgi configuration to workers=1 (or processes=1) and then see if it goes beyond 30 connections to amqp. From: Ionut Biru > Sent: Monday, January 4, 2021 4:07 AM To: Erik Olof Gunnar Andersson > Cc: feilong >; openstack-discuss > Subject: Re: [magnum][api] Error system library fopen too many open files with magnum-auto-healer Hi Erik, Here is lsof of one uwsgi api. https://paste.xinu.at/5YUWf/ I have kubernetes 12.0.1 installed in env. On Sun, Jan 3, 2021 at 3:06 AM Erik Olof Gunnar Andersson > wrote: Maybe something similar to this? https://github.com/kubernetes-client/python/issues/1158 What does lsof say? -- Ionut Biru - https://fleio.com -- Ionut Biru - https://fleio.com -- Ionut Biru - https://fleio.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From skaplons at redhat.com Thu Jan 14 10:43:22 2021 From: skaplons at redhat.com (Slawek Kaplonski) Date: Thu, 14 Jan 2021 11:43:22 +0100 Subject: [neutron] Drivers meeting agenda for 15.01.2021 Message-ID: <20210114104322.fv77hnspeckqbsnm@p1.localdomain> Hi, For tomorrow's drivers meeting we have one new RFE to discuss: * https://bugs.launchpad.net/neutron/+bug/1911126 Spec for that is proposed already: https://review.opendev.org/c/openstack/neutron-specs/+/770540 See You on the meeting tomorrow :) -- Slawek Kaplonski Principal Software Engineer Red Hat -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: not available URL: From ionut at fleio.com Thu Jan 14 11:08:45 2021 From: ionut at fleio.com (Ionut Biru) Date: Thu, 14 Jan 2021 13:08:45 +0200 Subject: [magnum][api] Error system library fopen too many open files with magnum-auto-healer In-Reply-To: References: <185a9715-4667-9610-0048-5434e6e2cd4e@catalyst.net.nz> Message-ID: Hi Erik, Seems that this one works better than the previous one. I have 19 connections with this patch vs 38. I'll keep it for the following days. On Thu, Jan 14, 2021 at 6:47 AM Erik Olof Gunnar Andersson < eandersson at blizzard.com> wrote: > Thanks Ionut. > > If you are able could you test this patch instead. I think I better > understand what the issue was now. We were not only creating a new RPC > Client for each HTTP request, but also a brand-new transport for each > request. > https://review.opendev.org/c/openstack/magnum/+/770707 > > ------------------------------ > *From:* Ionut Biru > *Sent:* Tuesday, January 12, 2021 3:17 AM > *To:* Erik Olof Gunnar Andersson > *Cc:* Spyros Trigazis ; feilong < > feilong at catalyst.net.nz>; openstack-discuss < > openstack-discuss at lists.openstack.org> > *Subject:* Re: [magnum][api] Error system library fopen too many open > files with magnum-auto-healer > > Hi Erik, > > Here it is: https://paste.xinu.at/LgH8dT/ > > > On Mon, Jan 11, 2021 at 10:45 PM Erik Olof Gunnar Andersson < > eandersson at blizzard.com> wrote: > > Thanks I added it to the commit. > > > > Could you share your uwsgi config as well. > > > > Best Regards, Erik Olof Gunnar Andersson > > Technical Lead, Senior Cloud Engineer > > > > *From:* Ionut Biru > *Sent:* Tuesday, January 5, 2021 1:51 AM > *To:* Erik Olof Gunnar Andersson > *Cc:* Spyros Trigazis ; feilong < > feilong at catalyst.net.nz>; openstack-discuss < > openstack-discuss at lists.openstack.org> > *Subject:* Re: [magnum][api] Error system library fopen too many open > files with magnum-auto-healer > > > > Hi, > > > > Here is my config. maybe something is fishy. > > > > I did have around 300 messages in the queue in notification.info > > and notification.err and I purged them. > > > > https://paste.xinu.at/woMt/ > > > > > > > > > On Tue, Jan 5, 2021 at 11:23 AM Erik Olof Gunnar Andersson < > eandersson at blizzard.com> wrote: > > Yea - tested locally as well and wasn't able to reproduce it either. I > changed the health service job to run every second and maxed out at about > 42 connections to RabbitMQ with two conductor workers. > > /etc/magnum/magnun.conf > > [conductor] > > workers = 2 > > > ------------------------------ > > *From:* Spyros Trigazis > *Sent:* Tuesday, January 5, 2021 12:59 AM > *To:* Ionut Biru > *Cc:* Erik Olof Gunnar Andersson ; feilong < > feilong at catalyst.net.nz>; openstack-discuss < > openstack-discuss at lists.openstack.org> > *Subject:* Re: [magnum][api] Error system library fopen too many open > files with magnum-auto-healer > > > > > > > > On Tue, Jan 5, 2021 at 9:36 AM Ionut Biru wrote: > > Hi, > > > I tried with process=1 and it reached 1016 connections to rabbitmq. > > lsof > > https://paste.xinu.at/jGg/ > > > > > i think it goes into error when it reaches 1024 file descriptors. > > > > I'm out of ideas of how to resolve this. I only have 3 clusters available > and it's kinda weird and It doesn't scale. > > > > No issues here with 100s of clusters. Not sure what doesn't scale. > > > > * Maybe your rabbit is flooded with notifications that are not consumed? > > * You can use way more than 1024 file descriptors, maybe 2^10? > > > > Spyros > > > > On Mon, Jan 4, 2021 at 9:53 PM Erik Olof Gunnar Andersson < > eandersson at blizzard.com> wrote: > > Sure looks like RabbitMQ. How many workers do have you configured? > > > > Could you try to changing the uwsgi configuration to workers=1 (or > processes=1) and then see if it goes beyond 30 connections to amqp. > > > > *From:* Ionut Biru > *Sent:* Monday, January 4, 2021 4:07 AM > *To:* Erik Olof Gunnar Andersson > *Cc:* feilong ; openstack-discuss < > openstack-discuss at lists.openstack.org> > *Subject:* Re: [magnum][api] Error system library fopen too many open > files with magnum-auto-healer > > > > Hi Erik, > > > > Here is lsof of one uwsgi api. https://paste.xinu.at/5YUWf/ > > > > > I have kubernetes 12.0.1 installed in env. > > > > > > On Sun, Jan 3, 2021 at 3:06 AM Erik Olof Gunnar Andersson < > eandersson at blizzard.com> wrote: > > Maybe something similar to this? > https://github.com/kubernetes-client/python/issues/1158 > > > What does lsof say? > > > > > > > > > -- > > Ionut Biru - https://fleio.com > > > > > > -- > > Ionut Biru - https://fleio.com > > > > > -- > Ionut Biru - https://fleio.com > > -- Ionut Biru - https://fleio.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From hberaud at redhat.com Thu Jan 14 11:27:38 2021 From: hberaud at redhat.com (Herve Beraud) Date: Thu, 14 Jan 2021 12:27:38 +0100 Subject: [release] Status: ORANGE - pip resolver issue with publish-openstack-releasenotes-python3 In-Reply-To: References: Message-ID: Hello, @release managers: Just a heads-up to highlight projects that need to be approved carefully. I think we could improve our filtering by only considering the failing projects in the list of patched and unmerged projects: https://review.opendev.org/q/topic:%2522fix-relmgt-pip-doc%2522+(status:open) Most of these projects CI met a pip resolver issue, so if we release these projects without merging the associated patches we will fail at least with: - publish-openstack-releasenotes-python3 - publish-openstack-sphinx-doc Take a look to the following example: - https://review.opendev.org/c/openstack/os-service-types/+/769766 - https://zuul.opendev.org/t/openstack/build/53eec1ae61734bf39fb24a106920bbcf @ptl: Please ensure that your projects aren't in the list of failing projects and if so, please try to address the resolver issue in your requirements. Thanks for your reading PS: Notice that you can consider that this email is also a friendly reminder about the fact that we are still at the Orange level status :) Le jeu. 7 janv. 2021 à 17:53, Herve Beraud a écrit : > Hello everyone, > > @release managers: all impacted projects now have fixes submitted, so > before validating a patch you only have to ensure that the released > projects aren't in the list of opened patches: > > > https://review.opendev.org/q/topic:%2522fix-relmgt-pip-doc%2522+(status:open) > > I move our status to ORANGE as the situation seems improving for now and > also because we can easily monitor the state. > > @all: Notice that some projects have been ignored here because they aren't > released, here is the list: > > i18n > ideas > openstack-manuals > openstack-zuul-roles > os-apply-config > os-collect-config > os-refresh-config > ossa > pyeclib > security-analysis > security-doc > tempest-lib > tempest-stress > training-guides > workload-ref-archs > > However it could be worth it to uniformize them, but we leave it to the > teams to update them. > > Also notice that we proposed to add the capabilities to zuul to retrieve > requirements from a dedicated place: > > https://review.opendev.org/c/zuul/zuul-jobs/+/769292 > > It will help projects that haven't documentation but that produce release > notes to split their requirements more properly. > > If you've questions do not hesitate to ping us on #openstack-release > > Thanks for your reading > > Le mer. 6 janv. 2021 à 12:47, Herve Beraud a écrit : > >> @release mangaers: For now I think we can restart validating projects >> that aren't present in the previous list (c.f >> http://lists.openstack.org/pipermail/openstack-discuss/2021-January/019612.html >> ). >> Normally they aren't impacted by this problem. >> >> I'll move to the "Orange" state when all the projects of list will be >> patched or at least when a related patch will be present in the list (c.f >> https://review.opendev.org/q/topic:%2522fix-relmgt-pip-doc%2522+(status:open+OR+status:merged)). >> For now my monitoring indicates that ~50 projects still need related >> changes. >> >> So, for now, please, ensure that the repos aren't listed here before >> validate a patch >> http://lists.openstack.org/pipermail/openstack-discuss/2021-January/019612.html >> >> Thanks to everyone who helped here! Much appreciated! >> >> Le mar. 5 janv. 2021 à 12:05, Martin Chacon Piza >> a écrit : >> >>> Hi Herve, >>> >>> I have added this topic to the Monasca irc meeting today. >>> >>> Thank you, >>> Martin (chaconpiza) >>> >>> >>> >>> El lun, 4 de ene. de 2021 a la(s) 18:30, Herve Beraud ( >>> hberaud at redhat.com) escribió: >>> >>>> Thanks all! >>>> >>>> Here we can track our advancement: >>>> >>>> https://review.opendev.org/q/topic:%22fix-relmgt-pip-doc%22+(status:open%20OR%20status:merged) >>>> >>>> Le lun. 4 janv. 2021 à 18:02, Radosław Piliszek < >>>> radoslaw.piliszek at gmail.com> a écrit : >>>> >>>>> On Mon, Jan 4, 2021 at 4:34 PM Herve Beraud >>>>> wrote: >>>>> > >>>>> > Here is the filtered list of projects that meet the conditions >>>>> leading to the bug, and who should be fixed to completely solve our issue: >>>>> > >>>>> > ... >>>>> > etcd3gw >>>>> > ... >>>>> > python-masakariclient >>>>> > ... >>>>> > >>>>> > Notice that some of these projects aren't deliverables but if >>>>> possible it could be worth fixing them too. >>>>> > >>>>> > These projects have an incompatibility between entries in their >>>>> test-requirements.txt, and they're missing a doc/requirements.txt file. >>>>> > >>>>> > The more straightforward path to unlock our job >>>>> "publish-openstack-releasenotes-python3" is to create a >>>>> doc/requirements.txt file that only contains the needed dependencies to >>>>> reduce the possibility of pip resolver issues. I personally think that we >>>>> could use the latest allowed version of requirements (sphinx, reno, etc...). >>>>> > >>>>> > I propose to track the related advancement by using the >>>>> "fix-relmgt-pip-doc" gerrit topic, when all the projects will be fixed we >>>>> would be able to update our status. >>>>> > >>>>> > Also it could be worth fixing test-requirements.txt >>>>> incompatibilities but this task is more on the projects teams sides and >>>>> this task could be done with a follow up patch. >>>>> > >>>>> > Thoughts? >>>>> >>>>> Thanks, Hervé! >>>>> >>>>> Done for python-masakariclient in [1]. >>>>> >>>>> etcd3gw needs more love in general but I will have this split in mind. >>>>> >>>>> [1] >>>>> https://review.opendev.org/c/openstack/python-masakariclient/+/769163 >>>>> >>>>> -yoctozepto >>>>> >>>>> >>>> >>>> -- >>>> Hervé Beraud >>>> Senior Software Engineer at Red Hat >>>> irc: hberaud >>>> https://github.com/4383/ >>>> https://twitter.com/4383hberaud >>>> -----BEGIN PGP SIGNATURE----- >>>> >>>> wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ >>>> Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ >>>> RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP >>>> F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G >>>> 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g >>>> glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw >>>> m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ >>>> hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 >>>> qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y >>>> F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 >>>> B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O >>>> v6rDpkeNksZ9fFSyoY2o >>>> =ECSj >>>> -----END PGP SIGNATURE----- >>>> >>>> >>> >>> -- >>> *Martín Chacón Pizá* >>> *chacon.piza at gmail.com * >>> >> >> >> -- >> Hervé Beraud >> Senior Software Engineer at Red Hat >> irc: hberaud >> https://github.com/4383/ >> https://twitter.com/4383hberaud >> -----BEGIN PGP SIGNATURE----- >> >> wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ >> Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ >> RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP >> F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G >> 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g >> glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw >> m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ >> hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 >> qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y >> F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 >> B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O >> v6rDpkeNksZ9fFSyoY2o >> =ECSj >> -----END PGP SIGNATURE----- >> >> > > -- > Hervé Beraud > Senior Software Engineer at Red Hat > irc: hberaud > https://github.com/4383/ > https://twitter.com/4383hberaud > -----BEGIN PGP SIGNATURE----- > > wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ > Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ > RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP > F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G > 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g > glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw > m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ > hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 > qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y > F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 > B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O > v6rDpkeNksZ9fFSyoY2o > =ECSj > -----END PGP SIGNATURE----- > > -- Hervé Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/ https://twitter.com/4383hberaud -----BEGIN PGP SIGNATURE----- wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O v6rDpkeNksZ9fFSyoY2o =ECSj -----END PGP SIGNATURE----- -------------- next part -------------- An HTML attachment was scrubbed... URL: From openinfradn at gmail.com Thu Jan 14 11:44:07 2021 From: openinfradn at gmail.com (open infra) Date: Thu, 14 Jan 2021 17:14:07 +0530 Subject: Enabling KVM on Openstack Inbox In-Reply-To: <5adeeecde601ab7d774d0bf4e09d50083efbaf68.camel@redhat.com> References: <5adeeecde601ab7d774d0bf4e09d50083efbaf68.camel@redhat.com> Message-ID: Thank you Sean. On Thu, Jan 14, 2021 at 12:54 AM Sean Mooney wrote: > On Thu, 2021-01-14 at 00:02 +0530, open infra wrote: > > Hi > > > > (This mail has been sent to the community mailing list already, and I was > > suggested to reach out to this mailing list.) > > > > I have enabled KVM after deploying openstack single node setup. > > Following entries has been added to /etc/nova/nova.conf and then restart > > libvirtd.service and openstack-nova-compute.servic. > > > > compute_driver = libvirt.LibvirtDriver [libvirt] virt_type=kvm > > #virt_type=qemu > > > > # lsmod | grep kvm > > kvm_intel 188740 0 > > kvm 637289 1 kvm_intel > > irqbypass 13503 1 kvm > > > > > > I have disabled qemu in nova config and restarted the entire box > (including > > the base OS and the VM where I deployed Openstack. > > But still no luck. > > > > > > $ openstack hypervisor list > > > +----+------------------------+-----------------+----------------+-------+ > > > ID | Hypervisor Hostname | Hypervisor Type | Host IP | State > | > > > +----+------------------------+-----------------+----------------+-------+ > > > 1 | openstack.centos.local | QEMU | 192.168.122.63 | up > | > > > +----+------------------------+-----------------+----------------+-------+ > > > > I still can see Hypervisor Type as QEMU, when I issue openstack > hypervisor > > list command. > no that is expected > enableing kvm does not change the hypervior type > its still qemu its just using the kvm accleartion instead of the tsc > backend. > so that wont change but your vms should not change tehre domain type and > be using kvm. > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From stephenfin at redhat.com Thu Jan 14 11:51:34 2021 From: stephenfin at redhat.com (Stephen Finucane) Date: Thu, 14 Jan 2021 11:51:34 +0000 Subject: [ops][nova][designate] Does anyone rely on fully-qualified instance names? In-Reply-To: References: Message-ID: On Mon, 2020-11-30 at 11:51 +0000, Stephen Finucane wrote: > When attaching a port to an instance, nova will check for DNS support in neutron > and set a 'dns_name' attribute if found. To populate this attribute, nova uses a > sanitised version of the instance name, stored in the instance.hostname > attribute. This sanitisation simply strips out any unicode characters and > replaces underscores and spaces with dashes, before truncating to 63 characters. > It does not currently replace periods and this is the cause of bug 1581977 [1], > where an instance name such as 'ubuntu20.04' will fail to schedule since neutron > identifies '04' as an invalid TLD. > > The question now is what to do to resolve this. There are two obvious paths > available to us. The first is to simply catch these invalid hostnames and > replace them with an arbitrary hostname of format 'Server-{serverUUID}'. This is > what we currently do for purely unicode instance names and is what I've proposed > at [2]. The other option is to strip all periods, or rather replace them with > hyphens, when sanitizing the instance name. This is more predictable but breaks > the ability to use the instance name as a FQDN. Such usage is something I'm told > we've never supported, but I'm concerned that there are users out there who are > relying on this all the same and I'd like to get a feel for whether this is the > case first. > > So, the question: does anyone currently rely on this inadvertent "feature"? A quick update. I've reworked the change [1] such that it will always replace periods with hyphens. From the sounds of things, there are people who name their instance using FQDNs for management purposes but there does not appear to be anyone using the name published via the metadata service for DNS integration purposes. This makes replacing the periods the least complex solution to the immediate issue. A future change can look at exposing a way to configure this information via the API when creating a new instance. We might also want to change from stripping of unicode to replacement using punycode. If anyone missed this discussion the first time around and has concerns, please raise them here or on the review. Cheers, Stephen [1] https://review.opendev.org/c/openstack/nova/+/764482 > Cheers, > Stephen > > [1] https://launchpad.net/bugs/1581977 > [2] https://review.opendev.org/c/openstack/nova/+/764482 > From muhammad.ahsan991 at gmail.com Thu Jan 14 13:23:29 2021 From: muhammad.ahsan991 at gmail.com (ahsan ashraf) Date: Thu, 14 Jan 2021 18:23:29 +0500 Subject: Getting CPU Utilization null value Message-ID: Hi Team, I have been using openstack apis and have following issue: - API used: /servers/{server_id}/diagnostics - API version: v2.1 Problem: Couldn't get utilization value of my server it is showing null even i have applied stress on the cpu API Result: { "state": "running", "driver": "libvirt", "hypervisor": "kvm", "hypervisor_os": "linux", "uptime": 10020419, "config_drive": false, "num_cpus": 2, "num_nics": 1, "num_disks": 2, "disk_details": [ { "read_bytes": 983884800, "read_requests": 26229, "write_bytes": 7373907456, "write_requests": 574537, "errors_count": -1 }, { "read_bytes": 3215872, "read_requests": 147, "write_bytes": 0, "write_requests": 0, "errors_count": -1 } ], "cpu_details": [ { "id": 0, "time": 12424380000000, "utilisation": null }, { "id": 1, "time": 12775460000000, "utilisation": null } ], "nic_details": [ { "mac_address": "fa:16:3e:0e:c7:f2", "rx_octets": 943004980, "rx_errors": 0, "rx_drop": 0, "rx_packets": 4464445, "rx_rate": null, "tx_octets": 785254710, "tx_errors": 0, "tx_drop": 0, "tx_packets": 4696786, "tx_rate": null } ], "memory_details": { "maximum": 2, "used": 2 } } Regards, Muhammad Ahsan -------------- next part -------------- An HTML attachment was scrubbed... URL: From stephenfin at redhat.com Thu Jan 14 13:49:57 2021 From: stephenfin at redhat.com (Stephen Finucane) Date: Thu, 14 Jan 2021 13:49:57 +0000 Subject: Getting CPU Utilization null value In-Reply-To: References: Message-ID: <7dfeb6b8ad3419ff4e9168adf50015b4ccc26c47.camel@redhat.com> On Thu, 2021-01-14 at 18:23 +0500, ahsan ashraf wrote: > Hi Team, > I have been using openstack apis and have following issue: > * API used: /servers/{server_id}/diagnostics > * API version: v2.1 > Problem: Couldn't get utilization value of my server it is showing null even i > have applied stress on the cpu  This feature is specific to certain virt drivers. Only the XenAPI virt driver supported reporting this metric and this driver was removed from nova in the Victoria release, meaning there are no longer any in-tree drivers with support for this. The libvirt driver, which I suspect you're using here, reports ID and time but not utilization. Hope this helps, Stephen > API Result: > { "state": "running", "driver": "libvirt", "hypervisor": "kvm", > "hypervisor_os": "linux", "uptime": 10020419, "config_drive": false, > "num_cpus": 2, "num_nics": 1, "num_disks": 2, "disk_details": [ { > "read_bytes": 983884800, "read_requests": 26229, "write_bytes": 7373907456, > "write_requests": 574537, "errors_count": -1 }, { "read_bytes": 3215872, > "read_requests": 147, "write_bytes": 0, "write_requests": 0, "errors_count": - > 1 } ], "cpu_details": [ { "id": 0, "time": 12424380000000, "utilisation": null > }, { "id": 1, "time": 12775460000000, "utilisation": null } ], "nic_details": > [ { "mac_address": "fa:16:3e:0e:c7:f2", "rx_octets": 943004980, "rx_errors": > 0, "rx_drop": 0, "rx_packets": 4464445, "rx_rate": null, "tx_octets": > 785254710, "tx_errors": 0, "tx_drop": 0, "tx_packets": 4696786, "tx_rate": > null } ], "memory_details": { "maximum": 2, "used": 2 } } > > Regards, > Muhammad Ahsan -------------- next part -------------- An HTML attachment was scrubbed... URL: From amoralej at redhat.com Thu Jan 14 15:43:35 2021 From: amoralej at redhat.com (Alfredo Moralejo Alonso) Date: Thu, 14 Jan 2021 16:43:35 +0100 Subject: [RDO][CentOS] RDO plans to move to CentOS Stream Message-ID: Hi, As you know, CentOS announced recently that they will be focusing on CentOS Stream [1] and that CentOS Linux 8 will be EOL at the end of 2021 [2]. In order to align with this change, the RDO project is adapting the roadmap for the current and upcoming releases: - RDO Wallaby (ETA is end of April 2021 [3]) will be built, tested and released only for CentOS 8 Stream. - RDO CloudSIG repos for Victoria and Ussuri will be updated and tested for both CentOS Stream and CentOS Linux 8 until end of 2021 and then continue on CentOS Stream. - In the upcoming weeks, we will create new RDO CloudSIG repos for Victoria and Ussuri for CentOS Stream 8. - RDO Trunk repositories (aka DLRN repos) will be built and tested using CentOS 8 Stream for all releases currently using CentOS Linux 8 (starting with Train). If you are interested in the details about these plans and how we plan to implement it, we've created a blog post [4]. Don't hesitate to ask us in the ML or in the #rdo channel on freenode if you have questions or suggestions about this. We are also organizing a video AMA about RDO and CentOS Stream on Thursday Jan 21 1600 UTC in the RDO Meet room https://meet.google.com/uzo-tfkt-top On behalf of RDO, Alfredo [1] https://centos.org/distro-faq/ [2] https://blog.centos.org/2020/12/future-is-centos-stream/ [3] https://releases.openstack.org/ [4] https://blogs.rdoproject.org/2021/01/rdo-plans-to-move-to-centos-stream/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From smooney at redhat.com Thu Jan 14 15:45:35 2021 From: smooney at redhat.com (Sean Mooney) Date: Thu, 14 Jan 2021 15:45:35 +0000 Subject: Getting CPU Utilization null value In-Reply-To: <7dfeb6b8ad3419ff4e9168adf50015b4ccc26c47.camel@redhat.com> References: <7dfeb6b8ad3419ff4e9168adf50015b4ccc26c47.camel@redhat.com> Message-ID: On Thu, 2021-01-14 at 13:49 +0000, Stephen Finucane wrote: > On Thu, 2021-01-14 at 18:23 +0500, ahsan ashraf wrote: > > Hi Team, > > I have been using openstack apis and have following issue: > > * API used: /servers/{server_id}/diagnostics > > * API version: v2.1 > > Problem: Couldn't get utilization value of my server it is showing null even i > > have applied stress on the cpu  > This feature is specific to certain virt drivers. Only the XenAPI virt driver > supported reporting this metric and this driver was removed from nova in the > Victoria release, meaning there are no longer any in-tree drivers with support > for this. The libvirt driver, which I suspect you're using here, reports ID and > time but not utilization. so technically we have the ablity to plug in metric monitors for this. we have a cpu monitor avaihble https://github.com/openstack/nova/blob/master/nova/compute/monitors/cpu/virt_driver.py but that is based on the host cpu utilisation which is why we dont hook that up to this api. there was also a numa mem bandwith one proposed at one point https://review.opendev.org/c/openstack/nova/+/270344 they can be use with the metrics filter and since this is a stevadore entroy point you can write your own. since that data is nto hooked up to the diagnostics endpoint we dont have that info in the api responce. i belive we can get a per instace view from libvirt too so the libvirt driver could provide some of this info but it was never implemeted. there is a performace overhad to collecting that info however so we support disabling the PMU in the guest to reduce that. that normally only important for realtime instances. when its disabled there is no way for libvirt to get this info form qemu as far as i know. in anycase i agree with stephn that htis is not expected to work for libvirt currently. > > Hope this helps, > Stephen > > > API Result: > > { "state": "running", "driver": "libvirt", "hypervisor": "kvm", > > "hypervisor_os": "linux", "uptime": 10020419, "config_drive": false, > > "num_cpus": 2, "num_nics": 1, "num_disks": 2, "disk_details": [ { > > "read_bytes": 983884800, "read_requests": 26229, "write_bytes": 7373907456, > > "write_requests": 574537, "errors_count": -1 }, { "read_bytes": 3215872, > > "read_requests": 147, "write_bytes": 0, "write_requests": 0, "errors_count": - > > 1 } ], "cpu_details": [ { "id": 0, "time": 12424380000000, "utilisation": null > > }, { "id": 1, "time": 12775460000000, "utilisation": null } ], "nic_details": > > [ { "mac_address": "fa:16:3e:0e:c7:f2", "rx_octets": 943004980, "rx_errors": > > 0, "rx_drop": 0, "rx_packets": 4464445, "rx_rate": null, "tx_octets": > > 785254710, "tx_errors": 0, "tx_drop": 0, "tx_packets": 4696786, "tx_rate": > > null } ], "memory_details": { "maximum": 2, "used": 2 } } > > > > Regards, > > Muhammad Ahsan > From juliaashleykreger at gmail.com Thu Jan 14 16:08:25 2021 From: juliaashleykreger at gmail.com (Julia Kreger) Date: Thu, 14 Jan 2021 08:08:25 -0800 Subject: [ironic] virtual midcycle Message-ID: Greetings awesome humans, We in the lands of baremetal and irony (err... Ironic, but you get the idea) have been discussing having a virtual midcycle in the next few weeks to help sort through some items and enable us to prioritize the remainder of the development cycle. I've created an etherpad[0], and a doodle poll[1]. Please keep in mind we have active contributors across the globe at this time, so if anyone feels like we need more time windows, please let me know. I'm hoping to schedule the midcycle by early next week. Additional topics are welcome on the etherpad. We will use that to identify how much time we should try and schedule. Thanks everyone! [0] https://etherpad.opendev.org/p/ironic-wallaby-midcycle [1] https://doodle.com/poll/y9afrz6hhq7s23km?utm_source=poll&utm_medium=link From rodrigo.barbieri2010 at gmail.com Thu Jan 14 16:50:03 2021 From: rodrigo.barbieri2010 at gmail.com (Rodrigo Barbieri) Date: Thu, 14 Jan 2021 13:50:03 -0300 Subject: [nova] workarounds and operator experience around bug 1522307/1908133 In-Reply-To: <98fb643dc6ec0d0201c8e4aea114cd07cf46fef7.camel@redhat.com> References: <7b4f6f10e682698dfaed22a86397f5b174fed7e8.camel@redhat.com> <20210106134822.Horde.dGo06NkPF_G8_AogeK9L2i7@webmail.nde.ag> <98fb643dc6ec0d0201c8e4aea114cd07cf46fef7.camel@redhat.com> Message-ID: Hello there, Thanks Sean for the suggestions. I've tested them and reported my findings in https://bugs.launchpad.net/nova/+bug/1908133 Your links helped me a lot of figuring out that my placement aggregates were set up incorrectly, and the fake reservation worked slightly better than the reserved_host_disk_mb (more details on that in the bug update). And it works very well on Rocky+, so that's very good. This problem is now much more manageable, thanks for the suggestions! Regards, On Fri, Jan 8, 2021 at 7:13 PM Sean Mooney wrote: > On Fri, 2021-01-08 at 18:27 -0300, Rodrigo Barbieri wrote: > > Thanks for the responses Eugen and Sean! > > > > The placement.yaml approach sounds good if it can prevent the compute > host > > from reporting local_gb repeatedly, and then as you suggested use > Placement > > Aggregates I can perhaps make that work for a subset of use cases. Too > bad > > it is only available on Victoria+. I was looking for something that could > > work, even if partially, on Queens and Stein. > > > > The cron job updating the reservation, I'm not sure if it will clash with > > the host updates (being overriden, as I've described in the LP bug), but > > you actually gave me another idea. I may be able to create a fake > > allocation in the nodes to cancel out their reported values, and then > rely > > only on the shared value through placement. > well actully you could use the host reserved disk space config value to do > that on older releases > just set it equal to the pool size. > > https://docs.openstack.org/nova/latest/configuration/config.html#DEFAULT.reserved_host_disk_mb > not sure why that is in MB it really should be GB but anyway if you set > that then it will set the placement value. > > > > > Monitoring Ceph is only part of the problem. The second part, if you end > up > > needing it (and you may if you're not very conservative in the monitoring > > parameters and have unpredictable workload) is to prevent new instances > > from being created, thus new data from being stored, to prevent it from > > filling up before you can react to it (think of an accidental DoS attack > by > > running a certain storage-heavy workloads). > > > > @Eugen, yes. I was actually looking for more reliable ways to prevent it > > from happening. > > > > Overall, the shared placement + fake allocation sounded like the cleanest > > workaround for me. I will try that and report back. > > if i get time in the next week or two im hoping ot try and tweak our ceph > ci job to test > that toplogy in the upstream ci. but just looking a the placemnt > funcitonal tests it should work. > > This covers the use of sharing resouce providers > > https://github.com/openstack/placement/blob/master/placement/tests/functional/gabbits/shared-resources.yaml > > the final section thes the allocation candiate endpoint and asserts we > getan allocation for both providres > > https://github.com/openstack/placement/blob/master/placement/tests/functional/gabbits/shared-resources.yaml#L135-L143 > > its relitivly simple to read this file top to bottom and its only 143 > lines long but it basically step > through and constucte the topolgoy i was descifbing or at least a similar > ones and shows step by step what > the different behavior will be as the rps are created and aggreates are > created exctra. > > the main issue with this approch is we dont really have a good way to > upgrade existing deployments to this toplogy beyond > live migrating everything one node at a time so that there allcoation will > get reshaped as a side effect of the move operation. > > looking a tthe history of this file it was added 3 years ago > https://github.com/openstack/placement/commit/caeae7a41ed41535195640dfa6c5bb58a7999a9b > around stien although it may also have worked before thatim not sure when > we added sharing providers. > > > > > Thanks for the help! > > > > On Wed, Jan 6, 2021 at 10:57 AM Eugen Block wrote: > > > > > Hi, > > > > > > we're using OpenStack with Ceph in production and also have customers > > > doing that. > > > From my point of view fixing nova to be able to deal with shared > > > storage of course would improve many things, but it doesn't liberate > > > you from monitoring your systems. Filling up a ceph cluster should be > > > avoided and therefore proper monitoring is required. > > > > > > I assume you were able to resolve the frozen instances? > > > > > > Regards, > > > Eugen > > > > > > > > > Zitat von Sean Mooney : > > > > > > > On Tue, 2021-01-05 at 14:17 -0300, Rodrigo Barbieri wrote: > > > > > Hi Nova folks and OpenStack operators! > > > > > > > > > > I have had some trouble recently where while using the > "images_type = > > > rbd" > > > > > libvirt option my ceph cluster got filled up without I noticing and > > > froze > > > > > all my nova services and instances. > > > > > > > > > > I started digging and investigating why and how I could prevent or > > > > > workaround this issue, but I didn't find a very reliable clean way. > > > > > > > > > > I documented all my steps and investigation in bug 1908133 [0]. It > has > > > been > > > > > marked as a duplicate of 1522307 [1] which has been around for > quite > > > some > > > > > time, so I am wondering if any operators have been using nova + > ceph in > > > > > production with "images_type = rbd" config set and how you have > been > > > > > handling/working around the issue. > > > > > > > > this is indeed a know issue and the long term plan to fix it was to > > > > track shared storae > > > > as a sharing resouce provide in plamcent. that never happend so > > > > there si currenlty no mechanium > > > > available to prevent this explcitly in nova. > > > > > > > > the disk filter which is nolonger used could prevnet the boot of a > > > > vm that would fill the ceph pool but > > > > it could not protect against two concurrent request form filling the > > > pool. > > > > > > > > placement can protect against that due to the transational nature of > > > > allocations which serialise > > > > all resouce useage however since each host reports the total size of > > > > the ceph pool as its local storage that wont work out of the box. > > > > > > > > as a quick hack what you can do is set the > > > > [DEFAULT]/disk_allocation_ratio=(1/number of compute nodes) > > > > > > > > https://docs.openstack.org/nova/latest/configuration/config.html#DEFAULT.disk_allocation_ratio > > > > on each of your compute agents configs. > > > > > > > > > > > > that will prevent over subscription however it has other negitve > > > sidefects. > > > > mainly that you will fail to scudle instance that could boot if a > > > > host exced its 1/n usage > > > > so unless you have perfectly blanced consumtion this is not a good > > > approch. > > > > > > > > a better appoch but one that requires external scripting is to have > > > > a chron job that will update the resrved > > > > usaage of each of the disk_gb inventores to the actull amount of of > > > > stoarge allocated form the pool. > > > > > > > > the real fix however is for nova to tack its shared usage in > > > > placment correctly as a sharing resouce provide. > > > > > > > > its possible you might be able to do that via the porvider.yaml file > > > > > > > > by overriding the local disk_gb to 0 on all comupte nodes > > > > then creating a singel haring resouce provider of disk_gb that > > > > models the ceph pool. > > > > > > > > > > > > https://specs.openstack.org/openstack/nova-specs/specs/ussuri/approved/provider-config-file.html > > > > currently that does not support the addtion of providers to placment > > > > agggreate so while it could be used to 0 out the comptue node > > > > disk inventoies and to create a sharing provider it with the > > > > MISC_SHARES_VIA_AGGREGATE trait it cant do the final step of mapping > > > > which compute nodes can consume form sharing provider via the > > > > agggrate but you could do that form. > > > > that assume that "sharing resouce provdiers" actully work. > > > > > > > > > > > > bacialy what it comes down to today is you need to monitor the > > > > avaiable resouce yourslef externally and ensure you never run out of > > > > space. > > > > that sucks but untill we proably track things in plamcent there is > > > > nothign we can really do. > > > > the two approch i suggested above might work for a subset of > > > > usecasue but really this is a feature that need native suport in > > > > nova to adress properly. > > > > > > > > > > > > > > Thanks in advance! > > > > > > > > > > [0] https://bugs.launchpad.net/nova/+bug/1908133 > > > > > [1] https://bugs.launchpad.net/nova/+bug/1522307 > > > > > > > > > > > > > > > > > > > > > > > > > > -- Rodrigo Barbieri MSc Computer Scientist OpenStack Manila Core Contributor Federal University of São Carlos -------------- next part -------------- An HTML attachment was scrubbed... URL: From smooney at redhat.com Thu Jan 14 17:15:38 2021 From: smooney at redhat.com (Sean Mooney) Date: Thu, 14 Jan 2021 17:15:38 +0000 Subject: [nova] workarounds and operator experience around bug 1522307/1908133 In-Reply-To: References: <7b4f6f10e682698dfaed22a86397f5b174fed7e8.camel@redhat.com> <20210106134822.Horde.dGo06NkPF_G8_AogeK9L2i7@webmail.nde.ag> <98fb643dc6ec0d0201c8e4aea114cd07cf46fef7.camel@redhat.com> Message-ID: <83cd20278b68a8e6ec25f2d99bb33e96a34e6d8d.camel@redhat.com> On Thu, 2021-01-14 at 13:50 -0300, Rodrigo Barbieri wrote: > Hello there, > > Thanks Sean for the suggestions. I've tested them and reported my findings > in https://bugs.launchpad.net/nova/+bug/1908133 > > Your links helped me a lot of figuring out that my placement aggregates > were set up incorrectly, and the fake reservation worked slightly better > than the reserved_host_disk_mb (more details on that in the bug update). > And it works very well on Rocky+, so that's very good. > > This problem is now much more manageable, thanks for the suggestions! im glad to hear it worked. im still hoping to see if i can configure our ceph multi node job to replciate this shared provider configuretion in our ci and test it but i likely wont get to that untill after feature freeze at m3. assuming i can get it to work there too we can docudment a procedure for how to do this and next cycle we can consider if there is a clean way to automate the process. thanks for updateing the bug with your findings :) > > Regards, > > On Fri, Jan 8, 2021 at 7:13 PM Sean Mooney wrote: > > > On Fri, 2021-01-08 at 18:27 -0300, Rodrigo Barbieri wrote: > > > Thanks for the responses Eugen and Sean! > > > > > > The placement.yaml approach sounds good if it can prevent the compute > > host > > > from reporting local_gb repeatedly, and then as you suggested use > > Placement > > > Aggregates I can perhaps make that work for a subset of use cases. Too > > bad > > > it is only available on Victoria+. I was looking for something that could > > > work, even if partially, on Queens and Stein. > > > > > > The cron job updating the reservation, I'm not sure if it will clash with > > > the host updates (being overriden, as I've described in the LP bug), but > > > you actually gave me another idea. I may be able to create a fake > > > allocation in the nodes to cancel out their reported values, and then > > rely > > > only on the shared value through placement. > > well actully you could use the host reserved disk space config value to do > > that on older releases > > just set it equal to the pool size. > > > > https://docs.openstack.org/nova/latest/configuration/config.html#DEFAULT.reserved_host_disk_mb > > not sure why that is in MB it really should be GB but anyway if you set > > that then it will set the placement value. > > > > > > > > Monitoring Ceph is only part of the problem. The second part, if you end > > up > > > needing it (and you may if you're not very conservative in the monitoring > > > parameters and have unpredictable workload) is to prevent new instances > > > from being created, thus new data from being stored, to prevent it from > > > filling up before you can react to it (think of an accidental DoS attack > > by > > > running a certain storage-heavy workloads). > > > > > > @Eugen, yes. I was actually looking for more reliable ways to prevent it > > > from happening. > > > > > > Overall, the shared placement + fake allocation sounded like the cleanest > > > workaround for me. I will try that and report back. > > > > if i get time in the next week or two im hoping ot try and tweak our ceph > > ci job to test > > that toplogy in the upstream ci. but just looking a the placemnt > > funcitonal tests it should work. > > > > This covers the use of sharing resouce providers > > > > https://github.com/openstack/placement/blob/master/placement/tests/functional/gabbits/shared-resources.yaml > > > > the final section thes the allocation candiate endpoint and asserts we > > getan allocation for both providres > > > > https://github.com/openstack/placement/blob/master/placement/tests/functional/gabbits/shared-resources.yaml#L135-L143 > > > > its relitivly simple to read this file top to bottom and its only 143 > > lines long but it basically step > > through and constucte the topolgoy i was descifbing or at least a similar > > ones and shows step by step what > > the different behavior will be as the rps are created and aggreates are > > created exctra. > > > > the main issue with this approch is we dont really have a good way to > > upgrade existing deployments to this toplogy beyond > > live migrating everything one node at a time so that there allcoation will > > get reshaped as a side effect of the move operation. > > > > looking a tthe history of this file it was added 3 years ago > > https://github.com/openstack/placement/commit/caeae7a41ed41535195640dfa6c5bb58a7999a9b > > around stien although it may also have worked before thatim not sure when > > we added sharing providers. > > > > > > > > Thanks for the help! > > > > > > On Wed, Jan 6, 2021 at 10:57 AM Eugen Block wrote: > > > > > > > Hi, > > > > > > > > we're using OpenStack with Ceph in production and also have customers > > > > doing that. > > > >  From my point of view fixing nova to be able to deal with shared > > > > storage of course would improve many things, but it doesn't liberate > > > > you from monitoring your systems. Filling up a ceph cluster should be > > > > avoided and therefore proper monitoring is required. > > > > > > > > I assume you were able to resolve the frozen instances? > > > > > > > > Regards, > > > > Eugen > > > > > > > > > > > > Zitat von Sean Mooney : > > > > > > > > > On Tue, 2021-01-05 at 14:17 -0300, Rodrigo Barbieri wrote: > > > > > > Hi Nova folks and OpenStack operators! > > > > > > > > > > > > I have had some trouble recently where while using the > > "images_type = > > > > rbd" > > > > > > libvirt option my ceph cluster got filled up without I noticing and > > > > froze > > > > > > all my nova services and instances. > > > > > > > > > > > > I started digging and investigating why and how I could prevent or > > > > > > workaround this issue, but I didn't find a very reliable clean way. > > > > > > > > > > > > I documented all my steps and investigation in bug 1908133 [0]. It > > has > > > > been > > > > > > marked as a duplicate of 1522307 [1] which has been around for > > quite > > > > some > > > > > > time, so I am wondering if any operators have been using nova + > > ceph in > > > > > > production with "images_type = rbd" config set and how you have > > been > > > > > > handling/working around the issue. > > > > > > > > > > this is indeed a know issue and the long term plan to fix it was to > > > > > track shared storae > > > > > as a sharing resouce provide in plamcent. that never happend so > > > > > there si currenlty no mechanium > > > > > available to prevent this explcitly in nova. > > > > > > > > > > the disk filter which is nolonger used could prevnet the boot of a > > > > > vm that would fill the ceph pool but > > > > > it could not protect against two concurrent request form filling the > > > > pool. > > > > > > > > > > placement can protect against that due to the transational nature of > > > > > allocations which serialise > > > > > all resouce useage however since each host reports the total size of > > > > > the ceph pool as its local storage that wont work out of the box. > > > > > > > > > > as a quick hack what you can do is set the > > > > > [DEFAULT]/disk_allocation_ratio=(1/number of compute nodes) > > > > > > > > > > > https://docs.openstack.org/nova/latest/configuration/config.html#DEFAULT.disk_allocation_ratio > > > > > on each of your compute agents configs. > > > > > > > > > > > > > > > that will prevent over subscription however it has other negitve > > > > sidefects. > > > > > mainly that you will fail to scudle instance that could boot if a > > > > > host exced its 1/n usage > > > > > so unless you have perfectly blanced consumtion this is not a good > > > > approch. > > > > > > > > > > a better appoch but one that requires external scripting is to have > > > > > a chron job that will update the resrved > > > > >  usaage of each of the disk_gb inventores to the actull amount of of > > > > > stoarge allocated form the pool. > > > > > > > > > > the real fix however is for nova to tack its shared usage in > > > > > placment correctly as a sharing resouce provide. > > > > > > > > > > its possible you might be able to do that via the porvider.yaml file > > > > > > > > > > by overriding the local disk_gb to 0 on all comupte nodes > > > > > then creating a singel haring resouce provider of disk_gb that > > > > > models the ceph pool. > > > > > > > > > > > > > > > > https://specs.openstack.org/openstack/nova-specs/specs/ussuri/approved/provider-config-file.html > > > > > currently that does not support the addtion of providers to placment > > > > > agggreate so while it could be used to 0 out the comptue node > > > > > disk inventoies and to create a sharing provider it with the > > > > > MISC_SHARES_VIA_AGGREGATE trait it cant do the final step of mapping > > > > > which compute nodes can consume form sharing provider via the > > > > > agggrate but you could do that form. > > > > > that assume that "sharing resouce provdiers" actully work. > > > > > > > > > > > > > > > bacialy what it comes down to today is you need to monitor the > > > > > avaiable resouce yourslef externally and ensure you never run out of > > > > > space. > > > > > that sucks but untill we proably track things in plamcent there is > > > > > nothign we can really do. > > > > > the two approch i suggested above might work for a subset of > > > > > usecasue but really this is a feature that need native suport in > > > > > nova to adress properly. > > > > > > > > > > > > > > > > > Thanks in advance! > > > > > > > > > > > > [0] https://bugs.launchpad.net/nova/+bug/1908133 > > > > > > [1] https://bugs.launchpad.net/nova/+bug/1522307 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From ryan at messagecloud.com Thu Jan 14 17:17:27 2021 From: ryan at messagecloud.com (Ryan Price-King) Date: Thu, 14 Jan 2021 17:17:27 +0000 Subject: Cannot login to Built trovestack image In-Reply-To: References: Message-ID: Hi, Sorry for the delay, I had time off and had to research what the issues were. Your doc really helped to get the SSH working on the instance, by creating a keypair in the services project and referencing it. With that I was able to diagnose many issues I faced. The image I initially built was not working properly for a start. Now I can successfully build a trove DB on OpenStack. Yay me lol. I do have other issues though that the trove database is not showing the floating IP and I need to get it working with designate properly, but I am on the right track now. This seemed like the best way for me to get a working image: https://www.server-world.info/en/note?os=CentOS_8&p=openstack_victoria3&f=15 Thank-you very much for your help :) Regards, Ryan On Fri, 8 Jan 2021 at 02:25, Lingxian Kong wrote: > In this case, we need to check the trove-guestagent log. For how to ssh > into the guest instance, > https://docs.openstack.org/trove/latest/admin/troubleshooting.html > > You can also jump into #openstack-trove IRC channel we could have a chat > there. > > --- > Lingxian Kong > Senior Software Engineer > Catalyst Cloud > www.catalystcloud.nz > > > On Fri, Jan 8, 2021 at 1:34 PM Ryan Price-King > wrote: > >> Hi, >> >> Sorry I should have clarified. The build step I am stuck on is while >> spinning up the trove database on openstack horizon. I have built the qcow >> image fine. Also, I can view the login prompt of the trove instance that >> was created when creating a trove database. So it seems the agent is not >> running in the instance properly. >> >> I have read that document lots and need to login to the image to see the >> files and Ubuntu Ubuntu doesnt work. >> >> Regards, >> Ryan >> >> On 8 Jan 2021 at 00:16, Lingxian Kong wrote: >> >> Hi, >> >> Have you read >> https://docs.openstack.org/trove/latest/admin/building_guest_images.html? >> >> --- >> Lingxian Kong >> Senior Software Engineer >> Catalyst Cloud >> www.catalystcloud.nz >> >> >> On Fri, Jan 8, 2021 at 10:09 AM Ryan Price-King >> wrote: >> >>> Hi, >>> >>> Sorry I meant the instance is being deployed in nova correctly and >>> entering running state and console gives me login screen. >>> >>> Regards, >>> Ryan >>> >>> On Thu, 7 Jan 2021 at 17:14, Ryan Price-King >>> wrote: >>> >>>> Hi, >>>> >>>> I am having problems with the image being deployed correctly with nova, >>>> but the communication to the guestagent is timing out and i am stuck in >>>> build stage. >>>> >>>> ./trovestack build-image ubuntu bionic true ubuntu >>>> >>>> >>>> Also with that, I dont know which mysql version it is building. >>>> >>>> I am assuming it is 5.7.29. >>>> >>>> I cannot diagnose as i cannot login to the guest image instance. >>>> >>>> I assume the user is ubuntu, but i cannot login with any password that >>>> i have tried. >>>> >>>> Can you tell me what username/password to login to the instance by >>>> console in openstack please. >>>> >>>> Regards, >>>> Ryan >>>> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From shubjero at gmail.com Thu Jan 14 19:59:16 2021 From: shubjero at gmail.com (shubjero) Date: Thu, 14 Jan 2021 14:59:16 -0500 Subject: Trying to resolve 2 deprecation warnings Message-ID: Hi all, I am trying to resolve two deprecation warnings which I've not been able to locate exactly what package or file is causing them. We are running OpenStack Train on Ubuntu 18.04 The log entries are found in /etc/apache2/cinder_error.log : 2021-01-06 15:54:05.332604 /usr/lib/python3/dist-packages/oslo_context/context.py:108: DeprecationWarning: Policy enforcement is depending on the value of is_admin. This key is deprecated. Please update your policy file to use the standard policy values. 2021-01-06 15:54:20.147590 /usr/lib/python3/dist-packages/webob/acceptparse.py:1051: DeprecationWarning: The behavior of AcceptValidHeader.best_match is currently being maintained for backward compatibility, but it will be deprecated in the future, as it does not conform to the RFC. Any help on what needs to be changed/removed/updated/upgraded would be appreciated. Thanks! Jared Ontario Institute for Cancer Research From rlandy at redhat.com Thu Jan 14 21:25:41 2021 From: rlandy at redhat.com (Ronelle Landy) Date: Thu, 14 Jan 2021 16:25:41 -0500 Subject: [RDO][CentOS] RDO plans to move to CentOS Stream In-Reply-To: References: Message-ID: On Thu, Jan 14, 2021 at 10:45 AM Alfredo Moralejo Alonso < amoralej at redhat.com> wrote: > Hi, > Alfredo, thanks for posting this CentOS 8 stream related release info. > > As you know, CentOS announced recently that they will be focusing on > CentOS Stream [1] and that CentOS Linux 8 will be EOL at the end of 2021 > [2]. > > In order to align with this change, the RDO project is adapting the > roadmap for the current and upcoming releases: > > - RDO Wallaby (ETA is end of April 2021 [3]) will be built, tested and > released only for CentOS 8 Stream. > - RDO CloudSIG repos for Victoria and Ussuri will be updated and tested > for both CentOS Stream and CentOS Linux 8 until end of 2021 and then > continue on CentOS Stream. > - In the upcoming weeks, we will create new RDO CloudSIG repos for > Victoria and Ussuri for CentOS Stream 8. > - RDO Trunk repositories (aka DLRN repos) will be built and tested using > CentOS 8 Stream for all releases currently using CentOS Linux 8 (starting > with Train). > > If you are interested in the details about these plans and how we plan to > implement it, we've created a blog post [4]. > > Don't hesitate to ask us in the ML or in the #rdo channel on freenode if > you have questions or suggestions about this. > > We are also organizing a video AMA about RDO and CentOS Stream on > Thursday Jan 21 1600 UTC in the RDO Meet room > https://meet.google.com/uzo-tfkt-top > We are doing some initial CentOS 8 stream testing (on Train -> Wallaby releases) as tracked on http://dashboard-ci.tripleo.org/d/jwDYSidGz/rpm-dependency-pipeline?orgId=1. However, since the majority of the testing for RDO is done in upstream openstack, is there an estimate on when an upstream CentOS-8-Stream nodepool node will be available for check/gate testing? Thanks! > > On behalf of RDO, > > Alfredo > > [1] https://centos.org/distro-faq/ > [2] https://blog.centos.org/2020/12/future-is-centos-stream/ > [3] https://releases.openstack.org/ > [4] > https://blogs.rdoproject.org/2021/01/rdo-plans-to-move-to-centos-stream/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From fungi at yuggoth.org Thu Jan 14 22:44:42 2021 From: fungi at yuggoth.org (Jeremy Stanley) Date: Thu, 14 Jan 2021 22:44:42 +0000 Subject: [RDO][CentOS] RDO plans to move to CentOS Stream In-Reply-To: References: Message-ID: <20210114224104.pja5atja53dmsjt6@yuggoth.org> On 2021-01-14 16:25:41 -0500 (-0500), Ronelle Landy wrote: [...] > is there an estimate on when an upstream CentOS-8-Stream nodepool > node will be available for check/gate testing? [...] We expect to add it in June of last year. ;) https://review.opendev.org/734791 According to codesearch, looks like it's already being used for jobs in diskimage-builder, bifrost, openstacksdk... -- Jeremy Stanley -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From fungi at yuggoth.org Thu Jan 14 22:55:48 2021 From: fungi at yuggoth.org (Jeremy Stanley) Date: Thu, 14 Jan 2021 22:55:48 +0000 Subject: [RDO][CentOS] RDO plans to move to CentOS Stream In-Reply-To: <20210114224104.pja5atja53dmsjt6@yuggoth.org> References: <20210114224104.pja5atja53dmsjt6@yuggoth.org> Message-ID: <20210114225548.dbma2gkgnxdi3isr@yuggoth.org> On 2021-01-14 22:44:42 +0000 (+0000), Jeremy Stanley wrote: > On 2021-01-14 16:25:41 -0500 (-0500), Ronelle Landy wrote: > [...] > > is there an estimate on when an upstream CentOS-8-Stream nodepool > > node will be available for check/gate testing? > [...] > > We expect to add it in June of last year. ;) > > https://review.opendev.org/734791 > > According to codesearch, looks like it's already being used for jobs > in diskimage-builder, bifrost, openstacksdk... Oh sorry, I was looking at the wrong date, we added it in October. We also have package mirroring set up as best as I can tell (centos/8-stream on our mirror sites). -- Jeremy Stanley -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From hberaud at redhat.com Fri Jan 15 07:07:13 2021 From: hberaud at redhat.com (Herve Beraud) Date: Fri, 15 Jan 2021 08:07:13 +0100 Subject: [release] Release countdown for week R-12 Jan 18 - Jan 22 Message-ID: Greetings, Development Focus ----------------- The Wallaby-2 milestone is next week, on 21 January, 2021! Wallaby-related specs should now be finalized so that teams can move to implementation ASAP. Some teams observe specific deadlines on the second milestone (mostly spec freezes): please refer to https://releases.openstack.org/wallaby/schedule.html for details. General Information ------------------- Libraries need to be released at least once per milestone period. Next week, the release team will propose releases for any library that has not been otherwise released since milestone 1. PTL's and release liaisons, please watch for these and give a +1 to acknowledge them. If there is some reason to hold off on a release, let us know that as well. A +1 would be appreciated, but if we do not hear anything at all by the end of the week, we will assume things are OK to proceed. Remember that non-library deliverables that follow the cycle-with-intermediary release model should have an intermediary release before milestone-2. Those who haven't will be proposed to switch to the cycle-with-rc model, which is more suited to deliverables that are released only once per cycle. Next week is also the deadline to freeze the contents of the final release. All new 'Wallaby' deliverables need to have a deliverable file in https://opendev.org/openstack/releases/src/branch/master/deliverables and need to have done a release by milestone-2. Changes proposing those deliverables for inclusion in Wallaby have been posted, please update them with an actual release request before the milestone-2 deadline if you plan on including that deliverable in Wallaby, or -1 if you need one more cycle to be ready. Upcoming Deadlines & Dates -------------------------- Wallaby-2 Milestone: 21 January, 2021 -- Hervé Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/ https://twitter.com/4383hberaud -----BEGIN PGP SIGNATURE----- wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O v6rDpkeNksZ9fFSyoY2o =ECSj -----END PGP SIGNATURE----- -------------- next part -------------- An HTML attachment was scrubbed... URL: From hberaud at redhat.com Fri Jan 15 07:55:32 2021 From: hberaud at redhat.com (Herve Beraud) Date: Fri, 15 Jan 2021 08:55:32 +0100 Subject: [oslo][release] etcd3gw release model - series vs independent Message-ID: Greetings Osloers, etcd3gw was moved under the Oslo team's scope a few months ago [1][2]. This project hasn't yet been released by us and we should choose to release it either during Wallaby or to make it an independent [3] project. I didn't see significant changes merged since the project transition, so I think we could directly adopt the independent model for etcd3gw. However I want first to discuss this with all the core maintainers before and then I'll act accordingly. Notice that Wallaby Milestone 2 is next week, so it could be a good time for us to decide to continue with a coordinated series or to adopt the independent model directly. Let me know what you think about that. Thanks, [1] http://lists.openstack.org/pipermail/openstack-discuss/2020-August/016457.html [2] https://governance.openstack.org/tc/reference/projects/oslo.html#etcd3gw [3] https://releases.openstack.org/reference/release_models.html#independent -- Hervé Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/ https://twitter.com/4383hberaud -----BEGIN PGP SIGNATURE----- wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O v6rDpkeNksZ9fFSyoY2o =ECSj -----END PGP SIGNATURE----- -------------- next part -------------- An HTML attachment was scrubbed... URL: From roshananvekar at gmail.com Fri Jan 15 07:58:35 2021 From: roshananvekar at gmail.com (roshan anvekar) Date: Fri, 15 Jan 2021 13:28:35 +0530 Subject: Openstack stein TLS configuration with combined method of interfaces Message-ID: Hello, Openstack version: stein Deployment method: kolla-ansible I am trying to set up TLS for Openstack endpoint. I have chosen combined method of vip address where I supply only kolla_internal_vip_address and network_interface details. I do not enable external kolla vip address. After this I set up kolla_enable_tls_external: 'yes' and pass the kolla_external_fqdn_cert certificates. The installation is successful but I see that http link opens but https:// endpoint does not open at all. Is as good as not available. Any reason for this? Regards, Roshan -------------- next part -------------- An HTML attachment was scrubbed... URL: From hberaud at redhat.com Fri Jan 15 08:42:01 2021 From: hberaud at redhat.com (Herve Beraud) Date: Fri, 15 Jan 2021 09:42:01 +0100 Subject: [rpm-packaging]release] Update our deliverables accordingly to the SIG governance model Message-ID: Dear rpm team fellows, I take off my release PTL cap to discuss with you as a teammate about some inconsistencies in our deliverables. Indeed, last week we noticed some inconsistencies between the rpm-packaging team's deliverables described in the governance’s reference and deliverables defined in the openstack/releases repo. Since rpm-packaging became a SIG our deliverables [1][2][3] aren't managed by the release team anymore, so we should act accordingly to reflect that. Two choices are available to us: 1) mark these project as "release-model: abandoned" in the governance repo [4]; 2) remove the corresponding files from openstack/releases [1][2][3]. Each choice has pros and cons: - by choosing 1) it will reflect that our projects are abandoned, which is wrong, our projects are still active but not released by the coordinated releases anymore; - by choosing 2) it will reflect that we have always been a SIG, which is wrong too. I personally prefer 2) to allow us to avoid misleading someone by having an abandoned status, indeed, reflecting a SIG is less misleading than reflecting an abandoned project. Here is the list of our deliverables that should be addressed: - renderspec [1] - pymod2pkg [2] - rpm-packaging [3] Any opinion? For further details please take a look to our previous meeting discussion [5]. Thanks for reading, [1] https://opendev.org/openstack/releases/src/branch/master/deliverables/_independent/renderspec.yaml [2] https://opendev.org/openstack/releases/src/branch/master/deliverables/_independent/pymod2pkg.yaml [3] https://opendev.org/openstack/releases/src/branch/master/deliverables/wallaby/rpm-packaging.yaml [4] https://opendev.org/openstack/governance/src/branch/master/reference/sigs-repos.yaml#L24-L28 [5] http://eavesdrop.openstack.org/irclogs/%23openstack-release/%23openstack-release.2021-01-14.log.html#t2021-01-14T17:12:27 -- Hervé Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/ https://twitter.com/4383hberaud -----BEGIN PGP SIGNATURE----- wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O v6rDpkeNksZ9fFSyoY2o =ECSj -----END PGP SIGNATURE----- -------------- next part -------------- An HTML attachment was scrubbed... URL: From amoralej at redhat.com Fri Jan 15 08:45:13 2021 From: amoralej at redhat.com (Alfredo Moralejo Alonso) Date: Fri, 15 Jan 2021 09:45:13 +0100 Subject: [RDO][CentOS] RDO plans to move to CentOS Stream In-Reply-To: <20210114225548.dbma2gkgnxdi3isr@yuggoth.org> References: <20210114224104.pja5atja53dmsjt6@yuggoth.org> <20210114225548.dbma2gkgnxdi3isr@yuggoth.org> Message-ID: On Thu, Jan 14, 2021 at 11:59 PM Jeremy Stanley wrote: > On 2021-01-14 22:44:42 +0000 (+0000), Jeremy Stanley wrote: > > On 2021-01-14 16:25:41 -0500 (-0500), Ronelle Landy wrote: > > [...] > > > is there an estimate on when an upstream CentOS-8-Stream nodepool > > > node will be available for check/gate testing? > > [...] > > > > We expect to add it in June of last year. ;) > > > > https://review.opendev.org/734791 > > > > According to codesearch, looks like it's already being used for jobs > > in diskimage-builder, bifrost, openstacksdk... > > Yes, I see centos-8-stream images ready for testing. I'm also adding jobs for packstack in https://review.opendev.org/c/x/packstack/+/770771 > Oh sorry, I was looking at the wrong date, we added it in October. > We also have package mirroring set up as best as I can tell > (centos/8-stream on our mirror sites). > BTW, we need to merge https://review.opendev.org/c/zuul/zuul-jobs/+/770815 to get the proper 8-stream repos configured by configure-mirrors role > -- > Jeremy Stanley > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark at stackhpc.com Fri Jan 15 08:50:47 2021 From: mark at stackhpc.com (Mark Goddard) Date: Fri, 15 Jan 2021 08:50:47 +0000 Subject: Openstack stein TLS configuration with combined method of interfaces In-Reply-To: References: Message-ID: On Fri, 15 Jan 2021 at 07:59, roshan anvekar wrote: > > Hello, > > Openstack version: stein > Deployment method: kolla-ansible > > I am trying to set up TLS for Openstack endpoint. > > I have chosen combined method of vip address where I supply only kolla_internal_vip_address and network_interface details. I do not enable external kolla vip address. > > After this I set up kolla_enable_tls_external: 'yes' and pass the kolla_external_fqdn_cert certificates. > > The installation is successful but I see that http link opens but https:// endpoint does not open at all. Is as good as not available. > > Any reason for this? Hi. From the Stein documentation [1]: "The kolla_internal_vip_address and kolla_external_vip_address must be different to enable TLS on the external network." >From the Train release it is possible to enable TLS on the internal VIP, although Ussuri is typically necessary to make it work if you have a private CA. [1] https://docs.openstack.org/kolla-ansible/stein/admin/advanced-configuration.html#tls-configuration > > Regards, > Roshan From hberaud at redhat.com Fri Jan 15 08:57:38 2021 From: hberaud at redhat.com (Herve Beraud) Date: Fri, 15 Jan 2021 09:57:38 +0100 Subject: [barbican][release] Barbican deliverables questions Message-ID: Hi Barbican Team, The release team noticed some inconsistencies between the Barbican team's deliverables described in the governance’s reference and deliverables defined in the openstack/releases repo (c.f our related meeting topic [1]). First, we noticed that ansible-role-atos-hsm and ansible-role-thales-hsm are new barbican deliverables, and we would appreciate to know if we should plan to release them for Wallaby. The second thing is that barbican-ui (added in Oct 2019) was never released yet and was not ready yet for ussuri and victoria. maybe we should abandon this instead of waiting? Notice that Wallaby's milestone 2 is next week so it could be the good time to update all these things. Let us know your thoughts, we are waiting for your replies. Thanks for reading, [1] http://eavesdrop.openstack.org/irclogs/%23openstack-release/%23openstack-release.2021-01-14.log.html#t2021-01-14T17:05:23 -- Hervé Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/ https://twitter.com/4383hberaud -----BEGIN PGP SIGNATURE----- wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O v6rDpkeNksZ9fFSyoY2o =ECSj -----END PGP SIGNATURE----- -------------- next part -------------- An HTML attachment was scrubbed... URL: From hberaud at redhat.com Fri Jan 15 09:07:12 2021 From: hberaud at redhat.com (Herve Beraud) Date: Fri, 15 Jan 2021 10:07:12 +0100 Subject: [qa][release] Abandoning openstack-tempest-skiplist? Message-ID: Dear QA team, The release team noticed an inconsistency between the QA team's deliverables described in the governance’s reference and deliverables defined in the openstack/releases repo (c.f our related meeting topic [1]). Indeed, openstack-tempest-skiplist (added Mar 20, 2020) was never released yet, was not ready yet for ussuri and victoria. maybe we should abandon this instead of waiting? Notice that Wallaby's milestone 2 is next week so maybe it could be a good time to update this. Let us know your thoughts, we are waiting for your replies. Thanks for reading, [1] http://eavesdrop.openstack.org/irclogs/%23openstack-release/%23openstack-release.2021-01-14.log.html#t2021-01-14T17:05:23 -- Hervé Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/ https://twitter.com/4383hberaud -----BEGIN PGP SIGNATURE----- wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O v6rDpkeNksZ9fFSyoY2o =ECSj -----END PGP SIGNATURE----- -------------- next part -------------- An HTML attachment was scrubbed... URL: From hberaud at redhat.com Fri Jan 15 09:11:15 2021 From: hberaud at redhat.com (Herve Beraud) Date: Fri, 15 Jan 2021 10:11:15 +0100 Subject: [OpenStackSDK][release] Abandoning js-openstack-lib? Message-ID: Dear OpenStackSDK team, The release team noticed an inconsistency between the OpenStackSDK team's deliverables described in the governance’s reference and deliverables defined in the openstack/releases repo (c.f our related meeting topic [1]). Indeed, js-openstack-lib (added January 9, 2020) was never released yet and was not ready for ussuri or victoria. maybe we should abandon this instead of waiting? Notice that Wallaby's milestone 2 is next week so maybe it could be a good time to update this. Let us know your thoughts, we are waiting for your replies. Thanks for reading, [1] http://eavesdrop.openstack.org/irclogs/%23openstack-release/%23openstack-release.2021-01-14.log.html#t2021-01-14T17:05:23 -- Hervé Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/ https://twitter.com/4383hberaud -----BEGIN PGP SIGNATURE----- wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O v6rDpkeNksZ9fFSyoY2o =ECSj -----END PGP SIGNATURE----- -------------- next part -------------- An HTML attachment was scrubbed... URL: From hberaud at redhat.com Fri Jan 15 09:15:11 2021 From: hberaud at redhat.com (Herve Beraud) Date: Fri, 15 Jan 2021 10:15:11 +0100 Subject: [monasca][release] Abandoning monasca-ceilometer and monasca-log-api? Message-ID: Dear Monasca team, The release team noticed an inconsistency between the Monasca team's deliverables described in the governance’s reference and deliverables defined in the openstack/releases repo (c.f our related meeting topic [1]). Indeed, monasca-ceilometer and monasca-log-api were released in train but not released in ussuri nor victoria. Do you think that they should be deprecated (abandoned) in governance? Notice that Wallaby's milestone 2 is next week so maybe it could be a good time to update this. Let us know your thoughts, we are waiting for your replies. Thanks for reading, [1] http://eavesdrop.openstack.org/irclogs/%23openstack-release/%23openstack-release.2021-01-14.log.html#t2021-01-14T17:05:23 -- Hervé Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/ https://twitter.com/4383hberaud -----BEGIN PGP SIGNATURE----- wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O v6rDpkeNksZ9fFSyoY2o =ECSj -----END PGP SIGNATURE----- -------------- next part -------------- An HTML attachment was scrubbed... URL: From lyarwood at redhat.com Fri Jan 15 09:37:23 2021 From: lyarwood at redhat.com (Lee Yarwood) Date: Fri, 15 Jan 2021 09:37:23 +0000 Subject: [nova] MIN_{LIBVIRT,QEMU}_VERSION and NEXT_MIN_{LIBVIRT,QEMU}_VERSION bumps in Wallaby Message-ID: <20210115093723.q2uqabf2emedxc2z@lyarwood-laptop.usersys.redhat.com> Hello all, We are once again looking to increase the minimum and next minimum versions of libvirt and QEMU in the libvirt virt driver. These were previously increased late in the Victoria cycle: MIN_LIBVIRT_VERSION = (5, 0, 0) MIN_QEMU_VERSION = (4, 0, 0) NEXT_MIN_LIBVIRT_VERSION = (6, 0, 0) NEXT_MIN_QEMU_VERSION = (4, 2, 0) libvirt: Bump MIN_{LIBVIRT,QEMU}_VERSION and NEXT_MIN_{LIBVIRT,QEMU}_VERSION https://review.opendev.org/c/openstack/nova/+/746981 I am now proposing the following updates to these versions in Wallaby: MIN_LIBVIRT_VERSION = (6, 0, 0) MIN_QEMU_VERSION = (4, 2, 0) NEXT_MIN_LIBVIRT_VERSION = (7, 0, 0) NEXT_MIN_QEMU_VERSION = (5, 2, 0) libvirt: Bump MIN_{LIBVIRT,QEMU}_VERSION and NEXT_MIN_{LIBVIRT,QEMU}_VERSION https://review.opendev.org/c/openstack/nova/+/754700 libvirt v6.0.0 and QEMU 4.2.0 being supported by the three LTS releases supported by the Wallaby release of OpenStack [1][2]. libvirt v7.0.0 and QEMU 5.2.0 being slightly aspirational for the next minimum versions at this point but given current releases for both projects they seem appropriate for the time being. Please let me know ideally in the review if there are any issues with this increase. Regards, [1] https://governance.openstack.org/tc/reference/runtimes/wallaby.html [2] https://wiki.openstack.org/wiki/LibvirtDistroSupportMatrix -- Lee Yarwood A5D1 9385 88CB 7E5F BE64 6618 BCA6 6E33 F672 2D76 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: not available URL: From geguileo at redhat.com Fri Jan 15 10:01:23 2021 From: geguileo at redhat.com (Gorka Eguileor) Date: Fri, 15 Jan 2021 11:01:23 +0100 Subject: Trying to resolve 2 deprecation warnings In-Reply-To: References: Message-ID: <20210115100123.ezptbmoripuzbmvh@localhost> On 14/01, shubjero wrote: > Hi all, > > I am trying to resolve two deprecation warnings which I've not been > able to locate exactly what package or file is causing them. > > We are running OpenStack Train on Ubuntu 18.04 > > The log entries are found in /etc/apache2/cinder_error.log : > 2021-01-06 15:54:05.332604 > /usr/lib/python3/dist-packages/oslo_context/context.py:108: > DeprecationWarning: Policy enforcement is depending on the value of > is_admin. This key is deprecated. Please update your policy file to > use the standard policy values. Hi, Maybe it is caused by one of these 2 options: https://github.com/openstack/cinder/blob/60a73610910257abf5bdd5eae7606f5bd012ae5d/cinder/policies/base.py#L25-L32 > 2021-01-06 15:54:20.147590 > /usr/lib/python3/dist-packages/webob/acceptparse.py:1051: > DeprecationWarning: The behavior of AcceptValidHeader.best_match is > currently being maintained for backward compatibility, but it will be > deprecated in the future, as it does not conform to the RFC. > This could be one of these: https://github.com/openstack/cinder/blob/60a73610910257abf5bdd5eae7606f5bd012ae5d/cinder/api/openstack/wsgi.py#L253 https://github.com/openstack/cinder/blob/60a73610910257abf5bdd5eae7606f5bd012ae5d/cinder/api/openstack/wsgi.py#L840 Cheers, Gorka. > Any help on what needs to be changed/removed/updated/upgraded would be > appreciated. > > Thanks! > > Jared > Ontario Institute for Cancer Research > From kchamart at redhat.com Fri Jan 15 10:40:13 2021 From: kchamart at redhat.com (Kashyap Chamarthy) Date: Fri, 15 Jan 2021 11:40:13 +0100 Subject: [nova] MIN_{LIBVIRT,QEMU}_VERSION and NEXT_MIN_{LIBVIRT,QEMU}_VERSION bumps in Wallaby In-Reply-To: <20210115093723.q2uqabf2emedxc2z@lyarwood-laptop.usersys.redhat.com> References: <20210115093723.q2uqabf2emedxc2z@lyarwood-laptop.usersys.redhat.com> Message-ID: <20210115104013.GA484402@paraplu.home> On Fri, Jan 15, 2021 at 09:37:23AM +0000, Lee Yarwood wrote: > > Hello all, Hey, > We are once again looking to increase the minimum and next minimum > versions of libvirt and QEMU in the libvirt virt driver. > > These were previously increased late in the Victoria cycle: > > MIN_LIBVIRT_VERSION = (5, 0, 0) > MIN_QEMU_VERSION = (4, 0, 0) > > NEXT_MIN_LIBVIRT_VERSION = (6, 0, 0) > NEXT_MIN_QEMU_VERSION = (4, 2, 0) > > libvirt: Bump MIN_{LIBVIRT,QEMU}_VERSION and NEXT_MIN_{LIBVIRT,QEMU}_VERSION > https://review.opendev.org/c/openstack/nova/+/746981 > > I am now proposing the following updates to these versions in Wallaby: > > MIN_LIBVIRT_VERSION = (6, 0, 0) > MIN_QEMU_VERSION = (4, 2, 0) > > NEXT_MIN_LIBVIRT_VERSION = (7, 0, 0) > NEXT_MIN_QEMU_VERSION = (5, 2, 0) > > libvirt: Bump MIN_{LIBVIRT,QEMU}_VERSION and NEXT_MIN_{LIBVIRT,QEMU}_VERSION > https://review.opendev.org/c/openstack/nova/+/754700 > > libvirt v6.0.0 and QEMU 4.2.0 being supported by the three LTS releases > supported by the Wallaby release of OpenStack [1][2]. > > libvirt v7.0.0 and QEMU 5.2.0 being slightly aspirational for the next > minimum versions at this point but given current releases for both > projects they seem appropriate for the time being. Yeah, v7.0.0. is fine — it's only one year further (released: Jan 2021) from v6.0.0 (released: Jan 2020). > Please let me know ideally in the review if there are any issues with > this increase. Looks fine to me. Thanks! > Regards, > > [1] https://governance.openstack.org/tc/reference/runtimes/wallaby.html > [2] https://wiki.openstack.org/wiki/LibvirtDistroSupportMatrix > -- > Lee Yarwood A5D1 9385 88CB 7E5F BE64 6618 BCA6 6E33 F672 2D76 -- /kashyap From jegor at greenedge.cloud Fri Jan 15 11:39:41 2021 From: jegor at greenedge.cloud (Jegor van Opdorp) Date: Fri, 15 Jan 2021 11:39:41 +0000 Subject: [masakari] Masakari Team Meeting - the schedule In-Reply-To: References: Message-ID: <271344d8-61d1-4fa9-b40c-3bb4550a290c@email.android.com> I really doesn't matter to me, choose any :) On Jan 12, 2021 10:56, Radosław Piliszek wrote: Hello, Folks! I have realised the Masakari Team Meeting is to run on even weeks [1]. However, anyone who created the meeting record in their calendar (including me) has likely gotten the meeting schedule in odd weeks this year (because last year finished with an odd week and obviously numbering also starts on odd: the 1). So I have run the first meeting this year the previous week but someone came for the meeting this week. :-) According to the "new wrong" schedule, the next meeting would be on Jan 19, but according to the "proper" one it would be on Jan 26. I am available both weeks the same so can run either term (or both as well, why not). The question is whether we don't want to simply move to the weekly meeting schedule. We usually don't have much to discuss but it might be less confusing and a better way to form a habit if we met every week. Please let me know your thoughts. [1] http://eavesdrop.openstack.org/#Masakari_Team_Meeting -yoctozepto -------------- next part -------------- An HTML attachment was scrubbed... URL: From radoslaw.piliszek at gmail.com Fri Jan 15 13:05:22 2021 From: radoslaw.piliszek at gmail.com (=?UTF-8?Q?Rados=C5=82aw_Piliszek?=) Date: Fri, 15 Jan 2021 14:05:22 +0100 Subject: [OpenStackSDK][release] Abandoning js-openstack-lib? In-Reply-To: References: Message-ID: On Fri, Jan 15, 2021 at 10:11 AM Herve Beraud wrote: > > Dear OpenStackSDK team, > > The release team noticed an inconsistency between the OpenStackSDK team's deliverables described in the governance’s reference and deliverables defined in the openstack/releases repo (c.f our related meeting topic [1]). > > Indeed, js-openstack-lib (added January 9, 2020) was never released yet and was not ready for ussuri or victoria. maybe we should abandon this instead of waiting? Probably. It was me who saved it from demise but I did not get time to really work on it and not planning to any time soon nowadays. It has been established that the project more-or-less requires a serious redesign and rewrite to keep up with current technology and practices established in other, established OpenStackSDK deliverables. -yoctozepto From radoslaw.piliszek at gmail.com Fri Jan 15 13:55:18 2021 From: radoslaw.piliszek at gmail.com (=?UTF-8?Q?Rados=C5=82aw_Piliszek?=) Date: Fri, 15 Jan 2021 14:55:18 +0100 Subject: [oslo][release] etcd3gw release model - series vs independent In-Reply-To: References: Message-ID: On Fri, Jan 15, 2021 at 8:56 AM Herve Beraud wrote: > > Greetings Osloers, > > etcd3gw was moved under the Oslo team's scope a few months ago [1][2]. > > This project hasn't yet been released by us and we should choose to release it either during Wallaby or to make it an independent [3] project. > > I didn't see significant changes merged since the project transition, so I think we could directly adopt the independent model for etcd3gw. Based on the current status, I would say the independent release model would suit it best. -yoctozepto From gmann at ghanshyammann.com Fri Jan 15 14:54:07 2021 From: gmann at ghanshyammann.com (Ghanshyam Mann) Date: Fri, 15 Jan 2021 08:54:07 -0600 Subject: [qa][release][tripleo] Abandoning openstack-tempest-skiplist? In-Reply-To: References: Message-ID: <177068a105d.aea199651318020.1189554580760474526@ghanshyammann.com> ---- On Fri, 15 Jan 2021 03:07:12 -0600 Herve Beraud wrote ---- > Dear QA team, > The release team noticed an inconsistency between the QA team's deliverables described in the governance’s reference and deliverables defined in the openstack/releases repo (c.f our related meeting topic [1]). > Indeed, openstack-tempest-skiplist (added Mar 20, 2020) was never released yet, was not ready yet for ussuri and victoria. maybe we should abandon this instead of waiting? > Notice that Wallaby's milestone 2 is next week so maybe it could be a good time to update this. > Let us know your thoughts, we are waiting for your replies. > Thanks for reading, Thanks hberaud for brining it, I did not know about this repo until it was discussed in yesterday's release meeting. As per the governance project.yaml 'openstack-tempest-skiplist' is under the TripleO project, not QA [1] (tagging tripleo in sub). This repo is to maintain the test skiplist so not sure if it needed release but marios or Chandan can decide. [1] https://github.com/openstack/governance/blob/2bdd9cff00fb40b2f95b66cad47ae1cfd14a2f1b/reference/projects.yaml#L3069 -gmann > [1] http://eavesdrop.openstack.org/irclogs/%23openstack-release/%23openstack-release.2021-01-14.log.html#t2021-01-14T17:05:23 > -- > Hervé BeraudSenior Software Engineer at Red Hatirc: hberaudhttps://github.com/4383/https://twitter.com/4383hberaud > -----BEGIN PGP SIGNATURE----- > > wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ > Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ > RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP > F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G > 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g > glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw > m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ > hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 > qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y > F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 > B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O > v6rDpkeNksZ9fFSyoY2o > =ECSj > -----END PGP SIGNATURE----- > > From lei12zhang12 at gmail.com Fri Jan 15 03:26:28 2021 From: lei12zhang12 at gmail.com (Lei Zhang) Date: Fri, 15 Jan 2021 11:26:28 +0800 Subject: [all]Introduction to venus which is the project of log management and has been contributed to the OpenStack community In-Reply-To: References: Message-ID: This looks cool. One question about the Venus api, does it support full Elasticsearch DSL or just a subset of queries On Mon, Jan 11, 2021 at 4:59 AM Liye Pang(逄立业) wrote: > Hello everyone, after feedback from a large number of operations and > maintenance personnel in InCloud OpenStack, we developed the log management > project “Venus” for the OpenStack projects and that has contributed to the > OpenStack community. The following is an introduction to “Venus”. If there > is interest in the community, we are interested in proposing it to become > an official OpenStack project in the future. > Background > > In the day-to-day operation and maintenance of large-scale cloud platform, > the following problems are encountered： > > l Time-consuming for log querying while the server increasing to > thousands. > > l Difficult to retrieve logs, since there are many modules in the > platform, e.g. systems service, compute, storage, network and other > platform services. > > l The large amount and dispersion of log make faults are difficult to be > discovered. > > l Because of distributed and interaction between components of the cloud > platform, and scattered logs between components, it will take more time to > locate problems. > About Venus > > According to the key requirements of OpenStack in log storage, retrieval, > analysis and so on, we introduced *Venus *project, a unified log > management module. This module can provide a one-stop solution to log > collection, cleaning, indexing, analysis, alarm, visualization, report > generation and other needs, which involves helping operator or maintainer > to quickly solve retrieve problems, grasp the operational health of the > platform, and improve the management capabilities of the cloud platform. > > Additionally, this module plans to use machine learning algorithms to > quickly locate IT failures and root causes, and improve operation and > maintenance efficiency. > Application scenario > > Venus played a key role in the following scenarios： > > l *Retrieval:* Provide a simple and easy-to-use way to retrieve all log > and the context. > > l *Analysis*: Realize log association, field value statistics, and > provide multi-scene and multi-dimensional visual analysis reports. > > l *Alerts*：Convert retrieval into active alerts to realize the error > finding in massive logs. > > l *Issue location*: Establish a chain relationship and knowledge graphs > to quickly locate problems. > Overall structure > > The architecture of log management system based on Venus and elastic > search is as follows: > > Diagram 0: Architecture of Venus > > *venus_api*: API module，provide API、rest-api service. > > *venus_manager*: Internal timing task module to realize the core > functions of the log system. > Current progress > > The current progress of the Venus project is as follows: > > l Collection：Develop *fluentd* collection tasks based on collectd to > read, filter, format and send plug-ins for OpenStack, operating systems, > and platform services, etc. > > l Index：Dealing with multi-dimensional index data in *elasticsearch*, > and provide more concise and comprehensive authentication interface to > return query results. > > l Analysis：Analyzing and display the related module errors, Mariadb > connection errors, and Rabbitmq connection errors. > > l Alerts：Develop alarm task code to set threshold for the number of > error logs of different modules at different times, and provides alarm > services and notification services. > > l Location：Develop the call chain analysis function based on > *global_requested* series, which can show the execution sequence, time > and error information, etc., and provide the export operation. > > l Management：Develop configuration management functions in the log > system, such as alarm threshold setting, timing task management, and log > saving time setting, etc. > Application examples > > Two examples of Venus application scenarios are as follows. > > 1. The virtual machine creation operation was performed on the > cloud platform and it was found that the virtual machine was not created > successfully. > > First, we can find the request id of the operation and jump to the virtual > machine creation call chain page. > > Then, we can query the calling process, view and download the details of > the log of the call. > > 2. In the cloud platform, the error log of each module can be > converted into alarms to remind the users. > > Further, we can retrieve the details of the error log and error log > statistics. > > Next step > > The next step of the Venus project is as follows: > > l *Collection*：In addition to fluent, other collection plugins such as > logstash will be integrated. > > l *Analysis*: Explore more operation and maintenance scenarios, and > conduct statistical analysis and alarm on key data. > > l *display*: The configuration, analysis and alarm of Venus will be > integrated into horizon in the form of plugin. > > l *location*: Form clustering log and construct knowledge map, and > integrate algorithm class library to locate the root cause of the fault. > Venus Project Registry > > *Venus library*: https://opendev.org/inspur/venus > > You can grab the source code using the following git command: > > git clone https://opendev.org/inspur/venus.git > > > Venus Demo > > *Youtu.be*: https://youtu.be/mE2MoEx3awM > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 24507 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.jpg Type: image/jpeg Size: 3184 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image003.jpg Type: image/jpeg Size: 8136 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image004.jpg Type: image/jpeg Size: 15944 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image005.jpg Type: image/jpeg Size: 8405 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image006.jpg Type: image/jpeg Size: 3046 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image007.jpg Type: image/jpeg Size: 15175 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image008.jpg Type: image/jpeg Size: 8496 bytes Desc: not available URL: From pangliye at inspur.com Fri Jan 15 04:20:17 2021 From: pangliye at inspur.com (=?utf-8?B?TGl5ZSBQYW5nKOmAhOeri+S4mik=?=) Date: Fri, 15 Jan 2021 04:20:17 +0000 Subject: =?utf-8?B?562U5aSNOiBbYWxsXUludHJvZHVjdGlvbiB0byB2ZW51cyB3aGljaCBpcyB0?= =?utf-8?B?aGUgcHJvamVjdCBvZiBsb2cgbWFuYWdlbWVudCBhbmQgaGFzIGJlZW4gY29u?= =?utf-8?Q?tributed_to_the_OpenStack_community?= In-Reply-To: References: Message-ID: <308c7cdf6f0d4ea2806a9a736df71b11@inspur.com> Not all es DSL Some venus api will be directly converted to es api, some will query es data and return the result after calculation, and some will query mysql data, such as alarms. 发件人: Lei Zhang 发送时间: 2021年1月15日 11:26 收件人: Liye Pang(逄立业) 抄送: openstack-discuss at lists.openstack.org 主题: Re: [all]Introduction to venus which is the project of log management and has been contributed to the OpenStack community This looks cool. One question about the Venus api, does it support full Elasticsearch DSL or just a subset of queries On Mon, Jan 11, 2021 at 4:59 AM Liye Pang(逄立业) > wrote: Hello everyone, after feedback from a large number of operations and maintenance personnel in InCloud OpenStack, we developed the log management project “Venus” for the OpenStack projects and that has contributed to the OpenStack community. The following is an introduction to “Venus”. If there is interest in the community, we are interested in proposing it to become an official OpenStack project in the future. Background In the day-to-day operation and maintenance of large-scale cloud platform, the following problems are encountered： l Time-consuming for log querying while the server increasing to thousands. l Difficult to retrieve logs, since there are many modules in the platform, e.g. systems service, compute, storage, network and other platform services. l The large amount and dispersion of log make faults are difficult to be discovered. l Because of distributed and interaction between components of the cloud platform, and scattered logs between components, it will take more time to locate problems. About Venus According to the key requirements of OpenStack in log storage, retrieval, analysis and so on, we introduced Venus project, a unified log management module. This module can provide a one-stop solution to log collection, cleaning, indexing, analysis, alarm, visualization, report generation and other needs, which involves helping operator or maintainer to quickly solve retrieve problems, grasp the operational health of the platform, and improve the management capabilities of the cloud platform. Additionally, this module plans to use machine learning algorithms to quickly locate IT failures and root causes, and improve operation and maintenance efficiency. Application scenario Venus played a key role in the following scenarios： l Retrieval: Provide a simple and easy-to-use way to retrieve all log and the context. l Analysis: Realize log association, field value statistics, and provide multi-scene and multi-dimensional visual analysis reports. l Alerts：Convert retrieval into active alerts to realize the error finding in massive logs. l Issue location: Establish a chain relationship and knowledge graphs to quickly locate problems. Overall structure The architecture of log management system based on Venus and elastic search is as follows: Diagram 0: Architecture of Venus venus_api: API module，provide API、rest-api service. venus_manager: Internal timing task module to realize the core functions of the log system. Current progress The current progress of the Venus project is as follows: l Collection：Develop fluentd collection tasks based on collectd to read, filter, format and send plug-ins for OpenStack, operating systems, and platform services, etc. l Index：Dealing with multi-dimensional index data in elasticsearch, and provide more concise and comprehensive authentication interface to return query results. l Analysis：Analyzing and display the related module errors, Mariadb connection errors, and Rabbitmq connection errors. l Alerts：Develop alarm task code to set threshold for the number of error logs of different modules at different times, and provides alarm services and notification services. l Location：Develop the call chain analysis function based on global_requested series, which can show the execution sequence, time and error information, etc., and provide the export operation. l Management：Develop configuration management functions in the log system, such as alarm threshold setting, timing task management, and log saving time setting, etc. Application examples Two examples of Venus application scenarios are as follows. 1. The virtual machine creation operation was performed on the cloud platform and it was found that the virtual machine was not created successfully. First, we can find the request id of the operation and jump to the virtual machine creation call chain page. Then, we can query the calling process, view and download the details of the log of the call. 2. In the cloud platform, the error log of each module can be converted into alarms to remind the users. Further, we can retrieve the details of the error log and error log statistics. Next step The next step of the Venus project is as follows: * Collection：In addition to fluent, other collection plugins such as logstash will be integrated. * Analysis: Explore more operation and maintenance scenarios, and conduct statistical analysis and alarm on key data. * display: The configuration, analysis and alarm of Venus will be integrated into horizon in the form of plugin. * location: Form clustering log and construct knowledge map, and integrate algorithm class library to locate the root cause of the fault. Venus Project Registry Venus library: https://opendev.org/inspur/venus You can grab the source code using the following git command: git clone https://opendev.org/inspur/venus.git Venus Demo Youtu.be: https://youtu.be/mE2MoEx3awM -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 24507 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.jpg Type: image/jpeg Size: 3184 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image003.jpg Type: image/jpeg Size: 8136 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image004.jpg Type: image/jpeg Size: 15944 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image005.jpg Type: image/jpeg Size: 8405 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image006.jpg Type: image/jpeg Size: 3046 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image007.jpg Type: image/jpeg Size: 15175 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image008.jpg Type: image/jpeg Size: 8496 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3786 bytes Desc: not available URL: From bshewale at redhat.com Fri Jan 15 13:47:09 2021 From: bshewale at redhat.com (Bhagyashri Shewale) Date: Fri, 15 Jan 2021 19:17:09 +0530 Subject: [tripleo] TripleO CI Summary: Unified Sprint 37 and 38 Message-ID: Greetings, The TripleO CI team has just completed **Unified Sprint 36 and 37** (Dec 04 to Jan 13). The following is a summary of completed work during this sprint cycle: - Component standalone-upgrade added to tripleo component: 1. https://review.rdoproject.org/zuul/builds?job_name=periodic-tripleo-ci-centos-8-standalone-upgrade-tripleo-ussuri&job_name=periodic-tripleo-ci-centos-8-standalone-upgrade-tripleo-victoria&job_name=periodic-tripleo-ci-centos-8-standalone-upgrade-tripleo-master - Docs https://review.opendev.org/c/openstack/tripleo-docs/+/767375 https://docs.openstack.org/tripleo-docs/latest/ci/stages-overview.html - Reduce content-providers in upgrade job layouts: https://review.opendev.org/q/topic:reduce-content-providers - Improve tripleo-upgrade repo job coverage: https://review.opendev.org/q/topic:tripleo-upgrade-provider-jobs-coverage - (content providers) remove registry_ip_address: https://bugs.launchpad.net/tripleo/+bug/1904565 https://review.opendev.org/c/openstack/tripleo-ci/+/764359 - Build report for container builds and content provider jobs: https://review.opendev.org/q/topic:%2522build-report%2522+(status:merged) - Added a build report for the container builds and content provider jobs: https://review.opendev.org/q/topic:%2522build-report%2522+(status:merged) - Promoter configuration fix: https://review.rdoproject.org/r/#/c/28014/ - rpm diff comparison script added to dependency jobs logs: https://github.com/rdo-infra/ci-config/commit/bf829ed2b7bda23d85d5128907147403e8f1e1b4#diff-c946e763e9253e2ac6aa5b8a237dc956edd2dc583fa6578ad74ce53a363c0446 - centos 8 stream: - rpm comparison skip list was updated with release delivery's help: https://github.com/rdo-infra/ci-config/commit/ca144362ee520dbd6e89f1e23dcb8cb02979d09c - branch jobs were added: victoria, ussuri, train - dependency lines now run with a controller job for rpm comparisons - working to get the stream jobs running on stream nodes https://bugs.launchpad.net/tripleo/+bug/1910791 https://review.rdoproject.org/zuul/builds?pipeline=openstack-dependencies-centos8stream - Provisioning via metalsmith in 16.2 and created a new job for it in 16.2 component pipeline https://review.opendev.org/c/openstack/tripleo-ci/+/769469 - Stable version of scenario manager. Apart from that, https://review.opendev.org/c/openstack/tempest/+/766472 https://review.opendev.org/c/openstack/tempest/+/766015 - Writing unit test cases for the cockpit (telegraf container and moving scipts from py2 to py3 directory). https://review.rdoproject.org/r/#/c/30492/ - Done https://review.rdoproject.org/r/#/c/31442/ - Work in progress - Working on Promoter Stuff (Get familiar with the new promoter code). https://review.rdoproject.org/r/#/c/31318/ - Done - Released 1.2.1 version of Openstack Ansible collections: https://opendev.org/openstack/ansible-collections-openstack - Released 1.4.0 and 1.4.1 versions of Podman Ansible collections: https://github.com/containers/ansible-podman-collections - Created OSP 13 and OSP 16.2 jobs in CI that run Openstack Ansible collections tests to ensure collections work on these OSP versions. - Enable dracut list installed modules https://review.opendev.org/c/openstack/diskimage-builder/+/766232 - Collect dnf module related infos - https://review.opendev.org/c/openstack/ansible-role-collect-logs/+/768595 - still working on finishing copy-quay role: https://review.rdoproject.org/r/#/c/31395/ - Bugs related to os_tempest that is affecting upgrade jobs: https://bugs.launchpad.net/tripleo/+bug/1911020 - add test command on tempest-skip list and documentation https://review.opendev.org/c/openstack/openstack-tempest-skiplist/+/754994 Upstream promotions [1] NEXT SPRINT =========== - Bring the new promoter code online - Dependency pipeline - tripleo repos (As a design discussion for this sprint) - openstack Health for TripleO - Ruck and Rover - Akahat|rover - sshnaidm|ruck Please direct questions or queries to them regarding CI status or issues in #tripleo, ideally to whomever has the ‘|ruck’ suffix on their nick. [1]: http://dashboard-ci.tripleo.org/d/HkOLImOMk/upstream-and-rdo-promotions?orgId=1 Sprint 37 and 38 ruck/rover notes: https://hackmd.io/R0kCgz_7SHSix_cNgoC9pg Thanks and Regards, Bhagyashri Shewale -------------- next part -------------- An HTML attachment was scrubbed... URL: From marios at redhat.com Fri Jan 15 15:23:12 2021 From: marios at redhat.com (Marios Andreou) Date: Fri, 15 Jan 2021 17:23:12 +0200 Subject: [tripleo] next irc meeting Tuesday Jan 19 @ 1400 UTC in #tripleo Message-ID: Reminder that the next TripleO irc meeting is: ** Tuesday 19th January at 1400 UTC in #tripleo ** ** https://wiki.openstack.org/wiki/Meetings/TripleO ** ** https://etherpad.opendev.org/p/tripleo-meeting-items ** Please add anything you want to hilight at https://etherpad.opendev.org/p/tripleo-meeting-items This can include recently completed things, ongoing review requests, blocking issues, or anything else tripleo you'd like to share. Our last meeting was on Jan 05 - you can find the logs there http://eavesdrop.openstack.org/meetings/tripleo/2021/tripleo.2021-01-05-14.00.html Hope you can make it on Tuesday, thanks, marios -------------- next part -------------- An HTML attachment was scrubbed... URL: From marios at redhat.com Fri Jan 15 15:52:21 2021 From: marios at redhat.com (Marios Andreou) Date: Fri, 15 Jan 2021 17:52:21 +0200 Subject: [TripleO] moving stable/rocky for tripleo repos to unmaintained (+ then EOL) OK? In-Reply-To: References: Message-ID: On Thu, Dec 10, 2020 at 7:01 PM Marios Andreou wrote: > Hello TripleO > > I would like to propose that we move all tripleo stable/rocky repos [1] to > "unmaintained", with a view to tagging as end-of-life in due course. > > This will allow us to focus our efforts on keeping the check and gate > queues green and continue to deliver weekly promotions for the more recent > and active stable/* branches train ussuri victoria and master. > > The stable/rocky repos have not had much action in the last few months - I > collected some info at [2] about the most recent stable/rocky commits for > each of the tripleo repos. For many of those there are no commits in the > last 6 months and for some even longer. > > The tripleo stable/rocky repos were tagged as "extended maintenance" > (rocky-em) [2] in April 2020 with [3]. > > We have already reduced our CI commitment for rocky - these [4] are the > current check/gate jobs and these [5] are the jobs that run for promotion > to current-tripleo. However maintaining this doesn’t make sense if we are > not even using it e.g. merging things into tripleo-* stable/rocky. > > Please raise your objections or any other comments or thoughts about this. > Unless there are any blockers raised here, the plan is to put this into > motion early in January. > > One still unanswered question I have is that since there is no > ‘unmaintained’ tag, in the same way as we have the -em or > for extended maintenance and end-of-life, do we simply > _declare_ that the repos are unmaintained? Then after a period of “0 to 6 > months” per [6] we can tag the tripleo repos with rocky-eol. If any one > reading this knows please tell us! > > o/ hello ! replying to bump the thread - this was sent ~1 month ago now and there hasn't been any comment thus far. ping @Herve please do you know the answer to that question in the last paragraph above about 'declaring unmaintained' ? please thank you ;) As discussed at the last tripleo bi-weekly we can consider moving forward with this so I think it's prudent to give folks more chance to comment if they object for _reason_ thanks, marios > Thanks for reading! > > regards, marios > > > [1] https://releases.openstack.org/teams/tripleo.html#rocky > > [2] http://paste.openstack.org/raw/800464/ > > [3] https://review.opendev.org/c/openstack/releases/+/709912 > > [4] > http://dashboard-ci.tripleo.org/d/3-DYSmOGk/jobs-exploration?orgId=1&var-influxdb_filter=branch%7C%3D%7Cstable%2Frocky > > [5] > http://dashboard-ci.tripleo.org/d/3-DYSmOGk/jobs-exploration?orgId=1&fullscreen&panelId=9&var-influxdb_filter=type%7C%3D%7Crdo&var-influxdb_filter=job_name%7C%3D~%7C%2Fperiodic.*-rocky%2F > > [6] > https://docs.openstack.org/project-team-guide/stable-branches.html#maintenance-phases > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.mcginnis at gmx.com Fri Jan 15 16:06:12 2021 From: sean.mcginnis at gmx.com (Sean McGinnis) Date: Fri, 15 Jan 2021 10:06:12 -0600 Subject: [oslo][release] etcd3gw release model - series vs independent In-Reply-To: References: Message-ID: <20210115160612.GA2966915@sm-workstation> On Fri, Jan 15, 2021 at 02:55:18PM +0100, Radosław Piliszek wrote: > On Fri, Jan 15, 2021 at 8:56 AM Herve Beraud wrote: > > > > Greetings Osloers, > > > > etcd3gw was moved under the Oslo team's scope a few months ago [1][2]. > > > > This project hasn't yet been released by us and we should choose to release it either during Wallaby or to make it an independent [3] project. > > > > I didn't see significant changes merged since the project transition, so I think we could directly adopt the independent model for etcd3gw. > > Based on the current status, I would say the independent release model > would suit it best. > > -yoctozepto > +1 for independent. That makes sense for this type of library. From hberaud at redhat.com Fri Jan 15 17:01:24 2021 From: hberaud at redhat.com (Herve Beraud) Date: Fri, 15 Jan 2021 18:01:24 +0100 Subject: [TripleO] moving stable/rocky for tripleo repos to unmaintained (+ then EOL) OK? In-Reply-To: References: Message-ID: Hello, Sorry for my late reply, and thanks for the heads up. Can't we move directly to EOL [1]? I don't see reason to keep an unmaintained repo open, and if the repos remain open and patches merged then it's not really unmaintained repos. The goal of the extended maintenance was to offer more chances to downstream maintainers to get/share patches and fixes, if you decide to not maintain them anymore then I would suggest you to move to "EOL" directly, it would be less misleading. Notice that if you move rocky to eol all the corresponding branches will be dropped in your repos. Also notice that last week we proposed a new kind of tag (-last) [2][3] for Tempest's needs, but because tempest is branchless... Maybe we could extend this notion (-last) to allow the project to reflect the last step... It could reflect that it will be your last release, and that the project is near from the end. But if you don't plan to merge patches, or if you don't have patches to merge anymore, then I would really suggest to you to move directly to EOL, else it means that you're not really "unmaintained". Hopefully it will help you to find the solution that fits your needs. Let me know if you have more questions. [1] https://governance.openstack.org/tc/resolutions/20180301-stable-branch-eol.html#end-of-life [2] https://review.opendev.org/c/openstack/releases/+/770265 [3] https://review.opendev.org/c/openstack/project-team-guide/+/769821 Le ven. 15 janv. 2021 à 16:52, Marios Andreou a écrit : > > On Thu, Dec 10, 2020 at 7:01 PM Marios Andreou wrote: > >> Hello TripleO >> >> I would like to propose that we move all tripleo stable/rocky repos [1] >> to "unmaintained", with a view to tagging as end-of-life in due course. >> >> This will allow us to focus our efforts on keeping the check and gate >> queues green and continue to deliver weekly promotions for the more recent >> and active stable/* branches train ussuri victoria and master. >> >> The stable/rocky repos have not had much action in the last few months - >> I collected some info at [2] about the most recent stable/rocky commits for >> each of the tripleo repos. For many of those there are no commits in the >> last 6 months and for some even longer. >> >> The tripleo stable/rocky repos were tagged as "extended maintenance" >> (rocky-em) [2] in April 2020 with [3]. >> >> We have already reduced our CI commitment for rocky - these [4] are the >> current check/gate jobs and these [5] are the jobs that run for promotion >> to current-tripleo. However maintaining this doesn’t make sense if we are >> not even using it e.g. merging things into tripleo-* stable/rocky. >> >> Please raise your objections or any other comments or thoughts about >> this. Unless there are any blockers raised here, the plan is to put this >> into motion early in January. >> >> One still unanswered question I have is that since there is no >> ‘unmaintained’ tag, in the same way as we have the -em or >> for extended maintenance and end-of-life, do we simply >> _declare_ that the repos are unmaintained? Then after a period of “0 to 6 >> months” per [6] we can tag the tripleo repos with rocky-eol. If any one >> reading this knows please tell us! >> >> > o/ hello ! > > replying to bump the thread - this was sent ~1 month ago now and there > hasn't been any comment thus far. > > ping @Herve please do you know the answer to that question in the last > paragraph above about 'declaring unmaintained' ? please thank you ;) > > As discussed at the last tripleo bi-weekly we can consider moving forward > with this so I think it's prudent to give folks more chance to comment if > they object for _reason_ > > thanks, marios > > > > > > >> Thanks for reading! >> >> regards, marios >> >> >> [1] https://releases.openstack.org/teams/tripleo.html#rocky >> >> [2] http://paste.openstack.org/raw/800464/ >> >> [3] https://review.opendev.org/c/openstack/releases/+/709912 >> >> [4] >> http://dashboard-ci.tripleo.org/d/3-DYSmOGk/jobs-exploration?orgId=1&var-influxdb_filter=branch%7C%3D%7Cstable%2Frocky >> >> [5] >> http://dashboard-ci.tripleo.org/d/3-DYSmOGk/jobs-exploration?orgId=1&fullscreen&panelId=9&var-influxdb_filter=type%7C%3D%7Crdo&var-influxdb_filter=job_name%7C%3D~%7C%2Fperiodic.*-rocky%2F >> >> [6] >> https://docs.openstack.org/project-team-guide/stable-branches.html#maintenance-phases >> > -- Hervé Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/ https://twitter.com/4383hberaud -----BEGIN PGP SIGNATURE----- wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O v6rDpkeNksZ9fFSyoY2o =ECSj -----END PGP SIGNATURE----- -------------- next part -------------- An HTML attachment was scrubbed... URL: From gmann at ghanshyammann.com Fri Jan 15 19:36:30 2021 From: gmann at ghanshyammann.com (Ghanshyam Mann) Date: Fri, 15 Jan 2021 13:36:30 -0600 Subject: [all][interop] Reforming the refstack maintainers team In-Reply-To: References: <1765341f106.111a3f243109782.5942668683123760803@ghanshyammann.com> Message-ID: <177078c987c.c394eaa31331699.3566137682643757540@ghanshyammann.com> Thanks for continuing or coming forward for help. I have done the required modification and below is the current core group to handle day to day activity for interop source code repo: Amy Marrich amy at demarco.com Ghanshyam gmann at ghanshyammann.com Goutham Pacha Ravi gouthampravi at gmail.com Luigi Toscano ltoscano at redhat.com Martin Kopec mkopec at redhat.com Thierry Carrez thierry at openstack.org (ttx mentioned not having enough time for core roles but I kept him as it will be helpful for issue reporting and merging the things faster) Vida Haririan vhariria at redhat.com Chandan Kumar chkumar at redhat.com Also added a project-config change to combine the core group acl file - https://review.opendev.org/c/openstack/project-config/+/771066 -gmann ---- On Tue, 15 Dec 2020 08:53:54 -0600 Amy Marrich wrote ---- > Let me know if I can help. > Thanks, > Amy (spotz) > > On Fri, Dec 11, 2020 at 1:25 PM Ghanshyam Mann wrote: > Hello Everyone, > > As Goutham mentioned in a separate ML thread[2] that there is no active maintainer for refstack repo > which we discussed in today's interop meeting[1]. We had a few volunteers who can help to maintain the > refstack and other interop repo which is good news. > > I would like to call for more volunteers (new or existing ones), if you are interested to help please do reply > to this email. The role is to maintain the source code of the below repos. I will propose the ACL changes in infra sometime > next Friday (18th dec) or so. > > For easy maintenance, we thought of merging the below repo core group into a single group called 'refstack-core' > > - openstack/python-tempestconf > - openstack/refstack > - openstack/refstack-client > - x/ansible-role-refstack-client (moving to osf/ via https://review.opendev.org/765787) > > Current Volunteers: > - martin (mkopec at redhat.com) > - gouthamr (gouthampravi at gmail.com) > - gmann (gmann at ghanshyammann.com) > - Vida (vhariria at redhat.com) > > - interop-core (we will add this group also which has interop WG chairs so that it will be easy to maintain in the future changes) > > NOTE: there is no change in the 'interop' repo group which has interop guidelines and doc etc. > > [1] https://etherpad.opendev.org/p/interop > [2] http://lists.openstack.org/pipermail/openstack-discuss/2020-December/019263.html > > -gmann > > From Arkady.Kanevsky at dell.com Fri Jan 15 20:45:40 2021 From: Arkady.Kanevsky at dell.com (Kanevsky, Arkady) Date: Fri, 15 Jan 2021 20:45:40 +0000 Subject: [all] https://github.com/OpenStackweb/openstack-org Message-ID: Looking at out current website code I wonder if we should 1. Reword to be OpenInfra not just OpenStack or even move to new repo for OpenInfraWeb? 2. Keep it to be dedicated to OpenStack and create a parent Web for OpenInfra. That parent page will point to all projects under OpenInftastructure umbrella? In related question, should we also create openinfra-discuss mail list? Thanks, Arkady Kanevsky, Ph.D. SP Chief Technologist & DE Dell EMC office of CTO Dell Inc. One Dell Way, MS PS2-91 Round Rock, TX 78682, USA Phone: 512 7204955 -------------- next part -------------- An HTML attachment was scrubbed... URL: From Arkady.Kanevsky at dell.com Fri Jan 15 20:48:17 2021 From: Arkady.Kanevsky at dell.com (Kanevsky, Arkady) Date: Fri, 15 Jan 2021 20:48:17 +0000 Subject: [all][interop] Reforming the refstack maintainers team In-Reply-To: <177078c987c.c394eaa31331699.3566137682643757540@ghanshyammann.com> References: <1765341f106.111a3f243109782.5942668683123760803@ghanshyammann.com> <177078c987c.c394eaa31331699.3566137682643757540@ghanshyammann.com> Message-ID: Thanks for driving it Ghanshyam. I will help where I can. Arkady -----Original Message----- From: Ghanshyam Mann Sent: Friday, January 15, 2021 1:37 PM To: Amy Marrich Cc: openstack-discuss; foundation-board at lists.openstack.org Subject: Re: [all][interop] Reforming the refstack maintainers team [EXTERNAL EMAIL] Thanks for continuing or coming forward for help. I have done the required modification and below is the current core group to handle day to day activity for interop source code repo: Amy Marrich amy at demarco.com Ghanshyam gmann at ghanshyammann.com Goutham Pacha Ravi gouthampravi at gmail.com Luigi Toscano ltoscano at redhat.com Martin Kopec mkopec at redhat.com Thierry Carrez thierry at openstack.org (ttx mentioned not having enough time for core roles but I kept him as it will be helpful for issue reporting and merging the things faster) Vida Haririan vhariria at redhat.com Chandan Kumar chkumar at redhat.com Also added a project-config change to combine the core group acl file - https://review.opendev.org/c/openstack/project-config/+/771066 -gmann ---- On Tue, 15 Dec 2020 08:53:54 -0600 Amy Marrich wrote ---- > Let me know if I can help. > Thanks, > Amy (spotz) > > On Fri, Dec 11, 2020 at 1:25 PM Ghanshyam Mann wrote: > Hello Everyone, > > As Goutham mentioned in a separate ML thread[2] that there is no active maintainer for refstack repo > which we discussed in today's interop meeting[1]. We had a few volunteers who can help to maintain the > refstack and other interop repo which is good news. > > I would like to call for more volunteers (new or existing ones), if you are interested to help please do reply > to this email. The role is to maintain the source code of the below repos. I will propose the ACL changes in infra sometime > next Friday (18th dec) or so. > > For easy maintenance, we thought of merging the below repo core group into a single group called 'refstack-core' > > - openstack/python-tempestconf > - openstack/refstack > - openstack/refstack-client > - x/ansible-role-refstack-client (moving to osf/ via https://review.opendev.org/765787) > > Current Volunteers: > - martin (mkopec at redhat.com) > - gouthamr (gouthampravi at gmail.com) > - gmann (gmann at ghanshyammann.com) > - Vida (vhariria at redhat.com) > > - interop-core (we will add this group also which has interop WG chairs so that it will be easy to maintain in the future changes) > > NOTE: there is no change in the 'interop' repo group which has interop guidelines and doc etc. > > [1] https://etherpad.opendev.org/p/interop > [2] http://lists.openstack.org/pipermail/openstack-discuss/2020-December/019263.html > > -gmann > > From jimmy at openstack.org Fri Jan 15 23:00:08 2021 From: jimmy at openstack.org (Jimmy McArthur) Date: Fri, 15 Jan 2021 17:00:08 -0600 Subject: [all] https://github.com/OpenStackweb/openstack-org In-Reply-To: References: Message-ID: <4DC37310-4C2A-4502-8C1F-42622768585B@getmailspring.com> Hi Arkady, Renaming the repo is on the list. We have quite a few pieces we're still working to clean up (repos, legal, etc...) as we transfer to the new Foundation name. When you say "parent web", I think you're referring to a parent repo with the name openinfra, which would be taken care of by the above. But we do already have https://openinfra.dev which points to all of our projects and such. Re: the ml - we already have a Foundation and Foundation Board ml, so I'm not sure any renaming or new ml is necessary on that front. If you feel those won't cover it, can you let us know what you have in mind? Cheers, Jimmy On Jan 15 2021, at 2:45 pm, Kanevsky, Arkady wrote: > > Looking at out current website code I wonder if we should > > Reword to be OpenInfra not just OpenStack or even move to new repo for OpenInfraWeb? > Keep it to be dedicated to OpenStack and create a parent Web for OpenInfra. That parent page will point to all projects under OpenInftastructure umbrella? > > > > > In related question, should we also create openinfra-discuss mail list? > > Thanks, > Arkady Kanevsky, Ph.D. > SP Chief Technologist & DE > Dell EMC office of CTO > Dell Inc. One Dell Way, MS PS2-91 > Round Rock, TX 78682, USA > Phone: 512 7204955 -------------- next part -------------- An HTML attachment was scrubbed... URL: From fungi at yuggoth.org Sat Jan 16 16:41:17 2021 From: fungi at yuggoth.org (Jeremy Stanley) Date: Sat, 16 Jan 2021 16:41:17 +0000 Subject: bindep, pacman, and PyPI release In-Reply-To: References: Message-ID: <20210116164116.gqn6stp7kyvli4ao@yuggoth.org> On 2020-12-13 11:43:35 +0100 (+0100), Jakob Lykke Andersen wrote: > I'm trying to use bindep on Arch but hitting a problem with the > output handling. It seems that 'pacman -Q' may output warning > lines if you have a file with the same name as the package. E.g.,: > > $ mkdir cmake > $ pacman -Q cmake > error: package 'cmake' was not found > warning: 'cmake' is a file, you might want to use -p/--file. > > The current detection assumes the "was not found" is the last part > of the output. Applying the patch below seems to fix it. Apologies for taking this long to reply, I've proposed the patch you submitted here and listed you as co-author: https://review.opendev.org/771108 > After applying this patch, or whichever change you deem reasonable > to fix the issue, it would be great if you could make a new > release on PyPI. [...] Yes, once that patch is approved by other reviewers for bindep, I'll make sure to tag a new release so it will appear on PyPI. Thanks for providing this fix! -- Jeremy Stanley -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From zigo at debian.org Sat Jan 16 21:06:09 2021 From: zigo at debian.org (Thomas Goirand) Date: Sat, 16 Jan 2021 22:06:09 +0100 Subject: [nova] MIN_{LIBVIRT,QEMU}_VERSION and NEXT_MIN_{LIBVIRT,QEMU}_VERSION bumps in Wallaby In-Reply-To: <20210115093723.q2uqabf2emedxc2z@lyarwood-laptop.usersys.redhat.com> References: <20210115093723.q2uqabf2emedxc2z@lyarwood-laptop.usersys.redhat.com> Message-ID: On 1/15/21 10:37 AM, Lee Yarwood wrote: > > Hello all, > > We are once again looking to increase the minimum and next minimum > versions of libvirt and QEMU in the libvirt virt driver. > > These were previously increased late in the Victoria cycle: > > MIN_LIBVIRT_VERSION = (5, 0, 0) > MIN_QEMU_VERSION = (4, 0, 0) > > NEXT_MIN_LIBVIRT_VERSION = (6, 0, 0) > NEXT_MIN_QEMU_VERSION = (4, 2, 0) > > libvirt: Bump MIN_{LIBVIRT,QEMU}_VERSION and NEXT_MIN_{LIBVIRT,QEMU}_VERSION > https://review.opendev.org/c/openstack/nova/+/746981 > > I am now proposing the following updates to these versions in Wallaby: > > MIN_LIBVIRT_VERSION = (6, 0, 0) > MIN_QEMU_VERSION = (4, 2, 0) > > NEXT_MIN_LIBVIRT_VERSION = (7, 0, 0) > NEXT_MIN_QEMU_VERSION = (5, 2, 0) > > libvirt: Bump MIN_{LIBVIRT,QEMU}_VERSION and NEXT_MIN_{LIBVIRT,QEMU}_VERSION > https://review.opendev.org/c/openstack/nova/+/754700 > > libvirt v6.0.0 and QEMU 4.2.0 being supported by the three LTS releases > supported by the Wallaby release of OpenStack [1][2]. > > libvirt v7.0.0 and QEMU 5.2.0 being slightly aspirational for the next > minimum versions at this point but given current releases for both > projects they seem appropriate for the time being. > > Please let me know ideally in the review if there are any issues with > this increase. > > Regards, Hi, Wallaby will be on Debian Bullseye, for which the freeze has started, and which already has libvirt 6.9.0 and qemu 5.2, so no worries for me. Libvirt 7 would be a problem though. Cheers, Thomas Goirand (zigo) From mailakkina at gmail.com Sun Jan 17 10:51:56 2021 From: mailakkina at gmail.com (Nagaraj Akkina) Date: Sun, 17 Jan 2021 11:51:56 +0100 Subject: [$nova] [$horizon] openstack host show statistics Message-ID: Hello, Openstack host show compute-host, shows more memory allocated to instances than actual physical memory, although the memory allocation ratio is 1.0 in nova.conf, the same is also shown in horizon dashboard hypervisor statistics. We can see this in many compute nodes in the cluster. Also these statistics does not match with free -g or cat /proc/meminfo. For Example : Memory_mb | compute-node23 | (total) | 257915 | | compute-node23 | (used_now) | 271360 | | compute-node23 | (used_max) | 267264 | How to avoid misleading statistics, also which statistics are actually correct? versions : openstack : Stein nova : 2:19.3.0-0ubuntu1~cloud0 Regards, Akkina -------------- next part -------------- An HTML attachment was scrubbed... URL: From marios at redhat.com Mon Jan 18 09:21:43 2021 From: marios at redhat.com (Marios Andreou) Date: Mon, 18 Jan 2021 11:21:43 +0200 Subject: [TripleO] moving stable/rocky for tripleo repos to unmaintained (+ then EOL) OK? In-Reply-To: References: Message-ID: On Fri, Jan 15, 2021 at 7:01 PM Herve Beraud wrote: > Hello, > > Sorry for my late reply, and thanks for the heads up. > > Can't we move directly to EOL [1]? > I don't see reason to keep an unmaintained repo open, and if the repos > remain open and patches merged then it's not really unmaintained repos. > > The goal of the extended maintenance was to offer more chances to > downstream maintainers to get/share patches and fixes, if you decide to not > maintain them anymore then I would suggest you to move to "EOL" directly, > it would be less misleading. > > Notice that if you move rocky to eol all the corresponding branches will > be dropped in your repos. > > Also notice that last week we proposed a new kind of tag (-last) > [2][3] for Tempest's needs, but because tempest is branchless... > > Maybe we could extend this notion (-last) to allow the project to reflect > the last step... > It could reflect that it will be your last release, and that the project > is near from the end. > > But if you don't plan to merge patches, or if you don't have patches to > merge anymore, then I would really suggest to you to move directly to EOL, > else it means that you're not really "unmaintained". > OK thanks very much Herve as always for your time and thoughts here. I am not against the EOL I just thought it was more of a requirement to declare it 'unmaintained' first. The advantage is it is a softer path to completely closing it off for any future submissions. Possibly the '-last' tag fits this need but if I have understood correctly it might need some adjustment to the definition of that tag ('we could extend this notion') and honestly I don't know if it is necessary. More likely straight to EOL is what we want here. I will bring this up again in tomorrow's tripleo irc meeting http://lists.openstack.org/pipermail/openstack-discuss/2021-January/019859.html and point to this thread. Let's see what other opinions there are around EOL vs -last for stable/rocky thank you, marios > > Hopefully it will help you to find the solution that fits your needs. > > Let me know if you have more questions. > > [1] > https://governance.openstack.org/tc/resolutions/20180301-stable-branch-eol.html#end-of-life > [2] https://review.opendev.org/c/openstack/releases/+/770265 > [3] https://review.opendev.org/c/openstack/project-team-guide/+/769821 > > Le ven. 15 janv. 2021 à 16:52, Marios Andreou a > écrit : > >> >> On Thu, Dec 10, 2020 at 7:01 PM Marios Andreou wrote: >> >>> Hello TripleO >>> >>> I would like to propose that we move all tripleo stable/rocky repos [1] >>> to "unmaintained", with a view to tagging as end-of-life in due course. >>> >>> This will allow us to focus our efforts on keeping the check and gate >>> queues green and continue to deliver weekly promotions for the more recent >>> and active stable/* branches train ussuri victoria and master. >>> >>> The stable/rocky repos have not had much action in the last few months - >>> I collected some info at [2] about the most recent stable/rocky commits for >>> each of the tripleo repos. For many of those there are no commits in the >>> last 6 months and for some even longer. >>> >>> The tripleo stable/rocky repos were tagged as "extended maintenance" >>> (rocky-em) [2] in April 2020 with [3]. >>> >>> We have already reduced our CI commitment for rocky - these [4] are the >>> current check/gate jobs and these [5] are the jobs that run for promotion >>> to current-tripleo. However maintaining this doesn’t make sense if we are >>> not even using it e.g. merging things into tripleo-* stable/rocky. >>> >>> Please raise your objections or any other comments or thoughts about >>> this. Unless there are any blockers raised here, the plan is to put this >>> into motion early in January. >>> >>> One still unanswered question I have is that since there is no >>> ‘unmaintained’ tag, in the same way as we have the -em or >>> for extended maintenance and end-of-life, do we simply >>> _declare_ that the repos are unmaintained? Then after a period of “0 to 6 >>> months” per [6] we can tag the tripleo repos with rocky-eol. If any one >>> reading this knows please tell us! >>> >>> >> o/ hello ! >> >> replying to bump the thread - this was sent ~1 month ago now and there >> hasn't been any comment thus far. >> >> ping @Herve please do you know the answer to that question in the last >> paragraph above about 'declaring unmaintained' ? please thank you ;) >> >> As discussed at the last tripleo bi-weekly we can consider moving forward >> with this so I think it's prudent to give folks more chance to comment if >> they object for _reason_ >> >> thanks, marios >> >> >> >> >> >> >>> Thanks for reading! >>> >>> regards, marios >>> >>> >>> [1] https://releases.openstack.org/teams/tripleo.html#rocky >>> >>> [2] http://paste.openstack.org/raw/800464/ >>> >>> [3] https://review.opendev.org/c/openstack/releases/+/709912 >>> >>> [4] >>> http://dashboard-ci.tripleo.org/d/3-DYSmOGk/jobs-exploration?orgId=1&var-influxdb_filter=branch%7C%3D%7Cstable%2Frocky >>> >>> [5] >>> http://dashboard-ci.tripleo.org/d/3-DYSmOGk/jobs-exploration?orgId=1&fullscreen&panelId=9&var-influxdb_filter=type%7C%3D%7Crdo&var-influxdb_filter=job_name%7C%3D~%7C%2Fperiodic.*-rocky%2F >>> >>> [6] >>> https://docs.openstack.org/project-team-guide/stable-branches.html#maintenance-phases >>> >> > > -- > Hervé Beraud > Senior Software Engineer at Red Hat > irc: hberaud > https://github.com/4383/ > https://twitter.com/4383hberaud > -----BEGIN PGP SIGNATURE----- > > wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ > Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ > RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP > F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G > 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g > glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw > m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ > hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 > qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y > F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 > B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O > v6rDpkeNksZ9fFSyoY2o > =ECSj > -----END PGP SIGNATURE----- > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hberaud at redhat.com Mon Jan 18 10:44:32 2021 From: hberaud at redhat.com (Herve Beraud) Date: Mon, 18 Jan 2021 11:44:32 +0100 Subject: [TripleO] moving stable/rocky for tripleo repos to unmaintained (+ then EOL) OK? In-Reply-To: References: Message-ID: Hello Le lun. 18 janv. 2021 à 10:22, Marios Andreou a écrit : > > > On Fri, Jan 15, 2021 at 7:01 PM Herve Beraud wrote: > >> Hello, >> >> Sorry for my late reply, and thanks for the heads up. >> >> Can't we move directly to EOL [1]? >> I don't see reason to keep an unmaintained repo open, and if the repos >> remain open and patches merged then it's not really unmaintained repos. >> >> The goal of the extended maintenance was to offer more chances to >> downstream maintainers to get/share patches and fixes, if you decide to not >> maintain them anymore then I would suggest you to move to "EOL" directly, >> it would be less misleading. >> >> Notice that if you move rocky to eol all the corresponding branches will >> be dropped in your repos. >> >> Also notice that last week we proposed a new kind of tag (-last) >> [2][3] for Tempest's needs, but because tempest is branchless... >> >> Maybe we could extend this notion (-last) to allow the project to reflect >> the last step... >> It could reflect that it will be your last release, and that the project >> is near from the end. >> >> But if you don't plan to merge patches, or if you don't have patches to >> merge anymore, then I would really suggest to you to move directly to EOL, >> else it means that you're not really "unmaintained". >> > > OK thanks very much Herve as always for your time and thoughts here. I am > not against the EOL I just thought it was more of a requirement to declare > it 'unmaintained' first. The advantage is it is a softer path to completely > closing it off for any future submissions. Possibly the '-last' tag fits > this need but if I have understood correctly it might need some adjustment > to the definition of that tag ('we could extend this notion') and honestly > I don't know if it is necessary. More likely straight to EOL is what we > want here. > You're welcome, Do not hesitate to ping us. Concerning the "-last", I said that we surely need to extend this kind of tag because it is referenced for tempest's usages. I think EOL fits our needs and is the shortest path. > I will bring this up again in tomorrow's tripleo irc meeting > http://lists.openstack.org/pipermail/openstack-discuss/2021-January/019859.html > and point to this thread. Let's see what other opinions there are around > EOL vs -last for stable/rocky > Same thing on my side, I added this topic to our next relmgt irc meeting (thursday) to see opinions of the team. > thank you, marios > Thank you > > > >> >> Hopefully it will help you to find the solution that fits your needs. >> >> Let me know if you have more questions. >> >> [1] >> https://governance.openstack.org/tc/resolutions/20180301-stable-branch-eol.html#end-of-life >> [2] https://review.opendev.org/c/openstack/releases/+/770265 >> [3] https://review.opendev.org/c/openstack/project-team-guide/+/769821 >> >> Le ven. 15 janv. 2021 à 16:52, Marios Andreou a >> écrit : >> >>> >>> On Thu, Dec 10, 2020 at 7:01 PM Marios Andreou >>> wrote: >>> >>>> Hello TripleO >>>> >>>> I would like to propose that we move all tripleo stable/rocky repos [1] >>>> to "unmaintained", with a view to tagging as end-of-life in due course. >>>> >>>> This will allow us to focus our efforts on keeping the check and gate >>>> queues green and continue to deliver weekly promotions for the more recent >>>> and active stable/* branches train ussuri victoria and master. >>>> >>>> The stable/rocky repos have not had much action in the last few months >>>> - I collected some info at [2] about the most recent stable/rocky commits >>>> for each of the tripleo repos. For many of those there are no commits in >>>> the last 6 months and for some even longer. >>>> >>>> The tripleo stable/rocky repos were tagged as "extended maintenance" >>>> (rocky-em) [2] in April 2020 with [3]. >>>> >>>> We have already reduced our CI commitment for rocky - these [4] are the >>>> current check/gate jobs and these [5] are the jobs that run for promotion >>>> to current-tripleo. However maintaining this doesn’t make sense if we are >>>> not even using it e.g. merging things into tripleo-* stable/rocky. >>>> >>>> Please raise your objections or any other comments or thoughts about >>>> this. Unless there are any blockers raised here, the plan is to put this >>>> into motion early in January. >>>> >>>> One still unanswered question I have is that since there is no >>>> ‘unmaintained’ tag, in the same way as we have the -em or >>>> for extended maintenance and end-of-life, do we simply >>>> _declare_ that the repos are unmaintained? Then after a period of “0 to 6 >>>> months” per [6] we can tag the tripleo repos with rocky-eol. If any one >>>> reading this knows please tell us! >>>> >>>> >>> o/ hello ! >>> >>> replying to bump the thread - this was sent ~1 month ago now and there >>> hasn't been any comment thus far. >>> >>> ping @Herve please do you know the answer to that question in the last >>> paragraph above about 'declaring unmaintained' ? please thank you ;) >>> >>> As discussed at the last tripleo bi-weekly we can consider moving >>> forward with this so I think it's prudent to give folks more chance to >>> comment if they object for _reason_ >>> >>> thanks, marios >>> >>> >>> >>> >>> >>> >>>> Thanks for reading! >>>> >>>> regards, marios >>>> >>>> >>>> [1] https://releases.openstack.org/teams/tripleo.html#rocky >>>> >>>> [2] http://paste.openstack.org/raw/800464/ >>>> >>>> [3] https://review.opendev.org/c/openstack/releases/+/709912 >>>> >>>> [4] >>>> http://dashboard-ci.tripleo.org/d/3-DYSmOGk/jobs-exploration?orgId=1&var-influxdb_filter=branch%7C%3D%7Cstable%2Frocky >>>> >>>> [5] >>>> http://dashboard-ci.tripleo.org/d/3-DYSmOGk/jobs-exploration?orgId=1&fullscreen&panelId=9&var-influxdb_filter=type%7C%3D%7Crdo&var-influxdb_filter=job_name%7C%3D~%7C%2Fperiodic.*-rocky%2F >>>> >>>> [6] >>>> https://docs.openstack.org/project-team-guide/stable-branches.html#maintenance-phases >>>> >>> >> >> -- >> Hervé Beraud >> Senior Software Engineer at Red Hat >> irc: hberaud >> https://github.com/4383/ >> https://twitter.com/4383hberaud >> -----BEGIN PGP SIGNATURE----- >> >> wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ >> Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ >> RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP >> F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G >> 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g >> glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw >> m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ >> hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 >> qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y >> F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 >> B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O >> v6rDpkeNksZ9fFSyoY2o >> =ECSj >> -----END PGP SIGNATURE----- >> >> -- Hervé Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/ https://twitter.com/4383hberaud -----BEGIN PGP SIGNATURE----- wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O v6rDpkeNksZ9fFSyoY2o =ECSj -----END PGP SIGNATURE----- -------------- next part -------------- An HTML attachment was scrubbed... URL: From stephenfin at redhat.com Mon Jan 18 14:15:46 2021 From: stephenfin at redhat.com (Stephen Finucane) Date: Mon, 18 Jan 2021 14:15:46 +0000 Subject: [$nova] [$horizon] openstack host show statistics In-Reply-To: References: Message-ID: On Sun, 2021-01-17 at 11:51 +0100, Nagaraj Akkina wrote: > Hello, > > Openstack host show compute-host, shows more memory allocated to instances > than actual physical memory, although the memory allocation ratio is 1.0 in > nova.conf, the same is also shown in horizon dashboard hypervisor statistics. > We can see this in many compute nodes in the cluster. Also these statistics > does not match with free -g or cat /proc/meminfo. > > For Example :                                  Memory_mb > | compute-node23 | (total)                     |  257915 |     > | compute-node23 | (used_now)           |  271360 |     > | compute-node23 | (used_max)           |  267264 |     > > > How to avoid misleading statistics, also which statistics are actually > correct? > > versions : >  openstack : Stein >  nova : 2:19.3.0-0ubuntu1~cloud0 > > Regards, > Akkina  As you've noted, these statistics are generally misleading or outright incorrect. They're so often wrong, in fact, that we have removed them from the API starting with the 2.88 API microversion, which is being introduced in the next release (Wallaby). There are two suggestions. Firstly, Placement provides far better information as to the state of all the things nova knows about and should be used instead. You can find examples of how to replace this using the following link: https://specs.openstack.org/openstack/nova-specs/specs/wallaby/approved/modernize-os-hypervisors-api.html Secondly, the fact that you have overcommit enabled and are still seeing this happen suggests you don't have enough memory reserved for non-VM processes and other overhead. This is configured using the '[DEFAULT] reserved_host_memory_mb', config option, which defaults to a mere 512MB. You may need to increase this, basing your values on the average memory consumption of the host with and without load. For reference, the way that 'memory_mb_used' is calculated is by subtracting the total amount free memory reported via '/proc/meminfo' from the total amount of memory reported by libvirt. Hope this helps, Stephen -------------- next part -------------- An HTML attachment was scrubbed... URL: From christian.rohmann at inovex.de Mon Jan 18 16:24:27 2021 From: christian.rohmann at inovex.de (Christian Rohmann) Date: Mon, 18 Jan 2021 17:24:27 +0100 Subject: Ospurge or "project purge" - What's the right approach to cleanup projects prior to deletion Message-ID: <76498a8c-c8a5-9488-0223-3f47ac4486df@inovex.de> Hello Openstack-Discuss, I was wondering what the right approach to clean up all resources of a project was in order for it to be deleted? 1) There is ospurge (https://opendev.org/x/ospurge) which works, but seems kind of abandoned looking at the last commits and pending issues (https://bugs.launchpad.net/ospurge). Will there still be any further development of this tool? 2) Then there is the project purge command (https://docs.openstack.org/python-openstackclient/victoria/cli/command-objects/project-purge.html) introduced with the Pike release (https://docs.openstack.org/releasenotes/python-openstackclient/pike.html#relnotes-3-12-0-stable-pike // https://bugs.launchpad.net/python-openstackclient/+bug/1584596 // https://review.opendev.org/c/openstack/python-openstackclient/+/367673/). While it seems only natural to have the cleanup / purge functionality built into the openstack client, I was wondering  .. . a) if all potentially existing resources types are covered and this can fully replace ospurge to allow any project to be cleaned up and deleted? What about i.e. Networks, Containers or objects? b) Also ospurge seems to still have some extended options to target or exclude certain resources by using the following options: > [--resource > {Backups,Snapshots,Volumes,Zones,Images,Stacks,FloatingIPs,RouterInterfaces,Routers,Ports,Networks,SecurityGroups,Servers,LoadBalancers,Receivers,Policies,Clusters,Profiles,Objects,Containers}] > [--exclude-resource > {Backups,Snapshots,Volumes,Zones,Images,Stacks,FloatingIPs,RouterInterfaces,Routers,Ports,Networks,SecurityGroups,Servers,LoadBalancers,Receivers,Policies,Clusters,Profiles,Objects,Containers}] those options are not (yet) available for the "project purge" command of the openstack client. With regards, Christian From artem.goncharov at gmail.com Mon Jan 18 17:10:49 2021 From: artem.goncharov at gmail.com (Artem Goncharov) Date: Mon, 18 Jan 2021 18:10:49 +0100 Subject: Ospurge or "project purge" - What's the right approach to cleanup projects prior to deletion In-Reply-To: <76498a8c-c8a5-9488-0223-3f47ac4486df@inovex.de> References: <76498a8c-c8a5-9488-0223-3f47ac4486df@inovex.de> Message-ID: Hi, Please check https://review.opendev.org/c/openstack/python-openstackclient/+/734485 out. This is a followup of the ospurge, which bases on the project cleanup functionality built into OpenStackSDK. Idea is to replace “openstack project purge” functionality to completely rely on SDK only. Please also leave comments whether this works for you or not. Regards, Artem > On 18. Jan 2021, at 17:24, Christian Rohmann wrote: > > Hello Openstack-Discuss, > > > I was wondering what the right approach to clean up all resources of a project was in order for it to be deleted? > > > 1) There is ospurge (https://opendev.org/x/ospurge) which works, but seems kind of abandoned looking at the last commits and pending issues (https://bugs.launchpad.net/ospurge). > Will there still be any further development of this tool? > > > 2) Then there is the project purge command (https://docs.openstack.org/python-openstackclient/victoria/cli/command-objects/project-purge.html) introduced with the > Pike release (https://docs.openstack.org/releasenotes/python-openstackclient/pike.html#relnotes-3-12-0-stable-pike // https://bugs.launchpad.net/python-openstackclient/+bug/1584596 // https://review.opendev.org/c/openstack/python-openstackclient/+/367673/). > > > While it seems only natural to have the cleanup / purge functionality built into the openstack client, I was wondering .. . > > a) if all potentially existing resources types are covered and this can fully replace ospurge to allow any project to be cleaned up and deleted? What about i.e. Networks, Containers or objects? > > b) Also ospurge seems to still have some extended options to target or exclude certain resources by using the following options: > >> [--resource {Backups,Snapshots,Volumes,Zones,Images,Stacks,FloatingIPs,RouterInterfaces,Routers,Ports,Networks,SecurityGroups,Servers,LoadBalancers,Receivers,Policies,Clusters,Profiles,Objects,Containers}] >> [--exclude-resource {Backups,Snapshots,Volumes,Zones,Images,Stacks,FloatingIPs,RouterInterfaces,Routers,Ports,Networks,SecurityGroups,Servers,LoadBalancers,Receivers,Policies,Clusters,Profiles,Objects,Containers}] > > those options are not (yet) available for the "project purge" command of the openstack client. > > > > With regards, > > > Christian > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From zigo at debian.org Mon Jan 18 17:30:33 2021 From: zigo at debian.org (Thomas Goirand) Date: Mon, 18 Jan 2021 18:30:33 +0100 Subject: Ospurge or "project purge" - What's the right approach to cleanup projects prior to deletion In-Reply-To: References: <76498a8c-c8a5-9488-0223-3f47ac4486df@inovex.de> Message-ID: On 1/18/21 6:10 PM, Artem Goncharov wrote: > Hi, > > Please > check https://review.opendev.org/c/openstack/python-openstackclient/+/734485 >  out. > This is a followup of the ospurge, which bases on the project cleanup > functionality built into OpenStackSDK. Idea is to replace “openstack > project purge” functionality to completely rely on SDK only. Please also > leave comments whether this works for you or not. > > Regards, > Artem Hi, While all of this looks like a good idea, it's not implementing anything at all, just a few command line options. So it's currently of no use for operators. I'm still saluting the initiative, but in 6 months, it's kind of slow moving, IMO. Cheers, Thomas Goirand (zigo) From artem.goncharov at gmail.com Mon Jan 18 17:56:42 2021 From: artem.goncharov at gmail.com (Artem Goncharov) Date: Mon, 18 Jan 2021 18:56:42 +0100 Subject: Ospurge or "project purge" - What's the right approach to cleanup projects prior to deletion In-Reply-To: References: <76498a8c-c8a5-9488-0223-3f47ac4486df@inovex.de> Message-ID: <0CC2DFF7-5721-4106-A06B-6FC2970AC07B@gmail.com> What do you mean it doesn’t implement anything at all? It does clean up compute, network, block_storage, orchestrate resources. Moreover it gives you possibility to clean “old” resources (created before or last updated before). > On 18. Jan 2021, at 18:30, Thomas Goirand wrote: > > On 1/18/21 6:10 PM, Artem Goncharov wrote: >> Hi, >> >> Please >> check https://review.opendev.org/c/openstack/python-openstackclient/+/734485 >> out. >> This is a followup of the ospurge, which bases on the project cleanup >> functionality built into OpenStackSDK. Idea is to replace “openstack >> project purge” functionality to completely rely on SDK only. Please also >> leave comments whether this works for you or not. >> >> Regards, >> Artem > Hi, > > While all of this looks like a good idea, it's not implementing anything > at all, just a few command line options. So it's currently of no use for > operators. > > I'm still saluting the initiative, but in 6 months, it's kind of slow > moving, IMO. > > Cheers, > > Thomas Goirand (zigo) > From gmann at ghanshyammann.com Mon Jan 18 18:23:11 2021 From: gmann at ghanshyammann.com (Ghanshyam Mann) Date: Mon, 18 Jan 2021 12:23:11 -0600 Subject: [all][tc] Dropping lower-constraints testing from all projects In-Reply-To: <3c223c99-929e-ab6d-2268-10d361f76349@debian.org> References: <176d8da769b.b6edb13b874337.4809906168220534198@ghanshyammann.com> <3c223c99-929e-ab6d-2268-10d361f76349@debian.org> Message-ID: <17716bc8c42.12286180c5673.4264524174161781845@ghanshyammann.com> ---- On Wed, 06 Jan 2021 15:04:34 -0600 Thomas Goirand wrote ---- > Hi, > > On 1/6/21 6:59 PM, Ghanshyam Mann wrote: > > Hello Everyone, > > > > You might have seen the discussion around dropping the lower constraints > > testing as it becomes more challenging than the current value of doing it. > > As a downstream distribution package maintainer, I see this as a major > regression of the code quality that upstream is shipping. Without l-c > tests, there's no assurance of the reality of a lower-bound dependency. > > So then we're back to 5 years ago, when OpenStack just artificially was > setting very high lower bound because we just didn't know... Hi Zigo, We discussed the usage of l-c file among different packagers in 14th Jan TC meeting[1], can you confirm if Debian directly depends on l-c file and use them OR it is good for code quality if project maintains it? Below packagers does not use l-c file instead use u-c - RDO - openstack-charms - ubuntu [1] http://eavesdrop.openstack.org/meetings/tc/2021/tc.2021-01-14-15.00.log.html#l-105 -gmann > > Please don't do it. > > Cheers, > > Thomas Goirand (zigo) > > From miguel at mlavalle.com Mon Jan 18 18:33:44 2021 From: miguel at mlavalle.com (Miguel Lavalle) Date: Mon, 18 Jan 2021 12:33:44 -0600 Subject: [neutron] bug deputy report January 11th to 17th Message-ID: Hi, Here is this week's bugs deputy report: Critical ====== https://bugs.launchpad.net/neutron/+bug/1911128 Neutron with ovn driver failed to start on Fedora. Needs owner Medium ====== https://bugs.launchpad.net/neutron/+bug/1911153 [FT] DB migration "test_walk_versions" failing frequently. Owner ralonsoh https://bugs.launchpad.net/neutron/+bug/1911214 Scenario test test_multiple_ports_secgroup_inheritance fails in ovn scenario job. Needs owner https://bugs.launchpad.net/neutron/+bug/1910946 ovs is dead but ovs agent is up. Owner Norman Shen. Patch https://review.opendev.org/c/openstack/neutron/+/770058 https://bugs.launchpad.net/neutron/+bug/1911462 Optimize "PortForwarding" OVO loading. Owner Rodolofo Alonso. Patch: https://review.opendev.org/c/openstack/neutron/+/770654 https://bugs.launchpad.net/neutron/+bug/1911925 [FT] "test_read_queue_change_state" failing to initialize the keepalived-state-change monitor. Owner Rodolfo Alonso. Patch https://review.opendev.org/c/openstack/neutron/+/770950 https://bugs.launchpad.net/neutron/+bug/1911927 [FT] "test_add_and_remove_multiple_ips" failing while decoding the JSON file returned by "ip_monitor". Owner Rodolfo Alonso. Patch https://review.opendev.org/c/openstack/neutron/+/770983 https://bugs.launchpad.net/neutron/+bug/1911132 OVN mech driver - can't find Logical_Router errors. Needs owner RFE === https://bugs.launchpad.net/neutron/+bug/1911126 [RFE][L3] add ability to control router SNAT more granularly. Under discussion https://bugs.launchpad.net/neutron/+bug/1911864 [DHCP] AgentBinding for network will be created no matter the state -------------- next part -------------- An HTML attachment was scrubbed... URL: From radoslaw.piliszek at gmail.com Mon Jan 18 18:45:38 2021 From: radoslaw.piliszek at gmail.com (=?UTF-8?Q?Rados=C5=82aw_Piliszek?=) Date: Mon, 18 Jan 2021 19:45:38 +0100 Subject: [all][tc] Dropping lower-constraints testing from all projects In-Reply-To: <17716bc8c42.12286180c5673.4264524174161781845@ghanshyammann.com> References: <176d8da769b.b6edb13b874337.4809906168220534198@ghanshyammann.com> <3c223c99-929e-ab6d-2268-10d361f76349@debian.org> <17716bc8c42.12286180c5673.4264524174161781845@ghanshyammann.com> Message-ID: On Mon, Jan 18, 2021 at 7:24 PM Ghanshyam Mann wrote: > > ---- On Wed, 06 Jan 2021 15:04:34 -0600 Thomas Goirand wrote ---- > > Hi, > > > > On 1/6/21 6:59 PM, Ghanshyam Mann wrote: > > > Hello Everyone, > > > > > > You might have seen the discussion around dropping the lower constraints > > > testing as it becomes more challenging than the current value of doing it. > > > > As a downstream distribution package maintainer, I see this as a major > > regression of the code quality that upstream is shipping. Without l-c > > tests, there's no assurance of the reality of a lower-bound dependency. > > > > So then we're back to 5 years ago, when OpenStack just artificially was > > setting very high lower bound because we just didn't know... > > Hi Zigo, > > We discussed the usage of l-c file among different packagers in 14th Jan TC meeting[1], > > can you confirm if Debian directly depends on l-c file and use them OR it is good for > code quality if project maintains it? > > Below packagers does not use l-c file instead use u-c > - RDO > - openstack-charms > - ubuntu > FWIW, if we are including openstack-charms here, then I can also confirm the same for Kolla - we just use u-c. -yoctozepto From zigo at debian.org Mon Jan 18 18:52:06 2021 From: zigo at debian.org (Thomas Goirand) Date: Mon, 18 Jan 2021 19:52:06 +0100 Subject: Ospurge or "project purge" - What's the right approach to cleanup projects prior to deletion In-Reply-To: <0CC2DFF7-5721-4106-A06B-6FC2970AC07B@gmail.com> References: <76498a8c-c8a5-9488-0223-3f47ac4486df@inovex.de> <0CC2DFF7-5721-4106-A06B-6FC2970AC07B@gmail.com> Message-ID: <7237beb7-a68a-0398-f779-aef76fbc0e82@debian.org> On 1/18/21 6:56 PM, Artem Goncharov wrote: > What do you mean it doesn’t implement anything at all? It does clean up compute, network, block_storage, orchestrate resources. Moreover it gives you possibility to clean “old” resources (created before or last updated before). Oh really? With that few lines of code? I'll re-read the patch then, sorry for my bad assumptions. Can you point at the part that's actually deleting the resources? Thomas Goirand (zigo) From artem.goncharov at gmail.com Mon Jan 18 19:14:37 2021 From: artem.goncharov at gmail.com (Artem Goncharov) Date: Mon, 18 Jan 2021 20:14:37 +0100 Subject: Ospurge or "project purge" - What's the right approach to cleanup projects prior to deletion In-Reply-To: <7237beb7-a68a-0398-f779-aef76fbc0e82@debian.org> References: <76498a8c-c8a5-9488-0223-3f47ac4486df@inovex.de> <0CC2DFF7-5721-4106-A06B-6FC2970AC07B@gmail.com> <7237beb7-a68a-0398-f779-aef76fbc0e82@debian.org> Message-ID: <10C08D43-B4E6-4423-B561-183A4336C488@gmail.com> Ha, thats exactly the case, the whole logic sits in sdk and is spread across the supported services: - https://opendev.org/openstack/openstacksdk/src/branch/master/openstack/compute/v2/_proxy.py#L1798 - for compute. KeyPairs not dropped, since they belong to user, and not to the “project”; - https://opendev.org/openstack/openstacksdk/src/branch/master/openstack/block_storage/v3/_proxy.py#L547 - block storage; - https://opendev.org/openstack/openstacksdk/src/branch/master/openstack/orchestration/v1/_proxy.py#L490 - https://opendev.org/openstack/openstacksdk/src/branch/master/openstack/network/v2/_proxy.py#L4130 - the most complex one in order to give possibility to clean “old” resource without destroying everything else Adding image is few lines of code (never had enough time to add it), identity is a bit tricky, since also here mostly resources does not belong to Project. DNS would be also easy to do. OSC here is only providing I/F, while the logic sits in SDK and can be very easy extended for other services. P.S. I use it this on an hourly basis since more than a year already (not a complete cleanup, but with update_after filter in project where the cloud is monitored). Regards, Artem > On 18. Jan 2021, at 19:52, Thomas Goirand wrote: > > On 1/18/21 6:56 PM, Artem Goncharov wrote: >> What do you mean it doesn’t implement anything at all? It does clean up compute, network, block_storage, orchestrate resources. Moreover it gives you possibility to clean “old” resources (created before or last updated before). > > Oh really? With that few lines of code? I'll re-read the patch then, > sorry for my bad assumptions. > > Can you point at the part that's actually deleting the resources? > > Thomas Goirand (zigo) > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mnaser at vexxhost.com Mon Jan 18 19:59:03 2021 From: mnaser at vexxhost.com (Mohammed Naser) Date: Mon, 18 Jan 2021 14:59:03 -0500 Subject: [tc] weekly update Message-ID: Hi everyone, Here’s an update on what happened in the OpenStack TC this week. You can get more information by checking for changes in openstack/governance repository. # Patches ## Open Reviews - Setting Ke Chen as Watcher's PTL https://review.opendev.org/c/openstack/governance/+/770913 - Drop openSUSE from commonly tested distro list https://review.opendev.org/c/openstack/governance/+/770855 - [manila] add assert:supports-api-interoperability https://review.opendev.org/c/openstack/governance/+/770859 - Add Resolution of TC stance on the OpenStackClient https://review.opendev.org/c/openstack/governance/+/759904 - Define Xena release testing runtime https://review.opendev.org/c/openstack/governance/+/770860 - Cool-down cycle goal https://review.opendev.org/c/openstack/governance/+/770616 - Remove Karbor project team https://review.opendev.org/c/openstack/governance/+/767056 - WIP NO MERGE Move os-*-config to Heat project governance https://review.opendev.org/c/openstack/governance/+/770285 ## Project Updates - Setting Xinran Wang as Cyborg's PTL https://review.opendev.org/c/openstack/governance/+/770075 - Add glance-tempest-plugin to Glance https://review.opendev.org/c/openstack/governance/+/767666 - molteniron does not make releases https://review.opendev.org/c/openstack/governance/+/769805 ## General Changes - Add link to Xena announcement https://review.opendev.org/c/openstack/governance/+/769620 - Add doc/requirements https://review.opendev.org/c/openstack/governance/+/769696 # Other Reminders - Our next [TC] Weekly meeting is scheduled for January 21st at 1500 UTC. If you would like to add topics for discussion, please go to https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting and fill out your suggestions by Wednesday, January 20th, at 2100 UTC. Thanks for reading! Mohammed & Kendall -- Mohammed Naser VEXXHOST, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From m64m64m64ali at outlook.com Mon Jan 18 13:32:01 2021 From: m64m64m64ali at outlook.com (ali ali) Date: Mon, 18 Jan 2021 13:32:01 +0000 Subject: Openstack integration with NSX-T Message-ID: Hi. I use Openstack train version and I want to integrate openstack with nsx-t. I only found the following documentation. https://docs.vmware.com/en/VMware-NSX-T-Data-Center/2.5/nsxt-openstack-plugin-installation/GUID-FA2371AE-6B1D-4C81-9B69-C877ED138B17.html and at the start of integration, I install, following packages apt install python-vmware-nsxlib openstack-vmware-nsx python-neutron-fwaas outputs: E: Unable to locate package openstack-vmware-nsx The following packages have unmet dependencies: python-neutron-fwaas : Depends: python-neutron (>= 2:12.0.0~) but it is not going to be installed E: Unmet dependencies. Try 'apt --fix-broken install' with no packages (or specify a solution). when I checked there are no python-neutron packages but there was a python3-neutron package. I don't know what to do with this problem. I think if I delete python3-neutron and install python-neutron, everything will crash and mess up. is it basicly possible to integrate openstack train or ussuri or victoryia with nsx-t? -------------- next part -------------- An HTML attachment was scrubbed... URL: From fungi at yuggoth.org Tue Jan 19 00:34:58 2021 From: fungi at yuggoth.org (Jeremy Stanley) Date: Tue, 19 Jan 2021 00:34:58 +0000 Subject: Openstack integration with NSX-T In-Reply-To: References: Message-ID: <20210119003458.xmq22gbiiaept6hr@yuggoth.org> On 2021-01-18 13:32:01 +0000 (+0000), ali ali wrote: > I use Openstack train version and I want to integrate openstack > with nsx-t. I only found the following documentation. > https://docs.vmware.com/en/VMware-NSX-T-Data-Center/2.5/nsxt-openstack-plugin-installation/GUID-FA2371AE-6B1D-4C81-9B69-C877ED138B17.html [...] > is it basicly possible to integrate openstack train or ussuri or > victoryia with nsx-t? According to that documentation provided by vmWare: "The NSX-T Data Center Plugin for OpenStack has the following specific requirements[...] Stein" It looks like they'll need to provide updated packages which support newer OpenStack releases. In particular, they seem to want OpenStack packages run with the Python v2 interpreter, while modern releases of OpenStack only support Python v3 (hence the different package names you found in your distro). If you have a support contract with vmWare, you may want to reach out to your service representative and ask them what their plans are for NSX-T and OpenStack. I see the same site has documentation for a "VMware NSX-T Data Center Plugin 3.1" and mentions OpenStack Train, so maybe that's closer to what you need? Still doesn't take care of Ussuri for you though. -- Jeremy Stanley -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From iwienand at redhat.com Tue Jan 19 05:58:30 2021 From: iwienand at redhat.com (Ian Wienand) Date: Tue, 19 Jan 2021 16:58:30 +1100 Subject: [all] CI test result table in the new gerrit review UI In-Reply-To: References: Message-ID: <20210119055830.GB3137911@fedora19.localdomain> On Thu, Nov 26, 2020 at 01:39:13PM +0100, Balázs Gibizer wrote: > I understand that adapting the old CI test result table to the new gerrit > review UI is not a simple task. We got there in the end :) Change [1] enabled the zuul-summary-results plugin, which is available from [2]. I just restarted opendev gerrit with it, and it seems to be working. Look for the new "Zuul Summary" tab next to "Files". I would consider it a 0.1 release and welcome any contributions to make it better. If you want to make changes, you should be able to submit a change to system-config with a Depends-On: and trigger the system-config-run-review test; in the results returned there are screenshot artifacts that will show the results (expanding this testing also welcome!). We can also a put a node on hold for you to work on the plugin if you have interest. It's also fairly easy to run the container locally, so there's plenty of options. Thanks, -i [1] https://review.opendev.org/c/opendev/system-config/+/767079 [2] https://gerrit-review.googlesource.com/admin/repos/plugins/zuul-results-summary From anost1986 at gmail.com Tue Jan 19 06:48:53 2021 From: anost1986 at gmail.com (Andrii Ostapenko) Date: Tue, 19 Jan 2021 00:48:53 -0600 Subject: [all] CI test result table in the new gerrit review UI In-Reply-To: <20210119055830.GB3137911@fedora19.localdomain> References: <20210119055830.GB3137911@fedora19.localdomain> Message-ID: One click more than before, but looks great! Thank you! On Tue, Jan 19, 2021 at 12:00 AM Ian Wienand wrote: > > On Thu, Nov 26, 2020 at 01:39:13PM +0100, Balázs Gibizer wrote: > > I understand that adapting the old CI test result table to the new gerrit > > review UI is not a simple task. > > We got there in the end :) Change [1] enabled the zuul-summary-results > plugin, which is available from [2]. I just restarted opendev gerrit > with it, and it seems to be working. Look for the new "Zuul Summary" > tab next to "Files". I would consider it a 0.1 release and welcome > any contributions to make it better. > > If you want to make changes, you should be able to submit a change to > system-config with a Depends-On: and trigger the > system-config-run-review test; in the results returned there are > screenshot artifacts that will show the results (expanding this > testing also welcome!). We can also a put a node on hold for you to > work on the plugin if you have interest. It's also fairly easy to run > the container locally, so there's plenty of options. > > Thanks, > > -i > > [1] https://review.opendev.org/c/opendev/system-config/+/767079 > [2] https://gerrit-review.googlesource.com/admin/repos/plugins/zuul-results-summary > > From zigo at debian.org Tue Jan 19 07:03:25 2021 From: zigo at debian.org (Thomas Goirand) Date: Tue, 19 Jan 2021 08:03:25 +0100 Subject: [all][tc] Dropping lower-constraints testing from all projects In-Reply-To: <17716bc8c42.12286180c5673.4264524174161781845@ghanshyammann.com> References: <176d8da769b.b6edb13b874337.4809906168220534198@ghanshyammann.com> <3c223c99-929e-ab6d-2268-10d361f76349@debian.org> <17716bc8c42.12286180c5673.4264524174161781845@ghanshyammann.com> Message-ID: On 1/18/21 7:23 PM, Ghanshyam Mann wrote: > ---- On Wed, 06 Jan 2021 15:04:34 -0600 Thomas Goirand wrote ---- > > Hi, > > > > On 1/6/21 6:59 PM, Ghanshyam Mann wrote: > > > Hello Everyone, > > > > > > You might have seen the discussion around dropping the lower constraints > > > testing as it becomes more challenging than the current value of doing it. > > > > As a downstream distribution package maintainer, I see this as a major > > regression of the code quality that upstream is shipping. Without l-c > > tests, there's no assurance of the reality of a lower-bound dependency. > > > > So then we're back to 5 years ago, when OpenStack just artificially was > > setting very high lower bound because we just didn't know... > > Hi Zigo, > > We discussed the usage of l-c file among different packagers in 14th Jan TC meeting[1], > > can you confirm if Debian directly depends on l-c file and use them OR it is good for > code quality if project maintains it? > > Below packagers does not use l-c file instead use u-c > - RDO > - openstack-charms > - ubuntu > > > [1] http://eavesdrop.openstack.org/meetings/tc/2021/tc.2021-01-14-15.00.log.html#l-105 > > -gmann Hi, Of course, I'm using upper-constraints too, to try to package them as much as possible, however, the dependencies are expressed according to lower-constraints. Let's say we have dependency a that has ===2.1 in u-c, but 1.9 in l-c. I'll write: Depends: a (>= 1.9) but will try to get 2.1 in Debian. At the end, if 1.9 is in Debian stable backports, I may attempt to not do the backporting job for 2.1, as the project is telling me 1.9 works ok and that it's useless work. Does this make sense now? Cheers, Thomas Goirand (zigo) From marios at redhat.com Tue Jan 19 07:04:07 2021 From: marios at redhat.com (Marios Andreou) Date: Tue, 19 Jan 2021 09:04:07 +0200 Subject: [all] CI test result table in the new gerrit review UI In-Reply-To: References: <20210119055830.GB3137911@fedora19.localdomain> Message-ID: On Tue, Jan 19, 2021 at 8:52 AM Andrii Ostapenko wrote: > One click more than before, but looks great! Thank you! > > +1 it really does look great very clear and easy to see the failure (and bonus it's even clearer than it was in the 'old' zuul) thanks very much Balazs for bringing this up and big thanks to Ian and anyone else who worked on that On Tue, Jan 19, 2021 at 12:00 AM Ian Wienand wrote: > > > > On Thu, Nov 26, 2020 at 01:39:13PM +0100, Balázs Gibizer wrote: > > > I understand that adapting the old CI test result table to the new > gerrit > > > review UI is not a simple task. > > > > We got there in the end :) Change [1] enabled the zuul-summary-results > > plugin, which is available from [2]. I just restarted opendev gerrit > > with it, and it seems to be working. Look for the new "Zuul Summary" > > tab next to "Files". I would consider it a 0.1 release and welcome > > any contributions to make it better. > > > > If you want to make changes, you should be able to submit a change to > > system-config with a Depends-On: and trigger the > > system-config-run-review test; in the results returned there are > > screenshot artifacts that will show the results (expanding this > > testing also welcome!). We can also a put a node on hold for you to > > work on the plugin if you have interest. It's also fairly easy to run > > the container locally, so there's plenty of options. > > > > Thanks, > > > > -i > > > > [1] https://review.opendev.org/c/opendev/system-config/+/767079 > > [2] > https://gerrit-review.googlesource.com/admin/repos/plugins/zuul-results-summary > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From skaplons at redhat.com Tue Jan 19 07:52:16 2021 From: skaplons at redhat.com (Slawek Kaplonski) Date: Tue, 19 Jan 2021 08:52:16 +0100 Subject: Openstack integration with NSX-T In-Reply-To: References: Message-ID: <20210119075216.typhykuhpkog6ylk@p1.localdomain> Hi, On Mon, Jan 18, 2021 at 01:32:01PM +0000, ali ali wrote: > Hi. > I use Openstack train version and I want to integrate openstack with nsx-t. I only found the following documentation. > https://docs.vmware.com/en/VMware-NSX-T-Data-Center/2.5/nsxt-openstack-plugin-installation/GUID-FA2371AE-6B1D-4C81-9B69-C877ED138B17.html > > > and at the start of integration, I install, following packages > apt install python-vmware-nsxlib openstack-vmware-nsx python-neutron-fwaas > > outputs: > E: Unable to locate package openstack-vmware-nsx > The following packages have unmet dependencies: > python-neutron-fwaas : Depends: python-neutron (>= 2:12.0.0~) but it is not going to be installed > E: Unmet dependencies. Try 'apt --fix-broken install' with no packages (or specify a solution). Just FYI, please remember that neutron-fwaas project was deprecated as neutron stadium in Ussuri cycle and Ussuri is last stable release of it. There is no newer releases and this project is not maintained anymore. > > when I checked there are no python-neutron packages but there was a python3-neutron package. > > I don't know what to do with this problem. > I think if I delete python3-neutron and install python-neutron, everything will crash and mess up. > > is it basicly possible to integrate openstack train or ussuri or victoryia with nsx-t? > -- Slawek Kaplonski Principal Software Engineer Red Hat -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: not available URL: From skaplons at redhat.com Tue Jan 19 07:56:02 2021 From: skaplons at redhat.com (Slawek Kaplonski) Date: Tue, 19 Jan 2021 08:56:02 +0100 Subject: [all] CI test result table in the new gerrit review UI In-Reply-To: References: <20210119055830.GB3137911@fedora19.localdomain> Message-ID: <20210119075602.eimellc6icvkhdbf@p1.localdomain> Hi, On Tue, Jan 19, 2021 at 09:04:07AM +0200, Marios Andreou wrote: > On Tue, Jan 19, 2021 at 8:52 AM Andrii Ostapenko > wrote: > > > One click more than before, but looks great! Thank you! > > > > > +1 it really does look great very clear and easy to see the failure (and > bonus it's even clearer than it was in the 'old' zuul) > > thanks very much Balazs for bringing this up and big thanks to Ian and > anyone else who worked on that +1, thx for that improvement :) > > > > On Tue, Jan 19, 2021 at 12:00 AM Ian Wienand wrote: > > > > > > On Thu, Nov 26, 2020 at 01:39:13PM +0100, Balázs Gibizer wrote: > > > > I understand that adapting the old CI test result table to the new > > gerrit > > > > review UI is not a simple task. > > > > > > We got there in the end :) Change [1] enabled the zuul-summary-results > > > plugin, which is available from [2]. I just restarted opendev gerrit > > > with it, and it seems to be working. Look for the new "Zuul Summary" > > > tab next to "Files". I would consider it a 0.1 release and welcome > > > any contributions to make it better. > > > > > > If you want to make changes, you should be able to submit a change to > > > system-config with a Depends-On: and trigger the > > > system-config-run-review test; in the results returned there are > > > screenshot artifacts that will show the results (expanding this > > > testing also welcome!). We can also a put a node on hold for you to > > > work on the plugin if you have interest. It's also fairly easy to run > > > the container locally, so there's plenty of options. > > > > > > Thanks, > > > > > > -i > > > > > > [1] https://review.opendev.org/c/opendev/system-config/+/767079 > > > [2] > > https://gerrit-review.googlesource.com/admin/repos/plugins/zuul-results-summary > > > > > > > > > > -- Slawek Kaplonski Principal Software Engineer Red Hat -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: not available URL: From hberaud at redhat.com Tue Jan 19 08:39:02 2021 From: hberaud at redhat.com (Herve Beraud) Date: Tue, 19 Jan 2021 09:39:02 +0100 Subject: [Release-job-failures] Release of openstack/monasca-tempest-plugin for ref refs/tags/2.2.0 failed In-Reply-To: References: Message-ID: Hello monasca team, FYI a release failure happened on monasca-tempest-plugin within the job publish-monasca-tempest-plugin-docker-image. This build was triggered by https://review.opendev.org/c/openstack/releases/+/768551 (the Wallaby part). A new incompatibility in requirements was found by pip's new resolver: > pykafka 2.8.0 has requirement kazoo==2.5.0, but you'll have kazoo 2.8.0 which is incompatible. (c.f https://zuul.opendev.org/t/openstack/build/aba1acc623e74cf08e82ffc4d73134aa/log/job-output.txt#1157 ) I didn't find a trace of these requirements on your repo so I think they are pulled/resolved from/for underlying libraries. After that the job fails to push the "latest" docker tag because the tag is not found, I think it's a side effect of the previous error. (c.f https://zuul.opendev.org/t/openstack/build/aba1acc623e74cf08e82ffc4d73134aa/log/job-output.txt#1443 ) Let us know if we can help you, The Release Team. Le lun. 18 janv. 2021 à 23:31, a écrit : > Build failed. > > - openstack-upload-github-mirror > https://zuul.opendev.org/t/openstack/build/8dd9a4fce3bc4ae2a32134b7d7fec5b5 > : SUCCESS in 52s > - release-openstack-python > https://zuul.opendev.org/t/openstack/build/ff7c8136563444df9c565f07f618c559 > : SUCCESS in 3m 44s > - announce-release > https://zuul.opendev.org/t/openstack/build/78731c6e0948490d82e1e2d14eb67857 > : SUCCESS in 3m 42s > - propose-update-constraints > https://zuul.opendev.org/t/openstack/build/3eab7a3209a84a33b8d7b69e41e185cb > : SUCCESS in 2m 49s > - publish-monasca-tempest-plugin-docker-image > https://zuul.opendev.org/t/openstack/build/aba1acc623e74cf08e82ffc4d73134aa > : POST_FAILURE in 8m 19s > > _______________________________________________ > Release-job-failures mailing list > Release-job-failures at lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/release-job-failures > -- Hervé Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/ https://twitter.com/4383hberaud -----BEGIN PGP SIGNATURE----- wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O v6rDpkeNksZ9fFSyoY2o =ECSj -----END PGP SIGNATURE----- -------------- next part -------------- An HTML attachment was scrubbed... URL: From doug at stackhpc.com Tue Jan 19 09:36:14 2021 From: doug at stackhpc.com (Doug) Date: Tue, 19 Jan 2021 09:36:14 +0000 Subject: [monasca][release] Abandoning monasca-ceilometer and monasca-log-api? In-Reply-To: References: Message-ID: <72283d02-7f75-1589-e5e1-4f5ac0d91334@stackhpc.com> On 15/01/2021 09:15, Herve Beraud wrote: > Dear Monasca team, Hi Herve > > The release team noticed an inconsistency between the Monasca team's > deliverables described in the governance’s reference and deliverables > defined in the openstack/releases repo (c.f our related meeting topic > [1]). > > Indeed, monasca-ceilometer and monasca-log-api were released in train > but not released in ussuri nor victoria. Do you think that they should > be deprecated (abandoned) in governance? Both of these services have been deprecated (see details below). Please proceed. https://review.opendev.org/c/openstack/monasca-ceilometer/+/720319 https://review.opendev.org/c/openstack/monasca-log-api/+/704519 > > Notice that Wallaby's milestone 2 is next week so maybe it could be a > good time to update this. > > Let us know your thoughts, we are waiting for your replies. > > Thanks for reading, Thanks! > > [1] > http://eavesdrop.openstack.org/irclogs/%23openstack-release/%23openstack-release.2021-01-14.log.html#t2021-01-14T17:05:23 > > > -- > Hervé Beraud > Senior Software Engineer at Red Hat > irc: hberaud > https://github.com/4383/ > https://twitter.com/4383hberaud > -----BEGIN PGP SIGNATURE----- > > wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ > Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ > RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP > F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G > 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g > glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw > m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ > hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 > qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y > F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 > B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O > v6rDpkeNksZ9fFSyoY2o > =ECSj > -----END PGP SIGNATURE----- > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hberaud at redhat.com Tue Jan 19 10:17:39 2021 From: hberaud at redhat.com (Herve Beraud) Date: Tue, 19 Jan 2021 11:17:39 +0100 Subject: [monasca][release] Abandoning monasca-ceilometer and monasca-log-api? In-Reply-To: <72283d02-7f75-1589-e5e1-4f5ac0d91334@stackhpc.com> References: <72283d02-7f75-1589-e5e1-4f5ac0d91334@stackhpc.com> Message-ID: Thanks Doug for your response. I think that more steps are needed to deprecate your repos properly: https://docs.openstack.org/project-team-guide/repository.html#deprecating-a-repository The release part is the last step of the deprecation. Also I think that it could be better to let a monasca team member submit these patches to inform the governance team and project-config team of your choices concerning these repos. With all these patches we will have a whole consistent state. Let me know what you think. Thanks, Le mar. 19 janv. 2021 à 10:36, Doug a écrit : > > On 15/01/2021 09:15, Herve Beraud wrote: > > Dear Monasca team, > > Hi Herve > > > The release team noticed an inconsistency between the Monasca team's > deliverables described in the governance’s reference and deliverables > defined in the openstack/releases repo (c.f our related meeting topic [1]). > > Indeed, monasca-ceilometer and monasca-log-api were released in train but > not released in ussuri nor victoria. Do you think that they should be > deprecated (abandoned) in governance? > > Both of these services have been deprecated (see details below). Please > proceed. > > https://review.opendev.org/c/openstack/monasca-ceilometer/+/720319 > > https://review.opendev.org/c/openstack/monasca-log-api/+/704519 > > > Notice that Wallaby's milestone 2 is next week so maybe it could be a good > time to update this. > > Let us know your thoughts, we are waiting for your replies. > > Thanks for reading, > > Thanks! > > > [1] > http://eavesdrop.openstack.org/irclogs/%23openstack-release/%23openstack-release.2021-01-14.log.html#t2021-01-14T17:05:23 > > -- > Hervé Beraud > Senior Software Engineer at Red Hat > irc: hberaud > https://github.com/4383/ > https://twitter.com/4383hberaud > -----BEGIN PGP SIGNATURE----- > > wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ > Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ > RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP > F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G > 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g > glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw > m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ > hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 > qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y > F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 > B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O > v6rDpkeNksZ9fFSyoY2o > =ECSj > -----END PGP SIGNATURE----- > > -- Hervé Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/ https://twitter.com/4383hberaud -----BEGIN PGP SIGNATURE----- wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O v6rDpkeNksZ9fFSyoY2o =ECSj -----END PGP SIGNATURE----- -------------- next part -------------- An HTML attachment was scrubbed... URL: From dtantsur at redhat.com Tue Jan 19 11:37:33 2021 From: dtantsur at redhat.com (Dmitry Tantsur) Date: Tue, 19 Jan 2021 12:37:33 +0100 Subject: [all] CI test result table in the new gerrit review UI In-Reply-To: <20210119055830.GB3137911@fedora19.localdomain> References: <20210119055830.GB3137911@fedora19.localdomain> Message-ID: On Tue, Jan 19, 2021 at 7:01 AM Ian Wienand wrote: > On Thu, Nov 26, 2020 at 01:39:13PM +0100, Balázs Gibizer wrote: > > I understand that adapting the old CI test result table to the new gerrit > > review UI is not a simple task. > > We got there in the end :) Change [1] enabled the zuul-summary-results > plugin, which is available from [2]. I just restarted opendev gerrit > with it, and it seems to be working. Look for the new "Zuul Summary" > tab next to "Files". I would consider it a 0.1 release and welcome > any contributions to make it better. > Thank you, this is amazing! I wonder if we could also run the plugin that shows the live progress (it was mentioned somewhere in the thread). Dmitry > > If you want to make changes, you should be able to submit a change to > system-config with a Depends-On: and trigger the > system-config-run-review test; in the results returned there are > screenshot artifacts that will show the results (expanding this > testing also welcome!). We can also a put a node on hold for you to > work on the plugin if you have interest. It's also fairly easy to run > the container locally, so there's plenty of options. > > Thanks, > > -i > > [1] https://review.opendev.org/c/opendev/system-config/+/767079 > [2] > https://gerrit-review.googlesource.com/admin/repos/plugins/zuul-results-summary > > > -- Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill -------------- next part -------------- An HTML attachment was scrubbed... URL: From balazs.gibizer at est.tech Tue Jan 19 11:44:09 2021 From: balazs.gibizer at est.tech (Balazs Gibizer) Date: Tue, 19 Jan 2021 12:44:09 +0100 Subject: [all] CI test result table in the new gerrit review UI In-Reply-To: <20210119055830.GB3137911@fedora19.localdomain> References: <20210119055830.GB3137911@fedora19.localdomain> Message-ID: On Tue, Jan 19, 2021 at 16:58, Ian Wienand wrote: > On Thu, Nov 26, 2020 at 01:39:13PM +0100, Balázs Gibizer wrote: >> I understand that adapting the old CI test result table to the new >> gerrit >> review UI is not a simple task. > > We got there in the end :) Change [1] enabled the zuul-summary-results > plugin, which is available from [2]. I just restarted opendev gerrit > with it, and it seems to be working. Look for the new "Zuul Summary" > tab next to "Files". I would consider it a 0.1 release and welcome > any contributions to make it better. > > If you want to make changes, you should be able to submit a change to > system-config with a Depends-On: and trigger the > system-config-run-review test; in the results returned there are > screenshot artifacts that will show the results (expanding this > testing also welcome!). We can also a put a node on hold for you to > work on the plugin if you have interest. It's also fairly easy to run > the container locally, so there's plenty of options. Awesome. Thank you Ian! Cheers, gibi > > Thanks, > > -i > > [1] https://review.opendev.org/c/opendev/system-config/+/767079 > [2] > https://gerrit-review.googlesource.com/admin/repos/plugins/zuul-results-summary > From szabolcs at szabolcstoth.eu Tue Jan 19 11:49:19 2021 From: szabolcs at szabolcstoth.eu (=?iso-8859-1?Q?Szabolcs_T=F3th?=) Date: Tue, 19 Jan 2021 11:49:19 +0000 Subject: [tempest] extending python-tempestconf In-Reply-To: References: Message-ID: Hej! The official tool named python-tempestconf has a parameter named --create, which allows to create the following resources: * CirrOS image (uploads the image based on the location defined with --image parameter), * Flavors (based on default values - DEFAULT_FLAVOR_RAM, DEFAULT_FLAVOR_RAM_ALT, DEFAULT_FLAVOR_DISK - which can be changed with --flavor-min-mem and --flavor-min-disk). In order to verify our specific installation with Tempest, we need to create the basic resources as * Flavors (with extra-spec parameters like hw:mem_page_size). * Networks (one for fixed_network_name and one for floating_network_name). * python-tempestconf is able to find an already existing network created with router:external flag and set it as value for floating_network_name. * Router and port (for routing traffic between internal and external networks). I would like to ask the following: * Is there any particular reason why the basic resource create functionality is limited to the image and flavor? * Are there any plans to extend the basic resource create functionality? * Ability to set extra parameters for the flavors. * Creating networks, routers and ports (based on a user inputs, which can be separate parameters or a specific file). Would the community accept contributions extending python-tempestconf into this direction? -- BR, Szabolcs -------------- next part -------------- An HTML attachment was scrubbed... URL: From ltoscano at redhat.com Tue Jan 19 12:14:32 2021 From: ltoscano at redhat.com (Luigi Toscano) Date: Tue, 19 Jan 2021 13:14:32 +0100 Subject: [tempest] extending python-tempestconf In-Reply-To: References: Message-ID: <10167377.aFP6jjVeTY@whitebase.usersys.redhat.com> On Tuesday, 19 January 2021 12:49:19 CET Szabolcs Tóth wrote: > Hej! > > The official tool named python-tempestconf has a parameter named --create, > which allows to create the following resources: > > * CirrOS image (uploads the image based on the location defined with > --image parameter), * Flavors (based on default values - > DEFAULT_FLAVOR_RAM, DEFAULT_FLAVOR_RAM_ALT, DEFAULT_FLAVOR_DISK - which can > be changed with --flavor-min-mem and --flavor-min-disk). > > In order to verify our specific installation with Tempest, we need to create > the basic resources as > > * Flavors (with extra-spec parameters like hw:mem_page_size). > * Networks (one for fixed_network_name and one for > floating_network_name). > > * python-tempestconf is able to find an already existing network > created with router:external flag and set it as value for > floating_network_name. > > * Router and port (for routing traffic between internal and external > networks). > > I would like to ask the following: > > * Is there any particular reason why the basic resource create > functionality is limited to the image and flavor? > * Are there any plans > to extend the basic resource create functionality? The aim of python-tempestconf (which is not part of the QA/tempest project, but of the refstack project) is described as "for automatic generation of tempest configuration based on user’s cloud." This means that any resource creation is limited to what is needed for running "the basics" of tempest. >From an historical point of view, it is not meant to be able to discover everything, but to be used as starting point for your tempest settings, which means that tests may work with the output of tempestconf, but tuning may be needed and it is expected. > > * Ability to set extra parameters for the flavors. > * Creating networks, routers and ports (based on a user inputs, which > can be separate parameters or a specific file). > > Would the community accept contributions extending python-tempestconf into > this direction? I'd leave space to other python-tempestconf people, but IMHO this will stretch the scope of the project. -- Luigi From ralonsoh at redhat.com Tue Jan 19 12:21:53 2021 From: ralonsoh at redhat.com (Rodolfo Alonso Hernandez) Date: Tue, 19 Jan 2021 13:21:53 +0100 Subject: [all] CI test result table in the new gerrit review UI In-Reply-To: References: <20210119055830.GB3137911@fedora19.localdomain> Message-ID: Thanks Ian! Very useful. On Tue, Jan 19, 2021 at 12:48 PM Balazs Gibizer wrote: > > > On Tue, Jan 19, 2021 at 16:58, Ian Wienand wrote: > > On Thu, Nov 26, 2020 at 01:39:13PM +0100, Balázs Gibizer wrote: > >> I understand that adapting the old CI test result table to the new > >> gerrit > >> review UI is not a simple task. > > > > We got there in the end :) Change [1] enabled the zuul-summary-results > > plugin, which is available from [2]. I just restarted opendev gerrit > > with it, and it seems to be working. Look for the new "Zuul Summary" > > tab next to "Files". I would consider it a 0.1 release and welcome > > any contributions to make it better. > > > > If you want to make changes, you should be able to submit a change to > > system-config with a Depends-On: and trigger the > > system-config-run-review test; in the results returned there are > > screenshot artifacts that will show the results (expanding this > > testing also welcome!). We can also a put a node on hold for you to > > work on the plugin if you have interest. It's also fairly easy to run > > the container locally, so there's plenty of options. > > Awesome. Thank you Ian! > > Cheers, > gibi > > > > > Thanks, > > > > -i > > > > [1] https://review.opendev.org/c/opendev/system-config/+/767079 > > [2] > > > https://gerrit-review.googlesource.com/admin/repos/plugins/zuul-results-summary > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From christian.rohmann at inovex.de Tue Jan 19 12:33:57 2021 From: christian.rohmann at inovex.de (Christian Rohmann) Date: Tue, 19 Jan 2021 13:33:57 +0100 Subject: Ospurge or "project purge" - What's the right approach to cleanup projects prior to deletion In-Reply-To: <10C08D43-B4E6-4423-B561-183A4336C488@gmail.com> References: <76498a8c-c8a5-9488-0223-3f47ac4486df@inovex.de> <0CC2DFF7-5721-4106-A06B-6FC2970AC07B@gmail.com> <7237beb7-a68a-0398-f779-aef76fbc0e82@debian.org> <10C08D43-B4E6-4423-B561-183A4336C488@gmail.com> Message-ID: <9f408ffe-4046-76e0-bbdf-57ee94191738@inovex.de> Hey Artem, thank you very much for your quick reply and pointer to the patchset you work on! On 18/01/2021 20:14, Artem Goncharov wrote: > Ha, thats exactly the case, the whole logic sits in sdk and is spread > across the supported services: > - > https://opendev.org/openstack/openstacksdk/src/branch/master/openstack/compute/v2/_proxy.py#L1798 >  - > for compute. KeyPairs not dropped, since they belong to user, and not > to the “project”; > - > https://opendev.org/openstack/openstacksdk/src/branch/master/openstack/block_storage/v3/_proxy.py#L547 >  - > block storage; > - > https://opendev.org/openstack/openstacksdk/src/branch/master/openstack/orchestration/v1/_proxy.py#L490 > > - > https://opendev.org/openstack/openstacksdk/src/branch/master/openstack/network/v2/_proxy.py#L4130 >  - > the most complex one in order to give possibility to clean “old” > resource without destroying everything else > > Adding image is few lines of code (never had enough time to add it), > identity is a bit tricky, since also here mostly resources does not > belong to Project. DNS would be also easy to do. OSC here is only > providing I/F, while the logic sits in SDK and can be very easy > extended for other services. >> On 18. Jan 2021, at 19:52, Thomas Goirand > > wrote: >> >> On 1/18/21 6:56 PM, Artem Goncharov wrote: >>> What do you mean it doesn’t implement anything at all? It does clean >>> up compute, network, block_storage, orchestrate resources. Moreover >>> it gives you possibility to clean “old” resources (created before or >>> last updated before). >> >> Oh really? With that few lines of code? I'll re-read the patch then, >> sorry for my bad assumptions. >> >> Can you point at the part that's actually deleting the resources? If I understood correctly, the cleanup relies on the SDK functionality / requirement for each resource type to provide a corresponding function( https://github.com/openstack/openstacksdk/blob/master/openstack/cloud/openstackcloud.py#L762) ? Reading through the (SDK) code this even covers depending resources, nice! I certainly will leave some feedback and comments in your change (https://review.opendev.org/c/openstack/python-openstackclient/+/734485). But what are your immediate plans moving forward on with this then, Artem? There is a little todo list in the description on your change .. is there anything you yourself know that is still missing before taking this to a full review and finally merging it? Only code that is shipped and then actively used will improve further and people will notice other required functionality or switches for later iterations. With the current state of having a somewhat working but unmaintained ospurge and a non feature complete "project purge"  (supports only Block Storage v1, v2; Compute v2; Image v1, v2) this will only cause people to start hacking away on the ospurge codebase or worse building their own tools and scripts to implement project cleanup for their environments over and over again. Regards, Christian -------------- next part -------------- An HTML attachment was scrubbed... URL: From smooney at redhat.com Tue Jan 19 12:56:41 2021 From: smooney at redhat.com (Sean Mooney) Date: Tue, 19 Jan 2021 12:56:41 +0000 Subject: [all] CI test result table in the new gerrit review UI In-Reply-To: References: <20210119055830.GB3137911@fedora19.localdomain> Message-ID: On Tue, 2021-01-19 at 12:37 +0100, Dmitry Tantsur wrote: > On Tue, Jan 19, 2021 at 7:01 AM Ian Wienand wrote: > > > On Thu, Nov 26, 2020 at 01:39:13PM +0100, Balázs Gibizer wrote: > > > I understand that adapting the old CI test result table to the new gerrit > > > review UI is not a simple task. > > > > We got there in the end :) Change [1] enabled the zuul-summary-results > > plugin, which is available from [2]. I just restarted opendev gerrit > > with it, and it seems to be working. Look for the new "Zuul Summary" > > tab next to "Files". I would consider it a 0.1 release and welcome > > any contributions to make it better. > > > > Thank you, this is amazing! I wonder if we could also run the plugin that > shows the live progress (it was mentioned somewhere in the thread). > > Dmitry i belive showing the live progress of the jobs is effectivly a ddos vector. infra have ask that we not use javascript to pool the the live status of the jobs in our browser in the past. providing a link to the running zuul objs that are not actively pooling might be nice at least for the 1st party ci. there might be a way for 3rd party ci to post a link to the builds or something for there results. my concern would still remain though with anything that does active pooling ddosing the zuul api. i know that we previously tried enbeding the zuul job status directly into gerrit a few years ago and that had to be qickly reverted as it does not take many developers leave review open in a tab to quickly make that unworkable. i know i for one often leave review open over night if im pinged to review something shortly before i finish for the day so that its open on my screen when i log in the next day. if that tab was activly pooling ci jobs that would be an issue if many people did it. if it was just as static liknk on the other hand to the job build it would not have the same downside. so i guess it depend on if you want live updates of the running jobs or just a one of server side generated static link to the running job that you can click though to look at its console output. the latter might be nice but i am not sure the former is a good idea for the reason i mentioned. > > > > > > If you want to make changes, you should be able to submit a change to > > system-config with a Depends-On: and trigger the > > system-config-run-review test; in the results returned there are > > screenshot artifacts that will show the results (expanding this > > testing also welcome!). We can also a put a node on hold for you to > > work on the plugin if you have interest. It's also fairly easy to run > > the container locally, so there's plenty of options. > > > > Thanks, > > > > -i > > > > [1] https://review.opendev.org/c/opendev/system-config/+/767079 > > [2] > > https://gerrit-review.googlesource.com/admin/repos/plugins/zuul-results-summary > > > > > > > From artem.goncharov at gmail.com Tue Jan 19 13:16:28 2021 From: artem.goncharov at gmail.com (Artem Goncharov) Date: Tue, 19 Jan 2021 14:16:28 +0100 Subject: Ospurge or "project purge" - What's the right approach to cleanup projects prior to deletion In-Reply-To: <9f408ffe-4046-76e0-bbdf-57ee94191738@inovex.de> References: <76498a8c-c8a5-9488-0223-3f47ac4486df@inovex.de> <0CC2DFF7-5721-4106-A06B-6FC2970AC07B@gmail.com> <7237beb7-a68a-0398-f779-aef76fbc0e82@debian.org> <10C08D43-B4E6-4423-B561-183A4336C488@gmail.com> <9f408ffe-4046-76e0-bbdf-57ee94191738@inovex.de> Message-ID: <5C651C9C-0D00-4CB8-9992-4AC23D92FE38@gmail.com> Hi Christian. Actually the patch stuck due to lack of reviewers. Idea here was not to replace “openstack project purge”, but to add a totally new implementation (hopefully later dropping project purge as such). From my POV at the moment there is nothing else I was thinking to mandatorily implement on OSC side (sure, for future I would like to give possibility to limit services to cleanup, to add cleanup of key-airs, etc). SDK part is completely independent of that. Here we definitely need to add dropping of private images. Also on DNS side we can do cleanup. Other services are tricky (while swift we can still implement relatively easy). All in all - we can merge the PR in it’s current form (assuming we get some positive reviews). BG, Artem > On 19. Jan 2021, at 13:33, Christian Rohmann wrote: > > Hey Artem, > > thank you very much for your quick reply and pointer to the patchset you work on! > > > > On 18/01/2021 20:14, Artem Goncharov wrote: >> Ha, thats exactly the case, the whole logic sits in sdk and is spread across the supported services: >> - https://opendev.org/openstack/openstacksdk/src/branch/master/openstack/compute/v2/_proxy.py#L1798 - for compute. KeyPairs not dropped, since they belong to user, and not to the “project”; >> - https://opendev.org/openstack/openstacksdk/src/branch/master/openstack/block_storage/v3/_proxy.py#L547 - block storage; >> - https://opendev.org/openstack/openstacksdk/src/branch/master/openstack/orchestration/v1/_proxy.py#L490 >> - https://opendev.org/openstack/openstacksdk/src/branch/master/openstack/network/v2/_proxy.py#L4130 - the most complex one in order to give possibility to clean “old” resource without destroying everything else >> >> Adding image is few lines of code (never had enough time to add it), identity is a bit tricky, since also here mostly resources does not belong to Project. DNS would be also easy to do. OSC here is only providing I/F, while the logic sits in SDK and can be very easy extended for other services. > >>> On 18. Jan 2021, at 19:52, Thomas Goirand > wrote: >>> >>> On 1/18/21 6:56 PM, Artem Goncharov wrote: >>>> What do you mean it doesn’t implement anything at all? It does clean up compute, network, block_storage, orchestrate resources. Moreover it gives you possibility to clean “old” resources (created before or last updated before). >>> >>> Oh really? With that few lines of code? I'll re-read the patch then, >>> sorry for my bad assumptions. >>> >>> Can you point at the part that's actually deleting the resources? > If I understood correctly, the cleanup relies on the SDK functionality / requirement for each resource type to provide a corresponding function( https://github.com/openstack/openstacksdk/blob/master/openstack/cloud/openstackcloud.py#L762 ) ? > > Reading through the (SDK) code this even covers depending resources, nice! > > > > I certainly will leave some feedback and comments in your change (https://review.opendev.org/c/openstack/python-openstackclient/+/734485 ). > But what are your immediate plans moving forward on with this then, Artem? > > There is a little todo list in the description on your change .. is there anything you yourself know that is still missing before taking this to a full review and finally merging it? > > Only code that is shipped and then actively used will improve further and people will notice other required functionality or switches for later iterations. With the current state of having a somewhat working but unmaintained ospurge and a non feature complete "project purge" (supports only Block Storage v1, v2; Compute v2; Image v1, v2) this will only cause people to start hacking away on the ospurge codebase or worse building their own tools and scripts to implement project cleanup for their environments over and over again. > > > > > > Regards, > > > > Christian > -------------- next part -------------- An HTML attachment was scrubbed... URL: From fungi at yuggoth.org Tue Jan 19 15:17:22 2021 From: fungi at yuggoth.org (Jeremy Stanley) Date: Tue, 19 Jan 2021 15:17:22 +0000 Subject: [all][infra] CI test result table in the new gerrit review UI In-Reply-To: References: <20210119055830.GB3137911@fedora19.localdomain> Message-ID: <20210119151722.gguyp53vn7oa6vtc@yuggoth.org> On 2021-01-19 12:56:41 +0000 (+0000), Sean Mooney wrote: > On Tue, 2021-01-19 at 12:37 +0100, Dmitry Tantsur wrote: [...] > > I wonder if we could also run the plugin that shows the live > > progress (it was mentioned somewhere in the thread). > > i belive showing the live progress of the jobs is effectivly a > ddos vector. infra have ask that we not use javascript to pool the > the live status of the jobs in our browser in the past. [...] > i know that we previously tried enbeding the zuul job status > directly into gerrit a few years ago and that had to be qickly > reverted as it does not take many developers leave review open in > a tab to quickly make that unworkable. i know i for one often > leave review open over night if im pinged to review something > shortly before i finish for the day so that its open on my screen > when i log in the next day. [...] I think it's probably worth trying again. The previous attempts hit a wall because of several challenges: 1. The available Zuul status API returned data on all enqueued refs (a *very* large JSON blob when the system is under heavy use) 2. Calls to the API were handled by a thread of the scheduler daemon, so often blocked or were blocked by other things going on, especially when Zuul was already under significant load 3. Browsers at the time continued running Javascript payloads in "background" tabs so the volume of queries was multiplied not just by the number of users but also by the average number of review tabs they had open Over time we added a ref-scoped status method so callers could request the status of a specific change. The Zuul REST API is now served by a separate zuul-web daemon, which we can move to a different server entirely if load demands that (and can even scale horizontally with more than one instance of it, I think?). Browser tech has also improved, and popular ones these days suspend Javascript stacks when tabs are not exposed. We may also be caching status API responses more aggressively than we used to do. All of these factors combined could make live status info in a Gerrit plug-in entirely tractable, we'll just need someone with time to try it and see... and be prepared for multiple Gerrit service restarts to enable/disable it, so probably not when utilization is as high as it has been the past couple of weeks. -- Jeremy Stanley -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From fungi at yuggoth.org Tue Jan 19 15:32:02 2021 From: fungi at yuggoth.org (Jeremy Stanley) Date: Tue, 19 Jan 2021 15:32:02 +0000 Subject: [all][tc] Dropping lower-constraints testing from all projects In-Reply-To: References: <176d8da769b.b6edb13b874337.4809906168220534198@ghanshyammann.com> <3c223c99-929e-ab6d-2268-10d361f76349@debian.org> <17716bc8c42.12286180c5673.4264524174161781845@ghanshyammann.com> Message-ID: <20210119153202.l6jcm723qq5uq2zc@yuggoth.org> On 2021-01-19 08:03:25 +0100 (+0100), Thomas Goirand wrote: [...] > Of course, I'm using upper-constraints too, to try to package them > as much as possible, however, the dependencies are expressed > according to lower-constraints. [...] The same lower bounds would also typically be expressed in the requirements.txt file. Presumably you looked there before projects added lower-constraints.txt files? Noting that lower bounds testing isn't feasible and the jobs we were running weren't actually correctly testing minimum versions of everything, these have always been a "best effort" assertion anyway. I gather you run Tempest tests against your OpenStack packages on Debian already, so if a dependency there is too low you'll find out and can let the project maintainers know that their minimum version for that in requirements.txt isn't correct. Hopefully that doesn't come up very often, but for things we can't realistically test, getting notified by downstream distributors and users is the best feedback mechanism we can hope for. -- Jeremy Stanley -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From juliaashleykreger at gmail.com Tue Jan 19 15:48:19 2021 From: juliaashleykreger at gmail.com (Julia Kreger) Date: Tue, 19 Jan 2021 07:48:19 -0800 Subject: Ironic Midcycle - Three time windows next week Message-ID: Greetings everyone, Given we have a global community, I think the statement "Scheduling is hard" is definitely one of those things that we've all had to learn over the years. Luckily we have some time slots where many of the participants have indicated they will be able to attend. From that, it appears that the following times seem in terms of trying to cover time zones as well as including participants that have expressed interest. Monday January 25th @ 5PM - 6PM UTC / 9AM - 10AM US Pacific Tuesday January 26th @ 8 PM - 9PM UTC / 12:00 PM - 1 PM Pacific Wednesday January 27th @ 3PM - 4PM UTC / 7AM - 8AM US Pacific We will meet in MeetPad[0], and the etherpad is still open if more topics wish to be added, although we cannot guarantee we will get to them. I've also tried to spread them up across days in order to try and make efficient use of the time. Thanks everyone, and see you there. -Julia [0]: https://meetpad.opendev.org/ironic [1]: https://etherpad.opendev.org/p/ironic-wallaby-midcycle From elod.illes at est.tech Tue Jan 19 16:20:47 2021 From: elod.illes at est.tech (=?UTF-8?B?RWzFkWQgSWxsw6lz?=) Date: Tue, 19 Jan 2021 17:20:47 +0100 Subject: [TripleO] moving stable/rocky for tripleo repos to unmaintained (+ then EOL) OK? In-Reply-To: References: Message-ID: <9d339305-e637-b27a-2b68-7ec3eb4b6555@est.tech> Hi, just to add some clarification: - 'Unmaintained' is rather a state, where a stable/branch is not maintained (meaning, no one pushes CI fixes, bugfix backports), you don't need to transition to 'unmaintained' - a team can decide whether they want to wait for the 6 months to move the branch to EOL, or (if no one steps up as maintainer) start the EOL process [1] after the warning is sent to the mailing list - the '-last' tag is really created to support tempest's special case, so in TripleO's case EOL is the right choice I hope this helps. And sorry for the late response. Thanks, Előd [1] https://docs.openstack.org/project-team-guide/stable-branches.html#end-of-life On 2021. 01. 18. 11:44, Herve Beraud wrote: > Hello > > Le lun. 18 janv. 2021 à 10:22, Marios Andreou > a écrit : > > > > On Fri, Jan 15, 2021 at 7:01 PM Herve Beraud > wrote: > > Hello, > > Sorry for my late reply, and thanks for the heads up. > > Can't we move directly to EOL [1]? > I don't see reason to keep an unmaintained repo open, and if > the repos remain open and patches merged then it's not really > unmaintained repos. > > The goal of the extended maintenance was to offer more chances > to downstream maintainers to get/share patches and fixes, if > you decide to not maintain them anymore then I would suggest > you to move to "EOL" directly, it would be less misleading. > > Notice that if you move rocky to eol all the corresponding > branches will be dropped in your repos. > > Also notice that last week we proposed a new kind of tag > (-last) [2][3] for Tempest's needs, but because > tempest is branchless... > > Maybe we could extend this notion (-last) to allow the project > to reflect the last step... > It could reflect that it will be your last release, and that > the project is near from the end. > > But if you don't plan to merge patches, or if you don't have > patches to merge anymore, then I would really suggest to you > to move directly to EOL, else it means that you're not really > "unmaintained". > > > OK thanks very much Herve as always for your time and thoughts > here. I am not against the EOL I just thought it was more of a > requirement to declare it 'unmaintained' first. The advantage is > it is a softer path to completely closing it off for any future > submissions. Possibly the '-last' tag fits this need but if I have > understood correctly it might need some adjustment to the > definition of that tag ('we could extend this notion') and > honestly I don't know if it is necessary. More likely straight to > EOL is what we want here. > > > You're welcome, Do not hesitate to ping us. > Concerning the "-last", I said that we surely need to extend this kind > of tag because it is referenced for tempest's usages. > I think EOL fits our needs and is the shortest path. > > > I will bring this up again in tomorrow's tripleo irc meeting > http://lists.openstack.org/pipermail/openstack-discuss/2021-January/019859.html > and point to this thread. Let's see what other opinions there are > around EOL vs -last for stable/rocky > > Same thing on my side, I added this topic to our next relmgt irc > meeting (thursday) to see opinions of the team. > > > thank you, marios > > > Thank you > > > > Hopefully it will help you to find the solution that fits your > needs. > > Let me know if you have more questions. > > [1] > https://governance.openstack.org/tc/resolutions/20180301-stable-branch-eol.html#end-of-life > [2] https://review.opendev.org/c/openstack/releases/+/770265 > [3] > https://review.opendev.org/c/openstack/project-team-guide/+/769821 > > Le ven. 15 janv. 2021 à 16:52, Marios Andreou > > a écrit : > > > On Thu, Dec 10, 2020 at 7:01 PM Marios Andreou > > wrote: > > Hello TripleO > > > I would like to propose that we move all tripleo > stable/rocky repos [1] to "unmaintained", with a view > to tagging as end-of-life in due course. > > > This will allow us to focus our efforts on keeping the > check and gate queues green and continue to deliver > weekly promotions for the more recent and active > stable/* branches train ussuri victoria and master. > > > The stable/rocky repos have not had much action in the > last few months - I collected some info at [2] about > the most recent stable/rocky commits for each of the > tripleo repos. For many of those there are no commits > in the last 6 months and for some even longer. > > > The tripleo stable/rocky repos were tagged as > "extended maintenance" (rocky-em) [2] in April 2020 > with [3]. > > > We have already reduced our CI commitment for rocky - > these [4] are the current check/gate jobs and these > [5] are the jobs that run for promotion to > current-tripleo. However maintaining this doesn’t make > sense if we are not even using it e.g. merging things > into tripleo-* stable/rocky. > > > Please raise your objections or any other comments or > thoughts about this. Unless there are any blockers > raised here, the plan is to put this into motion early > in January. > > > One still unanswered question I have is that since > there is no ‘unmaintained’ tag, in the same way as we > have the -em or for extended > maintenance and end-of-life, do we simply _declare_ > that the repos are unmaintained? Then after a period > of “0 to 6 months” per [6] we can tag the tripleo > repos with rocky-eol. If any one reading this knows > please tell us! > > > > o/ hello ! > > replying to bump the thread - this was sent ~1 month ago > now and there hasn't been any comment thus far. > > ping @Herve please do you know the answer to that question > in the last paragraph above about 'declaring unmaintained' > ? please thank you ;) > > As discussed at the last tripleo bi-weekly we can consider > moving forward with this so I think it's prudent to give > folks more chance to comment if they object for _reason_ > > thanks, marios > > > > > Thanks for reading! > > regards, marios > > > > [1] > https://releases.openstack.org/teams/tripleo.html#rocky > > [2] http://paste.openstack.org/raw/800464/ > > [3] > https://review.opendev.org/c/openstack/releases/+/709912 > > [4] > http://dashboard-ci.tripleo.org/d/3-DYSmOGk/jobs-exploration?orgId=1&var-influxdb_filter=branch%7C%3D%7Cstable%2Frocky > > [5] > http://dashboard-ci.tripleo.org/d/3-DYSmOGk/jobs-exploration?orgId=1&fullscreen&panelId=9&var-influxdb_filter=type%7C%3D%7Crdo&var-influxdb_filter=job_name%7C%3D~%7C%2Fperiodic.*-rocky%2F > > [6] > https://docs.openstack.org/project-team-guide/stable-branches.html#maintenance-phases > > > > -- > Hervé Beraud > Senior Software Engineer at Red Hat > irc: hberaud > https://github.com/4383/ > https://twitter.com/4383hberaud > -----BEGIN PGP SIGNATURE----- > > wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ > Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ > RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP > F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G > 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g > glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw > m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ > hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 > qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y > F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 > B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O > v6rDpkeNksZ9fFSyoY2o > =ECSj > -----END PGP SIGNATURE----- > > > > -- > Hervé Beraud > Senior Software Engineer at Red Hat > irc: hberaud > https://github.com/4383/ > https://twitter.com/4383hberaud > -----BEGIN PGP SIGNATURE----- > > wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ > Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ > RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP > F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G > 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g > glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw > m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ > hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 > qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y > F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 > B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O > v6rDpkeNksZ9fFSyoY2o > =ECSj > -----END PGP SIGNATURE----- > -------------- next part -------------- An HTML attachment was scrubbed... URL: From marios at redhat.com Tue Jan 19 16:34:20 2021 From: marios at redhat.com (Marios Andreou) Date: Tue, 19 Jan 2021 18:34:20 +0200 Subject: [qa][release][tripleo] Abandoning openstack-tempest-skiplist? In-Reply-To: <177068a105d.aea199651318020.1189554580760474526@ghanshyammann.com> References: <177068a105d.aea199651318020.1189554580760474526@ghanshyammann.com> Message-ID: On Fri, Jan 15, 2021 at 4:56 PM Ghanshyam Mann wrote: > ---- On Fri, 15 Jan 2021 03:07:12 -0600 Herve Beraud > wrote ---- > > Dear QA team, > > The release team noticed an inconsistency between the QA team's > deliverables described in the governance’s reference and deliverables > defined in the openstack/releases repo (c.f our related meeting topic [1]). > > Indeed, openstack-tempest-skiplist (added Mar 20, 2020) was never > released yet, was not ready yet for ussuri and victoria. maybe we should > abandon this instead of waiting? > > Notice that Wallaby's milestone 2 is next week so maybe it could be a > good time to update this. > > Let us know your thoughts, we are waiting for your replies. > > Thanks for reading, > > Thanks hberaud for brining it, > > I did not know about this repo until it was discussed in yesterday's > release meeting. > > As per the governance project.yaml 'openstack-tempest-skiplist' is under > the TripleO project, not QA [1] (tagging tripleo in sub). > > This repo is to maintain the test skiplist so not sure if it needed > release but marios or Chandan can decide. > > [1] > https://github.com/openstack/governance/blob/2bdd9cff00fb40b2f95b66cad47ae1cfd14a2f1b/reference/projects.yaml#L3069 > > -gmann > Thank you Herve and Ghanshyam (and thanks Chandan for pointing me to this thread!) apologies for the late response but I initially missed this. I just discussed a bit with Arx (adding him into cc) - he agrees this isn't something we will want or need to make releases for. It is used by CI tooling and not to do with TripleO deploying OpenStack. The repo itself is branchless so if we *want* to make releases for it then we can consider adding a release file under deliverables/_independent in the releases repo. However since we don't then I think we should just mark it so in governance? I posted that just now there https://review.opendev.org/c/openstack/governance/+/771488 @Herve is that correct? regards, marios > > > [1] > http://eavesdrop.openstack.org/irclogs/%23openstack-release/%23openstack-release.2021-01-14.log.html#t2021-01-14T17:05:23 > > -- > > Hervé BeraudSenior Software Engineer at Red Hatirc: hberaudhttps:// > github.com/4383/https://twitter.com/4383hberaud > > -----BEGIN PGP SIGNATURE----- > > > > wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ > > Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ > > RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP > > F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G > > 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g > > glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw > > m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ > > hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 > > qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y > > F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 > > B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O > > v6rDpkeNksZ9fFSyoY2o > > =ECSj > > -----END PGP SIGNATURE----- > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From noonedeadpunk at ya.ru Tue Jan 19 17:02:44 2021 From: noonedeadpunk at ya.ru (Dmitriy Rabotyagov) Date: Tue, 19 Jan 2021 19:02:44 +0200 Subject: [all][tc][goals] Migrate RBAC Policy Format from JSON to YAML: Week R-16 Update In-Reply-To: <176afca89ab.1012b6043628566.4875338583213848682@ghanshyammann.com> References: <1769c0ad573.cf348131542704.5195004248291055264@ghanshyammann.com> <884141609228423@mail.yandex.ru> <176afca89ab.1012b6043628566.4875338583213848682@ghanshyammann.com> Message-ID: <6138511611075251@mail.yandex.ru> An HTML attachment was scrubbed... URL: From noonedeadpunk at ya.ru Tue Jan 19 17:54:08 2021 From: noonedeadpunk at ya.ru (Dmitriy Rabotyagov) Date: Tue, 19 Jan 2021 19:54:08 +0200 Subject: [all][tc][goals] Migrate RBAC Policy Format from JSON to YAML: Week R-16 Update In-Reply-To: <6138511611075251@mail.yandex.ru> References: <1769c0ad573.cf348131542704.5195004248291055264@ghanshyammann.com> <884141609228423@mail.yandex.ru> <176afca89ab.1012b6043628566.4875338583213848682@ghanshyammann.com> <6138511611075251@mail.yandex.ru> Message-ID: <1671511611078715@mail.yandex.ru> An HTML attachment was scrubbed... URL: From gmann at ghanshyammann.com Tue Jan 19 18:16:14 2021 From: gmann at ghanshyammann.com (Ghanshyam Mann) Date: Tue, 19 Jan 2021 12:16:14 -0600 Subject: [all][tc] Dropping lower-constraints testing from all projects In-Reply-To: <20210119153202.l6jcm723qq5uq2zc@yuggoth.org> References: <176d8da769b.b6edb13b874337.4809906168220534198@ghanshyammann.com> <3c223c99-929e-ab6d-2268-10d361f76349@debian.org> <17716bc8c42.12286180c5673.4264524174161781845@ghanshyammann.com> <20210119153202.l6jcm723qq5uq2zc@yuggoth.org> Message-ID: <1771bdc8d1e.d3cb624075720.6344507521187621605@ghanshyammann.com> ---- On Tue, 19 Jan 2021 09:32:02 -0600 Jeremy Stanley wrote ---- > On 2021-01-19 08:03:25 +0100 (+0100), Thomas Goirand wrote: > [...] > > Of course, I'm using upper-constraints too, to try to package them > > as much as possible, however, the dependencies are expressed > > according to lower-constraints. > [...] > > The same lower bounds would also typically be expressed in the > requirements.txt file. Presumably you looked there before projects > added lower-constraints.txt files? Noting that lower bounds testing > isn't feasible and the jobs we were running weren't actually > correctly testing minimum versions of everything, these have always > been a "best effort" assertion anyway. > > I gather you run Tempest tests against your OpenStack packages on > Debian already, so if a dependency there is too low you'll find out > and can let the project maintainers know that their minimum version > for that in requirements.txt isn't correct. Hopefully that doesn't > come up very often, but for things we can't realistically test, > getting notified by downstream distributors and users is the best > feedback mechanism we can hope for. Yeah, in requirments.txt we always have a lower bound of deps and we do not update it or sync it with u-c. Yes, we will not be testing those as such but as Jeremy mentioned if there is some wrong lower bound then we can fix it quickly. Usually, on every new feature or interface deps, we do bump that lower bound in requirements.txt. We usually check if anything new we are using that is being updated in this file or not -gmann > -- > Jeremy Stanley > From gmann at ghanshyammann.com Tue Jan 19 18:39:39 2021 From: gmann at ghanshyammann.com (Ghanshyam Mann) Date: Tue, 19 Jan 2021 12:39:39 -0600 Subject: [all][tc][goals] Migrate RBAC Policy Format from JSON to YAML: Week R-16 Update In-Reply-To: <6138511611075251@mail.yandex.ru> References: <1769c0ad573.cf348131542704.5195004248291055264@ghanshyammann.com> <884141609228423@mail.yandex.ru> <176afca89ab.1012b6043628566.4875338583213848682@ghanshyammann.com> <6138511611075251@mail.yandex.ru> Message-ID: <1771bf1fc95.eb108f1f76821.5001860786267000124@ghanshyammann.com> ---- On Tue, 19 Jan 2021 11:02:44 -0600 Dmitriy Rabotyagov wrote ---- > Hi! I have some follow up questions. On oslo.policy side it looks like it's better to explicitly set policy.yaml path > in config and not rely if services have already moved to using yaml files. Or in case policy.json does not exist, oslo > will try to load yaml instead? This was first thought but we can not do that as this will break the existing deployment relying on policy.json. That is why we need to wait for all services to do 1. change the default value of CONF.policy_file to policy.yaml 2. officially deprecate the JSON format policy file support. And once that is done in all openstack services and the operator has moved to policy.yaml then we can change it in oslo.policy safely. Overall what we are trying to achieve is "Convey the JSON->YAML policy file migration properly to the operator and then switch the flag" so that we do not introduce any breaking change and migrate it smoothly. >Another question is more general one and very basic :( I have a feeling that policies are applied without >related service reload which means that they're loaded from disk for each incoming request? Is that >assumption right? I'm just thinking about the best way to do upgrade and at what point we should be >dropping old policy.json and if we can do this before placing policy.yaml or not. My plan is 1. finish the service side deprecation and default file change in Wallaby 2. give Xena cycle as a buffer for the operator to notice these changes 3. In the Y cycle, we remove the JSON format and file support completly. -gmann 29.12.2020, 20:37, "Ghanshyam Mann" : ---- On Tue, 29 Dec 2020 01:56:22 -0600 Dmitriy Rabotyagov wrote ---- > > Hi! Regarding OpenStack-Ansible I was planning to land patches early January. We eventually need to patch every role to change "dest" and "config_type" for placing template, ie. [1] Also we will need to think through removal of old json file for ppl that will perform upgrade, to avoid any possible conflicts and confusions because of the prescence of both files. [1] https://opendev.org/openstack/openstack-ansible-os_glance/src/branch/master/tasks/glance_post_install.yml#L78-L82 > > Thanks, Dmitriy, do let me know if you need help this is a large number of changes. I will be able to push changes for this. > > On point of the presence of both files, yes this is a good point. From the service side default value change, I am taking care of > this on oslo.policy side[1]. If both files exist and deployment rely on the default value (config option is not overridden ) then > oslo policy will pick up the 'policy.json'. With this, we make sure we do not break any upgrade for deployment relying on this > default value. In the future, when we decide to remove the support of policy.json then we can remove this fallback logic. > > -gmann > > [1] https://github.com/openstack/oslo.policy/blob/0a228dea2ee96ec3eabed3361ca22502d0bbd4a1/oslo_policy/policy.py#L363 > > > > 26.12.2020, 00:41, "Ghanshyam Mann" :Hello Everyone, > > > > Please find the week's R-16 updates on 'Migrate RBAC Policy Format from JSON to YAML' community-wide goals. > > > > Tracking: https://etherpad.opendev.org/p/migrate-policy-format-from-json-to-yaml > > > > Gerrit Topic: https://review.opendev.org/q/topic:%22policy-json-to-yaml%22+(status:open%20OR%20status:merged) > > > > Progress: > > ======= > > * Projects completed: 5 > > * Projects left to merge the patches: 25 > > * Projects left to push the patches: 2 (horizon and Openstackansible) > > * Projects do not need any work: 17 > > > > Updates: > > ======= > > * I have pushed the patches for all the required service projects. > > > > ** Because of many services gate is already broken for lower constraints job, these patches might not be green in the > > test results. I request projects to fix the gate so that we can merge this goal work before m-2. > > > > ** There are many project tests where CONF object was not fully initialized before the policy is init. This was working till now > > as policy init did not use the CONF object but oslo_policy 3.6.0 onwards it needs fully initialized CONF object during init only. > > > > ** Aodh work for this goal is blocked because it needs oslo_policy 3.6.0 but gnocchi is capped for oslo_policy 3.4.0 [1] > > - https://review.opendev.org/c/openstack/aodh/+/768499 > > > > * Horizon and Openstackansible work is pending to use/deploy the YAML formatted policy file. I will start exploring this > > next week or so. > > > > [1] https://github.com/gnocchixyz/gnocchi/blob/e19fda590c7f7f07f1df0ba93177df07d9802300/setup.cfg#L33 > > > > Merry Christmas and Happy Holidays! > > > > -gmann > > > > -- > > Kind Regards,Dmitriy Rabotyagov > -- > Kind Regards,Dmitriy Rabotyagov From gmann at ghanshyammann.com Tue Jan 19 18:44:21 2021 From: gmann at ghanshyammann.com (Ghanshyam Mann) Date: Tue, 19 Jan 2021 12:44:21 -0600 Subject: [qa][release][tripleo] Abandoning openstack-tempest-skiplist? In-Reply-To: References: <177068a105d.aea199651318020.1189554580760474526@ghanshyammann.com> Message-ID: <1771bf6499a.e47b8f1076996.4876840442407425263@ghanshyammann.com> ---- On Tue, 19 Jan 2021 10:34:20 -0600 Marios Andreou wrote ---- > > > On Fri, Jan 15, 2021 at 4:56 PM Ghanshyam Mann wrote: > ---- On Fri, 15 Jan 2021 03:07:12 -0600 Herve Beraud wrote ---- > > Dear QA team, > > The release team noticed an inconsistency between the QA team's deliverables described in the governance’s reference and deliverables defined in the openstack/releases repo (c.f our related meeting topic [1]). > > Indeed, openstack-tempest-skiplist (added Mar 20, 2020) was never released yet, was not ready yet for ussuri and victoria. maybe we should abandon this instead of waiting? > > Notice that Wallaby's milestone 2 is next week so maybe it could be a good time to update this. > > Let us know your thoughts, we are waiting for your replies. > > Thanks for reading, > > Thanks hberaud for brining it, > > I did not know about this repo until it was discussed in yesterday's release meeting. > > As per the governance project.yaml 'openstack-tempest-skiplist' is under the TripleO project, not QA [1] (tagging tripleo in sub). > > This repo is to maintain the test skiplist so not sure if it needed release but marios or Chandan can decide. > > [1] https://github.com/openstack/governance/blob/2bdd9cff00fb40b2f95b66cad47ae1cfd14a2f1b/reference/projects.yaml#L3069 > > -gmann > > > Thank you Herve and Ghanshyam (and thanks Chandan for pointing me to this thread!) > apologies for the late response but I initially missed this. > I just discussed a bit with Arx (adding him into cc) - he agrees this isn't something we will want or need to make releases for. It is used by CI tooling and not to do with TripleO deploying OpenStack. > The repo itself is branchless so if we *want* to make releases for it then we can consider adding a release file under deliverables/_independent in the releases repo. > However since we don't then I think we should just mark it so in governance? I posted that just now there https://review.opendev.org/c/openstack/governance/+/771488 at Herve is that correct? Thanks, marios for your response and updates. I also agree that this skip list repo does not need release as such. -gmann > > regards, marios > > > > [1] http://eavesdrop.openstack.org/irclogs/%23openstack-release/%23openstack-release.2021-01-14.log.html#t2021-01-14T17:05:23 > > -- > > Hervé BeraudSenior Software Engineer at Red Hatirc: hberaudhttps://github.com/4383/https://twitter.com/4383hberaud > > -----BEGIN PGP SIGNATURE----- > > > > wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ > > Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ > > RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP > > F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G > > 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g > > glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw > > m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ > > hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 > > qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y > > F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 > > B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O > > v6rDpkeNksZ9fFSyoY2o > > =ECSj > > -----END PGP SIGNATURE----- > > > > > > From openstack at nemebean.com Tue Jan 19 20:04:07 2021 From: openstack at nemebean.com (Ben Nemec) Date: Tue, 19 Jan 2021 14:04:07 -0600 Subject: [all][tc][goals] Migrate RBAC Policy Format from JSON to YAML: Week R-16 Update In-Reply-To: <1771bf1fc95.eb108f1f76821.5001860786267000124@ghanshyammann.com> References: <1769c0ad573.cf348131542704.5195004248291055264@ghanshyammann.com> <884141609228423@mail.yandex.ru> <176afca89ab.1012b6043628566.4875338583213848682@ghanshyammann.com> <6138511611075251@mail.yandex.ru> <1771bf1fc95.eb108f1f76821.5001860786267000124@ghanshyammann.com> Message-ID: <1df1b294-fd76-c598-1b57-6b298675123a@nemebean.com> On 1/19/21 12:39 PM, Ghanshyam Mann wrote: > ---- On Tue, 19 Jan 2021 11:02:44 -0600 Dmitriy Rabotyagov wrote ---- > > Hi! I have some follow up questions. On oslo.policy side it looks like it's better to explicitly set policy.yaml path >> in config and not rely if services have already moved to using yaml files. Or in case policy.json does not exist, oslo >> will try to load yaml instead? > > This was first thought but we can not do that as this will break the existing deployment relying on policy.json. > That is why we need to wait for all services to do 1. change the default value of CONF.policy_file to policy.yaml > 2. officially deprecate the JSON format policy file support. And once that is done in all openstack services and > the operator has moved to policy.yaml then we can change it in oslo.policy safely. Overall what we are trying to > achieve is "Convey the JSON->YAML policy file migration properly to the operator and then switch the flag" so > that we do not introduce any breaking change and migrate it smoothly. There was also a security concern with potentially having multiple policy files and it not being clear which was in use. If someone converted their JSON policy to YAML, but left the JSON one in place, it could result in oslo.policy using the wrong one (or not the one they expect). We decided it was better for each project to make a clean switchover, which allows for things like upgrade checks that oslo.policy couldn't have itself, than to try to handle it all in oslo.policy. From aditi.Dukle at ibm.com Tue Jan 19 11:36:20 2021 From: aditi.Dukle at ibm.com (aditi Dukle) Date: Tue, 19 Jan 2021 11:36:20 +0000 Subject: [nova] unit testing on ppc64le In-Reply-To: References: , , <5E9MMQ.3INH7FY465VR3@est.tech> Message-ID: An HTML attachment was scrubbed... URL: From ankelezhang at gmail.com Tue Jan 19 12:37:53 2021 From: ankelezhang at gmail.com (Ankele zhang) Date: Tue, 19 Jan 2021 20:37:53 +0800 Subject: docs about ironic-inspector Message-ID: Hi, I have an rocky OpenStack platform, and I need openstack-ironic-inspector to inspect my baremetal node, but the documentation on the websit https://docs.openstack.org/ironic/rocky/admin/inspection.html is too concise, without a detailed configuration process. I need a link to documentation for detailed ironic-inspector configuration and usage. Looking forward to your help. Ankele -------------- next part -------------- An HTML attachment was scrubbed... URL: From narjes.bessghaier.1 at ens.etsmtl.ca Tue Jan 19 21:29:32 2021 From: narjes.bessghaier.1 at ens.etsmtl.ca (Bessghaier, Narjes) Date: Tue, 19 Jan 2021 21:29:32 +0000 Subject: Requesting help with OpenStack configuration files Message-ID: Dear OpenStack team, I’m a Ph.D. student in software engineering at the ETS Montreal, University of Quebec working on the quality and configuration of web-based software systems. I’m particularly interested in analyzing configuration files from different OpenStack files. One of the main challenges I am currently facing is the proper identification of configuration files. I’m mostly confused between the python files used for production and the python files used for configuration. I am kindly requesting your precious help with the following questions: 1- How to distinguish between python files used for configuration and python files used for production? It will be very helpful if there are some configuration-based patterns (eg, textual patterns or expressions) that we can find in python files to help us distinguish between source code and configuration files? 2- Certain python files use the oslo_config to access and define configuration options. Could "all" these python files be considered as configuration files? For example, the following python file of the keystone project: keystone/keystone/conf/auth.py, is it considered a source code or configuration file? 3- Why are there different source code and configuration repositories for OpenStack projects (eg, nova and puppet-nova)? For instance, does the OpenStack-nova service have some configuration files in its repository and have the puppet-nova as a separate configuration repository as well? Thank you very much in advance for your time and your help! Kind regards, Narjes Bessghaier Narjes Bessghaier Ph.D student in Software Engineering École de Technologie Supérieure (ETS)| University of Quebec Montreal, Canada narjes.bessghaier.1 at ens.etsmtl.ca -------------- next part -------------- An HTML attachment was scrubbed... URL: From lbragstad at gmail.com Tue Jan 19 22:28:03 2021 From: lbragstad at gmail.com (Lance Bragstad) Date: Tue, 19 Jan 2021 16:28:03 -0600 Subject: Secure RBAC work In-Reply-To: <1764f5dc30b.ce68476360070.2800550259733297462@ghanshyammann.com> References: <1764f5dc30b.ce68476360070.2800550259733297462@ghanshyammann.com> Message-ID: Hey all, I want to follow up on this thread because there's been some discussion and questions (some of which are in reviews) as services work through the proposed changes [0]. TL;DR - OpenStack services implementing secure RBAC should update default policies with the `reader` role in a consistent manner, where it is not meant to protect sensitive information. In the process of reviewing changes for various resources, some folks raised concerns about the `reader` role definition. One of the intended use-cases for implementing a `reader` role was to use it for auditing, as noted in the keystone definitions for each role and persona [1]. Another key point of that document, and the underlying design of secure RBAC, is that the default roles have role implications built between them (e.g., reader implies member, and member implies admin). This detail serves two important functions. First, it reduces duplication in check strings because keystone expands role implications in token response bodies. For example, someone with the `admin` role on a project will have `member` and `reader` roles in their token body when they authenticate for a token or validate a token. This reduces the complexity of our check strings by writing the policy to the highest level of authorization required to access an API or resource. Users with anything above that level will work through the role implications feature. Second, it reduces the need for extra role assignments. If you grant someone the `admin` role on a project you don't need to also give them `reader` and `member` role assignments. This is true regardless of how services implement check strings. Ultimately, the hierarchical role structure in keystone and role expansion in token responses give us shorter check strings and less role assignments. But, one thing we're aware of now is that we need to be careful how we expose certain information to users via the `reader` role, since it is the least-privileged role in the hierarchy. For example, one concern was exposing license key information in images to anyone with the `reader` role on the system. Some deployments, depending on their security posture or auditing targets, might not allow sensitive information to be implicitly exposed. Instead, they may require deployments to explicitly grant access to sensitive information [2]. So what do we do moving forward? I think it's clear that there are APIs and resources in OpenStack that fall into a special category where we shouldn't expose certain information to the lowest level of the role hierarchy, regardless of the scope. But, the role implication functionality served a purpose initially to deliver a least-privileged role used only for read operations within a given scope. I think breaking that implication now is confusing considering we implemented the implication in Rocky [3], but I think future work for an elevated read-only role is a good path forward. Eventually, keystone can consider implementing support for a new default role, which implies `reader`, making all the work we do today still useful. At that time, we can update relevant policies to expose sensitive information with the elevated read-only role. I suspect this will be a much smaller set of APIs and policies. I think this approach strikes a balance between what we have today, and a way to move forward that still protects sensitive data. I proposed an update to the documentation in keystone to clarify this point [4]. It also doesn't assume all audits are the same. Instead, it phrases the ability to use `reader` roles for auditing in a way that leaves that up to the deployer and auditor. I think that's an important detail since different deployments have different security requirements. Instead of assuming everyone can use `reader` for auditing, we can give them a list of APIs they can interact with as a `reader` (or have them generate those policies themselves, especially if they have custom policy) and let them determine if that access is sufficient for their audit. If it isn't, deployers aren't in a worse position today, but it emphasizes the importance of expanding the default roles to include another tier for elevated read-only permissions. Given where we are in the release cycle for Wallaby, I don't expect keystone to implement a new default role this late in the release [5]. Perhaps Xena is a better target, but I'll talk with Kristi about it next week during the keystone meeting. I hope this helps clarify some of the confusion around the secure RBAC patches. If you have additional comments or questions about this topic, let me know. We can obviously iterate here, or use the policy pop up time slot which is in a couple of days [6]. Thanks, Lance [0] https://review.opendev.org/q/topic:secure-rbac [1] https://docs.openstack.org/keystone/latest/admin/service-api-protection.html [2] FedRAMP control AC -06 (01) is an example of this - *The organization explicitly authorizes access to [Assignment: organization-defined security functions (deployed in hardware, software, and firmware) and security-relevant information].* [3] https://docs.openstack.org/releasenotes/keystone/rocky.html#new-features [4] https://review.opendev.org/c/openstack/keystone/+/771509 [5] https://releases.openstack.org/wallaby/schedule.html [6] https://etherpad.opendev.org/p/default-policy-meeting-agenda On Thu, Dec 10, 2020 at 7:15 PM Ghanshyam Mann wrote: > ---- On Wed, 09 Dec 2020 14:04:57 -0600 Lance Bragstad < > lbragstad at gmail.com> wrote ---- > > Hey everyone, > > > > I wanted to take an opportunity to clarify some work we have been doing > upstream, specifically modifying the default policies across projects. > > > > These changes are the next phase of an initiative that’s been underway > since Queens to fix some long-standing security concerns in OpenStack [0]. > For context, we have been gradually improving policy enforcement for years. > We started by improving policy formats, registering default policies into > code [1], providing better documentation for policy writers, implementing > necessary identity concepts in keystone [2], developing support for those > concepts in libraries [3][4][5][6][7][8], and consuming all of those > changes to provide secure default policies in a way operators can consume > and roll out to their users [9][10]. > > > > All of this work is in line with some high-level documentation we > started writing about three years ago [11][12][13]. > > > > There are a handful of services that have implemented the goals that > define secure RBAC by default, but a community-wide goal is still > out-of-reach. To help with that, the community formed a pop-up team with a > focused objective and disbanding criteria [14]. > > > > The work we currently have in progress [15] is an attempt to start > applying what we have learned from existing implementations to other > projects. The hope is that we can complete the work for even more projects > in Wallaby. Most deployers looking for this functionality won't be able to > use it effectively until all services in their deployment support it. > > Thanks, Lance for pushing this work forwards. I completely agree and that > is what we get feedback in > forum sessions also that we should implement this in all the services > first before we ask operators to > move their cloud to the new RBAC. > > We discussed these in today's policy-popup meeting also and encourage > every project to help in those > patches to add tests and review. This will help to finish the work on > priority and we can provide better > RBAC experience to the deployer. > > -gmann > > > > > > > I hope this helps clarify or explain the patches being proposed. > > > > > > As always, I'm happy to elaborate on specific concerns if folks have > them. > > > > > > Thanks, > > > > > > Lance > > > > > > [0] https://bugs.launchpad.net/keystone/+bug/968696/ > > [1] > https://governance.openstack.org/tc/goals/selected/queens/policy-in-code.html > > [2] > https://specs.openstack.org/openstack/keystone-specs/specs/keystone/queens/system-scope.html > > [3] https://review.opendev.org/c/openstack/keystoneauth/+/529665 > > [4] > https://review.opendev.org/c/openstack/python-keystoneclient/+/524415 > > [5] https://review.opendev.org/c/openstack/oslo.context/+/530509 > > [6] https://review.opendev.org/c/openstack/keystonemiddleware/+/564072 > > [7] https://review.opendev.org/c/openstack/oslo.policy/+/578995 > > [8] > https://review.opendev.org/q/topic:%22system-scope%22+(status:open%20OR%20status:merged) > > [9] > https://review.opendev.org/q/status:merged+topic:bp/policy-defaults-refresh+branch:master > > [10] > https://review.opendev.org/q/topic:%22implement-default-roles%22+(status:open%20OR%20status:merged) > > [11] > https://specs.openstack.org/openstack/keystone-specs/specs/keystone/ongoing/policy-goals-and-roadmap.html > > [12] > https://docs.openstack.