Friday, 2025-12-19

opendevreviewAndrew Bonney proposed openstack/openstack-ansible-ops master: Add backup capability to Cluster API setup  https://review.opendev.org/c/openstack/openstack-ansible-ops/+/97151108:05
damiandabrowskiHey! noonedeadpunk jrosser I think we're ready for next round of reviews in https://review.opendev.org/q/topic:%22osa_hashi_vault%22+and+status:open 09:40
damiandabrowskiI changed few things which were discussed some time ago:09:40
damiandabrowski- changed default pki paths(pki/ -> pki_root), `pki_int/` stays as is09:40
damiandabrowski- renamed `vault_root_ca_path` in hashi_vault backend to `signed_by`, to share the same var with standalone backend09:40
damiandabrowski- improved docs, added some diagram explaining how pki paths work and where certificates are stored09:40
damiandabrowski- removed `openstack_pki_san` definition from integrated repo09:41
damiandabrowski- added task for hashi_vault backend which ensures that python3-hvac is installed on `pki_setup_host`09:41
f0oMorning; What's the reason for RabbitMQ mgmt's UI being always enabled and seemingly no easy way to disable it? Is it used for something internally? reason I ask is because our Rabbit is very busy churning through internal metrics/stats (channel_queue_exchange_metrics_metrics and queue_metrics_metrics_collector according to `rabbitmq-diagnostics observer`) and I'd like to10:59
f0oeither limit those or straight up disable them if they're unused10:59
noonedeadpunkI think you can disable it, right? https://opendev.org/openstack/openstack-ansible-rabbitmq_server/src/branch/master/defaults/main.yml#L100-L10211:08
f0onoonedeadpunk: yeah usually there's an easy switch for things to en/disable but for management there's your linked rabbitmq_plugins, plus rabbitmq_management_* which suggest it's always sorta enabled, plus group-vars that always configure HAProxy11:10
noonedeadpunkI'm not sure if it's in fact used by anything internal....11:10
noonedeadpunkbut it is in case you're using rabbitmqadmin tool11:10
f0othat's why I wonder, it seems so "expected to be always available"11:10
f0ojust by the way it is configured regardless11:11
f0oI dont want to nuke my rabbit haha11:11
noonedeadpunkHm, I thought that if you don't enable the plugin - you can have it in config, just with no effect11:11
noonedeadpunkBut I never tried that tbh11:11
f0o_Oo11:16
f0o_how does Cinder instruct Nova to mount an NFS share? I have some discrepancy between the nfs_mount_options supplied in cinder.conf and the effective mount options used on the compute nodes14:17
noonedeadpunkthrough the api call14:18
noonedeadpunkthere are some helper methods which do that14:19
f0o_I have "rw,nolock,nconnect=8,hard,tcp,rsize=1048576,wsize=1048576,timeo=1200,actimeo=120,noatime,nodiratime" specified but `/proc/mounts` return "rw,relatime,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,local_lock=none" - the big differences are `relatime` instead of the wanted `noatime` as well as different `timeo` settings and the14:19
f0o_absence of `nconnect`14:19
f0o_so I wonder if those settings are simply 'stripped'/sanitized from the options somewhere and then the kernel goes ahead and assumes defaults14:19
noonedeadpunkeh, I can't recall these bits now unfortunatelly :(14:19
f0o_guess I'll check the cinder driver? :D14:20
noonedeadpunk um, I think it's not in the driver itself....14:22
noonedeadpunkI guess I'd check Nova API which is called during the mount... 14:23
noonedeadpunkBut in case of NFS it might be, that Nova just do the mount with default options, and indeed cinder does not pass them at all14:23
noonedeadpunkAs it's passing basically the storage "object" and Nova figures out what to do with it in it's own14:24
noonedeadpunkSo I'd be looking at nova to begin with14:24
f0o_ok, I just started with os_brick/remotefs object. Hoping it had sometihng to do with it. Maybe I find it in nova again14:24
f0o_https://github.com/openstack/nova/blob/4b71dab239b4f82d50297ec5bd887c207b43b7ea/nova/virt/libvirt/volume/nfs.py#L41 down the rabbithole I go!14:27
f0o_I think I found it14:36
f0o_cinder.volume_attachment SQL table, has connection_info field that describes the NFS mount, however the `options` field of that is set to `null` which means https://github.com/openstack/nova/blob/4b71dab239b4f82d50297ec5bd887c207b43b7ea/nova/virt/libvirt/volume/nfs.py#L46 is null and thus kernel defaults are taken14:38
f0o_This should be a bug right?14:38
noonedeadpunkf0o_: yes, I think that should be it :)14:44
f0o_why do I find these things on friday afternoons? I seem to have some weird track record about this by now (:14:49
f0o_but I have found something odd https://github.com/openstack/cinder/blob/master/cinder/volume/drivers/remotefs.py#L9914:50
f0o_so nfs_mount_options is only for cinder-volume to mount the share; nas_mount_options is being loaded into the shares object14:51
f0o_https://github.com/openstack/cinder/blob/master/cinder/volume/drivers/nfs.py#L149-L150 << this shares object is what goes into the options of connections14:51
f0o_(ref where nas_mount_options is loaded instead of nfs_mount_options: https://github.com/openstack/cinder/blob/master/cinder/volume/drivers/remotefs.py#L595 )14:52
f0o_nas_mount_options also replaces nfs_mount_options if found in https://github.com/openstack/cinder/blob/master/cinder/volume/drivers/nfs.py#L107-L11514:53
f0o_https://codesearch.opendev.org/?q=nas_mount_options << nas_mount_options has no documentation14:54
f0o_but TLDR; I should use nas_mount_options and not nfs_mount_options14:54
f0o_or rather safest way would be to define both nas_ and nfs_ versions. Because it does just feel like nas_ is a leftover considering the onyl reference I found is a ML entry from 201715:07
f0o_nope that didnt do it either15:45
noonedeadpunkI don;t think this part responsible for mounts on compute hosts15:47
noonedeadpunkit's only for cinder-vo,.lume part afaik15:47
noonedeadpunkand indeed nas_mount_options looks kinda redundant and nfs_mount_options should be enough, imo15:47
f0o_well both nas_ and nfs_ options still yield `null` in the SQL' connection_info option field15:59
f0o_really hoped that would be it15:59
f0o_I can always just go nuclear and set libvirt.nfs_mount_options in nova15:59
f0o_but that seems... wrong...15:59
f0o_https://github.com/openstack/nova/blob/4b71dab239b4f82d50297ec5bd887c207b43b7ea/nova/virt/libvirt/volume/nfs.py#L41-L50 << Something I do not udnerstand here. The libvirt check adds the -o flag for the options. The connection_info block does not. So would that even work? Which one is correct?16:01
f0o_I've wrote my findings into #openstack-cinder since I found a 3rd way of defining mount options16:13
noonedeadpunkwell, cinder does not and will not do any mounts on compute nodes, unless cinder-volume is installed there16:14
f0o_right but that's what the connection_info field in volume_attachments is for right? to instruct nova on how to consume the volume16:14
noonedeadpunkbut the possible conflict of options...16:14
noonedeadpunkI think current subset is kind of systemd default tbh16:15
noonedeadpunkum16:15
noonedeadpunkSo nova uses it's own volume attachments table, which is stored in cell database16:15
noonedeadpunkAnd data between is passed only via api calls16:16
f0o_why do you hate me?16:16
noonedeadpunknova can not look for info in cinder database16:16
f0o_gues I'll make a coffe and go digging into nova's attachment db16:16
noonedeadpunkAnd eventually these tables are expected to be in sync between cinder and novca16:16
f0o_because I know libvirt nfs driver thingy looks for `options` field in a json in a connection_info object that looks virtually identical to the one I found in volume_attachment at cinder16:17
noonedeadpunkyou should check connection_info inside of the block_device_mapping in the nova database16:18
noonedeadpunkit is likely simmilar, but not necessarily identical16:19
f0o_FIrst Win: I ahve no a populated options field in cinder's volume_attachment table. My nfs_shares are now `share: "/foo/bar -o opts"` in openstack_user_config16:21
f0o_now*16:21
f0o_ok the same options are also in nova.block_device_mappings - they were previously null as well16:21
f0o_so it seems https://github.com/openstack/cinder/blob/master/cinder/volume/drivers/remotefs.py#L601-L604 is the correct way and nas/nfs_mount_options are bogus16:22
f0o_as a bonus headscratcher I noticed that all my OS drives are RAW while all ephemeral are QCOW - https://github.com/openstack/cinder/blob/master/cinder/volume/drivers/remotefs.py#L530 that explains it, all images are always RAW regardless of disktype16:28
f0o_anyway beer o'clock; noonedeadpunk if you havent tried yet go to systembolaget and grab that "Stark Julmust". It's Julmust but with 4.5%!16:29
noonedeadpunkeh, well, systembolagets are like 3h flight from my place of residence :D16:33
* noonedeadpunk resides in Croatia so far16:34
f0o_hope you got better weather than we got here right now16:34
f0o_for some reason I thought you were in Sweden, huh16:34
* noonedeadpunk had +16 outside today and had a very comfy walk in t-shirt and sun shining whole day16:34
f0o_must be nice :D16:35
f0o_just shitty rain here16:35
noonedeadpunkI have a contract with Swedish org, so travel there from time to time:)16:35
f0o_aaah16:35
f0o_well next time you're around stockholm by any chance let me know and I'll pay for some beers16:36
noonedeadpunkah, well, never been there (except single transfer in airport), so good reason to stop by :D16:40
* noonedeadpunk goes and grabs some beers as well16:41
opendevreviewMerged openstack/openstack-ansible-os_tempest master: Fix(tempest): Register tempest_router_details to resolve undefined variable _add_router  https://review.opendev.org/c/openstack/openstack-ansible-os_tempest/+/97036022:18
opendevreviewMerged openstack/openstack-ansible-plugins master: Check for a supported Operating System - add information about AlmaLinux  https://review.opendev.org/c/openstack/openstack-ansible-plugins/+/96912522:30
opendevreviewMerged openstack/openstack-ansible-plugins master: Remove Create ganesha log dir  https://review.opendev.org/c/openstack/openstack-ansible-plugins/+/97070322:41

Generated by irclog2html.py 4.0.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!