jiebi/CodeConvo huggingface dataset:
Change:
// Initialize passes a Kubernetes clientBuilder interface to the cloud provider func (vs *VSphere) Initialize(clientBuilder controller.ControllerClientBuilder) { <ins> } // Initialize Node Informers func (vs *VSphere) SetInformers(informerFactory informers.SharedInformerFactory) { </ins> if vs.cfg == nil { return } // Only on controller node it is required to register listeners. // Register callbacks for node updates <del> client := clientBuilder.ClientOrDie("vsphere-cloud-provider") factory := informers.NewSharedInformerFactory(client, 5*time.Minute) nodeInformer := factory.Core().V1().Nodes() nodeInformer.Informer().AddEventHandler(cache.ResourceEventHandlerFuncs{ </del> <ins> glog.V(4).Infof("Setting up node informers for vSphere Cloud Provider") nodeInformer := informerFactory.Core().V1().Nodes().Informer() nodeInformer.AddEventHandler(cache.ResourceEventHandlerFuncs{ </ins> AddFunc:    vs.NodeAdded, DeleteFunc: vs.NodeDeleted, }) <del> go nodeInformer.Informer().Run(wait.NeverStop) glog.V(4).Infof("vSphere cloud provider initialized") </del> <ins> glog.V(4).Infof("Node informers in vSphere cloud provider initialized") </ins> } // Creates new worker node interface and returns

Discussion:
Here if we with , then we are only able to watch the latest change. In this case if the key is modified after the returns but before the we call the , then we will miss the event. To avoid the window time, we'd better specify the to be the index in the response of the . BTW, I think if we use with , we can probably eliminate the first call.
This is fixed in
Change:
Ports:     []api.EndpointPort{{Name: "", Port: 80}, {Name: "p", Port: 93}}, }}, }, <ins> { ObjectMeta: metav1.ObjectMeta{ Name:      "foo-second-ip", Namespace: metav1.NamespaceDefault, }, Subsets: []api.EndpointSubset{{ Addresses: []api.EndpointAddress{{IP: "2001:db7::", TargetRef: &api.ObjectReference{Name: "foo", Namespace: metav1.NamespaceDefault}}}, Ports:     []api.EndpointPort{{Name: "", Port: 80}, {Name: "p", Port: 93}}, }}, }, </ins> }, } pods := &api.PodList{

Discussion:
Hi, I have a issue with a dualstack cluster for my Kubernetes Dashboard deployment. I opened a ticket here (), but I am informed that it is not related to Kubernetes Dashboard. What is the problem? Errors in kube-api: The service is created with the correct ipFamily (=IPv6). My endpoint is fully in IPv6. Indeed, my pod has one IP in IPv4 and another in IPv6. Do you have also the issue? Kubernetes version: 1.18 OS: RHEL7
/sig network /sig api-machinery
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry. ‍
I think the following should fix the error you saw:
/remove-sig api-machinery
Change:
}() } <ins> // StartRecordingToSink starts sending events received from the specified eventBroadcaster to the given sink. func (e *eventBroadcasterImpl) StartRecordingToSink(stopCh <-chan struct{}) { go wait.Until(e.refreshExistingEventSeries, refreshTime, stopCh) go wait.Until(e.finishSeries, finishTime, stopCh) e.startRecordingEvents(stopCh) } </ins> type eventBroadcasterAdapterImpl struct { coreClient          typedv1core.EventsGetter coreBroadcaster     record.EventBroadcaster

Discussion:
Which jobs are flaking: periodic-kubernetes-bazel-test-master (xref ) Which test(s) are flaking: TestEventSeriesf Testgrid link: Reason for failure: Timeout: Anything else we need to know: To reproduce with stress: /cc
There are no sig labels on this issue. Please add an appropriate label by using one of the following commands: - Please see the for a listing of the SIGs, working groups, and committees available. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/assign
filed to address this issue.
contains the correct analysis of flakes (thanks a lot!), I commented on way of fixing it (which I'm not convinced about).
Change:
Ready:    true Hostname:   <unset> TargetRef:  Pod/test-124 <del> NodeName:   <unset> </del> <ins> NodeName:   node-2 </ins> Zone:       <unset> Events:         <none>` + "n", },

Discussion:
<!-- Please use this template while reporting a bug and provide as much info as possible. Not doing so may result in your bug not being addressed in a timely manner. Thanks! If the matter is security related, please disclose it privately via --panic as below when an Endpoint doesn't have zone. should print zone as if an Endpoint's zone is unset. not set "" for Nodes. Pods and export them as a service. kubectl to describe the corresponding EndpointSlice. Kubernetes version (use ): v1.21.0 Cloud provider or hardware configuration: OS (e.g: ): Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others:
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the label and provide further guidance. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/sig network /sig cli /assign
Change:
metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" "k8s.io/apimachinery/pkg/util/sets" "k8s.io/apimachinery/pkg/util/uuid" <ins> utilfeature "k8s.io/apiserver/pkg/util/feature" "k8s.io/kubernetes/pkg/features" </ins> "k8s.io/kubernetes/test/e2e/framework" . "github.com/onsi/ginkgo"

Discussion:
Once the API for is finalized, add a node e2e test. /kind feature /assign /cc /sig node
We plan on adding this for 1.10
Change:
echo "Creating minions." <ins> # TODO(mbforbes): Refactor setting scope flags. </ins> local -a scope_flags=() if (( "${#MINION_SCOPES[@]}" > 0 )); then scope_flags=("--scopes" "${MINION_SCOPES[@]}")

Discussion:
See issue as the roll-up for node upgrades. tl;dr: Update MIG template, then call a MIG rollingupdate. More details: When upgrading nodes, an in-place upgrade must worry about leftover state on the boot disk, VM configuration like IP tables, and the idempotency of salt. Getting a fresh VM instead would remove these concerns and provide a clean state for a new node. Furthermore, a versioned node spec () includes the tuple of (kubelet, kube-proxy, docker, kernel/OS). In the general case, changing docker or the kernel/OS means we have to stop the running pods. Once know we have to stop the pods, the simplest upgrade mechanism is to totally down the node and provision a new one. Provisioning a new node is also a great backup to have for node repairs. To be clear, though, this issue is entirely separate from node repairs; once we have the capability to grow the cluster by adding new nodes, this mechanism, and other repair mechanisms, will build on top of that capability. This was blocked by: nodes joining a running cluster (template-only metadata) References: The most relevant discussion regarding the worries of complications with state while doing in-place upgrades is .
FWIW, I think we need this as a fallback to repair completely borked nodes? That is, it may not be necessary for upgrades per se, but could end up being independently useful.
Thanks for the comment, I updated the description to be clear about what this issue is addressing. Having the ability to add new nodes to a cluster will both enable this upgrade path as well as give us a great "hammer" to use for repairs.
Working on this now.
Change:
testsuites.CapBlock:               true, testsuites.CapPVCDataSource:       true, testsuites.CapControllerExpansion: true, <ins> testsuites.CapSingleNodeVolume:    true, </ins> } return initHostPathCSIDriver("csi-hostpath", capabilities,

Discussion:
What happened: When we run csi hostpath driver e2e tests on a multi-node cluster some tests failed because they assume that volumes are node independent but this is not the case for some drivers like hostpath. Related PR; What you expected to happen: Skip the tests that assume volumes are node independent for the drivers that don't support node independent volumes. /sig storage /assign
Change:
ExpectedError: "does not contain declared merge key", }, }, <ins> { Description: "$deleteFromPrimitiveList of nonexistent item in primitive list should not add the item to the list", StrategicMergePatchRawTestCaseData: StrategicMergePatchRawTestCaseData{ Original: []byte(` mergingIntList: - 1 - 2 `), TwoWay: []byte(` $deleteFromPrimitiveList/mergingIntList: - 3 `), Modified: []byte(` mergingIntList: - 1 - 2 `), }, }, { Description: "$deleteFromPrimitiveList on empty primitive list should not add the item to the list", StrategicMergePatchRawTestCaseData: StrategicMergePatchRawTestCaseData{ Original: []byte(` mergingIntList: `), TwoWay: []byte(` $deleteFromPrimitiveList/mergingIntList: - 3 `), Modified: []byte(` mergingIntList: `), }, }, { Description: "$deleteFromPrimitiveList on nonexistent primitive list should not add the primitive list", StrategicMergePatchRawTestCaseData: StrategicMergePatchRawTestCaseData{ Original: []byte(` foo: - bar `), TwoWay: []byte(` $deleteFromPrimitiveList/mergingIntList: - 3 `), Modified: []byte(` foo: - bar `), }, }, </ins> } func TestCustomStrategicMergePatch(t *testing.T) {

Discussion:
<!-- Please use this template while reporting a bug and provide as much info as possible. Not doing so may result in your bug not being addressed in a timely manner. Thanks! If the matter is security related, please disclose it privately via --Patching an object without finalizers using results in the given finalizers being . is idempotent in case there are other list elements than the removed one. I expected to also be idempotent in case the list is already empty. an arbitrary object: an arbitrary finalizer to the object via strategic merge patch: the finalizer again by using the directive: the same patch again: Kubernetes version (use ):
/sig api-machinery
Strange. It looks like attempting to delete a nonexistent primitive actually adds it. Below is a slightly different take on your example, client-side only and without any finalizers to start with. It tries to delete which is nonexistent and it ends up being : I also tested with some previous versions of kubectl (back to 1.10.2 even) and saw the same thing, so it appears to have always been this way.
I just checked: the same thing happens when directly talking to the API server (so it's not a kubectl-only bug):
that's good to know. But I guess, this is not expected behavior, right?
I don't think it is expected behavior. It is surprising to me at least. I am curious to know what someone who has more experience with Strategic Merge Patch has to say though.
looks like this was reported in as well
/cc /triage accepted
The best workaround for now is probably to json merge patch the whole list with the resourceVersion set. I don't know much about the code nor the bug, but it really looks like a bug rather than a feature, so we should be able to fix it without causing too much surprise to other users. We generally have limited interest fixing smp but that seems worthy. Is somone interested in looking at it?
/assign
Change:
message RollingUpdateDeployment { // The maximum number of pods that can be unavailable during the update. // Value can be an absolute number (ex: 5) or a percentage of desired pods (ex: 10%). <del> // Absolute number is calculated from percentage by rounding up. </del> <ins> // Absolute number is calculated from percentage by rounding down. </ins> // This can not be 0 if MaxSurge is 0. // By default, a fixed value of 1 is used. // Example: when this is set to 30%, the old RC can be scaled down to 70% of desired pods

Discussion:
API documentation says is rounded up, but it is actually rounded down: The code shows it is rounded down, not up: and
Yes, the documentation is obsolete. We changed maxUnavailable to round down so that we wouldn't accidentally infer 100% unavailability for non-100 percentages. For example, maxSurge=25% and maxUanavailable=25% with a Deployment of 1 replica meant that we could scale down 1 before thus leading in 100% maxUnavailable (implicit).
Change:
labelSelector := "" fieldSelector := "" timeout := time.Duration(0) <ins> wait := true </ins> filenames := []string{} recursive := false

Discussion:
<!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . If this may be security issue, please disclose it privately via --Is this a BUG REPORT or FEATURE REQUEST?: /kind bug /sig CLI What happened: Running leads to nil pointer dereference: What you expected to happen: is expected to run delete with wait in that case How to reproduce it (as minimally and precisely as possible): (with any valid resource yaml) Anything else we need to know?: Discovered in when accidentally enabled wait for deletion from other commands than and saw failing integration tests in https://k8s- Environment: Kubernetes version (use ): latest master Cloud provider or hardware configuration: OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: Others:
This bug was introduced in : is set in that requires to be non-nil flag is being set in is normally being set in method which is not invoked in . a result, the invocation of resource finder leads to nil pointer dereference (see stack trace in the description).
/cc
Change:
ioStreams, _, _, errBuf := genericclioptions.NewTestIOStreams() cmd := NewCmdDrain(tf, ioStreams) <ins> var recovered interface{} </ins> sawFatal := false fatalMsg := "" func() { defer func() { // Recover from the panic below. <del> _ = recover() </del> <ins> recovered = recover() </ins> // Restore cmdutil behavior cmdutil.DefaultBehaviorOnFatal() }()

Discussion:
<!-- Please use this template while reporting a bug and provide as much info as possible. Not doing so may result in your bug not being addressed in a timely manner. Thanks! If the matter is security related, please disclose it privately via --What happened: kubectl drain crashed with panic when apiserver connection disappeared while there were pods that couldn't be evicted/deleted (sorry, the problem is a bit hard to reproduce and the log was lost) What you expected to happen: kubectl drain should exit with a proper error message How to reproduce it (as minimally and precisely as possible): Try kubectl drain multiple times, interrupting the connection during eviction/deletion Anything else we need to know?: The here can be in case if returns an error, and will panic upon accessing : This causes the c Environment: Kubernetes version (use ): The problem is present as of but is also present in earlier versions (I have a fix for this bug)
/priority important-longterm /sig cli
Change:
return waitForServiceAccountInNamespace(c, namespace, "default", ServiceAccountProvisionTimeout) } <ins> // WaitForKubeRootCAInNamespace waits for the configmap kube-root-ca.crt containing the service account // CA trust bundle to be provisioned in the specified namespace so that pods do not have to retry mounting // the config map (which creates noise that hides other issues in the Kubelet). func WaitForKubeRootCAInNamespace(c clientset.Interface, namespace string) error { return waitForConfigMapInNamespace(c, namespace, "kube-root-ca.crt", ServiceAccountProvisionTimeout) } </ins> // CreateTestingNS should be used by every test, note that we append a common prefix to the provided test name. // Please see NewFramework instead of using this directly. func CreateTestingNS(baseName string, c clientset.Interface, labels map[string]string) (*v1.Namespace, error) {

Discussion:
Originally posted by in
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the label and provide further guidance. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/sig testing /cc
/hold I have a subtly different fix in :)
Oh wait, this is an issue. Yay, thanks :). Fixed in
Change:
import ( "fmt" <ins> "net" </ins> "time" "github.com/GoogleCloudPlatform/kubernetes/pkg/api"

Discussion:
Why doesn't the 'node' entity have a hostname and/or IP fields? Currently its id field (soon to become name field) holds the IP but is that something that a REST api consumer can firmly rely on to get the node's IP/hostname so this field 'name/id' will always hold IP/hostname and not other information? (IP/hostname is useful for example for visualization of the minions available in a k8s cluster in UI and showing their IP/hostnames)
Minion does have a HostIP field in v1beta1, and NodeStatus has a HostIP field in v1beta3. When you GET the resource, is the value for that field not set? If so, on what cloudprovider? It's true that there is no hostname field, but the minion/node name itself is the hostname.
, I'm currently using the hack/local cluster setup , this is the output of GET for minion 127.0.0.1 with v1beta1, seems that HostIP is not returned at all (even not with empty value) { "kind": "Node", "id": "127.0.0.1", "uid": "-8527-11e4-8f4b-", "creationTimestamp": "2014-12-16T15:31:50+02:00", "selfLink": "/api/v1beta1/minions/127.0.0.1", "resourceVersion": 7, "apiVersion": "v1beta1", "resources": { "capacity": { "cpu": 1000, "memory": } } } Can you please elaborate/point to docs about the change in v3? so HostIP field is moved into a NodeStatus section/internal to Node entity? BTW why is it considered part of a status? thank you
The best documentation of v1beta3 is unfortunately the source right now: It adheres to the conventions described here: The fact that HostIP is not reported is probably a quirk with static minions. In reality, hosts can have multiple IP addresses, some private and some public, v4 and v6, dynamically assigned (e.g., using DHCP), etc. For now, we support single, private, static IP addresses, but in cases where hosts are specified using hostnames, the IP addresses are looked up.

So, status makes the most sense to me.
Yeah, HostIP is only queried from cloudprovider. you won't see hostIP in json if it's empty (see the tag)
why HostIP is not returned for local static setup? the id reflects the IP anyhow. it sounds like a bug, but this issue is tagged with "documentation".
Yes, I agree that it's a bug that HostIP isn't populated. The documentation aspect is to explain somewhere why it's in Status rather than Spec.
Change:
cleanupLocalVolume(config, testVol) }) <del> It("should be able to mount and read from the volume using one-command containers", func() { By("Creating a pod to read from the PV") readCmd := createReadCmd(volumeDir, testFile) podSpec := makeLocalPod(config, testVol, readCmd) //testFileContent was written during setupLocalVolume f.TestContainerOutput("pod reads PV", podSpec, 0, []string{testFileContent}) }) It("should be able to mount and write to the volume using one-command containers", func() { By("Creating a pod to write to the PV") writeCmd, readCmd := createWriteAndReadCmds(volumeDir, testFile, testVol.hostDir /*writeTestFileContent*/) writeThenReadCmd := fmt.Sprintf("%s;%s", writeCmd, readCmd) podSpec := makeLocalPod(config, testVol, writeThenReadCmd) f.TestContainerOutput("pod writes to PV", podSpec, 0, []string{testVol.hostDir}) }) </del> It("should be able to mount volume and read from pod1", func() { By("Creating pod1") pod1, pod1Err := createLocalPod(config, testVol)

Discussion:
<!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . --Is this a BUG REPORT or FEATURE REQUEST?: /kind bug /assign What happened: Looks like the event messaging has changed
Change:
} // return: disk provisionState, diskID, error <del> func (c *ManagedDiskController) getDisk(diskName string) (string, string, error) { </del> <ins> func (c *ManagedDiskController) getDisk(resourceGroup, diskName string) (string, string, error) { </ins> ctx, cancel := getContextWithCancel() defer cancel() <del> result, err := c.common.cloud.DisksClient.Get(ctx, c.common.resourceGroup, diskName) </del> <ins> result, err := c.common.cloud.DisksClient.Get(ctx, resourceGroup, diskName) </ins> if err != nil { return "", "", err }

Discussion:
<!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . If the matter is security related, please disclose it privately via --Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: there will be azure disk creation issue when specifying an external resource group, after azure disk creation succeeded, it fails to get azure disk state What you expected to happen: How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: Environment: Kubernetes version (use ): v1.11 Cloud provider or hardware configuration: OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: Others: /assign /azure
/sig azure
/kind bug
Change:
hostPath: path: /dev containers: <del> - image: "gcr.io/gke-release/nvidia-gpu-device-plugin@sha256:a75ec0caa9e3038bd9886b3f36641a624574ff34b064974de6ee45048de3372b" </del> <ins> - image: "k8s.gcr.io/nvidia-gpu-device-plugin@sha256:4b036e8844920336fa48f36edeb7d4398f426d6a934ba022848deed2edbf09aa" </ins> command: ["/usr/bin/nvidia-gpu-device-plugin", "-logtostderr"] name: nvidia-gpu-device-plugin resources:

Discussion:
Looks like we have 2 images: Here: Should these be moved to community owned repositories? Are there already there and we just need to fix up the locations?
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the label and provide further guidance. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/assign
for there are some PRs in progress to move the registry: and requested to copy the exiting image to the new community registry. for I will work on that next. :)
thanks !
discovered that the is available here: will open a PR to update to use this image
Where are the sources for these images? Will we be able to continue to publish new images? cc xref: None of these images seem to have version tags? If we're not actually publishing these, then we should probably either: consume them from somewhere that is publishing them and maintaining them set up mirroring them
copying from Also as much as I would like to see this sorted out I don't think or counts as a test-only issue to be resolving in this part of the release cycle. This seems like something we should do early in 1.22 and focus on actual test coverage improvements and functionality fixes right now.
/sig testing
/wg k8s-infra /milestone v1.22
Was CSI moved?
yes Ben ( was moved)
gcp-compute-persistent-disk-csi-driver is moved and nvidia-gpu-device-plugin have a good slack and the image was move in k/k with this PR I think we can close this issue. will close, if I did wrong we can reopen /close
Change:
# Please see http://docs.fluentd.org/articles/install-by-deb for more # information about installing fluentd using deb package. <del> FROM ubuntu:14.04 </del> <ins> FROM gcr.io/google_containers/ubuntu-slim:0.4 </ins> MAINTAINER Alex Robinson "arob@google.com" MAINTAINER Jimmi Dyson "jimmidyson@gmail.com"

Discussion:
It's 400+mb and we need to pull it on every node. This leads to a lot of image pulling flake (), and also gets very expensive in some countries where bandwidth is sold at a premium. We took a stab at halving the size with: , but then realized that we were using an unsupported base image We tried to optimize to ~300Mb by building a smaller ubuntu:15 base, but that's still huge. Every other mandatory system daemon is built on busybox and so takes ~10Mb.
I can try again now that the agent supports
Newer Docker images using the spec from the official repository are based on AlpineLinux and are around ~38MB: