jiebi/CodeConvo huggingface dataset:
Change:
}, { <del> name: "spec:v4 ip:v6 dualstack:on", </del> <ins> name: "spec:v4 ip:v6 dualstack:on isIPv6Primary:false", isIPv6Primary:          false, </ins> specExpctPrimary:       true, clusterIPExpectPrimary: false, enableDualStack:        true,

Discussion:
What happened: When K8s is started in dual-stack mode with IPv6 as the "main" (or base) family services specified with ipFamily:IPv4 still get a ipv6 ; The is expicitly set to "10.0.0.0" using . What you expected to happen: Services with ipFamily:IPv4 shall get ipv4 ClusterIP addresses. How to reproduce it (as minimally and precisely as possible): Setup a K8s cluster in dual-stack mode with family IPv6 as base Define a service with ipFamily: IPv4 To make K8s think IPv6 is the main family the cue is to define ipv6 addresses to K8s binaries. Below are my settings as an example. I do not use but install "from scratch"; Master processes; is accessed with ipv4 which does not affect the K8s family. Worker processes; Anything else we need to know?: There are other problems with dual-stack/ipv6-base but may be caused by this one. For example does not work and some processes does not become "ready". Ipv6 traffic to ipv6 services and DNS works; Environment: Kubernetes version (use ):Cloud provider or hardware configuration: - OS (e.g: ): BusyBox based own setup. Kernel (e.g. ):Install tools: "from scratch" Network plugin and version (if this is a network-related bug): Others:
/sig network /cc
The problem seem to be; The problem occurs when an ipv6 range is specified first, even in an ipv4-based dual-stack cluster. But the ipv6 range must be specified first otherwise the "kubernetes" service gets an ipv4 address but an ipv6 backend; ~Perhaps the way to fix this problem is to make sure the service address is from the right family and require that the order to is "ipv4,ipv6".~ Bad idea!
There seem to be a option; But I can't see it in the help printout. I will try to use it...
:disappointed:
Here it where the kubernetes service address is set;
/assign
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry. ‍
Change:
for version in $(BUNDLED_ETCD_VERSIONS); do  etcd_release_tmp_dir=$(shell mktemp -d);  curl -sSL --retry 5 https://github.com/coreos/etcd/releases/download/v$$version/etcd-v$$version-linux-amd64.tar.gz | tar -xz -C $$etcd_release_tmp_dir --strip-components=1;  <del> cp $$etcd_release_tmp_dir/etcd $$etcd_release_tmp_dir/etcdctl $(TEMP_DIR)/;  cp $(TEMP_DIR)/etcd $(TEMP_DIR)/etcd-$$version;  cp $(TEMP_DIR)/etcdctl $(TEMP_DIR)/etcdctl-$$version;  </del> <ins> $(BIN_INSTALL) $$etcd_release_tmp_dir/etcd $$etcd_release_tmp_dir/etcdctl $(TEMP_DIR)/;  $(BIN_INSTALL) $(TEMP_DIR)/etcd $(TEMP_DIR)/etcd-$$version;  $(BIN_INSTALL) $(TEMP_DIR)/etcdctl $(TEMP_DIR)/etcdctl-$$version;  </ins> done else

Discussion:
Part of What happened: Attempt to run as a non-root user Get What you expected to happen: It runs How to reproduce it (as minimally and precisely as possible): /sig release /sig cluster-lifecycle /area security And as part of kubeadm v1.16 milestone: /milestone v1.16 /priority critical-urgent
/assign randomvariable /lifecycle active
/priority important-soon
Change:
"net/http" "net/http/httptest" "net/url" <ins> "os" "path/filepath" </ins> "strconv" <ins> "strings" </ins> "testing" "time" <ins> "github.com/go-openapi/spec" </ins> "sigs.k8s.io/yaml" apiextensionsv1 "k8s.io/apiextensions-apiserver/pkg/apis/apiextensions/v1"

Discussion:
With in a CRD we get: This is because gnostic's OpenAPI proto types have no nullable support. Luckily CRDs keep working because in the upper error case we don't stop serving, just set the SSA schema to nil.
Thanks for reporting!
I think it should be "This is because gnostic's OpenAPI v2 proto types have no nullable support.". The problem is that we're not supposed to pass-in v3.
Source:
OK, We'll write a test and fix this, thanks Stefan!
/reopen This still happens in slightly different shape: This comes from :
That's a fairly different bug but yes, thanks!
Is this related to the stating that use of "anyOf" wouldn't be allowed after 1.16? We're seeing issue on OpenFaaS after going to 1.17.5 and 1.18. Usually upgrading K8s versions hasn't caused breaking changes and we're trying to figure out where to start with this one.
No. That post was about structural schemas. v1 CRDs are limited to structural schemas. v1beta1 CRDs can continue to create non-structural schemas until v1beta1 is no longer served (in 1.22) Also, is not completely disallowed, specific restrictions inside an clause (like ) are what are not allowed ("logical constraints using oneOf, allOf, anyOf, not are allowed").
extracted the newly found issue to to track separately with isolated reproducer /close
Closing this issue. <detailsIn response to : extracted the newly found issue to to track separately Instructions 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
Change:
testKubelet.fakeCadvisor.On("RootFsInfo").Return(cadvisorapiv2.FsInfo{}, nil) kl.nodeLister = testNodeLister{nodes: []api.Node{ <del> {ObjectMeta: api.ObjectMeta{Name: "127.0.0.1"}}, </del> <ins> { ObjectMeta: api.ObjectMeta{Name: "127.0.0.1"}, Status: api.NodeStatus{ Allocatable: api.ResourceList{ api.ResourcePods: *resource.NewQuantity(110, resource.DecimalSI), }, }, }, </ins> }} kl.nodeInfo = testNodeInfo{nodes: []api.Node{ <del> {ObjectMeta: api.ObjectMeta{Name: "127.0.0.1"}}, </del> <ins> { ObjectMeta: api.ObjectMeta{Name: "127.0.0.1"}, Status: api.NodeStatus{ Allocatable: api.ResourceList{ api.ResourcePods: *resource.NewQuantity(110, resource.DecimalSI), }, }, }, </ins> }} pods := []*api.Pod{

Discussion:
Was there some reason only the checking to the scheduler, not Kubelet?
IIRC it was written at the time when we stated adding checking in Kubelet. In other words - no reason.
Change:
if err != nil { return errors.Wrap(err, "failed to load admin kubeconfig") } <ins> if err = clientcmdapi.FlattenConfig(adminConfig); err != nil { return err } </ins> adminCluster := adminConfig.Contexts[adminConfig.CurrentContext].Cluster // Copy the cluster from admin.conf to the bootstrap kubeconfig, contains the CA cert and the server URL

Discussion:
What happened: Hi, I use to spawn the Kubernetes clusters inside the Kubernetes. Cert-manager is used to generate the certificates. Certificates mounted into pod as standard secret volume. This has no section but use instead: During the bootstrap this phase is executed by kubeadm: Which is overriding config in namespace: In result has no any CA, which make other nodes not possible to join the cluster: What you expected to happen: has correct CA-file new nodes are able to join How to reproduce it (as minimally and precisely as possible): put CA into file remove certificate-authority-data from describe path to the CA in parameter in Anything else we need to know?: Environment: Kubernetes version (use ): Cloud provider or hardware configuration: on-premise 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 cluster-lifecycle /assign neolit123
Change:
utilnet "k8s.io/apimachinery/pkg/util/net" "k8s.io/apiserver/pkg/apis/apiserver" egressmetrics "k8s.io/apiserver/pkg/server/egressselector/metrics" <del> compbasemetrics "k8s.io/component-base/metrics" </del> <ins> "k8s.io/component-base/metrics/legacyregistry" </ins> "k8s.io/component-base/tracing" "k8s.io/klog/v2" client "sigs.k8s.io/apiserver-network-proxy/konnectivity-client/pkg/client"

Discussion:
At (originally ) component-base metrics exposed Registerer API for raw prometheus registration, and I took dependency in The resulting does not seem to emit the new metrics (example: ). The metrics handler should emit the registered metrics. Falling back to does work. So there is some material difference with . 24, 1.25, 1.26 GKE No response No response No response No response
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
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
/assign jkh52
Change:
package completion import ( <ins> "fmt" </ins> "io" "github.com/spf13/cobra"

Discussion:
The command is generating a couple of hardcoded which seemingly causes any commands wrapping this package downstream to break. In this example, the OpenShift client: This should generate the compdef based on the rather than forcing kubectl, for example with : It could be even cleaner with the compdef function removed and the extraneous tag repeated below the boilerplate: compdef command command boilerplate stuff body Such as: generates the same first two lines as There is also a related downstream issue: Ideally, this might get resolved here at the source as it might help anyone else wrapping these commands downstream. I also have a possible solution which involves changing the hardcoded values from to use the which fixes the downstream without changing anything upstream. <details</details<detailsDownstream client-side issue unrelated to a specific cloud provider. </details<details</details<details- Latest </br- OpenShift client = 4.9 </detailsNo response <details</details
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 cli
Change:
var NodePrePullImageList = sets.NewString( imageutils.GetE2EImage(imageutils.Agnhost), "gcr.io/cadvisor/cadvisor:v0.47.2", <del> "registry.k8s.io/stress:v1", </del> busyboxImage, "registry.k8s.io/e2e-test-images/busybox@sha256:a9155b13325b2abef48e71de77bb8ac015412a566829f621d06bfae5c699b1b9", imageutils.GetE2EImage(imageutils.Nginx),

Discussion:
The image is built as a legacy Schema 1 image and will not work with most runtimes soon: ref:
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 node
cc You seemed to have built the image from on 2016-06-24T22:29:32 , could you rebuild and push the image?
/sig testing
I actually ran into an issue with this one a few months ago. There was very little in the image for testing and I believe that pointed me to the new test images they are using. We found that this image was quite old and essentially unmaintained.
Where is the new image?
PR to merge stress to agnhost:
Next:
Change:
software-properties-common  lsb-release <del> # focal repo for docker is not yet available, so we use bonic for now # https://github.com/kubernetes/kubernetes/issues/90709 </del> release=$(lsb_release -cs) <del> if [ "$release" == "focal" ]; then release="bionic"; fi </del> # Add the Docker apt-repository curl -fsSL https://download.docker.com/linux/$(. /etc/os-release; echo "$ID")/gpg 

Discussion:
We have some scripts that install docker/containerd etc and are having trouble installing on focal based images as does not yet support focal fossa. So in we have a patch that uses debs for focal. Additional context, please see ci test failures in and This issue is to track fixing the script back up when focal support is to
/sig release /sig testing
/priority important-soon /area release-eng
/assign
Change:
maskLocksmithdOnCoreos() if *startServices { <del> e2es = services.NewE2EServices() </del> <ins> // If the services are expected to stop after test, they should monitor the test process. // If the services are expected to keep running after test, they should not monitor the test process. e2es = services.NewE2EServices(*stopServices) </ins> Expect(e2es.Start()).To(Succeed(), "should be able to start node services.") glog.Infof("Node services started.  Running tests...") } else {

Discussion:
In node e2e, we have the option to keep the services running after test for further debug. However, we set to for the services, which means that once the parent exits, they will receive and exit with the parent if they don't trap the signal. With this, option will never work. If we still need this feature, we should not set if is false. /cc
We still need this feature. It helps with debugging test failures by keeping all the daemons running upon failure. , Lantao Liu wrote:
Change:
proxyMode := getProxyMode(string(config.Mode), iptInterface, iptables.LinuxKernelCompatTester{}) if proxyMode == proxyModeIPTables { glog.V(0).Info("Using iptables Proxier.") <del> var nodeIP net.IP if config.BindAddress != "0.0.0.0" { nodeIP = net.ParseIP(config.BindAddress) } else { </del> <ins> nodeIP := net.ParseIP(config.BindAddress) if nodeIP.Equal(net.IPv4zero) || nodeIP.Equal(net.IPv6zero) { </ins> nodeIP = getNodeIP(client, hostname) } if config.IPTables.MasqueradeBit == nil {

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 feature What happened: Upon code inspection, found that kube-proxy server takes into consideration a bind address of 0.0.0.0 (IPv4), but does not check for a bind address of :: (all-zeros IPv6) when calculating its node IP. What you expected to happen: IPv6 address "::" should be taken into consideration when calculating node IP. How to reproduce it (as minimally and precisely as possible): Code inspection. Anything else we need to know?: Environment: Kubernetes version (use ): Latest master Cloud provider or hardware configuration**: VirtualBox cluster, Ubuntu 16.04.1 host, CentOS 7 guests OS (e.g. from /etc/os-release): CentOS 7 Kernel (e.g. ): 3.10.0-514.26.2.el7.x8664 SMP Tue Jul 4 15:04:05 UTC 2017 x8664 x8664 x8664 GNU/Linux Install tools: Others:
There are no sig labels on this issue. Please by: a sig: e.g., to notify the contributor experience sig, OR the label manually: e.g., to apply the label Note: Method 1 will trigger an email to the group. You can find the group list and label list . The in the method 1 has to be replaced with one of these: bugs, feature-requests, pr-reviews, test-failures, proposals
/area ipv6 /sig network
Change:
} // createClientBuilders creates clientBuilder and rootClientBuilder from the given configuration <del> func createClientBuilders(logger klog.Logger, c *config.CompletedConfig) (clientBuilder clientbuilder.ControllerClientBuilder, rootClientBuilder clientbuilder.ControllerClientBuilder) { </del> <ins> func createClientBuilders(c *config.CompletedConfig) (clientBuilder clientbuilder.ControllerClientBuilder, rootClientBuilder clientbuilder.ControllerClientBuilder) { </ins> rootClientBuilder = clientbuilder.SimpleControllerClientBuilder{ ClientConfig: c.Kubeconfig, } if c.ComponentConfig.KubeCloudShared.UseServiceAccountCredentials { <del> if len(c.ComponentConfig.SAController.ServiceAccountKeyFile) == 0 { // It's possible another controller process is creating the tokens for us. // If one isn't, we'll timeout and exit when our client builder is unable to create the tokens. logger.Info("Warning: --use-service-account-credentials was specified without providing a --service-account-private-key-file") } </del> clientBuilder = clientbuilder.NewDynamicClientBuilder( restclient.AnonymousClientConfig(c.Kubeconfig),

Discussion:
The kube-controller-manager issues a warning during startup when is specified without providing a . This warning is misleading because the legacy service account token controller, which relies on the , is no longer required for most modern Kubernetes clusters unless explicitly needed for generating long-lived tokens. Additionally, the documentation does not clearly state the purpose of this flag or its impact on legacy token mechanisms. I expected that the warning related to the would either not appear or be updated to reflect its relevance only to the legacy token mechanism. Furthermore, I expected the documentation to clearly explain that this flag is only necessary for enabling the legacy service account token controller and to provide updated guidance on generating long-lived tokens. kube-controller-manager with the --use-service-account-credentials flag but without the --service-account-private-key-file flag. the warning message that is issued during initialization. the current documentation for kube-controller-manager flags and the process for generating long-lived service account tokens. for context <details</details<detailsBare metal </details<details</details<details</details<details</details<details</details
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
/sig auth
Change:
const ( fileMode        = "file_mode" dirMode         = "dir_mode" <ins> gid             = "gid" </ins> vers            = "vers" defaultFileMode = "0755" defaultDirMode  = "0755"

Discussion:
If I look at the code of azureFile plugin, it has fsGroup as an argument, but don't see its usage anywhere I also don't see anywhere explicitely stated that azureFile volume supports fsGroup.
/sig storage
For those landing here, a separate path to get the mount point to have the right permissions is to add this annotation to the PV metadata: This makes the plugin mount the volume in the Pod under those UID,GID. Obviously, this implies that one knows what those are for their workload in the container ...
If i create a PV like this, still mounted with the default root used into POD. StorageClass PV
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. Prevent issues from auto-closing with an comment. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
/remove-lifecycle stale cc Let's check whether works for azure file.
/sig azure
is another way to set groupid(gid) While according to this , we also need to support Here is the code about setting fsgroup from securityContext. I will enable this feature and do a test, it should be 3 lines of code. /assign
BTW, this is all for Linux(UserID, GroupID), is there an identical setting for Windows container?
No, setting user for volumes doesn't work on Windows. Only the rw/ro options are implemented.
According to my investigation, though I put the following code in azure file , it does not take effect. The reason is azure file(cifs) mount does not support gid setting after file system mount, by default would be 0(root) So in summary, set fsGroup code in azure file is useless, user could set gid by mountOptions in storage class, here is an Let me know if you hav any concern about this issue Update: Root cause is azure file(cifs) mount does not support gid setting after file system mount, while azure disk supports.
is this true, that cifs does not support guid setting?
Of course cifs support gid setting, see example: I mean cifs does not support second time gid setting, kind of differnet than azure disk.

Anyway, I am working on a PR to support if no gid setting in azure file storage class, while if both sets, only gid from storage class would be used.
while the code is quite different than just add below 3 lines of code, actually below does not work: I will show you the PR tomorrow.
Change:
docker manifest push --purge ${MANIFEST_IMAGE}:${IMAGE_TAG} unit-test: <del> docker run --interactive -v $(shell pwd)/../../../:/go/src/k8s.io/kubernetes -e GOARCH=$(ARCH) golang:$(GOLANG_VERSION)  </del> <ins> docker run --interactive -v $(shell pwd)/../../../:/go/src/k8s.io/kubernetes$(DOCKER_VOL_OPTS) -e GOARCH=$(ARCH) golang:$(GOLANG_VERSION)  </ins> /bin/bash -c "CGO_ENABLED=0 go test -v k8s.io/kubernetes/cluster/images/etcd/migrate" # Integration tests require both a golang build environment and all the etcd binaries from a `k8s.gcr.io/etcd` image (`/usr/local/bin/etcd-<version>`, ...).

Discussion:
Part of What happened: Attempt to run as a non-root user Get What you expected to happen: It runs How to reproduce it (as minimally and precisely as possible): /sig release /sig cluster-lifecycle /area security And as part of kubeadm v1.16 milestone: /milestone v1.16 /priority critical-urgent
/assign randomvariable /lifecycle active
/priority important-soon
Change:
"math" "net" "net/http" <del> "os" </del> "path" "path/filepath" "strconv"

Discussion:
What happened: follow on to Need to comment and avoid checking UID on windows. requires some research into what we should be checking so that we can add appropriate TODO. What you expected to happen: Lets also check this at the call site, Anything else we need to know?: Environment: Kubernetes version (use ): master OS (e.g: ): windows
/assign
/assign
/good-first-issue
This request has been marked as suitable for new contributors. Please ensure the request meets the requirements listed . If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : /good-first-issue Instructions 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 windows
Hi are you working on this issue already? If not I'd like to tackle this issue :)
Hi yeah I am already working on this :)
Started branch for this here
thanks
Hey guys is there anything I can do here?
If you want to test perks patch that would be great ?
That sounds great Where do I get started?
Hey ! is there anything I can help with? and how?
I dont think there is anything left to do anything more that you think we need to do to get this merged?
Tested this with containerd as well, I think its good to test
/triage accepted