April 2022 - openstack-discuss - lists.openstack.org

Requests to solve Unhelpful error message when neutron server is unavailable
by ATIM IMMACULATE 07 Apr '22

07 Apr '22

I am Immaculate Atim, an outreachy applicant, interested to work on open stack project #1 Add missing CLI support for some Glance API in Openstack Client . I request to work on the issue of Unhelpful error message when neutron server is unavailable <https://bugs.launchpad.net/ubuntu/+source/python-openstackclient/+bug/16753…>. I would like to submit a patch for the stable/ocata branch that fixes this issue if it is decided that this is the right way to fix this issue. I commented to work on it but did not get any feedback so I would be glad to get feedback on this. Thank you.

2 2

Eventlet fails under Python 3.10
by Thomas Goirand 07 Apr '22

07 Apr '22

Hi, This was sent to the Debian BTS: https://bugs.debian.org/1009112 This issue was reported upstream: https://github.com/eventlet/eventlet/issues/730 https://github.com/eventlet/eventlet/issues/739 For #730, I tried manually, indeed: # python3.9 tests/isolated/patcher_existing_locks_locked.py pass # python3.10 tests/isolated/patcher_existing_locks_locked.py Traceback (most recent call last): File "/root/eventlet/python-eventlet-0.30.2/tests/isolated/patcher_existing_locks_locked.py", line 19, in <module> lock.release() RuntimeError: cannot release un-acquired lock I don't understand what's going on. Can anyone help? Cheers, Thomas Goirand (zigo)

1 0

[kolla-ansible][Xena][Magnum] dns configured in template is not pushed into cluster instances
by wodel youchi 07 Apr '22

07 Apr '22

Hi, I deployed Xena using kolla-ansible. Then I deployed Magnum, then created a kubernetes template with --dns-nameserver ip_of_my_dns_server That dns server does not get pushed into the master instance, and I get : Apr 07 13:57:32 k8simplekubf34-bnczkwda7z5d-master-0 podman[2153]: Authorization failed: *Unable to establish connection to https://dash.cloud.example.local:5000/v3/auth/tokens <https://dash.cloud.example.local:5000/v3/auth/tokens>* Apr 07 13:57:32 k8simplekubf34-bnczkwda7z5d-master-0 podman[2153]: Source [heat] Unavailable. Apr 07 13:57:32 k8simplekubf34-bnczkwda7z5d-master-0 podman[2153]: /var/lib/os-collect-config/local-data not found. Skipping In the master's /etc/resolv.conf I have google's dns 8.8.8.8 I am using fedora-core 34 for my cluster. Regards.

1 0

Re: [neutron] exposing ip address of external Network from
by A Monster 07 Apr '22

07 Apr '22

I tried attaching that public interface directly to the instance, and use that same ip address to configure the port manually inside the instance, but it doesn't work.

2 1

[neutron] PTG - Thursday
by Lajos Katona 07 Apr '22

07 Apr '22

Hi, As we have no topics we have no meeting today. We have the Nova-Neutron cross project meeting on Friday 14:00 UTC: https://etherpad.opendev.org/p/neutron-zed-ptg#L308 Cheers Lajos Katona (lajoskatona)

1 0

[tc][tacker][heat-translator] Discusssion about heat-translater maintenance
by ueha.ayumu＠fujitsu.com 07 Apr '22

07 Apr '22

Hi Bob, I’m Ayumu Ueha, I work as a core of Tacker. Previously, some member of Tacker team participated to the core of heat-translator. Since LiangLu has left the Tacker project, I would like to participate the core of heat-translator from the Tacker team instead of him and maintain it. Is it OK? This is agreed within the Tacker team at the Zed vPTG. >heat-translator >- yoshito-ito (yoshito.itou.dr(a)hco.ntt.co.jp<mailto:yoshito.itou.dr@hco.ntt.co.jp>) >- LiangLu (lu.liang(a)jp.fujitsu.com<mailto:lu.liang@jp.fujitsu.com>) *** change to ueha (ueha.ayumu(a)fujitsu.com<mailto:ueha.ayumu@fujitsu.com>) *** Best regards, Ueha

4 4

[neutron] exposing ip address of external Network from within the virtual machine
by A Monster 07 Apr '22

07 Apr '22

I have two networks, one internal to openstack " internal_network" 10.10.10.0/24 and an external Network "public" which is connected to an external network 192.168.100.0/24 in order to connect instances to "public" network, I created a router of which the gateway is public network, and also connected to internal_network, and used floating ip to access vm instances from the external network (public), but the problem I have encountered now is that I want to expose the and Ip from the external network inside the vm instance , but when I try to directly attach an interface from the external network to the instance, I don't get and Ip address inside the instance, and even if I assign it manually it still doesn't work, I can't use enable DHCP with public network because it already has its own external dhcp server. How can I solve this problem?

2 1

Wireguard setup between a server and a aio
by Adivya Singh 07 Apr '22

07 Apr '22

Hi Team, i m trying to set a wireguard setup between a web server and a AIO server with a public IP I have created a tunnel interface between 2 servers with Endpoint as AIP public IP range, but still I am unable to reach the Public IP of AIO. Note : Please note that IT has not allowed public IP range for AIO Regards Adivya Singh

2 1

[TripleO] Gate blockers - C8 Wallaby & C9 Master|Wallaby
by Dariusz Smigiel 06 Apr '22

06 Apr '22

Hey! TripleO team noticed two separate issues which hit gates about 5h ago: * C8 Wallaby https://bugs.launchpad.net/tripleo/+bug/1967943 * C9 Master|Wallaby: https://bugs.launchpad.net/tripleo/+bug/1967945 Please withhold rechecking until further notice. Thanks, Dariusz

2 3

plain text config parameters encryption feature
by Alexander Yeremko 06 Apr '22

06 Apr '22

Dear OpenStack community, we are developing plain text config secrets encryption feature according to the next specification: https://specs.openstack.org/openstack/openstack-ansible-specs/specs/xena/pr… We started from Glance OS service and submitted two patchsets already: https://review.opendev.org/c/openstack/openstack-ansible-os_glance/+/814865 Now we have two questions that we need to clarify to proceed our work on that feature and finish our development: 1. Is it correct that we need to develop more patchsets to rework some logic of encryption mechanism according to comment to 'files/encypt_secrets.py' script that arised at the second patchset (PatchSet 2) dated Nov/30/2021 ? Comment is by Dmitry Rabotyagov: "We _really_ should make it as an ansible plugin and re-work logic" 2. We wish to have such feature in previous releases also, not just in upcoming Yoga or Zed. Stein, Train and Victoria - it would be excellent to have plain text secrets encryption with these releases also. So question is how is it possible to use our feature in those releases also? Can we push some backports to those releases openstack-ansible repo? Could someone be so kind and give us answers? Best regards and wishes, Alex Yeremko This E-Mail (including any attachments) may contain privileged or confidential information. It is intended only for the addressee(s) indicated above. The sender does not waive any of its rights, privileges or other protections respecting this information. Any distribution, copying or other use of this E-Mail or the information it contains, by other than an intended recipient, is not sanctioned and is prohibited. If you received this E-Mail in error, please delete it and advise the sender (by return E-Mail or otherwise) immediately. Any calls held by you with Connectria may be recorded by an automated note taking system to ensure prompt follow up and for information collection purposes, and your attendance on any calls with Connectria confirms your consent to this. Any E-mail received by or sent from Connectria is subject to review by Connectria supervisory personnel.

4 6

[swift][ptg] Ops feedback session - Apr 7 at 13:00 UTC
by Timothy Burke 06 Apr '22

06 Apr '22

As in PTGs past, we're getting devs and ops together to talk about Swift: what's working, what isn't, and what would be most helpful to improve. We're meeting in Havana (https://www.openstack.org/ptg/rooms/havana) on Apr 7 at 13:00UTC -- if you run a Swift cluster, we hope to see you there! Even if you can't make it, I'd appreciate if you can offer some feedback on this PTG's etherpad (https://etherpad.opendev.org/p/swift-zed-ops-feedback) Tim

3 2

[ptg][ptl][largescale-sig][all] PTG session: "The Scaling Journey" - Wednesday, April 6 15utc - kilo room
by Belmiro Moreira 06 Apr '22

06 Apr '22

Hi, the Large Scale SIG is organizing a PTG session to discuss "The Scaling Journey". The SIG worked in a "scaling journey" to guide and help operators to scale their OpenStack deployments. Definitely, there are different ways to scale OpenStack! and the challenges to move from a few hundreds cores to thousands or now millions cores are completely different. Based on the experience of several operators, we tried to answer different common questions and identify the pain points. https://wiki.openstack.org/wiki/Large_Scale_SIG If you are interested in scalability it would be great to have your feedback. Also, it's important that PTLs join because they can give the project vision for scalability and advise on how to overcome possible bottlenecks. To discuss all of this we will have a "zoom" session on Wednesday, April 6 15utc - "kilo room". See you there! cheers, Belmiro on behalf of the Large Scale SIG

2 1

Upgrading Openstack nodes
by Marc-Antoine Godde 06 Apr '22

06 Apr '22

Hello, We are running an Openstack cloud composed of 3 controller nodes and 4 compute nodes. Our deployment was realized with OpenStack-ansible and we are running OpenStack Ussuri on Ubuntu 18.04. Our plan is to upgrade nodes to Ubuntu 20.04, that way we would be able to update to OpenStack Victoria and further. We would like to withdraw each node from the cluster, reinstall a clean linux and redeploy the nodes. There is garbage remaining from previous upgrades. We figured out the way in the documentation to remove a compute node from the cluster with Openstack-ansible but we can’t find any related documentation for controller nodes. Any help would be very much appreciated. By the way, if you’d have any other suggestions on how to perform that upgrade, fell free to help. Best, Marc-Antoine Godde

2 2

[dev][infra][qa][tact-sig] Zuul behavior change with Depends-On across queues
by Jeremy Stanley 06 Apr '22

06 Apr '22

For those who haven't seen the more detailed announcement[*] about it, just a quick note that if you get a sudden -2 back from Zuul when approving a change with a Depends-On to a change in a different project which hasn't merged yet, that's likely an indication those projects don't share a dependent queue. It's not a bug, but an intentional clarification of Zuul's enqueuing behavior. For most other Zuul deployments (and even our other Zuul tenants in OpenDev) this is purely cosmetic, but since OpenStack's Zuul tenant is configured to require a positive Verified vote before enqueuing into the gate pipeline, it means some changes may end up unexpectedly needing another pass through check first. It's worth re-evaluating whether or not this "clean check" rule remains a useful requirement for gating. It was added some years ago because a number of gate breaking bugs were traced back to unstable changes being rechecked enough times that eventually they got lucky and were able to merge, and then their instability contributed to destabilizing the integrated gate as a whole. Similarly, changes were being approved without reviewers confirming their jobs were passing first, and this led to additional resource waste. There is a bit of discussion around "blind rechecks" at the PTG this week, and so this topic is related; it might be a good idea to consider it in conjunction with the greater recheck conversation. [*] http://lists.opendev.org/pipermail/service-announce/2022-April/000033.html -- Jeremy Stanley

2 2

[openstack-ansible][PTG] Session on 6th of April is cancelled
by Dmitriy Rabotyagov 06 Apr '22

06 Apr '22

1 0

[Oslo] IRC meeting.
by Daniel Mats Niklas Bengtsson 06 Apr '22

06 Apr '22

Hi there, I would like to know if you agree that we have the meeting once a week? Instead of the first and third Monday of the month. It will be easier to manage and if sometimes it is canceled it does not matter Even if the meetings each week are short, this way we will have regular follow-up.

2 1

Metadata service {devices list}
by Ahmed Abdelhamid 06 Apr '22

06 Apr '22

Hi All, I am running into a strange issue with the metadata service. Per metadata-service manual <https://docs.openstack.org/nova/latest/user/metadata.html>, the devices attached to a VM should be visible in $ curl http://169.254.169.254/openstack/2018-08-27/meta_data.json However, whenever i execute it from a VM , the devices array is empty and looks like this, any idea why ? Thanks { "random_seed": "yu5ZnkqF2CqnDZVAfZgarG...", "availability_zone": "nova", "keys": [ { "data": "ssh-rsa AAAAB3NzaC1y...== Generated by Nova\n", "type": "ssh", "name": "mykey" } ], "hostname": "test.novalocal", "launch_index": 0, "meta": { "priority": "low", "role": "webserver" }, "devices": [ ], "project_id": "f7ac731cc11f40efbc03a9f9e1d1d21f", "public_keys": { "mykey": "ssh-rsa AAAAB3NzaC1y...== Generated by Nova\n" }, "name": "test"}

3 10

wireguard - ? - puzzle
by lejeczek 06 Apr '22

06 Apr '22

Hi guys. Has anybody solved that puzzle? Or perhaps it's not a puzzle at all, I'd imagine might be trivial to experts. First I thought - and only thought so far thus asking here - 'allowed_address_pairs' I'd need but that obviously does not do anything as 'wireguard' creates its own ifaces. So.. how do you get your 'wireguard' in openstack to route (no NAT) to instances' local network(s)? many thanks, L.

3 3

[Octavia] Weekly meeting cancelled
by Gregory Thiemonge 06 Apr '22

06 Apr '22

Hi, As this is the PTG week, the Octavia weekly meeting is cancelled. Thanks, Gregory

1 0

[tripleo][RDO] Tags for Yoga GA version in tripleo projects
by Alfredo Moralejo Alonso 05 Apr '22

05 Apr '22

Hi, As we are doing builds for RDO Yoga release, I'd like to know what we should include in yoga release. In Xena, tags were created with the commits for the most recent promotion at around GA and shipped rpm packages for them. Additionally, we pinned RDO Trunk Xena to those versions. Will we get similar tags for Yoga? Best regards, Alfredo

2 3

Problems running Watcher on DevStack
by Christian Rohmann 05 Apr '22

05 Apr '22

Hello there, I am trying to setup devstack which is running Watcher. But I am running always into problems with setup not finishing and throwing errors (see below). To clarify: I am trying to setup the devstack with multiple nodes (three nodes to be exactly, one control/compute and two compute) following the instructions at https://docs.openstack.org/watcher/latest/contributor/devstack.html which leads to this configuration control / first compute node: > [[local|localrc]] > ADMIN_PASSWORD="<password>" > DATABASE_PASSWORD=$ADMIN_PASSWORD > RABBIT_PASSWORD=$ADMIN_PASSWORD > SERVICE_PASSWORD=$ADMIN_PASSWORD > SERVICE_HOST="<ip of the control node>" > HOST_IP="<ip of host>" > FIXED_RANGE="10.4.128.0/20" > FLOATING_RANGE="subnet range" > > DEVSTACK_RELEASE="stable/yoga" > > LOGFILE=/opt/stack/logs/stack.sh.log > LOGDAYS=7 > LOG_COLOR=False > > enable_plugin watcher https://opendev.org/openstack/watcher > $DEVSTACK_RELEASE > > enable_plugin watcher-dashboard > https://opendev.org/openstack/watcher-dashboard $DEVSTACK_RELEASE > > enable_plugin ceilometer https://opendev.org/openstack/ceilometer.git > $DEVSTACK_RELEASE > CEILOMETER_BACKEND=gnocchi > > enable_service ceilometer-api > enable_service ceilometer-acompute > > enable_plugin gnocchi https://github.com/gnocchixyz/gnocchi > > # OpenStack Telemetry (Ceilometer) Alarming > # enable_plugin aodh https://opendev.org/openstack/aodh $DEVSTACK_RELEASE > > # I did not use the panko project which is mentioned in the > documentation because it is deprecated > > [[post-config|$NOVA_CONF]] > [DEFAULT] > compute_monitors=cpu.virt_driver > [scheduler] > discover_hosts_in_cells_interval=2 additional compute node(s): > [[local|localrc]] > HOST_IP="<host ip>" > FIXED_RANGE=10.4.128.0/20 > FLOATING_RANGE="<floating range" > ADMIN_PASSWORD="<password>" > DATABASE_PASSWORD=$ADMIN_PASSWORD > RABBIT_PASSWORD=$ADMIN_PASSWORD > SERVICE_PASSWORD=$ADMIN_PASSWORD > DATABASE_TYPE=mysql > SERVICE_HOST="<ip of control node>" > MYSQL_HOST=$SERVICE_HOST > RABBIT_HOST=$SERVICE_HOST > GLANCE_HOSTPORT=$SERVICE_HOST:9292 > Q_HOST=$SERVICE_HOST > OVN_SB_REMOTE=tcp:$SERVICE_HOST:6642 > disable_all_services > ENABLED_SERVICES=n-cpu,placement-client,ovn-controller,q-ovn-metadata-agent > NOVA_VNC_ENABLED=True > NOVNCPROXY_URL="http://$SERVICE_HOST:6080/vnc_lite.html" > VNCSERVER_LISTEN=$HOST_IP > VNCSERVER_PROXYCLIENT_ADDRESS=$VNCSERVER_LISTEN > > DEVSTACK_RELEASE="stable/yoga" > > LOGFILE=/opt/stack/logs/stack.sh.log > LOGDAYS=7 > LOG_COLOR=False > > enable_plugin ceilometer https://opendev.org/openstack/ceilometer > $DEVSTACK_RELEASE > disable_service ceilometer-acentral > disable_service ceilometer-collector > disable_service ceilometer-api > > [[post-config|$NOVA_CONF]] > [DEFAULT] > compute_monitors=cpu.virt_driver In addition I have tried to use the configuration that can be found in the repository of the watcher-project at https://opendev.org/openstack/watcher/src/branch/master/devstack. The error is always the same with setup.sh ending in: > ++ /opt/stack/ceilometer/devstack/plugin.sh:configure_ceilometer:244 > : cp /opt/stack/ceilometer/etc/ceilometer/polling_all.yaml > /etc/ceilometer/polling.yaml > ++ /opt/stack/ceilometer/devstack/plugin.sh:configure_ceilometer:246 > : cp > /opt/stack/ceilometer/ceilometer/pipeline/data/event_definitions.yaml > /opt/stack/ceilometer/ceilometer/pipeline/data/event_pipeline.yaml > /opt/stack/ceilometer/ceilometer/pipeline/data/pipeline.yaml > /etc/ceilometer > ++ /opt/stack/ceilometer/devstack/plugin.sh:configure_ceilometer:248 > : '[' '' ']' > ++ /opt/stack/ceilometer/devstack/plugin.sh:configure_ceilometer:251 > : '[' False == True ']' > ++ /opt/stack/ceilometer/devstack/plugin.sh:configure_ceilometer:259 > : iniset /etc/ceilometer/ceilometer.conf service_credentials > auth_type password > ++ /opt/stack/ceilometer/devstack/plugin.sh:configure_ceilometer:260 > : iniset /etc/ceilometer/ceilometer.conf service_credentials > user_domain_id default > ++ /opt/stack/ceilometer/devstack/plugin.sh:configure_ceilometer:261 > : iniset /etc/ceilometer/ceilometer.conf service_credentials > project_domain_id default > ++ /opt/stack/ceilometer/devstack/plugin.sh:configure_ceilometer:262 > : iniset /etc/ceilometer/ceilometer.conf service_credentials > project_name service > ++ /opt/stack/ceilometer/devstack/plugin.sh:configure_ceilometer:263 > : iniset /etc/ceilometer/ceilometer.conf service_credentials > username ceilometer > ++ /opt/stack/ceilometer/devstack/plugin.sh:configure_ceilometer:264 > : iniset /etc/ceilometer/ceilometer.conf service_credentials > password <password> > ++ /opt/stack/ceilometer/devstack/plugin.sh:configure_ceilometer:265 > : iniset /etc/ceilometer/ceilometer.conf service_credentials > region_name RegionOne > ++ /opt/stack/ceilometer/devstack/plugin.sh:configure_ceilometer:266 > : iniset /etc/ceilometer/ceilometer.conf service_credentials > auth_url http://192.168.0.100/identity > ++ /opt/stack/ceilometer/devstack/plugin.sh:configure_ceilometer:268 > : configure_auth_token_middleware /etc/ceilometer/ceilometer.conf > ceilometer /var/cache/ceilometer > ++ lib/keystone:configure_auth_token_middleware:467 : echo 'WARNING: > configure_auth_token_middleware is deprecated, use > configure_keystone_authtoken_middleware instead' > WARNING: configure_auth_token_middleware is deprecated, use > configure_keystone_authtoken_middleware instead > ++ lib/keystone:configure_auth_token_middleware:468 : > configure_keystone_authtoken_middleware > /etc/ceilometer/ceilometer.conf ceilometer > ++ lib/keystone:configure_keystone_authtoken_middleware:447 : local > conf_file=/etc/ceilometer/ceilometer.conf > ++ lib/keystone:configure_keystone_authtoken_middleware:448 : local > admin_user=ceilometer > ++ lib/keystone:configure_keystone_authtoken_middleware:449 : local > section=keystone_authtoken > ++ lib/keystone:configure_keystone_authtoken_middleware:451 : iniset > /etc/ceilometer/ceilometer.conf keystone_authtoken auth_type password > ++ lib/keystone:configure_keystone_authtoken_middleware:452 : iniset > /etc/ceilometer/ceilometer.conf keystone_authtoken interface public > ++ lib/keystone:configure_keystone_authtoken_middleware:453 : iniset > /etc/ceilometer/ceilometer.conf keystone_authtoken auth_url > http://192.168.0.100/identity > ++ lib/keystone:configure_keystone_authtoken_middleware:454 : iniset > /etc/ceilometer/ceilometer.conf keystone_authtoken username ceilometer > ++ lib/keystone:configure_keystone_authtoken_middleware:455 : iniset > /etc/ceilometer/ceilometer.conf keystone_authtoken password <password> > ++ lib/keystone:configure_keystone_authtoken_middleware:456 : iniset > /etc/ceilometer/ceilometer.conf keystone_authtoken user_domain_name > Default > ++ lib/keystone:configure_keystone_authtoken_middleware:457 : iniset > /etc/ceilometer/ceilometer.conf keystone_authtoken project_name service > ++ lib/keystone:configure_keystone_authtoken_middleware:458 : iniset > /etc/ceilometer/ceilometer.conf keystone_authtoken project_domain_name > Default > ++ lib/keystone:configure_keystone_authtoken_middleware:460 : iniset > /etc/ceilometer/ceilometer.conf keystone_authtoken cafile > /opt/stack/data/ca-bundle.pem > ++ lib/keystone:configure_keystone_authtoken_middleware:461 : iniset > /etc/ceilometer/ceilometer.conf keystone_authtoken memcached_servers > localhost:11211 > ++ /opt/stack/ceilometer/devstack/plugin.sh:configure_ceilometer:270 > : [[ libvirt = \v\s\p\h\e\r\e ]] > ++ /opt/stack/ceilometer/devstack/plugin.sh:configure_ceilometer:277 > : _ceilometer_configure_storage_backend > ++ > /opt/stack/ceilometer/devstack/plugin.sh:_ceilometer_configure_storage_backend:208 > : '[' gnocchi = none ']' > ++ > /opt/stack/ceilometer/devstack/plugin.sh:_ceilometer_configure_storage_backend:210 > : '[' gnocchi = gnocchi ']' > ++ > /opt/stack/ceilometer/devstack/plugin.sh:_ceilometer_configure_storage_backend:211 > : sed -i > 's/gnocchi:\/\//gnocchi:\/\/?archive_policy=ceilometer-low\&filter_project=gnocchi_swift/' > /etc/ceilometer/event_pipeline.yaml /etc/ceilometer/pipeline.yaml > ++ > /opt/stack/ceilometer/devstack/plugin.sh:_ceilometer_configure_storage_backend:212 > : [[ ,watcher,watcher-dashboard,ceilometer,gnocchi =~ gnocchi ]] > + /opt/stack/ceilometer/devstack/plugin.sh:configure_ceilometer:1 : > exit_trap What am I missing? Any configuration parameter? Thanks in advance Christian

2 1

[TripleO] Move tripleo repos stable/ussuri to End Of Life OK?
by Marios Andreou 05 Apr '22

05 Apr '22

Hello TripleO o/ The tripleo-ci team proposes that we move the stable/ussuri branch for all tripleo repos [1] to End of Life [2]. The branch was moved to extended maintenance with [3] so we can already no longer make any new releases for ussuri/tripleo repos. Are there any objections or concerns about this? If so please speak up here or directly on the patch. I think that any patches posted to ussuri nowadays are mainly about cherrypicking back to train, rather than merging something to ussuri specifically. I have posted the proposal to move to EOL at [4] and have WF-1 to wait for this discussion. If there are no objections then once we move to EOL the tripleo-ci team will remove all Ussuri related CI, check/gate/promotions. regards, marios [1] https://releases.openstack.org/teams/tripleo.html#ussuri [2] https://docs.openstack.org/project-team-guide/stable-branches.html#maintena… [3] https://review.opendev.org/c/openstack/releases/+/817623 [4] https://review.opendev.org/c/openstack/releases/+/834049

2 5

Kubernetes cluster fails with timed out error
by Karera Tony 05 Apr '22

05 Apr '22

Hello Team, I deployed Openstack Wallaby using kolla-ansible and enabled Magnum. The Installation was Ok but when I try to deploy a k8s cluster with fedora-coreos-32.20200601.3.0 image, it fails with a timeout error. When I check the /var/log/heat-config/heat-config-script logs on the master node, I get the error below. ++ kubectl get --raw=/healthz The connection to the server localhost:8080 was refused - did you specify the right host or port? + '[' ok = '' ']' + sleep 5 ++ kubectl get --raw=/healthz The connection to the server localhost:8080 was refused - did you specify the right host or port? + '[' ok = '' ']' + sleep 5 ++ kubectl get --raw=/healthz Any idea on what could be the issue. Regards Regards Tony Karera

2 4

[cinder] Zed PTG schedule
by Rajat Dhasmana 05 Apr '22

05 Apr '22

Hello Argonauts, Zed PTG is going to start from next week i.e. 4th April, 2022 to 8th April, 2022. Kindly register if you haven't already[1]. The registration is free and acts as a count of the people participating. The Cinder team will be meeting from 5th April (Tuesday) till 8th April (Friday) in the 1300-1700 UTC time slot. I've arranged the topics as per participants availability and in the following manner[2]. The connection details are on the etherpad along with the day wise schedule of topics. I've also arranged them in a tabular structure[3] (the time allotted to each topic here might vary). Hope to see everyone next week! [1] https://openinfra-ptg.eventbrite.com/ [2] https://etherpad.opendev.org/p/zed-ptg-cinder [3] https://ethercalc.openstack.org/crz6qdm7fq0v Thanks and regards Rajat Dhasmana

1 1

[tacker] No IRC meeting on Apr 5th
by Yasufumi Ogawa 05 Apr '22

05 Apr '22

Hi, I'd like to skip IRC meeting today since it's PTG week. Cheers, Yasufumi

1 0