text:
Publish v1-0 version of the docs

We'd like to do the following

Start publishing master on v1-0.kubeflow.org
Have www.kubeflow.org continue to direct to the v0.7 version of the docs
When the docs on master are ready redirect www.kubeflow.org to the v1 version of the docs.

I think doing the above should be fairly straightforward based on the docs
We basically want to follow the process for cutting release branches.
The only difference is in netlify. We should point master/latest at the version of the site corresponding to the v0.7 branch not v1.0.

@jlewi The website at www.kubeflow.org now declares itself to be an unmaintained version of the docs, and gives people a link for up to date docs which points them back to the same place:

My recommendation is to keep www.kubeflow.org reflecting the master, without needing to do any redirects. When we're ready to start publishing the docs for an RC (in this case, the v1.0.0 RCs) then we should (a) make sure we've already created the archive version for the current docs (in this case v07. which we have created) and (b) change the version number on the master and on www.kubeflow.org to represent the new version (in this case, v1.0 RC) and add a banner on every page saying the docs now reflect the upcoming release. We can link people back to the latest archive (in this case, v0.7) for the stable release.

@sarahmaddox Can we just remove the banner on the v0.7-branch?
When people go to www.kubeflow.org they should see the v0.7 version of the docs.
I would rather not direct users to 1.0 docs and then force them to redirect. If we show 1.0 docs on www.kubeflow.org that is an invitation for people to try it out and get frustrated when things don't work.

The master version of the docs are now available on
https://master.kubeflow.org/
But you will get a
`NET::ERR_CERT_COMMON_NAME_INVALID
This server could not prove that it is master.kubeflow.org; its security certificate is from *.netlify.com. This may be caused by a misconfiguration or an attacker intercepting your connection.
`
In chrome you should be able to click on advanced and then just proceed. It looks like you can't be signed to chrome using your corporate account; using icognito or your personal account should work.

v0-7-branch.kubeflow.org still redirects to master.kubeflow.org I wonder if this is because we've configured kubeflow.org to direct to the the v0.7 branch?
kubeflow/website#1586 for the cert error.

I cannot access master.kubeflow.org on either my corp or my personal account in Chrome. I can access it in incognito.
Having the site show old, unmaintained docs is bad UX for contributors, whether we show the banner or not - they'll see a version of the docs that doesn't reflect what's in the repo. When their pull requests are merged, they won't see the update reflected in the docs. IMO we therefore need a banner of some sort, if we must show people the v0.7 docs.
If we're ready to start publishing the docs for the RC, then don't we want people to try it (in the full knowledge that it's an early release)?
I think it's confusing to have the site redirecting to an older branch for part of its life - this could last a couple of weeks for v1.0.
@abhi-g and @theadactyl I'm keen to know your opinion here. We did discuss this back in August 2018 (I can forward you the notes) and decided that we should publish master even if experimental. At that time, this was the policy followed by the other projects we looked at. I'm happy to discuss it again, but I do want to make sure we all agree.

@sarahmaddox what about https://master--competent-brattain-de2d6d.netlify.com/?

Having the site show old, unmaintained docs is bad UX for contributors, whether we show the banner or not - they'll see a version of the docs that doesn't reflect what's in the repo.

I agree its bad for contributors but what about users? If we start publishing 1.0 docs at www.kubeflow.org and showing them to users isn't that exposing users to our experiments?
My concern is that users will go to www.kubeflow.org try out 1.0, complain about it, and then we will tell them its not ready and to try v0.7.
How do we get the docs ready for 1.0 without exposing existing users to the churn and inconsistencies? Can we have some way to atomically publish all the 1.0 changes at once?

Yes, I can access https://master--competent-brattain-de2d6d.netlify.com/.
This also now works: https://v0-7.kubeflow.org/
I don't have a way to automatically merge all the PRs when we're ready, nor to atomically publish all the v1.0 docs at once. I still favor the solution of showing the experimental version on the main doc site when we have a reasonably stable RC, and publishing the docs serially from that point onwards.
I do see what you're saying about users, but whichever way we go, we're giving users a bad experience. If we redirect to a snapshot, users don't know that they're not getting the latest docs. They won't see the latest version of the docs unless we cherry-pick bug fixes. This could last a couple of weeks (or more) of each quarter.
However, I'm happy to go with the new solution, given that we seem to have opposing opinions here. To make things work, I think this is what needs to happen:

Make master.kubeflow.org accessible - fix the certificate error. This should be a P0 as the situation is currently not workable.

Update the release procedures, for at least the following:

Add the Netlify procedure for setting and resetting the redirect.
Make any other necessary changes to the Netlify procedures to reflect the updates made in this issue.
In the doc versioning procedure, don't enable the "archived" banner until the redirect is reset.

Update the docs README to let people know that their changes may not be immediately visible on the website, because of the redirects around release time, but that they can see their change in master.

Check all release procedures and docs procedures for any other necessary updates.

@sarahmaddox I think we can separate this into two questions

What do we for PRs that are aimed at the upcoming release
What do we show to users

We can either point www.kubeflow.org at the v0.7-branch or at master.
The reason I think we should point www.kubeflow.org at the v0.7-branch is that this unblocks 1.0 development on master.
The alternative would be to treat master as "v0.7" and do development of 1.0 on a branch.
I believe our reasoning in the past (and consistent for non-doc development) was to create stable release branches for users and then continue development on master.
If we think we should show users the latest docs on master even though they are under development we can repoint www.kubeflow.org at master.
The primary thing I want to address is unblocking PRs related to 1.0. e.g.
#1583
#1520
etc...
Merging these PRs into a branch seems preferable to putting holds on them until we are ready to review them and then trying to integrate them all at once. It also makes it easier to get a consistent view of what state the docs are in for 1.0.
I don't think we want to start merging 1.0 PRs though if they are directly visible to users. That's why i think we should point www.kubeflow.org at the v0.7 branch.
Once we are ready to make 1.0 docs visible we would point www.kubeflow.org back at master.
So master and www.kubeflow.org would only be out of sync for the short period leading up to a release during which we are trying to get the docs ready for 1.0 but not yet ready to publish them.

For the SSL certificate issue; the docs say to contact technical support. So I submitted a request.

Certificate has been fixed by netlfiy support.
I was able to access https://master.kubeflow.org/  with no more warnings.
kubeflow/kubeflow#4717 is pending to update instructions.

Awesome.
I think for Kubeflow Users the current release version is 0.7.x until we
release 1.0. Therefore www.kubeflow.org should be pointing to stable docs
from 0.7.
From developer perspective:

0.7 docs are mostly stable and shouldn't need changes. If in off cases
they do, then the developers can merge cherry picks, or make modifications
in 0.7 branch.
they should have easy way to update documents for upcoming release and
therefore should merge their update PRs to master.

So based on this, we have three categories for docs:

Archival: accessible to users via archival sites from versioned
branches. Developers can update these by merged to appropriate branch, an
uncommon activity.
Current: last release that is recommended for deployment to users. This
set of docs are stable and accessible to users via the site for
corresponding branch. But since this is the most common set of documents
that users should be accessing, this is what www.kubeflow.org should point
to. Updates to these from devs should again be less frequent and therefore
requiring cherry picks or merge into the branch corresponding to current
release is reasonable.
Upcoming: Most users should not be working with set until release is
final. Users accessing these should understand risks and be okay to use the
bleeding edge. Developers will most often be updating these documents as
they get features ready. Therefore master.kubeflow.org is an appropriate
site to access these. Also, for devs this matches seamlessly with their
development workflow into master.

@sarahmaddox @jlewi Hopefully the above reconciles our issues. Sarah this
evolves a bit from our previous discussion last year but I think moves us
in the right direction.
On Sat, Feb 1, 2020 at 8:07 PM Jeremy Lewi notifications@github.com wrote:

Certificate has been fixed by netlfiy support.
I was able to access https://master.kubeflow.org/ with no more warnings.
kubeflow/kubeflow#4717 https://github.com/kubeflow/kubeflow/pull/4717
is pending to update instructions.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/kubeflow/website/issues/1581?email_source=notifications&email_token=ACZ2UZTJWUIORRVIKNFG6TDRAZBJZA5CNFSM4KOIIV7KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEKRNGGY#issuecomment-581096219,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ACZ2UZT2NUZ2P3GQKDBNZE3RAZBJZANCNFSM4KOIIV7A
.

Thanks @abhi-g and @jlewi

Downgrading to P1 because I don't think the remaining work is blocking 1.0.
Remaining work is to get kubeflow/kubeflow#4717 merged updating the process for releasing the docs.

@jlewi PR https://github.com/kubeflow/kubeflow/pull/4717 is now merged. I think we can close this issue now.
We'll need to repoint www.kubeflow.org to master at some point, but I think the main goal of this particular issue was to publish the v1.0 docs on master.kubeflow.org, which is now done.
Please do re-open this issue if there's still work to do on it.
/close

authors: abhi-g jlewi sarahmaddox

repo: kubeflow/website


text:
Update Kubeflow Pipelines Standalone Deployment documentation to refrense to the latest version

Today the document refrences to 0.2.5 but 0.3.0 is out .
https://www.kubeflow.org/docs/pipelines/installation/standalone-deployment/
Happy to make a contribute if you point me to the right direction!

@JohanWork
You can follow the instruction in https://github.com/kubeflow/website#creating-and-updating-the-kubeflow-docs

Thanks @JohanWork! The version number for Pipelines is held in this file:
https://github.com/kubeflow/website/blob/master/layouts/shortcodes/pipelines/latest-version.html
/cc @Bobgy
/cc @rmgogogo
/cc @joeliedtke

Thnx @sarahmaddox pushed a pr for it here

/close
This doc is now referencing 0.5.1.

source: gharchive/issue

authors: JohanWork janeman98 joeliedtke sarahmaddox

license_type: permissive

license_source: github-api


text:
Added a section for deployment on Azure

Co-authored-by: rem20806 t-remcfa@microsoft.com
Co-authored-by: mohona17 t-moahme@microsoft.com
Not a robust and complete deployment guide, but more than enough to get Kubeflow deployed and running on Azure.
Upcoming PRs will have information on authentication. Will also serve as a base to be expanded upon during the upcoming doc sprint.

This change is

/ok-to-test
@MaanavD your commit might have a different identity than the github id you used to create the PR. Please see the CLA message

@abhi-g I checked my CLA, and all the e-mails I use at all have been signed. Is there a chance that it's checking my co-authors (I've also ensured their CLAs are signed) ?

Yes, its likely if there are commits in the PR with other authors
On Thu, Jun 6, 2019 at 11:05 AM Maanav Dalal notifications@github.com
wrote:

@abhi-g https://github.com/abhi-g I checked my CLA, and all the e-mails
I use at all have been signed. Is there a chance that it's checking my
co-authors (I've also ensured their CLAs are signed) ?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/kubeflow/website/pull/780?email_source=notifications&email_token=ACZ2UZT6H5H73LMOI53BDI3PZFGVTA5CNFSM4HVFIUP2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXDVYAQ#issuecomment-499604482,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ACZ2UZXWX6NWTYUDVCI6GBLPZFGVTANCNFSM4HVFIUPQ
.

Alright, I've ensured that all e-mails used in the commit have signed the CLA. Hopefully the bot recognizes it. Hope to see this PR merged!

/assign

Preview:
https://deploy-preview-780--competent-brattain-de2d6d.netlify.com/docs/azure/

Addresses https://github.com/kubeflow/website/issues/32

/lgtm
/approve

@MaanavD For the CLA, there's one commit with an email address that the CLA process can't identify. Please would you check? Sorry for all the admin on this. Once done, things should go smoothly. If that doesn't work then you may need to rebase the commits with the correct email address.

@MaanavD For the CLA, there's one commit with an email address that the CLA process can't identify. Please would you check? Sorry for all the admin on this. Once done, things should go smoothly. If that doesn't work then you may need to rebase the commits with the correct email address.

Hi @sarahmaddox , I double and triple checked that myself as well as my two teammates have signed the CLA for all accounts we could have potentially used. Is there any way to figure out which e-mail we're having issues with?

@googlebot please re-check the CLA.

Thanks for confirming the CLA signatures @MaanavD

source: gharchive/pull-request

authors: MaanavD abhi-g sarahmaddox


text:
Network policy E2E fails

Expected Behavior
Actual Behavior
2022-12-30T09:53:48.0127828Z Summarizing 6 Failures:
2022-12-30T09:53:48.0128460Z   [FAIL] [sig-network] Netpol NetworkPolicy between server and client [It] should allow ingress access from namespace on one named port [Feature:NetworkPolicy]
2022-12-30T09:53:48.0128842Z   /home/runner/go/pkg/mod/k8s.io/kubernetes@v1.26.0/test/e2e/network/netpol/test_helper.go:126
2022-12-30T09:53:48.0129486Z   [FAIL] [sig-network] Netpol NetworkPolicy between server and client [It] should enforce except clause while egress access to server in CIDR block [Feature:NetworkPolicy]
2022-12-30T09:53:48.0129860Z   /home/runner/go/pkg/mod/k8s.io/kubernetes@v1.26.0/test/e2e/network/netpol/test_helper.go:126
2022-12-30T09:53:48.0130500Z   [FAIL] [sig-network] Netpol NetworkPolicy between server and client [It] should allow ingress access on one named port [Feature:NetworkPolicy]
2022-12-30T09:53:48.0130871Z   /home/runner/go/pkg/mod/k8s.io/kubernetes@v1.26.0/test/e2e/network/netpol/test_helper.go:126
2022-12-30T09:53:48.0131600Z   [FAIL] [sig-network] Netpol NetworkPolicy between server and client [It] should ensure an IP overlapping both IPBlock.CIDR and IPBlock.Except is allowed [Feature:NetworkPolicy]
2022-12-30T09:53:48.0131961Z   /home/runner/go/pkg/mod/k8s.io/kubernetes@v1.26.0/test/e2e/network/netpol/test_helper.go:126
2022-12-30T09:53:48.0132532Z   [FAIL] [sig-network] Netpol NetworkPolicy between server and client [It] should allow egress access to server in CIDR block [Feature:NetworkPolicy]
2022-12-30T09:53:48.0132900Z   /home/runner/go/pkg/mod/k8s.io/kubernetes@v1.26.0/test/e2e/network/netpol/test_helper.go:126
2022-12-30T09:53:48.0133714Z   [FAIL] [sig-network] Netpol NetworkPolicy between server and client [It] should allow egress access on one named port [Feature:NetworkPolicy]
2022-12-30T09:53:48.0134091Z   /home/runner/go/pkg/mod/k8s.io/kubernetes@v1.26.0/test/e2e/network/netpol/test_helper.go:126

Steps to Reproduce the Problem

Additional Info

Kubernetes version:
Output of kubectl version:
(paste your output here)

kube-ovn version:
(paste your output here)

operation-system/kernel version:
Output of awk -F '=' '/PRETTY_NAME/ { print $2 }' /etc/os-release:
Output of uname -r:
(paste your output here)

should allow ingress access from namespace on one named port
should allow ingress access on one named port
should allow egress access on one named port
是一类问题，可以看到下面规则tcp.dst==0, 所以kube-ovn这边没处理named port需要加逻辑
ip4.src == $port.policy.default.ingress.allow.IPv4.0 && ip4.src != $port.policy.default.ingress.except.IPv4.0 && tcp.dst == 0 && outport==@port.policy.default && ip"

should enforce except clause while egress access to server in CIDR block
should ensure an IP overlapping both IPBlock.CIDR and IPBlock.Except is allowed
should allow egress access to server in CIDR block
是一类问题。主要是因为k8s netpo检查可达性的时候，目的ip用的对应pod的svc ip而不是pod ip，导致结果行为不一样

比如case 1
poda 去访问 podb （svcip 10.107.181.41, pod ip 10.16.1.115）
egress:

to:

ipBlock:
cidr: 10.16.0.46/4
except:

10.16.1.115
podSelector:
matchLabels:
pod: a
policyTypes:

Egress
规则如上

脚本期望： poda 访问podb不能通，
实际结果： poda 访问podb通了
对于kube-ovn的行为来说：
如果是poda去访问podb svcip, 那确实会导致实际结果是通的和脚本预期结果不一致。

如果是poda去访问podb podip，结果和脚本预期结果才是一样的。

第一类问题算是功能缺失，需要考虑怎么加上 named port 支持。
第二类问题测试是没问题的，如果不能访问某个 pod 那么通过 service 也不应该能访问。这个可能和 ovn 里的逻辑有关，有可能是先做的 acl 后做的 svc ，不知道后端 ip 导致的。这个可能要考虑下 networkpolicy 的 acl 该怎么加，可以参考下 ovn-kubernetes 这块是怎么实现的

是的 先做的acl,然后做dnat，

ovn acl中加options:apply-after-lb="true" 可以先dnat 后 acl

=====================================================================

should allow ingress access from namespace on one named port
should allow ingress access on one named port
should allow egress access on one named port

是一类问题， 直接用port的acl规则 ip4.src == $port.policy.default.ingress.allow.IPv4.0 && ip4.src != $port.policy.default.ingress.except.IPv4.0 && tcp.dst == 80 && outport==@port.policy.default && ip
用port name的acl规则 ip4.src == $port.policy.default.ingress.allow.IPv4.0 && ip4.src != $port.policy.default.ingress.except.IPv4.0 && tcp.dst == 0 && outport==@port.policy.default && ip
可以见到tcp.dst == 0没有解析到端口号，需要kube-ovn增加解析
=====================================================================

should enforce except clause while egress access to server in CIDR block
should ensure an IP overlapping both IPBlock.CIDR and IPBlock.Except is allowed
should allow egress access to server in CIDR block
是一类问题。主要是因为k8s netpo检查可达性的时候，目的ip用的对应pod的svc ip而不是pod ip，导致结果行为不一样

比如case 1 poda 去访问 podb （svcip 10.107.181.41, pod ip 10.16.1.115）
egress:
 - to:
   - ipBlock:
        cidr: 10.16.0.46/4
        except:
        - 10.16.1.115
  podSelector:
      matchLabels:
        pod: a
  policyTypes:
  - Egress

规则如上
脚本期望： poda 访问podb不能通，
实际结果： poda 访问podb通了
对于kube-ovn的行为来说： 如果是poda去访问podb svcip, 那确实会导致实际结果是通的和脚本预期结果不一致。 如果是poda去访问podb podip，结果和脚本预期结果才是一样的。

k8s应该是依赖dns来解析的

https://kubernetes.io/docs/concepts/services-networking/dns-pod-service/#srv-records
https://github.com/ovn-org/ovn-kubernetes/pull/1225#ref-issue-1514958371
看起来ovn-kubenetes也讨论过这个功能的实现，主要是因为处理重名问题麻烦，就没做了。

Namedport is still WIP

authors: changluyi oilbeater zhangzujian

repo: kubeovn/kube-ovn


text:
update ovs health check, delete connection to ovn sb db

What type of this PR

Bug fixes

1、update ovs health check, delete connection to ovn sb db
2、It's better for kube-ovn-monitor to keep running without ovn-central pod
Which issue(s) this PR fixes:
Fixes #1575

已回合release-1.10 和release-1.9 分支


text:
Need to set hostPID and hostIPC to false in Kured

As per the security recommendation to avoid containers sharing sensitive host namespaces, I need to set the hostPID and hostIPC to false on the pod spec in Kured.
We are using helm chart to deploy the Kured and when i deploy by assigning the value to false it is not reflecting in pod values.yaml.
Please let me know if any input is required.
Please assist me to solve this.

Hi @kavinkvb,
the helm-chart does not offer the hostPID and hostIPC to be set through the values.yaml file. The hostPID variable is hardcoded to true in the chart, because kured needs this setting right now to work properly. We know, that this is not ideal from a security pov, but there would be huge architectural changes needed to achieve this.

Hi @ckotzbauer
Thanks for your inputs.
I manually edited the hostPID to false in the daemonset after deploying the helm chart and this resolves the security recommendation.
Can you please suggest if this is the correct way of approach?
Also, in this case we need to change this value manually whenever we are redeploying the helm chart to avoid security recommendations.

Did you test, that kured successfully can reboot nodes with this config? When kured is just idle, the hostpid is not needed, so maybe it does not work now.

I'll have a look and let you know if face any challenges.
Thanks

@kavinkvb Do you have any feedback for us here?

authors: ckotzbauer kavinkvb

repo: kubereboot/charts


text:
fix build date on macos

use correct date parameters when using "make build" on macos.
macos' date is not aware of --rfc3339 parameter.

date: illegal option -- -
usage: date [-jnRu] [-r seconds|file] [-v[+|-]val[ymwdHMS]]
[-I[date | hours | minutes | seconds]]
[-f fmt date | [[[mm]dd]HH]MM[[cc]yy][.ss]] [+format]

Signed-off-by: Karsten Kosmala kosmala@cosmocode.de
/kind bug
/kind chore

Hi @kossmac, this logic is already macOS-aware but expects coreutils to be installed (for the gdate command, which doesn't exist on Linux and as such doesn't make sense in the "Linux" condition). Would that also work for you?

Hi @embik, sure thing, since you have to install other things to build anyway. Tested it with coreutils from homebrew.

Glad to hear that things are working as expected now!

authors: embik kossmac

repo: kubermatic/kubeone


text:
Azure: Assign security group to instances

What this PR does / why we need it:
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:
none

/lgtm
/approve

/override pull-machine-controller-e2e-kubevirt
Its currently being worked on
/override dco

authors: alvaroaleman kdomanski

repo: kubermatic/machine-controller


text:
E2E: "CSI attach test using HostPath driver" fails

The "CSI attach test using HostPath driver" test from kubernetes/test/e2e/storage/csi_volumes.go fails for me:
$ go run hack/e2e.go -- --provider=local --test --test_args="--ginkgo.focus=CSI.attach.test.using.HostPath.driver"
....
• Failure [40.263 seconds]
[sig-storage] [Serial] CSI Volumes
/nvme/gopath/src/k8s.io/kubernetes/_output/local/go/src/k8s.io/kubernetes/test/e2e/storage/utils/framework.go:22
  CSI attach test using HostPath driver [Serial][Feature:CSISkipAttach]
  /nvme/gopath/src/k8s.io/kubernetes/_output/local/go/src/k8s.io/kubernetes/test/e2e/storage/csi_volumes.go:125
    attachable volume needs VolumeAttachment [It]
    /nvme/gopath/src/k8s.io/kubernetes/_output/local/go/src/k8s.io/kubernetes/test/e2e/storage/csi_volumes.go:165

    Failed to create CSIDriver: CSIDriver.csi.storage.k8s.io "csi-hostpath" is invalid: []: Invalid value: map[string]interface {}{"kind":"CSIDriver", "apiVersion":"csi.storage.k8s.io/v1alpha1", "metadata":map[string]interface {}{"creationTimestamp":"2018-09-27T12:48:19Z", "generation":1, "uid":"9c1caf02-c253-11e8-a335-fcaa1497a416", "name":"csi-hostpath"}, "spec":map[string]interface {}{"attachRequired":true, "podInfoOnMountVersion":interface {}(nil)}}: validation failure list:
    spec.podInfoOnMountVersion in body must be of type string: "null"
    Expected error:
        <*errors.StatusError | 0xc422404900>: {
            ErrStatus: {
                TypeMeta: {Kind: "", APIVersion: ""},
                ListMeta: {SelfLink: "", ResourceVersion: "", Continue: ""},
                Status: "Failure",
                Message: "CSIDriver.csi.storage.k8s.io \"csi-hostpath\" is invalid: []: Invalid value: map[string]interface {}{\"kind\":\"CSIDriver\", \"apiVersion\":\"csi.storage.k8s.io/v1alpha1\", \"metadata\":map[string]interface {}{\"creationTimestamp\":\"2018-09-27T12:48:19Z\", \"generation\":1, \"uid\":\"9c1caf02-c253-11e8-a335-fcaa1497a416\", \"name\":\"csi-hostpath\"}, \"spec\":map[string]interface {}{\"attachRequired\":true, \"podInfoOnMountVersion\":interface {}(nil)}}: validation failure list:\nspec.podInfoOnMountVersion in body must be of type string: \"null\"",
                Reason: "Invalid",
                Details: {
                    Name: "csi-hostpath",
                    Group: "csi.storage.k8s.io",
                    Kind: "CSIDriver",
                    UID: "",
                    Causes: [
                        {
                            Type: "FieldValueInvalid",
                            Message: "Invalid value: map[string]interface {}{\"apiVersion\":\"csi.storage.k8s.io/v1alpha1\", \"metadata\":map[string]interface {}{\"creationTimestamp\":\"2018-09-27T12:48:19Z\", \"generation\":1, \"uid\":\"9c1caf02-c253-11e8-a335-fcaa1497a416\", \"name\":\"csi-hostpath\"}, \"spec\":map[string]interface {}{\"attachRequired\":true, \"podInfoOnMountVersion\":interface {}(nil)}, \"kind\":\"CSIDriver\"}: validation failure list:\nspec.podInfoOnMountVersion in body must be of type string: \"null\"",
                            Field: "[]",
                        },
                    ],
                    RetryAfterSeconds: 0,
                },
                Code: 422,
            },
        }
        CSIDriver.csi.storage.k8s.io "csi-hostpath" is invalid: []: Invalid value: map[string]interface {}{"kind":"CSIDriver", "apiVersion":"csi.storage.k8s.io/v1alpha1", "metadata":map[string]interface {}{"creationTimestamp":"2018-09-27T12:48:19Z", "generation":1, "uid":"9c1caf02-c253-11e8-a335-fcaa1497a416", "name":"csi-hostpath"}, "spec":map[string]interface {}{"attachRequired":true, "podInfoOnMountVersion":interface {}(nil)}}: validation failure list:
        spec.podInfoOnMountVersion in body must be of type string: "null"
    not to have occurred

    /nvme/gopath/src/k8s.io/kubernetes/_output/local/go/src/k8s.io/kubernetes/test/e2e/storage/csi_volumes.go:227
------------------------------
SSSSSSSSSSSSSSSSSSep 27 14:48:37.353: INFO: Running AfterSuite actions on all node
Sep 27 14:48:37.353: INFO: Running AfterSuite actions on node 1

Summarizing 2 Failures:

[Fail] [sig-storage] [Serial] CSI Volumes CSI attach test using HostPath driver [Serial][Feature:CSISkipAttach] [It] non-attachable volume does not need VolumeAttachment
/nvme/gopath/src/k8s.io/kubernetes/_output/local/go/src/k8s.io/kubernetes/test/e2e/storage/csi_volumes.go:227

[Fail] [sig-storage] [Serial] CSI Volumes CSI attach test using HostPath driver [Serial][Feature:CSISkipAttach] [It] attachable volume needs VolumeAttachment
/nvme/gopath/src/k8s.io/kubernetes/_output/local/go/src/k8s.io/kubernetes/test/e2e/storage/csi_volumes.go:227

Ran 3 of 1813 Specs in 158.815 seconds
FAIL! -- 1 Passed | 2 Failed | 0 Pending | 1810 Skipped --- FAIL: TestE2E (158.90s)
FAIL

I ran this after building Kubernetes from source (some recent master revision) and starting the cluster with:
RUNTIME_CONFIG= ALLOW_PRIVILEGED=1 FEATURE_GATES="BlockVolume=true,MountPropagation=true,KubeletPluginsWatcher=true,CSINodeInfo=true,CSIDriverRegistry=true"  hack/local-up-cluster.sh -O

/cc @verult @jsafrane

"Someone" forgot to add omitempty to CSIDriverInfo types.go. And passed all API reviews :-)
I filled https://github.com/kubernetes/kubernetes/pull/69331. I still see one failed test, but CSIDriver instance is created correctly there. Will continue tomorrow.

@saad-ali you asked in https://docs.google.com/document/d/1-WmRYvqw1FREcD1jmZAOjC0jX6Gop8FMOzsdqXHFoT4/edit# whether this only occurs "in alpha environment".
It can be reproduced with v1.12.1-beta.0 and no special feature gates. But @jsafrane seems to have found the root cause, so this is probably mute.

The root cause is that CSIDriver CRD and corresponding types.go are not in sync. Therefore you need  CSIDriverRegistry alpha feature enabled to hit it.

I filled kubernetes/kubernetes#69331. I still see one failed test, but CSIDriver instance is created correctly there. Will continue tomorrow.

The failed test is not related to CSI driver registrar, opened #69367.

@pohly tests with [Feature] tags are often meant to only be run in alpha clusters where the appropriate feature gates are enabled.

repo: kubernetes-csi/driver-registrar


text:
Automated cherry pick of #178

Cherry pick of #178 on release-1.0.
#178: Add compatibility section to README.md

Codecov Report

Merging #185 into release-1.0 will not change coverage.
The diff coverage is n/a.

@@             Coverage Diff              @@
##           release-1.0     #185   +/-   ##
============================================
  Coverage        94.46%   94.46%
============================================
  Files                9        9
  Lines              668      668
============================================
  Hits               631      631
  Misses              37       37

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 3517bed...c9c1d9e. Read the comment docs.

authors: codecov-io mbohlool

repo: kubernetes-incubator/client-python


text:
Plumbing topology information through Provision call in external PVController library.

This is a dependency for adding topology functionality to CSI.
In the future, we'd like to cache Node objects since almost all plugins will go through CSI. For now I hope to get the provisioner interface change in first to unblock CSI work, and open an issue to track the work once this PR is merged.
/cc @wongma7 @msau42 @lichuqiang

Seems you need go-fmt.
Also, can you add some test cases to validate the change?

Cleaned up errors/logs/events as mentioned above, and added tests

/lgtm

authors: lichuqiang msau42 verult

repo: kubernetes-incubator/external-storage

license_source: bigquery


text:
Audit support improvement

What this PR is about:

Minor variable reuses instead of redefinitions
Do not mount when audit_log_path is set to stdout ("-")
Do not mount when kubeadm is used (as it mounts itself from the host cf. https://github.com/kubernetes/kubernetes/blob/32dc6cc08aa0349d44aa3109f0a718cbb51fb101/cmd/kubeadm/app/phases/controlplane/volumes.go)
Makes policy volume not writeable

Caveat: Setting audit_log_path to "-" when using kubeadm would certainly end up with failures. kubeadm only supports log files. NB: the destination file seems to be hardcoded to "audit.log" (https://github.com/kubernetes/kubernetes/blob/master/cmd/kubeadm/app/phases/controlplane/manifests.go)
Follow-up to PR #3113

@riverzhang @woopstar What do you think?

ci check this

ci passed

/lgtm

@mirwan  Glad you can handle it.

Custom audit policy file #3127
Open an issue in kubeadm about audit log path.

authors: ant31 mirwan riverzhang

repo: kubernetes-incubator/kubespray


text:
Generate swagger spec

We should generate a swagger API for service catalog and have the API server serve it as in k8s.

#349

repo: kubernetes-incubator/service-catalog


text:
Split Reconcile in multiple logical sub-methods

/kind feature
Describe the solution you'd like
The current Reconcile method has a lot of logic in it that could be extrapolated out in different reconciliation steps as sub-methods, which would also have the benefit of allow for more detailed unit testing.

/priority important-longterm
/milestone Next
I agree with the refactoring functions bit. I think we've finally gotten to a point where all the cases are clearly organized and factoring them out should not be very difficult.
I'm still inclined to only unit test the public functions (Reconclie) and set up state so we can control the execution path of reconcile. It requires a bit of DI, but from my experience, this keeps tests from being overly focused and brittle.

I like the idea of testing around Reconcile as much as we can, since we can more accurately test, verify enforcement, and validate the contracts and behaviors we define around providers that way.

We should do both, it's hard to tell at this point if all the code paths are properly tested.

authors: chuckha detiber vincepri


text:
Use cloud-provider-kubevirt in the capk tenant cluster

Cloud-provider was already implemented for kubevirt platform
https://github.com/kubevirt/cloud-provider-kubevirt
Need research:

How to include this controller in the capk installation?
Are there any gaps in this controller need to be added?

/assign @nirarg

/remove-lifecycle stale


text:
🌱  Adding new/updated ClusterVersion and VirtualCluster test suites

Now that we've updated to controller-runtime 0.8.3 and were seeing flakes like #79 it made sense to take a second and step back and write tests for at least the native provisioned that some folks have been using and actually get the Reconcilers for both ClusterVersion and VirtualCluster. in doing so this removes the flakes between test suites and cleans up more code.
Related
Closes #79
Related #27
Related #59
Signed-off-by: Chris Hein me@chrishein.com

Awesome work!
/approve
/lgtm

authors: Fei-Guo christopherhein


text:
Pod security context fix for Openshift

Related to the Downstreamed descheduler and openshift specific requirements. But adding Security contexts here would not hurt, and avoids conflicts for us when downstreaming changes there: https://github.com/openshift/descheduler/pull/80

@madeelibm would you please sign the CNCF CLA?

I don't think it is a great idea to upstream vendor-specific changes just for convenience. If this is something that's only needed for OpenShift's tests, then I think a carry patch in the downstream fork is the right approach

@knelasevero hopefully those changes can be made compatible for both Kubernetes and OpenShift

But I think @damemi is also against that? It makes the pod spec in tests more verbose and it is only a requirement for k8s flavors where security context are required (Namely only Openshift I think).
@damemi That is the rationale, right?

This exercise is only relevant when the same change is compatible with both Kubernetes and OpenShift. If not, we will carry downstream patch.

I admit I'm not an expert in security contexts, so I'm just commenting from an oss point of view. But if this is a valid improvement for users besides OpenShift's CI, then it's fine by me

It is best practice to define security context, and that's why this is enforced in Openshift, but, tbh, I don't think it brings a lot of value to pods in e2e tests (with some exceptions at the end of this comment).
The downsides that I can see here are:

verbosity of declaring the pods in tests
this is yet another thing that can fail in tests, that are not related to what we want to test. (if we change how the image is built and for some reason if invalidates the security context and it fails for that we would have to be aware and also change things in tests)

The pros are:

e2e tests closer to what people should run in real life [?]
easier to downstream when this is a requirement
this is safer for people wanting to re-run e2e tests themselves in their environments, in their CIs, if they re-build things (maybe gets more relevant when we think about people using the framework to build their own deschedulers)

@madeelibm would you please sign the CNCF CLA?

I have started the process, it will take some time.

authors: a7i ingvagabund knelasevero madeelibm

repo: kubernetes-sigs/descheduler


text:
fix the path to the entry point

What type of PR is this?
/kind bug

What this PR does / why we need it:
It was a mistake on me in https://github.com/kubernetes-sigs/kube-scheduler-wasm-extension/pull/103.

no required module provides package kube-scheduler-wasm-extension.go; to add it:
https://prow.k8s.io/view/gs/kubernetes-jenkins/logs/post-kube-scheduler-wasm-extension-push-images/1768944622496649216

Which issue(s) this PR fixes:

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

NONE

What are the benchmark results of this change?

/lgtm

👍
https://prow.k8s.io/view/gs/kubernetes-jenkins/logs/post-kube-scheduler-wasm-extension-push-images/1769247085099487232


text:
Should not delete namespace when unjoin cluster

What would you like to be added:
UnjoinCluster in pkg/kubefedctl should not delete the kubefed namespace.
Why is this needed:
Because maybe there are other resources in this namespace, which can not and should not be deleted.
This will leave a Terminating namespace, and will cause a failure when joining this cluster again.
Because it's not allowed to create any resource (include the RBAC resources) in a Terminating namespace.
We cann't stop user to use the kubefed namespace to store other resources. So it' better to keep the namespace left, like what we do on the Primary cluster.

/kind feature

@davidwtf I don't think it is a good and recommended practice to use the kubefed namespace to federated resources. I'd recommend to use a different namespace that you can after federate to the clusters. If you don't want to get the resource deleted when unjoining you could also make usage of an annotation kubefed.io/orphan: true. This annotation ensures retention of the resource (e.g.. namespace) when unjoining.

@hectorj2f Thanks for your suggestion.
But I think the main point is not which namespace to save the federated resources, but is that we can not stop the user to save something in the kubefed namespace.
The user may save just normal resources. And maybe there are other operators will create their CR in the kubefed namespace.
If we delete the namespace, we will delete the resources that not create by us. And we don't know what will happen, the deleting may be blocked.

To be clear,  the namespace which I mentioned, is the not the user defined federated namespace, but the namespace used by kubefed's control plane .

/remove-lifecycle stale

authors: davidwtf hectorj2f makkes

repo: kubernetes-sigs/kubefed


text:
Fix "should print workloads list with paging" test

What type of PR is this?
/kind flake

What this PR does / why we need it:
Fix "should print workloads list with paging" test.
Which issue(s) this PR fixes:

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

NONE

/test pull-kueue-test-integration-main

/test pull-kueue-test-integration-main

/test pull-kueue-test-integration-main

/test pull-kueue-test-integration-main

/test pull-kueue-test-integration-main

/assign @trasc

@mbobrovskyi Could you clear the reason why this test is flaky?

It's because sometime not enough one second to create resources and execute command. And it's printing Age with 1s instead 0s.

/approve
/lgtm
Thanks!

authors: mbobrovskyi mimowo tenzen-y

repo: kubernetes-sigs/kueue


text:
Informer for non Poseidon pods ( for max-pods and resource calculation)

This PR add a new informer to view other pods not scheduled by Poseidon.
This information is required for resource calculation of node and also for max-pods feature.
This PR also includes the max-pods feature.

/assign @deepak-vij

/lgtm

/ok-to-test

/lgtm

@m1093782566 This PR has realized it.

This PR also includes the max-pods feature.

Oh, I missed that.
Great!

@m1093782566 @islinwb
Please don't close #112
I will cherry-pick the E2E test case from that PR.

/test ci-poseidon-e2e-gce

/retest

Error logs of test:
I1011 10:45:17.862]
I1011 10:45:17.862] • Failure [16.822 seconds]
I1011 10:45:17.862] Poseidon
I1011 10:45:17.863] /go/src/github.com/kubernetes-sigs/poseidon/test/e2e/poseidon_integration.go:38
I1011 10:45:17.863]   Poseidon [Predicates]
I1011 10:45:17.863]   /go/src/github.com/kubernetes-sigs/poseidon/test/e2e/poseidon_integration.go:297
I1011 10:45:17.863]     should validates resource limits of pods that are allowed to run  [It]
I1011 10:45:17.863]     /go/src/github.com/kubernetes-sigs/poseidon/test/e2e/poseidon_integration.go:314
I1011 10:45:17.863]
I1011 10:45:17.863]     Expected error:
I1011 10:45:17.863]         <*errors.errorString | 0xc000335ba0>: {
I1011 10:45:17.863]             s: "pod ran to completion",
I1011 10:45:17.863]         }
I1011 10:45:17.863]         pod ran to completion
I1011 10:45:17.863]     not to have occurred
I1011 10:45:17.863]
I1011 10:45:17.864]     /go/src/github.com/kubernetes-sigs/poseidon/test/e2e/poseidon_integration.go:422
I1011 10:45:17.864] ------------------------------

/retest

authors: deepak-vij islinwb m1093782566 shivramsrivastava

repo: kubernetes-sigs/poseidon


text:
Inconsistent Persona Naming

The persona naming scheme is inconsistent across documentation.
Intro Page:

Platform Provider
Platform Operator
Service Operator

Concepts Page:

Infrastructure Provider
Cluster Operator
Application Developer

@robscott and I prefer the concepts page naming scheme. Thoughts?
/assign @mark-church
/cc @hbagdi

I think we have usually discussed the API with the naming in Concepts doc.
I personally prefer the naming in Concepts doc as well.

I think we have usually discussed the API with the naming in Concepts doc.
I personally prefer the naming in Concepts doc as well.

Yeah makes sense, I like the ones from the concepts doc as well. I can go ahead and change it later this week.

Yeah makes sense, I like the ones from the concepts doc as well. I can go ahead and change it later this week.

Great, thanks!
I'll assign this to you for now.
/assign @mark-church

Great, thanks!
I'll assign this to you for now.
/assign @mark-church

Hey @mark-church, do you still have the bandwidth to take this on?

Yup, fixed it with https://github.com/kubernetes-sigs/gateway-api/pull/551

authors: danehans hbagdi mark-church

repo: kubernetes-sigs/service-apis


text:
[stable/nginx-ingress] how to do 30x redirect instead of 301 redirect?

Hi all,
I have 1 service that has only 1 method POST. I've setup nginx-ingress and kube-lego and it works fine for https.
However, it doesn't work on http because

POST data is discarded on redirect as a client will perform a GET request to the URL specified by the 301. Period.

According to this stackoverflow answer
Is there anyway for me to change that 301 redirect to sth else, say 307.
Thank you all in advance.

This doesn't seem to be a Chart problem, but an nginx or nginx-ingress one. I recommend asking in one of those upstream projects.

authors: mgoodness tuananh

repo: kubernetes/charts


text:
Fix SSL certs for docker registry chart

What this PR does / why we need it:
@jpds Thanks for creating this chart! I ran into issues using the SSL support: generating a k8s TLS secret didn't template properly into the secret volume due to what I think is an extraneous .tls; and also, the current template creates the TLS cert in a secret volume, but does not instruct the registry process to use it, and this resulted in it listening on HTTP when I deployed it. (Not sure if that is something that varies with docker registry version.)
Fixing both of these issues required two commits. With my local checkout with these commits applied I was able to successfully have the daemon listen on SSL with a self signed cert.
Which issue this PR fixes
(no issue created yet)

Failed linting due to lack of version bump, fixed.

/assign @unguiculus

cc @jpds

/ok-to-test

/lgtm

Looks like you will have to rebase and set a new version though.

authors: Eronarn timstoop unguiculus


text:
The compatibility-matrix needs to be updated to include versions 1.29 and 1.30 in README.md

The compatibility-matrix needs to be updated to include versions 1.29 and 1.30 in README.md.
https://github.com/kubernetes/client-go#compatibility-matrix

And there's actually also 1.31 now; https://github.com/kubernetes/client-go/tree/release-1.31

authors: JanneKiiskila joselitofilho

repo: kubernetes/client-go


text:
Better cloud LB names

LBs provisioned by Kubernetes on any cloud provider uses auto-generated names based on the Service's UUID (e.g. a44e18e4c552b11e683bb02fff13e176) which is not very human-friendly. With https://github.com/kubernetes/kubernetes/pull/66589 merged it should be doable to have each provider set LB names based on naming requirements.
SIG CP tracking issue for https://github.com/kubernetes/kubernetes/issues/69293.
This will need a KEP reviewed by SIG network & cloud-provider.

/milestone
/priority backlog

/remove-lifecycle stale

/remove-lifecycle stale

/lifecycle frozen

Hi all, @andrewsykim there is a simple TODO here related with this issue
https://github.com/kubernetes/cloud-provider/blob/1bd40cdc05f920de6af55dad4abd709cf646dea1/fake/fake.go#L174
but for fake package. If I understand well this is for testing purposes only so I was thinking to improve this by using names like docker does for container names. Would this be friendlier? or the name should be generated from parameters only ?

/remove-lifecycle frozen

authors: andrewsykim cheftako rvillablanca

repo: kubernetes/cloud-provider


text:
Connecting cassandra instance running in kuberentes

My Cassandra instance is running on Kubernetes.
From my desktop i use to connect it with the below command "kubectl exec -it cassandra-0 cqlsh --namespace cassandra"
I want to know how to do the same with java.

Please consider asking questions on Stack Overflow or kubernetes-users mailing list.

authors: ahmetb sivakumaris

repo: kubernetes/examples


text:
Redondant deploy configuration with kubernetes repository

It seems the deployement configuration proposed here:
https://github.com/kubernetes/heapster/tree/08c8af3/deploy/kube-config
Are also available here (with more recent updates):
https://github.com/kubernetes/kubernetes/tree/69fd7aa/cluster/addons/cluster-monitoring/influxdb
Maybe a good idea to close the heapster directory ?

@piosz is there any reason for us to keep around two separate copies of the deployment information?  I'd tend to agree with @kartoch here...

I had similar thoughts many times in the past and eventually came to the conclusion that there is a lot of template boilerplate + addon resizer out of the box in Kubernetes deployment version, so it's not possible to just create Heapster deployment without using kube-up.sh scripts. At the same time there was a number of issues filed in Heapster repo about not working deployment files so it seems there is a number of folks using them.
I think at some point it would be great to have them in a single place but I'm afraid we are not ready for this yet.

authors: DirectXMan12 kartoch piosz

repo: kubernetes/heapster


text:
replace --force --dry-run=server will ignore the dry-run flag

What happened:
Executed  kubectl replace -f - --force --dry-run=server and object was indeed replaced
 % kubectl create cm foo --from-literal foo=bar --dry-run=client -o yaml > foo.yaml
 % kubectl apply -f foo.yaml
 % kubectl create cm foo --from-literal baz=foo --dry-run=client -o yaml > foo.yaml
 % kubectl replace -f foo.yaml --force --dry-run=server
 % kubectl get -f foo.yaml -o yaml
apiVersion: v1
data:
  baz: foo
kind: ConfigMap
metadata:
  creationTimestamp: "2022-06-01T02:49:56Z"
  name: foo
  namespace: sandbox
  resourceVersion: "585111136"
  uid: d8899f20-a087-4ace-a95a-7baa5277526e

What you expected to happen:
For the replace operation to have been a dry run.
How to reproduce it (as minimally and precisely as possible):

kubectl create cm foo --from-literal foo=bar --dry-run=client -o yaml > foo.yaml
kubectl apply -f foo.yaml
kubectl create cm foo --from-literal baz=foo --dry-run=client -o yaml > foo.yaml
kubectl replace -f foo.yaml --force --dry-run=server

Anything else we need to know?:
Don't think so!
Environment:

Kubernetes client and server versions (use kubectl version):

 % k version
Client Version: version.Info{Major:"1", Minor:"22", GitVersion:"v1.22.2", GitCommit:"8b5a19147530eaac9476b0ab82980b4088bbc1b2", GitTreeState:"archive", BuildDate:"2021-09-16T04:22:31Z", GoVersion:"go1.17.1", Compiler:"gc", Platform:"darwin/amd64"}
Server Version: version.Info{Major:"1", Minor:"22", GitVersion:"v1.22.9", GitCommit:"6df4433e288edc9c40c2e344eb336f63fad45cd2", GitTreeState:"clean", BuildDate:"2022-04-13T19:52:02Z", GoVersion:"go1.16.15", Compiler:"gc", Platform:"linux/amd64"}

Cloud provider or hardware configuration:
OS (e.g: cat /etc/os-release): darwin/OS X 12.3.1

Thanks for the issue @alam0rt. It looks that when force flag is set, dry-run is not be used as seen in here https://github.com/kubernetes/kubernetes/blob/e389b2723e6af29a9f70509fe8ff6e5121c30681/staging/src/k8s.io/kubectl/pkg/cmd/replace/replace.go#L275.
I think this is misleading and I opened a PR to return error message in such cases.

/triage accepted
/assign

repo: kubernetes/kubectl


text:
Fix documentation typo: 'bash' -> 'brew'

This change is

/lgtm
/approve

authors: ahmetb xLegoz


text:
Adding missing CONTRIBUTING.md

It adds contribution guidelines for node-problem-detector
fixes #190

we should have a standard format and content of contributor guide across projects but it is ok as of now because this commit adding good doc for new contributor and it can be standardize later.

authors: ghanshyammann poothia

repo: kubernetes/node-problem-detector


text:
Dns -  Adding jsonify

Converting dns benchmark result files to metric files.
This will create 3 metrics:

Latency:

max_latency
avg_latency
min_latency

LatencyPerc:

Perc50
Perc90
Perc99

Queries:

queries_completed
queries_lost
queries_send

/assign @wojtek-t

/hold

@krzysied - what's the status of it? Should I review it?

@wojtek-t It's not ready for the review, it turned out there will be some changes. I will let you know when I implement it. Until then, I'm keeping this PR on hold.

/hold cancel

/approve
I will let @bowei LGTM it once he is ready (it looks good to me).

/lgtm

authors: krzysied prameshj wojtek-t

repo: kubernetes/perf-tests


text:
Add Daemonset test logic in TestGetReplicasFromRuntimeObject

And also fix the usage of DefaultUnstructuredConverter.FromUnstructured()
Ref #790
/assign @mm4tt

/lgtm
/approve
Thanks a lot for the fix and tests!

/ok-to-test

authors: mozhuli wojtek-t


text:
BUG: links inside tabs do not have the proper CSS

if you go to this page:
https://kubernetes.io/docs/setup/independent/create-cluster-kubeadm/#pod-network

under the "Kube-router" tab there is the following text "....Kube-router using kubeadm, please see official setup guide."
in that sentence setup guide is a markdown link except it's missing the regular CSS color / mouse over highlight.

reported by @libnux here:
https://github.com/kubernetes/website/issues/11715
/kind bug
/sig docs
@kubernetes/sig-docs-maintainers

/close
as https://github.com/kubernetes/website/pull/11845 fixed this.

repo: kubernetes/website


text:
Translation for content/ja/case-studies/spotify in Japanese

This is a Feature Request
What would you like to be added
Translation for case study for Spotify
https://kubernetes.io/case-studies/spotify/
Why is this needed
No translation exists in Japanese.
And this case study is so useful for Japanese readers (not only for developers)
Comments
Copy a file from en contents to content/ja/case-studies/spotify/index.html and content/ja/case-studies/spotify/spotify_featured_logo.png and translate the former into Japanese.
/language ja
/assign

/milestone 1.16-ja.1


text:
Translate /docs/tasks/access-application-cluster/list-all-running-container-images/ into Japanese

This is a Feature Request

What would you like to be added
Translate /docs/tasks/access-application-cluster/list-all-running-container-images/ into Japanese.
Why is this needed
This page has not been translated.
Comments
/language ja
/assign

/close


text:
Translate concepts/services-networking/ingress-controllers into Japanese

This is a Feature Request
What would you like to be added
Translate concepts/services-networking/ingress-controllers into Japanese.
Why is this needed
This page has not been translated.
Comments
/language ja
/assign

Closing because this page has been translated already.


text:
Update Configuration API reference docs for dockershim removal

Once https://github.com/kubernetes/website/issues/30941 is complete, we need to update the configuration API docs. These docks are autogenerated from code.
The person who does this needs to be technically competent enough to both complete the generation process but also work in the kubernetes/kubernetes repository to remove any issues in code. This is not a beginner issue.
Description
(thanks @shannonxtreme!)
Page: https://kubernetes.io/docs/reference/config-api/kubeadm-config.v1beta2/#kubeadm-init-configuration-types
Source: https://github.com/kubernetes/kubernetes/blob/master/cmd/kubeadm/app/apis/kubeadm/v1beta2/doc.go#L154
The example YAML uses dockershim.
Actions: Replace with a fully-fledged example using a different CRI.

Page: https://kubernetes.io/docs/reference/config-api/kubeadm-config.v1beta3/
Source: https://github.com/kubernetes/kubernetes/blob/master/cmd/kubeadm/app/apis/kubeadm/v1beta3/doc.go#L176
The example YAML uses dockershim.
Actions: Clean up the YAML formatting (it's currently rendering as a bulleted list) and replace the example with one that uses a different CRI.

https://kubernetes.io/docs/reference/config-api/kubelet-config.v1beta1/ has a mention of the docker daemon in serializeImagePulls but IDK if relevant.

/triage accepted
/milestone 1.24
/assign @celestehorgan
Assigning this to myself so that no one inadvertently takes it :)

/assign

I'd be happy for the help on this @chris-short 🙂

/assign

/unassign (whoops)

/unassign

/assign @nate-double-u @reylejano

Looks like this was fixed in https://github.com/kubernetes/kubernetes/pull/107317

Based on the issue report and the upstream fix, we can close the issue now.
New reference will be generated once 1.24 is out.

/close

authors: celestehorgan chris-short nate-double-u tengqm


text:
Restructure and consolidate information in Contribute section

👷♀ Do not merge 👷♀

[x] Address feedback in this conversation
[ ] Fix links

This is a re-opening of PR #19109.
Closes #19108. See also: #18878

This PR replaces the Start Contributing and Intermediate pages into topic/task-based subject areas. It also aims to reduce duplication of content that occurred between these pages. It was closed to a better branching strategy on my part, to fix some merge conflicts, and to
It's a big PR that's already had considerable content review in the original PR, and still has a bit of work to go.

Note: I couldn't find a reasonable home/place for the changes in https://github.com/kubernetes/website/commit/ead3e36150870bb9826ff6dcd17f53d266f7f173 – any suggestions?

/do-not-merge work-in-progress

To mark this as WIP, I will:
/retitle [WIP] Restructure and consolidate information in Contribute section

/remove-work-in-progress

Commit #d0c0a56 addresses feedback from @kbhawkey. There were a few things to look at here:

The wholesale removal of lots of the "work from a local fork" info, which Karen found useful
Some weird formatting issues around the tabs, which swallowed and ate some of the subsections below it in the original preview
General organization, grammar, etc.

Given the change, I think the logical reviewers are @kbhawkey @zacharysarah.

@celestehorgan , I'll try and read the updates to fork+clone+pr.
Also, does the first commit belong on this branch?

@kbhawkey It does. It changes the URL on an old, deleted page, but I did make sure to update the same link in its new location.

@celestehorgan Because this PR is so large, I've almost certainly missed things. Also, too many suggestions lead to pink unicorns. Hopefully what I've added can point you to other things that need fixing. Please let me know if you have any questions!

I've addressed all of @kbhawkey and @zacharysarah's feedback. If it's all right, I'd like to take this PR and mark it as wip again so I can go through and fix links.

@celestehorgan , Just checking if this PR is a WIP or ready for another review?

Still WIP. Link corrections should come in today 😊
On Thu, Mar 19, 2020, 5:01 PM Karen Bradshaw notifications@github.com
wrote:

@celestehorgan https://github.com/celestehorgan , Just checking if this
PR is a WIP or ready for another review?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/kubernetes/website/pull/19576#issuecomment-601263282,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AEJKNHI7RUIFJSEKIYNI3FTRII6XNANCNFSM4LEQD7FA
.

@kbhawkey  this is ready for another look :)

@celestehorgan , I went through the files -- getting closer 🎯 . I still need to preview the pages.
There are a few minor nits and some other small fixes.

Hi @celestehorgan ,
Double check any links containing, review-process.
Add entries to static/_redirects for the deleted contribute/start and contribute/intermediate pages?

/cc @kubernetes/sig-docs-en-owners

/remove-area blog

/remove-language zh
/remove-language ru

/remove-language de
/remove-language id
/remove-language pl

cc: @zacharysarah

@celestehorgan Thanks for reorganizing this content and making it more friendly! ✨
This PR looks good to me, and I'm approving it.
Some feedback for a follow-up PR:

Make "Documenting for a Release" the first left nav option.
Retitle "Suggesting content improvements" to "Improving content" and swap places with "Documenting for a release"

/lgtm
/approve

authors: celestehorgan kbhawkey sftim zacharysarah


text:
clean up too old comments for v1.9 or before in examples

only language/en

/assign @annajung

/assign @annajung

/approve

/approve

authors: oke-py tengqm


text:
[zh]translation optimization

Page： https://kubernetes.io/zh/docs/concepts/cluster-administration/system-metrics/
Some sentences on the above page was confused,i try to optimizate itt.

/cc @chenrui333

Thanks.
/lgtm
/approve

/retest

authors: tanjunchen tengqm wangyysde


text:
[zh-cn]sync extend-resources/mutating-webhook-configuration-v1.md

content/zh-cn/docs/reference/kubernetes-api/extend-resources/mutating-webhook-configuration-v1.md

/approve

/lgtm

authors: my-git9 tengqm windsonsea


text:
Fix broken in v1.29 Release Announcement blog

Go through the release announcement just identified a broken link to the Authors file of the release team members. This PR aims to fix the link.

/cc @katcosgrove @natalisucks
A very tiny issue. But would be beneficial to address, especially considering the release announcement blog will be receiving increased attention.

/lgtm
Thank you for catching this!

/approve

/lgtm
/approve

authors: dipesh-rawat katcosgrove natalisucks reylejano


text:
[zh] Sync using-api/cel.md

Sync with en #42695 and #44972
content/zh-cn/docs/reference/using-api/cel.md

See preview

/lgtm
/approve


text:
Update test blacklists

Updating the toc and title check skip files. Many of the files no longer exist, some were in there erroneously.

This change is

@heidecke Make sure this doesn't conflict w/ @steveperry-53's work in https://github.com/kubernetes/website/pull/6051.

authors: chenopis heidecke


text:
Updating index

Adding information to reflect that CDK tracks upstream and doesn't alter binaries.
Partially Fixes https://github.com/kubernetes/website/issues/7464

This change is

/approve
/lgtm


text:
ValidatingAdmissionPolicy for C-0004

Control C-0004
Related Resources: CronJob, DaemonSet, Deployment, Job, Pod, ReplicaSet, StatefulSet
Control Docs: https://hub.armosec.io/docs/c-0004
Control Rego: https://github.com/kubescape/regolibrary/blob/master/rules/resources-memory-limit-and-request/raw.rego

Hi @slashben! Is there any particular reason to set the type of memoryRequestMin, memoryRequestMax to array in CRD? If not, shall I change them to integer type?

You are right, I tried to understand why this was defined as an array of integers. You can changed this to a scalar

authors: slashben suhasgumma

repo: kubescape/cel-admission-library


text:
添加翻译文章：How to monitor your disks and filesystems, now also with eBPF

请审校者在合并该 PR 前需要检查以下内容：

[ ] Header 设置正确，包括文章的类型、tag、分类、作者、译者、摘要、reviewer 发布时间等信息
[ ] 关联 Issue 编号 https://github.com/kubesphere-sigs/awesome-cloud-native-blogs/issues/${ISSUE_ID}
[ ] 该 PR Assigned 给了提交者
[ ] 指定了 Reviewer
[ ] 为 PR 明确了 label 信息，如 categories、kind、size、tag、status
[ ] 所有代码片段都指定了代码语言
[ ] 文章遵守了路径规范  YEAR/MONTH/TITLE/index.md，例如 2021/08/new-blog/index.md
[ ] 图片保存了在 GitHub上，跟文章在同级目录
[ ] 文章标题简短且语义明确
[ ] 文章语句通顺，没有语病和格式问题
[ ] 文中没有不可达的链接
[ ] 提交者同意授权「KubeSphere 云原生」公众号和 http://kubesphere.com.cn 发布原创或翻译的文章

当所有以上问题都确定之后，可以由管理者合并 PR 并关闭关联 issue。

https://github.com/kubesphere-sigs/awesome-cloud-native-blogs/issues/20


text:
Custom Jenkins configuration will be lost after reloading Jenkins CasC

If users have set customized Jenkins configuration via Jenkins management UI, like GitLab Server configuration, and then Jenkins CasC is reloaded, the user customized Jenkins configuration will be lost at this time.
/kind bug

I don't think it's a bug. Currently, we don't support that kind of operation.

/remove-kind bug

authors: JohnNiang LinuxSuRen

repo: kubesphere-sigs/ks-devops


text:
Fix UI refresh issues for providers secret data and for migration plan VMs list

Fixes: #369
Fix two UI refresh issues that are a result of a wrong react query fetching/caching options.

For the providers secret data sync issue, apply the 'invalidateQueries' option for the 'secret' query.

For the migration plan VMs list sync issue, avoid the 'keepPreviousData' option and apply the 'invalidateQueries' option for the 'inventory-tree' query.

Fix result:

When editing an existing provider's secret data, the data is updated successfully and immediately in the UI, without the need to hard refresh.

When adding a new VM(s) to the source provider, while the migration plan UI wizard is already opened , the new VM is added successfully in the UI, without the need to re-open the migration plan wizard.

@sgratch 2.4.2 is not yet open, I reopen the issue to make sure we will not forget to backport once it's open

@ahadas hi, can you open 2.4.2 for the plugin ?
@sgratch hi, once 2.4.2 is open, can you make a backport PR ?

Yes, done

authors: ahadas sgratch yaacov


text:
Fix export of Host in vsphere type

Issue:
Ass reported by @jschuler in the file src/types/provider/vsphere/index.ts host is not a module.
Fix:
Make the export specific to file

cc:// @sgratch @jschuler


text:
The kubevirt:view ClusterRole does not provide permissions for users to access VirtualMachineCluster{Instancetype,Preference} cluster scoped resources when bound using RoleBinding

/area instancetype
/assign
What happened:
$subject, the kubevirt:view ClusterRole doesn't provide access to cluster scoped resources when bound through a RoleBinding:
$ oc whoami
kube:admin

$ oc get user/test -o json
{
    "apiVersion": "user.openshift.io/v1",
    "groups": null,
    "identities": [
        "test:test"
    ],
    "kind": "User",
    "metadata": {
        "creationTimestamp": "2023-09-13T06:32:27Z",
        "name": "test",
        "resourceVersion": "2296746",
        "uid": "82589434-61c0-43f9-b583-4cdf1c07a449"
    }
}
$ oc get rolebinding/view -o json
{
    "apiVersion": "rbac.authorization.k8s.io/v1",
    "kind": "RoleBinding",
    "metadata": {
        "creationTimestamp": "2023-09-12T00:26:26Z",
        "name": "view",
        "namespace": "default",
        "resourceVersion": "299686",
        "uid": "41047a8a-9d95-42bc-9f59-667ae114ea5c"
    },
    "roleRef": {
        "apiGroup": "rbac.authorization.k8s.io",
        "kind": "ClusterRole",
        "name": "view"
    },
    "subjects": [
        {
            "apiGroup": "rbac.authorization.k8s.io",
            "kind": "User",
            "name": "test"
        }
    ]
}

$ oc get clusterrole/view -o json | jq -r '.rules[] | select(.apiGroups==["instancetype.kubevirt.io"])'
{
  "apiGroups": [
    "instancetype.kubevirt.io"
  ],
  "resources": [
    "virtualmachineinstancetypes",
    "virtualmachineclusterinstancetypes",
    "virtualmachinepreferences",
    "virtualmachineclusterpreferences"
  ],
  "verbs": [
    "get",
    "list",
    "watch"
  ]
}

$ oc whoami
test

$ oc get virtualmachineclusterinstancetypes
Error from server (Forbidden): virtualmachineclusterinstancetypes.instancetype.kubevirt.io is forbidden: User "test" cannot list resource "virtualmachineclusterinstancetypes" in API group "instancetype.kubevirt.io" at the cluster scope

What you expected to happen:
A separate ClusterRole should be provided by KubeVirt that can be bound with a ClusterRoleBinding allowing access to these cluster scoped resources.
How to reproduce it (as minimally and precisely as possible):
As above.
Additional context:
Add any other context about the problem here.
Environment:

KubeVirt version (use virtctl version): N/A
Kubernetes version (use kubectl version): N/A
VM or VMI specifications: N/A
Cloud provider or hardware configuration: N/A
OS (e.g. from /etc/os-release): N/A
Kernel (e.g. uname -a): N/A
Install tools: N/A
Others: N/A

Reproduced the issue and verified the instancetype.kubevirt.io:view ClusterRole from the PR against a vanilla kubevirtci env without the User kind from OCP:
$ openssl genrsa -out lyarwood.pem
$ openssl req -new -key lyarwood.pem -out lyarwood.csr -subj "/CN=lyarwood"

$ ./cluster-up/kubectl.sh apply -f - <<EOF
---
apiVersion: certificates.k8s.io/v1
kind: CertificateSigningRequest
metadata:
  name: user-request-lyarwood
spec:
  groups:
  - system:authenticated
  request:  $(cat lyarwood.csr | base64 | tr -d '\n')
  signerName: kubernetes.io/kube-apiserver-client
  expirationSeconds: 315569260
  usages:
  - digital signature
  - key encipherment
  - client auth
EOF
certificatesigningrequest.certificates.k8s.io/user-request-lyarwood created

$ ./cluster-up/kubectl.sh certificate approve user-request-lyarwood
$ ./cluster-up/kubectl.sh get csr user-request-lyarwood -o jsonpath='{.status.certificate}' | base64 -d > lyarwood-user.crt

$ cp $(./cluster-up/kubeconfig.sh) ./.lyarwood-config
$ ./cluster-up/kubectl.sh config --kubeconfig ./.lyarwood-config set-credentials lyarwood --client-certificate=lyarwood-user.crt --client-key=lyarwood.pem --embed-certs=true
$ ./cluster-up/kubectl.sh config --kubeconfig ./.lyarwood-config set-context lyarwood@kubernetes --cluster=kubernetes --user=lyarwood

$ ./cluster-up/kubectl.sh --kubeconfig ./.lyarwood-config apply -f - <<EOF
> apiVersion: v1
kind: Namespace
metadata:
  name: lyarwood
spec: {}
status: {}
---
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: lyarwood
  namespace: lyarwood
subjects:
- kind: User
  name: lyarwood
  apiGroup: rbac.authorization.k8s.io
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: view
EOF

$ ./cluster-up/kubectl.sh --kubeconfig ./.lyarwood-config config use-context lyarwood@kubernetes
$ ./cluster-up/kubectl.sh --kubeconfig ./.lyarwood-config get virtualmachineclusterinstancetypes
selecting podman as container runtime
Error from server (Forbidden): virtualmachineclusterinstancetypes.instancetype.kubevirt.io is forbidden: User "lyarwood" cannot list resource "virtualmachineclusterinstancetypes" in API group "instancetype.kubevirt.io" at the cluster scope

$ ./cluster-up/kubectl.sh --kubeconfig ./.lyarwood-config config use-context kubernetes-admin@kubernetes
selecting podman as container runtime
Switched to context "kubernetes-admin@kubernetes".
./cluster-up/kubectl.sh --kubeconfig ./.lyarwood-config apply -f - << EOF
> kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: lyarwood-instancetype-view
subjects:
- kind: User
  name: lyarwood
  apiGroup: rbac.authorization.k8s.io
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: instancetype.kubevirt.io:view
EOF
selecting podman as container runtime
clusterrolebinding.rbac.authorization.k8s.io/lyarwood-instancetype-view created

$ ./cluster-up/kubectl.sh --kubeconfig ./.lyarwood-config config use-context lyarwood@kubernetes
$ ./cluster-up/kubectl.sh --kubeconfig ./.lyarwood-config get virtualmachineclusterinstancetypes
selecting podman as container runtime
No resources found

repo: kubevirt/kubevirt


text:
Do VNFs supports Kubevirt ? Are VNFs complient to Kubevirt? How quickly are VNFs adapting to be deployed on Kubvirt VMs?

this is just an information request

I'm unclear about your question, can you share specific outcome explanation and details of what components you want to support specifically?
/triage needs-information

authors: Ajayimpec usrbinkat


text:
[linstor] Dashboard and alerts about created backups

Is your feature request related to a problem? Please describe:
Our engineers want to see list of created backups in Grafana and receive alerts in case of failures.
Describe the solution you'd like:
Create additional Grafana dashboard and configure alerts

Sorry wrong repo 😅


text:
[release-1.3] instancetype: Introduce PreferredEfi to API

/cc @0xFelix
/cc @acardace
What this PR does
This is a manual backport of #12739 and ca865468b7e9d5917e463d5147dae20637314ea1 from #12740 to avoid conflicts from this and any future instancetype backports.
Fixes #12743
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
https://github.com/kubevirt/kubevirt/blob/main/docs/release-branch-backporting.md#bug-fix-definition
IMHO this is a additive and thus backwardly compatible API change that is fixing a serious shortcoming in the preferences API.

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

A new `PreferredEfi` field has been added to preferences to express the preferred `EFI` configuration for a given `VirtualMachine`.

The code looks good to me. However, this changes the API of a release version. Are the others fine with this change?

Forgot to include the following justification from the original PR:
https://github.com/kubevirt/kubevirt/blob/main/docs/release-branch-backporting.md#bug-fix-definition
IMHO this is a additive and thus backwardly compatible API change that is fixing a serious shortcoming in the preferences API.

/retest-required

/test pull-kubevirt-unit-test-1.3

/test pull-kubevirt-unit-test-1.3

/approve
/hold
/cc @xpivarc
I think this improves the maintainability of the release branch, thank you @lyarwood .
I'd just like to have a second approver looking at this since it is unusual that we backport api additions.

/hold cancel
This is will help to improve the instance types flow

/hold cancel

/test pull-kubevirt-unit-test-1.3

/cherry-pick release-1.2

authors: acardace lyarwood xpivarc


text:
Extend and refactor template test

What this PR does / why we need it:
This PR adds the following functionality:

[x] Refactor and extend tests.RunCommand() function to be more verbose, to allow separate handling of stdout and stderr, and to confine the executed external command to clearly defined namespace.
[x] Implement new function test.RunCommandPipe() function that allows executing a set of commands chained by stdout pipe. It follows the logic of the new tests.RunCommand().
[x] Extend and refactor tests/template_test.go, simplify code structure and add more test case to comply actual test plan, optimize test time, add the proper annotation to all Gomega matcher calls to simplify debugging.

We need to this PR to optimize test execution and to extend test coverage. This PR also sets the ground for future test automation. The Template test was also modified to be backward compatible with the older KubeVirt releases; thus it is recommendable to include this test into cherry-picked backports.
Special notes for your reviewer:
I provide a detailed description of the partial contributions in the corresponding commit messages. All commits were rebased on top of master branch.
Release note:
NONE

@cynepco3hahue I got your point, and I will most likely refactor the RunCommandPipeWithNS() function within the scope a consequent PR. Thank you for your suggestion.


text:
Allow increasing log verbosity for KubeVirt components

What this PR does / why we need it:
This PR aims to make the debugging process of KubeVirt's components easier.
Administrators will be able to modify the KubeVirt CR and set the logging verbosity of all KubeVirt components cluster-wide.
It's also possible to override the verbosity of all components running on specific nodes, by providing a list of nodes and the corresponding verbosity in nodeVerbosity
For example:
  configuration:
    developerConfiguration:
      logVerbosity:
        nodeVerbosity:
          node01: 5
          node02: 5
        virtAPI: 3
        virtController: 3
        virtHandler: 3
        virtLauncher: 2

Virt-Launcher

With this PR, only the newly created VMIs will be affected by the altered verbosity level.
Setting the verbosity level above 5 will also enable the verbose libvirt logging.
To override the cluster-wide verbosity level a logVerbosity: "5" label can be set on the VMI

Release note:
allow increasing logging verbosity of infra components in KubeVirt CR

/cc @rmohr @davidvossel

/assign jean-edouard

How about something like this:
type LogVerbosity struct {
    Global uint
    VirtAPI uint
    VirtHandler uint
    VirtLauncher uint
}

Yea, thanks. Switching to verbosity levels looks better.

```go
type DebugVirtStack struct {
    NodeList []string
}

It may also be that we need verbosity for virt-handler and virt-launcher per node configurable and not just libvirt/qemu logs.

I'm not sure what's the purpose of this.
Originally,
DebugNodeList []string `json:"debugNodeList,omitempty"`
}	}

Was intended to enable debug (high verbosity level) for virt-handlers on a specific nodes.
Did you have something else in mind with the NodeList ?

I think it is fine to use Debug for debugging libvirt/qemu, but for the rest we should stick with verbosity levels

maybe enabling a certain verbosity level triggers libvirt/qemu debug logs? or is that not intuitive enough?

Was intended to enable debug (high verbosity level) for virt-handlers on a specific nodes. Did you have something else in mind with the NodeList ?

I was under the impression the per node verbosity would target all our "infra" components (handler, launcher, libvirt, qemu, etc..) per a node.
I like the idea of setting verbosity level for a component cluster wide, and then having the ability to target specific nodes for increased verbosity.
something like this?
  configuration:
    developerConfiguration:
      logVerbosity:
        virtOperator: 2
        virtApi: 2
        virtController: 2
        virtHandler: 2
        virtLauncher: 2
        nodeList:
        - name: "node02"
          verbosity: 5
        - name: "node01"
          verbosity: 5

maybe enabling a certain verbosity level triggers libvirt/qemu debug logs? or is that not intuitive enough?

That was my main concern, since we log always what libvirt/qemu gives us. And  for these we basically just have "default" verbosity and "debug".

/test pull-kubevirt-unit-test

/test pull-kubevirt-unit-test

/test pull-kubevirt-unit-test

/test pull-kubevirt-unit-test

/retest

/retest

@davidvossel @rmohr could you please take a look, does it make sense this way?

@davidvossel @rmohr could you please take a look, does it make sense this way?

/retest

/retest

@jean-edouard any thoughts on this PR? Speak can you review?

@jean-edouard any thoughts on this PR? Speak can you review?

authors: davidvossel fabiand jean-edouard rmohr vladikr


text:
[Bugfix]: HyperV Reenlightenment VMIs should be able to start when TSC Frequency is not exposed

What this PR does / why we need it:
This is a follow-up to this PR: https://github.com/kubevirt/kubevirt/pull/7986. In this PR, I've explicitly provided QEMU with the lowest TSC frequency on the cluster since that's the only way such VMIs can be migratable.
However, sometimes (e.g. on PSI nodes) TSC frequency is not exposed. In such cases, VMIs with Reenlightenment shouldn't be migratable - but they should be able to run.
In the above PR, an error occurs when trying to create a Reenlightenment VMIs when TSC frequency is not exposed on the cluster nodes. In this PR it would be started successfully, but wouldn't be able to migrate.
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: https://bugzilla.redhat.com/show_bug.cgi?id=2119069
Special notes for your reviewer:
Release note:

[Bugfix]: HyperV Reenlightenment VMIs should be able to start when TSC Frequency is not exposed

/test pull-kubevirt-build
/test pull-kubevirt-e2e-windows2016
/test pull-kubevirt-e2e-k8s-1.24-sig-compute
/test pull-kubevirt-e2e-k8s-1.23-sig-compute
/test pull-kubevirt-e2e-k8s-1.22-sig-compute

/test pull-kubevirt-e2e-k8s-1.24-sig-compute
/test pull-kubevirt-e2e-k8s-1.23-sig-compute
/test pull-kubevirt-e2e-k8s-1.22-sig-compute

/test pull-kubevirt-e2e-k8s-1.24-sig-compute
/test pull-kubevirt-e2e-k8s-1.23-sig-compute
/test pull-kubevirt-e2e-k8s-1.22-sig-compute

/test pull-kubevirt-e2e-windows2016

/test pull-kubevirt-e2e-windows2016

/test pull-kubevirt-e2e-windows2016

/test pull-kubevirt-e2e-windows2016

/test pull-kubevirt-e2e-windows2016

/hold cancel

FYI @vladikr @acardace

@iholder-redhat I think you should also make sure that the unit tests for (virt-launcher) converter.go cover this additional corner case when generating the domain XML.

Hey @acardace! Thanks a lot for your review, I fully agree with your important comments.
I've tried to make this as easy as possible to re-review, let me briefly summarize the changes:

Commit https://github.com/kubevirt/kubevirt/pull/8359/commits/954739453aed1a960e167ca98bde88b0d68723a4 changes logic in converter.go to set TSC frequency if not already set and considered "required" (more on that in a second)
Commit https://github.com/kubevirt/kubevirt/pull/8359/commits/2185ad2e0b5e0a7c99f1ffd476b5c8ac17e73750 refactors topology hinter & tsc files according to your suggestions. Briefly:

As you suggested, TopologyHintsForVMI() now returns an enum type that reflect the requirement of the TSC frequency. The enum currently supports 3 values: RequiredForBoot, RequiredForMigration and NotRequired.
A new SetNonMigratableCondition() method has been added to topologyHinter. The reason of introducing this method is because I wanted to decouple assignment of the reason for not being migratable from virt-controller. IOW, I don't think that virt-controller should why the VMI is not migratable, all it needs to know is that the requirement is RequiredForMigration and an error occured, therefore it asks the topology hinter to set and VMI as non migratable with a proper reason. Currently Reenligtenment is the only reason for this case, but this may change in the future.

Commit https://github.com/kubevirt/kubevirt/pull/8359/commits/bd9da1b1e9f92e90ba7918c8fdd0a234a36087ef adds, as you suggested, a unit test for converter.go. This was a great catch as there was a small flaw in converter's logic after my changes. Thanks!
Other than that, the other commits remained 99% untouched.

Thanks again for your review!

@iholder-redhat can you squash commit f74745229765e83a27bf851d6684ef05760cc97a and 2185ad2e0b5e0a7c99f1ffd476b5c8ac17e73750? It's a bit confusing to see a piece of code getting added and then removed inside the same PR.

@iholder-redhat can you squash commit f747452 and 2185ad2? It's a bit confusing to see a piece of code getting added and then removed inside the same PR.

@acardace done :)
Thanks again for your review

/retest-required

/lgtm
all looks good now, thank you :)

/retest-required

Hey @xpivarc! Thanks for your review.
I've addressed your comments :)

/hold cancel

/cherry-pick release-0.53
/cherry-pick release-0.56

/cherry-pick release-0.56

/cherry-pick release-0.55

/cherry-pick release-0.57

authors: Barakmor1 acardace iholder-redhat


text:
[Feature]: Add ES2022 support

🚀 Feature Proposal
Add es2022 as valid target/module.
Motivation
ES2022 has been released a month ago: https://github.com/tc39/ecma262/releases/tag/es2022
Example
No response

We support all targets, what do you mean “support”? Which issue do you run into?

This warning is TypeScript specific warning, which requires your TypeScript version to be updated. We use TypeScript API to compile codes.
This is not in the scope of ts-jest, please report to TypeScript team about this.

authors: Julien-Marcou ahnpnl

repo: kulshekhar/ts-jest

license: MIT


text:
Monster_Maker Game added

PR Description 📜
#787

Mark the task you have completed ✅

[x] I follow CONTRIBUTING GUIDELINE & CODE OF CONDUCT of this project.
[x] I have performed a self-review of my own code or work.
[x] I have commented my code, particularly in hard-to-understand areas.
[x] My changes generates no new warnings.
[x] I have followed proper naming convention showed in CONTRIBUTING GUIDELINE
[x] I have added screenshot for website preview in assets/images
[x] I have added entries for my game in main README.md
[x] I have added README.md in my folder
[x] I have added working video of the game in README.md (optional)
[x] I have specified the respective issue number for which I have requested the new game.

Add your screenshots(Optional) 📸

Thank you soo much for contributing to our repository 💗

Thank you @Kalivarapubindusree ,for creating the PR and contributing to our GameZone 💗
Review team will review the PR and will reach out to you soon! 😇
Make sure that you have marked all the tasks that you are done with ✅.
Thank you for your patience! 😀

I Have already added images in assets/Images folder please check at once!

I Have already added All images in assets/Images folder please check at once! @kunjgit

Hello @Kalivarapubindusree,
You have to add your image here : https://github.com/kunjgit/GameZone/tree/main/assets/images which will be used as thumbnail for your game on our website.

Okay sir I will change it soon thank you for responding and letting me know the mistake @daccdacc

authors: Kalivarapubindusree daccdacc kunjgit

repo: kunjgit/GameZone


text:
Add Triangle Back to Home Game

PR Description 📜
Please review my PR!
Fixes #2088

Mark the task you have completed ✅

[x] I follow CONTRIBUTING GUIDELINE & CODE OF CONDUCT of this project.
[x] I have performed a self-review of my own code or work.
[x] I have commented my code, particularly in hard-to-understand areas.
[x] My changes generates no new warnings.
[x] I have followed proper naming convention showed in CONTRIBUTING GUIDELINE
[x] I have added screenshot for website preview in assets/images
[x] I have added entries for my game in main README.md
[x] I have added README.md in my folder
[x] I have specified the respective issue number for which I have requested the new game.

Add your screenshots(Optional) 📸

Thank you soo much for contributing to our repository 💗

Thank you @kartikjoshi267 ,for creating the PR and contributing to our GameZone 💗
Review team will review the PR and will reach out to you soon! 😇
Make sure that you have marked all the tasks that you are done with ✅.
Thank you for your patience! 😀

Resolve conflicts @kartikjoshi267

Resolved!!

Thank you  @kartikjoshi267 , for your valuable time and contribution in our GameZone 💗.
It’s our GameZone, so Let’s build this GameZone altogether !!🤝
Hoping to see you soon with another PR again 😇
Wishing you all the best for your journey into Open Source🚀

@daccdacc please add gssoc23 label

@gurjeetsinghvirdee please add the labels for gssoc23!

Please add appropriate labels for gssoc23! @gurjeetsinghvirdee @kunjgit @daccdacc

Please add appropriate labels for gssoc23! @gurjeetsinghvirdee @kunjgit @daccdacc

Not a mentor anymore & don't have access to the repo

@daccdacc @kunjgit Please add gssoc23 labels! I guess you forgot to add them!


text:
Update README.md requires jitpack.io

The transitive dependency retro-optional can only be found in the jitpack.io repository. That means jitpack.io is also requirment for RxFirebase.  It would help to add that info to your README.md, similar to the "Get It" section on retro-optional
Example:
 repositories {
        // ...
        maven { url "https://jitpack.io" }
  }

@NateWickstrom Thanks for the issue.
I've added transitive=false on dependency setup guide to prevent transitive dependency, which does not require to have jitpack repository.

authors: NateWickstrom kunny

repo: kunny/RxFirebase


text:
Investigate async db problems in tests

https://travis-ci.org/kurtlewis/ceas-ambassadors-website/builds/413852302
I need to see if I can figure out what is causing these - they happen occasionally locally but It's hard to track so here's a link to it on the buid server

ooooof I accidentally overwrote the bad build with a good one

Here's a build where it happened that I won't overwrite https://travis-ci.org/kurtlewis/ceas-ambassadors-website

I've seen this a few more times, my though here is to make the delete everything in the database function work in order - that is, go down the list and delete everything one model by model, hopefully avoiding a db lock like what I've seen
 ✓ Edit attendance status confirmed -> unconfirmed (95ms)
Unhandled rejection SequelizeDatabaseError: Deadlock found when trying to get lock; try restarting transaction
    at Query.formatError (/home/travis/build/kurtlewis/ceas-ambassadors-website/node_modules/sequelize/lib/dialects/mysql/query.js:247:16)
    at Query.handler [as onResult] (/home/travis/build/kurtlewis/ceas-ambassadors-website/node_modules/sequelize/lib/dialects/mysql/query.js:68:23)
    at Query.Command.execute (/home/travis/build/kurtlewis/ceas-ambassadors-website/node_modules/mysql2/lib/commands/command.js:30:12)
    at Connection.handlePacket (/home/travis/build/kurtlewis/ceas-ambassadors-website/node_modules/mysql2/lib/connection.js:502:28)
    at PacketParser.onPacket (/home/travis/build/kurtlewis/ceas-ambassadors-website/node_modules/mysql2/lib/connection.js:81:16)
    at PacketParser.executeStart (/home/travis/build/kurtlewis/ceas-ambassadors-website/node_modules/mysql2/lib/packet_parser.js:77:14)
    at Socket.<anonymous> (/home/travis/build/kurtlewis/ceas-ambassadors-website/node_modules/mysql2/lib/connection.js:89:29)
    at emitOne (events.js:116:13)
    at Socket.emit (events.js:211:7)
    at addChunk (_stream_readable.js:263:12)
    at readableAddChunk (_stream_readable.js:250:11)
    at Socket.Readable.push (_stream_readable.js:208:10)
    at TCP.onread (net.js:597:20)
      1) "before each" hook for "Delete attendance with status unconfirmed"

repo: kurtlewis/ceas-ambassadors-website


text:
FR: Be able to use any github repo without kurtosis locators

Background & motivation
It would be great if I could reference any github repo without needing to have a kurtosis.yml locator.
Desired behaviour
Be able to use any github repo without kurtosis locator.
How important is this to you?
Painful; the lack of this feature makes using Kurtosis frictionful.
What area of the product does this pertain to?
CLI: the Command Line Interface

Thanks for filing this @barnabasbusa ! I'd love to get more info on the usecase you're thinking about for this

it would be in combination of this issue: https://github.com/kurtosis-tech/kurtosis/issues/2215
Where I could reference any arbitrary dockerfile in any
random github repo, or possibly any url.

This makes sense to me. So just repeating my understanding of this ticket + #2215 , would the following solve your problem:

Kurtosis allows you to use Github locators even if there's not a Kurtosis kurtosis.yml at it (e.g. github.com/ethereum/go-ethereum)
Kurtosis allows you to use arbitrary paths on your filesystem (e.g. /home/barnabas/code/my-custom-microservice)

authors: barnabasbusa mieubrisse

repo: kurtosis-tech/kurtosis


text:
Build the REST API

Django provides a solid framework for building an API that could be used for whatever else, like a mobile app.

The REST API is built. Need to flesh out functionality. Creating another issue for it.


text:
Confusing error message with reserved argument name in prepared statement

conn.execute(
    "MATCH (vf:V {id: $from})-[e:LINKS_TO]->(vt:V {id: $to}) RETURN vf,e,vt;",
    {"from": "id1", "to": "id2"},
)

currently errors with error

RuntimeError: Parser exception: Invalid input <MATCH (vf:V {id: $from>: expected rule oC_SingleQuery (line: 1, offset: 18)
"MATCH (vf:V {id: $from})-[e:LINKS_TO]->(vt:V {id: $to}) RETURN vf,e,vt;"
^^^^

This is confusing from user perspective - statement is syntactically correct, but  from and to both seem to be reserved keywords.
Renaming from -> from_id , to -> to_id will work, but I would suggest to either provide better error description or preferrably have no restrictions on argument names.
Related: https://github.com/kuzudb/kuzu/issues/2676

Hi @sapalli2989,
It took a while but we finally get to this. We have updated our reversed keyword list in #3626 according to the PG standard. The list will be update to the documentation as well. You can find a temporary version here.
For this specific case, FROM and TO are still reserved.
In terms of better error message, we will continue investigate how to do it with antlr4.

Hey @andyfengHKU No problem, thanks for having kept an eye on this !

repo: kuzudb/kuzu


text:
Feature: Case-insensitive for column names with LOAD FROM

API
Other
Description
Table and column names are case insensitive when it comes to Kuzu tables, however, we force case sensitive when it comes to LOAD FROM statements. I propose to change column names in LOAD FROM into case insensitive too.

Yup, we would want to be similar in behaviour to DuckDB and Postgres, which are also case insensitive on table names.

This actually also causes another problem in RDBMS extension. When we attach a postgres database, given a table with schema like this:
Comment(ID BIGINT, creationDate TIMESTAMP, locationIP varchar, browserUsed varchar, content varchar, length INT, PRIMARY KEY(ID))

We force users to LOAD FROM with all lower-case column names like this
load from Comment return min(id), min(creationdate), min(locationip), min(browserused), min(content), min(length);

Otherwise will throw binder exceptions "Variable x is not in scope."
This is very confusing, as we changed the column names in users' perspective. I think this should be fixed in a high priority.


text:
Add hack to fix output type for coalesce

Add flag to skip table required check for joins when using COALESCE.
Obviously this is pretty gross hack. We really need to refactor how the type checking in sqlc works.
Fixes #1096

Thanks, Kyle!

authors: kevinburkemeter kyleconroy

repo: kyleconroy/sqlc


text:
PathKit method calls

This is more of a question than an issue. In your README documentation, whenever a PathKit method is called such as path.exists() it uses the () at the end as seems normal. But when I do it in the Xcode IDE, it doesn't like the () at the end. I have a check in my code:
if path.exists {
....
}
And that runs fine but with the parens:
if path.exists() {
...
}
it gives me a build error. Any idea why this is the case? It's not a big deal as I've figured how to make it work. Just curious as to whether I'm doing something wrong implementing PathKit.

It appears to be a case of the readme being out of date compared to the implementation. At somepoint we made those computed properties instead of functions.
Although, in retrospect I am not sure it was a good idea, but here we are today. They are computed.

authors: kylef liquidoshin

repo: kylef/PathKit


text:
Using aux['outs']['z_indices'] for QuantizedAE

Hi,
Thank you for the nice work. I was trying to understand your codes, and I found something puzzling according to my understanding of discrete representations.
This line sets aux['z_hat] as the discrete indices from the codebook where the latent variables are indeed discrete, which is a correct implementation for VQVAE. However, you do not do the same assignment for QLAE even though you set is_continuous as False in this line. So, you are using the quantized, and continuous representation to calculate the disentanglement even if you treat QLAE as a discrete model. I was thinking you should do the same assignment like:
if isinstance(model, disentangle.models.QuantizedAE):
    aux['z_hat'] = aux['outs']['z_indices']
in this method.
If I'm missing something or misunderstanding things, I would be really happy if you can clarify it. Thank you for your time.

If I recall correctly, there is no difference for QLAE, as the preprocessing for calculating the disentanglement metrics will discretize the inputs. The reason we do this for VQVAE is to convert from continuous code vectors to scalar integers, but QLAE's continuous representation is already scalar (per codebook).

I see your point. According to my experiments, two different implementations lead to nearly the same disentanglement results, but I still wanted to ask as I thought using the indices of the quantizing scalars might be conceptually more appropriate. Thank you for your reply.

authors: gulcinbaykal kylehkhsu


text:
Enhance unit-test for downloading remote HELM charts

Description
The unit test for workspace / chart render has to be enhanced to verify it deals properly with download of

External HELM charts (TGZ) from a cloud storage (HTTP download, no GIT involved)
External HELM charts (TGZ) from Github

AC:

Unit tests for workspace factor and Helm chart render are also tested by using external HELM charts
It has to be tested with Helm charts which are retrieved from Cloud storages (via HTTPS) and also from Github

Reasons
We got a bug caused by a later change which was no identified by our current unit tests. Test coverage has to be increased to verify the file-download behaviour as well.
Attachments

done as part of #404

repo: kyma-incubator/reconciler


text:
Hardcode ServiceManager auth URL suffix for sc-migration

Older versions of Service Manager client library from BTP operator had this hardcoded internally, newly BTP operator moved the default value to the chart.
https://github.com/SAP/sap-btp-service-operator/pull/48/

/retest

/retest

/retest

/retest

/retest

/retest

/retest

/retest

/retest

/retest

/retest

/retest

/retest

/retest

/retest

/retest

/retest

/retest

/retest

/retest

/retest

/retest

/retest

/retest

/retest

/retest

/retest

/retest

/retest

/retest

/retest

/retest

/retest

/retest

/retest

/retest

/retest

/retest

/retest

/retest

/retest

/retest

/retest

/retest

/retest

/retest

/retest

/retest

/retest

/retest

/retest

/retest

/retest

/retest

/retest

/retest

/retest

/retest

/retest

/retest

/retest

/retest

/retest

/retest

/retest

/retest

/retest

/retest

/retest

/retest

/retest

/retest

/retest

/retest

/retest

/retest

/retest

/retest

/retest

/retest

/retest

/retest

/retest

/retest

/retest

/retest

/retest

/retest

/retest

/retest

/retest

/retest

/retest

/retest

/retest

/retest


text:
Introduce keyboard navigation via ctr+k (⌘ k)

As Sebastian and Mathew I would like to be able to use the keyboard to navigate busola menu similar to Github using ⌘ k

Acceptance Criteria

[ ] Follow Project DOD
[x] Introduce a ⌘ ? that will show the user the available commands
[ ] the commands will follow the kubectl short commands (shortNames)
[ ] This task covers basic command lines from the SHORTNAMES list and only navigates to list view
[ ] testing is performed to smoke test the feature
[x] Absolutely great to have https://www.npmjs.com/package/didyoumean

Tasks

[ ] Add Tasks

We could use https://docs.luigi-project.io/docs/global-search/, but sadly it doesn't support "did you mean" mechanism.

repo: kyma-project/busola


text:
Remove module-template-push target

Description
Changes proposed in this pull request:

cleanup unused make target

Related issue(s)
Fixes https://github.com/kyma-project/keda-manager/issues/54

/test all

repo: kyma-project/keda-manager