text:
fixes critical vulnerabiolities on ray

chore: 	fix the following CVEs
- CVE-2023-6019: Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection')
- CVE-2023-6020: Use of GET Request Method With Sensitive Query Strings
There are no fix for CVE-2023-48023 yet

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 #
Type of changes
Please delete options that are not relevant.

[ ] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] This change requires a documentation update

Feature/Issue validation/testing:
Please describe the tests that you ran to verify your changes and relevant result summary. Provide instructions so it can be reproduced.
Please also list any relevant details for your test configuration.

[ ] Test A

[ ] Test B

Logs

Special notes for your reviewer:

Please confirm that if this PR changes any image versions, then that's the sole change this PR makes.

Checklist:

[ ] Have you added unit/e2e tests that prove your fix is effective or that this feature works?
[ ] Has code been commented, particularly in hard-to-understand areas?
[ ] Have you made corresponding changes to the documentation?

Release note:

The failing test reports only:
ValueError: `detached=False` is no longer supported. In a future release, it will be removed altogether.

on .py files like

The failing image build has succeed locally.
on GHA it is failing due:   FileNotFoundError: [Errno 2] No such file or directory: '/prod_venv/lib/python3.9/site-packages/idna-3.6.dist-info'
not sure what might be missing.

@spolti Can you help rebase?

@spolti Can you help rebase?

Hi @yuzisun, updated, sry for the delay.

@spolti nitpick: can you fix the typo in the PR title?

/lgtm

/approve

authors: spolti terrytangyuan yuzisun


text:
Add faculty website URL

Add faculty website URL in https://hercules-10496.herokuapp.com/api/v1/faculty/info/all. wimp needs it too :D

Most definitely! ❤
Do we scrape the websites from the faculty directory?
Also, I think this would require adding a new website column to the faculty table.

Yes, exactly!

source: gharchive/issue

license: MIT

license_type: permissive

license_source: github-api


text:
Errors creating replicated tables

Hello all,
First of all, thanks for the driver, it's being really useful :).
We're running into a problem that I would like to describe here: we make use of the ClickHouse abilities to replicate tables and we're getting errors while we try to create the table in all the nodes of the cluster
Cluster
Our current setup is a ClickHouse cluster with 3 shards; every shard contains two replicas
    	<us-west-2>
        	<shard>
            	<internal_replication>true</internal_replication>
            	<replica>
                	<host>clickhouse-1-us-west-2</host>
                	<port>9000</port>
           		</replica>
            	<replica>
                	<host>clickhouse-2-us-west-2</host>
                	<port>9000</port>
           		</replica>
        	</shard>
        	<shard>
            	<internal_replication>true</internal_replication>
            	<replica>
                	<host>clickhouse-3-us-west-2</host>
                	<port>9000</port>
           		</replica>
            	<replica>
                	<host>clickhouse-4-us-west-2</host>
                	<port>9000</port>
           		</replica>
        	</shard>
        	<shard>
            	<internal_replication>true</internal_replication>
            	<replica>
                	<host>clickhouse-5-us-west-2</host>
                	<port>9000</port>
           		</replica>
            	<replica>
                	<host>clickhouse-6-us-west-2</host>
                	<port>9000</port>
           		</replica>
        	</shard>
    	</us-west-2>

Queries
We're trying to create a replicated table in all the six previous nodes (we cannot make use of the ON CLUSTER directive)
CREATE TABLE IF NOT EXISTS local_calls (
    trace_id String,
    call_id String,
    date Date MATERIALIZED toDate(t/1000),
    t UInt64,
    a UInt64,
    b String,
    c String
) ENGINE = ReplicatedMergeTree('/clickhouse/tables/{shard}/local_calls', '{replica}') PARTITION BY toRelativeDayNum(date) ORDER BY t SETTINGS index_granularity=8192;

I am removing most of the columns for the sake of simplicity
Problem
When we try to run the query on every node, we get the following error:
(details: code: 122, message: Table structure in ZooKeeper is too different from local table structure)’

We get in every replica node: so if we run the queries in the following order: clickhouse-1 to clickhouse-6, we get the errors in nodes 2, 4 and 6
Analysis
I am not 100% sure, but, what I think it's happening is that the columns are being sent in a different order when the query is submitted to the second replica.
So, the first create statement is sent to clickhouse-1, the table is created and all the metadata is stored in Zookeeper, then, when the same query is sent to clickhouse-2, the columns are sent in a different order: the node will check the actual query statement against the metadata stored in Zookeeper (because it's a replicated table) an it will fail with an error like the one already described.
Does it make sense?
Please, let me know if I can help some how (in case this is a real issue :) )

Hi, I think it's a ClickHouse problem/bug. Try to create the table without a slash in default value (date Date MATERIALIZED toDate(t/1000) )

I will give it a try.
Just would like to add that creating the tables using regular HTTP requests works fine

It's very strange. I'll troubleshoot it

I've followed the same process using and HTTP Client and the command line (which uses the TCP protocol, doesn't it) and both works for me.
The only way I am able to reproduce the issue is using the driver

OK, I'll be back on Monday and fix it.

Hi @kshvakov,
do you have any news on this ticket? Where you able to reproduce the problem we encountered?
If there is anything we can do to help out, let us know.
Thanks,
Marcel

I had hoped this was an instance of a map being ranged over for columns being presented to the clickhouse server, however this does not seem to be the case :/

You can ignore this.
The issue was that we were creating a table on one replica and then running all the migration alter statements. The next create would then fail because the initial create is the original table minus the alter deltas.

authors: kshvakov marcelbirkner migue sigil66

repo: kshvakov/clickhouse

license: mit

license_source: bigquery


text:
“奇”不在“ji”的列表里

输入“jiuu”可以找到“奇数”，但单独输入“ji”，无法找到“奇”字。

感谢反馈！

提高了单字表中「奇」字字频，现在打 jidko 可以在首选位置了。
字词模式增补了之前遗漏的码 jidk奇。

authors: ksqsf kuqquk

repo: ksqsf/rime-moran


text:
Caching middleware

It could be common feature request to cache read queries for many apis.
we should design and implement middleware that will be caching responses from BE and sending them back to the client

So are you saying the this will be a server side cache?

@shan-96 yes the idea to have some thing similar to rate limiter middleware, https://github.com/ksysoev/wasabi/blob/main/middleware/request/ratelimiter.go#L17 For now we can keep implementations simple and use some in memory cache. for handling concurrent request to the same key we can use https://pkg.go.dev/golang.org/x/sync/singleflight

also for catching api response we can use connection wrapper https://github.com/ksysoev/wasabi/blob/main/channel/connection_wrapper.go

I'm adding some proposals here. Let me know if a document with details are need.

Caching lib prospects

https://github.com/VictoriaMetrics/fastcache - thread safe + in memory, might be suitable for large number of entries and small GC overhead
https://github.com/dgraph-io/ristretto - probably same as above but more popular and there might be option to offload the cache to separate layer or outside main memory
https://github.com/akyoto/cach - very simple, does one job
https://github.com/OrlovEvgeny/go-mcache - pointer based in memory cache

I personally favor ristretto just because it is a stable project and caching middleware is an important north star for wasabi so we should think long term.
Comments?

@shan-96 ristretto looks good, we can start with it, as a next steps we can provide option to provide customer cache storage that satisfy the interface.

@shan-96 do you have any concern if i takeover this issue?

@ksysoev go ahead

Implemented in #97, I decided to go with https://github.com/jellydator/ttlcache as it looks way simpler and looks enough for current needs.

ah yes ttlcache is a good alternative

repo: ksysoev/wasabi


text:
Trip Card Modules

On the trip page, we will need to create a component that will be used to populate some trip info. -

Use a bootstrap card to contain the elements
Have a Title, Picture, Cost, Location, Date and Time, Description (maybe a condensed description instead of full length), and anything else that might be neccassary
Make the Card itself a linkable item using Next.js Link element
Make sure title, pictures, and descriptions are inherited from the props of the component for re-usability

Completed on Branch feature/tripCard and merged to development

repo: ktayah/drexelWeekendWarriorsSite


text:
pretrained mobilenetv3_small_67.4.pth.tar file is broken

RT. cannot open this file as a .tar file

I was able to open the file as ".pth" file, not as the archived tar. you could rename it from mobilenetv3_small_67.4.pth.tar to mobilenetv3_small_67.4.pth, and load it with torch.load or tools like Netron - which is a great model visualizer - would  be a good method to inspect models.


text:
[Bug] 编辑应用配置时，会丢失模型的ID导致后续chat失败

💻 系统环境 | Operating System
Windows
🌐 浏览器 | Browser
Chrome
🐛 问题描述 | Bug Description

🚦 期望结果 | Expected Behavior
No response
📷 复现步骤 | Recurrence Steps
No response
📝 补充信息 | Additional Information
No response

Thanks @Carrotzpc and @Jandiasnow it works.

repo: kubeagi/ops-console


text:
Overestimation for underlying node storage on Azure platform root disks

It seems when gathering metrics on an Azure AKS cluster, the underlying root disks are being overestimated. Possibly due to this query needing some additional filters.
Example:
Node pool settings:

Disk breakdown as reported by Kubecost:

Related json:
Azure/0bd50fdf-c923-4e1e-850c-196dd3dcc5d3/__undefined__/Storage/azure-primary/Disk/Kubernetes/aks-agentpool-41384482-vmss000000/aks-agentpool-41384482-vmss000000: {
  type: "Disk",
  properties: {
    category: "Storage",
    provider: "Azure",
    account: "0bd50fdf-c923-4e1e-850c-196dd3dcc5d3",
    service: "Kubernetes",
    cluster: "azure-primary",
    name: "aks-agentpool-41384482-vmss000000",
    providerID: "aks-agentpool-41384482-vmss000000"
},
labels: { },
window: {
  start: "2022-06-07T00:00:00Z",
  end: "2022-06-08T00:00:00Z"
},
start: "2022-06-07T00:00:00Z",
  end: "2022-06-08T00:00:00Z",
  minutes: 1440,
  byteHours: 4444152299520,
  bytes: 185173012480,
  breakdown: {
    idle: 0.8205240948497843,
    other: 0,
    system: 0.17947590515021575,
    user: 0
  },
  adjustment: 0,
  totalCost: 0.227804
}

Prometheus results:
container_fs_limit_bytes:
container_fs_limit_bytes{agentpool="agentpool", beta_kubernetes_io_arch="amd64", beta_kubernetes_io_instance_type="Standard_B4ms", beta_kubernetes_io_os="linux", device="/dev/sda1", failure_domain_beta_kubernetes_io_region="eastus", failure_domain_beta_kubernetes_io_zone="0", id="/", instance="aks-agentpool-41384482-vmss000000", job="kubernetes-nodes-cadvisor", kubernetes_azure_com_agentpool="agentpool", kubernetes_azure_com_cluster="MC_khandkcost_khand-dev-1_eastus", kubernetes_azure_com_mode="system", kubernetes_azure_com_node_image_version="AKSUbuntu-1804gen2containerd-2022.02.01", kubernetes_azure_com_os_sku="Ubuntu", kubernetes_azure_com_role="agent", kubernetes_azure_com_storageprofile="managed", kubernetes_azure_com_storagetier="Premium_LRS", kubernetes_io_arch="amd64", kubernetes_io_hostname="aks-agentpool-41384482-vmss000000", kubernetes_io_os="linux", kubernetes_io_role="agent", node_kubernetes_io_instance_type="Standard_B4ms", storageprofile="managed", storagetier="Premium_LRS", topology_kubernetes_io_region="eastus", topology_kubernetes_io_zone="0"}
133018140672

container_fs_limit_bytes{agentpool="agentpool", beta_kubernetes_io_arch="amd64", beta_kubernetes_io_instance_type="Standard_B4ms", beta_kubernetes_io_os="linux", device="/dev/sdb1", failure_domain_beta_kubernetes_io_region="eastus", failure_domain_beta_kubernetes_io_zone="0", id="/", instance="aks-agentpool-41384482-vmss000000", job="kubernetes-nodes-cadvisor", kubernetes_azure_com_agentpool="agentpool", kubernetes_azure_com_cluster="MC_khandkcost_khand-dev-1_eastus", kubernetes_azure_com_mode="system", kubernetes_azure_com_node_image_version="AKSUbuntu-1804gen2containerd-2022.02.01", kubernetes_azure_com_os_sku="Ubuntu", kubernetes_azure_com_role="agent", kubernetes_azure_com_storageprofile="managed", kubernetes_azure_com_storagetier="Premium_LRS", kubernetes_io_arch="amd64", kubernetes_io_hostname="aks-agentpool-41384482-vmss000000", kubernetes_io_os="linux", kubernetes_io_role="agent", node_kubernetes_io_instance_type="Standard_B4ms", storageprofile="managed", storagetier="Premium_LRS", topology_kubernetes_io_region="eastus", topology_kubernetes_io_zone="0"}
33684209664

container_fs_limit_bytes{agentpool="agentpool", beta_kubernetes_io_arch="amd64", beta_kubernetes_io_instance_type="Standard_B4ms", beta_kubernetes_io_os="linux", device="/dev/shm", failure_domain_beta_kubernetes_io_region="eastus", failure_domain_beta_kubernetes_io_zone="0", id="/", instance="aks-agentpool-41384482-vmss000000", job="kubernetes-nodes-cadvisor", kubernetes_azure_com_agentpool="agentpool", kubernetes_azure_com_cluster="MC_khandkcost_khand-dev-1_eastus", kubernetes_azure_com_mode="system", kubernetes_azure_com_node_image_version="AKSUbuntu-1804gen2containerd-2022.02.01", kubernetes_azure_com_os_sku="Ubuntu", kubernetes_azure_com_role="agent", kubernetes_azure_com_storageprofile="managed", kubernetes_azure_com_storagetier="Premium_LRS", kubernetes_io_arch="amd64", kubernetes_io_hostname="aks-agentpool-41384482-vmss000000", kubernetes_io_os="linux", kubernetes_io_role="agent", node_kubernetes_io_instance_type="Standard_B4ms", storageprofile="managed", storagetier="Premium_LRS", topology_kubernetes_io_region="eastus", topology_kubernetes_io_zone="0"}
8393371648

container_fs_limit_bytes{agentpool="agentpool", beta_kubernetes_io_arch="amd64", beta_kubernetes_io_instance_type="Standard_B4ms", beta_kubernetes_io_os="linux", device="/run", failure_domain_beta_kubernetes_io_region="eastus", failure_domain_beta_kubernetes_io_zone="0", id="/", instance="aks-agentpool-41384482-vmss000000", job="kubernetes-nodes-cadvisor", kubernetes_azure_com_agentpool="agentpool", kubernetes_azure_com_cluster="MC_khandkcost_khand-dev-1_eastus", kubernetes_azure_com_mode="system", kubernetes_azure_com_node_image_version="AKSUbuntu-1804gen2containerd-2022.02.01", kubernetes_azure_com_os_sku="Ubuntu", kubernetes_azure_com_role="agent", kubernetes_azure_com_storageprofile="managed", kubernetes_azure_com_storagetier="Premium_LRS", kubernetes_io_arch="amd64", kubernetes_io_hostname="aks-agentpool-41384482-vmss000000", kubernetes_io_os="linux", kubernetes_io_role="agent", node_kubernetes_io_instance_type="Standard_B4ms", storageprofile="managed", storagetier="Premium_LRS", topology_kubernetes_io_region="eastus", topology_kubernetes_io_zone="0"}
1678675968

container_fs_limit_bytes{agentpool="agentpool", beta_kubernetes_io_arch="amd64", beta_kubernetes_io_instance_type="Standard_B4ms", beta_kubernetes_io_os="linux", device="/run/lock", failure_domain_beta_kubernetes_io_region="eastus", failure_domain_beta_kubernetes_io_zone="0", id="/", instance="aks-agentpool-41384482-vmss000000", job="kubernetes-nodes-cadvisor", kubernetes_azure_com_agentpool="agentpool", kubernetes_azure_com_cluster="MC_khandkcost_khand-dev-1_eastus", kubernetes_azure_com_mode="system", kubernetes_azure_com_node_image_version="AKSUbuntu-1804gen2containerd-2022.02.01", kubernetes_azure_com_os_sku="Ubuntu", kubernetes_azure_com_role="agent", kubernetes_azure_com_storageprofile="managed", kubernetes_azure_com_storagetier="Premium_LRS", kubernetes_io_arch="amd64", kubernetes_io_hostname="aks-agentpool-41384482-vmss000000", kubernetes_io_os="linux", kubernetes_io_role="agent", node_kubernetes_io_instance_type="Standard_B4ms", storageprofile="managed", storagetier="Premium_LRS", topology_kubernetes_io_region="eastus", topology_kubernetes_io_zone="0"}
5242880

container_fs_limit_bytes{agentpool="agentpool", beta_kubernetes_io_arch="amd64", beta_kubernetes_io_instance_type="Standard_B4ms", beta_kubernetes_io_os="linux", device="/sys/fs/cgroup", failure_domain_beta_kubernetes_io_region="eastus", failure_domain_beta_kubernetes_io_zone="0", id="/", instance="aks-agentpool-41384482-vmss000000", job="kubernetes-nodes-cadvisor", kubernetes_azure_com_agentpool="agentpool", kubernetes_azure_com_cluster="MC_khandkcost_khand-dev-1_eastus", kubernetes_azure_com_mode="system", kubernetes_azure_com_node_image_version="AKSUbuntu-1804gen2containerd-2022.02.01", kubernetes_azure_com_os_sku="Ubuntu", kubernetes_azure_com_role="agent", kubernetes_azure_com_storageprofile="managed", kubernetes_azure_com_storagetier="Premium_LRS", kubernetes_io_arch="amd64", kubernetes_io_hostname="aks-agentpool-41384482-vmss000000", kubernetes_io_os="linux", kubernetes_io_role="agent", node_kubernetes_io_instance_type="Standard_B4ms", storageprofile="managed", storagetier="Premium_LRS", topology_kubernetes_io_region="eastus", topology_kubernetes_io_zone="0"}
8393371648

sum(container_fs_limit_bytes{device!="tmpfs", id="/"}): 185173012480

Taking just the device /dev/sda1 is 123.9GB, which gets much closer to the 128 that we'd expect. We probably need to do this per platform since disk conventions vary from provider to provider.

authors: AjayTripathy keithhand

repo: kubecost/opencost


text:
EdgeMesh-agent deployment failure on Raspberry Pi 4 (ARM based CPU)

What happened:
edgemesh-agent cannot be deployed on Raspberry Pi 4.
pi@raspberrypi:~ $ docker ps -a

CONTAINER ID   IMAGE                     COMMAND            CREATED         STATUS                     PORTS     NAMES

abbba6511322   kubeedge/edgemesh-agent   "edgemesh-agent"   2 minutes ago   Exited (1) 2 minutes ago             k8s_edgemesh-agent_edgemesh-agent-edge-7bbsm_kubeedge_1dce335a-e6a7-4b91-b2b3-e11d97c395b8_92

a78a927b7ec2   kubeedge/pause-arm:3.1    "/pause"           8 hours ago     Up 8 hours                           k8s_POD_edgemesh-agent-edge-7bbsm_kubeedge_1dce335a-e6a7-4b91-b2b3-e11d97c395b8_0

Check docker container through docker logs
pi@raspberrypi:~ $ docker logs abbba6511322

standard_init_linux.go:228: exec user process caused: exec format error

What you expected to happen:
EdgeMesh deployment complete without any error
root@charliecloud-ASUSPRO-D340MC-C-S340MC:/home/charlie-cloud# kubectl get all -n kubeedge -o wide

NAME                                   READY   STATUS    RESTARTS   AGE     IP              NODE                NOMINATED NODE   READINESS GATES
pod/edgemesh-agent-edge-7bbsm          1/1     Running     57         5h10m   192.168.0.86    raspberrypi         <none>           <none>
pod/edgemesh-agent-edge-rbcrv          1/1     Running   0          6h6m    192.168.0.206   default-edge-node   <none>           <none>
pod/edgemesh-server-7bdbcfc7b5-hf4ds   1/1     Running   0          36s     <none>          cloud-node          <none>           <none>

NAME                                  DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR   AGE    CONTAINERS       IMAGES                           SELECTOR
daemonset.apps/edgemesh-agent-cloud   0         0         0       0            0           <none>          6h7m   edgemesh-agent   kubeedge/edgemesh-agent:latest   k8s-app=kubeedge,kubeedge=edgemesh-agent
daemonset.apps/edgemesh-agent-edge    2         2         2       2            2           <none>          6h6m   edgemesh-agent   kubeedge/edgemesh-agent:latest   k8s-app=kubeedge,kubeedge=edgemesh-agent

NAME                              READY   UP-TO-DATE   AVAILABLE   AGE     CONTAINERS        IMAGES                            SELECTOR
deployment.apps/edgemesh-server   1/1     1            1           6h44m   edgemesh-server   kubeedge/edgemesh-server:latest   k8s-app=kubeedge,kubeedge=edgemesh-server

NAME                                         DESIRED   CURRENT   READY   AGE     CONTAINERS        IMAGES                            SELECTOR
replicaset.apps/edgemesh-server-7bdbcfc7b5   1         1         1       6h44m   edgemesh-server   kubeedge/edgemesh-server:latest   k8s-app=kubeedge,kubeedge=edgemesh-server,pod-template-hash=7bdbcfc7b5

How to reproduce it (as minimally and precisely as possible):

Deploy a k8s cluster through kubeadm

Deploy a KubeEdge cluster (Binary Method)

master node: k8s master + KubeEdge cloud
edge node 1: KubeEdge edge node (intel CPU PC)
edge node 2: KubeEdge edge node (arm CPU Raspberry Pi 4)

Deploy EdgeMesh through kubectl apply -f by the Official Document

Anything else we need to know?:
command:
kubectl get all -n kubeedge -o wide

root@charliecloud-ASUSPRO-D340MC-C-S340MC:/home/charlie-cloud# kubectl get all -n kubeedge -o wide
NAME                                   READY   STATUS    RESTARTS   AGE     IP              NODE                NOMINATED NODE   READINESS GATES
pod/edgemesh-agent-edge-7bbsm          0/1     Error     57         5h10m   192.168.0.86    raspberrypi         <none>           <none>
pod/edgemesh-agent-edge-rbcrv          1/1     Running   0          6h6m    192.168.0.206   default-edge-node   <none>           <none>
pod/edgemesh-server-7bdbcfc7b5-hf4ds   0/1     Pending   0          36s     <none>          cloud-node          <none>           <none>

NAME                                  DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR   AGE    CONTAINERS       IMAGES                           SELECTOR
daemonset.apps/edgemesh-agent-cloud   0         0         0       0            0           <none>          6h7m   edgemesh-agent   kubeedge/edgemesh-agent:latest   k8s-app=kubeedge,kubeedge=edgemesh-agent
daemonset.apps/edgemesh-agent-edge    2         2         1       2            1           <none>          6h6m   edgemesh-agent   kubeedge/edgemesh-agent:latest   k8s-app=kubeedge,kubeedge=edgemesh-agent

NAME                              READY   UP-TO-DATE   AVAILABLE   AGE     CONTAINERS        IMAGES                            SELECTOR
deployment.apps/edgemesh-server   0/1     1            0           6h44m   edgemesh-server   kubeedge/edgemesh-server:latest   k8s-app=kubeedge,kubeedge=edgemesh-server

NAME                                         DESIRED   CURRENT   READY   AGE     CONTAINERS        IMAGES                            SELECTOR
replicaset.apps/edgemesh-server-7bdbcfc7b5   1         1         0       6h44m   edgemesh-server   kubeedge/edgemesh-server:latest   k8s-app=kubeedge,kubeedge=edgemesh-server,pod-template-hash=7bdbcfc7b5

Environment:

EdgeMesh version: main branch
root@charliecloud-ASUSPRO-D340MC-C-S340MC:/home/charlie-cloud/Downloads/edgemesh# git checkout

M	build/server/edgemesh/05-configmap.yaml
Your branch is up to date with 'origin/main'.

(2021/09/17 18:46)

Kubernetes version (use kubectl version):
root@charliecloud-ASUSPRO-D340MC-C-S340MC:/home/charlie-cloud/Downloads/edgemesh# kubectl version

Client Version: version.Info{Major:"1", Minor:"19", GitVersion:"v1.19.14", GitCommit:"0fd2b5afdfe3134d6e1531365fdb37dd11f54d1c", GitTreeState:"clean", BuildDate:"2021-08-11T18:07:41Z", GoVersion:"go1.15.15", Compiler:"gc", Platform:"linux/amd64"}

Server Version: version.Info{Major:"1", Minor:"19", GitVersion:"v1.19.14", GitCommit:"0fd2b5afdfe3134d6e1531365fdb37dd11f54d1c", GitTreeState:"clean", BuildDate:"2021-08-11T18:02:17Z", GoVersion:"go1.15.15", Compiler:"gc", Platform:"linux/amd64"}

KubeEdge version(e.g. cloudcore --version and edgecore --version):
cloudcore on k8s master node
root@charliecloud-ASUSPRO-D340MC-C-S340MC:/home/charlie-cloud/Downloads/edgemesh# cloudcore --version

KubeEdge v1.8.0-beta.0.81+149aa721b82ae9

The intel CPU based PC
charlie-edge@charlieedge-CM1745:~$ edgecore --version

KubeEdge v1.8.0-beta.0.81+149aa721b82ae9

The ARM CPU based Raspberry Pi 4
pi@raspberrypi:~ $ edgecore --version

KubeEdge v1.8.0-beta.0.91+29905c6704b6e9

Cloud nodes Environment:

Hardware configuration (e.g. lscpu):root@charliecloud-ASUSPRO-D340MC-C-S340MC:/home/charlie-cloud/Downloads/edgemesh# lscpu

  Architecture:                    x86_64
  CPU op-mode(s):                  32-bit, 64-bit
  Byte Order:                      Little Endian
  Address sizes:                   39 bits physical, 48 bits virtual
  CPU(s):                          6
  On-line CPU(s) list:             0-5
  Thread(s) per core:              1
  Core(s) per socket:              6
  Socket(s):                       1
  NUMA node(s):                    1
  Vendor ID:                       GenuineIntel
  CPU family:                      6
  Model:                           158
  Model name:                      Intel(R) Core(TM) i5-8500 CPU @ 3.00GHz
  Stepping:                        10
  CPU MHz:                         887.468
  CPU max MHz:                     4100.0000
  CPU min MHz:                     800.0000
  BogoMIPS:                        6000.00
  Virtualization:                  VT-x
  L1d cache:                       192 KiB
  L1i cache:                       192 KiB
  L2 cache:                        1.5 MiB
  L3 cache:                        9 MiB
  NUMA node0 CPU(s):               0-5
  Vulnerability Itlb multihit:     KVM: Mitigation: VMX disabled
  Vulnerability L1tf:              Mitigation; PTE Inversion; VMX conditional cache flushes, SMT disabled
  Vulnerability Mds:               Mitigation; Clear CPU buffers; SMT disabled
  Vulnerability Meltdown:          Mitigation; PTI
  Vulnerability Spec store bypass: Mitigation; Speculative Store Bypass disabled via prctl and seccomp
  Vulnerability Spectre v1:        Mitigation; usercopy/swapgs barriers and __user pointer sanitization
  Vulnerability Spectre v2:        Mitigation; Full generic retpoline, IBPB conditional, IBRS_FW, STIBP disabled, RSB filling
  Vulnerability Srbds:             Mitigation; Microcode
  Vulnerability Tsx async abort:   Mitigation; Clear CPU buffers; SMT disabled
  Flags:                           fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constan
                                  t_tsc art arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16
                                  xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch cpuid_fault invpcid_single pti ssbd
                                  ibrs ibpb stibp tpr_shadow vnmi flexpriority ept vpid ept_ad fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm mpx rdseed adx smap clflushopt in
                                  tel_pt xsaveopt xsavec xgetbv1 xsaves dtherm ida arat pln pts hwp hwp_notify hwp_act_window hwp_epp md_clear flush_l1d

OS (e.g. cat /etc/os-release):root@charliecloud-ASUSPRO-D340MC-C-S340MC:/home/charlie-cloud/Downloads/edgemesh# cat /etc/os-release

  NAME="Ubuntu"
  VERSION="20.04.3 LTS (Focal Fossa)"
  ID=ubuntu
  ID_LIKE=debian
  PRETTY_NAME="Ubuntu 20.04.3 LTS"
  VERSION_ID="20.04"
  HOME_URL="https://www.ubuntu.com/"
  SUPPORT_URL="https://help.ubuntu.com/"
  BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
  PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
  VERSION_CODENAME=focal
  UBUNTU_CODENAME=focal

Kernel (e.g. uname -a):root@charliecloud-ASUSPRO-D340MC-C-S340MC:/home/charlie-cloud/Downloads/edgemesh# uname -a

Linux charliecloud-ASUSPRO-D340MC-C-S340MC 5.11.0-34-generic #36~20.04.1-Ubuntu SMP Fri Aug 27 08:06:32 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

Go version (e.g. go version):root@charliecloud-ASUSPRO-D340MC-C-S340MC:/home/charlie-cloud/Downloads/edgemesh# go version

go version go1.17 linux/amd64

Others:

Edge nodes Environment:

PC (intel CPU)

edgecore version (e.g. edgecore --version):charlie-edge@charlieedge-CM1745:~$ edgecore --version

KubeEdge v1.8.0-beta.0.81+149aa721b82ae9

Hardware configuration (e.g. lscpu):charlie-edge@charlieedge-CM1745:~$ lscpu

Architecture:                    x86_64
CPU op-mode(s):                  32-bit, 64-bit
Byte Order:                      Little Endian
Address sizes:                   48 bits physical, 48 bits virtual
CPU(s):                          4
On-line CPU(s) list:             0-3
Thread(s) per core:              2
Core(s) per socket:              2
Socket(s):                       1
NUMA node(s):                    1
Vendor ID:                       AuthenticAMD
CPU family:                      21
Model:                           16
Model name:                      AMD A8-5500 APU with Radeon(tm) HD Graphics
Stepping:                        1
Frequency boost:                 enabled
CPU MHz:                         1400.000
CPU max MHz:                     3200.0000
CPU min MHz:                     1400.0000
BogoMIPS:                        6400.57
Virtualization:                  AMD-V
L1d cache:                       32 KiB
L1i cache:                       128 KiB
L2 cache:                        4 MiB
NUMA node0 CPU(s):               0-3
Vulnerability Itlb multihit:     Not affected
Vulnerability L1tf:              Not affected
Vulnerability Mds:               Not affected
Vulnerability Meltdown:          Not affected
Vulnerability Spec store bypass: Mitigation; Speculative Store Bypass disabled v
                                ia prctl and seccomp
Vulnerability Spectre v1:        Mitigation; usercopy/swapgs barriers and __user
                                pointer sanitization
Vulnerability Spectre v2:        Mitigation; Full AMD retpoline, STIBP disabled,
                                RSB filling
Vulnerability Srbds:             Not affected
Vulnerability Tsx async abort:   Not affected
Flags:                           fpu vme de pse tsc msr pae mce cx8 apic sep mtr
                                r pge mca cmov pat pse36 clflush mmx fxsr sse s
                                se2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtsc
                                p lm constant_tsc rep_good nopl nonstop_tsc cpu
                                id extd_apicid aperfmperf pni pclmulqdq monitor
                                ssse3 fma cx16 sse4_1 sse4_2 popcnt aes xsave
                                avx f16c lahf_lm cmp_legacy svm extapic cr8_leg
                                acy abm sse4a misalignsse 3dnowprefetch osvw ib
                                s xop skinit wdt lwp fma4 tce nodeid_msr tbm to
                                poext perfctr_core perfctr_nb cpb hw_pstate ssb
                                d vmmcall bmi1 arat npt lbrv svm_lock nrip_save
                                tsc_scale vmcb_clean flushbyasid decodeassists
                                pausefilter pfthreshold

OS (e.g. cat /etc/os-release):charlie-edge@charlieedge-CM1745:~$ cat /etc/os-release

NAME="Ubuntu"
VERSION="20.04.2 LTS (Focal Fossa)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 20.04.2 LTS"
VERSION_ID="20.04"
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
VERSION_CODENAME=focal
UBUNTU_CODENAME=focal

Kernel (e.g. uname -a):charlie-edge@charlieedge-CM1745:~$ uname -a

Linux charlieedge-CM1745 5.11.0-34-generic #36~20.04.1-Ubuntu SMP Fri Aug 27 08:06:32 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

Go version (e.g. go version):charlie-edge@charlieedge-CM1745:~$ go version

go version go1.17 linux/amd64

Others:

Raspberry Pi (arm CPU)

edgecore version (e.g. edgecore --version):pi@raspberrypi:~ $ edgecore --version

KubeEdge v1.8.0-beta.0.91+29905c6704b6e9

Hardware configuration (e.g. lscpu):pi@raspberrypi:~ $ lscpu

Architecture:        armv7l
Byte Order:          Little Endian
CPU(s):              4
On-line CPU(s) list: 0-3
Thread(s) per core:  1
Core(s) per socket:  4
Socket(s):           1
Vendor ID:           ARM
Model:               3
Model name:          Cortex-A72
Stepping:            r0p3
CPU max MHz:         1500.0000
CPU min MHz:         600.0000
BogoMIPS:            108.00
Flags:               half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm crc32

OS (e.g. cat /etc/os-release):pi@raspberrypi:~ $ cat /etc/os-release

PRETTY_NAME="Raspbian GNU/Linux 10 (buster)"
NAME="Raspbian GNU/Linux"
VERSION_ID="10"
VERSION="10 (buster)"
VERSION_CODENAME=buster
ID=raspbian
ID_LIKE=debian
HOME_URL="http://www.raspbian.org/"
SUPPORT_URL="http://www.raspbian.org/RaspbianForums"
BUG_REPORT_URL="http://www.raspbian.org/RaspbianBugs"

Kernel (e.g. uname -a):pi@raspberrypi:~ $ uname -a

Linux raspberrypi 5.10.60-v7l+ #1449 SMP Wed Aug 25 15:00:44 BST 2021 armv7l GNU/Linux

Go version (e.g. go version):pi@raspberrypi:~ $ go version

go version go1.17 linux/arm

Others:

Additional note:
KubeEdge v1.8.1 has the very same problem.

KubeEdge version(e.g. cloudcore --version and edgecore --version):
cloudcore on k8s master node
charlie-cloud@charliecloud-ASUSPRO-D340MC-C-S340MC:~$ cloudcore --version

KubeEdge v1.8.1

The intel CPU based PC
charlie-edge@charlieedge-CM1745:~$ edgecore --version

KubeEdge v1.8.1

The ARM CPU based Raspberry Pi 4
pi@raspberrypi:~ $ edgecore --version

KubeEdge v1.8.1

Error Message:
kubectl get all -n kubeedge -o wide

root@charliecloud-ASUSPRO-D340MC-C-S340MC:/home/charlie-cloud/Downloads/edgemesh# kubectl get all -n kubeedge -o wide
NAME                                   READY   STATUS    RESTARTS   AGE     IP              NODE                NOMINATED NODE   READINESS GATES
pod/edgemesh-agent-edge-rjlp6          1/1     Running   0          8m12s   192.168.0.206   default-edge-node   <none>           <none>
pod/edgemesh-agent-edge-x2cmt          0/1     Error     6          8m12s   192.168.0.86    raspberrypi         <none>           <none>
pod/edgemesh-server-7bdbcfc7b5-hjvmx   0/1     Pending   0          19s     <none>          cloud-node          <none>           <none>

NAME                                  DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR   AGE     CONTAINERS       IMAGES                           SELECTOR
daemonset.apps/edgemesh-agent-cloud   0         0         0       0            0           <none>          9m7s    edgemesh-agent   kubeedge/edgemesh-agent:latest   k8s-app=kubeedge,kubeedge=edgemesh-agent
daemonset.apps/edgemesh-agent-edge    2         2         1       2            1           <none>          8m12s   edgemesh-agent   kubeedge/edgemesh-agent:latest   k8s-app=kubeedge,kubeedge=edgemesh-agent

NAME                              READY   UP-TO-DATE   AVAILABLE   AGE     CONTAINERS        IMAGES                            SELECTOR
deployment.apps/edgemesh-server   0/1     1            0           9m53s   edgemesh-server   kubeedge/edgemesh-server:latest   k8s-app=kubeedge,kubeedge=edgemesh-server

NAME                                         DESIRED   CURRENT   READY   AGE     CONTAINERS        IMAGES                            SELECTOR
replicaset.apps/edgemesh-server-7bdbcfc7b5   1         1         0       9m53s   edgemesh-server   kubeedge/edgemesh-server:latest   k8s-app=kubeedge,kubeedge=edgemesh-server,pod-template-hash=7bdbcfc7b5

The images of kubeedge docker hub are all amd64, and there is not arm version.
we will support later.

/good-first-issue

/assign

Thus, may I ask how to fix this problem?
I mean how could I compile an arm version image of kubeedge?

Maybe we can refer to https://github.com/kubeedge/kubeedge/blob/master/Makefile#L166 to support multi arch for EdgeMesh. But we need some time to do this work. If you just need an arm version for EdgeMesh, may be you can try CGO_ENABLED=0 GOOS=linux GOARCH=arm64 go build -o agent-arm ./agent/cmd/edgemesh-agent/agent.go to build edgemesh-agent binary.

Okay, I understand. Let me try it. Thank you for your help!

your are welcome. And please let us know how the things is going. And also welcome to file a pull request for this feature.

May I ask how to use the binary? Where should I modify the source of docker image?
Thank you very much!

we do not try to build the arm version yet. I will try do the job and feedback here

Thank you for your help!

Because I do not have a arm64 arch machine, so I dont not test the Dockerfile yet. If we would like to using the x86 marchine to build a arm64 image, we will need qemu. And we need some time to do the job. If you have a arm64 arch machine, you can use the follow dockerfile to build the image
FROM arm64v8/alpine:3.9

RUN apk update && apk --no-cache add iptables

COPY ./edgemesh-agent /usr/local/bin/edgemesh-agent

ENTRYPOINT ["edgemesh-agent"]

I have tried to build an arm64 image by the Dockerfile of  "build/agent/Dockerfile", but it doesn't work(though build the image successfully). And i tried to run the executable file "edgemesh-agent" in container, the error is "Segmentation fault".

authors: khalid-jobs s099064146 yoseihouyn

repo: kubeedge/edgemesh


text:
Add blog post about 2022 survey results

Signed-off-by: Anna Jung (VMware) antheaj@vmware.com
Add blog post about 2022 Kubefow user survey results

deploy preview: https://deploy-preview-121--infallible-murdock-d05108.netlify.app/kubeflow-user-survey-2022/

cc @kubeflow/release-team @jbottum @DomFleischmann

Hi @james-jwu @zijianjoy @theadactyl, could you take a look? I think it would be helpful to get this published before the upcoming Kubeflow summit so that everyone has a pointer to discuss survey results.
cc @akgraner @jbottum

/lgtm
/approve
Thank you for composing the blogpost!

/lgtm

/lgtm
/approve

source: gharchive/pull-request

authors: annajung james-jwu jbottum zijianjoy

repo: kubeflow/blog


text:
Add @andreyvelich to kf-kcc members

I added myself to kf-kcc members from @kubeflow/automl-leads side to help maintaining CI/CD for Training and AutoML WG.
Related: https://github.com/kubeflow/community-infra/issues/14.
/assign @jlewi
/cc @gaocegege @johnugeorge

/lgtm
/approve

authors: andreyvelich jlewi

repo: kubeflow/internal-acls


text:
Add mvlassis as member of Kubeflow org

Closes #723
Contributions:

Part of the release team for 1.10
Kubeflow 1.10 Liaison for the Notebooks WG

Output from pytest test_org_yaml.py:
============================================================ test session starts =============================================================
platform linux -- Python 3.12.7, pytest-8.3.3, pluggy-1.5.0
rootdir: /home/manos/Github/internal-acls/github-orgs
plugins: anyio-4.4.0, typeguard-4.3.0
collected 1 item

test_org_yaml.py .                                                                                [100%]

============================================================= 1 passed in 0.11s ==============================================================

@terrytangyuan  can you approve/review this? thanks

authors: mvlassis varodrig


text:
Turn the remove-namespace kustomize function into a proper function.

Use a client side CRD so we can easily add more types
for which we need to remove the namespace.

Package it in the same docker image as our image-prefix kpt function.

Fix kubeflow/gcp-blueprints#27

Not ready for review but creating a PR so I don't forget about it.

/assign @Bobgy
This is ready for review.

/lgtm
/approve

/lgtm
/approve

authors: Bobgy jlewi

repo: kubeflow/kfctl


text:
[v1alpha2] CreatedCondition is not set

We add created condition in addTFJob but we do not use the updated obj to enqueue, thus we do not have the condition.

IIUC it's on this line https://github.com/kubeflow/tf-operator/blob/050a71771fb0c98f70e6d265d8185a3e67b89cbe/pkg/controller.v2/controller_tfjob.go#L45
The tfjob variable is updated but obj is not?
Is the fix just do tc.enqueueTFJob(tfjob), or something else needs to be done?

I haven't tried it. I will take a look.
/assign

authors: gaocegege lluunn

repo: kubeflow/tf-operator


text:
Slack link expired

Slack invite link on website has expired https://www.kubeflow.org/docs/about/community/

Done: https://github.com/kubeflow/website/pull/3210

authors: dari-o zijianjoy

repo: kubeflow/website


text:
fix bug to running pipeline example successful

Please verify the part I modified.It spent me about two days to figured it out the root cause

Thanks for your pull request. It looks like this may be your first contribution to a Google open source project (if not, look below for help). Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).
📝 Please visit https://cla.developers.google.com/ to sign.
Once you've signed (or fixed any issues), please reply here with @googlebot I signed it! and we'll verify it.
What to do if you already signed the CLA
Individual signers
It's possible we don't have your GitHub username or you're using a different email address on your commit. Check your existing CLA data and verify that your email is set on your git commits.
Corporate signers
Your company has a Point of Contact who decides which employees are authorized to participate. Ask your POC to be added to the group of authorized contributors. If you don't know who your Point of Contact is, direct the Google project maintainer to go/cla#troubleshoot (Public version).
The email used to register you as an authorized contributor must be the email used for the Git commit. Check your existing CLA data and verify that your email is set on your git commits.
The email used to register you as an authorized contributor must also be attached to your GitHub account.
ℹ Googlers: Go here for more info.

@googlebot I signed it!

/assign @animeshsingh

/assign @animeshsingh

/cc @berndverst @vjrantal

@goldwinner do you still want to merge this? AML Studio still exists by the way -- different product from AML.

authors: berndverst goldwinner janeman98


text:
update doc to point reasonable line

In Pipeline metrics guide, there is a link issue which is point to unreasonable line. Correct that.

This change is

/assign @sarahmaddox

/lgtm
/approve

authors: jinchihe sarahmaddox


text:
install ruby gem dependencies

Updates the controller to insert an init container for Ruby runtimes
when a Gemfile is provided. Bundler is set to install gems in the shared
volume and GEM_HOME is set in the container to load the gems from this
volume.

we can merge, but like the other PR about ruby runtime we need to have tests

is one of the example making use of this now ?

@sebgoa @ngtuna rebased and added an example and test

/lgtm
@ngtuna merge when you want

@prydonius @sebgoa Thanks. I want to hold this a bit until the PR #291 get landed. I don't want to see too many red-crosses on the master branch. I am working with @prydonius to fix it asap.

@prydonius Rebase this one as well. The PR #291 has landed already

rebased and squashed :)

Thanks @prydonius . I am landing it 🛬

authors: ngtuna prydonius sebgoa

repo: kubeless/kubeless


text:
Update Kafka

Issue Ref: None
Description:
Update Kafka version
TODOs:

[X] Ready to review
[X] Automated Tests
- [X] Docs

LGTM

authors: andresmgot murali-reddy


text:
ci: use kind built with containerd v1.7.23

Pull Request

[x] Make sure you have followed Kube-OVN Code Style.

What type of this PR
Examples of user facing changes:

Features
Bug fixes
Docs
Tests

Which issue(s) this PR fixes
Fixes #(issue-number)

Pull Request Test Coverage Report for Build 12308429876
Details

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 22.084%

Totals

Change from base Build 12308058851:
0.0%

Covered Lines:
10267

Relevant Lines:
46491

💛  - Coveralls

authors: coveralls zhangzujian

repo: kubeovn/kube-ovn


text:
Upgrading HA cluster without API server LB is failing because Docker is restarted

What happened:
Upgrading an HA cluster that doesn't use LB as an API endpoint is failing because we restart Docker which causes all containers to get terminated. In case the first node is used as an API endpoint, the cluster will be inaccessible until Kubelet detects that containers are terminated. However, that can take several minutes, which is quite long, and will also cause the upgrade process to fail/timeout.
What is the expected behavior:
The upgrade process works on HA clusters without an API server LB.
How to reproduce the issue:

Create a cluster on some cloud provider without creating an LB
Try to upgrade the cluster

Information about the environment:
KubeOne version (kubeone version): 1.4.0
Provider you're deploying cluster on: Azure
Operating system you're deploying on: Ubuntu

@xmudrii but can we consider a cluster "an HA cluster" if it doesn't use kubeapi loadbalancing? I think such setup violates any assumptions as we should "void a warranty".

@kron4eg This is correct, however, there are valid use cases when you might have an HA cluster without an LB (e.g. bare metal setups). I think fixing this should be relatively as easy, e.g. we can just restart kubelet after restarting Docker. containerd is not affected, since restarting containerd doesn't restart containers.

repo: kubermatic/kubeone


text:
NodeCSRApprover doesn't approve requests on GCP

The NodeCSRApprover controller is not approving CSRs for GCP worker nodes due to lack of private IP address and DNS name in the .status.Addresses field in the Machine object.
The CSR includes both private IP address and DNS name and as those are not in the Machine object, the validation fails, therefore the CSR is not signed.
As a workaround, until the issue is not fixed, the operator can manually approve the CSR, by following the instructions from the CSR docs.
As a fix, the following function should be extended to include the other type of addresses.

Unfortunately the bug is still present, used the latest machine controller version v1.14.3 and it seams the machine controller is still not approving the CSRs:
k get csr
NAME        AGE     REQUESTOR                                   CONDITION
csr-2grjt   3m20s   system:node:k1-pool-az-a-75cf6c85cf-h6bpn   Pending
csr-flqd4   6m32s   system:bootstrap:oszbfi                     Approved,Issued
csr-tz7tx   7m7s    system:bootstrap:oszbfi                     Approved,Issued
csr-wbq8n   9m45s   system:node:k1-control-plane-1              Approved,Issued
csr-z5sqm   3m35s   system:bootstrap:fqdtlp                     Approved,Issued

Attached you will find logs and current object states to determine the error. My guess is the following error:
I0628 17:31:35.991471       1 node_csr_approver.go:109] Skipping reconciling CSR 'csr-z5sqm' because CSR object is not valid: username must have the 'system:node:' prefix

machinecontroller.pod.log
machinecontroller.describe.log
csr.output.yaml.log

The root of the issue is that the hostname (InternalDNSName) on the Machine object is empty for some reason. I had no time to investigate why this happens, but I'll try to find out once I have some more time.

can confirm seams to work now

authors: toschneck xmudrii

repo: kubermatic/machine-controller


text:
checkpoint: explicitly load checkpoint manifests

@aaronlevy
Now we load the existing manifests, and only try to install the manifest if checkpoint exists. The previously logic try to create static pod blindly.
Last change for the preparation of the final code logic restructure. With the disk manifest preloading, the checkpointer knows exactly what it expects to recreate if not exists.

test checkpoint code please

Just fyi the above is to trigger the jenkins job. Code-wise this lgtm

@aaronlevy I can see the bootkube-dev turns green. Does this mean the test get passed? cc @pbx0

test checkpoint code please

@aaronlevy :( It is not.

test checkpoint code please

test checkpoint code please

test checkpoint code please

coreosbot test checkpoint code please

coreosbot test checkpoint code

repo: kubernetes-incubator/bootkube


text:
[release-1.10] conmon: fix incorrect log line on a log refresh

backport of https://github.com/kubernetes-incubator/cri-o/pull/1606

/test all

authors: giuseppe mrunalp

repo: kubernetes-incubator/cri-o


text:
[DO NOT MERGE] contrib: test: fix failing networking tests in RHEL

should function for intra-pod communication: http
should function for intra-pod communication: udp

Signed-off-by: Antonio Murdaca runcom@redhat.com

:tada:

Now Fedora and RHEL pass all node-e2e together

LGTM for now.
though we need to fix this the right way.
cc: @rajatchopra

authors: mrunalp runcom


text:
Rename libkpod to libpod

Nobody seems to like the 'kpod' name. There is no existing, established user of libpod, and is a better description of what this library is. Move to using the libpod name instead. The executable may be renamed later, if a good name for it can be found.

Closing as new work will obsolete


text:
Mv version and status test into runtime_info.go

cc @feiskyer
Signed-off-by: Xianglin Gao xlgao@zju.edu.cn

@feiskyer Updated

/lgtm

authors: feiskyer xlgao-zju

repo: kubernetes-incubator/cri-tools


text:
Relaxing aws client version

Rook uses this project for creating a Kubernetes volume provisioner for rook volumes. Rook also uses the aws client for their end-to-end test. Rook requires version v1.8.3 of the aws client. However setting this version will conflict to the version that is pinned by the external-storage project.
This PR relaxes the version so that v1.7.3 - v2.0 of the aws client can be used

I didnt include the glide.lock or vendor changes. Let me know if those are needed. When i ran glide up, there were a lot of new and modified vendor files being picked up.

Thanks, sorry for the inconvenience :) this change alone will be fine

repo: kubernetes-incubator/external-storage


text:
Moves apiserver port to bindPort when using controlPlaneEndpoint

Hi! when using an external loadBalancer, adding port to controlPlaneEndpoint causes kubeadm to fail regex validation. this mends that.

Hi.
Kubeadm 1.10.7 emits the following:
error parsing `ControlPlaneEndpoint to valid dns subdomain with errors: [a DNS-1123 subdomain must consist of lower case alphanumeric characters, '-' or '.', and must start and end with an alphanumeric character (e.g. 'example.com', regex used for validation is '[a-z0-9]([-a-z0-9]*[a-z0-9])?(\.[a-z0-9]([-a-z0-9]*[a-z0-9])?)*')

what is the domain you are using that fails the check?

api.dev.k8s.foo.bar:6443

/lgtm
/approve

authors: neolit123 whereismyjetpack woopstar

repo: kubernetes-incubator/kubespray


text:
pull-cluster-api-operator-e2e-main needs to be migrated to the community cluster ASAP

if not, the job will be disabled starting August 1st

/triage accepted
/assign

Possible fix: https://github.com/kubernetes/test-infra/pull/33091

Closing it, tests are now moved to new prow cluster and passing in both main and release-0.11 branches.
/close

repo: kubernetes-sigs/cluster-api-operator


text:
Fixes for namespace-scoped federatednamespaceplacement

FederatedNamespacePlacement becoming namespace-scoped has resulted in the user guide example not working. Specifically, the resources all get created successfully, but when you try to remove cluster2 from the FederatedNamespacePlacement object, the resources in the test-namespace are not removed because the test-namespace is never removed.
This was caused by mismatching keys to retrieve Namespace and FederatedNamespacePlacement objects from the cache. This is a temporary fix as Namespaces are the only resources we currently support whose template is cluster-scoped while the placement is namespace-scoped. A proper long-term solution should be investigated, especially when we begin to support more cluster-scoped resources.

Hmm, good catch.  I don't understand the failure mode yet, but this seems like something that would ideally be validated in the tests.  Can you think of a way to accomplish this?

Ah, it's the namespace removal that is the problem. I didn't read the comment very carefully.  Yeah, sounds like multiple clusters is the only way to uncover this.

/lgtm

authors: font marun


text:
Refactor create jobs

Fixes #495
Change summary:

reconcileReplicatedJobs() now encapsulates the logic which operates at the replicatedJob level (enforcing in-order startup of replicatedJobs), only calling into createJobs() when the replicatedJob is ready to be created (based on the startup policy, any order vs in order)
createJobs() now only creates jobs.

/assign @kannon92 @ahg-g this one should be straight-forward to review, please take a look when you have a chance

/lgtm

authors: ahg-g danielvegamyhre

repo: kubernetes-sigs/jobset


text:
chore: Bump github.com/awslabs/operatorpkg to latest

Fixes #N/A
Description
Bump github.com/awslabs/operatorpkg to the latest
How was this change tested?
make presubmit
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

Pull Request Test Coverage Report for Build 10817817116
Details

0 of 0   changed or added relevant lines in 0 files are covered.
11 unchanged lines in 3 files lost coverage.
Overall coverage decreased (-0.05%) to 80.521%

Files with Coverage Reduction
New Missed Lines
%

pkg/test/expectations/expectations.go
2
94.73%

pkg/scheduling/requirements.go
2
98.01%

pkg/controllers/provisioning/scheduling/preferences.go
7
86.67%

Totals

Change from base Build 10729017085:
-0.05%

Covered Lines:
8379

Relevant Lines:
10406

💛  - Coveralls

authors: coveralls jonathan-innis

repo: kubernetes-sigs/karpenter


text:
Initialize the kjob issue templates based on Kueue

/assign @mbobrovskyi

/kind cleanup

authors: mbobrovskyi mimowo

repo: kubernetes-sigs/kjob


text:
remove duplicate error message

Signed-off-by: kerthcet kerthcet@gmail.com

What type of PR is this?
/kind cleanup

What this PR does / why we need it:
remove redup error message
Which issue(s) this PR fixes:

Fixes #
Special notes for your reviewer:

/ok-to-test
/lgtm
/approve
Thanks!

authors: alculquicondor kerthcet

repo: kubernetes-sigs/kueue


text:
Changes the project to support multiple api groups

What type of PR is this?
/kind feature
What this PR does / why we need it:
Changes the project to support multiple api groups. This is needed to add a config group for ComponentConfig api.
Which issue(s) this PR fixes:
Special notes for your reviewer:

/hold

do we want this in 0.1.0?

Yes, i think we may also want to change the domain to kueue.sh; so we would have core.kueue.sh and config.kueue.sh.
We actually own the kueue.sh domain :)

The second commit changes the domain to kueue.sh.

the other option is to change the domain to kueue.x-k8s.io and kueue group to core

Removed the second commit.

/hold cancel

authors: ArangoGutierrez ahg-g


text:
Update KEP-2076: Kueuectl.

What type of PR is this?
/kind documentation

What this PR does / why we need it:
Update "KEP-2076: Kueuectl":

Add separate delete workload command,
Remove delete workload command from pass-through.

Which issue(s) this PR fixes:

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

NONE

/approve
Leaving lgtm to @mwielgus

/lgtm

authors: mbobrovskyi mimowo mwielgus


text:
Automated cherry pick of #3514: TAS: fix computing assignment when multiple PodSets

Cherry pick of #3514 on release-0.9.
#3514: TAS: fix computing assignment when multiple PodSets
For details on the cherry pick process, see the cherry pick requests page.
Fix computing the topology assignment for workloads using multiple PodSets requesting the same
topology. In particular, it was possible for the set of topology domains in the assignment to be empty,
and as a consequence the pods would remain gated forever as the TopologyUngater would not have
topology assignment information.

I had to do one manual change in this line: https://github.com/kubernetes-sigs/kueue/pull/3524/files#diff-130e36b28b6a84d355879caa6b7927c98ec18c63adad6ab4fc486458763080bfR3947
because this PR https://github.com/kubernetes-sigs/kueue/pull/3509

/kind bug


text:
Instrument metrics

/assign @dgrisonnet
/triage accepted

@dgrisonnet  /ping

@dgrisonnet Can you please help review? thank you.

repo: kubernetes-sigs/prometheus-adapter


text:
Release v3.4.x

v3.4.0

[x] Release: https://github.com/kubernetes-sigs/promo-tools/releases/tag/v3.4.0
[x] Image promotion: https://github.com/kubernetes/k8s.io/pull/3601
[ ] Rollout:

[x] k8s.io promotion jobs: https://github.com/kubernetes/test-infra/pull/25891

[x] Update image references to use registry.k8s.io

[ ] prow promotion jobs:

[ ] Update image references to use registry.k8s.io

v3.4.x

[x] (@puerco) https://github.com/kubernetes-sigs/promo-tools/issues/536
https://github.com/kubernetes-sigs/promo-tools/pull/537
[x] (@justaugustus investigating) image promotion PR flags seem to have broken: https://github.com/kubernetes-sigs/promo-tools/pull/538
[x] (@justaugustus) Release documentation: https://github.com/kubernetes-sigs/promo-tools/pull/538 / https://github.com/kubernetes-sigs/promo-tools/issues/539
[x] (@justaugustus) Fix tag references in repo: https://github.com/kubernetes-sigs/promo-tools/pull/538
[x] (@puerco) https://github.com/kubernetes-sigs/promo-tools/pull/542

We should release promo-tools v3.4.0 to get the image signature changes into the official image. After that we should promote the image to production and update the related test-infra jobs.

@kubernetes-sigs/release-engineering anyone interested in working on this?

I can take a look tomorrow morning.

This potentially has some sharp edges.
I'll work on this this week and document.

(renamed to "3.4.x" to track all trailing actions, follow-ups, bug fixes needed)

I think we can consider this as done, right?

authors: justaugustus palnabarun saschagrunert

repo: kubernetes-sigs/promo-tools


text:
produce structured test output for this repo's tests

What would you like to be added:
junit test results in CI, so they can be properly processed by the projects's tooling
gotestsum can solve convert go test output to junit.xml (many instances throughout the project e.g. kubernetes/kubernetes, kubernetes-sigs/kind, kubernetes/test-infra, ...)
Why is this needed:
We can't use go.k8s.io/triage to analyze situations like flaking tests because there are no structured test results, only log files.
prow.k8s.io and testgrid can also process junit files and produced structure test result rendering.

/remove-lifecycle stale

/remove-lifecycle stale

/remove-lifecycle stale

/lifecycle frozen

authors: BenTheElder xmudrii


text:
verify config directory checks for kubectl generator

I ran into a problem when running the update-imported-docs script for the 1.18 release.
Previously, I set up the reference configuration directories because some of the references required configuration changes for the release (run make createversiondirs).
The gen-kubectldocs/generators/v1_18/toc.yaml was written over (typical behavior if release dir does not exist) instead of reusing the toc.yaml in the existing target directory.
Look into the logic in the setup script, set_version_dirs.sh.

/assign

/close

repo: kubernetes-sigs/reference-docs


text:
Add v1 to admission review versions and AARCH64 architecture to default secomp profile

What type of PR is this?

/kind feature
What this PR does / why we need it:

Add AARCH64 architecture to default seccomp profile
Add v1 to admission review versions

Which issue(s) this PR fixes:

Does this PR have test?

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

Add v1 to admission review versions and AARCH64 architecture to default profile.

Codecov Report

Merging #1238 (d25f160) into main (15f4aba) will not change coverage.
The diff coverage is n/a.

Additional details and impacted files
@@           Coverage Diff           @@
##             main    #1238   +/-   ##
=======================================
  Coverage   45.41%   45.41%
=======================================
  Files          48       48
  Lines        5362     5362
=======================================
  Hits         2435     2435
  Misses       2807     2807
  Partials      120      120

authors: ccojocar codecov-commenter


text:
Rewrite Listeners in terms of an endpoint concept.

This change explores one way to solve the problem described here,
which is that there is an implied endpoint abstraction that is awkwardly
split across the cluster operator and application owner roles.
Rewrite Listeners to model the concept of a logical network endpoint.
This change defines a Gateway more strongly as the network element to
which addresses can be attached, and Listeners as logical endpoints
within the network element.
The main goal of this change is to consolidate the name of an application
(i.e. the endpoint) into a single part of the API that is controlled
by one user persona. In this change, the application name is strictly
part of the Gateway spec and controlled by the cluster operator role,
while routes are controlled by the application owner.
The Listener protocol is now strongly defined to a core set of common
protocol stacks. This loss of flexibility improves clarity because it
makes it possible to specify how Listeners should be collapsed into
virtual hosts in an underlying proxy implementation.
This change doesn't update ListenerStatus, though clearly it no longer
makes complete sense. The most likely change needed for GatewayStatus
is to drop the Listeners field and fold listener errors directly into
the Conditions field.

/hold

This an interesting concept, thanks for the work on it! The diff is relatively large, but if I'm understanding it correctly, the change entails moving hostname from routes to listeners and moving the route selector into listeners. Did I miss any other significant changes in the diff?

Nope, you have nailed the main intent. See attached doc for my reasoning that there is a "logical endpoint" object that we should model.

/ok-to-test

/assign

Splitting the ports by listener seems to clean things up.
I'm not so sure about the hostname requirement:
How to have wildcard hostnames.
This is a common use case (in fact we added support for it Ingress GA, maybe step backwards).
If not complex wildcards "*.foo.com", at least we at least need to be able to handle default hostname.
Given that with the listener + TLS + associated routes => you can valid the hostname matches and certs w/ all of the objects involved, can we remove hostname from the Gateway level?

Given that with the listener + TLS + associated routes => you can validate the hostname matches and certs w/ all of the objects involved, can we remove hostname from the Gateway level?

That works for HTTP but not HTTPS.
I think this change is a positive one and we should proceed.
I have the same thought as @bowei on the hostname. Default and wildcard domains need to be supported here.
Here is what I think might work:
Keep Hostname in HTTPRoute. This is used for route matching.
In Gateway's Listener, we keep a field AllowedHostnames []string which acts as a filter.
Cluster Operator populate the field after they do the due diligence on their part (ensure DNS setup, TLS certs, approvals, etc).
App owners are now free to bind routes as they see fit as long as the hostname they wish to use is allowed in the Gateway Listener. If not, then they go and talk to the Cluster Operator.
AllowedHostnames can be strict, meaning each and every domain needs to be added, semi-strict by allowed a wildcard set of domains, or relaxed, where it allows for all domains (the easy path).

Splitting the ports by listener seems to clean things up.
I'm not so sure about the hostname requirement:
How to have wildcard hostnames.
This is a common use case (in fact we added support for it Ingress GA, maybe step backwards).

I need to go dig up and read the Ingress spec for this! I changed the Listener hostname to be a match type, so you can express wildcards as a domain match. The default would be an exact host name match.

We at least need to be able to handle default hostname.

I documented the case where the Listener can omit the Hostname. This would allow your to specify routes without pinning to any name.
This, together with domain matching, required a fair amount of new text to specify how Listeners should be collapsed into a virtual host configuration.

Given that with the listener + TLS + associated routes => you can validate the hostname matches and certs w/ all of the objects involved, can we remove hostname from the Gateway level?

Yeh I agree with @hbagdi on this. You need some deterministic information about the hostname in the Listener to do the right certificate selection. In the Google doc linked from the initial comment I discussed some of the corner cases here. Keeping some hostname spec in the Listener means that the semantics are consistent across changes in what the route selector selects.

Given that with the listener + TLS + associated routes => you can validate the hostname matches and certs w/ all of the objects involved, can we remove hostname from the Gateway level?

That works for HTTP but not HTTPS.
I think this change is a positive one and we should proceed.
I have the same thought as @bowei on the hostname. Default and wildcard domains need to be supported here.
Here is what I think might work:
Keep Hostname in HTTPRoute. This is used for route matching.
In Gateway's Listener, we keep a field AllowedHostnames []string which acts as a filter.
Cluster Operator populate the field after they do the due diligence on their part (ensure DNS setup, TLS certs, approvals, etc).
App owners are now free to bind routes as they see fit as long as the hostname they wish to use is allowed in the Gateway Listener. If not, then they go and talk to the Cluster Operator.
AllowedHostnames can be strict, meaning each and every domain needs to be added, semi-strict by allowed a wildcard set of domains, or relaxed, where it allows for all domains (the easy path).

I restored the Hostname in HTTPRoute as per this suggestion. Probably we need some more explanatory text to describe how we intend it to work.
To address the default and wildcard cases, I borrowed the match concept from routes and change the Listener hostname to have "domain" and "exact" match types. A hostname can be omitted, which would give the Listener default route semantics.

Added some example YAML.

These are good changes, James! Thank you for working on this.
One downside is that the user needs to specify the hostnames twice for http and https.
I think that this is a feature and not a limitation and we should move ahead and come back to this later (if users complain about it).

Yeh, there's a few configurations that you could argue have some textual redundancy, but on the bright side, they will be quite explicit :)
I've updated the test to try to clarify some of the questions inline, but left the conversations unresolved.

James,
My understanding was flawed until this point.
What we are doing in this PR is:
 listeners:
  - hostname:
      value: httpbin.example.com
    port: 443
    protocol: HTTPS
    tls:
      certificateRefs:
      - resource: secrets
        name: httpbin
    routes:
    - routeSelector:
        matchLabels:
          app: httpbin
  - hostname:
      value: conformance.example.com
    port: 443
    protocol: HTTPS
    tls:
      certificateRefs:
      - resource: secrets
        name: conformance
    routes:
    - routeSelector:
        matchLabels:
          app: conformance

And how I was (incorrectly) thinking about this was:
 listeners:
  - hostnames:
      name: httpbin.example.com
      name: conformance.example.com
    port: 443
    protocol: HTTPS
    tls:
      - snis:
        httpbin.example.com
        certificateRefs:
        - resource: secrets
          name: httpbin
      - snis:
        conformance.example.com
        certificateRefs:
        - resource: secrets
          name: conformance
    routes:
    - routeSelector:
        matchLabels:
          app: example.com

The differnce in the tls config stands out the most but that's less important.
The important part is about having a routeSelector that can be shared across hostnames. Why?

If you want to share the route selector for multiple domains, that is possible in this model. In the model where route selector is per hostname/port pair, if you use a common selector, then a HTTPRoute resource will be considered invalid for one listener (where hostname doesn't match) but considered valid for another listener (where hostname does match), This can get confusing and a little cumbersome to use.
In case a user wants different route selector, that's still possible, you can either create another gateway resource and specify a different route selector for that, or create another listener in the same gateway to achieve that.

The important part is about having a routeSelector that can be shared across hostnames. Why?

If you want to share the route selector for multiple domains, that is possible in this model. In the model where route selector is per hostname/port pair, if you use a common selector, then a HTTPRoute resource will be considered invalid for one listener (where hostname doesn't match) but considered valid for another listener (where hostname does match), This can get confusing and a little cumbersome to use.

I don't think this is quire right. The spec implicitly describes 2 layers of matching for hostnames. The first applies at the Listener, the second at the HttpRoute. The way this PR specs it, you wold have 2 Listeners for "a.com" and "b.com", and give both Listeners the same route selector. That doesn't mean that routes would ever be invalid for a listener, just that the hostname for some routes would never be matched by requests that come from some Listeners.
Basically, there's no requirement that the Hostname in the HTTPRouteHost has to match anything in any Listener. It will just either work or not.

In case a user wants different route selector, that's still possible, you can either create another gateway resource and specify a different route selector for that, or create another listener in the same gateway to achieve that.

We already have multiple Listeners and rules around collapsing so I'm a bit reluctant to make the matching more complex too. If Listeners have multiple hostname matches, we have to order them and figure out how they might conflict.
We should be flexible, but also avoid having too many ways to say the same thing.

I think what you are saying makes sense now. Thanks for being patient with me and explaining this.
I can buy everything you have said.
I've some new questions:
0. If an HTTPRoute c.com is created, to which traffic is never routed, the status of the route needs to be Invalid to signal to the user that something is amiss rather than "this route will never be matched".

How/Where to define a default TLS cert-key pair?
In the case where the hostname match is not defined for a listener (match all domains), how are TLS configs defined?

I think what you are saying makes sense now. Thanks for being patient with me and explaining this.
I can buy everything you have said.
I've some new questions:
0. If an HTTPRoute c.com is created, to which traffic is never routed, the status of the route needs to be Invalid to signal to the user that something is amiss rather than "this route will never be matched".

I'm not sure whether I'd classify this is an error, it probably needs it's own issue to discuss. Controllers could add a warning condition on the Gateway as a quality of implementation improvement, but maybe the Listener becomes invalid if the Controller can prove it can't actually route any traffic?

How/Where to define a default TLS cert-key pair?
In the case where the hostname match is not defined for a listener (match all domains), how are TLS configs defined?

If a Listener omits the hostname field, it can still have port, protocol, and tls fields. The spec describes how each collapse group can have one of these types of Listener, which captures all unmatched traffic. This is also how you would define a default TLS certificate.

Edit:
Re-reading the PR, it seems that you haven't touched the TLS parts and we should probably keep the TLS conversation out of scope from this PR. We can revisit how to structure the TLSConfig part in a subsequent PR.

Yup, that was intentional :)

I'm not sure whether I'd classify this is an error, it probably needs it's own issue to discuss. Controllers could add a warning condition on the Gateway as a quality of implementation improvement, but maybe the Listener becomes invalid if the Controller can prove it can't actually route any traffic?

Let's discuss this in another issues or a subsequent PR. I'd like to see this PR being merged and iterated upon rather than having more blockers on it.

If a Listener omits the hostname field, it can still have port, protocol, and tls fields. The spec describes how each collapse group can have one of these types of Listener, which captures all unmatched traffic. This is also how you would define a default TLS certificate.

But in that case, there is no way to define different cert-key pairs for different domains. That's a limitation of TLSConfig and not introduced in this PR. I've something in mind and I'll PR once this is merged in.

If a Listener omits the hostname field, it can still have port, protocol, and tls fields. The spec describes how each collapse group can have one of these types of Listener, which captures all unmatched traffic. This is also how you would define a default TLS certificate.

But in that case, there is no way to define different cert-key pairs for different domains. That's a limitation of TLSConfig and not introduced in this PR. I've something in mind and I'll PR once this is merged in.

The way do this is to have a Listener for each domain that you have TLS material for. The Hostname file in the Listener can be matched to a domain and that Listener specified the TLS configuration.

+1 to Wildcard.
Exact is also a "domain"

I don't know why gitHub doesn't show me a field to reply inline, but 🤷
I think that in the YAML, it reads fairly clearly:
Exact match:
  - hostname:
      match: Exact
      name: ssh.example.com

Domain match:
  - hostname:
      match: Domain
      name: example.com

Updated with a number of changed to address review feedback, including the "Any" hostname match type.
I think I've captured most of the feedback. Two suggestions that I haven't addressed are

s/domain/wildcard/
s/collapsable/compatible/

thanks -- are you going to incorporate those changes? I will merge it after that

thanks -- are you going to incorporate those changes? I will merge it after that

I'm not too keen on the wildcard nomenclature. I'll experiment with rewriting the Listener collapse docs though.

thanks -- are you going to incorporate those changes? I will merge it after that

I'm not too keen on the wildcard nomenclature. I'll experiment with rewriting the Listener collapse docs though.

Updated the listener collapse docs to emphasize "compatible" listeners rather than "collapsible" listeners. I moved all that text up to the Gateway's listeners field since it is applicable to how a gateway should deal with the listeners array there.

Updated field tags and examples so that all examples can be applies to a cluster. Filed the following issues to track follow on work:
#206 Discuss domain match vs. wildcard match for listener hostnames kind/feature
#205 WebSocket protocol support kind/feature
#204 h2c (cleartext HTTP/2) protocol support kind/feature
#203 Protocol type extensibility kind/bug
#202 Re-address Gateway and Listener error conditions kind/bug

Can you change gateway conditions since route is not part of Gateway? Also it would be nice to add GatewayConditionType for Addresses like InvalidAddress.

Can you change gateway conditions since route is not part of Gateway? Also it would be nice to add GatewayConditionType for Addresses like InvalidAddress.

There's a lot of conditions that don't make sense after this change, and also conditions that are missing. Since this PR is quite intrusive already, I'm proposing to spin that out into #202.

On Jun 6, 2020, at 8:46 AM, Bowei Du notifications@github.com wrote:

@bowei commented on this pull request.
In api/v1alpha1/gateway_types.go:

@@ -54,78 +55,212 @@ type GatewayList struct {
type GatewaySpec struct {
// Class used for this Gateway. This is the name of a GatewayClass resource.
Class string json:"class" protobuf:"bytes,1,opt,name=class"

// Listeners associated with this Gateway. Listeners define what addresses,
// ports, protocols are bound on this Gateway.

// Listeners associated with this Gateway. Listeners define
// logical endpoints that are bound on this Gateway's addresses.
// At least one Listener MUST be specified.
//
// Each Listener in this array must have a unique Port field,
// however a GatewayClass may collapse compatible Listener
// definitions into single implementation-defined acceptor
// configuration even if their Port fields would otherwise conflict.
//
// Listeners are compatible if all of the following conditions are true:
We can fix this in a later commit, but it would be good to frame this from the user's standpoint, as the current description is somewhat hard to parse.

I’ve been through a number of revisions of this, but I still agree that it could be improved. Happy to take editorial suggestions or discuss on a call :)

/approve
let's merge and iterate

Just confirmed with @jpeach that we can remove the hold and get this in.
/hold cancel
/lgtm

authors: bowei hanlins hbagdi jpeach robscott

repo: kubernetes-sigs/service-apis


text:
clean up community doc to removec outdated links

removes the outdated cschedule scratchpad
removes the old design doc

@robscott PTAL

Thanks!
/lgtm
/approve

authors: hbagdi robscott


text:
"tests pending" checks are buggy

Two separate issues that I've noticed the munger getting confused by:

tests were broken at some point a few days ago. I request a re-test of just that particular build, and then the munger thinks tests have been pending for over 24h.
someone LGTM's a PR before all tests have finished running for the first time. The munger will comment "
pr builder appears to be missing, activating due to 'lgtm' label." and retest, which may cause some builds to needlessly rerun.

cc @lavalamp @eparis @apelisse

cc @foxish

authors: apelisse ixdy

repo: kubernetes/contrib


text:
Fix for setting the upstart fact for ansible prior to 2.0.2

Addresses: #773

Caused by some upstream ansible bugs around converting strings to booleans. Listed in the issue.

Tested on CoreOS + VirtualBox + Vagrant and Centos + Virtualbox +Vagrant

Thanks, @stephenrlouie ! LGTM.

authors: rutsky stephenrlouie


text:
Fixed godeps

godep restore
godep save ./...

LGTM

authors: mwielgus piosz

repo: kubernetes/heapster


text:
X-Real-IP and X-Forwarded-For missing

I've upgraded from 0.9.0-beta5 to beta 7 and I don't see any X-Real-IP or X-Forwarded-For-Header anymore.
beta5:
Host: hostname.foo
X-Real-IP: 79.192.218.180
X-Forwarded-For: 79.192.218.180, 79.192.218.180
X-Forwarded-Host: hostname.foo
X-Forwarded-Port: 443
X-Forwarded-Proto: https
X-Original-URI: /
X-Scheme: https

beta 6/7:
Host: hostname.foo
X-Forwarded-Host: hostname.foo
X-Forwarded-Port: 443
X-Forwarded-Proto: https
X-Original-URI: /
X-Scheme: https

SSL is terminated by an AWS ELB. No proxy protocol is used.

I am working in adding e2e test to the ingress controller in order to avoid all this regressions we are having. https://github.com/kubernetes/ingress/pull/801

I am using quay.io/aledbf/nginx-ingress-controller:0.132 and seem to get X-Real-IP alright.

@weitzj negative, I can't confirm that. I tried, and passing X-Forwarded-Proto: https still results in both X-Forwarded-For and X-Real-IP being swallowed with that image. Which makes sense since the map statements haven't been touched: https://github.com/kubernetes/ingress/compare/nginx-0.9.0-beta.7...master#diff-b7803798d356c6c17a90d93cc58bdbaa

@totallyunknown please update the image to quay.io/aledbf/nginx-ingress-controller:0.148

Closing. Please reopen if you still have issues

The fix is in master https://github.com/kubernetes/ingress/blob/master/controllers/nginx/rootfs/etc/nginx/template/nginx.tmpl#L138 and included in the PR for 0.9.0-beta-9

PR https://github.com/kubernetes/ingress/pull/905

Thanks, I've took a look into the Changelog and #890 isn't listed - that why I was asking.

@totallyunknown sorry, the issues are not sorted https://github.com/kubernetes/ingress/pull/905/files#diff-2b00570d6a55cbb418bfb30203d59114R25

authors: aledbf andor44 totallyunknown weitzj

repo: kubernetes/ingress


text:
Add support for 'worker-shutdown-timeout'

When reloading the configuration or gracefully shutting down, Nginx waits 10secondes for the workers to exit.
It would be great if we could configure this value through the ConfigMap as it implicitely determines how long we are waiting for open connections to close.

This change is

Coverage increased (+0.007%) to 43.9% when pulling d9e7d1eabcc1ca689c2b396c2832b3495faae00f on maxlaverse:worker_shutdown_timeout into 7844415cffc83da46eaf022e3cc3f2c3df6f3c16 on kubernetes:master.

/lgtm

@maxlaverse thanks!

authors: aledbf coveralls k8s-reviewable maxlaverse


text:
ClusterLoader - main

Main file for cluster loader.

/assign shyamjvs

It seems like gofmt is failing in the presubmit:
!!! 'gofmt -s' needs to be run on the following files:
./clusterloader2/cmd/clusterloader.go

Will lgtm once that's fixed.

/lgtm

authors: krzysied shyamjvs

repo: kubernetes/perf-tests


text:
Fix typo in the warning message

Line 139: at leaste->at least

/assign @mikedanese

/lgtm
/ok-to-test

authors: AdamDang wojtek-t


text:
Stale metrics reference

This is a Bug Report

Problem:
The metrics reference at https://kubernetes.io/docs/reference/instrumentation/metrics/ has not been fully updated for the v1.26 release.
Proposed Solution:
Update https://kubernetes.io/docs/reference/instrumentation/metrics/ based on the generator code (which is not yet documented).
Page to Update:
https://kubernetes.io/docs/reference/instrumentation/metrics/

Additional Information:
/sig instrumentation
If you are not sure how that page is managed and updated, it's OK to pick a different issue to work on - here's a list of good candidates.

/assign @logicalhan
/triage accepted

/close

authors: dashpole sftim

repo: kubernetes/website


text:
[hi] Translate concepts/architecture/cgroups into Hindi

The cgroup v2 page is available in English and Chinese. Still, This term also needs to be Localized into Hindi for the people who want to read this page in Hindi.
Link: https://kubernetes.io/docs/concepts/architecture/cgroups/

Will be fixed by #36185

/triage accepted

/language hi

/assign

/triage accepted


text:
DisableAcceleratorUsageMetrics has been removed

https://kubernetes.io/docs/concepts/cluster-administration/system-metrics/#disable-accelerator-metrics
The DisableAcceleratorUsageMetrics feature gate disables metrics collected by the kubelet, with a timeline for enabling this feature by default.

According to the documentation the "DisableAcceleratorUsageMetrics" feature gate has already been removed, so the section "Disable accelerator metrics" needs to be updated.

/assign @pegasas

authors: nnlkcncff pegasas


text:
Fix monitor node health "running as a cluster addon" link error

Fixes #10164
Signed-off-by: Yuanbin.Chen cybing4@gmail.com

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Please delete this note before submitting the pull request.
For 1.12 Features: set Milestone to 1.12 and Base Branch to release-1.12
Help editing and submitting pull requests:  https://deploy-preview-9510--kubernetes-io-master-staging.netlify.com/docs/contribute/start/#submit-a-pull-request.
Help choosing which branch to use, see
https://kubernetes.io/docs/contribute/start#choose-which-git-branch-to-use.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

/assgin @tengqm


text:
Fix StorageObjectInUseProtection format in doc

Fix StorageObjectInUseProtection format to follow other admission controllers in doc.

I signed it

/lgtm
/approve

authors: LipingMao tengqm


text:
Changed Spellings For The Hindi Documentation

Changed "कुबरनेट्स" to "कुबरनेटिस"
Both terms have different pronunciations.
Before:
कुबरनेट्स : Pronunciation goes like koo-bar-ne-tas
After:
कुबरनेटिस : Pronunciation goes like koo-bar-ne-tis

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Remember to delete this note before submitting your pull request.
For pull requests on 1.15 Features: set Milestone to 1.15 and Base Branch to dev-1.15
For pull requests on Chinese localization, set Base Branch to release-1.14
For pull requests on Korean Localization: set Base Branch to dev-1.14-ko.<latest team milestone>
If you need Help on editing and submitting pull requests, visit:
https://kubernetes.io/docs/contribute/start/#improve-existing-content.
If you need Help on choosing which branch to use, visit:
https://kubernetes.io/docs/contribute/start#choose-which-git-branch-to-use.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

I have completed the CLA Process and have signed the agreement successfully. Please check it.

/lang hi

/language hi

Hello @ShivamPandya,
I suggest you take a look at Kubernetes Hindi-language team glossary https://docs.google.com/spreadsheets/d/1UmL4K0v4yaN34k4WzYDZBobLBp5OZQp4GCTi28AfwQM/edit?usp=sharing

कुबरनेट्स: Pronunciation goes like koo-bar-ne-tas
After:
कुबरनेटिस: Pronunciation goes like koo-bar-ne-tis

As you have suggested that the spellings are incorrect as it spells incorrectly.
I understand that, but it's not always the case, the Hindi language can be a bit tricky in those scenarios when it comes to the actual word and the way we write is different.
Even if you speak the word Kuberntes word aloud, you will notice that a in tas become silent.

Hello @ShivamPandya,
I suggest you take a look at Kubernetes Hindi-language team glossary https://docs.google.com/spreadsheets/d/1UmL4K0v4yaN34k4WzYDZBobLBp5OZQp4GCTi28AfwQM/edit?usp=sharing

कुबरनेट्स: Pronunciation goes like koo-bar-ne-tas
After:
कुबरनेटिस: Pronunciation goes like koo-bar-ne-tis

As you have suggested that the spellings are incorrect as it spells incorrectly.
I understand that, but it's not always the case, the Hindi language can be a bit tricky in those scenarios when it comes to the actual word and the way we write is different.
Even if you speak the word Kuberntes word aloud, you will notice that a in tas become silent.

I am not sure about the a in tas becoming silent . kubernetes is pronounced /koo-ber-nay'-tace/ and means "sailing master".... we may need to update this document https://docs.google.com/spreadsheets/d/1UmL4K0v4yaN34k4WzYDZBobLBp5OZQp4GCTi28AfwQM/edit?usp=sharing accordingly.

/uassign

/assign @Rajakavitha1 @daminisatya

Hello @ShivamPandya .
Because this pull request has been open for an extended time, I plan to close it.
You can reopen the PR to continue to work on the changes.
/close

authors: Rajakavitha1 ShivamPandya jimangel kbhawkey mittalyashu stewart-yu


text:
Ensure that the load test uses current namespace

Hi All,
Recently I created a pull request to enhance another area of the documentation under https://github.com/kubernetes/website/pull/19603
This request is similar and part of it follows the same principle, making the example, namespace agnostic.
Whilst going through the horizontal pod autoscale walkthrough, and in particular, this section https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/#increase-load
It failed for me when generating the load as it is assumed that the namespace, the example is being run from is 'default'.
This change, will allow the example in this walkthrough to work for any namespace that the walkthrough is run within.  Rather than assuming 'default', the namespace is looked up from the running pod  -
Before -
while true; do wget -q -O- http://php-apache.default.svc.cluster.local; done

After -
while true; do wget -q -O- http://php-apache.$(cat /var/run/secrets/kubernetes.io/serviceaccount/namespace).svc.cluster.local; done

Link to the documentation change for convenience: https://deploy-preview-19901--kubernetes-io-master-staging.netlify.com/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/#increase-load
I hope this helps.  Should it be accepted, I will follow up accordingly with corresponding pull requests for the ZH and KO locales.
Many Thanks
James

/assign @rajakavitha1

Thanks @rajeshdeshpande02
This is good feedback, leave it with me.  Will update accordingly.

@rajeshdeshpande02 - updated as per your feedback
Thanks
James

Hi @rajeshdeshpande02 @DirectXMan12 @fgrzadkowski
For now, I've set this back to WIP.  After making the changes, I thought about this again and I think it may be better to approach this in a different way to that I originally proposed.  To summarise -
Original (Current) -
while true; do wget -q -O- http://php-apache.default.svc.cluster.local; done

PR Proposed -
while true; do wget -q -O- http://php-apache.$(cat /var/run/secrets/kubernetes.io/serviceaccount/namespace).svc.cluster.local; done

This also has the note, as per feedback from @rajeshdeshpande02
New Alternative -
while true; do wget -q -O- http://php-apache; done

The new alternative outlined has the benefit that it will work from any namespace and owing to this, the note becomes un-necessary.  The corresponding locale changes are also simplified and easier to implement owing to their being no language translations involved.
I'm more than happy to re-do the PR commit if you agree that this is a better approach.
Thanks
James

Closing this pull request and will re-raise as a new request, with the alternative approach.   Thanks all.


text:
update chinese page certificates.md

Update chinese page certificates.md. Correct a wrong link which direct to English version page

/lgtm
/approve


text:
Translate docs/concepts/containers/images into Japanese

Closes #22905

/assign @inductor

<li>などの箇条書き（markdownだと-や1.など）の場合は不要であれば文末の。は付けない（原文でも.がないです）
通例だと箇条書きの中は「だ・である調」になってるかと思いますので、合わせていただけますと！

@inductor
リストの表現も箇条書きにし、文末の「。」を削除しました。
リスト表現部分でも２つの文章で構成されている部分については、最初の文の。は残してました。
文章の区切れがわかるように残してます。以下が例です。
1. クラスターに独自仕様でない(例えば、オープンソース)イメージだけを実行する。イメージを非公開にする必要がない

L37までみました

レジストリの訳ミスが他にもあったので全部修正し、
もう一度全体をみて、言葉のおかしい部分を再チェックしました。
箇条書きの「です・ます調」、「である調」の件は、どうしましょうか？
個人的には「である調のほう」がスッキリ見えるとは思います。

箇条書きはだ・である調派です。

一通り見てコメント書きました！

レビューの結果を反映し、マニフェストに統一しました。

修正ありがとうございます。
/lgtm

/approve

authors: inductor kakts takaf04


text:
docs: Add README to Solve Too Many Openfiles in MacOS

This should solve #22895

@zacharysarah solved 👌

/lgtm
/approve

authors: irvifa zacharysarah


text:
Update incorrect links

Resolves #27550
Resolves #27552

/kind cleanup

/retitle Update incorrect links

I rebased and force-pushed.
Direct links to the preview:

https://deploy-preview-27554--kubernetes-io-master-staging.netlify.app/blog/2020/12/08/kubernetes-1-20-release-announcement/#exec-probe-timeout-handling
https://deploy-preview-27554--kubernetes-io-master-staging.netlify.app/docs/concepts/workloads/controllers/job/
https://deploy-preview-27554--kubernetes-io-master-staging.netlify.app/docs/setup/production-environment/container-runtimes/#migrating-to-the-systemd-driver-in-kubeadm-managed-clusters
https://deploy-preview-27554--kubernetes-io-master-staging.netlify.app/docs/setup/production-environment/windows/intro-windows-in-kubernetes/#windows-os-version-support
https://deploy-preview-27554--kubernetes-io-master-staging.netlify.app/docs/tasks/administer-cluster/enabling-topology-aware-hints/#enable-topology-aware-hints
https://deploy-preview-27554--kubernetes-io-master-staging.netlify.app/docs/tasks/administer-cluster/kubeadm/configure-cgroup-driver/#configuring-the-kubelet-cgroup-driver
https://deploy-preview-27554--kubernetes-io-master-staging.netlify.app/docs/tasks/job/indexed-parallel-processing-static/#before-you-begin

Thanks @jihoon-seo .
/lgtm

/approve

authors: jihoon-seo kbhawkey


text:
Add the search box and the toggle section navigation

✅ Resolves #20895.
📄 Page preview: https://deploy-preview-27689--kubernetes-io-master-staging.netlify.app/blog/
Search box
This PR adds the search box to the blog page.
Screenshot:

Toggle button
Also, this adds the toggle button on the right of the search box for the mobile page. Clicking the button expands the navigation menu. It's the same as the documentation pages.
Screenshot:

How to test

Open the blog page (https://deploy-preview-27689--kubernetes-io-master-staging.netlify.app/blog).
Test search functionality with keywords you like.
Change to the mobile view.
Test search again.
Tap the toggle button and confirm to show the Table of Contents of the page.

/assign @kbhawkey

Hi @shuuji3 . The search bar looks good!
I viewed a blog page, reducing the window to about mobile size. The inner hamburger works, but when the page is displayed after the left navigation, the title for the blog page runs over the left nav (2021, 2020, 2019, ...).
I have not had time to look into the cause of the overflow.
Thanks!

@kbhawkey Thank you for reviewing!🙂  Although the issue didn't happen on the top page of the blog, I can also replicate the behavior when clicking the inner hamburger on each post page.

OK, I'd like to investigate the cause of this issue by my side.

I also found an similar issue on the left bottom of the navbar on the desktop

view.

The issue should be fixed now.
mobile view:

desktop view:

One style setting in the main.sccs is the cause of this issue. That style is needed to adjust the height of the navbar because the search bar didn't exist on the blog pages.

/area web-development

/sig blog

Hi @shuuji3 .
I looked at the changes again. Thanks for the updates.
I think it is worthwhile to get someone from the blog project to look over these changes.
The inner hamburger color should be the site's blue color and change colors when you hover?
Otherwise, LGTM. Thanks!
/lgtm

/area blog

@kbhawkey I investigated the issue of the inner hamburger color and fixed it. Sorry, could you take a look at it again?
The cause of the issue was the awesome font JavaScript file. It is loaded only on the blog page and replaces the hamburger <button> element with the <svg> equivalent. The style was only applied to the <button> hamburger, so I modified the style so that the style applies to both <button> and <svg> hamburger.

Looks good!
/lgtm


text:
[ko] Update content/ko/docs/concepts/services-networking/

refs #30000 tasks M23, M24, M25 and M26

@seokho-son 감사합니다. 의견 반영해서 squash 했습니다.

/assign

감사합니다!
/lgtm
/approve

authors: gochist seokho-son


text:
Update labels.md

add a new line between listing and other section

Thanks.
/lgtm
/approve

authors: soul-craft tengqm


text:
[ko] Update outdated files in dev-1.26.-ko.1 [M24-26]

from #38458
I have updated some of the outdated contents in dev-1.26-ko.1 branch.
Full changes in the original english content can be checked with this comparison.
Updated Files

[x] M24. content/en/docs/concepts/extend-kubernetes/api-extension/_index.md | 1(+XS) 1(-)
[x] M25. content/en/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation.md | 22(+S) 7(-)
[x] M26. content/en/docs/concepts/extend-kubernetes/api-extension/custom-resources.md | 87(+M) 46(-)

/assign

@bugoverdose , 리뷰가 늦었습니다.
앞선 2개의 파일은 문제가 없으나, 마지막 수정사항인 docs/concepts/extend-kubernetes/api-extension/custom-resources.md 파일의 경우 전체 줄바꿈 문제로 영문파일의 라인수와 한글파일의 라인수가 불일치 하고 있습니다.
https://github.com/kubernetes/website/blob/dev-1.26-ko.1/content/en/docs/concepts/extend-kubernetes/api-extension/custom-resources.md?plain=1
링크 참고하셔서 줄바꿈 등으로 전체 라인을 맞춰주시면 감사하겠습니다.

@bugoverdose , 리뷰가 늦었습니다. 앞선 2개의 파일은 문제가 없으나, 마지막 수정사항인 docs/concepts/extend-kubernetes/api-extension/custom-resources.md 파일의 경우 전체 줄바꿈 문제로 영문파일의 라인수와 한글파일의 라인수가 불일치 하고 있습니다.
https://github.com/kubernetes/website/blob/dev-1.26-ko.1/content/en/docs/concepts/extend-kubernetes/api-extension/custom-resources.md?plain=1
링크 참고하셔서 줄바꿈 등으로 전체 라인을 맞춰주시면 감사하겠습니다.

반영했습니다. a387fa8
짧은 문장도 약간 억지로 줄 수를 늘려가면서 전체적인 라인수만이 아니라 문단별로 라인수를 완전히 일치시켰습니다

@bugoverdose , 리뷰가 늦었습니다. 앞선 2개의 파일은 문제가 없으나, 마지막 수정사항인 docs/concepts/extend-kubernetes/api-extension/custom-resources.md 파일의 경우 전체 줄바꿈 문제로 영문파일의 라인수와 한글파일의 라인수가 불일치 하고 있습니다.
https://github.com/kubernetes/website/blob/dev-1.26-ko.1/content/en/docs/concepts/extend-kubernetes/api-extension/custom-resources.md?plain=1
링크 참고하셔서 줄바꿈 등으로 전체 라인을 맞춰주시면 감사하겠습니다.

@ysyukr 반영했습니다. a387fa837cc20a74e75aaf91461095bae0e4c027
짧은 문장도 약간 억지로 줄 수를 늘려가면서 전체적인 라인수 & 문단별 라인수를 완전히 일치시켰습니다

@bugoverdose 고생하셨습니다.
/lgtm

컨벤션인 것 같아서 커밋 하나로 합쳤습니다.

72549f240a9532fabab3a5192b47a1b7d83454e4

@bugoverdose 감사합니다.
/approve

authors: bugoverdose ysyukr


text:
[zh] sync /setup/production-environment/_index.md

Sync with en text:
content/zh-cn/docs/setup/production-environment/_index.md

/lgtm
/approve

authors: tengqm windsonsea


text:
[es] Add concepts/storage/windows-storage.md

Se añadió la documentación en español para las sección: content/es/docs/concepts/storage/windows-storage.md
Agradecería puedan revisarlo y darme feedback. Wohoo!!!! 🕺🏼
Gracias! :)
Closes #43791

/assign @electrocucaracha @krol3

/retest

/retest

Solo una sugerencia pendiente.

Se me fue, muchas gracias! :)

/lgtm

Great! Thanks @edithturn
/lgtm
/approve

Great! Thanks @edithturn /lgtm /approve

Wohoo! Thank youuu!!!

authors: edithturn electrocucaracha ramrodo


text:
Set (partial) release information for v1.31

Set the v1.31 release branch to be for Kubernetes v1.31
This change does not cover /data/releases, which also needs doing.
/sig release

Not a change to the live site, but I'd prefer not to approve this one myself.
@katcosgrove @tengqm @salaxander PTAL

This is step 6 under "Ensure Access is Set Up" in the the Release Team's Docs handbook timeline
/approve

authors: reylejano sftim


text:
Remove unused autoscaling files.

This change is

/assign @heckj

/lgtm