public inbox for pbs-devel@lists.proxmox.com
 help / color / mirror / Atom feed
From: Thomas Lamprecht <t.lamprecht@proxmox.com>
To: Proxmox Backup Server development discussion
	<pbs-devel@lists.proxmox.com>, Dylan Whyte <d.whyte@proxmox.com>,
	Hannes Laimer <h.laimer@proxmox.com>
Subject: Re: [pbs-devel] [PATCH proxmox-backup v9 1/6] api-types: add maintenance type
Date: Mon, 11 Apr 2022 09:33:04 +0200	[thread overview]
Message-ID: <78a07a72-c23c-496e-894a-8a838d70059b@proxmox.com> (raw)
In-Reply-To: <81a44a2f-4b21-0b78-ef69-071ad7cf2a19@proxmox.com>

On 06.04.22 15:08, Dylan Whyte wrote:
>> +pub const MAINTENANCE_MESSAGE_SCHEMA: Schema =
>> +    StringSchema::new("Message describing the reason for the maintenance.")
>> +        .format(&MAINTENANCE_MESSAGE_FORMAT)
>> +        .max_length(32)
>> +        .schema();
> Is 32 characters enough for the message? I would think this is somewhat limiting, but am open to other opinions.

The idea is to start more limited, as opening those up once there's real world
requests for legitimate reasons is easy, but we cannot really easily reduce the
allowed length ever without breaking older systems.

Naturally starting out with a overly strict limit is not much of use either, note
that 32 characters is not /that/ strict, infos like "zfs pool disk maintenance"
(26 chars) fit there easily, but yes it may be limitting for more detailed infos.

Maybe we could settle for 64 now, that would allow a info message like:
"zfs pool disk replacement undergoing until 2022-04-11T10:00Z" (61 chars), which
is IMO an OK upper limit of what people can be enforced to condense the relevant
info bits into without being required to play "text golf".




  reply	other threads:[~2022-04-11  7:33 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-17 17:14 [pbs-devel] [PATCH proxmox-backup v9 0/6] closes #3071: maintenance mode for datastore Hannes Laimer
2022-02-17 17:14 ` [pbs-devel] [PATCH proxmox-backup v9 1/6] api-types: add maintenance type Hannes Laimer
2022-04-06 13:08   ` Dylan Whyte
2022-04-11  7:33     ` Thomas Lamprecht [this message]
2022-02-17 17:14 ` [pbs-devel] [PATCH proxmox-backup v9 2/6] datastore: add check for maintenance in lookup Hannes Laimer
2022-04-06 13:08   ` Dylan Whyte
2022-02-17 17:14 ` [pbs-devel] [PATCH proxmox-backup v9 3/6] pbs-datastore: add active operations tracking Hannes Laimer
2022-02-17 17:14 ` [pbs-devel] [PATCH proxmox-backup v9 4/6] api: make maintenance_type updatable Hannes Laimer
2022-02-17 17:14 ` [pbs-devel] [PATCH proxmox-backup v9 5/6] api: add get_active_operations endpoint Hannes Laimer
2022-02-17 17:14 ` [pbs-devel] [PATCH proxmox-backup v9 6/6] ui: add option to change the maintenance type Hannes Laimer
2022-04-06 13:08 ` [pbs-devel] [PATCH proxmox-backup v9 0/6] closes #3071: maintenance mode for datastore Dylan Whyte
2022-04-11  7:35   ` 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=78a07a72-c23c-496e-894a-8a838d70059b@proxmox.com \
    --to=t.lamprecht@proxmox.com \
    --cc=d.whyte@proxmox.com \
    --cc=h.laimer@proxmox.com \
    --cc=pbs-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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Service provided by Proxmox Server Solutions GmbH | Privacy | Legal