text:
Rename ocid to criod

Project was renamed from ocid to cri-o so we might as well bite the bullet and rename daemon to criod.
Change all references to ocid to cri-o, and put proper links into man pages and crio.spec file for
provides ocid.

Commit needs to be signed and gofmt server/config.go

Fixed.
@mrunalp PTAL

I am having some second thoughts about the name criod. Should we just keep it simple and call it crio. The client is a test client and its name doesn't matter as much. It could be renamed to crioctl.
WDYT?

Personally would be in favor of crio over criod - there are plenty of projects that use their project name for the main executable (nginx, for example), and crio is easier to say and sounds a lot better than criod to me.

+1 to crio and crioctl

Also, one of the tests failed:
not ok 28 Ensure correct CNI plugin namespace/name/container-id arguments

Is crioctl meant only for CRI-O or is it intended as a general tool for CRI implementations? I thought the crictl name suggested the latter, especially given that it's in its own repository? https://github.com/kubernetes-incubator/cri-tools
Or will there be both crioctl and crictl?

@jawnsy

Or will there be both crioctl and crictl?

The implicit plan is to eventually drop crioctl in favor or crictl. We need to port all our tests to it for example.

@mrunalp Passes tests, I ran through this once again, and now everything is crio and crioctl.

Nice! I think we will run the k8s e2e on this once.

LGTM, couple of possible nits.  Is there any customer facing documentation that we need to touch up that's outside of these changes?

All tests passed with kubernetes e2e node conformance tests. We can address the minor comments in a separate PR.

authors: TomSweeneyRedHat jawnsy mheon mrunalp rhatdan runcom sameo

repo: kubernetes-incubator/cri-o


text:
AWS zone not found with latest container tag

When I use the latest tag creating AWS names doesn't work. When I use the latest defined versions in release on GitHub, it works. I also tried 0.5.11 and 0.5.13, which work.
yaml:
apiVersion: v1
kind: ServiceAccount
metadata:
  name: external-dns
---
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRole
metadata:
  name: external-dns
rules:
- apiGroups: [""]
  resources: ["services"]
  verbs: ["get","watch","list"]
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get","watch","list"]
- apiGroups: ["extensions"]
  resources: ["ingresses"]
  verbs: ["get","watch","list"]
- apiGroups: [""]
  resources: ["nodes"]
  verbs: ["list","watch"]
---
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRoleBinding
metadata:
  name: external-dns-viewer
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: external-dns
subjects:
- kind: ServiceAccount
  name: external-dns
  namespace: default
---
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: external-dns
spec:
  strategy:
    type: Recreate
  template:
    metadata:
      labels:
        app: external-dns
    spec:
      serviceAccountName: external-dns
      containers:
      - name: external-dns
        image: registry.opensource.zalan.do/teapot/external-dns:latest
        args:
        - --aws-zone-type=private
        - --domain-filter=inf.us-west-2.aws.parsablenet.org
        - --log-level=debug
        - --provider=aws
        - --registry=txt
        - --source=service
        - --txt-owner-id=kube

image: registry.opensource.zalan.do/teapot/external-dns:v0.5.14
time="2019-06-03T20:30:15Z" level=debug msg="Considering zone: /hostedzone/Z1HYM5AP1NPUTZ (domain: inf.us-west-2.aws.parsablenet.org.)"
time="2019-06-03T20:30:15Z" level=debug msg="No endpoints could be generated from service kube-system/kubernetes-dashboard"
time="2019-06-03T20:30:15Z" level=debug msg="No endpoints could be generated from service default/beacon-dendrite"
time="2019-06-03T20:30:15Z" level=debug msg="No endpoints could be generated from service default/youbetcha"
time="2019-06-03T20:30:15Z" level=debug msg="No endpoints could be generated from service kube-system/coredns"
time="2019-06-03T20:30:15Z" level=debug msg="No endpoints could be generated from service default/ambassador-admin"
time="2019-06-03T20:30:15Z" level=debug msg="No endpoints could be generated from service default/gutenberg"
time="2019-06-03T20:30:15Z" level=debug msg="No endpoints could be generated from service default/importer"
time="2019-06-03T20:30:15Z" level=debug msg="No endpoints could be generated from service default/kubernetes"
time="2019-06-03T20:30:15Z" level=debug msg="No endpoints could be generated from service default/mothership"
time="2019-06-03T20:30:15Z" level=debug msg="No endpoints could be generated from service default/notifications"
time="2019-06-03T20:30:15Z" level=debug msg="Endpoints generated from service: default/ambassador: [api.kube.inf.us-west-2.aws.parsablenet.org 0 IN CNAME aa7b3a60d712011e9a4e406ff2ff0859-796789769.us-west-2.elb.amazonaws.com [] go.kube.inf.us-west-2.aws.parsablenet.org 0 IN CNAME aa7b3a60d712011e9a4e406ff2ff0859-796789769.us-west-2.elb.amazonaws.com [] report.kube.inf.us-west-2.aws.parsablenet.org 0 IN CNAME aa7b3a60d712011e9a4e406ff2ff0859-796789769.us-west-2.elb.amazonaws.com [] sig.kube.inf.us-west-2.aws.parsablenet.org 0 IN CNAME aa7b3a60d712011e9a4e406ff2ff0859-796789769.us-west-2.elb.amazonaws.com []]"
time="2019-06-03T20:30:15Z" level=debug msg="Skipping endpoint bastion-bastion-01.inf.us-west-2.aws.parsablenet.org 300 IN A 10.100.25.43 [] because owner id does not match, found: \"\", required: \"kube\""
time="2019-06-03T20:30:15Z" level=debug msg="Skipping endpoint emr-emr-master-01.inf.us-west-2.aws.parsablenet.org 300 IN CNAME ip-10-100-6-158.us-west-2.compute.internal [] because owner id does not match, found: \"\", required: \"kube\""
time="2019-06-03T20:30:15Z" level=debug msg="Skipping endpoint kube-kube-master-01.inf.us-west-2.aws.parsablenet.org 300 IN A 10.100.0.20 [] because owner id does not match, found: \"\", required: \"kube\""
time="2019-06-03T20:30:15Z" level=debug msg="Skipping endpoint kube-kube-worker-a8dcfc8d.inf.us-west-2.aws.parsablenet.org 300 IN A 10.100.15.191 [] because owner id does not match, found: \"\", required: \"kube\""
time="2019-06-03T20:30:15Z" level=debug msg="Skipping endpoint kube-kube-worker-eebd2cba.inf.us-west-2.aws.parsablenet.org 300 IN A 10.100.14.104 [] because owner id does not match, found: \"\", required: \"kube\""
time="2019-06-03T20:30:15Z" level=debug msg="Skipping endpoint salt-salt-master-01.inf.us-west-2.aws.parsablenet.org 300 IN A 10.100.5.116 [] because owner id does not match, found: \"\", required: \"kube\""
time="2019-06-03T20:30:15Z" level=debug msg="Skipping endpoint kube-kube-master.inf.us-west-2.aws.parsablenet.org 300 IN CNAME internal-kube-kube-master-internal-elb-2019043210.us-west-2.elb.amazonaws.com [] because owner id does not match, found: \"\", required: \"kube\""
time="2019-06-03T20:30:15Z" level=debug msg="Skipping endpoint kube-kube-worker-8e7a2e2d.inf.us-west-2.aws.parsablenet.org 300 IN A 10.100.16.189 [] because owner id does not match, found: \"\", required: \"kube\""
time="2019-06-03T20:30:15Z" level=debug msg="Skipping endpoint sensu-sensu-redis.inf.us-west-2.aws.parsablenet.org 300 IN CNAME internal-elb-internal-sensu-sensu-redis-983660360.us-west-2.elb.amazonaws.com [] because owner id does not match, found: \"\", required: \"kube\""
time="2019-06-03T20:30:15Z" level=debug msg="Skipping endpoint dns-dns-02.inf.us-west-2.aws.parsablenet.org 300 IN A 10.100.40.10 [] because owner id does not match, found: \"\", required: \"kube\""
time="2019-06-03T20:30:15Z" level=debug msg="Skipping endpoint kube-frodo-worker-f9ba02bd.inf.us-west-2.aws.parsablenet.org 300 IN A 10.100.6.2 [] because owner id does not match, found: \"\", required: \"kube\""
time="2019-06-03T20:30:15Z" level=debug msg="Skipping endpoint kube-kube-worker-d9fe1195.inf.us-west-2.aws.parsablenet.org 300 IN A 10.100.13.154 [] because owner id does not match, found: \"\", required: \"kube\""
time="2019-06-03T20:30:15Z" level=debug msg="Skipping endpoint kube-kube-worker-eda43349.inf.us-west-2.aws.parsablenet.org 300 IN A 10.100.6.228 [] because owner id does not match, found: \"\", required: \"kube\""
time="2019-06-03T20:30:15Z" level=debug msg="Skipping endpoint dns-dns-03.inf.us-west-2.aws.parsablenet.org 300 IN A 10.100.24.10 [] because owner id does not match, found: \"\", required: \"kube\""
time="2019-06-03T20:30:15Z" level=debug msg="Skipping endpoint kube-kube-master-02.inf.us-west-2.aws.parsablenet.org 300 IN A 10.100.8.20 [] because owner id does not match, found: \"\", required: \"kube\""
time="2019-06-03T20:30:15Z" level=debug msg="Skipping endpoint salt-salt-master-02.inf.us-west-2.aws.parsablenet.org 300 IN A 10.100.19.63 [] because owner id does not match, found: \"\", required: \"kube\""
time="2019-06-03T20:30:15Z" level=debug msg="Skipping endpoint sensu-sensu-02.inf.us-west-2.aws.parsablenet.org 300 IN A 10.100.2.124 [] because owner id does not match, found: \"\", required: \"kube\""
time="2019-06-03T20:30:15Z" level=debug msg="Skipping endpoint kube-frodo-master.inf.us-west-2.aws.parsablenet.org 300 IN CNAME internal-kube-frodo-master-internal-elb-1511863099.us-west-2.elb.amazonaws.com [] because owner id does not match, found: \"\", required: \"kube\""
time="2019-06-03T20:30:15Z" level=debug msg="Skipping endpoint kube-frodo-worker-acdffc4e.inf.us-west-2.aws.parsablenet.org 300 IN A 10.100.10.135 [] because owner id does not match, found: \"\", required: \"kube\""
time="2019-06-03T20:30:15Z" level=debug msg="Skipping endpoint dns-dns-01.inf.us-west-2.aws.parsablenet.org 300 IN A 10.100.32.10 [] because owner id does not match, found: \"\", required: \"kube\""
time="2019-06-03T20:30:15Z" level=debug msg="Skipping endpoint kube-frodo-master-02.inf.us-west-2.aws.parsablenet.org 300 IN A 10.100.8.21 [] because owner id does not match, found: \"\", required: \"kube\""
time="2019-06-03T20:30:15Z" level=debug msg="Skipping endpoint kube-frodo-worker-3ffab3c1.inf.us-west-2.aws.parsablenet.org 300 IN A 10.100.7.204 [] because owner id does not match, found: \"\", required: \"kube\""
time="2019-06-03T20:30:15Z" level=debug msg="Skipping endpoint kube-frodo-worker-4d380e6f.inf.us-west-2.aws.parsablenet.org 300 IN A 10.100.11.80 [] because owner id does not match, found: \"\", required: \"kube\""
time="2019-06-03T20:30:15Z" level=debug msg="Skipping endpoint kube-kube-worker-922197cf.inf.us-west-2.aws.parsablenet.org 300 IN A 10.100.7.151 [] because owner id does not match, found: \"\", required: \"kube\""
time="2019-06-03T20:30:15Z" level=debug msg="Skipping endpoint kube-kube-worker-f1bf3de3.inf.us-west-2.aws.parsablenet.org 300 IN A 10.100.11.2 [] because owner id does not match, found: \"\", required: \"kube\""
time="2019-06-03T20:30:15Z" level=debug msg="Skipping endpoint kube-frodo-worker-0bd928a0.inf.us-west-2.aws.parsablenet.org 300 IN A 10.100.5.112 [] because owner id does not match, found: \"\", required: \"kube\""
time="2019-06-03T20:30:15Z" level=debug msg="Skipping endpoint kube-frodo-worker-5b8a3c9f.inf.us-west-2.aws.parsablenet.org 300 IN A 10.100.18.249 [] because owner id does not match, found: \"\", required: \"kube\""
time="2019-06-03T20:30:15Z" level=debug msg="Skipping endpoint kube-frodo-worker-d573b5f4.inf.us-west-2.aws.parsablenet.org 300 IN A 10.100.17.71 [] because owner id does not match, found: \"\", required: \"kube\""
time="2019-06-03T20:30:15Z" level=debug msg="Skipping endpoint scp-scp-01.inf.us-west-2.aws.parsablenet.org 300 IN A 10.100.18.127 [] because owner id does not match, found: \"\", required: \"kube\""
time="2019-06-03T20:30:15Z" level=debug msg="Skipping endpoint salt-salt-master.inf.us-west-2.aws.parsablenet.org 300 IN CNAME internal-salt-salt-master-internal-elb-168990921.us-west-2.elb.amazonaws.com [] because owner id does not match, found: \"\", required: \"kube\""
time="2019-06-03T20:30:15Z" level=debug msg="Skipping endpoint kube-frodo-worker-71b9ce0e.inf.us-west-2.aws.parsablenet.org 300 IN A 10.100.17.240 [] because owner id does not match, found: \"\", required: \"kube\""
time="2019-06-03T20:30:15Z" level=debug msg="Skipping endpoint kube-frodo-worker-e63ca501.inf.us-west-2.aws.parsablenet.org 300 IN A 10.100.7.85 [] because owner id does not match, found: \"\", required: \"kube\""
time="2019-06-03T20:30:15Z" level=debug msg="Skipping endpoint sensu-sensu-03.inf.us-west-2.aws.parsablenet.org 300 IN A 10.100.23.136 [] because owner id does not match, found: \"\", required: \"kube\""
time="2019-06-03T20:30:15Z" level=debug msg="Skipping endpoint kube-kube-master-03.inf.us-west-2.aws.parsablenet.org 300 IN A 10.100.16.20 [] because owner id does not match, found: \"\", required: \"kube\""
time="2019-06-03T20:30:15Z" level=debug msg="Skipping endpoint salt-salt-master-03.inf.us-west-2.aws.parsablenet.org 300 IN A 10.100.8.241 [] because owner id does not match, found: \"\", required: \"kube\""
time="2019-06-03T20:30:15Z" level=debug msg="Skipping endpoint vpn-pritunl-clientvpn-01.inf.us-west-2.aws.parsablenet.org 300 IN A 10.100.38.243 [] because owner id does not match, found: \"\", required: \"kube\""
time="2019-06-03T20:30:15Z" level=debug msg="Skipping endpoint kube-frodo-worker-63dcd850.inf.us-west-2.aws.parsablenet.org 300 IN A 10.100.11.75 [] because owner id does not match, found: \"\", required: \"kube\""
time="2019-06-03T20:30:15Z" level=debug msg="Skipping endpoint sensu-sensu-uchiwa.inf.us-west-2.aws.parsablenet.org 300 IN CNAME internal-elb-internal-sensu-sensu-uchiwa-1041790166.us-west-2.elb.amazonaws.com [] because owner id does not match, found: \"\", required: \"kube\""
time="2019-06-03T20:30:15Z" level=debug msg="Skipping endpoint kube-frodo-master-03.inf.us-west-2.aws.parsablenet.org 300 IN A 10.100.16.21 [] because owner id does not match, found: \"\", required: \"kube\""
time="2019-06-03T20:30:15Z" level=debug msg="Skipping endpoint kube-frodo-worker-2b1bbb09.inf.us-west-2.aws.parsablenet.org 300 IN A 10.100.1.85 [] because owner id does not match, found: \"\", required: \"kube\""
time="2019-06-03T20:30:15Z" level=debug msg="Skipping endpoint kube-frodo-worker-36debfb5.inf.us-west-2.aws.parsablenet.org 300 IN A 10.100.22.123 [] because owner id does not match, found: \"\", required: \"kube\""
time="2019-06-03T20:30:15Z" level=debug msg="Skipping endpoint build-build-01.inf.us-west-2.aws.parsablenet.org 300 IN A 10.100.18.172 [] because owner id does not match, found: \"\", required: \"kube\""
time="2019-06-03T20:30:15Z" level=debug msg="Skipping endpoint kube-frodo-worker-05b968bd.inf.us-west-2.aws.parsablenet.org 300 IN A 10.100.8.173 [] because owner id does not match, found: \"\", required: \"kube\""
time="2019-06-03T20:30:15Z" level=debug msg="Skipping endpoint kube-frodo-worker-2fa3bec3.inf.us-west-2.aws.parsablenet.org 300 IN A 10.100.22.91 [] because owner id does not match, found: \"\", required: \"kube\""
time="2019-06-03T20:30:15Z" level=debug msg="Skipping endpoint kube-kube-worker-ad5b9aeb.inf.us-west-2.aws.parsablenet.org 300 IN A 10.100.18.43 [] because owner id does not match, found: \"\", required: \"kube\""
time="2019-06-03T20:30:15Z" level=debug msg="Skipping endpoint superset-superset-01.inf.us-west-2.aws.parsablenet.org 300 IN A 10.100.9.248 [] because owner id does not match, found: \"\", required: \"kube\""
time="2019-06-03T20:30:15Z" level=debug msg="Skipping endpoint kube-frodo-master-01.inf.us-west-2.aws.parsablenet.org 300 IN A 10.100.0.21 [] because owner id does not match, found: \"\", required: \"kube\""
time="2019-06-03T20:30:15Z" level=debug msg="Skipping endpoint kube-frodo-worker-cf51f6a0.inf.us-west-2.aws.parsablenet.org 300 IN A 10.100.10.92 [] because owner id does not match, found: \"\", required: \"kube\""
time="2019-06-03T20:30:15Z" level=debug msg="Skipping endpoint kube-kube-worker-affd7420.inf.us-west-2.aws.parsablenet.org 300 IN A 10.100.12.17 [] because owner id does not match, found: \"\", required: \"kube\""
time="2019-06-03T20:30:15Z" level=debug msg="Skipping endpoint sensu-sensu-01.inf.us-west-2.aws.parsablenet.org 300 IN A 10.100.12.206 [] because owner id does not match, found: \"\", required: \"kube\""
time="2019-06-03T20:30:15Z" level=debug msg="Considering zone: /hostedzone/Z1HYM5AP1NPUTZ (domain: inf.us-west-2.aws.parsablenet.org.)"
time="2019-06-03T20:30:15Z" level=debug msg="Adding go.kube.inf.us-west-2.aws.parsablenet.org. to zone inf.us-west-2.aws.parsablenet.org. [Id: /hostedzone/Z1HYM5AP1NPUTZ]"
time="2019-06-03T20:30:15Z" level=debug msg="Adding api.kube.inf.us-west-2.aws.parsablenet.org. to zone inf.us-west-2.aws.parsablenet.org. [Id: /hostedzone/Z1HYM5AP1NPUTZ]"
time="2019-06-03T20:30:15Z" level=debug msg="Adding sig.kube.inf.us-west-2.aws.parsablenet.org. to zone inf.us-west-2.aws.parsablenet.org. [Id: /hostedzone/Z1HYM5AP1NPUTZ]"
time="2019-06-03T20:30:15Z" level=debug msg="Adding report.kube.inf.us-west-2.aws.parsablenet.org. to zone inf.us-west-2.aws.parsablenet.org. [Id: /hostedzone/Z1HYM5AP1NPUTZ]"
time="2019-06-03T20:30:15Z" level=debug msg="Adding go.kube.inf.us-west-2.aws.parsablenet.org. to zone inf.us-west-2.aws.parsablenet.org. [Id: /hostedzone/Z1HYM5AP1NPUTZ]"
time="2019-06-03T20:30:15Z" level=debug msg="Adding api.kube.inf.us-west-2.aws.parsablenet.org. to zone inf.us-west-2.aws.parsablenet.org. [Id: /hostedzone/Z1HYM5AP1NPUTZ]"
time="2019-06-03T20:30:15Z" level=debug msg="Adding sig.kube.inf.us-west-2.aws.parsablenet.org. to zone inf.us-west-2.aws.parsablenet.org. [Id: /hostedzone/Z1HYM5AP1NPUTZ]"
time="2019-06-03T20:30:15Z" level=debug msg="Adding report.kube.inf.us-west-2.aws.parsablenet.org. to zone inf.us-west-2.aws.parsablenet.org. [Id: /hostedzone/Z1HYM5AP1NPUTZ]"
time="2019-06-03T20:30:15Z" level=info msg="Desired change: CREATE go.kube.inf.us-west-2.aws.parsablenet.org A"
time="2019-06-03T20:30:15Z" level=info msg="Desired change: CREATE api.kube.inf.us-west-2.aws.parsablenet.org A"
time="2019-06-03T20:30:15Z" level=info msg="Desired change: CREATE sig.kube.inf.us-west-2.aws.parsablenet.org A"
time="2019-06-03T20:30:15Z" level=info msg="Desired change: CREATE report.kube.inf.us-west-2.aws.parsablenet.org A"
time="2019-06-03T20:30:15Z" level=info msg="Desired change: CREATE go.kube.inf.us-west-2.aws.parsablenet.org TXT"
time="2019-06-03T20:30:15Z" level=info msg="Desired change: CREATE api.kube.inf.us-west-2.aws.parsablenet.org TXT"
time="2019-06-03T20:30:15Z" level=info msg="Desired change: CREATE sig.kube.inf.us-west-2.aws.parsablenet.org TXT"
time="2019-06-03T20:30:15Z" level=info msg="Desired change: CREATE report.kube.inf.us-west-2.aws.parsablenet.org TXT"
time="2019-06-03T20:30:15Z" level=info msg="8 record(s) in zone inf.us-west-2.aws.parsablenet.org. were successfully updated"

image: registry.opensource.zalan.do/teapot/external-dns:latest:
time="2019-06-03T20:31:20Z" level=debug msg="Endpoints generated from service: default/ambassador: [api.kube.inf.us-west-2.aws.parsablenet.org 0 IN CNAME aa7b3a60d712011e9a4e406ff2ff0859-796789769.us-west-2.elb.amazonaws.com [] go.kube.inf.us-west-2.aws.parsablenet.org 0 IN CNAME aa7b3a60d712011e9a4e406ff2ff0859-796789769.us-west-2.elb.amazonaws.com [] report.kube.inf.us-west-2.aws.parsablenet.org 0 IN CNAME aa7b3a60d712011e9a4e406ff2ff0859-796789769.us-west-2.elb.amazonaws.com [] sig.kube.inf.us-west-2.aws.parsablenet.org 0 IN CNAME aa7b3a60d712011e9a4e406ff2ff0859-796789769.us-west-2.elb.amazonaws.com []]"
time="2019-06-03T20:31:20Z" level=debug msg="No endpoints could be generated from service default/gutenberg"
time="2019-06-03T20:31:20Z" level=debug msg="No endpoints could be generated from service default/kubernetes"
time="2019-06-03T20:31:20Z" level=debug msg="No endpoints could be generated from service default/mothership"
time="2019-06-03T20:31:20Z" level=debug msg="Skipping record {\n  Action: \"CREATE\",\n  ResourceRecordSet: {\n    AliasTarget: {\n      DNSName: \"aa7b3a60d712011e9a4e406ff2ff0859-796789769.us-west-2.elb.amazonaws.com\",\n      EvaluateTargetHealth: true,\n      HostedZoneId: \"Z1H1FL5HABSF5\"\n    },\n    Name: \"api.kube.inf.us-west-2.aws.parsablenet.org\",\n    Type: \"A\"\n  }\n} because no hosted zone matching record DNS Name was detected "
time="2019-06-03T20:31:20Z" level=debug msg="Skipping record {\n  Action: \"CREATE\",\n  ResourceRecordSet: {\n    AliasTarget: {\n      DNSName: \"aa7b3a60d712011e9a4e406ff2ff0859-796789769.us-west-2.elb.amazonaws.com\",\n      EvaluateTargetHealth: true,\n      HostedZoneId: \"Z1H1FL5HABSF5\"\n    },\n    Name: \"go.kube.inf.us-west-2.aws.parsablenet.org\",\n    Type: \"A\"\n  }\n} because no hosted zone matching record DNS Name was detected "
time="2019-06-03T20:31:20Z" level=debug msg="Skipping record {\n  Action: \"CREATE\",\n  ResourceRecordSet: {\n    AliasTarget: {\n      DNSName: \"aa7b3a60d712011e9a4e406ff2ff0859-796789769.us-west-2.elb.amazonaws.com\",\n      EvaluateTargetHealth: true,\n      HostedZoneId: \"Z1H1FL5HABSF5\"\n    },\n    Name: \"report.kube.inf.us-west-2.aws.parsablenet.org\",\n    Type: \"A\"\n  }\n} because no hosted zone matching record DNS Name was detected "
time="2019-06-03T20:31:20Z" level=debug msg="Skipping record {\n  Action: \"CREATE\",\n  ResourceRecordSet: {\n    AliasTarget: {\n      DNSName: \"aa7b3a60d712011e9a4e406ff2ff0859-796789769.us-west-2.elb.amazonaws.com\",\n      EvaluateTargetHealth: true,\n      HostedZoneId: \"Z1H1FL5HABSF5\"\n    },\n    Name: \"sig.kube.inf.us-west-2.aws.parsablenet.org\",\n    Type: \"A\"\n  }\n} because no hosted zone matching record DNS Name was detected "
time="2019-06-03T20:31:20Z" level=debug msg="Skipping record {\n  Action: \"CREATE\",\n  ResourceRecordSet: {\n    Name: \"api.kube.inf.us-west-2.aws.parsablenet.org\",\n    ResourceRecords: [{\n        Value: \"\\\"heritage=external-dns,external-dns/owner=kube,external-dns/resource=service/default/ambassador\\\"\"\n      }],\n    TTL: 300,\n    Type: \"TXT\"\n  }\n} because no hosted zone matching record DNS Name was detected "
time="2019-06-03T20:31:20Z" level=debug msg="Skipping record {\n  Action: \"CREATE\",\n  ResourceRecordSet: {\n    Name: \"go.kube.inf.us-west-2.aws.parsablenet.org\",\n    ResourceRecords: [{\n        Value: \"\\\"heritage=external-dns,external-dns/owner=kube,external-dns/resource=service/default/ambassador\\\"\"\n      }],\n    TTL: 300,\n    Type: \"TXT\"\n  }\n} because no hosted zone matching record DNS Name was detected "
time="2019-06-03T20:31:20Z" level=debug msg="Skipping record {\n  Action: \"CREATE\",\n  ResourceRecordSet: {\n    Name: \"report.kube.inf.us-west-2.aws.parsablenet.org\",\n    ResourceRecords: [{\n        Value: \"\\\"heritage=external-dns,external-dns/owner=kube,external-dns/resource=service/default/ambassador\\\"\"\n      }],\n    TTL: 300,\n    Type: \"TXT\"\n  }\n} because no hosted zone matching record DNS Name was detected "
time="2019-06-03T20:31:20Z" level=debug msg="Skipping record {\n  Action: \"CREATE\",\n  ResourceRecordSet: {\n    Name: \"sig.kube.inf.us-west-2.aws.parsablenet.org\",\n    ResourceRecords: [{\n        Value: \"\\\"heritage=external-dns,external-dns/owner=kube,external-dns/resource=service/default/ambassador\\\"\"\n      }],\n    TTL: 300,\n    Type: \"TXT\"\n  }\n} because no hosted zone matching record DNS Name was detected "
time="2019-06-03T20:31:20Z" level=info msg="All records are already up to date, there are no changes for the matching hosted zones"

THANK YOU !!! for checking the image, I thought I was going crazy b/c this was working yesterday. Please fix the image.

This should be fixed with #1059

source: gharchive/issue

authors: cmattoon edgan guanzo

repo: kubernetes-incubator/external-dns

license_type: permissive

license_source: bigquery


text:
Fixes issues #577

Add rbac as an option in the Values file, add templates for generating the service account and role bindings.
Pull request based on https://github.com/kubernetes-incubator/external-storage/pull/579.

/area local-volume

/assign

Is not that the case for any/all parameters?
Not sure there is much value in describing it further.
On Tue, 6 Feb 2018 at 17:25, Serguei Bezverkhi notifications@github.com
wrote:

@sbezverk commented on this pull request.
In local-volume/README.md
https://github.com/kubernetes-incubator/external-storage/pull/590#discussion_r166358654
:

@@ -229,15 +227,17 @@ helm template ./helm/provisioner --set engine=gke > ./provisioner/deployment/kub

Parameter **--set engine=** canbe used in conjunction with custom vlues.yaml file in the same command line.

-3. Deploy Provisioner
+Note: By default, common.rbac is set to "true" which generates the necessary ServiceAccount, ClusterRole and ClusterRoleBinding for an RBAC enabled kubernetes cluster.

I think we should add a comment that, common.rbac can be overridden in the
command line if creating those objects is not required. Maybe adding an
example could be useful here too.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<https://github.com/kubernetes-incubator/external-storage/pull/590#pullrequestreview-94408787>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AdweXGtXQD9HAtbdexCvcK69gcLbuCi_ks5tSHzcgaJpZM4R6tXF>
.

/lgtm

Added example in README.md.

And squashed commits into 1.

/lgtm

source: gharchive/pull-request

authors: msau42 nseyvet rootfs

repo: kubernetes-incubator/external-storage


text:
Support insecure registry and enhance parsing of image stream tag

2 enhancements for openshift:

support insecure docker registry for generation of openshift image stream
we add an import policy for the image stream tag by following instruction of the command argument
enhance parsing of image tag
current implementation doesn't support format like "myregistryhost:5000/fedora/httpd:version1.0". Enhance the parsing logic.

Hey @qujinping , Thank you for your patch. This is really nice, we will look at it. But can you please sign the CLA first or else this PR is blocked.

I signed it

@qujinping It look like k8s-ci-robot  is not picking that up :-(
Have you used same email as you have in git commit?
Or you could try push something to your branch so it forces bot to recheck.

ping @cdrage @surajssd

@qujinping Almost there! Thanks a lot for this contribution. The code LGTM.
One thing that needs to be adding is here: https://github.com/qujinping/kompose/blob/e4302af6fe3fdf7eb9944438cd13022f2e62f2a5/cmd/convert.go#L147
Since we have a custom output for --help an entry for Insecure Registry should be there.
I also have another comment in regards to the description which I'll put in a code review.

@cdrage, thanks for your comment, accepted.
Pls review my update.

I close this PR because I messed things up while merging from upstream.
A new PR will be created instead. Very sorry for the inconvenience.

authors: cdrage kadel pradeepto qujinping

repo: kubernetes-incubator/kompose

license_source: github-api


text:
kubespray deployment couldn't reach the nodes (master/etcd/worker) behind bastion

Is this a BUG REPORT or FEATURE REQUEST? (choose one):
BUG REPORT
I'm trying to use the Terraform (from contrib/terraform) to launch the infrastructure, which has all the nodes behind bastion, and then use kubespray to configure the kubernetes cluster.    However, the deploy failed with "UNREACHABLE" to all nodes.
Environment:

Cloud provider or hardware configuration: : AWS

OS (printf "$(uname -srm)\n$(cat /etc/os-release)\n"):
Linux 4.4.0-1049-aws x86_64
NAME="Ubuntu"
VERSION="16.04.3 LTS (Xenial Xerus)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 16.04.3 LTS"
VERSION_ID="16.04"
HOME_URL="http://www.ubuntu.com/"
SUPPORT_URL="http://help.ubuntu.com/"
BUG_REPORT_URL="http://bugs.launchpad.net/ubuntu/"
VERSION_CODENAME=xenial
UBUNTU_CODENAME=xenial

Version of Ansible (ansible --version):
ansible 2.4.2.0

Kubespray version (commit) (git rev-parse --short HEAD):
da17361
Network plugin used:
calico
Copy of your inventory file:
[all]
kubernetes-k8s-test-master0 ansible_host=10.250.197.154
kubernetes-k8s-test-master1 ansible_host=10.250.211.20
kubernetes-k8s-test-master2 ansible_host=10.250.202.75
kubernetes-k8s-test-worker0 ansible_host=10.250.197.191
kubernetes-k8s-test-worker1 ansible_host=10.250.217.184
kubernetes-k8s-test-worker2 ansible_host=10.250.195.245
kubernetes-k8s-test-worker3 ansible_host=10.250.213.139
kubernetes-k8s-test-etcd0 ansible_host=10.250.207.12
kubernetes-k8s-test-etcd1 ansible_host=10.250.215.196
kubernetes-k8s-test-etcd2 ansible_host=10.250.195.61
bastion ansible_host=52.53.200.37
bastion ansible_host=13.57.36.236
[kube-master]
kubernetes-k8s-test-master0
kubernetes-k8s-test-master1
kubernetes-k8s-test-master2
[kube-node]
kubernetes-k8s-test-worker0
kubernetes-k8s-test-worker1
kubernetes-k8s-test-worker2
kubernetes-k8s-test-worker3
[etcd]
kubernetes-k8s-test-etcd0
kubernetes-k8s-test-etcd1
kubernetes-k8s-test-etcd2
[k8s-cluster:children]
kube-node
kube-master
[k8s-cluster:vars]
apiserver_loadbalancer_domain_name="kubernetes-elb-k8s-test-1065579689.us-west-1.elb.amazonaws.com"
Command used to invoke ansible:
ansible-playbook -vvvv -b --user=ubuntu -i inventory/hosts cluster.yml -e ansible_user=ubuntu -e ansible_ssh_private_key_file=~/.ssh/terraform-k8s-test.pem
Output of ansible run:

https://gist.github.com/ctlam/2eb792daff3ba15b7c9162b398f42a48
Anything else do we need to know:
I actually have a fix on my own fork: https://github.com/ctlam/kubespray/commit/5712f7e91c93a060660f84308a525abc958c3c6f
It seems the ansible_ssh_common_args is not including the ansible_ssh_private_key_file. The line6, line9, line12, line15 from the gist above shows shows then ansible tried to ssh into the nodes behind the bastion, it's not using the private key file, thus, it's not going through the bastion properly.  I see similar logic is in the roles/bastion-ssh-config/:  https://github.com/kubernetes-incubator/kubespray/blob/master/roles/bastion-ssh-config/templates/ssh-bastion.conf#L19  I think we just need similar logic here.

@ctlam if this issue is fixed then please close it. Thanks

authors: ctlam rsjethani

repo: kubernetes-incubator/kubespray


text:
Allow retries for instances with Failed condition after spec changes

Implementation of item number 2. from the checklist https://github.com/kubernetes-incubator/service-catalog/issues/1715#issuecomment-366857230
After this change we should be able to retry after receiving 400 Bad Request from broker as soon as we change the spec.

This needs to wait on #1748, right? Otherwise, if the user tries to update an instance that failed to provision, then the controller will attempt to send an update request to the broker, instead of a provision request.

We should also remove the Failed condition when we're starting the new operation.

@kibbles-n-bytes yes, you're right, I do this in #1748

@staebler yes, I think both this PR and #1765 depend on #1748.
Will add a do-not-merge label.

The only issue with allowing retries for instances with Failed:True after updating the spec is that if we exhausted retries for orphan mitigation, it will lead to provisioning without retrying the orphan mitigation first.
See https://github.com/kubernetes-incubator/service-catalog/issues/1771#issuecomment-369104345

LGTM

authors: n3wscott nilebox staebler

repo: kubernetes-incubator/service-catalog


text:
Update kustomize tool path

$(TOOLBIN)/kustomize was refactored to use the absolute path.

/assign @barney-s

repo: kubernetes-sigs/application


text:
Add exec sync timeout test.

Signed-off-by: Lantao Liu lantaol@google.com

/lgtm

authors: Random-Liu runcom

repo: kubernetes-sigs/cri-tools


text:
How to disable TLS?

I noticed that the descheduler by default creates TLS certs on startup. Is there a way to disable this behaviour while still providing  a health and metrics endpoint?
In our Kubernetes cluster TLS is handled by the service mesh, so there is no need for the descheduler to do this.
I can see that there is a --secure-port flag that is documented with
The port on which to serve HTTPS with authentication and authorization. If 0, don't serve HTTPS at all.
But unfortunately the application crashes when I try to specify that option so I can't check if this is the behaviour I want (I can create a separate bug ticket for this if it helps).

Does it cause issues with the service-mesh mTLS?

Not the service mesh, but with another component that is supposed to check the uptime of the descheduler.
I think having TLS on by default is a good idea, but it would be nice to have an option to disable it if required.

/kind support

authors: damemi psontag

repo: kubernetes-sigs/descheduler


text:
Rename Helm chart

Now that the helm/chart-releaser and helm/chart-releaser-action can support creating a custom tag name for helm chart release the descheduler helm chart no longer needs to be named to avoid tag collisions.
This PR updates the CI tooling for helm, renames the descheduler helm chart to descheduler from descheduler-helm-chart and updates the related documentation.
On applying this merge request the existing helm charts will not be modified or removed and only future releases will be impacted. My suggestion would be to use the helm/chart-releaser with the --commit flag to re-create the existing charts with the new name in parallel.

@seanmalloy is this something you could look at?

@ingvagabund @k82cn could you let me know if there is anything else you need to approve this for testing?

@stevehipwell appologies, I have no knowledge of helm. @damemi and @seanmalloy were participating in the effort.

@damemi I think I missed the fact that the helm/chart-releaser-action could provide arguments to the helm/chart-releaser as environment variables rather than just as CLI arguments. I went through the code again after the v1.1.0 release and figured out how it should work.
As far as helm/chart-releaser-action#37 goes I'll close it once this is proven to work.

@ingvagabund apologies, I missed off @damemi from my original comment and then when @seanmalloy didn't reply I saw that you and @k82cn were listed as the reviewers so tried you.

/lgtm

@seanmalloy I could have a go at the manual chart creation and create a PR to add the correctly named charts to the gh-pages branch if that would be helpful?

@seanmalloy I could have a go at the manual chart creation and create a PR to add the correctly named charts to the gh-pages branch if that would be helpful?

@stevehipwell sounds good to me.

@seanmalloy I've just looked into this further and realised that someone will need to do it on this repo; I've documented the steps below as best as I can figure out. These steps assume, correctly I think, that the current chart is backwards compatible with all existing releases.
The setup steps are below.

Install the helm/chart-releaser and add to path
Navigate to repo root and make sure the branch is set to master
Get GitHub auth token and export it as CR_GH_TOKEN

I think we want to release the following charts; one for each release with a Docker image.
version: 0.19.1
appVersion: 0.19.0

version: 0.18.2
appVersion: 0.18.0

version: 0.10.0
appVersion: 0.10.0

For each block above follow these steps to package the charts.

Modify ./charts/descheduler/Chart.yaml with the content of the block
Run cr package ./charts/descheduler

The following steps should be completed once all the charts have been packaged.

Run cr upload --token "${CR_GH_TOKEN}" --release-name-template "descheduler-helm-chart-{{ .Version }}" --owner kubernetes-sigs --git-repo descheduler
Run cr index --token "${CR_GH_TOKEN}" --release-name-template "descheduler-helm-chart-{{ .Version }}" --owner kubernetes-sigs --git-repo descheduler --charts-repo https://kubernetes-sigs.github.io/descheduler

As an aside I'd also suggest removing everything from the gh-pages branch that isn't index.yaml.

@stevehipwell  thanks for the info. Between myself @and @damemi we will sort this out.

Do we need to manually merge to the gh-pages branch? We run the chart-releaser action when any PRs merge against the release-* branches, so could it be done that way?

@damemi the steps I've outlined above should be correct to add renamed releases without needing any manual commits. Moving forwards, the same process as previously should work.

@seanmalloy & @damemi it looks like it would be best practice to deprecate the descheduler-helm-chart releases when creating the new descheduler releases as suggested by https://github.com/kubernetes/autoscaler/issues/3475#issuecomment-733398751. Based on https://github.com/kubernetes-sigs/descheduler/pull/444#issuecomment-733123444 my suggestion would be to add the following block to the ones I put above for the manual process to release a deprecated version. This would mean using a chart version 0.19.2 instead of 0.19.1 for for the actual v0.19.0 chart re-release as the repo tags need to be unique for each release.
name: descheduler-helm-chart
version: 0.19.1
appVersion: 0.19.0
maintainers: []
deprecated: true

Coming back to this, I'm not totally clear on the difference between running the steps listed above (https://github.com/kubernetes-sigs/descheduler/pull/436#issuecomment-729870148) vs backporting the changes from this PR to the release branches.
@stevehipwell I understand that running the chart-releaser tool locally removes the need for making manual changes, but I think it would actually be ideal if this could be done through the regular PR workflow for history tracking. If it's possible we should try not to push changes to this repo without the usually review/approval steps.
Could you clarify some more if I'm misunderstanding a necessary step in your process that wouldn't be covered by backporting these changes to the release branches in github? (And thank you for your help in leading our helm changes 🙂)

@damemi you should be able to do this via backporting. Each release would need two PRs, one to deprecate the old chart and a second to add the new chart. Would you like me to open these for both 1.18 and 1.19? If it works I could open a single PR to create a chart for 1.17.

@damemi on a slightly separate note is anyone in this team part of the https://artifacthub.io/ kubernetes-sig organisation? If so you should be able to move the organisation ownership of this repo to the organisation; RE https://github.com/kubernetes-sigs/metrics-server/issues/572#issuecomment-740496665.

@stevehipwell if it's not too much work for you, that would be very helpful! And with 1.20 coming soon, we will only need to support back to 1.18 (so I don't think creating a 1.17 chart is necessary, if I'm wrong though feel free to create that PR as well)
For the artifacthub org, I don't think any of us are part of it. We can track that in a new issue, because that sounds like a good idea to get set up. Thanks!

I'll create the MRs, I suspect that you do want a 1.17 version as if you look at the cloud providers supported versions 1.17 isn't going away any time soon. I'll flag the PRs as draft, who should I assign them to once they're all done?
RE artefact hub, it might be worth messaging @scottrigby on that metrics-server thread to get some of you added to the organisation. Currently this repo is part of the Helm catch all organisation which I think is from the migration from the original helm hub.

Feel free to assign them to me, and I'll approve (and make sure the chart-releaser github action runs).
We'll look more into the artifacthub org, thanks for linking to someone we can talk to over there

@damemi there are now 3 PRs that need to be released in order to rename the charts, I'm just about to assign you and remove the draft flag.
PR https://github.com/kubernetes-sigs/descheduler/pull/458
PR https://github.com/kubernetes-sigs/descheduler/pull/457
PR https://github.com/kubernetes-sigs/descheduler/pull/459
After this has been done you might want to backport the latest chart changes onto the release branches and create a v0.17 chart release.

Thanks @stevehipwell! I'll review those PRs and if come to you with any questions :)

authors: damemi ingvagabund seanmalloy stevehipwell


text:
Add imagePullPolicy to helm chart controllermanager deployment template

Add missing imagePullPolicy option to the helm chart's controllermanager deployment template and add support for it in the deploy federation script. If you want to change the policy to Always for example, just set IMAGE_PULL_POLICY=Always when invoking the deploy-federation.sh script.
This also adds a .helmignore file to avoid helm parsing errors while editing the chart.

LGTM

/lgtm

authors: font marun xunpan


text:
Add ability to sort parallel step by status

It will be great to have sort parallel step by status, especially when you have multiple jobs that you are triggering with parallel
In my case, it can be wonderful to see jobs that are still in progress in the head of the parallel list.

sorry, wrong git repo

repo: kubernetes-sigs/gateway-api


text:
Updates Envoy Gateway Implementation Details

Signed-off-by: danehans daneyonhansen@gmail.com
What type of PR is this?
/kind documentation
What this PR does / why we need it:
Updates Envoy Gateway details in the implementation docs page.

Fixes a broken link.
Fixes grammar.
Simplifies messaging.

Does this PR introduce a user-facing change?:
NONE

cc: @youngnick

Thanks @danehans!
/lgtm
/approve

authors: danehans robscott


text:
Fix GEP template - status link was wrong

Status definitions were pointing to the wrong file

/ok-to-test


text:
fix: Ignore released volumes when deleting a node

Fixes #1684
Description
Ignore released volumes when waiting for volume attachments
When deciding whether a node can be terminated, ignore persistent
volumes that have already been released (perhaps attached to a pod
that has since been drained)
How was this change tested?
Using make test. This change is split into two commits, the first is a test that fails before the change in the second commit and succeeds afterwards
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

#1700 may supersede this PR

This PR is no longer necessary

repo: kubernetes-sigs/karpenter


text:
Support JobSet in Kueue

What would you like to be added:
The ability to control JobSet startup through Kueue.
Why is this needed:
To support a wide variety of workloads
Completion requirements:
This enhancement requires the following artifacts:

[ ] Design doc
[ ] API change
[ ] Docs update

The artifacts should be linked in subsequent comments.

The first release of jobset came up https://github.com/kubernetes-sigs/jobset/releases/tag/v0.1.0

/assign @trasc

/assign

/unassign @trasc

I helped write the suspend code in Jobset so feel free to tag if you find issues.

For initially unsuspend, setting NodeAffinity foreach  ReplicatedJob Template should be enough.
But if the jobs are already created the node selectors should be updated on each of them.
I propose to do that in jobset_contolled in resumeJobSetIfNecessary function on Jobset Operator.

@mcariatm is working on this at the jobset side.
https://github.com/kubernetes-sigs/jobset/issues/134

So it will take a bit of time.

Yes, I'm still working on it. On both sides kueue and jobset. I think tomorrow I will put all changes for kueue. Working on tests now.

authors: alculquicondor kannon92 mcariatm tenzen-y

repo: kubernetes-sigs/kueue


text:
Perform finalize processes when job is deleting

What type of PR is this?
/kind bug
What this PR does / why we need it:
If the job is deleting, perform finalize processes. This can prevent the deletion of finalizers in the plain pod integration.
Which issue(s) this PR fixes:

Fixes #
Special notes for your reviewer:
Does this PR introduce a user-facing change?

Fix a bug that plain pods managed by kueue will remain a terminating condition forever.

/label tide/merge-method-merge

cc @nstogner
/assign @trasc @mimowo

/cherry-pick release-0.5

/kind bug

/release-note-edit
Fix a bug that plain pods managed by kueue will remain in a terminating state, due to a finalizer

authors: alculquicondor tenzen-y


text:
[kjobctl] Add Slurm mode

What type of PR is this?

/kind feature
What this PR does / why we need it:
Add Slurm mode on kjobctl.
Which issue(s) this PR fixes:

Fixes #
Special notes for your reviewer:
Does this PR introduce a user-facing change?

NONE

/cc @mbobrovskyi

@IrvingMg Thank you for this effort. BTW, could you share the context, objectives, and motivations for this enhancement in the dedicated issue?

@IrvingMg Thank you for this effort. BTW, could you share the context, objectives, and motivations for this enhancement in the dedicated issue?

Sure. The summary is that this enhancement is part of KJobctl, an experimental tool to submit batch jobs quickly. Over the last couple of months, we've been adding support for some job types such as the plain K8s Job, RayJob, among others; so now we want to allow execution of bash scripts following a SLURM-like approach, making the experience of using Kjobctl similar to the sbatch command.
However, I think @mwielgus is the right person to provide more information, if needed :)

@IrvingMg Thank you for this effort. BTW, could you share the context, objectives, and motivations for this enhancement in the dedicated issue?

Yeah, I would like to clarify the motivations and context for this feature since we do not support Slurm in the Kueue controller manager, and we used to claim that the K8s has many advantages for the HPC environments rather than Slurm, then we used to recommended use the K8s instead of Slurm.

/test pull-kueue-test-kjobctl

Good job! LGTM.

@mwielgus Could you please check?

Just one question - where the set of environment variables is built?

We are building it on the slurm builder:
https://github.com/kubernetes-sigs/kueue/blob/6670fb4b2ca1424bbe459500b0f7b53aa5799980/cmd/experimental/kjobctl/pkg/builder/slurm_builder.go#L456-L474
This will create an entrypoint.sh wrapper, set and export environment variables, and execute the script.sh.

Cool, thanks!
/lgtm

/cc @alculquicondor

/lgtm
/approve

@IrvingMg Thank you for this effort. BTW, could you share the context, objectives, and motivations for this enhancement in the dedicated issue?

Yeah, I would like to clarify the motivations and context for this feature since we do not support Slurm in the Kueue controller manager, and we used to claim that the K8s has many advantages for the HPC environments rather than Slurm, then we used to recommended use the K8s instead of Slurm.

Ah, now I understand that this PR motivation. This command simulates the slurm command. So, even if we use this command, we keep using the Kubernetes cluster, right?

Ah, now I understand that this PR motivation. This command simulates the slurm command. So, even if we use this command, we keep using the Kubernetes cluster, right?

Exactly.

Ah, now I understand that this PR motivation. This command simulates the slurm command. So, even if we use this command, we keep using the Kubernetes cluster, right?

Exactly.

Thanks for the confirmation. That is a great feature!

It's a command line translation layer, there is no actual slurm involved.

authors: IrvingMg alculquicondor mbobrovskyi mwielgus tenzen-y


text:
Add a pod stage for failing a container

What type of PR is this?

/kind feature
What this PR does / why we need it:
The PR adds a pod stage that injects an error to a regular container for reliability and fault tolerance testing.
Which issue(s) this PR fixes:

Fixes #
Special notes for your reviewer:
Does this PR introduce a user-facing change?

Support reliability and fault-tolerance testing by injecting failure to a container

Additional documentation e.g., KEPs (Kubernetes Enhancement Proposals), usage docs, etc.:

/cc @wzshiming

/assign @wzshiming

/approve
/lgtm

repo: kubernetes-sigs/kwok


text:
Release v0.4.0

Release Checklist

[ ] All OWNERS must LGTM the release proposal
[x] Verify that the changelog in this issue is up-to-date
[x] For major or minor releases (v$MAJ.$MIN.0), create a new release branch.

[x] an OWNER creates a vanilla release branch with
git branch release-$MAJ.$MIN main
[x] An OWNER pushes the new release branch with
git push release-$MAJ.$MIN

[x] Update things like README, deployment templates, docs, configuration, test/e2e flags.
Submit a PR against the release branch:
[x] An OWNER prepares a draft release

[x] Write the change log into the draft release.
[x] Run
make artifacts IMAGE_REGISTRY=registry.k8s.io/lws GIT_TAG=$VERSION
to generate the artifacts and upload the files in the artifacts folder
to the draft release.

[x] An OWNER creates a signed tag running
git tag -s $VERSION
and inserts the changelog into the tag description.
To perform this step, you need a PGP key registered on github.
[x] An OWNER pushes the tag with
git push $VERSION

Triggers prow to build and publish a staging container image
gcr.io/k8s-staging-lws/lws:$VERSION

[x] Submit a PR against k8s.io,
updating k8s.gcr.io/images/k8s-staging-lws/images.yaml to
promote the container images
to production:
[x] Wait for the PR to be merged and verify that the image registry.k8s.io/lws/lws:$VERSION is available.
[x] Publish the draft release prepared at the Github releases page.
[x] Add a link to the tagged release in this issue:
[x] Send an announcement email to sig-apps@kubernetes.io, sig-scheduling@kubernetes.io and wg-batch@kubernetes.io with the subject [ANNOUNCE] LeaderWorkerSet $VERSION is released
[x] Add a link to the release announcement in this issue:
[x] For a major or minor release, update README.md and docs/setup/install.md
in main branch:
[x] For a major or minor release, create an unannotated devel tag in the
main branch, on the first commit that gets merged after the release
branch has been created (presumably the README update commit above), and, push the tag:
DEVEL=v0.$(($MAJ+1)).0-devel; git tag $DEVEL main && git push $DEVEL
This ensures that the devel builds on the main branch will have a meaningful version number.
[ ] Close this issue

Changelog

### Tasks
- [ ] https://github.com/kubernetes-sigs/lws/issues/161

@ahg-g and @kerthcet could you approve this?

/lgtm

image release PR: https://github.com/kubernetes/k8s.io/pull/7295

release issue link: https://github.com/kubernetes-sigs/lws/releases/tag/v0.4.0

LGTM

authors: ahg-g kerthcet liurupeng

repo: kubernetes-sigs/lws


text:
HNC: consider preventing orphans

Currently, HNC lets you delete parents of full namespaces without any restrictions, e.g.:
k create ns parent
k create ns child
k hns set child -p parent
k delete ns parent # ok; `child` now has CritParentMissing

Since our admission webhooks stop you from creating most other critical conditions, I'm wondering if we should do the same thing here? E.g., maybe we should insist that all (full) children are removed from this tree before allowing deletion? Or maybe it would need to integrate with allowCascadingDelete in some way (though this isn't really cascading deletion so we may need a new name for it).

/assign @yiqigao217
Again this isn't for HNC v0.4

/remove-lifecycle stale

/remove-lifecycle rotten
On Thu, Dec 10, 2020 at 10:43 AM fejta-bot notifications@github.com wrote:

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.
If this issue is safe to close now please do so with /close.
Send feedback to sig-testing, kubernetes/test-infra and/or fejta
https://github.com/fejta.
/lifecycle rotten
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/kubernetes-sigs/multi-tenancy/issues/717#issuecomment-742602242,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AE43PZBLYNVLWK63DXB7UWTSUDUDNANCNFSM4M76XLPA
.

/remove-lifecycle stale
@adrianludwin this can remain in backlog and not into v0.8 milestone.

/remove-lifecycle rotten

Moved to https://github.com/kubernetes-sigs/hierarchical-namespaces/issues/30
/close

repo: kubernetes-sigs/multi-tenancy


text:
Change subnamespace object to SubnamespaceAnchor

This is a breaking change; the HierarchicalNamespace object is replaced
with the SubnamespaceAnchor object. Otherwise, there are no changes
(including to the UX).
Tested: manual + all tests continue to pass

/assign @yiqigao217
/assign @rjbez17

If this is a breaking change, shouldn't we at a minimum rev to v1alpha2?

We've made breaking changes in "v1alpha1" in every version of HNC up until
now. We should probably be more cautious in the future (e.g. once we move
to our own repo and start having real users) but personally I'd like to
take advantage of the fact that, AFAIK, no-one will be badly impacted if we
do this today.
On Mon, May 11, 2020 at 10:54 AM Ryan Bezdicek notifications@github.com
wrote:

If this is a breaking change, shouldn't we at a minimum rev to v1alpha2?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/kubernetes-sigs/multi-tenancy/pull/704#issuecomment-626755019,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AE43PZCAR3JMPX3PE5IBSZTRRAGR3ANCNFSM4M5L4MMA
.

Yeah, I was just thinking about the (hopefully soon) move to a real repo and wondered when we should start following those practices. I'm good with waiting until then.

sgtm!
On Mon, May 11, 2020 at 11:35 AM Ryan Bezdicek notifications@github.com
wrote:

Yeah, I was just thinking about the (hopefully soon) move to a real repo
and wondered when we should start following those practices. I'm good with
waiting until then.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/kubernetes-sigs/multi-tenancy/pull/704#issuecomment-626779637,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AE43PZG2AMYIS7RV7R3ILI3RRALNVANCNFSM4M5L4MMA
.

/lgtm
/hold

/lgtm
/approve
/hold cancel


text:
[stable/*] bump dependency mariadb 1.0.2

PRs to review

[ ] drupal #1925
[ ] ghost #1926
[ ] jasterreports #1927
[ ] jooma #1928
[ ] magento #1929
[ ] mediawiki #1930
[ ] moodle #1931
[ ] opencart #1932
[ ] orangehrm #1933
[ ] osclass #1934
[ ] owncloud #1935
[ ] phabricator #1936
[ ] phpbb #1937
[ ] prestashop #1938
[ ] redmine #1939
[ ] sugarcrm #1940
[ ] suitecrm #1941
[ ] testlink #1942
[ ] wordpress #1943

Background
PRs opened using my dependency version bump utility script. See:

https://github.com/kubernetes/helm/issues/1947
https://github.com/kubernetes/helm/pull/2041
https://github.com/kubernetes/helm/issues/2205

This one is on hold until #2004 is merged:
From  @prydonius on Slack:

there is a PR for updating the storageClass pattern in MariaDB but it hasn't been merged yet. We should merge that first, and then update the other PRs for storageClassName to pull in the new mariadb before merging

This issue will also be updated to MariaDB v1.0.3:
From @mgoodness on Slack:

@scottrigby I merged MariaDB to v1.0.3 this morning. how do you want to handle the v1.0.2 dependency bump PRs?

Tl;dr, I'm going to close the 1.0.2 PRs, and reopen 0.1.3 equivalents, and edit this issue to point to those new PRs.

repo: kubernetes/charts


text:
[stable/kubernetes-dashboard] Add extraArgs to kubernetes-dashboard

Adds extraArgs to stable/kubernetes-dashboard.
Use-case:
I'd like to add --enable-insecure-login because I get a certificate from cert-manager and set it on Ingress, and don't get the login view without it.

/assign @mattfarina

cc @kfox1111
/ok-to-test

Thought I had done a commit for that yesterday after looking at CircleCI, guess I forgot to push it.
I replaced the loop with {{ toYaml .Values.extraArgs | indent 10 }} after looking at a few other charts, I think it looks cleaner.

lgtm

/lgtm

authors: filoozom kfox1111 mattfarina unguiculus


text:
[stable/fluent-bit] Allow mounting any file from the config map

This is just a wild idea and solution for the following problem: certain output plugins require files to be mounted (certificates, private keys, etc). Until now from the config map only the config file got mounted. With this change any file in the config map.
I'm open to suggestions (separate configmap, separate secret, config option in values file, etc) as I'm not really fond of this idea TBH.
/cc @kfox1111 @edsiper

The problem is, there are other files in that location. Either we would have to pull them into the configmap too or find some other solution.
This is a general problem with Helm I think. I would like for end users to be able to override things in the template itself without having to fork/patch the template themselves. I'm going to be talking about it at the Helm Summit coming up...
In the mean time, I think what I'd recommend is some kind of extraVolume and extraVolumeMounts section so that users themselves can slide in any extra secrets/configfiles/mounts as needed. Is that something you would be interested in implementing?

Sure thing! Great idea!


text:
[stable/lemonldap-ng-ingress] New chart

For https://github.com/lemonldap-ng-controller/lemonldap-ng-controller.

Current as of b1521b3d98088662367a246314e55881ce4e14dc.

Thanks for the PR. It looks like you just copied the Nginx ingress chart and added the additional stuff. This is not ideal. It creates redundancy and updates to the Nginx ingress chart won't be reflected here. A better option would probably be to add support for arbitrary sidecars to the Nginx ingress chart. This would allow you to configure it for LemonLDAP.
Here's an example of a chart doing this:
https://github.com/kubernetes/charts/blob/4c2f507494905fb020392d03b18c52dae367c4ee/stable/neo4j/templates/core-statefulset.yaml#L85-L87

Abandoned in favor of #3983.

authors: sathieu unguiculus


text:
Unable to specify a namespace for ingressclass which fails due to lack fo permissions

This line of code here:
https://github.com/kubernetes/client-go/blob/master/kubernetes/typed/networking/v1beta1/ingressclass.go#L39
Unlike many of the other apis, it does not accept a namespace name parameter, which results in a query at the cluster scope.
In my cluster we have it setup with multi-tenancy and most users do not have permissions to query for resources at the cluster level.
I'd be happy to make a pull request which adds this support but I'm wondering if anyone knows a reason why it was omitted from this resource? Was it done so intentionally?

Related to https://github.com/nginxinc/kubernetes-ingress/issues/1673

Not actually an issue, we're actually using some namespaced version of a custom resource. Not any problem in this repo though I will say that it would probably make sense for IngressClass to be namespaced instead of put at the cluster level for this reason.

repo: kubernetes/client-go


text:
Add config file for enabling multi-zone e2e test.

Fixes #176
Release note:
None

/sig testing

/ok-to-test

repo: kubernetes/cloud-provider-azure


text:
Dual Stack Octavia - Buggy Behavior / Not Working Correctly - Can Not Make An IPv6 Load Balancer nor Dual Stack

Why is this requesting an IPv4 VIP ?! Cam i ONLY have Single Stack in the cloud.yaml !?
What do i need in "address-sort-order" under network to correct this behavior.... ?  I have two default routes (ipv6 and IPv4)
[Router]
router-id=66edcd05-f9c3-45ca-9356-3779840d9185  <- Dual Stack Router with 0::/0 and 0.0.0.0/0 routes

[LoadBalancer]
use-octavia=true
network-id=f98de447-6357-41bb-971e-fa21b1721a0c <- Dua; Stck Subnet
floating-network-id=a027ee56-79ab-4dd9-ada3-4d56eece242d <- Dual Stack Subnet

apiVersion: v1
kind: Service
metadata:
  name: hostname-server
  namespace: default
  labels:
    app.kubernetes.io/name: hostname-server
spec:
  ipFamilyPolicy: SingleStack
  ipFamilies:
  - IPv6
  type: LoadBalancer
  selector:
    app.kubernetes.io/name: MyApp
  ports:
  - port: 80
    protocol: TCP
    targetPort: 8080

root@5net-k8s-master-1:~/kubernetes# kubectl describe svc hostname-server
Name:                     hostname-server
Namespace:                default
Labels:                   app.kubernetes.io/name=hostname-server
Annotations:              <none>
Selector:                 app.kubernetes.io/name=MyApp
Type:                     LoadBalancer
IP Family Policy:         SingleStack
IP Families:              IPv6
IP:                       fc00:db8:42:1::a362
IPs:                      fc00:db8:42:1::a362
Port:                     <unset>  80/TCP
TargetPort:               8080/TCP
NodePort:                 <unset>  31366/TCP
Endpoints:                <none>
Session Affinity:         None
External Traffic Policy:  Cluster
Events:
  Type     Reason                  Age              From                Message
  ----     ------                  ----             ----                -------
  Warning  SyncLoadBalancerFailed  6s               service-controller  Error syncing load balancer: failed to ensure load balancer: error creating loadbalancer kube_service_kubernetes_default_hostname-server: error creating loadbalancer {"name":"kube_service_kubernetes_default_hostname-server","description":"Kubernetes external service default/hostname-server from cluster kubernetes","vip_network_id":"f98de447-6357-41bb-971e-fa21b1721a0c","provider":"amphora","listeners":[{"protocol":"TCP","protocol_port":80,"name":"listener_0_kube_service_kubernetes_default_hostname-server","default_pool":{"lb_algorithm":"ROUND_ROBIN","protocol":"TCP","name":"pool_0_kube_service_kubernetes_default_hostname-server","members":[{"address":"2606:8180:5001:4004::211","protocol_port":31366,"name":"5net-k8s-worker-1"},{"address":"2606:8180:5001:4004::c1","protocol_port":31366,"name":"5net-k8s-worker-2"},{"address":"2606:8180:5001:4004::168","protocol_port":31366,"name":"5net-k8s-worker-3"}]},"connection_limit":-1,"timeout_client_data":50000,"timeout_member_data":50000,"timeout_member_connect":5000,"timeout_tcp_inspect":0,"allowed_cidrs":["::/0"],"tags":["kube_service_kubernetes_default_hostname-server"]}],"tags":["kube_service_kubernetes_default_hostname-server"]}: Bad request with: [POST https://192.168.5.99:9876/v2.0/lbaas/loadbalancers], error message: {"faultcode": "Client", "faultstring": "Validation failure: CIDR ::/0 IP version incompatible with VIP 172.16.5.39 IP version.", "debuginfo": null}
  Normal   EnsuringLoadBalancer    1s (x2 over 8s)  service-controller  Ensuring load balancer

Given it's not possible to have FIPs with IPv6, could you try again without specifying any network-id? Also, it seems the members subnet can be identified based on the Node addresses and IPFamily.

That did not work seemingly.
[LoadBalancer]
use-octavia=true
member-subnet-id=f98de447-6357-41bb-971e-fa21b1721a0c
Events:
Type     Reason                  Age               From                Message

Warning  SyncLoadBalancerFailed  38s               service-controller  Error syncing load balancer: failed to ensure load balancer: failed to get subnet to create load balancer for service default/hostname-server: no address found for host
Normal   EnsuringLoadBalancer    3s (x4 over 38s)  service-controller  Ensuring load balancer
Warning  SyncLoadBalancerFailed  3s (x3 over 33s)  service-controller  Error syncing load balancer: failed to ensure load balancer: failed to get subnet to create load balancer for service default/hostname-server: Resource not found: [GET https://:8774/v2.1/servers//os-interface], error message: {"itemNotFound": {"code": 404, "message": "Instance os-interface could not be found."}}

Are you running a dual stack environment? In order for IPv6 LBs to work you need your nodes to have IPv6 addresses too. This is how LB Services work.
It seems like you're using some older version of CPO. Please tell us which one.
Doing some guesses based on the error message I think you might have something weird as providerID in the node [1]. The call to Nova API seems to be done with empty ID of the server. Please tell us more about your setup. Please note that if your nodes are baremetal, then CPO will not work properly.
[1] https://github.com/kubernetes/cloud-provider-openstack/blob/fe71c9f0cfe57c9b39df5ff2c5a961caefe1f6bf/pkg/openstack/loadbalancer.go#L716-L719

Nodes are VM - Dual stack of course as is K8S. I am trying IPv6 only as Dual stack seems to not be supported with Octavia as of yet. K8s = current., OS = 2023.1, CPO = current.
Ref to provider ID, I am using CPO & the following cloud.yaml  (I am hiding the Auth part)
[Router]
router-id=66edcd05-f9c3-45ca-9356-3779840d9185
[LoadBalancer]
use-octavia=true
member-subnet-id=084267f1-ab2b-4827-8e53-229d63d448ad

@noelashford Can you try removing the member-subnet-id setting? This way I believe CPO will try to discover the IPv6  subnet based on the Node addresses. I tried creating a IPv6 loadbalancer Service without specifying any subnet/network setting and it got created.

Is this by chance fixed ? does it now support multi vip dual stack networks / IP's?

We're testing dual stack and IPv6 setups with OpenShift and upstream CPO is fine if you're not requesting dual stack LBs. If you need RequireDualStack, then CPO currently does not support that.

I don't understand the source code request. We use upstream. We do not support dual stack services at the moment, only either IPv4 or IPv6.

Ah sorry I misread the open shift comment to mean it's being tested there -
was going to see if I could port it. No worries, as a question though as I
may be able to fix it myself, where is the limitation generally speaking ?
Amphora or Octavia code ? Ie does the image support it and it's just
Octavia not supporting dual stack ?
On Wed, Feb 28, 2024, 12:34 PM Michal Dulko @.***>
wrote:

I don't understand the source code request. We use upstream. We do not
support dual stack services at the moment, only either IPv4 or IPv6.
—
Reply to this email directly, view it on GitHub
https://github.com/kubernetes/cloud-provider-openstack/issues/2333#issuecomment-1969499555,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/A2QZ4J4D6Q6JDUEZFXOR45LYV5TBNAVCNFSM6AAAAAA324RKXKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNRZGQ4TSNJVGU
.
You are receiving this because you were mentioned.Message ID:
@.***>

Octavia supports dual stack with Amphora for a bunch of OpenStack releases now. It's just not coded in CPO. See #1937 for a discussion on implementation.

authors: MaysaMacedo dulek noelashford

repo: kubernetes/cloud-provider-openstack


text:
[occm] Add log for NodeAddressesByProviderID

What this PR does / why we need it:
Which issue this PR fixes(if applicable):
related to #1208
Special notes for reviewers:

Release note:

NONE

/lgtm

/approve

authors: jichenjc lingxiankong ramineni


text:
Expand cluster autoscaler documentation

More details on when and how scale up/down work are needed.

Added documentation and FAQ.

repo: kubernetes/contrib


text:
stable/mysql chart not found

Have you tried running helm repo update?

for some reason it wasnt working after a repo update .. i did it again and its working.. thanks... is there a way to prompt users that charts might be out of date and need to be updated?

repo: kubernetes/helm


text:
Does Helm support istio kube-inject now?

Hi, Team,
Does Helm support istio 0.4 kube-inject now? i.e.
MS="myServices"; kubectl apply -f <(istioctl kube-inject -f deploy/$MS.yaml --includeIPRanges=100.64.0.0/10);
Thanks!

@kubebc what do you mean by helm supporting kube inject?
I believe istios suggested way of hanging this is to use the auto initializers in 1.9.0+

closing; see #2878.

use auto initializer https://archive.istio.io/v0.3/docs/setup/kubernetes/sidecar-injection.html

authors: SaifRehman Stono bacongobbler kubebc


text:
feat(tiller): verify apiVersions before install

This changes Tiller so that Tiller checks every Kubernetes resource against the apiVersions that are loaded on the server, and returns an error if the API version on the resources is not supported by the server.
Closes #1001

This change is

Is there any way I can switch on install resources depending on supported api versions? My use case:
My chart needs to install a CRD, but there are a few conditions:

If the CRD already exists (i.e. the apiVersion that the CRD creates is already available in the API server), do not do anything (perhaps just log a warning/message, although I doubt that is possible right now?)
Otherwise, if CRDs are supported by the API server, install a CRD
Otherwise, if CRDs are not supported but ThirdPartyResources are, install a TPR

From what I can tell, the best I can do here is switch based on the Kubernetes version?

Ah, I've just spotted Capabilities.APIVersions.Has $version - I think this is exactly what I'm looking for!

authors: munnerz technosophos


text:
kubectl create secret: Support multiple --from-env-file flags

What would you like to be added: Same as https://github.com/kubernetes/kubectl/issues/1033, but for kubectl create secret as well.
Why is this needed: These two creation commands both have the flag in question, so it should continue to behave the same way, i.e. it needs to be made repeatable on both.
/assign @lauchokyip
/triage accepted
/sig cli

Thanks!

authors: KnVerey lauchokyip

repo: kubernetes/kubectl


text:
kubectl exec -i echoes passwords

What happened?
kubectl exec -i sets up a terminal that prevents disabling echoing. So when an application ask for a password, it is visible in the terminal.
$ kubectl exec -i pod/test -- passwd
New password: mypassword
BAD PASSWORD: The password fails the dictionary check - it is based on a dictionary word
Retype new password: mypassword
Changing password for user root.
passwd: all authentication tokens updated successfully.

It may seem that adding the -t is the way to help out here, but -t merges stdout and stderr together on purpose, unfortunately. So when you try to redirect the output of such command into a variable (or stdout to a file), you will never see the "Password: " promt because it gets written into stdout because of how  kubectl exec -it sets up the terminal using raw option.
$ STDOUT_RESULT="$( kubectl exec -i pod/test -- passwd )"
New password: mypassword
BAD PASSWORD: The password fails the dictionary check - it is based on a dictionary word
Retype new password: mypassword
$ echo "${STDOUT_RESULT}"
Changing password for user root.
passwd: all authentication tokens updated successfully.

$ STDOUT_RESULT="$( kubectl exec -it pod/test -- passwd )"
# (Without any prompt, I have blindly typed two times `mypassword` into the terminal.)
$ echo "${STDOUT_RESULT}"
Changing password for user root.
New password:
BAD PASSWORD: The password fails the dictionary check - it is based on a dictionary word
Retype new password:
passwd: all authentication tokens updated successfully.

/sig cli
What did you expect to happen?
kubectl exec -i should set up terminal in a way that allows disabling echo. Alternatively, -t should distinguish between stdout and stderr.
How can we reproduce it (as minimally and precisely as possible)?

kubectl run test --image=registry.access.redhat.com/ubi9/ubi:9.3-1610@sha256:66233eebd72bb5baa25190d4f55e1dc3fff3a9b77186c1f91a0abdb274452072 -- sleep infinity
kubectl exec -i pod/test -- passwd
see the password echoed
STDOUT_RESULT="$( kubectl exec -it pod/test -- passwd )"
observe the missing password prompt

Anything else we need to know?
I have used passwd as an example of a tool that ask for password on stderr and is available to everyone to reproduce this. It doesn't return much useful value on stdout, so here is a real word example of a cqlsh query that needs to ask for a password first:
(password echoed)
TOKEN="$( kubectl exec -i "service/scylla-client" -c scylla -- cqlsh --user cassandra -e "SELECT salted_hash from system_auth.roles WHERE role = 'cassandra'" )"
/opt/scylladb/python3/lib64/python3.11/getpass.py:91: GetPassWarning: Can not control echo on the terminal.
Warning: Password input may be echoed.
Password: cassandra

(no output but silently expects the password)
TOKEN="$( kubectl exec -it "service/scylla-client" -c scylla -- cqlsh --user cassandra -e "SELECT salted_hash from system_auth.roles WHERE role = 'cassandra'" )"

Kubernetes version

$ kubectl version
# paste output here

Cloud provider

kubeadm version
kubeadm version: &version.Info{Major:"1", Minor:"28", GitVersion:"v1.28.2", GitCommit:"89a4ea3e1e4ddd7f7572286090359983e0387b2f", GitTreeState:"clean", BuildDate:"2023-09-13T09:34:32Z", GoVersion:"go1.20.8", Compiler:"gc", Platform:"linux/amd64"}

OS version

# On Linux:
$ cat /etc/os-release
PRETTY_NAME="Ubuntu 22.04.4 LTS"
NAME="Ubuntu"
VERSION_ID="22.04"
VERSION="22.04.4 LTS (Jammy Jellyfish)"
VERSION_CODENAME=jammy
ID=ubuntu
ID_LIKE=debian
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
UBUNTU_CODENAME=jammy

$ uname -a
Linux ubuntu-2204 5.15.0-100-generic kubernetes/kubernetes#110-Ubuntu SMP Wed Feb 7 13:27:48 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux

Install tools

Container runtime (CRI) and version (if applicable)

$ crictl version
Version:  0.1.0
RuntimeName:  cri-o
RuntimeVersion:  1.24.6
RuntimeApiVersion:  v1

Related plugins (CNI, CSI, ...) and versions (if applicable)

$ kubectl version
Client Version: v1.30.0-beta.0.7+c9384550cbf771
Kustomize Version: v5.0.4-0.20230601165947-6ce0bf390ce3
Server Version: v1.28.3

What did you expect to happen?
kubectl exec -i should set up terminal in a way that allows disabling echo.

I think you can do this on your own with stty -echo.

Alternatively, -t should distinguish between stdout and stderr

As far as I understand, this is what allocating a psuedo-tty is inteded for. It creates an "actual" tty device inside the container. It attaches local stdout to the combined remote streams so we can distinguish remote output from local output (kubectl).

I don't think there's anything for us to actually implement here. Feel free to reopen if that's not the case.
/close

authors: eddiezane tnozicka


text:
when EXTERNAL-IP too long

Kubernetes version (use kubectl version):
Client Version: version.Info{Major:"1", Minor:"10", GitVersion:"v1.10.11", GitCommit:"637c7e288581ee40ab4ca210618a89a555b6e7e9", GitTreeState:"clean", BuildDate:"2018-11-26T14:38:32Z", GoVersion:"go1.9.3", Compiler:"gc", Platform:"darwin/amd64"}
Server Version: version.Info{Major:"1", Minor:"12+", GitVersion:"v1.12.6-eks-d69f1b", GitCommit:"d69f1bf3669bf00b7f4a758e978e0e7a1e3a68f7", GitTreeState:"clean", BuildDate:"2019-02-28T20:26:10Z", GoVersion:"go1.10.8", Compiler:"gc", Platform:"linux/amd64"}

Environment:
Darwin PauldeMacBook-Pro.local 18.5.0 Darwin Kernel Version 18.5.0: Mon Mar 11 20:40:32 PDT 2019; root:xnu-4903.251.3~3/RELEASE_X86_64 x86_64

Install tools: zsh

What happened:
when use AKS in AWS, the ip too long ,so can not be found the ip
EX:
NAME           TYPE           CLUSTER-IP       EXTERNAL-IP        PORT(S)          AGE
redis-master     LoadBalancer   10.100.6.182     a98068ce56515...   3000:31686/TCP   36m

/remove-lifecycle rotten
/sig cli
/area kubectl
/kind bug
/priority P2

/remove-lifecycle rotten

@naihuayang Can you provide more info to reproduce?  Do you have a yaml file you used to create redis-master?  Are you using IPv6?
I created an AKS cluster and the deployment using the aks quickstart and did not observe the problem like you did:
$ k get services
NAME               TYPE           CLUSTER-IP     EXTERNAL-IP      PORT(S)        AGE
azure-vote-back    ClusterIP      10.0.96.3      <none>           6379/TCP       14m
azure-vote-front   LoadBalancer   10.0.191.223   104.45.185.250   80:31875/TCP   8m12s
kubernetes         ClusterIP      10.0.0.1       <none>           443/TCP        25m

Without being able to reproduce it, I just happened to find where it truncates the external IP to 13 bytes + "..." when it is longer than 16 bytes.
https://github.com/kubernetes/kubernetes/blob/ea5cef1c65b5890011bdd258f5c61dcf197ee5e3/pkg/printers/internalversion/printers.go#L1018
const (
	loadBalancerWidth = 16
	...
}

func loadBalancerStatusStringer(s api.LoadBalancerStatus, wide bool) string {
	...
	if !wide && len(r) > loadBalancerWidth {
		r = r[0:(loadBalancerWidth-3)] + "..."
	}
	return r
}

func getServiceExternalIP(svc *api.Service, wide bool) string {
	switch svc.Spec.Type {
	...
	case api.ServiceTypeLoadBalancer:
		lbIps := loadBalancerStatusStringer(svc.Status.LoadBalancer, wide)
	...
}

It looks like that in order to support full display of IPv6 in table format, loadBalancerWidth would need to be changed from 16 to 48

Hi,
I think can be try use
kubectl get svc -o wide

kubectl get svc -o wide

@yangnaihua does that show the entire address for you?

kubectl get svc -o wide

@yangnaihua does that show the entire address for you?

in fact, i am not sure. if not , it is a bug

authors: brianpursley naihuayang seans3 yangnaihua


text:
Issue with /docs/admin/

This is a...

[ ] Feature Request
[x] Bug Report

Problem:
there is a problem with one of the link http://kubernetes.io/docs/admin/networking
it shows 404 error Sorry, this page was not found. :(
Proposed Solution:
change link or create http://kubernetes.io/docs/admin/networking
Page to Update:
http://kubernetes.io/...

Their is a fix for this in the queue. PR #1605

marking as closed

authors: a-mccarthy alexanderdrozd chrismarino


text:
node conditions update correctly but taints never apply to the node

Hi,
Im not finding any answers online to help me with my issue and hope someone here could help me 😉 please.
I understand that node problem detector is not responsible for applying taints and the feature gate for TaintNodesByCondition must be enabled, In order to allow kubernetes control plane processes to taint node based on reported node conditions. Reading the documention for Kubernetes says TaintNodesByCondition enabled by default from 1.17 K8S DOC

I am working on eks 1.21 and it also say that TaintNodesByCondition is on by default AWS DOC
I have deployed node problem detector to the cluster using the helm chart, and I went to test it with the following command via ssh on a node.
sudo sh -c "echo 'kernel: INFO: task docker:20744 blocked for more than 120 seconds.' >> /dev/kmsg"

It resulted in
Conditions:
  Type                 Status  LastHeartbeatTime                 LastTransitionTime                Reason                       Message
  ----                 ------  -----------------                 ------------------                ------                       -------
  KernelDeadlock       True    Tue, 01 Feb 2022 23:03:41 +0000   Tue, 01 Feb 2022 23:03:40 +0000   DockerHung                   kernel:  INFO: task docker:20744 blocked for more than 120 seconds.`

Which looks perfect🍾, However the node taint remains Taints: <none> Which now blocks use us from using descheduler.
Any help would be greatly received as to why or what I have missed to cause taints not to happen.
Anyone got any guidance for node problem detector on aws eks or eks gotchas

The current "TaintNodesByCondition" admission controller in k8s actually doesn't do what the name indicates, it simply add a taint at node creation, see the comment in code.
The README approach using Descheduler's "RemovePodsViolatingNodeTaints" feature seems to be gapped by not having an actor by adding a taint.

I have arrived at the same conclusion. It seems like TaintNodesByCondition only applies to a few hard-coded conditions and can not be extended in its current state.
https://github.com/kubernetes/kubernetes/issues/42001

Looks like a dup of #457.  There's an (old) related PR #565 to resolve.

Okay it's not just me then. :sweat:

authors: JSC0DE jhohertz rbjorklin rhockenbury tdihp

repo: kubernetes/node-problem-detector


text:
Changed perfdash service type to NodePort

/cc @mm4tt
As perfdash is currently deployed at the aaa cluster
at community owned infrastructure and we don't have to use
services with LoadBalancer types it's good to change it
in the source repository and then removing unnecessary
manual instructions from the k/k8s.io repository
Signed-off-by: Bart Smykla bsmykla@vmware.com

/approve
/lgtm

@mm4tt thanks for looking! :-) Would you look at kubernetes/k8s.io#778 too please?

repo: kubernetes/perf-tests


text:
compute-device-assignment.md is not found

This is a Bug Report

Proposed Solution:
Support Device Monitoring in this page is linked to a dead url.
Page to Update:
https://kubernetes.io/docs/reference/command-line-tools-reference/feature-gates/

/kind bug
/sig node
/language en
/triage accepted
Rather than linking to a KEP, we should really add a new page to the documentation (maybe in Concepts, maybe in Reference) and then link to that.

@sftim @MartinForReal
The fail link in Support Device Monitoring due to this page changed.
This root cause in the kind/bug is the repo of kubernetes/enhancements url that move keps/sig-node/compute-device-assignment.md to keps/sig-node/606-compute-device-assignment/README.md .
I had a look at it and sent in a pull request for fix this.(PR #26412)
/assign

/close

authors: MartinForReal sftim ydFu

repo: kubernetes/website


text:
Authenticating page shows example beginning with "system:" while Using RBAC Authorization page states this prefix is reserved for Kubernetes system use

This is a Bug Report

Problem:
At the url https://kubernetes.io/docs/reference/access-authn-authz/authentication/#authentication-strategies the example system:masters is used as what a common value for a group may be. This conflicts with the cautionary message at https://kubernetes.io/docs/reference/access-authn-authz/rbac/#referring-to-subjects stating:

The prefix system: is reserved for Kubernetes system use, so you should ensure that you don't have users or groups with names that start with system: by accident.

On the first page listed system:authenticated appears to be used properly, but does not denote that this is done by the Kubernetes system.
I believe these could cause confusion or improper use among users that do not thoroughly read the documentation.
Proposed Solution:
The example system:masters should be removed and replaced with a more appropriate label that does not conflict with a Kubernetes reserved prefix or use potentially offensive master/slave terminology. architecture:leaders or something similar could be an appropriate replacement.
Additionally it could be useful to add that system:authenticated is included in the list of groups by the Kubernetes system.
Page to Update:
https://kubernetes.io/docs/reference/access-authn-authz/authentication/#authentication-strategies

Noted. Thank you for the resources!

/close


text:
Replace html tables with markdown

Fixes #16102 .  Replaced all the html tables with markdown in the following pages,
https://kubernetes.io/docs/contribute/style/style-guide/
https://kubernetes.io/docs/contribute/style/write-new-topic/

/assign @ryanmcginnis

@aimeeu Thank you. I will wait for Tim, and squash the commits into one if there is no further change.

/lgtm
(will need another one after squashing, or an approver can /lgtm /approve in a single comment)

/lgtm

@zacharysarah Thank you for the review. I have made the changes, Can you review once again ?

@zacharysarah, I have squashed all commits into one.

/lgtm
/approve

authors: sNathan13 savitharaghunathan sftim zacharysarah


text:
ID localization for administer cluster - configure upgrade etcd

This PR translates /docs/tasks/administer-cluster/configure-upgrade-etcd as mentioned in #22296

/check-cla

/assign @girikuncoro

Thanks @Miftahunajat for your first contribution, welcome to Kubernetes! Can you first follow instruction to sign CLA here https://github.com/kubernetes/website/pull/22733#issuecomment-663853561

Hello I already sign CLA. Please verify.

Hello, @ariscahyadi Thank you for reviewing my Pull Request and also for writing suggestions for my first contribution.
I already implement all of your suggestions for translation in my current commit.
I also already squashed the commits.
Thank you.

Hello, @girikuncoro Thank you for reviewing my Pull Request and also for writing suggestions for my first contribution.
I already made some new changes in this new commit.
I also already squashed the commits.
Thank you.

@Miftahunajat thanks a lot, hope you learned something by localizing this page! Feel free to pick other pages when you have time
/lgtm
/approve

authors: Miftahunajat girikuncoro


text:
Delete the duplicate content

Delete the duplicate content

cla

/check-cla

@k8s-ci-robot /check-cla

I signed it


text:
moved drain the node step to after call kubeadm upgrade step for worker nodes in dev-1.20

Description - Updating upgrade kubeadm docs to move drain node step in Upgrade worker nodes section #25732
Moved the "Drain the node" step to after "Call kubeadm upgrade" step in Upgrading worker nodes section in the Upgrading kubeadm docs to be consistent with Upgrading the control-plane nodes and to ensure draining nodes is preformed before applying maintenance to nodes when updating kubelet/kubectl and restarting the kubelet service

/hold
@sculley, there are too many commits here. I think you'll need to make sure the edits you're making start from the dev-1.20 branch.

@sculley, there are too many commits here. I think you'll need to make sure the edits you're making start from the dev-1.20 branch.

@sftim - apologies, you're correct I branched from the master branch and not the dev-1.20 one. Not sure how to fix within this PR so I will close and open a new PR with a branch which is used the dev-1.20 branch.

authors: sculley sftim


text:
[ko] Update to Outdated files in the dev-1.20-ko.7 (p1)

This PR from issue #27148
41 of 42 files to be modified

[x] M1. content/ko/docs/concepts/architecture/control-plane-node-communication.md
[x] M2. content/ko/docs/concepts/architecture/nodes.md
[x] M3. content/ko/docs/concepts/cluster-administration/manage-deployment.md
[x] M4. content/ko/docs/concepts/configuration/configmap.md
[x] M5. content/ko/docs/concepts/configuration/overview.md
[x] M6. content/ko/docs/concepts/containers/images.md
[x] M7. content/ko/docs/concepts/extend-kubernetes/operator.md
[x] M8. content/ko/docs/concepts/scheduling-eviction/assign-pod-node.md
[x] M9. content/ko/docs/concepts/scheduling-eviction/resource-bin-packing.md
[x] M10. content/ko/docs/concepts/storage/dynamic-provisioning.md
[x] M11. content/ko/docs/concepts/storage/volumes.md
[x] M12. content/ko/docs/concepts/workloads/controllers/deployment.md
[x] M13. content/ko/docs/reference/_index.md
[x] M14. content/ko/docs/reference/access-authn-authz/_index.md
[x] M15. content/ko/docs/reference/command-line-tools-reference/_index.md
[x] M16. content/ko/docs/reference/command-line-tools-reference/feature-gates.md
[x] M17. content/ko/docs/reference/command-line-tools-reference/kube-proxy.md
[x] M18. content/ko/docs/reference/glossary/index.md
[x] M19. content/ko/docs/reference/issues-security/_index.md
[x] M20. content/ko/docs/reference/kubectl/_index.md
[x] M21. content/ko/docs/reference/kubectl/overview.md
[x] M22. content/ko/docs/reference/scheduling/config.md
[x] M23. content/ko/docs/reference/setup-tools/_index.md
[x] M24. content/ko/docs/reference/using-api/_index.md
[x] M25. content/ko/docs/setup/best-practices/certificates.md
[x] M26. content/ko/docs/setup/best-practices/multiple-zones.md
[x] M27. content/ko/docs/setup/production-environment/container-runtimes.md
[x] M28. content/ko/docs/setup/production-environment/tools/kops.md
[x] M29. content/ko/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md
[x] M30. content/ko/docs/setup/production-environment/tools/kubespray.md
[x] M31. content/ko/docs/setup/production-environment/windows/intro-windows-in-kubernetes.md
[x] M32. content/ko/docs/setup/release/notes.md
[x] M33. content/ko/docs/tasks/administer-cluster/access-cluster-api.md
[x] M34. content/ko/docs/tasks/administer-cluster/change-default-storage-class.md
[x] M35. content/ko/docs/tasks/administer-cluster/kubeadm/kubeadm-certs.md
[x] M36. content/ko/docs/tasks/manage-kubernetes-objects/declarative-config.md
[x] M37. content/ko/docs/tasks/manage-kubernetes-objects/imperative-command.md
[x] M38. content/ko/docs/tasks/manage-kubernetes-objects/imperative-config.md
[x] M39. content/ko/docs/tasks/manage-kubernetes-objects/kustomization.md
[ ] M40. content/ko/docs/tasks/tools/included/optional-kubectl-configs-bash-mac.md

#26949 내에서 추가된 문서로 선 반영됨

[x] M41. content/ko/docs/tasks/tools/install-kubectl-linux.md
[x] M42. content/ko/docs/tasks/tools/install-kubectl-macos.md

1 of 1 files to be renamed

[x] R1. R078 content/ko/docs/reference/tools.md -> content/ko/docs/reference/tools/_index.md

/milestone dev-1.20-ko.7

/retitle [ko] Update to Outdated files in the dev-1.20-ko.7 (p1)

@ysyukr 감사합니다!! :)
@kubernetes/sig-docs-ko-reviews
해당 PR 리뷰 가능하신 분 계실까요? 내용이 다소 많으므로, 영역을 나눠서 공동 리뷰를 해도 될 것 같습니다.
가능하신 분은 의사를 표시해주세요.. ^^

저도 리뷰 코멘트를 좀 달아 보겠습니다.. ^^

/assign @jihoon-seo

안녕하세요! 손석호입니다. 즐거운 주말 보내셨는지요~? ^^
dev-1.20-ko.7 마감 일정 공유드립니다.

PR 프리즈: 03/28 - 일 (작업 브랜치에 포함되는 PR을 확정, 이후의 PR은 차기 작업 브랜치로 리베이스 필요)
브랜치 머지: 03/31 - 수 (master 브랜치에 머지되며, k8s.io에 반영)

이번 dev-1.20-ko.7는 쿠버네티스 1.21 릴리스 일정에 따라, 수요일 내에 master에 merge 하려고 합니다. 도움을 부탁드립니다.. ^^
리뷰어께서는 컨트리뷰터와 협업하여 가능한 수요일까지 처리 부탁드립니다. 혹시 리뷰가 어려운 분은 다른 분들이 함께 도울 수 있도록 연락 부탁드립니다.. ^^
승인자께서는 직접 할당된 PR이 아니더라도, lgtm이 있는 PR의 경우, (프리뷰 등) 최종 확인 후에 approve 부탁드립니다!

@jihoon-seo 님 리뷰 감사합니다!
정식 리뷰어는 아니시지만, 리뷰 코멘트를 보니 꼼꼼하게 살펴봐주신 것 같네요.. :)
리뷰 코멘트는 @ysyukr 님께서 판단하셔서 적절히 반영해주시면 될 것 같습니다.
1차 반영해주시고 나면, 최종적으로 제가 검토 및 승인하도록 하겠습니다..! 감사합니다.
/assign @seokho-son

확인이 늦었습니다. 남겨주신 리뷰는 확인하여 반영했습니다.

@ysyukr @jihoon-seo 고생 많으셨습니다! 감사합니다.. :)
/lgtm
/approve

authors: jihoon-seo pjhwa seokho-son ysyukr


text:
[uk] fix & update KubeCon link

/assign @MaxymVlasov

/lgtm
/approve

authors: Arhell MaxymVlasov


text:
[JP] Blogs page

Improvement suggestions for the following

Blogs --> Kubernetesブログ
The preview page: Link

LGTM

I tested where these fields are used.
---
title: Kubernetesブログ(title)
linkTitle: ブログ(linkTitle)
menu:
  main:
    title: "ブログ(title-in-main)"
    weight: 40
    post: >

Kubernetesやコンテナ全般に関する最新ニュースを読んで、技術的なハウツーをいち早く入手しましょう。

---

I don't know where the title field in the main is used, but it would be good to keep it the same as the original file.

/retitle [ja] Translate title and linkTitle for Blogs page

@t-inu may can you recheck?

I seem the modified file is fine.
We'd like to solve Netlify's deploy failed.
The following comment may be helpful to you.
https://github.com/kubernetes/website/pull/39528#issuecomment-1449197631

/assign @inductor @nasa9084

authors: Saliha067 sftim t-inu


text:
[de] German localization of further glossary items

This PR is for the German localization of the following glossary items:
content/de/docs/reference/glossary/addons.md
content/de/docs/reference/glossary/admission-controller.md
content/de/docs/reference/glossary/affinity.md
content/de/docs/reference/glossary/aggregation-layer.md
content/de/docs/reference/glossary/annotation.md
content/de/docs/reference/glossary/api-eviction.md
content/de/docs/reference/glossary/api-group.md
content/de/docs/reference/glossary/app-container.md
content/de/docs/reference/glossary/application-architect.md
content/de/docs/reference/glossary/application-developer.md
content/de/docs/reference/glossary/applications.md
content/de/docs/reference/glossary/approver.md

/lgtm

/approve


text:
Update apparmor.md

Adding Armiel free online service as an option to generate AppArmor profiles.

/hold
I have some hesitation about linking out to an online tool that is not open source. @katcosgrove @reylejano @divya-mohan0209 @natalisucks @tengqm - could you provide input please?

authors: Archguardian-io salaxander


text:
Fix podpreset task

There are several problems with the current task doc -- inject information into pods using prodpreset:

The YAML files should have been split out for easier trying out;
The ReplicaSet sample used was using wrong API group;
The ReplicaSet sample is showing the result with a Pod spec, which is confusing.

This patch fixes the above problems.

This change is

@tengqm :wave: The build is failing with this error:

Error:  Could not locate the included file 'podpreset-conflict-merged.yaml' in any of ["/opt/build/repo/docs/tasks/inject-data-application"]. Ensure it exists in one of those directories and, if it is a symlink, does not point outside your site source.

@tengqm Would you like to have a tech review?

@steveperry-53 Better find someone else, not the author, :)

@vishh @Random-Liu @tallclair Could one of you do a tech review? Thanks.

/lgtm

Thanks for fixing it.

authors: droot steveperry-53 tengqm zacharysarah


text:
kubectl/cheatsheet - add command for sorting events

add a command to "List Events sorted by timestamp"

workaround for #29838

This change is

Signed the CLA.

/approve
/lgtm

authors: heckj pawelprazak


text:
chore: retarget a ListFrameworks fix, suggest targeting master in PRs

Overview
I mistakenly merged #1046 into dev, when we moved to targeting master. This change re-targets the misrouted commit, documents that we target master in new PRs and updates the Pull Request template accordingly.
Related issues/PRs:
Includes #1046.
Fixes #1040.

@vladklokun thanks. I was unaware of this change of rules. Will pull request against master moving forward

@fredbi Well, we didn’t update the docs nor the PR template and I straight up forgot about it, so this one is fully on us :grin:
As always, thank you for contributing!

@dwertent Please merge this when you have the time.

authors: fredbi vladklokun

repo: kubescape/kubescape


text:
fix missing and incorrect packages in package-lock

This PR fixes the errors when trying to run the storybook commend. There are a lot of changes to the package-lock due to uninstalling and reinstalling the storybook and vite dependencies.
Changes

Fixes

Checklist

[x] tested locally
[x] added new dependencies
[ ] updated the docs
[ ] added a test

This looks like monorepo dependency deduplication chaos to me. It should work if you install node-fetch and uuid in the components package
npm i -DE uuid@latest node-fetch@latest

authors: DzoQiEuoi monojack

repo: kubeshop/monokle-core

license: MIT


text:
chore: add kustomize for easier config adjustments

This allows easier management via tools that support kustomize, e.g. ArgoCD.

The CRDs will need to be deployed as well, regardless of whether they get
customised.
On Fri, 30 Apr 2021 at 12:16 pm, Benjamin Huo @.***>
wrote:

@.**** requested changes on this pull request.
See my comments above
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/kubesphere/fluentbit-operator/pull/46#pullrequestreview-648811725,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AACYNPRQTYVKOJYJ6SFC5BDTLIHGDANCNFSM42SW2VKQ
.

Got you, actually what you need is a placeholder. And you'll customize it as you wish.

authors: benjaminhuo estahn

repo: kubesphere/fluentbit-operator


text:
📖 Make quickstart clearer about kcp

Mention its installation more clearly.  Document the required version.

Summary
This PR documents the required version of kcp and includes mention of kcp in section headings about install.  This is good because @eaepstein has demonstrated that users are lost without it.
Related issue(s)
Fixes #

/cc @dumb0002
/cc @francostellari
/cc @clubanderson
@eaepstein

repo: kubestellar/kubestellar


text:
CNV-32485: Use cluster-wise eviction strategy configuration

📝 Description
EvictionStrategy on 4.14 can be configured cluster-wise using the Hyperconverge configuration
When VM does not specify an evictionStrategy, the vmi will be created with the configured strategy.
This means that on other screens like the schedule tab, when we show 'No eviction strategy' we have to show the cluster strategy.
Steps:

create a common hook to fetch cluster configuration
edit pending changes considering the cluster configuration
Create a common component to show the EvictionStrategy in all the schedule tab that use the cluster configuration (other than the template schedule tab with its specific component)
on checkbox uncheck, set the evictionStrategy to None instead of deleting it. Deleting the strategy means 'Use the cluster strategy'

🎥 Demo
Before

After
reading from the cluster configuration

/retest

/lgtm
/retest

/retest

/retest

/cherry-pick release-4.14

authors: gouyang metalice pcbailey upalatucci

repo: kubevirt-ui/kubevirt-plugin