nit: Maybe we could still leave these consts and then use them directly in cerrdefs.ErrInvalidArgument.WithMessage(...)?

Also, what's wrong with having validationError?

Ah, right;

nit: Maybe we could still leave these consts and then use them directly in

I was originally considering keeping them as consts, but my main train of thought here was that they are not "special". Un-exporting them would be an option, but from this file (and some other places I've seen), it quickly led to "to return an error, it must be defined first!"), sometimes after that resulting in exporting those errors, and now it all becomes tightly coupled and a "contract".

I'm not "sold" on all of these errors, so putting them inline makes it more clear "just an error message; not a contract; change if needed".

Also, what's wrong with having validationError?

That's a good one, and I went back-and-forth a bit; I initially kept the type, then considered making it a function that wraps the containerd types;

func validationError(msg string) error {
    return cerrdefs.ErrInvalidArgument.WithMessage(msg)
}

But then thought; maybe we just need to get used to using cerrdefs, so perhaps better to remove that helper; I'd be fine putting that one back though if that was what you meant.

Yeah 100% on unexporting them! The only thing that I like about the current approach is that there is a centralized place for them to look at. But then as you've said:

putting them inline makes it more clear "just an error message; not a contract; change if needed".

so I'm okay with your change 👍🏻

func validationError(msg string) error {
    return cerrdefs.ErrInvalidArgument.WithMessage(msg)
}

Yep that helper would avoid a lot of unneeded repetition and also makes it really easy to see that all of these are InvalidArgument.
OTOH, when writing new code here, one would probably forget about this helper anyway, and would lead to inconsistent usage later, so maybe indeed it's better to just use the cerrdefs directly..

Yeah 100% on unexporting them! The only thing that I like about the current approach is that there is a centralized place for them to look at. But then as you've said:

putting them inline makes it more clear "just an error message; not a contract; change if needed".

so I'm okay with your change 👍🏻

func validationError(msg string) error {
    return cerrdefs.ErrInvalidArgument.WithMessage(msg)
}

Yep that helper would avoid a lot of unneeded repetition and also makes it really easy to see that all of these are InvalidArgument.
OTOH, when writing new code here, one would probably forget about this helper anyway, and would lead to inconsistent usage later, so maybe indeed it's better to just use the cerrdefs directly..