Automatic merge from submit-queue
openstack: Support config-drive and improve CurrentNodeName, GetZone
This PR adds support for fetching local instance metadata via config-drive (as well as querying metadata service), and surfaces some additional metadata information (from either source):
- `CurrentNodeName` now returns the OpenStack instance name, rather than the current hostname (they might not be the same)
- `GetZone` includes availability zone label in `FailureDomain`
Thanks to @kiall for a WIP implementation of the latter.
Automatic merge from submit-queue
hack: update cherry-pick script to show subject when patch is split
<!-- Thanks for sending a pull request! Here are some tips for you:
1. If this is your first time, read our contributor guidelines https://github.com/kubernetes/kubernetes/blob/master/CONTRIBUTING.md and developer guide https://github.com/kubernetes/kubernetes/blob/master/docs/devel/development.md
2. If you want *faster* PR reviews, read how: https://github.com/kubernetes/kubernetes/blob/master/docs/devel/faster_reviews.md
3. Follow the instructions for writing a release note: https://github.com/kubernetes/kubernetes/blob/master/docs/devel/pull-requests.md#release-notes
-->
**What this PR does / why we need it**:
This is a continuation of #34049, which worked, but then I realized some patch files have more than one subject, see example: https://github.com/kubernetes/kubernetes/pull/34228
This cleans the output so it looks like this:
```
Automated cherry pick of #32593
Cherry pick of #32593 on release-1.4.
#32593: Fix audit_test regex for iso8601 timestamps
```
pretty!!!
**Which issue this PR fixes** *(optional, in `fixes #<issue number>(, #<issue_number>, ...)` format, will close that issue when PR gets merged)*: fixes #
**Special notes for your reviewer**:
**Release note**:
<!-- Steps to write your release note:
1. Use the release-note-* labels to set the release note state (if you have access)
2. Enter your extended release note in the below block; leaving it blank means using the PR title as the release note. If no release note is required, just write `NONE`.
-->
Signed-off-by: Jess Frazelle <acidburn@google.com>
Automatic merge from submit-queue
Use nodeutil.GetHostIP consistently when talking to nodes
Most of our communications from apiserver -> nodes used
nodutil.GetNodeHostIP, but a few places didn't - and this meant that the
node name needed to be resolvable _and_ we needed to populate valid IP
addresses.
```release-note
The apiserver now uses addresses reported by the kubelet in the Node object's status for apiserver->kubelet communications, rather than the name of the Node object. The address type used defaults to `InternalIP`, `ExternalIP`, and `LegacyHostIP` address types, in that order.
```
Automatic merge from submit-queue
Federated deployment controller - part 1
Based on federated replicaset controller (copy + find/replace).
Remaining stuff:
- refacing out common elements to libs
- using owerref in pod analysis
- e2e tests
- renaming concurrency flag for rs and reusing it in deployment
- updating only one cluster at a time if rollingupdate strategy is used.
cc: @quinton-hoole @kubernetes/sig-cluster-federation
**Release note**:
```release-note
Federated deployment controller that supports the same api as the regular kubernetes deployment controller.
```
Automatic merge from submit-queue
hack/e2e.go: listen for Interrupt signal and attempt cleanup if run with --down
<!-- Thanks for sending a pull request! Here are some tips for you:
1. If this is your first time, read our contributor guidelines https://github.com/kubernetes/kubernetes/blob/master/CONTRIBUTING.md and developer guide https://github.com/kubernetes/kubernetes/blob/master/docs/devel/development.md
2. If you want *faster* PR reviews, read how: https://github.com/kubernetes/kubernetes/blob/master/docs/devel/faster_reviews.md
3. Follow the instructions for writing a release note: https://github.com/kubernetes/kubernetes/blob/master/docs/devel/pull-requests.md#release-notes
-->
**What this PR does / why we need it**: adds a listener on ^C, so if `hack/e2e.go` is run with `--down` and the user ^C, then it will attempt to cleanup the resources.
**Which issue this PR fixes** *(optional, in `fixes #<issue number>(, #<issue_number>, ...)` format, will close that issue when PR gets merged)*: fixes #
**Special notes for your reviewer**:
**Release note**:
<!-- Steps to write your release note:
1. Use the release-note-* labels to set the release note state (if you have access)
2. Enter your extended release note in the below block; leaving it blank means using the PR title as the release note. If no release note is required, just write `NONE`.
-->
```release-note
NONE
```
Signed-off-by: Jess Frazelle <me@jessfraz.com>
Automatic merge from submit-queue
refactor controller as posthook when configured and enabled
builds on https://github.com/kubernetes/kubernetes/pull/33785 .
Models the bootstrap controller as a PostHook which is added when its API group is available and its configured.
@liggitt Stefan is out for a while.
Automatic merge from submit-queue
Match GroupVersionKind against specific version
Currently when multiple GVK match a specific kind in `KindForGroupVersionKinds` only the first will be matched, which not necessarily will be the correct one. I'm proposing to extend this to pick the best match, instead.
Here's my problematic use-case, of course it involves ScheduledJobs 😉:
I have a `GroupVersions` with `batch/v1` and `batch/v2alpha1` in that order. I'm calling `KindForGroupVersionKinds` with kind `batch/v2alpha1 ScheduledJob` and that currently results this matching first `GroupVersion`, instead of picking more concrete one. There's a [clear description](ee77d4e6ca/pkg/api/unversioned/group_version.go (L183)) why it is on single `GroupVersion`, but `GroupVersions` should pick this more carefully.
@deads2k this is your baby, wdyt?
Automatic merge from submit-queue
[Part 1] Implementation of equivalence pod
Part 1 of #30844
This PR:
- Refactored `predicate.go`, so that `GetResourceRequest` can be used in other places to `GetEquivalencePod`.
- Implement a `equivalence_cache.go` to deal with all information we need to calculate an equivalent pod.
- Define and register a `RegisterGetEquivalencePodFunction `.
Work in next PR:
- The update of `equivalence_cache.go`
- Unit test
- Integration/e2e test
I think we can begin from the `equivalence_cache.go`? Thanks. cc @wojtek-t @davidopp
If I missed any other necessary part, please point it out.
Automatic merge from submit-queue
Update documentation for running e2e tests locally
**What this PR does / why we need it**:
The docs for running e2e tests locally needs to be updated.
check_node_count option has been removed and developers usually
need to perform additional steps do get it going.
Automatic merge from submit-queue
Generate and store federation OpenAPI spec in source tree
A follow up of #33628 to also add federation spec to source tree.
Automatic merge from submit-queue
Add sandbox gc minage
Fixes https://github.com/kubernetes/kubernetes/issues/34272.
Fixes https://github.com/kubernetes/kubernetes/issues/33984.
This PR:
1) Change the `GetPodStatus` to get statuses of all containers in a pod instead of only containers belonging to existing sandboxes. This is because sandbox may be removed by GC or by users, kubelet should be able to deal with this case.
2) Change the CRI comment to clarify the timestamp unit (nanosecond).
2) Add MinAge for sandbox GC Policy.
@yujuhong @feiskyer @yifan-gu
/cc @kubernetes/sig-node
Automatic merge from submit-queue
Juju automated charm testing shouldn't bootstrap
**What this PR does / why we need it**:
**Special notes for your reviewer**: This controls the tooling around our test automation. This is a low impact change to the k8s codebase, that will have a big impact on our CI infrastructure.
**Release note**:
```release-note
release-note-none
```
Juju bootstrapping is an act of cost. This should be an explicit action
by the tooling surrounding bundle-tester when testing a charm. Setting
bootstrap:false will allow us to get faster feedback at lower cost when
running the kubernetes charm under ci.
Automatic merge from submit-queue
Check for rsync and give friendlier message
Fixes#34300.
Not sure if #34309 is the same issue. Hopefully it is the same issue.
Automatic merge from submit-queue
controller: save older revisions for Deployment's replica sets
@jwforres the only usable way I could find for multiple old revisions for a single replica set is to stuff them as comma-separated values.
@kubernetes/deployment this retains old revisions served by a replica set inside an annotation.
Fixes https://github.com/kubernetes/kubernetes/issues/33844
Automatic merge from submit-queue
Fix confusing log messages
While debugging https://github.com/kubernetes/kubernetes/issues/33876 , I noticed following confusing message:
```
The status of Pod kibana-logging-v1-j99la is Running, waiting for it to be either Running or Failed
```
Automatic merge from submit-queue
annotate some addtional errors in e2e tests
<!-- Thanks for sending a pull request! Here are some tips for you:
1. If this is your first time, read our contributor guidelines https://github.com/kubernetes/kubernetes/blob/master/CONTRIBUTING.md and developer guide https://github.com/kubernetes/kubernetes/blob/master/docs/devel/development.md
2. If you want *faster* PR reviews, read how: https://github.com/kubernetes/kubernetes/blob/master/docs/devel/faster_reviews.md
3. Follow the instructions for writing a release note: https://github.com/kubernetes/kubernetes/blob/master/docs/devel/pull-requests.md#release-notes
-->
**What this PR does / why we need it**:
Adds some additional context to e2e test failures.
**Which issue this PR fixes** *(optional, in `fixes #<issue number>(, #<issue_number>, ...)` format, will close that issue when PR gets merged)*: some work toward #34059
**Special notes for your reviewer**: I didn't want to go through all of the offending cases so I picked off a few files and addressed those.
**Release note**:
<!-- Steps to write your release note:
1. Use the release-note-* labels to set the release note state (if you have access)
2. Enter your extended release note in the below block; leaving it blank means using the PR title as the release note. If no release note is required, just write `NONE`.
-->
```release-note
NONE
```
Automatic merge from submit-queue
user-parameter support for API_BIND_ADDRESS in local-up-cluster.sh
**What this PR does / why we need it**:
Fixes#34262.
user-parameter for the secure api bind address when running a local dev cluster.
Default bind-address is `0.0.0.0` if not specified by the user. I'm guessing this was the intended behaviour of the original code.
Allow to reach the secure API on different interfaces/IPs when running a dev local-up-cluster.
Automatic merge from submit-queue
Make kubectl label and annotate more consistent
**What this PR does / why we need it**:
This makes the label and annotate cmd files more consistent which should help with code maintenance.
Some of the main changes:
- add dryrun to annotate (can push this in a different PR if requested)
- use Complete(), Validate() and RunX()
- don't place dynamic variables in the options (only user options and args)
- call the NewBuilder() in the Run function.
**Which issue this PR fixes**
fixes#34151
**Special notes for your reviewer**:
Note: you *can* now diff the two files and the changes make sense.
**Release note**:
```release-note
kubectl annotate now supports --dry-run
```
