January 2024 - openstack-discuss - lists.openstack.org

tox -e pep8 error
by Alex Song (宋文平) 05 Jan '24

05 Jan '24

Folks, my env run 'tox -e pep8' error with the info below, any body can help? Thanks. /opt/stack/nova/.tox/pep8/lib/python3.8/site-packages/setuptools/__init__.py :80: _DeprecatedInstaller: setuptools.installer and fetch_build_eggs are deprecated. !! **************************************************************************** **** Requirements should be satisfied by a PEP 517 installer. If you are using pip, you can try `pip install --use-pep517`. **************************************************************************** **** !! dist.fetch_build_eggs(dist.setup_requires) /opt/stack/nova/.tox/pep8/lib/python3.8/site-packages/setuptools/command/dev elop.py:39: EasyInstallDeprecationWarning: easy_install command is deprecated. !! **************************************************************************** **** Please avoid running ``setup.py`` and ``easy_install``. Instead, use pypa/build, pypa/installer or other standards-based tools. See https://github.com/pypa/setuptools/issues/917 for details. **************************************************************************** **** !! easy_install.initialize_options(self) /opt/stack/nova/.tox/pep8/lib/python3.8/site-packages/setuptools/_distutils/ cmd.py:66: SetuptoolsDeprecationWarning: setup.py install is deprecated. !! **************************************************************************** **** Please avoid running ``setup.py`` directly. Instead, use pypa/build, pypa/installer or other standards-based tools. See https://blog.ganssle.io/articles/2021/10/setup-py-deprecated.html for details. **************************************************************************** **** !! self.initialize_options() pep8 develop-inst-nodeps: /opt/stack/nova pep8 installed: alembic==1.9.4,amqp==5.1.1,async-timeout==4.0.3,attrs==23.1. 0,autopage==0.5.1,backports.zoneinfo==0.2.1,bcrypt==4.0.1,cachetools==5.3.1, castellan==4.3.0,certifi==2023.11.17,cffi==1.15.1,cfgv==3.4.0,charset-normal izer==3.2.0,cliff==4.4.0,cmd2==2.4.3,cryptography==41.0.4,cursive==0.2.3,deb tcollector==2.5.0,decorator==5.1.1,Deprecated==1.2.14,distlib==0.3.7,dnspyth on==2.4.2,dogpile.cache==1.2.2,eventlet==0.33.3,fasteners==0.19,filelock==3. 12.4,fixtures==4.1.0,futurist==2.4.1,greenlet==2.0.2,identify==2.5.33,idna== 3.4,importlib-metadata==6.0.1,importlib-resources==6.1.1,iso8601==2.0.0,Jinj a2==3.1.2,jmespath==1.0.1,jsonpatch==1.33,jsonpointer==2.4,jsonschema==4.19. 1,jsonschema-specifications==2023.7.1,jwcrypto==1.5.1,keystoneauth1==5.4.0,k eystonemiddleware==10.5.0,kombu==5.3.2,lxml==4.9.3,Mako==1.2.4,MarkupSafe==2 .1.3,microversion-parse==1.0.1,msgpack==1.0.6,netaddr==0.9.0,netifaces==0.11 .0,nodeenv==1.8.0,-e git+ssh://songwenping@review.opendev.org:29418/openstack/nova@39f560d6730f2b 212506b7d754645c288d13f1cd#egg=nova,numpy==1.24.2,openstacksdk==2.0.0,os-bri ck==6.5.0,os-client-config==2.1.0,os-resource-classes==1.1.0,os-service-type s==1.7.0,os-traits==3.0.0,os-vif==3.3.0,os-win==5.9.0,osc-lib==2.8.1,oslo.ca che==3.5.0,oslo.concurrency==5.2.0,oslo.config==9.2.0,oslo.context==5.3.0,os lo.db==14.1.0,oslo.i18n==6.2.0,oslo.limit==2.2.0,oslo.log==5.4.0,oslo.messag ing==14.5.0,oslo.metrics==0.7.0,oslo.middleware==5.2.0,oslo.policy==4.2.1,os lo.privsep==3.2.0,oslo.reports==3.1.0,oslo.rootwrap==7.1.0,oslo.serializatio n==5.2.0,oslo.service==3.2.0,oslo.upgradecheck==2.2.0,oslo.utils==6.3.0,oslo .versionedobjects==3.2.0,ovs==3.1.2,ovsdbapp==2.5.0,packaging==23.1,paramiko ==3.3.1,Paste==3.5.3,PasteDeploy==3.0.1,pbr==6.0.0,pkgutil_resolve_name==1.3 .10,platformdirs==3.10.0,pre-commit==3.5.0,prettytable==3.9.0,prometheus-cli ent==0.17.1,psutil==5.9.5,pycadf==3.1.1,pycparser==2.21,pyinotify==0.9.6,PyJ WT==2.8.0,PyNaCl==1.5.0,pyOpenSSL==23.2.0,pyparsing==3.1.1,pyperclip==1.8.2, pyroute2==0.7.9,python-barbicanclient==5.6.1,python-cinderclient==9.4.0,pyth on-dateutil==2.8.2,python-glanceclient==4.4.0,python-keystoneclient==5.2.0,p ython-neutronclient==11.1.0,pytz==2023.3.post1,PyYAML==6.0.1,redis==5.0.0,re ferencing==0.30.2,repoze.lru==0.7,requests==2.31.0,requestsexceptions==1.4.0 ,retrying==1.3.4,rfc3986==2.0.0,Routes==2.5.1,rpds-py==0.10.3,simplejson==3. 19.1,six==1.16.0,sortedcontainers==2.4.0,SQLAlchemy==1.4.41,statsd==4.0.1,st evedore==5.1.0,tenacity==6.3.1,testresources==2.0.1,testscenarios==0.5.0,tes ttools==2.7.0,tooz==4.2.0,typing_extensions==4.8.0,tzdata==2023.3,urllib3==1 .26.16,vine==5.0.0,virtualenv==20.24.5,voluptuous==0.13.1,warlock==2.0.1,wcw idth==0.2.6,WebOb==1.8.7,websockify==0.11.0,wrapt==1.15.0,yappi==1.4.0,zipp= =3.17.0 pep8 run-test-pre: PYTHONHASHSEED='2048831401' pep8 run-test: commands[0] | pre-commit run --all-files --show-diff-on-failure [INFO] Locking pre-commit directory [INFO] Initializing environment for https://github.com/pre-commit/pre-commit-hooks. An unexpected error has occurred: CalledProcessError: command: ('/usr/bin/git', 'fetch', 'origin', '--tags') return code: 128 stdout: (none) stderr: (none) Check the log at /root/.cache/pre-commit/pre-commit.log ERROR: InvocationError for command /opt/stack/nova/.tox/pep8/bin/pre-commit run --all-files --show-diff-on-failure (exited with code 3) ____________________________________________________________________________ _______________________________________________________________ summary ____________________________________________________________________________ _______________________________________________________________ ERROR: pep8: commands failed

2 2

Issue when connecting to openstack object storage with openstacksdk
by sadir＠free.fr 05 Jan '24

05 Jan '24

Hello, I am currently developing a software application to access the OpenStack object store service on an IBM Spectrum Scale server. I first created a Python application which is manipulating objects and containers thru the OpenStack's object storage REST API (https://docs.openstack.org/api-ref/object-store) It works fine and I had no issue to access the server object store service by this way. But I also need to access the OpenStack object store service thru the openstacksdk (https://docs.openstack.org/openstacksdk/latest) Unfortunately, the connection does not seem to work properly in this case, even when using the same identifiers than in the working Python/REST application. The connection stalls and goes into some sort of timeout. I also made some tests by putting wrong identifiers, and then it fails immediately with a different error message. It makes me think that something goes wrong after the authentication process. The error message I have is this one: Failed to contact the endpoint at http://yeti.ds.eurecom.fr:8080/v1/AUTH_da0d8589692741d1b2a82956568227e6 for discovery. Fallback to using that endpoint as the base url. I am wondering if there is some additional configuration to perform on the server or the network to make it work as expected. Could you please provide me with some support so that I can sort out what's going on? I could of course share the Python piece of code I am using for my testing. Thank you for your help.

5 4

zun containers
by Jaime Ibar 05 Jan '24

05 Jan '24

Hi, anyone using zun for containers? I'm getting an error when launching one. Thanks Jaime -- Jaime

1 0

RE: openstack-discuss Digest, Vol 62, Issue 108- Neutron Issue | Urgent Assistance
by Asma Naz Shariq 05 Jan '24

05 Jan '24

Hi Neutron_ Team I have deployed Multinode cluster of Openstack through kolla-ansible zed release. The problem I am facing is instances created cannot pick any Ip addresses (Rather than loop back ip or ipv6 addresses) from the created tenant networks with the default network type is vxlan. However, if I can assign ip manually to the eth0 interface in cirros instance, the interface is up with the ip address, but still, it can’t able to ping even its router gateway. Router can’t be able to ping instance ip address but only ping itself as verified below: The following troubleshooting steps, I have followed and concluded: ~ The Tenant network is created and its port: network: router_interface, network:dhcp, compute:nova are in admin up and active state. ~ The router interfaces are in up state and in complete nova zone. ~ The instance is running and active state and automatically pick ip address from the created tenant network as displayed in gui but inside the vm it can’t pick any ip address. ~ The security groups have been defined to allow icmp, tcp, udp for inbound/outbound traffic. Hence, I may not be able to ping and ssh instance from the controller node further these instances won’t be able to connect to the internet until the issue get resolved. Can you guide me how to resolve these issues related to network connectivity so I may able to send you the required files to troubleshoot easily? -----Original Message----- From: openstack-discuss-request(a)lists.openstack.org <openstack-discuss-request(a)lists.openstack.org> Sent: Tuesday, January 2, 2024 7:39 PM To: openstack-discuss(a)lists.openstack.org Subject: openstack-discuss Digest, Vol 62, Issue 108 Send openstack-discuss mailing list submissions to openstack-discuss(a)lists.openstack.org To subscribe or unsubscribe via email, send a message with subject or body 'help' to openstack-discuss-request(a)lists.openstack.org You can reach the person managing the list at openstack-discuss-owner(a)lists.openstack.org When replying, please edit your Subject line so it is more specific than "Re: Contents of openstack-discuss digest..." Today's Topics: 1. Re: [trove][victoria] can't connect to trove DB from outside - although ssh to the trove instance works (Tony Breeds) 2. Re: [trove][victoria] can't connect to trove DB from outside - although ssh to the trove instance works (dieter.dorra(a)hsnr.de) 3. Re: Trove installation filed (dieter.dorra(a)hsnr.de) 4. Re: Trove installation filed (KEREM CELIKER) 5. Re: [kolla] ceilometer and nova compute agent (KEREM CELIKER) 6. Re: ceilometer cli client install help (KEREM CELIKER) 7. [neutron] Bug deputy report (last week of 2023) (Bernard Cafarelli) 8. New OpenStack machine on new node not responding (kjme001(a)gmail.com) 9. Re: New OpenStack machine on new node not responding ( 韩光宇 ) ---------------------------------------------------------------------- Message: 1 Date: Fri, 29 Dec 2023 23:28:42 +1100 From: Tony Breeds <tony(a)bakeyournoodle.com> Subject: Re: [trove][victoria] can't connect to trove DB from outside - although ssh to the trove instance works To: dieter.dorra(a)hsnr.de Cc: openstack-discuss(a)lists.openstack.org Message-ID: <CAFT5D2RzaXi6==waA732R0PVe6H0OeKBwzF_qUSOTHPVfCu7Ww(a)mail.gmail.com> Content-Type: text/plain; charset="UTF-8" On Fri, 29 Dec 2023 at 19:58, <dieter.dorra(a)hsnr.de> wrote: > > >From the guest vm I can ssh into the trove instance (so port 22 is > >open and accepting) From the guest vm I cannot reach port 3306 From > >within the trove instance I can reach port 3306 and mysql is > >functional > > It feels like the security group does not allow 3306, but the entry is > there (see etherpad) > > What puzzles me is that netstat in the trove instance does only show > listen to 3306 for tcp6 but not for tcp - whereas 22 listens for tcp6 > AND tcp > > root@ms57plain:~# netstat -anp | head -17 Active Internet connections > (servers and established) > Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name > tcp 0 0 127.0.0.53:53 0.0.0.0:* LISTEN 3867/systemd-resolv > tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 1074/sshd > tcp 0 0 10.9.9.126:22 10.9.9.128:60126 ESTABLISHED 9412/sshd: root@pts > tcp 0 0 10.10.10.84:54326 10.0.0.120:5672 ESTABLISHED 1002/python3 > tcp 0 0 10.9.9.126:22 10.9.9.128:57880 ESTABLISHED 9021/sshd: root@pts > tcp 0 0 10.10.10.84:44266 10.0.0.120:5672 ESTABLISHED 1002/python3 > tcp6 0 0 :::3306 :::* LISTEN 4881/mysqld You can see here that mysql is listening on all interfaces via an IPv4-mapped IPv6 address (https://en.wikipedia.org/wiki/IPv6#IPv4-mapped_IPv6_addresses) and from your previous post we can see that there is an explicit ACCEPT for the lo interface. That's how you're able to get access to the DB from within the guest. It looks to me that whatever added the ' -A openstack-INPUT -p tcp -m tcp --dport 22 -j ACCEPT' to the guest's firewall didn't also add an explicit rule for the database. At this point I don't know if that's trove, nova or neutron. If I had to guess I'd say that there is a mismatch in the trove configuration and the networks assigned to the guest. For example how does --- network_driver = trove.network.neutron.NeutronDriver # provider management_networks = 98b0de37-40af-4859-81f2-d89a4df2d6df # trovemgmt # provider ## management_networks = 3928eb68-edf9-4cca-8fa6-151ed26b7c04 # trove-mgmt 3928eb68-edf9-4cca-8fa6-151ed26b7c04 # management_networks = 3928eb68-edf9-4cca-8fa6-151ed26b7c04 management_security_groups = 26c4af6e-56f0-4644-8c55-e96983c74c1d --- relate to the "dozenet" and "trovemgmt" networks. Tony. ------------------------------ Message: 2 Date: Sun, 31 Dec 2023 11:27:37 -0000 From: dieter.dorra(a)hsnr.de Subject: Re: [trove][victoria] can't connect to trove DB from outside - although ssh to the trove instance works To: openstack-discuss(a)lists.openstack.org Message-ID: <170402205718.409.7027996557330367167(a)lists01.opendev.org> Content-Type: text/plain; charset="utf-8" The problem is solved! I tested a newer trove image from https://tarballs.opendev.org/openstack/trove/images/ The Victoria image caused the problem, it never showed the exposed ports in "docker ps". The Zed image is working: ubuntu@dd:~$ docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 1741ae3e7815 mysql:5.7.29 "docker-entrypoint.s…" 4 minutes ago Up 4 minutes 0.0.0.0:3306->3306/tcp, :::3306->3306/tcp, 33060/tcp database ubuntu@dd:~$ Thank you all so much for your assistance and help!!! Happy new year!! ------------------------------ Message: 3 Date: Sun, 31 Dec 2023 16:49:39 -0000 From: dieter.dorra(a)hsnr.de Subject: Re: Trove installation filed To: openstack-discuss(a)lists.openstack.org Message-ID: <170404137950.409.18389774625483655904(a)lists01.opendev.org> Content-Type: text/plain; charset="utf-8" Hi, when you log in as user trove in the service project - can you launch an instance? "no valid host was found" sounds that nova has a problem... BR Dieter ------------------------------ Message: 4 Date: Mon, 01 Jan 2024 05:40:46 -0000 From: "KEREM CELIKER" <kmceliker(a)gmail.com> Subject: Re: Trove installation filed To: openstack-discuss(a)lists.openstack.org Message-ID: <170408764655.409.16151116383780837301(a)lists01.opendev.org> Content-Type: text/plain; charset="utf-8" Please provide and check the Trove guest agent log file (by default, /var/log/trove/trove-guestagent.log) for any errors or warnings.. Also share with us the logs output that we can take a look. By the way, dont forget to check this following link to troubleshoot; https://docs.openstack.org/trove/latest/admin/troubleshooting.html Kerem Çeliker ------------------------------ Message: 5 Date: Mon, 01 Jan 2024 05:46:32 -0000 From: "KEREM CELIKER" <kmceliker(a)gmail.com> Subject: Re: [kolla] ceilometer and nova compute agent To: openstack-discuss(a)lists.openstack.org Message-ID: <170408799208.407.10760598762569499228(a)lists01.opendev.org> Content-Type: text/plain; charset="utf-8" You dont need to create a custom nova container to measure instances metrics. Only can use the “openstack host show” and “openstack server list” to get basic stats on resource usage for hosts and instances. Also use tools, such as Ganglia or Graphite, to gather more detailed data. It’s up to you! Kerem Çeliker ------------------------------ Message: 6 Date: Mon, 01 Jan 2024 06:07:02 -0000 From: "KEREM CELIKER" <kmceliker(a)gmail.com> Subject: Re: ceilometer cli client install help To: openstack-discuss(a)lists.openstack.org Message-ID: <170408922210.407.17546497674894904858(a)lists01.opendev.org> Content-Type: text/plain; charset="utf-8" It seems that you have not gnocchi plugin on OSP All-In-One. Also your OSP has not correct openstack client version or you needed the install the gnocchi plugin correctly. Please check gnocchi plugin if installed.. Here is the cli’s ; • openstack plugin list and check for gnocchi in the output any issues.. or try it; • pip install python-gnocchiclient. Kerem Çeliker ------------------------------ Message: 7 Date: Tue, 2 Jan 2024 09:52:31 +0100 From: Bernard Cafarelli <bcafarel(a)redhat.com> Subject: [neutron] Bug deputy report (last week of 2023) To: OpenStack Discuss <openstack-discuss(a)lists.openstack.org> Message-ID: <CABHdKwov77XQ31h26vq6UvzyOjaANcU1F6zjY1opS_H2XZp=PQ(a)mail.gmail.com> Content-Type: multipart/alternative; boundary="0000000000001b8f3a060df29f3c" Hey neutrinos, and happy new year! Here is the bug reported between 2023-12-25 and 2023-12-31 (as per tradition, it was a quiet week) The firewall group is ACTIVE without associate with a router or any firewall policies - https://bugs.launchpad.net/neutron/+bug/2047325 neutron-fwaas bug, patch proposed: https://review.opendev.org/c/openstack/neutron-fwaas/+/904317 Best wishes -- Bernard Cafarelli

2 5

[neutron] Drivers meeting
by Rodolfo Alonso Hernandez 05 Jan '24

05 Jan '24

Hello Neutrinos: Today we have the Neutron drivers meeting at 14:00UTC. There is one topic in the agenda [1]: * https://bugs.launchpad.net/neutron/+bug/2047849: [RFE] Start using oslo messaging namespaces See you in the IRC Neutron channel. [1]https://wiki.openstack.org/wiki/Meetings/NeutronDrivers#Agenda

1 0

[TC][Monasca] Proposal to mark Monasca as an inactive project
by Sławek Kapłoński 04 Jan '24

04 Jan '24

Hi, I just proposed patch [1] to mark Monasca as inactive project. It was discussed during last TC meeting on 03.10.2023. Reasons for that are described in the commit message of the [1] but I will also put all of it here: previous cycle there wasn't almost any contributions to that project and most active contributors in last 180 days were Elod Illes and Dr. Jens Harbott who were fixing some Zuul configuration issues only. Here are detailed statistics about Monasca projects: Validating Gerrit... * There are 7 ready for review patches generated within 180 days * There are 2 not reviewed patches generated within 180 days * There are 5 merged patches generated within 180 days * Unreviewed patch rate for patches generated within 180 days is 28.0 % * Merged patch rate for patches generated within 180 days is 71.0 % * Here's top 10 owner for patches generated within 180 days (Name/Account_ID: Percentage): - Dr. Jens Harbott : 42.86% - Joel Capitao : 28.57% - Elod Illes : 28.57% Validate Zuul... Set buildsets fetch size to 500 * Repo: openstack/monasca-log-api gate job builds success rate: 82% * Repo: openstack/monasca-statsd gate job builds success rate: 95% * Repo: openstack/monasca-tempest-plugin gate job builds success rate: 81% * Repo: openstack/monasca-common gate job builds success rate: 84% * Repo: openstack/monasca-kibana-plugin gate job builds success rate: 83% * Repo: openstack/monasca-ceilometer gate job builds success rate: 100% * Repo: openstack/monasca-events-api gate job builds success rate: 83% * Repo: openstack/monasca-ui gate job builds success rate: 88% * Repo: openstack/monasca-specs gate job builds success rate: 100% * Repo: openstack/monasca-grafana-datasource gate job builds success rate: 100% * Repo: openstack/monasca-persister gate job builds success rate: 98% * Repo: openstack/monasca-notification gate job builds success rate: 93% * Repo: openstack/monasca-thresh gate job builds success rate: 100% * Repo: openstack/monasca-api gate job builds success rate: 76% * Repo: openstack/monasca-agent gate job builds success rate: 98% * Repo: openstack/python-monascaclient gate job builds success rate: 100% * Repo: openstack/monasca-transform gate job builds success rate: 100% What's next? According to the "Emerging and inactive projects" document [2] if there will be no volunteers who will step up and want to maintain this project before Milestone-2 of the 2024.1 cycle (week of Jan 08 2024) there will be no new release of Monasca in the 2024.1 cycle and TC will discuss if project should be retired. So if You are interested in keeping Monasca alive and active, please reach out to the TC to discuss that ASAP. Thx in advance. [1] https://review.opendev.org/c/openstack/governance/+/897520 [2] https://governance.openstack.org/tc/reference/emerging-technology-and-inact… -- Slawek Kaplonski Principal Software Engineer Red Hat

8 14

beginning with [masakari]
by Shubham Kumar Yadav 04 Jan '24

04 Jan '24

Hi, i have recently started working on Masakari (kubernetes in openstack) so i wanted some help with it please i was trying to test the masakari-instance-monitor & masakari-host-monitor but having trouble with it. i have created a pacemaker remote cluster (with pacemaker & corosync on controller nodes and pacemaker remote on compute node). *pcs statusCluster name: lab-clusterCluster Summary: * Stack: corosync * Current DC: lab-11053-26006-ceph-2 (version 2.1.2-ada5c3b36e2) - partition with quorum * Last updated: Thu Dec 14 08:41:41 2023 * Last change: Thu Dec 14 08:41:22 2023 by root via cibadmin on lab-11053-26006-ceph-1 * 6 nodes configured * 3 resource instances configuredNode List: * Online: [ lab-11053-26006-ceph-1 lab-11053-26006-ceph-2 lab-11053-26006-ceph-3 ] * RemoteOnline: [ lab-11053-26006-comp-1.cluster.local lab-11053-26006-comp-2.cluster.local lab-11053-26006-comp-3.cluster.local ]Full List of Resources: * lab-11053-26006-comp-1.cluster.local (ocf:pacemaker:remote): Started lab-11053-26006-ceph-1 * lab-11053-26006-comp-2.cluster.local (ocf:pacemaker:remote): Started lab-11053-26006-ceph-2 * lab-11053-26006-comp-3.cluster.local (ocf:pacemaker:remote): Started lab-11053-26006-ceph-3Daemon Status: corosync: active/enabled pacemaker: active/enabled pcsd: active/enabled* i have also created segment and added segment hosts(computes) in it. when i tried to test the masakari host monitor by manually powering off the compute node, masakari should move the vms from powered off computes to some running compute but after the compute is powered off vms still remains on the powered off compute. Am i missing some conf? is there any need to add some conf in nova and keystone too? *in masakari engine logs i see host_failure.evacuate_all_instances = Trueinstance_failure.process_all_instances = Falsehost_failure.add_reserved_host_to_aggregate = Falsehost_failure.ha_enabled_instance_metadata_key = HA_Enabled log_opt_valueshost_failure.ignore_instances_in_error_state = Falsehost_failure.service_disable_reason = Masakari detected host failed.* and i get below error when i turn off an instance on the compute, logs are from masakari-instance-monitor *2024-01-03 13:01:15.574 1 DEBUG openstack.resource [-] Attribute [] not found in [<openstack.resource._ComponentManager object at 0x7fa051f48730>]: ''. __getattribute__ /var/lib/openstack/lib/python3.8/site-packages/openstack/resource.py:6222024-01-03 13:01:15.595 1 WARNING masakarimonitors.ha.masakari [-] Retry sending a notification. (BadRequestException: 400: Client Error for url: http://masakari-api.openstack.svc.cluster.local:15868/v1/9db00e10af034fc6a4… <http://masakari-api.openstack.svc.cluster.local:15868/v1/9db00e10af034fc6a4…>, Host with name lab-11053-26006-cmp-1 could not be found.): openstack.exceptions.BadRequestException: BadRequestException: 400: Client Error for url: http://masakari-api.openstack.svc.cluster.local:15868/v1/9db00e10af034fc6a4… <http://masakari-api.openstack.svc.cluster.local:15868/v1/9db00e10af034fc6a4…>, Host with name lab-11053-26006-cmp-1 could not be found.* (do i need to create some masakari notifications for it to work in openstack? if yes how may i do it) below i have attached the logs from masakari-hostmonitor and masakari-engine and also some components which i created in openstack about masakari do you have any suggestion please let me know! Thank You

2 1

[magnum][cluster-api] Why magnum creating bunch of users
by Satish Patel 04 Jan '24

04 Jan '24

Folks, I have deployed Magnum-CAPI for testing and things working fine but just noticed magnum creating a bunch of users and have no idea what they are those for? This list is small in real I have 100s of them. is this normal? # openstack user list +----------------------------------+-----------------------------------------------------------------------+ | ID | Name | +----------------------------------+-----------------------------------------------------------------------+ | 01ff85efed43419486558864e35f39cf | 90e763f2-c566-4c1f-92f0-e36be5933538_08cae850a5bb47d998da180a7f0e2660 | | bd8c2337df0a451da92732aae1fe5f68 | abf42808-d67c-450e-88e0-a20e65f35232_08cae850a5bb47d998da180a7f0e2660 | | 81d6c4c23bd84d62ab3422f109ced3d5 | ee1b8a35-d23b-42eb-9574-edb6562b4147_08cae850a5bb47d998da180a7f0e2660 | | 988550004ee3413eba2bb20f73f24013 | 8eaf2db3-d13c-4849-a517-5528219fc32f_08cae850a5bb47d998da180a7f0e2660 | | a50a0b596a024edb8c4a9bae05d1844c | e7194788-4ae5-4e17-9c48-fa3bf4e65016_08cae850a5bb47d998da180a7f0e2660 | | 664e7708f64f4b9d8071dac8d9fc580f | ea999930-8d10-42b2-ae31-2236fffb07a1_08cae850a5bb47d998da180a7f0e2660 | | 67de8c5761564fdbba998cc7c2a14948 | 0ef17525-9ee5-4416-b3bc-f6ccd5a1f3b0_08cae850a5bb47d998da180a7f0e2660 |

2 2

[magnum] magnum-capi management cluster controle plane in HA
by Satish Patel 04 Jan '24

04 Jan '24

Folks, In the lab I have deployed a magnum-capi driver with a single node kind cluster and it works great. Now I want to take it to production and make sure my capi management cluster runs on a HA environment of k8s and survives all kinds of failure. I have deployed 3 node k8s using kubespray and deployed CAPI applications on top of it using clusterctl init command but it default created a replica of 1/1 for all pods. How do I tell clusterctl to create a replica with 3 for HA and how does data replication work? How do I take backup/restore of data in k8s cluster using clusterctl for disaster recovery? I have checked official documents but it's a little confusing so I'm asking question here to clear my doubts. Cheers! ~S

3 6

Re: [kolla-ansible][magnum] question
by Oliver Weinmann 03 Jan '24

03 Jan '24

Hi Franck, Great. Glad it works. That is the k8s version and the url where magnum will pull the container from. The official docs are quite helpful. In the latest Openstack release bobcat there is already some support for CAPI. It is not 100% working out of the Box but it looks very promising. I have taken my blog post offline since I didn’t manage to get it working. But I will look into it again in the next couple of days. Cheers, Oliver Von meinem iPhone gesendet > Am 03.01.2024 um 12:21 schrieb Franck VEDEL <franck.vedel(a)univ-grenoble-alpes.fr>: > > Hi Oliver, > and thanks a lot for your help. > I followed the instructions on the blog and indeed, with [trust] it works. > I'm trying to understand everything. what are the parameters for: > > --labels kube_tag=v1.21.11-rancher1,hyperkube_prefix=docker.io/rancher/ > > Thanks in advance > > Franck > > > >> Le 25 déc. 2023 à 19:26, Franck VEDEL <franck.vedel(a)univ-grenoble-alpes.fr> a écrit : >> >> Hi Oliver and thanks you for this help. >> >> I was wrong in my explications. >> I had seen this article (roksblog.de ) and I did what it said: >> I first tried: >> enable_cluster_user_trust = True in globals.yml >> It didn't work. >> >> I then made the modification in /etc/kolla/config/magnum.conf: >> cluster_user_trust = True >> >> Same problem. >> >> That's why I asked the question. Is this really the way to do it? >> If so, I will have to restart the containers (keystone?) >> >> Franck >> >> >> >>> Le 25 déc. 2023 à 18:40, Oliver Weinmann <oliver.weinmann(a)me.com> a écrit : >>> >>> Hi Frank, >>> >>> According to the official kolla docs the option needs to be in globals.yml >>> >>> Ensure that you understand the consequences before enabling this option. Inglobals.yml: >>> >>> In case this also doesn’t work, you can try: >>> >>> yoga) [vagrant@seed ~]$ cat /etc/kolla/config/magnum.conf >>> [trust] >>> cluster_user_trust = True >>> >>> *www.roksblog.de >>> >>> Cheers, >>> Oliver >>> >>> Von meinem iPhone gesendet >>> >>>> Am 25.12.2023 um 18:10 schrieb Franck VEDEL <franck.vedel(a)univ-grenoble-alpes.fr>: >>>> >>>> enable_cluster_user_trust = True >> >

1 0