jiebi/CodeConvo huggingface dataset:
Code change:
return semver.MustParse(version.APIVersion + ".0"), nil } <del> // isSharedPIDNamespaceEnabled returns true if the Docker version is 1.13.1+ </del> <ins> // isSharedPIDNamespaceSupported returns true if the Docker version is 1.13.1+ </ins> // (API version 1.26+), and false otherwise. <del> func isSharedPIDNamespaceEnabled() (bool, error) { </del> <ins> func isSharedPIDNamespaceSupported() (bool, error) { </ins> version, err := getDockerAPIVersion() if err != nil { return false, err

Related discussion:
text: The problem is with images that assume they will only ever have , which has so far been the case with docker due to a technical limitation, but it was never the case with other runtimes such as rkt, hyperv, etc. Brainstorming other options: shared pid namespace and require users of systemd to set an environment variable in their Kubernetes config (or port the multi-process container to a multi-container pod). shared pid namespace and enable it in a future release where we have the same problem. a solution where pid namespace is configurable per-pod, but not supported indefinitely. It would probably be implemented using annotations, and we will have to modify the Container Runtime Interface to support it. Over the course of multiple releases the default behavior would change but could be reverted based on the presence of an annotation. In a future release, users will have to change an annotation in their config to get the old behavior (rather than the environment variable). In a future future release, the annotation will stop working and users will have to set the environment variable. to supporting per-pod shared vs isolated pid namespaces indefinitely and adding it to the Kubernetes API. It doesn't make sense in some runtimes, so we probably can't require all runtimes to implement it, so it'll likely only see use with Docker. Last time we discussed it in SIG Node, and didn't want to support isolated pid namespaces indefinitely.
Yes running systemd in a container is a critical need for us. There are lots of situations where it is and will be used. Biggest use case if for people simply moving current workloads that run in a VM into a container. I have a service that runs fun under systemd in a VM. If I can simply take the init script and move it whole sale into a container, why wouldn't I want to do this. It's simple and does require a great deal of knowledge by the end user. service containers. Not every project can easily be moved into microservices. But they probably can run inside of containers. If we drop support for systemd running inside of containers, then we loose a big group of users. Getting access to journald information inside of the container. Applications that write to syslog and directly to the journal. Currently in container world without systemd, this information is dropped on the floor.
Code change:
return semver.MustParse(version.APIVersion + ".0"), nil } <del> // isSharedPIDNamespaceEnabled returns true if the Docker version is 1.13.1+ </del> <ins> // isSharedPIDNamespaceSupported returns true if the Docker version is 1.13.1+ </ins> // (API version 1.26+), and false otherwise. <del> func isSharedPIDNamespaceEnabled() (bool, error) { </del> <ins> func isSharedPIDNamespaceSupported() (bool, error) { </ins> version, err := getDockerAPIVersion() if err != nil { return false, err

Related discussion:
text: if I run systemd and journald, I can actually retrieve and use this information.
If the intension is to force all containers inside of a POD to run with the same PID Namespace? I think this is a mistake since it eliminates another really cool use case. I would love to be able to run two containers inside of a pod, and INIT container with escallated privileges and a locked down container, with no privileges. I want to make sure the locked down container can not see the processes of the privileged container. An example of this, might be a container that loads a kernel module that is needed by the locked down container. Another use case would be a buildah container. The INIT container mounts up a COW file system onto a directory on a location that the locked down container can write, The locked down container writes out the data for his image, when the container completes, the INIT container commits the data to the repo. I believe allowing different containers inside of a POD to run with different security and isolated PIDs should not be removed.
none of the things you've mentioned are removed by this change, save using docker to hide other processes in the pod, and I'm not sure why that's a requirement. Is anyone currently using the "privileged sidecar" pattern you describe or is it hypothetical? It just occurred to me that an interesting compromise here might be to only enable shared pid for multi-container pods. This would enable pod semantics for PID when it would make a difference while drop-in docker monoliths keep the PID 1 behavior they're expecting in docker. I'd have to double check, but I'm pretty sure that behavior could be implemented entirely in the dockershim with no API or CRI changes.
Hypothetical, but I am pushing it for a solution for problems I hear from users fairly frequently, where then need big privileges at start and stop of the pod, but not for the time is is available to the network.
ok, thanks. ftr, I think we should continue to support this pattern as well, and I don't think a shared PID namespace prohibits it. I will bring up this issue at Tuesday's sig node meetup if you'd like to join us. Does the config I mentioned in fix the issue with systemd?
Code change:
return semver.MustParse(version.APIVersion + ".0"), nil } <del> // isSharedPIDNamespaceEnabled returns true if the Docker version is 1.13.1+ </del> <ins> // isSharedPIDNamespaceSupported returns true if the Docker version is 1.13.1+ </ins> // (API version 1.26+), and false otherwise. <del> func isSharedPIDNamespaceEnabled() (bool, error) { </del> <ins> func isSharedPIDNamespaceSupported() (bool, error) { </ins> version, err := getDockerAPIVersion() if err != nil { return false, err

Related discussion:
text: Copying from a comment made elsewhere:
Update from SIG Node Meetup: Everyone wants to support these use cases, but we're not yet sure the requirements we want to support medium to long term. is going to sync up with and then we'll figure out what we want to support in a future release. For 1.8 the current plan is to leave docker shared pid namespace enabled by default. Cluster administrators can disable it per-node with the --docker-disable-shared-pid flag. I'll see about whether we should add something back to the release notes.
This seems somewhat backwards. Wouldn't it make more sense to go back to supporting systemd use cases by default NOW (by making the shared PID namespace behavior optional or something) until a final decision is reached and can be advertised to current users?
absolutely ! thank you very much
I think that is the best solution is to make the PID Namespace sharing optional.
- optional at what scope - cluster, node, pod. let's sync up before next sig-node and we can revisit if need be before 1.8 goes out. The main question right now is if pid namespace sharing is opt-in or opt-out. We need to weigh pro/cons of both.
I would expect it at the POD, since pods would have different requirements, not sure why you would want to have this at the cluster or node level.
yes it works :)
awesome, thanks! I'd like to better understand the requirements of people objecting to this change ( I think there's a bit of confusion about what has changed, so let's start with some facts: This container image runs on Kubernetes without changes to the image, but it requires (non-obvious) pod configuration. is nothing inherently incompatible between a shared pid namespace and a process manager like systemd. systemd and other init systems work with pid != 1, but may require special invocation. in this issue is specific to Kubernetes. That is, this container image wouldn't work with vanilla docker PID namespace sharing, either. change does not affect securityContext I can think of a few things that are objectionable about the change, but let's state them as requirements. For example, are these requirements for anyone? Kubernetes must run all containers published on docker hub with no additional pod configuration Kubernetes must run all systemd containers, regardless of how they are built, with zero additional pod configuration.
Code change:
return semver.MustParse(version.APIVersion + ".0"), nil } <del> // isSharedPIDNamespaceEnabled returns true if the Docker version is 1.13.1+ </del> <ins> // isSharedPIDNamespaceSupported returns true if the Docker version is 1.13.1+ </ins> // (API version 1.26+), and false otherwise. <del> func isSharedPIDNamespaceEnabled() (bool, error) { </del> <ins> func isSharedPIDNamespaceSupported() (bool, error) { </ins> version, err := getDockerAPIVersion() if err != nil { return false, err

Related discussion:
text: Kubernetes must run this specific container image with zero additional configuration Kubernetes must officially support isolated PID namespaces between containers in a single pod across all runtimes (docker, rkt, hyperv, etc). Configuration changes are ok, but the flag to systemd cannot be used because the documentation says its not useful. I want to use systemd as intended. Rather than having Kubernetes work around this container image, should we patch the Dockerfile to make it compatible with even the native docker shared-pid, unrelated to Kubernetes?
Configuration changes are ok, but the --system flag to systemd cannot be used because the documentation says its not useful. I want to use systemd as intended. We can ask the systemd guys why they recommend never using the --system flag, but I would guess one of the reasons is that processes showing up that were not created in the ancestry of systemd, could cause confusion. I would also guess that running more then one container with systemd --system would not be supported. Kubernetes must officially support isolated PID namespaces between containers in a single pod. This is required so that you can run different containers with different security constraints in the same pod at the same time. Your last comment makes the seem like it is the default, when actually it is the exception. almost no containers run with shared-pid normally. I guess in a side car container, it makes sense to support this scenario, but forcing this as the ONLY way to run containers is limiting.
This is the part I don't understand. Why? What does PID visibility have to do with security constraints? What am I missing? nor do they run with a shared network namespace, but we impose that on docker containers because that's the pod model.
An update from the last SIG Node: we'll disable this by default in 1.8 and revisit for 1.9 I'll use to track that.
if I have a privileged container process in the same pid namespace as a pid in a non priv container, then the container process in the non priv can attack the priv process. Having them in separate pid namespaces gives you better security. Bottom line, you have a potential change where containers that expect to be run as PID 1, whether legitimately or not, could break when you make this change. Kubernetes in my opinion should make it easy to opt out of this behavior.
Code change:
return semver.MustParse(version.APIVersion + ".0"), nil } <del> // isSharedPIDNamespaceEnabled returns true if the Docker version is 1.13.1+ </del> <ins> // isSharedPIDNamespaceSupported returns true if the Docker version is 1.13.1+ </ins> // (API version 1.26+), and false otherwise. <del> func isSharedPIDNamespaceEnabled() (bool, error) { </del> <ins> func isSharedPIDNamespaceSupported() (bool, error) { </ins> version, err := getDockerAPIVersion() if err != nil { return false, err

Related discussion:
text: /priority critical-urgent
[MILESTONENOTIFIER] Milestone Labels Complete Issue label settings: sig/node: Issue will be escalated to these SIGs if needed. priority/critical-urgent: Never automatically move out of a release milestone; continually escalate to contributor and SIG through all available channels. kind/bug: Fixes a bug discovered during the current release. <detailsAdditional instructions available <a href=""here</a</details
Update: is pending review and should be to the v1.8 Milestone to resolve this issue.
Code change:
"k8s.io/apimachinery/pkg/api/resource" "k8s.io/apimachinery/pkg/types" "k8s.io/apimachinery/pkg/util/sets" <ins> utilfeature "k8s.io/apiserver/pkg/util/feature" "k8s.io/kubernetes/pkg/features" </ins> "k8s.io/kubernetes/pkg/volume" "k8s.io/kubernetes/pkg/volume/util" "k8s.io/legacy-cloud-providers/azure"

Related discussion:
text: <!-- Please only use this template for submitting enhancement requests --What would you like to be : Azure is not listed as "migratable" in could refer to Why is this needed:
/sig azure /assign
Code change:
proxier.portsMap = replacementPortsMap } <ins> // Clear UDP conntrack for port or all conntrack entries when port equal zero. // When a packet arrives, it will not go through NAT table again, because it is not "the first" packet. // The solution is clearing the conntrack. Known issus: // https://github.com/docker/docker/issues/8795 // https://github.com/kubernetes/kubernetes/issues/31983 func (proxier *Proxier) clearUdpConntrackForPort(port int) { var err error = nil glog.V(2).Infof("Deleting conntrack entries for udp connections") if port > 0 { err = proxier.execConntrackTool("-D", "-p", "udp", "--dport", strconv.Itoa(port)) if err != nil && !strings.Contains(err.Error(), noConnectionToDelete) { glog.Errorf("conntrack return with error: %v", err) } } else { glog.Errorf("Wrong port number. The port number must be greater than zero") } } </ins> // Join all words with spaces, terminate with newline and write to buf. func writeLine(buf *bytes.Buffer, words ...string) { buf.WriteString(strings.Join(words, " ") + "n")

Related discussion:
text: When I create PR I will let you know
The PR created: If you want verify it you can easily do it using local cluster Then clone kube-deploy project to create local k8s cluster with image you already created with fixes
Thanks for the fix. This is what we did manually to workaround so it should be good enough for us. It would be even better if you can clear the conntrack entry only for the affected entry, such as destination port, to minimizes the impact. Wondering if that possible? Will try out as well. Thanks.
I wanted do it like you mentioned but unfortunately conntract command doesn't give that possibilities. In parameters you can only pass the source and destination IP addresses.
Sorry didn't get back for a while. I tried the conntrack tool and seems like you can use --dport option: conntrack -D -s 172.27.209.165 -p udp --dport 53 udp 17 63 src=172.27.209.165 dst=171.70.168.183 sport= dport=53 src=171.70.168.183 dst=172.27.209.165 sport=53 dport= [ASSURED] mark=0 use=1 udp 17 33 src=172.27.209.165 dst=171.70.168.183 sport= dport=53 src=171.70.168.183 dst=172.27.209.165 sport=53 dport= [ASSURED] mark=0 use=1 conntrack v1.4.3 (conntrack-tools): 2 flow entries have been deleted.
Thanks for info I will try it
I've updated my PR for flag It works well
It's not clear to me why there would be a conntrack rule for your service port before we add any rules?
We have a router, which configured to export statistics using UDP to our host. That UDP stream is long live. If our host restarted, or we re-deploy our cluster (mainly during development), then udp packets received by host before K8S is provisioned.
But why do you have conntrack rules - simply receiving packets will not cause conntrack to create records.. , dachulin <:
Code change:
disablePreemption        bool percentageOfNodesToScore int32 enableNonPreempting      bool <del> lastProcessedNodeIndex   int </del> <ins> nextStartNodeIndex       int </ins> } // snapshot snapshots scheduler cache and node infos for all fit and priority

Related discussion:
text: What would you like to be : A unit test that verifies the evaluation order of the nodes in the scheduler. Why is this needed: The scheduler evaluates the nodes in a specific order until it finds a pre-defined minimum number of feasible nodes. To give all nodes a fair chance of being evaluated, in each scheduling cycle, the scheduler starts evaluating from where it left off in the previous cycle. This is captured by the parameter in  We need to add a unit test that captures regressions related to this behavior to avoid bugs like /sig scheduling /priority important-soon /help
/assign
/remove-help
Code change:
// Make an update of the DaemonSet which we know will create a hash collision when // the next ControllerRevision is created. <del> _, err = dsClient.Update(ds) if err != nil { t.Fatalf("Failed to update DaemonSet: %v", err) } </del> <ins> ds = updateDS(t, dsClient, ds.Name, func(updateDS *apps.DaemonSet) { updateDS.Spec.Template.Spec.TerminationGracePeriodSeconds = &one }) </ins> // Wait for any pod with the latest Spec to exist err = wait.PollImmediate(100*time.Millisecond, 10*time.Second, func() (bool, error) {

Related discussion:
text: https://k8s- /sig apps /priority critical-urgent /assign PR that the test: /cc
GitHub didn't allow me to assign the following users: mortent. Note that only and repo collaborators can be assigned. For more information please see <detailsIn response to : https://k8s- /priority critical-urgent /assign /cc 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
/kind flake
I'm looking into this.
The test is still flaky, but with different symptom: An example flake: https://k8s- It's likely because the collision count was updated in a previous sync loop, but the in the cache store hasn't been updated and we used a stale collision count while calculating the new hash: /assign
Code change:
{ Name: to.StringPtr("foo"), RegistryProperties: &containerregistry.RegistryProperties{ <del> LoginServer: to.StringPtr("foo-microsoft.azurecr.io"), </del> <ins> LoginServer: to.StringPtr("*.azurecr.io"), </ins> }, }, { Name: to.StringPtr("bar"), RegistryProperties: &containerregistry.RegistryProperties{ <del> LoginServer: to.StringPtr("bar-microsoft.azurecr.io"), </del> <ins> LoginServer: to.StringPtr("*.azurecr.cn"), </ins> }, }, { Name: to.StringPtr("baz"), RegistryProperties: &containerregistry.RegistryProperties{ <del> LoginServer: to.StringPtr("baz-microsoft.azurecr.io"), </del> <ins> LoginServer: to.StringPtr("*.azurecr.de"), }, }, { Name: to.StringPtr("bus"), RegistryProperties: &containerregistry.RegistryProperties{ LoginServer: to.StringPtr("*.azurecr.us"), </ins> }, }, }

Related discussion:
text: <!-- 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: after granting sp access to azure ACR , pull image from ACR would fail, and after wait about 15-30min, pull image would success. Root cause is that needs to be refreshed when doing , otherwise it will always return empty registry list. Related issue: 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.7 - v1.11 Cloud provider or hardware configuration: OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: Others: /sig azure /assign I will implement that function.
Thanks -- can we add a milestone label?
+1. We should fix this within v1.12 release and cherry pick to old releases. /priority critical-urgent /milestone v1.12
/status approved-for-milestone
[MILESTONENOTIFIER] Milestone Issue: Up-to-date for process <details open<summaryIssue Labels</summary- : Issue will be escalated to these SIGs if needed. : Never automatically move issue out of a release milestone; continually escalate to contributor and SIG through all available channels. : Fixes a bug discovered during the current release. </details<details<summaryHelp</summary<ul<li<a href=""Additional instructions</a</li<li<a href=""Commands for setting labels</a</li</ul</details
I'm not sure if this is related, but I'm seeing nodes (after they've been working fine for a few days) randomly start to fail pulling images with the error . Edit: I see this as the culprit: , after which all image pulls start to fail.
this is not related, original issue is that after granting sp access to azure acr, pull image still fails with .
Code change:
{ Name: to.StringPtr("foo"), RegistryProperties: &containerregistry.RegistryProperties{ <del> LoginServer: to.StringPtr("foo-microsoft.azurecr.io"), </del> <ins> LoginServer: to.StringPtr("*.azurecr.io"), </ins> }, }, { Name: to.StringPtr("bar"), RegistryProperties: &containerregistry.RegistryProperties{ <del> LoginServer: to.StringPtr("bar-microsoft.azurecr.io"), </del> <ins> LoginServer: to.StringPtr("*.azurecr.cn"), </ins> }, }, { Name: to.StringPtr("baz"), RegistryProperties: &containerregistry.RegistryProperties{ <del> LoginServer: to.StringPtr("baz-microsoft.azurecr.io"), </del> <ins> LoginServer: to.StringPtr("*.azurecr.de"), }, }, { Name: to.StringPtr("bus"), RegistryProperties: &containerregistry.RegistryProperties{ LoginServer: to.StringPtr("*.azurecr.us"), </ins> }, }, }

Related discussion:
text: After my repro and investigation(really spent a lot of time...), I found the issue lies here, would return empty even after granting sp access to azure acr, and after around 15min, it returns correct loginServer list: Looks like it's a SDK or acr list with specific sp issue, workaround is wait around 15min or more time, it could recover by itself. Paste my investigation logs here, I grant sp access to acr in around , you could see it returns empty registry list first and then after a few more minutes, it returns the correct list with loginServer:
BTW, in v1.12, acr list() uses new API, I will check whether in v1.12 would have same issue. Acutally I have already implemented LazyProvide func(check here: ), while it won't fix the original issue.
Update: After a few more tries, I found it's related to this code snippet, before , we need to generate a new ServicePrincipalToken every time: I will move this code snippet into Provide() func, and send out a PR! The failure recover time is within 2min now.
Code change:
} } <ins> func TestRegisterDuplicatePluginWouldFail(t *testing.T) { plugin := config.Plugin{Name: duplicatePluginName, Weight: 1} pluginSet := config.PluginSet{ Enabled: []config.Plugin{ plugin, plugin, }, } plugins := config.Plugins{} plugins.PreFilter = &pluginSet _, err := NewFramework(registry, &plugins, emptyArgs) if err == nil { t.Fatal("Framework initialization should fail") } if err != nil && !strings.Contains(err.Error(), "already registered") { t.Fatalf("Unexpected error, got %s, expect: plugin already registered", err.Error()) } } </ins> func TestRunScorePlugins(t *testing.T) { tests := []struct { name          string

Related discussion:
text: There is no reason this should be allowed to happen, especially that we can't configure duplicate plugins differently since plugin configs is a separate list . /sig scheduling
/label help-wanted
The label(s) cannot be applied. These labels are supported: <detailsIn response to : /label help-wanted 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
/help-wanted
/help /good-first-issue
/assign
/remove-good-first-issue /remove-help