From: Leo Nunner <l.nunner@proxmox.com>
To: Wolfgang Bumiller <w.bumiller@proxmox.com>
Cc: pve-devel@lists.proxmox.com
Subject: Re: [pve-devel] [PATCH firewall] fix #4204: automatically update usages of group when it is renamed
Date: Tue, 27 Sep 2022 12:13:30 +0200 [thread overview]
Message-ID: <315b33bc-d3cb-cdc8-ca6a-2cdb5678749d@proxmox.com> (raw)
In-Reply-To: <20220927095944.wsyvolsajbrajnhh@casey.proxmox.com>
On 9/27/22 11:59, Wolfgang Bumiller wrote:
> On Tue, Sep 27, 2022 at 11:28:26AM +0200, Leo Nunner wrote:
>> On 9/27/22 10:46, Wolfgang Bumiller wrote:
>>> On Mon, Sep 26, 2022 at 11:45:07AM +0200, Leo Nunner wrote:
>>>> + $cluster_conf->{groups}->{$param->{group}} = $cluster_conf->{groups}->{$param->{rename}};
>>>> + $cluster_conf->{group_comments}->{$param->{group}} = $cluster_conf->{group_comments}->{$param->{rename}};
>>>> +
>>>> + # Update comment if provided
>>>> $cluster_conf->{group_comments}->{$param->{group}} = $param->{comment} if defined($param->{comment});
>>>> +
>>> At this point you'd need to also store the cluster fw config, because
>>> *reading* the configs isn't necessarily done with a lock on the cluster
>>> config, and you don't want to race against readers seeing the new group
>>> being referred to without actually having the it in the config.
>>>
>>> You'll still be racing against clients having read the cluster config
>>> while you're *here* and then reading their host config *after* you've
>>> updated it...
>> Is there actually a way around this? Unless we use something like inotify,
>> there'll be no way for them to actually know about the new group if they've
>> read the cluster config before I updated it.
> Well, not yet, and we'd need to distinguish between the race and the
> group *actually* not existing.
> Currently it'll produce a warning in the log which we might consider to
> be "good enough".
> We *could* try to remember which groups were missing in the previous run
> and assume new missing groups are part of a race, but I'm not sure it's
> worth it. Though syncing up would be simple enough as we only need to
> lock/unlock the cluster fw config once.
Would this still be in the scope of this patch or should we just
leave it like this for now?
next prev parent reply other threads:[~2022-09-27 10:13 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-09-26 9:45 Leo Nunner
2022-09-27 8:46 ` Wolfgang Bumiller
2022-09-27 9:28 ` Leo Nunner
2022-09-27 9:59 ` Wolfgang Bumiller
2022-09-27 10:13 ` Leo Nunner [this message]
2022-09-27 10:17 ` Wolfgang Bumiller
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=315b33bc-d3cb-cdc8-ca6a-2cdb5678749d@proxmox.com \
--to=l.nunner@proxmox.com \
--cc=pve-devel@lists.proxmox.com \
--cc=w.bumiller@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox