From: Shannon Sterz <s.sterz@proxmox.com>
To: pdm-devel@lists.proxmox.com
Subject: [PATCH datacenter-manager] server: location cache: also update cache if a location was removed
Date: Wed, 27 May 2026 17:21:06 +0200 [thread overview]
Message-ID: <20260527152106.436183-1-s.sterz@proxmox.com> (raw)
this removes all locations from the cache if the remote has no
location anymore. otherwise clients may be served inconsitent data
depending on how the max age property is set. showing no location when
max-age is provided with a low value, but the cached location if it
isn't.
note that removing it would leave us in a race with newer writers as
the `set_if_newer_with_timestamp` has no equivalent for remove. so set
`None` in the cache instead for those cases.
also this only affected removing the last (or only) location of a
remote. if the location of a single node in a cluster with other
locations was removed, that worked, because the entry would simply be
dropped in the cached hashmap.
Reported-by: Christoph Heiss <c.heiss@proxmox.com>
Signed-off-by: Shannon Sterz <s.sterz@proxmox.com>
---
server/src/location_cache.rs | 14 ++++++--------
1 file changed, 6 insertions(+), 8 deletions(-)
diff --git a/server/src/location_cache.rs b/server/src/location_cache.rs
index bf73f36..9fe514b 100644
--- a/server/src/location_cache.rs
+++ b/server/src/location_cache.rs
@@ -39,20 +39,17 @@ pub async fn get_location_info_for_remote(
get_cached_location_info(&remote.id, u64::MAX).await?
}
};
- let info = match location_info {
- Some(info) => info,
- None => return Ok(None),
- };
+
let now = proxmox_time::epoch_i64();
if let Some(existing_state) =
- update_cached_location_info(&remote.id, info.clone(), now).await?
+ update_cached_location_info(&remote.id, location_info.clone(), now).await?
{
// Somebody else updated the cache while we performed the API request,
// return the more recent data instead of the data we just fetched.
return Ok(Some(existing_state));
}
- Ok(Some(info))
+ Ok(location_info)
}
}
@@ -76,14 +73,15 @@ async fn get_cached_location_info(
async fn update_cached_location_info(
remote: &str,
- info: CachedLocationInfo,
+ info: Option<CachedLocationInfo>,
now: i64,
) -> Result<Option<CachedLocationInfo>, Error> {
let cache = api_cache::write_remote(remote).await?;
Ok(cache
.set_if_newer_with_timestamp(LOCATION_STATE_CACHE_KEY, info, now)
- .await?)
+ .await?
+ .flatten())
}
/// Parse a PVE location property string (from the datacenter or a node config) into our [Location].
--
2.47.3
next reply other threads:[~2026-05-27 15:21 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-27 15:21 Shannon Sterz [this message]
2026-05-27 16:01 ` applied: [PATCH datacenter-manager] server: location cache: also update cache if a location was removed Thomas Lamprecht
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260527152106.436183-1-s.sterz@proxmox.com \
--to=s.sterz@proxmox.com \
--cc=pdm-devel@lists.proxmox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.