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
}
* Onboard boundary to use new .release/VERSION file and reproducible actions-go-build
* Added automatic patch version bumps to end of release pipeline
* Added back VersionMetadata to internal directory
* Moved VERSION file to version/
* Update to current version
* Using prepare workflow for pre-stable channel workflow
* Test prepare workflow
* PR feedback: allow builds to run builds locally without setting BIN_PATH
* PR feedback: revert Enos changes
* PR Feedback
* Remove current branch from ci pipeline
* Run make fmt
Since client code uses the package name as a prefix when referring to
the package contents, the names for those contents need not repeat the
package name.
- Rename base.BaseCommand to base.Command
- Rename base.BaseServer to base.Server
- Rename config.DevConfig() to config.Dev()
- Rename config.LoadConfigFile() to config.LoadFile()
- Rename config.NewConfig() to config.New()
- Rename config.ParseConfig() to config.Parse()
- Rename controller.ControllerCommand to controller.Command
- Rename controller.NewController() to controller.New()
- Rename dev.DevCommand to dev.Command
- Rename listener.ListenerFactory to listener.Factory
- Rename listener.NewListener() to listener.New()
- Rename version.GetVersion() to version.Get()
- Rename version.VersionInfo to version.Info
See:
- https://golang.org/doc/effective_go.html#package-names
- https://blog.golang.org/package-names#TOC_3.
- https://github.com/golang/go/wiki/CodeReviewComments#package-names
irenarindos
Jeff Mitchell
Timothy Messier
Jim
Irena Rindos
Damian Debkowski
Todd
Michele Degges
Johan Brandhorst-Satzkorn
emily neil
Louis Ruch
Danielle Miu
Sam Salisbury
Michael Gaffney