We currently have two redundant ways to test for breaking changes in
proto: proto-commit and releaselocks. These do the same thing, but add
substantial noise.
Release locks have also not been updated since 1.6.
The original intent was to test for breaking changes between versions.
However, since we test for breaking changes on each commit, there is no
need for the extra check; if it would have failed as "breaking change
from 1.0 -> HEAD" then it would also fail with "breaking change from
HEAD^ -> HEAD".
Finally, there are some weird LC_ALL issues with sorting that make the
releaselocks really hard to use, especially for newcomers. I spent hours
trying to fix it without success
* operator: use camelCase
operator relies on merging using K8s libraries. K8s libraries use the
`json` tag. protobuf doesn't have a way to configure this (`json_tag` is
for `protobuf.json`, not `json`) and never will.
JSON tag comes from the protobuf name. So we can make it camelCase to
fix the above issue. This will have no impact on unmarshalling with jsonpb -- which we use in
all cases aside from the merging -- any casing is allowed.
This may be a breaking change in the protobuf sense (but NOT to Istio
users), but it doesn't really matter as until last week the operator
protobuf was not a real protobuf at all and relied on `sed` to make it
into the shape we want. Therefor, its not possible someone depended on
the operator protobuf being protobuf-compatible.
* add comment
* gen
* extra line
* comment
* gen
Switching the default zero value to UNSPECIFIED. This allows us
to better detect when the user has set a value for the enum. If
the user previously specified ROUND_ROBIN, it will still be
handled properly, but will be assigned a new enum value.
In addition, the value LEAST_CONN is now deprecated in favor of
a new value LEAST_REQUEST. It was previously poorly named and
only remains for backward compatibility.
There is a chance that this change could break existing tools
if they rely on binary marshaling/unmarshaling of the proto.
There are currently no tools within Istio that do this,
however.
Pulls in update from common files. A bunch of files we don't use were
removed. For some reason the locking mechanism is asserting stuff in
common-protos when it probably shouldn't. I can look into this, but for
now just updated the locks.
Every other API is named `<kind in snake case>.proto`, but authz. It is
named authorization.policy. This impacts the generated code. For
consistency, renaming it to match all of our other APIs
* Consolidate opeator API to one file to maintain field order
* Mirror Tolerations
* Remove json gen
* Rebuild
* Restore deepcopy
* Remove unneeded sed
* Rebuild
* Lint
* Update releaselocks
* Move deepcopy from autogenerated path
* Copyright banner
* Gofmt
* Change proxyConfig.concurrency to wrapper
This allows distinguishing between 0 and undefined. See
https://github.com/istio/istio/issues/23470 for motivation
* update locks
* Make operator.meshConfig an interface type
Otherwise we lose information as the round trip of json -> meshconfig ->
json is lossy. See https://github.com/istio/istio/issues/22948 for more
information
* fix protolock
* Add shell
* release lock
* test
* Add UNSPECIFIED option for ingress mode
Otherwise, its impossible to tell if something is set or if its OFF,
meaning we cannot change the default. This blocks
https://github.com/istio/istio/pull/22326
I am not sure if this is something that is legal to change though...
* Fix locks
* Move locality load balancer settings to destination rule and use it in config.
* Add proto generated files with protolock
* Update based on proto run.
* Fix conventions
* Additional changes after generation
* Update the protolock status files.
* Add locality load balancer settings under port traffic policy
* Moved locality load balancer settings under load balancer settings.
* Remove extra lines added.
* Update after make gen.
* Test for incompatible changes against existing releases.
Add Makefile target to test curent protos against proto.lock files
from previous releases.
* Review comments.
John Howard