Now we can emit comments which stick to functions instead of coming
before or after the functions when emitting code.
For followup: I think we can simplify FunctionGen and ValidationGen
* typedefs to pointers
* pointers to pointers
* pointers to lists
* pointers to maps
* fixed-size arrays
* lists of pointers
* lists of lists
* lists of maps
* maps with non-string keys
* maps of pointers
* maps of lists
* maps of maps
- Introduce CoveredByDeclarative field to Error struct
- Add MarkCoveredByDeclarative method for Error and ErrorList
- Implement ExtractDeclarative method to filter out declaratively covered errors
- Update error constructors to include the new field
- Add corresponding test cases for new declarative validation functionality
(when passed a feature that is not Default)
This allows using the regex filter to skip tests that do not work on a cluster
without optional configuration, while moving tests to use WithFeatureGate
without also setting WithFeature unless they have some additional configuration
required.
Co-authored-by: Patrick Ohly <patrick.ohly@intel.com>
I discovered this by changing the validation in a way that SHOULD fail
(by allowing something it should not). But it didn't. A different
error happens which totally masks the non-failure I expected. New test
is much more explicit about what failures are expected.
This does not focus on adding test coverage, just making sure the test
is not terrible.
This adds dedicated integration tests for the feature to the general
test/integration/dra for the API and some minimal testing with the scheduler.
It also adds non-performance test cases for scheduler_perf because that is a
better place for running through the complete flow (for example, can reuse
infrastructure for setting up nodes).
If kube-apiservers run at a different version (during upgrades) and
each has different opinion on what the `extension-apiserver-authentication`
config map should look like, they would start dueling with config map
writes.
This commit removes handling of the update events of the target CM
in order to reduce the amount of such dueling to once a minute, as
the controller is guaranteed to run at least once a minute anyway.
The idea is that a cluster state with two different versions of
kube-apiserver should never be permanent, and so a reduced amount of
dueling for that period is tolerable.
For the most part, JSON is a subset of YAML. This might lead one to
think that we should ALWAYS use YAML processing. Unfortunately a JSON
"stream" (as defined by Go's encoding/json and many other places, though
not the JSON spec) is a series of JSON objects. E.g. This:
```
{}{}{}
```
...is a valid JSON stream.
YAML does NOT accept that, insisting on `---` on a new line between YAML
documents.
Before this commit, YAMLOrJSONDecoder tries to detect if the input is
JSON by looking at the first few characters for "{". Unfortunately,
some perfectly valid YAML also tastes like that.
After this commit, YAMLOrJSONDecoder will detect a failure to parse as
JSON and instead flip to YAML parsing. This should handle the ambiguous
YAML.
Once we flip to YAML we never flip back, and once we detect a JSON
stream (as defined above) we lose the ability to flip to YAML. A
multi-document is either all JSON or all YAML, even if we use the JSON
parser to decode the first object (because JSON is YAML for a single
object).
