- openstack-discuss - lists.openstack.org

[Ceilometer] neither gnocchi nor file publisher receive any data or metric
by Mostafa Salari 19 Sep '23

19 Sep '23

Hi. how can i find a simple, correct, ceilometer configuration for "yoga" version of openstack? 1) I followed this instruction guide <https://docs.openstack.org/ceilometer/latest/install/> step by step! 2) I installed devstack with enabled ceilometer (and gnocchi as backend) but after both tries mentioned above, i did not see any metric. I also changed the publisher from gnocchi:// into file:// but the result did not change. cat /etc/ceilometer/ceilometer.conf: [DEFAULT] transport_url = rabbit://stackrabbit:bsvbr5pzLpN0szN84v3m@127.0.0.1:5672/ use_syslog = True [oslo_messaging_notifications] topics = notifications driver = messagingv2 [coordination] backend_url = redis://localhost:6379 [notification] workers = 4 [cache] backend_argument = url:redis://localhost:6379 backend_argument = distributed_lock:True backend_argument = db:0 backend_argument = redis_expiration_time:600 backend = dogpile.cache.redis enabled = True [service_credentials] auth_url = http://127.0.0.1/identity region_name = RegionOne password = bsvbr5pzLpN0szN84v3m username = ceilometer project_name = service project_domain_id = default user_domain_id = default auth_type = password [keystone_authtoken] memcached_servers = localhost:11211 cafile = /opt/stack/data/ca-bundle.pem project_domain_name = Default project_name = service user_domain_name = Default password = bsvbr5pzLpN0szN84v3m username = ceilometer auth_url = http://127.0.0.1/identity interface = public auth_type = password _________________________________________ cat /etc/ceilometer/pipeline.yaml: --- sources: - name: meter_source meters: - "*" sinks: - meter_sink sinks: - name: meter_sink publishers: - file:///tmp/ceilofile?json # - gnocchi://?archive_policy=low&filter_project=service ____________________________ cat /etc/ceilometer/polling.yaml --- sources: - name: all_pollsters interval: 300 meters: - "*" _____________________________ root@os-aio:/# cat /etc/gnocchi/gnocchi.conf [DEFAULT] debug = True coordination_url = redis://localhost:6379 [indexer] url = mysql+pymysql:// root:bsvbr5pzLpN0szN84v3m@127.0.0.1/gnocchi?charset=utf8 [storage] redis_url = redis://localhost:6379 driver = redis [metricd] metric_processing_delay = 5 [api] auth_mode = keystone [keystone_authtoken] memcached_servers = localhost:11211 cafile = /opt/stack/data/ca-bundle.pem project_domain_name = Default project_name = service user_domain_name = Default password = bsvbr5pzLpN0szN84v3m username = gnocchi auth_url = http://127.0.0.1/identity interface = public auth_type = password

2 1

[manila] - Enforcing CephFS pool data placement via backend config. options deprecated?
by Paul Browne 18 Sep '23

18 Sep '23

Hello to the list, In OpenStack releases prior to Wallaby, in CephFS native driver Manila backend config there existed a configuration directive cephfs_volume_path_prefix <https://docs.openstack.org/manila/wallaby/configuration/shared-file-systems…> ; # DEPRECATED: The prefix of the cephfs volume path. (string value) > # This option is deprecated for removal since Wallaby. > # Its value may be silently ignored in the future. > # Reason: This option is not used starting with the Nautilus release > # of Ceph. > #cephfs_volume_path_prefix = /volumes This volume path prefix was usable (and very useful) to set different prefixes in different backends, pointing to different pools in the same backend Ceph cluster e.g. pools backed by storage devices of different characteristics/technology or Ceph CRUSH rule, etc The pool selection would be done in CephFS via the use of file layout fattributes <https://docs.ceph.com/en/quincy/cephfs/file-layouts/>, file layout inheritance ensuring that data created in sub-directories ends up in the correct Ceph pool. e.g. two backends using the same Ceph cluster but two different path prefixes hitting different Ceph pools [cephfsnative1] > driver_handles_share_servers = False > share_backend_name = CEPHFS1 > share_driver = manila.share.drivers.cephfs.driver.CephFSDriver > cephfs_conf_path = /etc/ceph/ceph.conf > cephfs_auth_id = manila > cephfs_cluster_name = ceph > cephfs_volume_path_prefix = /volumes-staging > cephfs_volume_mode = 777 > cephfs_enable_snapshots = False > [cephfsnative1_ec] > driver_handles_share_servers = False > share_backend_name = CEPHFS1_EC > share_driver = manila.share.drivers.cephfs.driver.CephFSDriver > cephfs_conf_path = /etc/ceph/ceph.conf > cephfs_auth_id = manila > cephfs_cluster_name = ceph > cephfs_volume_path_prefix = /volumes-ec-staging > cephfs_volume_mode = 777 > cephfs_enable_snapshots = False However, since Wallaby this config directive looks to have been deprecated and the default of using a path prefix of only /volumes is possible.Trying to use any other prefix in backend configs is ignored. Would anyone on the list know why this option was deprecated in Manila code, or was this forced on Manila by upstream Ceph as of Nautilus? Is there a way to get back to an equivalent functionality? Currently using only a default path of /volumes means we have lost all flexibility in defining Manila CephFS share data placement using the native CephFS driver. Possibly using share group types+share groups and some pre-created paths in the root CephFS could get to something like equivalency? But these paths would need to correspond to the share group UUID, which will only be known after the share group has been created. So not all that flexible a path, since it requires an interaction between users to communicate the share group ID and Ceph admins to set the correct file layout policy. Putting the path prefix in the backend type removed all of that in a nicely transparent way. Having just prototyped this, it will work for setting a desired file layout on a pre-defined share group UUID path in the root CephFS, though it's not really ideal or sustainable to be able to do this for dynamically created share groups by users or automation... Thanks in advance for any advice, Paul Browne

2 1

[neutron] Bug Deputy Report September 11 - 17
by Miro Tomaska 18 Sep '23

18 Sep '23

Hello All, I was the neutron bug deputy last week (Sept 11-17). Here is what is new: High: -https://bugs.launchpad.net/neutron/+bug/2035325 FDB entries grows indefinitely Assigned: Luis Tomas - https://bugs.launchpad.net/neutron/+bug/2035382 "TestMonitorDaemon._run_monitor" failing radomly, initial message not written Assigned: Miro Tomaska - https://bugs.launchpad.net/neutron/+bug/2035578 [stable branches] devstack-tobiko-neutron job Fails with InvocationError('could not find executable python', None) Unassigned - https://bugs.launchpad.net/neutron/+bug/2036118 VM fails to contact metadata during live-migration Assigned: Jakub Libosvar Medium: - https://bugs.launchpad.net/neutron/+bug/2035168 Remaining db migrations for unmaintained Nuage plugin Unassigned - https://bugs.launchpad.net/neutron/+bug/2035281 [ML2/OVN] DGP/Floating IP issue - no flows for chassis gateway port Assigned: Roberto Bartzen Acosta Undecided: - https://bugs.launchpad.net/neutron/+bug/2035230 Port on creation is returned without the fixed_ips field populated - https://bugs.launchpad.net/neutron/+bug/2035573 Insertion of a duplicated ProviderResourceAssociation entry while creating a HA router Asked for more info - https://bugs.launchpad.net/neutron/+bug/2035332 [OVN] VLAN networks for North / South Traffic Broken Best Regards, -- Miro Tomaska Senior Software Engineer

1 0

[ironic] Mass retirement of old branches due to config errs
by Jay Faulkner 18 Sep '23

18 Sep '23

Hi all, Ironic is one of the major offenders remaining in the work to cleanup Zuul config errors. To resolve these issues, it's my plan to retire any impacted branches unless a contributor volunteers to clean them up. I will give folks until at least September 1, 2023, to object before I begin to take action. These branches have been broken for at least one year, and have gotten no patches or releases in that time. It's clear they have little need to continue existing. Please look at https://zuul.opendev.org/t/openstack/config-errors for the full list of potentially impacted branches; I will list here as best I can: openstack/ironic-prometheus-exporter - bugfix/2.1 - stable/train openstack/networking-generic-switch - stable/pike - stable/train - stable/ussuri - stable/victoria - stable/wallaby - stable/xena openstack/python-ironicclient - stable/train - stable/ussuri - stable/victoria - stable/wallaby - stable/xena - Note: stable/yoga is also in the config errors list, but is considered maintained and cannot be retired at this time. I will work to remove failing jobs and get this zuul config fixed manuallt. As an additional note, the following branches were retired months ago, but due to a bug were recreated. They have been fully deleted (again): openstack/ironic-python-agent - bugfix/8.0 openstack/ironic - bugfix/18.0

3 4

[manila] Manila Bugsquash Sep 19th - Sep 21st
by Carlos Silva 18 Sep '23

18 Sep '23

Hello, Zorillas! As agreed in the previous weekly meeting, our bugsquash will run from September 19th to September 21st. The kick off call will be held on Tuesday, Sep 19th at 14:30 UTC using meetpad [1]. We will use the Manila weekly meeting on Thursday at 15 UTC as a checkpoint. If you plan to work on a bug that is not on the list [2], feel free to add it. Looking forward to seeing you there! [1] https://meetpad.opendev.org/manilabobcatbugsquash [2] https://etherpad.opendev.org/p/6VZ5-sbYiSy0hygRZZ6c Regards, carloss

1 0

[cinder] Map Availability Zone to Volume Type
by Jahns, Jay 18 Sep '23

18 Sep '23

Hi, We have a multi-AZ environment where we launch instances with bootable volumes. When we specify AZ, we need to have a specific volume type in that AZ selected to launch to. Right now, the __DEFAULT__ volume type is used. Normally, that would work, since there is 1 backend in each AZ; however, we need to be able to use the key/value RESKEY:availability_zones to pin a volume type to an AZ, so we can use specific key/values in creating the volume. It is 2 separate backends in the environment. I see this bug: https://bugs.launchpad.net/cinder/+bug/1999706 And this change: https://review.opendev.org/c/openstack/cinder/+/868539 Is there anything we can do to help expedite adding this functionality? It seems that it was supposed to already be in. Thanks, Jay

2 1

[neutron] CI meeting on 18.09.2023 cancelled
by Yatin Karel 18 Sep '23

18 Sep '23

Hello Neutron Team !! I will be out tomorrow for a public holiday, so cancelling the CI meeting. Sorry for the short notice. See You at the next meeting on 25th of September. Thanks and Regards Yatin Karel

1 1

[kolla] [ptg] Kolla 2024.1 (Caracal) PTG planning
by Michał Nasiadka 18 Sep '23

18 Sep '23

Hello All, The 2024.1 (Caracal) virtual PTG is approaching and will be held between 23-27 October, 2023. I’ve created a usual etherpad [1] where you can post your topic proposals and we’ll discuss them For dates - we have been usually meeting on two/three days: There were requests on the Bobcat PTG to make these time slots more Europe friendly (e.g. earlier in the day and not finish at 8pm) and host a slot that is Americas/Asia friendly (if needed) - so I associated each day with a Doodle Poll - let’s try to work out best times for most of us. 1. Kolla/Kolla-Ansible topics day 1 - 4 hours Doodle: https://doodle.com/meeting/participate/id/dyXZN9nb 2. Kolla/Kolla-Ansible topics day 2 - 4 hours (including Kolla Operator Hour) Doodle: https://doodle.com/meeting/participate/id/aO8WxqLb 3. Kayobe topics day - 2 hours Doodle: https://doodle.com/meeting/participate/id/e5LmZExd NOTE: If there are participants interested from other timezones that proposed times in the Doodle poll would not fit - please reply to this email and we’ll work out a dedicated slot. Please add your topics timely so they can be arranged as per your preferences, see you at the PTG! [1] https://etherpad.opendev.org/p/kolla-caracal-ptg Thanks, Michal

1 0

[nova] Live migration of a RAM intensive instance failed
by Rafa 18 Sep '23

18 Sep '23

Hello, I have a volume-backed instance with 16 vCPU and 64GB RAM. The instance uses 60GB RAM out of 64GB (used: 22GB; buff/cache 38GB). When I do a live migration of this instance, it fails without any timeouts. It copies almost all the RAM (within 150 - 250 seconds) to the target compute host without any problems according to the logs. Then the instance is paused to copy the rest of the RAM. Everything seems to be working correctly up to this point, but then the instance resumes and the following error message appears: Live Migration failure: operation failed: migration out job: unexpectedly failed: libvirt.libvirtError: operation failed: migration out job: unexpectedly failed Unfortunately, this error message does not say much. It doesn't look like it's due to any timeouts or short downtimes, but I still tested different (higher) values for the following configurations. Unfortunately without success. - live_migration_completion_timeout - live_migration_timeout_action: abort / force_complete (pause) - live_migration_downtime - live_migration_downtime_steps - live_migration_downtime_delay - live_migration_permit_auto_converge: True / False All other instances on the same source and destination hosts can be live migrated without any issues. This instance can also be successfully live migrated after a restart, as it is probably not yet heavily loaded. After a few hours, however, the live migration no longer works. Any ideas what the problem could be? Logs: - nova-compute.log from source compute host: https://paste.openstack.org/show/bJMFxnPKQBEVaPakud61/ - i found this Traceback using journalctrl: https://paste.openstack.org/show/bIS4GFAd2RJ5fHVN9I8d/ - there was also an error in /var/log/libvirt/qemu/: https://paste.openstack.org/show/bImT89IelDcXXBPSgTCO/ Enviroment: - Libvirt: 8.0.0 - QEMU: 4.2.1 - Nova: 25.1.1 - OpenStack: Yoga - Compute operating system: Ubuntu 20.04

4 7

[release] Release countdown for week R-2, Sep 18-22
by Elõd Illés 15 Sep '23

15 Sep '23

Development Focus ----------------- At this point we should have release candidates (RC1 or recent intermediary release) for all the 2023.2 Bobcat deliverables. Teams should be working on any release-critical bugs that would require another RC or intermediary release before the final release. Warning ------- This is a special note to teams about issues regarding oslo.db and castellan deliverables. Please be aware that new releases are about to be sent out. For details, see the mail thread: https://lists.openstack.org/pipermail/openstack-discuss/2023-September/0351… Actions ------- Early in the week, the release team will be proposing stable/2023.2 branch creation for all deliverables that have not branched yet, using the latest available 2023.2 Bobcat release as the branch point. If your team is ready to go for creating that branch, please let us know by leaving a +1 on these patches. If you would like to wait for another release before branching, you can -1 the patch and update it later in the week with the new release you would like to use. By the end of the week the release team will merge those patches though, unless an exception is granted. Once stable/2023.2 branches are created, if a release-critical bug is detected, you will need to fix the issue in the master branch first, then backport the fix to the stable/2023.2 branch before releasing out of the stable/2023.2 branch. After all of the cycle-with-rc projects have branched we will branch devstack, grenade, and the requirements repos. This will effectively open them up for 2024.1 Caracal development, though the focus should still be on finishing up 2023.2 Bobcat until the final release. For projects with translations, watch for any translation patches coming through and merge them quickly. A new release should be produced so that translations are included in the final 2023.2 Bobcat release. Finally, now is a good time to finalize release notes. In particular, consider adding any relevant "prelude" content. Release notes are targeted for the downstream consumers of your project, so it would be great to include any useful information for those that are going to pick up and use or deploy the 2023.2 Bobcat version of your project. Upcoming Deadlines & Dates -------------------------- Final RC deadline: September 28th, 2023 (R-1 week) Final 2023.2 Bobcat release: October 4th, 2023 2024.1 Caracal Virtual PTG - October 23-27, 2023

1 0