text:
Multitarget

This PR enables having multiple targets per domain name. I'm aware of PR 243, but this one works by having one Endpoint structure per (name, target) rather than extending Endpoint.Target to be an array and having one Endpoint per name. This means that the existing providers should work without changes, EXCEPT if they're written explicitly with the assumption of one endpoint per name in mind. We're using the Cloudflare provider; I had to modify one line (2d45bc2e19dd455f52925831c171c8506f423eb9) to make it work. I also modified the inmemory provider accordingly and added multi-target tests to for TXTRegistry, Controller and Plan.
I modified TXTRegistry to perform the ownerID tracking internally by caching some state in member variables between Records() and ApplyValues(), rather than using the Endpoints' .Labels["owner"] for that (storing per-name ownerIDs in per-target Endpoints would've been redundant and would've complicated things). This means that the labels are no longer used for anything now and might be removed unless we need them for something else in the future.
Everything works, AFAICS. We use the CF provider as I said, haven't really tested the others.
(update 11/08/17: inmemory provider multi-target capability, more tests)

I signed

Bump for CLAbot 🤞

Pretty clean code from scrolling over, thanks for this PR.
I am unsure if we have to have TTL defined in all tests or if we should have also tested the default ttl.
If this is not super complicated please also add tests for not defined TTL, because if this break, this could also break current production installations.

:+1:

@ideahitme @linki

Since I am very interested in supporting multiple targets for a single DNS name and I was intrigued by the idea to keep changes in providers to a minimum, I tried to adapt this PR for our environment. We are using Google Cloud DNS on GKE.
Unfortunately I don't think, that this approach is viable as a general solution. In Google Cloud DNS you encounter the problem that deletes need to match exactly the existing ResourceRecordSet. You can't delete a single A record for a DNS name (or you probably can, but not with the current provider implementation).
This PR makes deletes virtually impossible in Google Cloud DNS. And without working deletes, updates also fail (since they are 'delete and recreate').
From my point of view it looks we need to turn Endpoint.Target into an array, to be able to keep using the Google Cloud DNS provider.
But i won't deny the possibility that I am absolutely wrong and I just don't see the correct solution yet.

@dereulenspiegel the idea is to go with the Endpoint.Target to array transition. Personally I would prefer to immediately go with that solution which would work for all providers (presumably). Please refer to: https://github.com/kubernetes-incubator/external-dns/pull/396, https://github.com/kubernetes-incubator/external-dns/pull/404 it gives some context on how we are planning to enable multi-target support

I agree that one endpoint per target is probably not the best general solution, and I certainly don't cling to it or anything. It was just something to get going quickly on CF.

@ideahitme I already read #396 and #404 . But I thought I will try this idea, to a) provide some feedback on another provider than the one used by the creator of this PR and b) have short term solution for our cluster, since #404 seems to need a bit more time.
I generally think that the combination of #404 and #396 is probably the more generalstic approach, since it also addresses other problems.
I will follow #404 and #396 more closely now.

@dereulenspiegel yes, feedback would be awesome. However, based on my analysis, #404 should be safe for rollout in any dns-provider, however I only tested it on AWS. I am afraid any short term solution have to also fix internal component logic (plan) (in a fashion similar to #404), I could be wrong though

Multi-target functionality has successfully landed in another PR. Therefore I'm closing this.  Feel free to re-open if you think it's wrong.
Thanks @multi-io for all your effort!

authors: BenTheElder dereulenspiegel ideahitme linki multi-io szuecs

repo: kubernetes-incubator/external-dns


text:
Broken link in /nfs/docs/authorization

The PSP and/or RBAC link is broken.
It is currently: * [PSP and/or RBAC](#rbac)
It should be: * [PSP and/or RBAC](#psp-andor-rbac)

/lifecycle stale

/remove-lifecycle stale

source: gharchive/issue

repo: kubernetes-incubator/external-storage

license_type: permissive

license_source: bigquery


text:
Fixed nova command to get available flavors

The nova command for getting the flavors is not
nova list-flavors
but
nova flavor-list

I signed it!

@connz rebase your patch and it will recheck CLA

@connz the email address on the patch doesn't match your github account. Can you fix it?

I am out sick at the moment, sorry.

@Connz wanted to check in and see if you can address mattymo's comments

Sorry for the long delay - only now back to work...

source: gharchive/pull-request

authors: Connz bradbeam mattymo

repo: kubernetes-incubator/kargo


text:
InvalidParameterCombination: The parameter iops is not supported for gp2 volumes.

I started seeing this from around Thursday last week when creating a cluster with pretty much default settings:
$ kube-aws up --s3-uri s3://[...]/kube-aws/kube98
Error: Error validating cluster: failed to validate node pool #0: create volume dry-run request failed:
    InvalidParameterCombination: The parameter iops is not supported for gp2 volumes.
    status code: 400, request id: ...

Apparently kube-aws performs a request like this (taken from CloudTrail):
"eventTime": "2018-03-27T05:34:17Z",
"eventSource": "ec2.amazonaws.com",
"eventName": "CreateVolume",
[...]
"errorCode": "Client.DryRunOperation",
"errorMessage": "Request would have succeeded, but DryRun flag is set.",
"requestParameters": {
    "size": "30",
    "zone": "ap-southeast-2a",
    "volumeType": "gp2",
    "iops": "0"
},

The same request now fails:
"eventTime": "2018-04-02T06:08:48Z",
"eventSource": "ec2.amazonaws.com",
"eventName": "CreateVolume",
[...]
"errorCode": "Client.InvalidParameterCombination",
"errorMessage": "The parameter iops is not supported for gp2 volumes.",
"requestParameters": {
    "size": "30",
    "zone": "ap-southeast-2a",
    "volumeType": "gp2",
    "iops": "0"
},

I have raised that with AWS support but the fix will most likely have to be on kube-aws side and omit sending the iops attribute for anything else but io1 volumes.
Note that this is probably being sent by kube-aws itself, not as part of CFN template.

Hi @mludvig, thanks for trying kube-aws!
I sounds like you're hitting #1170, which is fixed on master since #1171

authors: mludvig mumoshu

repo: kubernetes-incubator/kube-aws

license_source: github-api


text:
Conformance tests cannot run on v1.2.1

This is caused by https://github.com/kubernetes-sigs/gateway-api/pull/3211 which overrides the passed in Client as mentioned here: https://github.com/kubernetes-sigs/gateway-api/pull/3343#discussion_r1764102336. Due to this change Microsoft Azure's implementation of the conformance tests is broken because we had a custom Client that was passed in while setting up the conformance suite.
What would you like to be added:  Ensure that the Client is still configurable for implementors to override if needed
Why this is needed: Unable to upgrade to v1.2.1 because it breaks conformance tests.
cc @howardjohn @BobyMCbobs

Thanks for reporting this @snehachhabria! To clarify, is this a regression between v1.2.0 and v1.2.1, or is it a problem with all v1.2 releases?
/cc @mlavacca

Thanks for reporting this @snehachhabria! To clarify, is this a regression between v1.2.0 and v1.2.1, or is it a problem with all v1.2 releases?
/cc @mlavacca
it's a problem with v1.2

/kind bug

Thanks for reporting this issue, @snehachhabria! With #3343 we introduced the possibility to customize the client options to be able to pass scheme, mapper, etc. Isn't the ClientOptions field enough to fit your needs?

Thanks for reporting this issue, @snehachhabria! With #3343 we introduced the possibility to customize the client options to be able to pass scheme, mapper, etc. Isn't the ClientOptions field enough to fit your needs?

Unfortunately not, exposing the Client allows us to modify the writer interface for the Create/Update function to add some custom annotations while creating gateway objects

Are there any more details you can share about what you need to add? Maybe that might be useful for other folks as well, and we should build support directly into the tests?

Our implementation requires custom annotations on the gateway object, sample can be found here: https://learn.microsoft.com/en-us/azure/application-gateway/for-containers/how-to-traffic-splitting-gateway-api?tabs=alb-managed#deploy-the-required-gateway-api-resources . In order to add these annotations to the gateway objects created by the conformance suite we have modified the Create/Update function exposed via the client.
It would be great if support for annotations on Gateway objects can be supported directly via the test suit, similar to how namespace annotations are exposed: https://github.com/kubernetes-sigs/gateway-api/blob/99a3934c6bc1ce0874f3a4c5f20cafd8977ffcb4/conformance/utils/suite/suite.go#L137 . That way it could potentially be used by other implementors as well

To be honest, it's really intended that what's described in that doc is implemented by having a GatewayClass that sets all Gateways associated to it to use the configured ALB.
I really don't like the approach of using annotations on Gateway to do this - it's totally against one of the major design goals of Gateway API, which is to pull that kind of config out of annotations and into structured fields and more specific resources.

+1 to @youngnick's comment here. In my mind, one of the most important purposes of conformance tests is ensuring that users will get the same shared experience out of the box with our portable features. Obviously implementations should feel welcome to add features on top of the core API, but we really want the base API and examples to work without any changes (other than setting a GatewayClass name on a Gateway).
If I'm understanding this specific modification correctly, it seems like users would need to manually configure some annotations on each Gateway, which goes against the API experience we're trying to guarantee with conformance tests and status.

@youngnick and @robscott thanks a lot of sharing your thoughts. I completely understand the primary design goal of Gateway API is not to have any configurability via annotations. Given the limitations that existed at the time we were implementing Gateway API and our infrastructure/design needs we had to go down the route of using an annotation on the Gateway object.
I understand if providing support for annotations on the gateway object in the conformance is against the experience desired and shouldn't be exposed. But if we could go back to having the Client exposed, like it was prior to release v1.2, we would still be able to run the conformance tests and generate the reports. We are still conformant with all of Gateway API's requirements and would like to continue doing so, the conformance tests aid this and it would be great if we can run them as is without too many modifications from our end.

authors: mlavacca robscott snehachhabria youngnick

repo: kubernetes-sigs/gateway-api


text:
Allow inclusive configuration of resources to propagate

 Issue by hferentschik
Tuesday Mar 16, 2021 at 09:34 GMT
Originally opened as https://github.com/kubernetes-sigs/multi-tenancy/issues/1436

When synchronizing additional resource types, eg Secrets, it is currently only possible to configure this globally (see #1435) and the propagation configuration only allows to exclude certain resources from propagation (via annotation).
It would be nice to have an inclusive way of configuring propagation as well. For example, assume the root namespace contains multiple secrets and I would like to only propagate specific secrets (something like what reflector does). In this case I would like to annotate the Secret to propagate and maybe somehow configure to which child namespaces it should be propagated.
This might require changing the propagation modes and adding a new one.

 Comment by adrianludwin
Tuesday Mar 16, 2021 at 14:40 GMT

Yes, this is a good idea and we considered it when we were first designing exceptions:

In addition, we will consider adding a global AllowPropagate mode to HNCConfig. This could be useful for types such as Secrets that we don’t want to always propagate. When the propagation mode is Propagate, objects will always be propagated unless an annotation is set; in AllowPropagate, the reverse is true and the objects will only be propagated if an annotation is set. If we do this, we’ll also a propagate.hnc.x-k8s.io/all=true annotation to allow an object to opt into full propagation.

We haven't seen a strong demand from this from our own customers, but I think the interface and semantics are fairly clear so I'd welcome PRs for this feature. Note that the majority of the work here would likely be in coming up with suitable integration tests; the code itself would likely be relatively easy.
/good-first-issue

 Comment by k8s-ci-robot
Tuesday Mar 16, 2021 at 14:40 GMT

@adrianludwin:
This request has been marked as suitable for new contributors.
Please ensure the request meets the requirements listed here.
If this request no longer meets these requirements, the label can be removed
by commenting with the /remove-good-first-issue command.

In response to this:

Yes, this is a good idea and we considered it when we were first designing exceptions:

In addition, we will consider adding a global AllowPropagate mode to HNCConfig. This could be useful for types such as Secrets that we don’t want to always propagate. When the propagation mode is Propagate, objects will always be propagated unless an annotation is set; in AllowPropagate, the reverse is true and the objects will only be propagated if an annotation is set. If we do this, we’ll also a propagate.hnc.x-k8s.io/all=true annotation to allow an object to opt into full propagation.

We haven't seen a strong demand from this from our own customers, but I think the interface and semantics are fairly clear so I'd welcome PRs for this feature. Note that the majority of the work here would likely be in coming up with suitable integration tests; the code itself would likely be relatively easy.
/good-first-issue

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

/remove-lifecycle stale

/remove-lifecycle stale

/remove-lifecycle stale
/lifecycle frozen

I have run into exactly this problem.
I'm working with multiple teams which all get a namespace in a Kubernetes cluster, we automatically populate this namespace with docker credentials to a repository that the team has access to.
We would like to allow the teams to create sub-namespaces and have only the docker credentials propagate to the sub-namespaces.
Only being able to exclude secrets makes it so that all automatically generated secrets, such as Helm release secrets, need to be annotated so that they won't get propagated. This is not optimal, when all we want to do is only propagate one single Kubernetes secret to the sub-namespaces.

This one feels like it has been addressed using "Allow Propagate" on the resource type and adding an annotation ("propagate.hnc.x-k8s.io/all" = "true") to the specific resources one wants to propagate

repo: kubernetes-sigs/hierarchical-namespaces


text:
fix kpng version command

fixes #228
The problem here likely stems from the fact that, currently, there are too many ways to build and deploy KPNG. None of them were passing the commit SHA to go build/install.
This PR:

fixes the version command for make tilt-up, make build,  kpng-local-up.sh, and test_e2e.sh;
makes all the tools above build kpng with the same command (make image);

Marked as draft because it is not solved for test_e2e.sh and modd. Will try to standardize the build process later.

/remove-lifecycle stale

/ok-to-test

@jaehnri can this be closed?

@friedrichwilken it looks like my last commit made the pipeline fail. I'll check it very soon so it can be reviewed.

/lgtm

authors: friedrichwilken jaehnri qabpea

repo: kubernetes-sigs/kpng


text:
Log more info when validation fails due to unexpected fields on a resource

What would you like to be added?
When validating a resource, if there's, let's say a typo on a property, the validation results in an error where no reference to the resource that failed to validate is logged. When validating a file with several resources in it, it's hard to find which to find which one errored.
Example:
apiVersion: v1
kind: ConfigMap
metadata:
  name: x.com
datas: # extra "s"
  key: value

Error message: datas: Invalid value: value provided for unknown field
So no reference to name and kind of the resource.
This happens as when resource parsing fails, it errors without parsing metadata's name. Group and kind are returned but not attached to the error.
https://github.com/kubernetes-sigs/kubectl-validate/blob/e1c86ccfb5930bcf8dc827919bd8c7c991b2c738/pkg/validator/validator.go#L82
Feels like getting this basic info on the resource could be done at parse function?
Why is this needed?
It will help identifying the resource that caused the  error.

I agree parse errors should be accumulated and linked back to the original object. Attributing only to file makes it hard to reason about large yamls with many documents

/assign

unassigned myself because I'm having a bit of trouble setting up my environment and don't want to block development. I'll try a good first issue when I'm set up. :)

/assign

Adding Group and kind will be very easy to fix. Adding name will require more work for me ( Ill handle it on the weekend )
:)

repo: kubernetes-sigs/kubectl-validate


text:
fix stylecheck in golangci.yaml

What type of PR is this?

/kind cleanup
What this PR does / why we need it:
Which issue(s) this PR fixes:

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

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

/ok-to-test

/kind cleanup

Please check the validation, there are some cases that do not pass

https://prow.k8s.io/view/gs/kubernetes-jenkins/pr-logs/pull/kubernetes-sigs_kwok/136/pull-kwok-verify-main/1600410067138514944
The new file header is not licensed

Squash all the commits

/assign
/lgtm

repo: kubernetes-sigs/kwok


text:
Add .gitignore

We want to ignore the bin/ directory and a few other temp things.

/lgtm

authors: ameukam justinsb

repo: kubernetes-sigs/porche


text:
correct updateapispec tgt

Correcting an error in updateapispec target. Retested in k8s/website.

em... it is funny why we need such a change.
/lgtm
/approve

em... it is funny why we need such a change.

Ermm, the script did not work without the changes (tested on Ubuntu) :smiley: .

authors: kbhawkey tengqm

repo: kubernetes-sigs/reference-docs


text:
Consider naming TypedLocalObjectReference fields fooRef

https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md#naming-conventions

The name of a field referring to another resource of kind Foo by name should be called fooName. The name of a field referring to another resource of kind Foo by ObjectReference (or subset thereof) should be called fooRef.

Following this recommendation would replace Extension with ExtensionRef, but it would also replace ForwardTo with something less wieldy (maybe TargetRef). So maybe it's better not to follow this convention in all cases.

Let's open a PR against the developer guide section of the docs and continue the discussion there.

/assign

/unassign

Opened #73 to replace types.

I believe this was fixed by #73, feel free to reopen if I missed anything.

/close

authors: Miciah bowei jpeach robscott

repo: kubernetes-sigs/service-apis


text:
[cinder-csi-plugin] resize of volume failed

Is this a BUG REPORT or FEATURE REQUEST?:

Uncomment only one, leave it on its own line:

/kind bug

/kind feature

What happened:
reported this before and can't find it now, so re-report and see whether we can improve
following the resize guide and the volume changed from 1G to 2G
# kubectl get pvc
NAME                    STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS          AGE
csi-pvc-cinderplugin    Bound    pvc-af9ecbfa-78c1-46eb-8b89-8835808a469a   2Gi        RWO            csi-sc-cinderplugin   68m
csi-pvc-cinderplugin1   Bound    pvc-3ed8dbed-1da7-4a19-b4f2-f06416da9c6b   2Gi        RWO            csi-sc-cinderplugin   60m

and logs shows
I0311 04:35:21.807237       1 mount_linux.go:405] Attempting to determine if disk "/dev/vdf" is formatted using blkid with args: ([-p -s TYPE -s PTTYPE -o export /dev/vdf])
I0311 04:35:21.810667       1 mount_linux.go:408] Output: "DEVNAME=/dev/vdf\nTYPE=ext4\n", err: <nil>
I0311 04:35:21.810691       1 resizefs_linux.go:53] ResizeFS.Resize - Expanding mounted volume /dev/vdf
I0311 04:35:21.814298       1 resizefs_linux.go:66] Device /dev/vdf resized successfully

resize ok, but the size is still actually 1G
# kubectl exec nginx1 -- df -h /var/lib/www/html
Filesystem      Size  Used Avail Use% Mounted on
/dev/vdf        976M  2.6M  958M   1% /var/lib/www/html

I don't have admin cred for this openstack so don't know why failed to extend (maybe policy ? )
but anyway better to detect this and report to upper layer...
What you expected to happen:
How to reproduce it:
Anything else we need to know?:
Environment:

openstack-cloud-controller-manager(or other related binary) version:
OpenStack version:
Others:

@jichenjc Can we close this? with recent change, the failure is reported well before right?

yes, I think at least we prevent that happen

authors: jichenjc ramineni

repo: kubernetes/cloud-provider-openstack


text:
occm: LB: Fall back to TCP health mon w/o HTTP.

If the Loadbalancer does not support HTTP health-monitor, we currently fail to create one. This is currently the case with OVN loadbalancers, and knowledge that HTTP health-mon is unsupported is hardcoded into occm. While HTTP is preferable and is on the roadmap for OVN, it is not straight-forward and not likely to happen very soon.
TCP health-monitoring is supported and still detects the vast majority of cases with unavailable service, e.g. situations where a node is unavailable, the listening process has died or the node is severed from the network. So TCP health-mon is much better than no health-mon.
This patch implements an unconditional fall back to TCP health monitoring if HTTP health monitoring is not available. This is similar to UDP where we already use UDP-CONNECT health mon. The patch also outputs the type of health mon into the logs.
Tested with OpenStack Zed using OvS-3.1.1 and OVN 23.03 (SCS R4), k8s-v1.26 and -v1.27 and occm-v.26.2 and -1.27. Test scenario using nginx-ingress with externalTrafficPolicy: Local.

What this PR does / why we need it:
Without this patch, OVN provider octavia loadbalancers can not have health-monitors for TCP listeners, as OCCM wants to create an HTTP health-monitor, which OVN LBs don't currently support.
With it, we fall back to TCP health-monitors, which still cover the vast majority of situations with non-working backend member service and is certainly much better than no health-mon.
This makes OVN LBs a really attractive choice in front of a service with externalTrafficPolicy: local, as OVN LB does retain the original client IP (unlike the amphorae where you need to do workarounds with proxy protocol to get the information).
Which issue this PR fixes(if applicable):
fixes #2225
Special notes for reviewers:

Containers to test are on:
registry.scs.community/occm-kg/garloff/openstack-cloud-controller-manager:v1.27.103
registry.scs.community/occm-kg/garloff/openstack-cloud-controller-manager:v1.26.203
I would like to see this patch applied not just to master, but also v1.27, v1.26 and v1.25 stable branches.
Release note:

[occm] Support health-mon for OVN loadbalancers by falling back from HTTP to TCP.

This PR addresses issue #2225.

/ok-to-test

/approve
@dulek please comment in case you have ,thanks

I'm struggling to find any documentation for the other end of this health check, but this GKE documentation hints that this behaviour might not be correct: https://cloud.google.com/kubernetes-engine/docs/concepts/service-load-balancer-parameters#spd-hc-port

Note: The kube-proxy always responds to packets sent to the health check node port. Health checks for LoadBalancer Services cannot be answered by serving Pods.

A TCP check would presumably always return success in this case.

I'm struggling to find any documentation for the other end of this health check, but this GKE documentation hints that this behaviour might not be correct: https://cloud.google.com/kubernetes-engine/docs/concepts/service-load-balancer-parameters#spd-hc-port

Note: The kube-proxy always responds to packets sent to the health check node port. Health checks for LoadBalancer Services cannot be answered by serving Pods.

A TCP check would presumably always return success in this case.

I think this piece [1] would make the health monitor to actually check the nodePort and not healthCheckNodePort in this case.
[1] https://github.com/openshift/cloud-provider-openstack/blob/a7c2d10b1add321cf1bee5f8a2c7896d51e42a40/pkg/openstack/loadbalancer.go#L1288-L1290

I still don't understand how this would work. The documentation for the TCP health monitor says:

TCP health monitors open a TCP connection to the back-end server’s protocol port. Your custom TCP application should be written to respond OK to the load balancer connecting, opening a TCP connection, and closing it again after the TCP handshake without sending any data.

But we don't have a custom TCP application running on healthCheckNodePort which returns OK, do we?

But we don't have a custom TCP application running on healthCheckNodePort which returns OK, do we?

And we should not need one. Normally TCP health checking means opening a TCP connection (SYN packet) and considering the connection to be successful, if the connection is established (SYN/ACK).
https://www.haproxy.com/documentation/aloha/latest/load-balancing/health-checks/tcp/
That is a proper L4 check, sending data or waiting for some specific "OK" would create a L7 check (and we should then use HTTP, of course.)
So I suspect the OpenStack docu to be misleading here. Will do some testing to be sure ...

I pushed an explicit check to ensure we can only use TCP health-mon if we have a TCP LB.
(The UDP case was safe before, but let's make it explicit and robust.)
Testing: docker pull registry.scs.community/occm-kg/garloff/openstack-cloud-controller-manager@sha256:6c3d70c3a10e0411a6696c13634991ea033f1831f298e724c6d9343f7bc1e3fa//

We have 2 major mismatches here:
We have Octavia documentation suggesting that a TCP check expects an OK response, but nothing will deliver that. The suggestion is that the documentation is wrong. If that's the case I'd prefer to see strong evidence of that, a long-form comment explaining this the the future similarly-confused maintainer, and preferably a linked docs patch against the Octavia docs to fix it.
If the Octavia documentation is not correct and the TCP check is indeed just a SYN/ACK check then we still have documentation (admittedly for GKE) suggesting that we will always get a response on this port whether a pod is present or not, suggesting that this isn't a valid health check.
We need code comments strongly backing up whatever choice we make here. As it stands I can't convince myself that this behaviour is correct. That's not to say it's incorrect, but it's sufficiently in doubt that we need to carefully document the assumptions we've made so they can be confidently challenged by future-us.

We have 2 major mismatches here:
We have Octavia documentation suggesting that a TCP check expects an OK response, but nothing will deliver that. The suggestion is that the documentation is wrong. If that's the case I'd prefer to see strong evidence of that, a long-form comment explaining this the the future similarly-confused maintainer, and preferably a linked docs patch against the Octavia docs to fix it.

Sure, makes sense, anyway this wording sounds like it's just a connection being created:

TCP health monitors open a TCP connection to the back-end server’s protocol port. Your custom TCP application should be written to respond OK to the load balancer connecting, opening a TCP connection, and closing it again after the TCP handshake without sending any data.

If the Octavia documentation is not correct and the TCP check is indeed just a SYN/ACK check then we still have documentation (admittedly for GKE) suggesting that we will always get a response on this port whether a pod is present or not, suggesting that this isn't a valid health check.

In this case we won't be calling that endpoint at all as we will not use healthCheckNodePort when lbaas.canUseHTTPMonitor() returns false [1]. Healthmonitor will call the Service NodePort directly and with ETP=Local that's a good source of truth about which nodes are hosting the Service pods.

We need code comments strongly backing up whatever choice we make here. As it stands I can't convince myself that this behaviour is correct. That's not to say it's incorrect, but it's sufficiently in doubt that we need to carefully document the assumptions we've made so they can be confidently challenged by future-us.

+1 for more comments! I haven't added enough myself. We should especially add comment to [1].
[1] https://github.com/kubernetes/cloud-provider-openstack/blob/bd767ba5d4493d2aa7965d57286f1e6460e9dba9/pkg/openstack/loadbalancer.go#L1288-L1290

@dulek This is approved but it sounds like we have doubts about it now?

@dulek This is approved but it sounds like we have doubts about it now?

Yes, we feel like the use case described in the PR and bug should just work in current state of the code. Waiting for @garloff input here.

@dulek @jichenjc We should probably remove the approval. If the bot complains that I'm not allowed to do this, it's probably the right command :)
/approve cancel

/remove-approve

/shrug

/approve cancel

@mdbooth done I removed the approve just now

This one is no longer needed.
Thanks for all the explanations and doc improvements!

authors: dulek garloff jichenjc mdbooth


text:
Add keystone-webhook-auth sample for ubuntu 16.04

What this PR does / why we need it:
Sometimes we had questions how to configure keystone-webhook-auth
on ubuntu 16.04, because that is a little far from current doc
explanation. So this adds the sample configuration for ubuntu 16.04
users.
Release note: NONE

Hello @oomichi thanks for your contribution.
Why this documentation is specific to Ubuntu ? It looks generic to me. I think we can remove the reference to Ubuntu.

@zioproto
because I am testing the feature on ubuntu only and I am not sure the file paths of configurations under /etc are the same on the other distributions.
If you are sure that, I'd like to remove ubuntu from the doc :-)

Let's leave this as-is for now.
/lgtm
/approve

authors: dims oomichi zioproto


text:
Investigate API Throttling in Node Controller

ref: https://github.com/kubernetes/kubernetes/issues/75016
For large clusters, we're seeing API throttling from providers becoming more common. Taking node-controller as an example, it will call a "get node" api request per node on every sync loop. For a 1000 node cluster that's could be 1000 get requests per minute which can result in users running out of API quotas.

/assign @aoxn @andrewsykim

SIG OpenStack has seen similar issues, but we're addressing in our own implementations. We would welcome a generic solution if one would be appropriate, but we're fine with adding cloud-specific tuning variables on our provider.

@hogepodge Cool work.   Could you share your solutions with us?

/remove-lifecycle stale

Investigate severity of API throttling for v1.16

If folks have user stories on how bad the API throttling is for clusters that would be really helpful in determining the priority for this issue.

This would be the issue for Azure. Refer #30.

/remove-lifecycle stale

/lifecycle frozen

/help

authors: andrewsykim aoxn cheftako feiskyer hogepodge

repo: kubernetes/cloud-provider


text:
Updated .gitignore.

/sig multicluster

@gyliu513 This looks good overall, but I have one small comment.

/approve
/lgtm

repo: kubernetes/cluster-registry


text:
kube-apiserver fails to start on secondary master node

Then setting up a cluster using Ansible with two masters on Fedora 25, the kube-apiserver service fails to start on the secondary master node.
There look to me like there is a certificate that is missing on the second node.
++ /usr/bin/kube-apiserver --logtostderr=true --v=0 --etcd-servers=http://kubelab1:2379,http://kubelab2:2379 --insecure-bind-address=127.0.0.1 --secure-port=443 --allow-privileged=true --service-cluster-ip-range=10.254.0.0/16 --admission-control=NamespaceLifecycle,LimitRanger,ServiceAccount,ResourceQuota --tls-cert-file=/etc/kubernetes/certs/server.crt --tls-private-key-file=/etc/kubernetes/certs/server.key --client-ca-file=/etc/kubernetes/certs/ca.crt --token-auth-file=/etc/kubernetes/tokens/known_tokens.csv --service-account-key-file=/etc/kubernetes/certs/server.crt --bind-address=0.0.0.0
I1219 16:02:45.330796    9876 genericapiserver.go:629] Will report 192.168.20.39 as public IP address.
F1219 16:02:45.331033    9876 server.go:238] Invalid Authentication Config: open /etc/kubernetes/certs/server.crt: no such file or directory
Certificates on first master node:
[root@kubelab1 ~]# ls -l /etc/kubernetes/certs/
total 40
-r--r-----. 1 kube kube-cert 1338 Dec 19 15:51 ca.crt
-r--r-----. 1 kube kube-cert 4557 Dec 19 15:51 kubecfg.crt
-r--r-----. 1 kube kube-cert 1708 Dec 19 15:51 kubecfg.key
-rw-rw----. 1 root kube-cert 4557 Dec 19 15:51 kubelet.crt
-rw-rw----. 1 root kube-cert 1704 Dec 19 15:51 kubelet.key
-r--r-----. 1 kube kube-cert 5051 Dec 19 15:51 server.crt
-r--r-----. 1 kube kube-cert 1704 Dec 19 15:51 server.key
Certificates on second master node:
[root@kubelab2 ~]# ls -l /etc/kubernetes/certs/
total 16
-rw-r--r--. 1 root root 1338 Dec 19 15:51 ca.crt
-rw-r--r--. 1 root root 4557 Dec 19 15:51 kubecfg.crt
-rw-r--r--. 1 root root 1708 Dec 19 15:51 kubecfg.key
My inventory file look like this:
[masters]
kubelab1
kubelab2
[etcd:children]
masters
[nodes]
kubelab1
kubelab2

See #2369 for a fix.

It is really helpful, thanks! @galexrt

@xialonglee Did #2369 fix this issue for you?

@galexrt Yes, thanks. I use it before it was merged : )

This can now be closed. The Ansible code has been changed so multi apiservers are now working.

authors: bjornl galexrt xialonglee

repo: kubernetes/contrib


text:
Add a publisher that publishes the staging client to its own repository daily

You can see the sample commits here: https://github.com/caesarxuchao/client-go/commits/master (see last few commits)
@lavalamp @foxish

This change is

@lavalamp PTAL. Thanks.

@caesarxuchao Lint errors from hack/verify-all.sh -v are making the CI build fail.

OK, just a few more nits.

Review status: 0 of 13 files reviewed at latest revision, 6 unresolved discussions, some commit checks failed.

mungegithub/mungers/publisher.sh, line 23 [r3] (raw file):

echo $@
if [ ! $# -eq 6 ]; then
    echo "usage: publisher source_dir destination_dir source_url destination_url token"

add " temp_mem_dir"?

mungegithub/mungers/publisher.sh, line 48 [r3] (raw file):

git clone "${DSTURL}" "${DST}"
pushd "${DST}" > /dev/null
rm -r ./*

Something I thought of last night while trying to go to sleep: does this behave OK after we switch to the next release, e.g. 1.5? Now that I look at it I think it correctly  handles this. OK.

mungegithub/mungers/publisher.sh, line 49 [r3] (raw file):

pushd "${DST}" > /dev/null
rm -r ./*
cp -a "${SRC}/." "${DST}"

Maybe add in a comment somewhere near the top that both src and dst must be absolute paths?

Comments from Reviewable

Review status: 0 of 13 files reviewed at latest revision, 9 unresolved discussions, some commit checks failed.

mungegithub/mungers/publisher.sh, line 23 [r3] (raw file):
Previously, lavalamp (Daniel Smith) wrote…
> add " temp_mem_dir"?

Dpme

mungegithub/mungers/publisher.sh, line 48 [r3] (raw file):
Previously, lavalamp (Daniel Smith) wrote…
> Something I thought of last night while trying to go to sleep: does this behave OK after we switch to the next release, e.g. 1.5? Now that I look at it I think it correctly  handles this. OK.

Yeah, there is nothing related to the release version in the script.

mungegithub/mungers/publisher.sh, line 49 [r3] (raw file):
Previously, lavalamp (Daniel Smith) wrote…
> Maybe add in a comment somewhere near the top that both src and dst must be absolute paths?

Added in the usage string.

Comments from Reviewable

@lavalamp comments addressed, PTAL. Thanks.

Review status: 0 of 14 files reviewed at latest revision, 8 unresolved discussions.

Comments from Reviewable

Review status: 0 of 14 files reviewed at latest revision, 8 unresolved discussions.

mungegithub/Dockerfile-publisher, line 23 [r1] (raw file):
Previously, lavalamp (Daniel Smith) wrote…
> Hm, is there an easy way to build the publisher (script) into a separate container entirely?

Will iterate on this later.

Comments from Reviewable

Review status: 0 of 14 files reviewed at latest revision, 2 unresolved discussions.

Comments from Reviewable

Adding back the lgtm. It's a squash and a file header boilerplate fix.

authors: caesarxuchao foxish lavalamp


text:
Releasing Frakti v1.1

TODOs

[x] Bump version to v1.1 #242
[x] Release with v1.1 tag with release notes
[x] Update changelog

Draft release notes
Frakti v1.1 upgrades to kubernetes v1.8, enhances CNI network plugins and adds experimental unikernel support. It also includes various of enhancements and bug fixes.
Features and Updates

#192 Improves CNI plugin compatibility
#196 #208 Adds general support for CNI plugins, e.g. flannel and calico plugin
#219 #223 #226 Adds experimental support for unikernel
#217 Fixes problem of weave plugin
#199 #207 Adds cinder flexvolume plugin
#188 Fixes CNI podName problem
#189 Fixes CNI cleanup when sandbox runs failure
#205 Increases memory limits for kube-dns
#211 #212 #221 #224 #230 Adds unit tests for various packages

External Dependency Version Information

Kubernetes v1.8
Hyperd v1.0
Docker v1.12-v17.03

All done, will close it. 🥇

authors: feiskyer resouer

repo: kubernetes/frakti


text:
Docker image for ppc64le arch

This PR is for supporting docker image for ppc64le platform.

/cc @adamreese @technosophos

This and #1930 are raising the concern that maybe we need to revisit how the entire canary/release build process is working. The backpressure caused in CI by increasing the build time is having a negative effect on handling regular pull requests (since the build queue keeps getting longer and longer).
If we can offload some of the build pressure by making a CI/CD change then we can add things like dockerized builds for lots of platforms, and do so without increasing the build wait time to :45.
So let's hold off on merging this and #1930 until after 2.2.0 (so nobody gets distracted in these last few days), and then we can tackle the CI/CD situation without the risk of stalling the Feb. 14 release date.

@technosophos Just circling back to this. Maybe we should talk about the CI/CD stuff in one of the next public standup meetings

Bumping this back to Upcoming - Minor. @technosophos we should have a conversation about whether or not this is possible now

@mkumatag I see you're working on this upstream. Any idea on a general timeline when upstream should be able to support ppc64le architectures? :)

What kubernetes clusters run on ppc64le architectures? I don't even think kubernetes itself supports running on ppc64le at this point. kubernetes/kubernetes#38067
To be clear, I'm all for enabling all architecture types. I just want to be cautious about adding support for running Helm on alternative chip architectures that kubernetes core is unprepared to support.

kubernetes/kubernetes#38067 issue is ubmrella issue which is pointing to lot of thing. Currently kubernetes is building binaries for most of the architectures, you can find bits @ https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG-1.11.md#v1110-alpha1. And even we run tests on ppc64le platform and published in test-grid.

hi everybody! Please see my answer. I'm interested in participating to the discussion!

closing as irrelevant for Helm 3 as Tiller is being removed, and therefore there's no need to build a ppc64le docker image. Thanks!

authors: alicefr bacongobbler mkumatag technosophos thomastaylor312

repo: kubernetes/helm


text:
Remove additional quote in log format

Hey Ho Community,
while writing a logstash grok pattern for nginx ingress controller i realized a bug in the log format in autogenerated nginx.conf
This line is generated in default:
log_format upstreaminfo '$remote_addr - [$proxy_add_x_forwarded_for] - $remote_user [$time_local] "$request" $status $body_bytes_sent "$http_referer" "$http_user_agent" $request_length $request_time [$proxy_upstream_name] $upstream_addr $upstream_response_length $upstream_response_time $upstream_status"';

From my point of view the quote after upstream_status is too much.
Unsure if i am right:
https://github.com/kubernetes/ingress/blob/master/controllers/nginx/pkg/config/config.go#L50
Greetings, Thomas

Closing. Fixed in #481

authors: aledbf tsupertramp

repo: kubernetes/ingress


text:
Write valid JSON from kubectl cluster-info dump

What would you like to be added:
kubectl cluster-info dump writes out cluster info in JSON format, followed by one line:
Cluster info dumped to standard output

I would like that last line written to standard error
Why is this needed:
If the diagnostic is written to standard error, the output becomes valid JSON.
/sig cli

The relevant code is https://github.com/kubernetes/kubectl/blob/0555a86aaff9f0ba20dbc066dfaa1891222def87/pkg/cmd/clusterinfo/clusterinfo_dump.go#L292-L294

Precedence for using STDERR for verbosity
https://github.com/kubernetes/kubectl/blob/08c1f25495df730ea63fa7bb6b282e08ac4cd74e/pkg/cmd/plugin/plugin.go#L136

If dest is stdout, can we just suppress this message entirely?
Regarding the precedent for using stderr for verbosity, I actually just “fixed” that to use stdout 😆 in a recent PR, because I thought it was a mistake.
Kubectl does have a verbose flag that could be used for extra verbosity, and some commands make better use of that than others.

If dest is stdout, can we just suppress this message entirely?

Fine by me!

/assign

/area kubectl
/kind feature

repo: kubernetes/kubectl


text:
Remove inconsistent use of addons

This is the only place in all of the documentation where addon(s) is used
instead of addons. Even though with brackets it can be read as one or more
addons, it looks strange and inconsistent with the rest of the documentation.

NOTE: Please check the “Allow edits from maintainers” box below to allow
reviewers fix problems on your patch and speed up the review process.
Please delete this note before submitting the pull request.

This change is

I signed it!


text:
image v0.8.11 not published

FYI, the latest image is not published
gcloud container images list-tags k8s.gcr.io/node-problem-detector/node-problem-detector
DIGEST        TAGS          TIMESTAMP
f8f66daddc18  v0.8.10       2021-09-01T01:03:18
c4a75e50c3ee  v0.8.9        2021-06-25T22:52:08
072be0789048  v0.8.8        2021-05-15T03:30:50
0ce71ef6d759  v0.8.7        2021-02-19T02:17:37
22ac8343195e  v0.8.6        2021-01-22T22:44:17
07645e262314  v0.8.5        2020-11-19T01:27:27
3b5f074cf18a  v0.8.4        2020-09-01T07:14:34
9343960c22c6  0.8.3,v0.8.3  2020-07-30T20:09:31

/kind bug

@vteratipally if you are working on it, can you assign it to yourself? (ref https://github.com/kubernetes/node-problem-detector/pull/684#issuecomment-1206404338)

/assign @vteratipally

Please consider to push v0.8.11 tag to GCR. Its absence affects all default installations via Helm.

Hi we're also having issues with the fact that the image is missing.
❯ docker pull k8s.gcr.io/node-problem-detector/node-problem-detector:v0.8.11
Error response from daemon: manifest for k8s.gcr.io/node-problem-detector/node-problem-detector:v0.8.11 not found: manifest unknown: Failed to fetch "v0.8.11" from request "/v2/node-problem-detector/node-problem-detector/manifests/v0.8.11".```

Please publish image node-problem-detector:v0.8.11. We downgraded to node-problem-detector:v0.8.10 and it solved the issue.

Released v0.8.12
Docker Image: k8s.gcr.io/node-problem-detector/node-problem-detector:v0.8.12
/close

authors: JBOClara dfateyev dlovelace10 ialidzhikov maxres-ch vteratipally

repo: kubernetes/node-problem-detector


text:
Slo-monitor cleanup

Removing client-go's fork that is no longer used.
/assign @wojtek-t
/cc @marseel

/lgtm
/approve
Thanks!

authors: mborsz wojtek-t

repo: kubernetes/perf-tests


text:
[ClusterLoader2] run-e2e.sh improvements

Allows re-runs by checking if K8s objects exist before creating them
We only mutate temporary config, which prevents breakages for a local workflow

What type of PR is this?
/kind bug
What this PR does / why we need it:
After #2258 run-e2e failed on re-runs on the same cluster, and was messing with local KUBECONFIG. This change ensures that we only create service account and appropriate K8s configuration if it's missing. Additionally, we are creating a temporary configuration for CL2 usage.
/assign @wojtek-t

/lgtm
/approve
Thanks!

authors: jprzychodzen wojtek-t


text:
Doc.: orphaned fragment on k8s.io/docs/reference/access-authn-authz/authentication/

This is a Bug Report
Problem:
The page at https://kubernetes.io/docs/reference/access-authn-authz/authentication/ currently contains the confusing sentence fragment:
"An admin distributing private keys, a user store like Keystone or Google Accounts, even a file with a list of usernames and passwords."
Proposed Solution:
Probably, connect the preceding sentence and this fragment. (It looks like the fragment is examples of what the preceding sentence refers to.)
Page to Update:
https://kubernetes.io/docs/reference/access-authn-authz/authentication/

/language en
/kind bug
/help

authors: dsbos tengqm

repo: kubernetes/website


text:
404 link from concept page

This is a Bug Report
Problem:
The link (/docs/home/contribute/style/page-content-types/#concept) from the Concept page is not correct.
Proposed Solution:
Page to Update:
https://kubernetes.io/docs/concepts/

Thanks for spotting this.
/kind bug
/priority backlog
/language en

authors: mokua sftim


text:
Ingress Controllers

"AWS ALB Ingress Controller" is renamed to "AWS Load Balancer Controller". Name and link must be updated to "AWS Load Balancer Controller".

hello! first time contributor here!
Once this issue has been appropriately triaged - I'd be happy to work on it
/assign

/triage accepted

This issue seems to be fixed already.

authors: ravanapel sarnickaa tengqm


text:
[id] Broken links due to using "githubbranch" param

This is a Bug Report
Problem:
Regarding https://github.com/kubernetes/website/issues/31248, I found the similar broken links on other pages.
English pages have already been fixed. ref: https://github.com/kubernetes/website/pull/29311
id pages also need to be fixed.
Proposed Solution:
Fixes broken links including {{< param "githubbranch" >}} to master.
In the case of link to https://releases.k8s.io/, fixes to {{< param "fullversion" >}}.
ref: https://github.com/kubernetes/website/pull/29311#discussion_r685845250

/language id

authors: championshuttler krvaibhaw


text:
[ko]Translate website/content/en/blog/_posts/2022-05-13-grpc-probes-in-beta.md into Korean

This is a Feature Request
What would you like to be added
Translate website/content/en/blog/_posts/2022-05-13-grpc-probes-in-beta.md into Korean
Why is this needed
Not translated into Korean yet.
Comments
https://github.com/kubernetes/website/blob/main/content/en/blog/_posts/2022-05-13-grpc-probes-in-beta.md

/language ko
/assign

Page: https://kubernetes.io/blog/2022/05/13/grpc-probes-now-in-beta/
/triage accepted

Resolved by

#35280 (→ dev-1.24-ko.2)
#35767 (dev-1.24-ko.2 → main)

/close


text:
Dropdowns in the navbar not functional when JavaScript is disabled

This is a Bug Report

Problem:
The dropdowns for "Version" and "Language" in the website's navbar do not function when JavaScript is disabled. This limitation can make it difficult for users to switch between different versions or languages of the site, impacting usability and accessibility.
Expected Behaviour:
The "Version" and "Language" dropdowns should function correctly even when JavaScript is disabled, allowing users to switch between different versions and languages of the site.
Raised this issue as request in https://github.com/kubernetes/website/pull/41687#discussion_r1335470711
/sig docs
/area web-development
/priority important-longterm

/kind feature
/remove-kind bug
Adding this support would be a new feature

(no need to Cc: me on this issue - I'm going to unsubscribe)

/remove-priority important-longterm
We haven't decided that as a SIG

I don't see it feasible to completely avoid JS on the website.

I'd like to share my perspective. In my previous job, we encountered a situation where our work systems and browser settings didn't support JavaScript (security reasons). As a workaround, we had a simplified version of the internal website with limited functionality that we could use. It was essentially the same website but without JavaScript using checks in the code. But being fairly new here I'm not sure how feasible it is to implement or the efforts required, but we should definitely explore this accessibility aspect and invest in it if possible. But then again I'm new here and don't have any decision making power. Overall, it would be +1 in favor of doing this.

These dropdowns are implemented through [bootstrap] JS library, that's why it is not working when disabling JS in the browser.
we can implement through only CSS but appearance may change from current.

Another factor to consider. The Website is currently using docsy as its Hugo theme, where docsy has some builtin JS scripts as well.

authors: dipesh-rawat sftim steve-hardman tamilselvan1102 tengqm


text:
[ja] Translate content/en/docs/reference/glossary/device-plugin.md into Japanese

Note that this issue is for Japanese Speaker
This is a Feature Request
What would you like to be added
Translate content/en/docs/reference/glossary/device-plugin.md into Japanese
Why is this needed
There is no Japanese translation for this page
Comments

File to translate:

https://github.com/kubernetes/website/blob/main/content/en/docs/reference/glossary/device-plugin.md

Original:

https://kubernetes.io/ja/docs/reference/glossary/?all=true#term-device-plugin

日本語に翻訳する際は、以下のドキュメントを参考にしてください。

Japanese Localization document: https://kubernetes.io/ja/docs/contribute/localization/

/area localization
/language ja
/good-first-issue

/kind feature

/triage accepted

/assign

authors: Kei-Ta Okabe-Junya bells17


text:
etcd version >= 3.1.12

This is a...

[X ] Bug Report

Problem:
etcd version proposed is not valid:
root:~ #  kubeadm init --config=config.yaml
[init] Using Kubernetes version: v1.10.1
[init] Using Authorization modes: [Node RBAC]
[preflight] Running pre-flight checks.
	[WARNING FileExisting-crictl]: crictl not found in system path
Suggestion: go get github.com/kubernetes-incubator/cri-tools/cmd/crictl
[preflight] Some fatal errors occurred:
	[ERROR ExternalEtcdVersion]: this version of kubeadm only supports external etcd version >= 3.1.12. Current version: 3.1.10
	[ERROR ExternalEtcdVersion]: this version of kubeadm only supports external etcd version >= 3.1.12. Current version: 3.1.10
[preflight] If you know what you are doing, you can make a check non-fatal with `--ignore-preflight-errors=...`

Proposed Solution:
Change the version for 3.1.12, in section "Run etcd" part "systemd"
export ETCD_VERSION=v3.1.12
curl -sSL https://github.com/coreos/etcd/releases/download/${ETCD_VERSION}/etcd-${ETCD_VERSION}-linux-amd64.tar.gz | tar -xzv --strip-components=1 -C /usr/local/bin/
rm -rf etcd-$ETCD_VERSION-linux-amd64*

Page to Update:
https://kubernetes.io/docs/setup/independent/high-availability/#run-etcd

Fixed by #8099?

Confirm the issue has been fixed.
/close

authors: ThomasGsp mikebryant tengqm


text:
Minor UI fix

Closes #10685

/assign @bradtopol

/approve


text:
fix typo

一 => 已

/assign @caesarxuchao

/lgtm
/approve
thanks!

authors: adevjoe xichengliudui


text:
Update apiVersion on example-ingress to extensions/v1beta1

Update apiVersion on ingress to extensions/v1beta1
tested and verified working

/lgtm
/approve

authors: tengqm thecrudge


text:
Added documentation to support Topology Manager feature in Kubelet.

Added new document outlining feature
Updated feature-gates.md to include feature gate for feature
Update kubelet.md to include kubelet flags for feature

/milestone 1.16

/cc @nolancon

@lmdaly Today i.e 3rd Sept is the last date for docs PR to be in ready for review state.
Please make sure we are following the deadlines.
Thanks!

@sftim @nolancon @ConnorDoyle @klueska could you all take a final look through of the docs for Topology Manager? (Due date for documentation PRs is the 9th)
Thanks!

Hey, @lmdaly  @sftim we have a deadline for this PR to be in ready to be merged state by 7th September i.e tomorrow. Please make sure we are following the deadline.

Hi. I probably won't have time to provide more feedback between now and the v1.16 release.

@lmdaly @klueska I will need a technical lgtm on this before merging.

Minor nits, but nothing blocking.
/lgtm

@lmdaly Once the little format issues are fixed and the generated reference doc is remove. This is lgtm from me.

@simplytunde  Updated, removed generated doc + fixed any formatting issues I could see.

/lgtm

Preview: https://5d7401684e48d2000ce63f08--kubernetes-io-vnext-staging.netlify.com/docs/tasks/administer-cluster/topology-manager/

Preview: https://5d7401684e48d2000ce63f08--kubernetes-io-vnext-staging.netlify.com/docs/tasks/administer-cluster/topology-manager/

@simplytunde that's looking good to me!

@lmdaly Overall, it looks good but I will like to address this part.

The Topology Manager currently: - Works on Nodes with the static CPU Manager Policy enabled. See control CPU Management Policies - Works on Pods in the Guaranteed QOS Class QoS class  If these conditions are met, Topology Manager will align CPU and device requests.

Add a blank line before - Works on Nodes with the static CPU Manager Policy... if a list is intended here. Also, I noticed the repeated QOS Class

@lmdaly Overall, it looks good but I will like to address this part.

The Topology Manager currently: - Works on Nodes with the static CPU Manager Policy enabled. See control CPU Management Policies - Works on Pods in the Guaranteed QOS Class QoS class  If these conditions are met, Topology Manager will align CPU and device requests.

Add a blank line before - Works on Nodes with the static CPU Manager Policy... if a list is intended here. Also, I noticed the repeated QOS Class

Done! Let me know if the list is formatted correctly.

Yes, it is!
/lgtm

/approve

authors: VineethReddy02 klueska lmdaly sftim simplytunde xiangpengzhao zacharysarah


text:
fix operators's spelling problem [！= to !=]

/check-cla

please check your local email git config --list, whether the email address is the same as the one signed the agreement

/close

authors: RA489 stonecheung tengqm xichengliudui


text:
ID localization for administer cluster - sysctl

This PR addresses /docs/tasks/administer-cluster/sysctl-cluster page as mentioned here #22296

/assign @girikuncoro
/assign @danninov

Looks good, awesome job!
/lgtm
/approve

Looks good, awesome job!
/lgtm
/approve

Thanks @irvifa ... it is time to start another PR :)

authors: ariscahyadi irvifa


text:
Redirect to correct 1.19 release blog date

Resolves a 404 in an uneditable link from the official project twitter account: https://twitter.com/kubernetesio/status/1298722760189833220

/lgtm

authors: kbhawkey liggitt


text:
translate 2020-10-01

I noticed that there is no Chinese equivalent for this section, so I have translated it.

@Arhell

I received the email that the signing was successful, but the status of the robot did not change. Why is this?

我已经修改完了，感谢您的建议，再次麻烦您审查一次。

/lgtm
/approve

authors: ldsdsy tengqm


text:
Update API reference for Kubernetes v1.22

I squashed and rebased the changes in PR #29217, omitting updates to the Makefile and to the README. Those can land later.
@feloy FYI
/cc @PI-Victor
/milestone 1.22
/priority critical-urgent

thanks! i'll merge this right after the tests pass and i can check the website, since it's targeting dev-1.22

let's close this PR since https://github.com/kubernetes/website/pull/29217 is ready to merge. what do you think @PI-Victor @sftim

/remove-priority critical-urgent
/close

authors: PI-Victor annajung sftim


text:
fix error display string

Currently error looks like this:

1:17:45 PM: ERROR 2022/02/18 21:17:45 "alpha, beta, deprecated, stable" is not a valid feature-state, use one of %!q(MISSING)

/lgtm

/area web-development
/approve
Thanks

authors: SergeyKanzhelev mehabhalodiya sftim


text:
Use release codename matching user system

Having hardcoded xenial looks like a bug to me, but it should be confirmed by someone.

@jan-warchol can you outline how you tested this change, and on what versions of Debian / Ubuntu?

@jan-warchol can you outline how you tested this change, and on what versions of Debian / Ubuntu?

To be honest I just assumed it was a typo, I hadn't tested it.

/hold
Because this isn't tested, I'm recommending we take caution before merging this change.

@sftim should we close this now?

/close
Feel free to reopen if still interested in revising it.

authors: jan-warchol mehabhalodiya sftim tengqm


text:
[zh] sync blog: 2023-04-17-topology-spread-features.md

Add zh text to this blog:
content/zh-cn/blog/_posts/2023-04-17-topology-spread-features.md

See preview please.

/approve

authors: tengqm windsonsea


text:
remove https://kubernetes.io/docs/concepts/security/overview/

fixes #36591

I don't think we will drop this page completely.
A better option would be reorg these contents to make sure they are telling a consistent story with some logic behind them.

@sftim what's your view on it?

I've made https://github.com/kubernetes/website/pull/43176 - that's broadly how I'd like things to look.

/hold
I don't want to do the removal without at least also adding a redirect.

authors: satyampsoni sftim tengqm


text:
Clean up using-api/cel.md

Performed actions below:

Remove redundant spaces from those relatively big markdown tables
Put the link text and its url on a single line
Changes about bullets, consistency, and typo

See preview

/kind cleanup
/lgtm
/approve


text:
Update logging documentation

Juju option has changed.

This change is

/approve
/lgtm


text:
CLI: Updated kusk install UX

Updating the kusk install to match the new CLI UX.
UX Design:
https://www.figma.com/file/EkNk9tMEoAgYrwGP7N1dPm/Kusk-CLI?node-id=142%3A963

@jasmingacic to add the spinner

authors: aabedraba crjones

repo: kubeshop/kusk-gateway

license: MIT


text:
Project-level settings

I am using different versions of kubernetes and corresponding tooling (kustomize, helm, etc) for different projects - it would be great if Monokle could store these at the project/folder level so I can easily switch between them without having to make system-level changes

folds into #178

repo: kubeshop/monokle


text:
Add extension point for Jenkins plugins

Background
Jenkins has over 1800 plugins from the community. This is awesome. People almost can get all that they want from those plugins. And it also makes us be impossible to support all the Jenkins plugins.
In the real world, people might want to use different plugins in their teams. So, what should they do if DevOps does not provide these plugins? What will happen if they install other plugins into ks-jenkins?
First, users cannot use it if one plugin provides an option. Because there's no UI support for it.
Second, the controller will overwrite the Jenkins job configuration if users maintain it from Jenkins directly.
So, there're two sides that we need to discuss. For the front-end and backend sides.
Potential solutions

Add an update strategy

It provides the backend support

Potential Jenkins plugins

pipeline-multibranch-defaults plugin
git-parameter-plugin
active-choice-parameter (in Chinese)
image-tag-parameter (in Chinese)

add one more plugin: https://plugins.jenkins.io/git-parameter/

authors: LinuxSuRen calvinyv

repo: kubesphere-sigs/ks-devops


text:
How to enter the value of multi line text in export2config ?

When I use export2config in the workflow step, I add a key and value to the data, but the value can only be written in one line, not multiple lines. What should I do?

apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
  name: export2config
  namespace: default
spec:
  components:
    - name: export2config-demo-server
      type: webservice
      properties:
        image: oamdev/hello-world
        port: 8000
  workflow:
    steps:
      - name: apply-server
        type: apply-component
        outputs:
          - name: status
            valueFrom: output.status.conditions[0].message
        properties:
          component: export2config-demo-server
      - name: export-config
        type: export2config
        inputs:
          - from: status
            parameterKey: data.serverstatus
        properties:
          configName: my-configmap
          data:
            testkey: |
              testvalue
              value-line-2

authors: hanxinhang wonderflow

repo: kubevela/kubevela


text:
add  annotations and labels to gateway.cue

Description of your changes
add  annotations and labels to gateway.cue

Please fix PR Title Checker

please fix DCO

fix this issue  “https://github.com/kubevela/kubevela/issues/6396 ”

authors: StevenLeiZhang YanRyan


text:
Fix: Enables translate error property of gorm

Description of your changes

Fixes #
I have:

[ ] Read and followed KubeVela's contribution process.
[ ] Related Docs updated properly. In a new feature or configuration option, an update to the documentation is necessary.
[ ] Run yarn lint to ensure the frontend changes are ready for review.
[ ] Run make reviewableto ensure the server changes are ready for review.
[ ] Added backport release-x.y labels to auto-backport this PR if necessary.

Special notes for your reviewer

What is this field used for?

Sorry, I forgot to put that in the description. This is actually a bug. TranslateError field if enabled translates the error returned by the gorm drivers to gorm specific errors like ErrOnDuplicateKey. In our code we are using it here -
if match := errors.Is(dbAdd.Error, gorm.ErrDuplicatedKey); match {
			return datastore.ErrRecordExist
		}
		return datastore.NewDBError(dbAdd.Error)

Without translation we can't compare both the error and hence it's causing a bug. More info can be found here - https://gorm.io/docs/error_handling.html#Dialect-Translated-Errors

repo: kubevela/velaux


text:
[release-4.12] Bug 2236112: Fix disk table crash after memory dump

📝 Description
VM Disk table crashed after doing a memory dump
🎥 Demo
After:

Before:

/lgtm

authors: metalice pcbailey

repo: kubevirt-ui/kubevirt-plugin


text:
glog shadow breaks transitive builds.

Is this a BUG REPORT or FEATURE REQUEST?:

Uncomment only one, leave it on its own line:

/kind bug

/kind enhancement

What happened:
the glog build shadowing glog -> ../../../pkg/staging/glog//
breaks transitive builds, if they have libs that actually depend on glog.
The whole dependency closure doesn't work.
vendor/kubevirt.io/kubevirt/pkg/log/log.go:58:24: undefined: glog.LogLevel
vendor/kubevirt.io/kubevirt/pkg/log/log.go:59:24: undefined: glog.LogLevel
Makefile:39: recipe for target 'vet' failed

What you expected to happen:
For kubevirt to not shadow glog.
How to reproduce it (as minimally and precisely as possible):
Copy the  cmd/example-hook-sidecar folder into an empty folder.
copy this Gopkg.toml
https://gist.github.com/43f0fddf5876eb26f510d16c71923ead
and try building
Anything else we need to know?:
Environment:

KubeVirt version (use virtctl version):

Latest head as of today - see Gopkg.toml for reference

@senior7515 let me remove the additional public functions and fields. That should make it work again. Then we should be able to have both: Transitive builds and structured logging for kubevirt. Thanks!

Keeping the issue open until @senior7515 verified that it works.

verifying today. will do in a couple hours.
Sent from my mobile, please excuse my handwriting.
On Thu, Oct 18, 2018, 4:51 AM Roman Mohr notifications@github.com wrote:

Reopened #1612 https://github.com/kubevirt/kubevirt/issues/1612.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/kubevirt/kubevirt/issues/1612#event-1911626352, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAKsZiOVL2nbSV0iAU7RQ6RZb2vK60H9ks5umEEYgaJpZM4XZ1ay
.

Works! thanks!

repo: kubevirt/kubevirt


text:
upgrading to kubevirt v0.41.0-rc.0 with OLM on OKD/OCP 4.8 doesn't work

Is this a BUG REPORT or FEATURE REQUEST?:
/kind bug
What happened:
Upgrading (from different older releases) to kubevirt v0.41.0-rc.0 with OLM on OKD/OCP 4.8 doesn't work.
Older versions of kubevirt-operator are writing something like:
    {
        "group": "admissionregistration.k8s.io",
        "hash": "",
        "lastGeneration": 1,
        "name": "virt-operator-validator",
        "namespace": "",
        "resource": "validatingwebhookconfigurations"
    },

under status.generations on the kubevirt CR.
Although hash and namespace were supposed to be mandatory fields, for some reason (probably another bug on older OLM versions), in the past this has never been an issue.
Now kubevirt v0.41.0-rc.0 introduces a minor and completely unrelated changes to kubevirt CRD:
                 supportedGuestAgentVersions:
+                    description: deprecated

due to this,
before really starting the upgrade process, the OLM is going to validate the compatibility of existing CRs with the CRD that it is going to deploy during the upgrade.
And the OLM on OCP/OKD 4.8 is more picky and so it detects that hash and namespace are not filled under status.generations[*] and so it refuses to start the upgrade process with something like:
  - lastTransitionTime: "2021-05-05T10:42:26Z"
    lastUpdateTime: "2021-05-05T10:42:26Z"
    message: 'error validating existing CRs against new CRD''s schema: kubevirts.kubevirt.io:
      error validating custom resource against new schema &apiextensions.CustomResourceValidation{OpenAPIV3Schema:(*apiextensions.JSONSchemaProps)(0xc013051600)}:
      [[].status.generations.hash: Invalid value: "null": status.generations.hash
      in body must be of type string: "null", [].status.generations.namespace: Invalid
      value: "null": status.generations.namespace in body must be of type string:
      "null"]'
    reason: InstallComponentFailed

The easiest solution is probably to fix the schema in the CRD shipped with kubevirt 0.41 declaring hash and namespace on status.generations[] as optional.
What you expected to happen:
The OLM on OCP/OKD 4.8 is able to upgrade to kubevirt v0.41.0-rc.0
How to reproduce it (as minimally and precisely as possible):
Try upgrading to kubevirt v0.41.0-rc.0 from v0.40 with OLM on OCP/OKD 4.8 and check the conditions on the relevant installPlan.
Anything else we need to know?:
Environment:

KubeVirt version (use virtctl version): v0.41.0-rc.0
Kubernetes version (use kubectl version): OCP/OKD 4.8
VM or VMI specifications:
Cloud provider or hardware configuration:
OS (e.g. from /etc/os-release):
Kernel (e.g. uname -a):
Install tools:
Others:

/release-blocker release-0.41

I think merging and backporting https://github.com/kubevirt/kubevirt/pull/5495 will fix this. It will generate the correct api definition, which we would then publish via HCO to OLM and the validation should pass then.

@davidvossel FYI

we have a potential fix here, https://github.com/kubevirt/kubevirt/pull/5609

Although hash and namespace were supposed to be mandatory fields, for some reason (probably another bug on older OLM versions), in the past this has never been an issue.

There was also a bug in the OLM that was not validating existing CRs against the new version of the CRD if that CRD was owned just by a single CSV (and this is obviously our case!).
This got fixed on the OLM side only 28 days ago and this perfectly explains why we start seeing this issue only now, see:
https://github.com/operator-framework/operator-lifecycle-manager/pull/2090/commits/35271e927752d6b8287400b30c08ff475b774d6f

authors: davidvossel rmohr tiraboschi


text:
Verbose Flag does not affect virtctl console

What happened:
I wanted to get verbose logging of virtctl console so that I could see the URL and headers it is creating but verbose logging does not work. Adding -v flag also does not enable verbose output for any level.
ubuntu@tanay-kv-test-4:~$ kubectl virt console testvm -v 8
Successfully connected to testvm console. The escape sequence is ^]

$

What you expected to happen:
The verbose log output of virtctl console. Expected logs like those that are shown when you run kubectl get pods -v 8
ubuntu@tanay-kv-test-4:~$ kubectl virt console testvm -v 8
<Expected some logs here>
Successfully connected to testvm console. The escape sequence is ^]

How to reproduce it (as minimally and precisely as possible):
Run virtctl console with the verbose flag, -v 8.
Additional context:
NA
Environment:

KubeVirt version (use virtctl version):
  ubuntu@tanay-kv-test-4:~$ kubectl virt version
  Client Version: version.Info{GitVersion:"v0.53.0", GitCommit:"1f95d8c546c476b6120ecc25c43dac4a4c1f7011", GitTreeState:"clean", BuildDate:"2022-05-09T14:10:03Z", GoVersion:"go1.17.8", Compiler:"gc", Platform:"linux/amd64"}
  Server Version: version.Info{GitVersion:"v0.45.0-dirty", GitCommit:"c9e87c4cb6292af33ccad8faa5fb9bf269c0fbf4", GitTreeState:"dirty", BuildDate:"2021-09-08T14:30:14Z", GoVersion:"go1.16.6", Compiler:"gc", Platform:"linux/amd64"}

Kubernetes version (use kubectl version):
  ubuntu@tanay-kv-test-4:~$ kubectl version
  Client Version: version.Info{Major:"1", Minor:"21", GitVersion:"v1.21.3", GitCommit:"ca643a4d1f7bfe34773c74f79527be4afd95bf39", GitTreeState:"clean", BuildDate:"2021-07-15T21:04:39Z", GoVersion:"go1.16.6", Compiler:"gc", Platform:"linux/amd64"}
  Server Version: version.Info{Major:"1", Minor:"21", GitVersion:"v1.21.3", GitCommit:"ca643a4d1f7bfe34773c74f79527be4afd95bf39", GitTreeState:"clean", BuildDate:"2021-07-15T20:59:07Z", GoVersion:"go1.16.6", Compiler:"gc", Platform:"linux/amd64"}

VM or VMI specifications:
  apiVersion: kubevirt.io/v1
  kind: VirtualMachine
  metadata:
    name: testvm
  spec:
    running: true
    template:
      metadata:
        labels:
          kubevirt.io/size: small
          kubevirt.io/domain: testvm
      spec:
        domain:
          devices:
            disks:
              - name: containerdisk
                disk:
                  bus: virtio
              - name: cloudinitdisk
                disk:
                  bus: virtio
            interfaces:
            - name: default
              masquerade: {}
          resources:
            requests:
              memory: 64M
        networks:
        - name: default
          pod: {}
        volumes:
          - name: containerdisk
            containerDisk:
              image: quay.io/kubevirt/cirros-container-disk-demo
          - name: cloudinitdisk
            cloudInitNoCloud:
              userDataBase64: SGkuXG4=

Cloud provider or hardware configuration: N/A

OS (e.g. from /etc/os-release): Ubuntu 18.04.2 LTS

Kernel (e.g. uname -a):
  Linux tanay-kv-test-4 4.15.0-51-generic #55-Ubuntu SMP Wed May 15 14:27:21 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

Install tools: N/A

Others: N/A

/triage accepted
/kind enhancement
This could be useful for debugging. Also this could be a good first issue.

/assign @raspbeep

@tanaypatankar, there is a reason you are not seeing any logs in this case. kubectl commands are requests against the k8s API, while virtctl console <vm> (equivalent of kubectl virt console <vm>) is done through channels(pipes), so there no URLs or headers. Is there any particular use case where you need the mentioned logs so I could provide a different solution?

From what I tracked, it calls https://github.com/kubevirt/kubevirt/blob/main/staging/src/kubevirt.io/client-go/kubecli/async.go#L48 this, which is a websocket API call.

authors: dhiller raspbeep tanaypatankar


text:
build: Cleanup explicit bazel-skylib dependency as no longer needed

What this PR does
Since updating rules_go, this dependency is no longer required.

Fixes #
Why we need it and why it was done in this way
The following tradeoffs were made:
The following alternatives were considered:
Links to places where the discussion took place:
Special notes for your reviewer
/cc @dhiller @xpivarc

Checklist
This checklist is not enforcing, but it's a reminder of items that could be relevant to every PR.
Approvers are expected to review this list.

[ ] Design: A design document was considered and is present (link) or not required
[ ] PR: The PR description is expressive enough and will help future contributors
[ ] Code: Write code that humans can understand and Keep it simple
[ ] Refactor: You have left the code cleaner than you found it (Boy Scout Rule)
[ ] Upgrade: Impact of this change on upgrade flows was considered and addressed if required
[ ] Testing: New code requires new unit tests. New features and bug fixes require at least on e2e test
[ ] Documentation: A user-guide update was considered and is present (link) or not required. You want a user-guide update if it's a user facing feature / API change.
[ ] Community: Announcement to kubevirt-dev was considered

Release note

NONE

@xpivarc @acardace one of the few reasons where I miss being a root approver :)

authors: brianmcarey dhiller


text:
Give the expecter more time on a e2e test to retrieve info

What this PR does / why we need it:
The Chassis test gives an Expect only one second to succeed. This is not
always enough. Give it a reasonable value of 10 seconds.
Fixes issues like
tests/vmi_configuration_test.go:2352
Expected success, but got an error:
    <expect.TimeoutError>: 1000000000
    expect: timer expired after 1 seconds
tests/vmi_configuration_test.go:2376

Which issue(s) this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close the issue(s) when PR gets merged):
Fixes #
Special notes for your reviewer:
Here an example job: https://prow.apps.ovirt.org/view/gcs/kubevirt-prow/pr-logs/pull/kubevirt_kubevirt/5082/pull-kubevirt-e2e-k8s-1.19/1372426865519628289
Release note:
NONE

/cc @dhiller
/cc @fgimenez

/retest


text:
netstat: Update VMI interface status report unit tests

What this PR does / why we need it:
The existing unit tests which cover the VMI interface status report is missing some realistic overall scenarios about the existing data available.
This change unifies and tries to place some rules on what is the expected data provided to the report processing.
The current netstat unit tests have been updated to reflect the
following expected behavior:

When regular interfaces are added, this is the expected state/input:

VMI spec interfaces and networks should be in sync with 1:1 relation.
Domain spec is expect to reflect the VMI spec, i.e. having the same
interfaces.
The filesystem cache should reflect the same interfaces as the VMI
spec.
The volatile cache is optional, reflecting the same interface.
The Guest Agent data is optional.

When SR-IOV interfaces are added, this is the expected state/input:

VMI spec interfaces and networks should be in sync with 1:1 relation.
The Guest Agent data is optional.
Notes: Caches do not exist and the domain spec interfaces do not
include the SR-IOV interfaces. These are under the hostdevice section.

Miscellaneous scenarios are also covered to reflect what happens when such cases occur. However, these are not expected to occur in a normal system operation. Future production changes may treat these scenarios explicitly to avoid undefined and nontrivial behavior.
Which issue(s) this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close the issue(s) when PR gets merged):
Fixes #
Special notes for your reviewer:
Depends on #6926
Only the last 6 commits are to be reviewed as part of this PR.
Release note:
NONE

/uncc rmohr vladikr

/cc @maiqueb @AlonaKaplan @ormergi @oshoval

/sig network

change: Added misc test scenarios

change: Rebase

change: Rebase

Change: Answered review: Added a SR-IOV test to show what happens when it is accompanied with a "regular" interface.

/retest

change: Rebase

/test pull-kubevirt-e2e-kind-1.22-sriov

change: Rebase
The reabse required the inclusion of infoSource to the unit tests.

change: Answered review feedback.

/approve

/retest

/retest

/retest

/retest

authors: AlonaKaplan EdDev


text:
network, netstat: Simplify status update

What this PR does / why we need it:
This change aims to simplify the status update logic for network
interface.
It follows the expected logic where:

The interface status is populated with IP data from the configuration
cache (written to during the network setup).
Afterwards, it gets updated by the data collected from the domain
configuration.
Lastly, it gets updated by the (optional) guest-agent data.

With the new logic in place, the SR-IOV reporting is partially fixed to
not report interfaces when the guest-agent is missing.
A full fix should come in a following change that resolves
https://github.com/kubevirt/kubevirt/issues/7050
Which issue(s) this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close the issue(s) when PR gets merged):
Fixes #
Special notes for your reviewer:
Depends on #6951 , only the last commit is to be reviewed.
Although the changes have been introduced gradually while developing, the end result seem too different from the original code. Therefore, it is recommended to go over both version of the code and see it indeed does the needed. The diff tooling will most likely not help.
Please also warn about missing coverage in unit tests if you notice any.
Release note:
NONE

/uncc vatsalparekh vladikr

/cc @oshoval @ormergi @orelmisan @dteplits

/sig network

Thanks
Since this area is delicate,
and the e2e test of infoSource doesn't check IPs
please consider to manually see we don't break the mac change behavior by this change
the ips should not appear as they appeared here
https://github.com/kubevirt/kubevirt/pull/6744#issuecomment-968279660
(might worth to add assert on a follow PR in order to automate it)
additional checks i did manually were:

run without guest agent
stop guest agent after there were some reports
worth to consider trying them please as well (we can add automation later if needed)

Since this area is delicate, and the e2e test of infoSource doesn't check IPs

What does that mean exactly?

please consider to manually see we don't break the mac change behavior by this change the ips should not appear as they appeared here #6744 (comment) (might worth to add assert on a follow PR in order to automate it)

How is it possible that this is not covered by unit and e2e tests?
If you have reviewed this change, do you see a problem?

additional checks i did manually were:
1. run without guest agent
2. stop guest agent after there were some reports
worth to consider trying them manually please as well (we can add tier 2 automation later if needed, at least the 2nd which is bit longer)

Manual tests have no value, they may be correct now and incorrect a second later when some other PR gets merged.
I use them for debugging and understanding how things work.
So even if I do this, and say it to the world, I do not expect anyone, especially the reviewers to believe me.
I was under the impression we did include unit and e2e tests to cover what has been done in the code. If we missed something, it should be added sooner than later.
If the e2e test are too costly, then at least a unit test should be in place. Do you see such tests missing?

Since this area is delicate, and the e2e test of infoSource doesn't check IPs

What does that mean exactly?

Infosource VMI with 3 interfaces should have the expected entries in vmi status
This test checks mac change
It normalize ips because the ips was not the focus of this change,
but since we saw that removing the merger from virt-launcher might break the expected behavior,
I just raised that it might worth to either see it isn't break by this change as well.
We can add on a follow PR an assert that the ips are expected to be empty on the domain interface after the mac is change
in order to protect (as mentioned above as well)

please consider to manually see we don't break the mac change behavior by this change the ips should not appear as they appeared here #6744 (comment) (might worth to add assert on a follow PR in order to automate it)

How is it possible that this is not covered by unit and e2e tests? If you have reviewed this change, do you see a problem?

see please explanation above, the ips were not the main scope, we decided to normalize it, and it only later found it worth to check that the ips should be empty after mac change
I didn't review deeply yet, because saw this test fails and should be fixed first
https://prow.ci.kubevirt.io/view/gs/kubevirt-prow/pr-logs/pull/kubevirt_kubevirt/7051/pull-kubevirt-e2e-k8s-1.22-sig-network/1480438057151762432

additional checks i did manually were:

run without guest agent
stop guest agent after there were some reports
worth to consider trying them manually please as well (we can add tier 2 automation later if needed, at least the 2nd which is bit longer)

Manual tests have no value, they may be correct now and incorrect a second later when some other PR gets merged. I use them for debugging and understanding how things work. So even if I do this, and say it to the world, I do not expect anyone, especially the reviewers to believe me.
I was under the impression we did include unit and e2e tests to cover what has been done in the code. If we missed something, it should be added sooner than later. If the e2e test are too costly, then at least a unit test should be in place. Do you see such tests missing?

about the 1st
Since guest agent it enabled by default, i don't think we have a e2e test that disable it and run some tests (even if we add we need to think what we want to cover).
we do have some unit tests for no guest agent
about the 2nd we don't have e2e, i think that https://github.com/kubevirt/kubevirt/pull/6951 unit tests pretty covers the building blocks of this flow (by checking when there is guest agent report, and by checking there isn't)
Personally i usually run some corner cases ad hoc manually, some deserves adding e2e tests and then we usually add them,
but some don't imo.

change: Fixed the fails in the e2e tests.
TODO: Cover this in the unit-tests.

change: The simplification has been reworked, to make things hopefully simpler.
The PR description has been also updated to suggest the review strategy: Although the changes have been introduced gradually while developing, the end result seem too different from the original code. Therefore, it is recommended to go over both version of the code and see it indeed does the needed.
Please also warn about missing coverage in unit tests.

Please consider splitting it to 2 commits, one that refactor to functions without logic change
and one that adds the new logic
It will be much easier and safer to review

Please consider splitting it to 2 commits, one that refactor to functions without logic change and one that adds the new logic It will be much easier and safer to review

If you refer to the partial fix, then this was not an explicit objective to fix it. It was an subsequent result of placing the flow in a simpler form. So I do not see how this can be split.
If you are referring to the overall flow that changed, which can be considered a logic change, I do not see how such a split is possible. The code reached the current state because everyone added one small piece to it, without adjusting the existing to support such additions in a logically simple manner. It had to be taken apart one step at a time and rebuilt.
Unlike in other refactoring, I saw no value in reflecting these steps, as it would have made it worse to the reviewer to try and track it. I suggest you follow my suggestion on how to review this PR, if you are interested in diving in.

Please consider splitting it to 2 commits, one that refactor to functions without logic change and one that adds the new logic It will be much easier and safer to review

If you refer to the partial fix, then this was not an explicit objective to fix it. It was an subsequent result of placing the flow in a simpler form. So I do not see how this can be split.
If you are referring to the overall flow that changed, which can be considered a logic change, I do not see how such a split is possible. The code reached the current state because everyone added one small piece to it, without adjusting the existing to support such additions in a logically simple manner. It had to be taken apart one step at a time and rebuilt. Unlike in other refactoring, I saw no value in reflecting these steps, as it would have made it worse to the reviewer to try and track it. I suggest you follow my suggestion on how to review this PR, if you are interested in diving in.

I refer to only the last commit, i think some parts of it were stripped to functions (lets say just the ones that can be done easily without logic change), and can be a separate commit,
and the rest can be on a commit on top of it

change: Rebase

I tried locally #7053 + this PR and the test fails due to the change of 7053 that asserts there is no IP reported for the "original" interface, in the mac change scenario
we expect to see the first snippet, and not the 2nd one as appears in this explanation #6744 (comment)
please check it
I think we should add masquerade tests for the scenarios like infoSource test is doing before taking this PR, (for example mac change) in other to see there are no more regressions

Root cause is this
https://github.com/kubevirt/kubevirt/pull/7051/files#diff-c2b23c7cf6d14c6f6a9e12f1a63d6c8004ead588e9d4d6a369aeea15701ca086L180
at the past in case there were any of the conditions in the main loop, the interfaces from the pod were overriden
now they are append

change: Rebase

/retest

/approve

/retest

/retest

authors: AlonaKaplan EdDev oshoval


text:
Kubewarden 1.20-rc1 release

Checklist
This issue tracks the release of a new version of Kubewarden. Please follow the checklist below to ensure a smooth release process.

[x] Bump policy server version in the Cargo.toml.
[x] Policy Server CI is green
[x] Tag policy server
[x] Bump kwctl version in the Cargo.toml
[x] Kwctl CI is green
[x] Tag kwctl
[x] Controller CI is green
[x] Tag controller
[x] Audit scanner code is using the correct version of the kubewarden-controller package
[x] Audit scanner CI is green
[x] Tag audit scanner
[x] Check if the Helm chart repository CI open a PR updating the Helm charts with the correct changes.

[x] Check if the kubewarden-controller, kubewarden-defaults and kubewarden-crds chart versions are correctly bumped
[x] Check if kubewarden-controller, kubewarden-defaults and kubewarden-crds charts have the same appVersion
[x] Check if CI for the Helm chart PR is green. If so, merge it.

1.20-rc1 is out

authors: flavio viccuad

repo: kubewarden/kubewarden-controller


text:
[WIP] Refactoring ukub log node with telemetry

:construction:
Done:
Refactored original ukub log node code.
Added inter process CSP receive thread.
Added basic telemetry storage functions for creating filenames and log entries.
Todo:
Add inter subsystem CSP receive thread.
Rework disk io task_logging function from the original ukub log node code.
Organize into Yotta style folders.
:construction:
/cc @kubostech/devs

So now that I've hijacked this PR from @cnalley it should be ready for some review.
This should be the full finished code for the log node. It's currently subscribing to all of the telemetry publishers and should be storing the data to the sd card in a single file per publisher.

Looks good to merge here :shipit:

authors: cnalley kyleparrott plauche

repo: kubostech/ukub-log-node


text:
Added Microsoft's Fluent Design System

Just thought of adding Microsoft's Fluent Design System, as it's one of the most underrated, yet organized modern design systems. Perhap's it's because people think you can only use it when designing for windows, or maybe it's because it's not as popular as material design... 🤷🏽♂

Thank you @kelvinelove for your contribution.

authors: kelvinelove kudapara

repo: kudapara/curated-design-tools


text:
Test Dirs can be tarballs from URLs

It is now possible In the list of TestDirs to provide a URL to a tar or tgz file which is a suite of tests bundled.   This can be in the TestSuite file or on the command line.
From command-line: kubectl kuttl test http://localhost:8000/e2e.tgz --start-control-plane=false
Or from TestSuite
apiVersion: kudo.dev/v1beta1
kind: TestSuite
parallel: 4
timeout: 120
testDirs:
  - /opt/test
  - http://localhost:8000/e2e.tar

This PR will be followed by the ability to provide a local tarball as well.
More context:
Prior to this work, I didn't realize that the kubeconfig file was created for kind was in a temp folder.  We are leveraging that folder for more now.  Any tarballs are downloaded to that folder.  This is specifically designed for any size tarball.  That tarball is then untarred in the temp folder and run from a folder like any of the other tests.
Signed-off-by: Ken Sipe kensipe@gmail.com

Thanks @ANeumann82 great review and feedback!   All concerns addressed.

repo: kudobuilder/kuttl


text:
wget https://huggingface.co/kuleshov/llama-7b-4bit/resolve/main/llama-7b-4bit.pt 404 error

--2023-06-29 21:50:16--  https://huggingface.co/kuleshov/llama-7b-4bit/resolve/main/llama-7b-4bit.pt
Loaded CA certificate '/etc/ssl/certs/ca-certificates.crt'
Resolving huggingface.co (huggingface.co)... 99.84.238.160, 99.84.238.118, 99.84.238.109, ...
Connecting to huggingface.co (huggingface.co)|99.84.238.160|:443... connected.
HTTP request sent, awaiting response... 404 Not Found
2023-06-29 21:50:17 ERROR 404: Not Found.

Indeed the link https://huggingface.co/kuleshov/llama-7b-4bit/resolve/main/llama-7b-4bit.pt yields "Entry not found". Even checking the repository shows that the .pt file does not exist: https://huggingface.co/kuleshov/llama-7b-4bit/tree/main. I personally had to resort to using the other weights such as https://huggingface.co/kuleshov/llama-65b-4bit/resolve/main/llama-65b-4bit.pt

authors: developerdenesh otakutyrant

repo: kuleshov/minillm


text:
Line numbers are shown incorrectly when ussing mock-fs package.

Issue

If you use mock-fs package the line numbers are shown icorrectly.
import Dog from "./Dog";
import * as mock from "mock-fs";

describe("Dog", () => {

	beforeAll(() => {
		mock({
			"path/to/file.txt": "my text content",
		});
	});

	afterAll(() => {
		mock.restore();
	})

	test("should woof", () => {
		const dog = new Dog();
		expect(dog.woof()).toBe("Woof!____ SHOULD FAIL AND DISPLAY LINE NUMBER 19");
               // but it shows error at line number 16
	});
});

Expected behavior

When running the tests, the line number should be shown correctly. But instead the JS line number is shown (not the TS input file line number)

Link to a minimal repo that reproduces this issue

https://github.com/jhm-ciberman/ts-jest-bug

Optional (but highly recommended) - Configure Travis (or your favorite system) with the minimal repo

I cannot configure it because the test NEEDs to fail to show the line number.

@jhm-ciberman allowSyntheticDefaultImports needed to be set to true when using default imports. I've sent a PR with the patch to the linked repo. Let me know if that works for you

@kulshekhar there is a repo setup for this error
git clone https://github.com/jhm-ciberman/docs_gm.git
cd docs_gm
git checkout 5e2920b
npm install
npm test

@thiagoh is it the same issue your facing?
In either case, it would be better to open a new issue (link to this if it helps) so that your specific case can be discussed/fixed there

@kulshekhar, I'm facing the same issue, yeah. But the repo I'm having these problems are private, unfortunately. Can you take a look at @jhm-ciberman 's repo?

@thiagoh I'd like to look into this but without a minimal repo, I'm hesitant because there have been several instances where looking at a larger project has resulted in false leads and wasted time.
If you can replicate this issue with just a couple of files in src and test folders, I'll be happy to take a look at it after/before work. Without that, I'll have to wait till I can set aside a longer window of time.
And if this is opened as a new issue, there's less chance of it being overlooked by mistake

authors: jhm-ciberman kulshekhar thiagoh

repo: kulshekhar/ts-jest


text:
[New game]: Quick Fingers

🎮 Game Request
A game which test the speed of your fingers, by displaying the ball in a random grid, and you have to quickly click on it.
Point down the features
The game will consists of a table like structures, with the cells being square. There will be a ball that will quickly change its position. You have a set of given time, click on the ball as much number of times as posssible, to score more.
Select program in which you are contributing
GSSoC24
Code of Conduct

[X] I follow CONTRIBUTING GUIDELINE of this project.

Hey @VijaySamant4368 !
Thank you for raising an issue 💗
You can self assign the issue by commenting /assign in comment 😀
Make sure you follow CODE OF CONDUCT and CONTRIBUTING GUIDELINES 🚀
Don’t Forget to ⭐ our GameZone🎮
Make sure you join our Discord🕹

/assign

Hey @VijaySamant4368 ! Thank you so much for your raising the issue💗
It’s all yours, you can come anytime again and make some contributions! 🚀
Alone, we can do little, but together we can do so much! 😇

Hey @VijaySamant4368 ! Thank you so much for your raising the issue💗
It’s all yours, you can come anytime again and make some contributions! 🚀
Alone, we can do little, but together we can do so much! 😇

repo: kunjgit/GameZone


text:
[Enhancement]: Improving the UI and adding Home icon in "Brain Burst Game"

Do you want to have the enhancement of existing game ? 😀 Describe yourself..
Game enhancement

I will enhance the UI of the game as enhancing the game's visual appeal is essential for creating a compelling, enjoyable, and professional experience that attracts and retains players.
I will add a Home Icon, adding it will improve the game's usability, making it more user-friendly and accessible, which can lead to higher user satisfaction and retention.

Describe the solution you'd like
Solution steps

Visual Appeal: Adding gradients, shadows, and rounded corners to create a modern look.
Interactivity: Implementing hover effects and transitions for a more engaging user experience.
Readability and Usability: Improving text visibility and providing clear visual feedback.
Home Icon: Adding Home Icon at the top of the game, it will help players to navigate to the Home Page easily.

Select program in which you are contributing
GSSoC24
Code of Conduct

[X] I follow CONTRIBUTING GUIDELINE of this project.

Hey @ShristiiSharma , You can't have another issue before completing the previous one 😀
you already have the following 1 open issues 👀 ! :
#3807

Hey @ShristiiSharma ! Thank you so much for your raising the issue💗
It’s all yours, you can come anytime again and make some contributions! 🚀
Alone, we can do little, but together we can do so much! 😇

Hey @ShristiiSharma !
Thank you for raising an issue 💗
You can self assign the issue by commenting /assign in comment 😀
Make sure you follow CODE OF CONDUCT and CONTRIBUTING GUIDELINES 🚀
Don’t Forget to ⭐ our GameZone🎮
Make sure you join our Discord🕹

/assign

authors: ShristiiSharma kunjgit