This allows specifying multiple IDs in grants via an `ids` field, which
will eventually become the normal way to specify IDs. Internally, each
grant with multiple IDs turns into multiple ACL grants each with a
single ID; to make this distinction clearer and allow for better
separation of concerns an AclGrant type has been introduced, so really
multiple IDs in a Grant turn into multiple AclGrants.
The nice thing about doing it this way is that it becomes purely a
parsing concern; no actual validation logic has changed.
For backwards compatibility with grants already stored in roles, we do
not error out if `id` is specified. However, eventually we will simply
not support grants with `id` coming via the API; they will fail API
validation, such that new grants will require the use of the updated
`ids` field.
A follow-on PR will plumb this through the service handlers/API/CLI, but
I decided to do it in separate chunks to make reviewing easier, given
that they are easily separable into the internal and external aspects of
the change.
* Add CLI/API checks around using ID in grants (#3264)
* Plumb through some contexts to remove a lot of deprecated errors (#3268)
When using the json output of the cli (`-format=json`), a successful
call to the controller API would place the HTTP status code in the JSON
as `status_code`. However, if there was an error from the API the status
code would be placed in the JSON as `status`. In order to be consistent,
this adds a `status_code` field to the error response case. For
backwards compatibility it still populates `status` in the error case.
This inconsistency was missed partially due to a bug in the CLI tests.
The assertion on status code was not valid and would always be
successful. Thus this also fixes the assertions and tests.
This ensures that checks for features should work, and bails early if
that is not the case, since if this fails the binary is essentially
broken. This also simplifies code that performs these checks, ie instead
of:
binaryVersion, err := version.GetReleaseVersion()
if err != nil {
// handle error? panic?
}
if version.SupportsFeature(binaryVersion, version.FeatureA) {
// code for FeatureA
} else {
// without FeatureA
}
Implementations can do:
if version.SupportsFeature(version.Binary, version.FeatureA) {
// code for FeatureA
} else {
// without FeatureA
}
Jeff Mitchell
Todd
Damian Debkowski
Timothy Messier
Johan Brandhorst-Satzkorn
Irena Rindos