fix: accept day suffix in validityDuration as documented#394
Conversation
The API documents validityDuration as a human-readable duration like "100d12h", and the samples use "365d", but parseValidityDuration delegated directly to time.ParseDuration which rejects the "d" unit, so reconciliation failed with 'failed to parse ValidityDuration: time: unknown unit "d" in duration "365d"'. Expand a leading day segment to hours before parsing. Signed-off-by: Xavier Lange <xrlange@gmail.com>
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: xrl The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
|
Hi @xrl. Thanks for your PR. I'm waiting for a etcd-io member to verify that this patch is reasonable to test. If it is, they should reply with Regular contributors should join the org to skip this step. Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. DetailsInstructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. |
Setting
validityDurationto the documented day format (e.g.365d, used by both TLS samples in config/samples) makes reconciliation fail permanently withfailed to parse ValidityDuration: time: unknown unit "d" in duration "365d", becauseparseValidityDurationdelegates directly totime.ParseDuration, which does not support thedunit the API doc promises (100d12h). This change expands a leading day segment to hours before parsing, leaving plain Go durations and the empty-string default untouched. Adds table-driven tests forparseValidityDurationcovering day-suffix, mixed, plain, default, and invalid inputs.