text:
Trefferpunkte Wurf resultiert in 0 TP

Wenn man durch Wuchtschläge/Ansagen Bonusschaden an der Funktion "Trefferpunkte" zurechnen möchte,
resultiert dies in einem 0 TP Wurf.
Aber nur wenn man ein + vor den Bonusschadenwert setzt. (Soweit ich das sehen kann in der Rechnung fehlt da eine Klammer)
Lässt man das + weg ist alles in Ordnung.
Das ist soweit ich das sehen kann überall so, ob Nah-, Fern- oder Schildtreffer.

Rechnung wenn man stattdessen "4" eingibt.

Das hast du ganz richtig erkannt: Diese Formel habe ich noch nicht robust gemacht, indem eine Klammer um den TP-Bonus/Malus eingefügt wird. Danke für's Melden :)

Yes!!
War mir nicht 100% sicher. Die Formate von Roll20 sind leider noch bissl Böhmische Dörfer für mich.

authors: kreuvf renkash


text:
Could you support Join Monster instead of "dataloader"?

This
http://join-monster.readthedocs.io/en/latest/
best regards

Thanks for the suggestion. It was open for too long, closing for now.

source: gharchive/issue

authors: MichelDiz koistya

repo: kriasoft/nodejs-api-starter

license: mit

license_type: permissive

license_source: bigquery


text:
Testing null value

Hello guys, I am trying to test if a node exist or not.
local d = js.global.document:getElementById("test")
print(d) -- return null
if d then
  print(d.innerHTML) -- return Uncaught Lua.Error: TypeError: Cannot read property 'innerHTML' of null
end

In my page the id test doesn't exist but the if is always executed. How do you check for null and/or undefined value from lua code ?

How do you check for null and/or undefined value from lua code ?

null you need to compare to js.null.
undefined is the same as nil

Thanks again for your help.
I have others interrogations about the tables etc.
Is there a better way to question/discuss then issue because it's potentially not an issue.
Or is there any good samples of implementation or documentation ?

I have others interrogations about the tables etc.
Is there a better way to question/discuss then issue because it's potentially not an issue.

I'm happy to answer questions via github issues; this way I can refer others to them.
You can also find me on irc with the same username (on freenode and oftc) if you have a quick question.

Or is there any good samples of implementation or documentation ?

Sorry we're a bit light on documentation.
I'm not happy with how lua.vm.js leaks memory via proxys; and solving it may require a full overhaul.

authors: MangelMaxime daurnimator


text:
[GCE] Allow port 443 for API server access in firewall during setup

Refer https://github.com/kris-nova/kubicorn/issues/328#issuecomment-324459998

I think there may be 2 things here:

The kubelet is trying to talk to the apiserver using the apiserver's public IP address (i.e. the external IP of the VM). Would it make more sense to have the kubelet talk to the VM's internal IP?
If you want to access the apiserver from outside of GCE (e.g. on your laptop), then yes, the GCE firewall does need to allow you to talk to port 443

Regarding point one:
Where already using the internal ip, check here. Are there any specific error you can show us?
Regarding point 2 this should not be a problem by default. GCE has a few firewall rules by default that can be applied to instance. This is being done here and here and is working for me. There could be custom firewall rules that break this.
So ATM it looks like this is not a problem. @prateekgogia @ncdc can you guys check if your still seeing this problem with the new changes from #326?

authors: MyDigitalLife ncdc prateekgogia

repo: kris-nova/kubicorn


text:
Unable to start correctly

Hi and Thanks for the efforts!
I have a problem starting the docker.
I tried lunching it but got the following error in logs:
Starting Virtual DSM for Docker v3.34...
/run/network.sh: line 144: /usr/sbin/dnsmasq  --dhcp-range=20.20.20.21,20.20.20.21 --dhcp-host=02:11:32:AA:BB:CC,,20.20.20.21,VirtualDSM,infinite --dhcp-option=option:netmask,255.255.255.0 --dhcp-option=option:dns-server,127.0.0.11 --dhcp-option=option:router,20.20.20.1 --dhcp-option=option:domain-search,lan --dhcp-option=option:domain-name,lan: File name too long

And the docker is restarting constantly.
Tried without macvlan and with. The same result.

Yes!
Thank you!

repo: kroese/virtual-dsm

license: MIT

license_source: github-api


text:
Natalie breaks when using IBAnimatable

I'm not even sure if a fix is possible since it's caused by a third party dependency. But I get build errors when Natalie generates code for a view controller that is subclassed from AnimatableViewController of IBAnimatable

what kind of errors? can you make an example project?

Here is a blank project with IBAnimatable and Natalie. See if you get the error:
IBAnimatableNatalieError.zip

/Users/cupojoe/Code_Repos/NatalieError/IBAnimatableNatalieError/IBAnimatableNatalieError/Storyboards.swift:239:9: Property 'storyboardIdentifier' must be declared public because it matches a requirement in public protocol 'IdentifiableProtocol'

one more question. do you use master branch, or last release? I should do the release with the latest fixes

We are using the release of IBAnimatable (Cocoa Pods) and the master of Natalie, built from source.

the code is
output += "extension IdentifiableProtocol where Self: \(customClass) {\n"
if viewController.customModule != nil {
       output += "    var storyboardIdentifier: String? { return \"\(storyboardIdentifier)\" }\n"
} else {
       output += "    public var storyboardIdentifier: String? { return \"\(storyboardIdentifier)\" }\n"
}

customModule is not nil (because of IBAnimatable module is used)
I do not remember why there is this two case

duplicate of new one with more information #124

authors: cupojoe krzyzanowskim phimage waltermvp

repo: krzyzanowskim/Natalie


text:
Final_Project

＃１ － 시작 및 첫번째 방정식 사용

＃２ － 두번째 방정식 사용

＃３ － ３번째 방정식 사용

＃４ － 종료

@swcho84


text:
Remove unused security event permission and vulnerability scanning steps

This pull request removes the unused security event permission and vulnerability scanning steps from the workflow. These steps were no longer necessary and were causing unnecessary complexity in the workflow.
#36

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 91.76%. Comparing base (5d8f3b5) to head (ff21d5c).

Additional details and impacted files
@@           Coverage Diff           @@
##             main      #37   +/-   ##
=======================================
  Coverage   91.76%   91.76%
=======================================
  Files          21       21
  Lines         522      522
=======================================
  Hits          479      479
  Misses         25       25
  Partials       18       18

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

source: gharchive/pull-request

authors: codecov-commenter ksysoev

repo: ksysoev/deriv-api-bff


text:
Better detection of travis-ci vs pro

Currently if there is an env variable for repo token, plugin assumes it is travis-pro. This is not entirely correct. Since I have some integration tests, I am sending jacoco reports from my computer, not from travis. For this I need the env variable to be set, and yet I am using travis-ci not pro.

I have this problem too. The problem can be easily solved if coveralls-gradle-plugin doesn't ignore the environment variables for the serviceName which is CI_NAME. AS you can see, it is not used at all. So I think the CI_NAME should be also checked here and used here.

I've just uploaded the fixed one to my bintray repo and it works. Now I can see Coveralls's test coverage results.
If you want to test it, add the following info accordingly in your build.gradle.
buildscript {
  repositories {
    jcenter()
    mavenCentral()
    maven {
      url  "http://dl.bintray.com/kevinlee/maven"
    }
  }
  dependencies {
    classpath 'org.kt3k.gradle.plugin:coveralls-gradle-plugin:2.3.2'
  }
}

authors: Kevin-Lee igorspasic


text:
jmh:compile doesnt work with 0.2.3 ?

We didn't change any code just upgraded to 0.2.3. Did we miss any step ?
java:9: package org.openjdk.jmh.annotations does not exist
[error] org.openjdk.jmh.annotations.CompilerControl

java:10: package org.openjdk.jmh.runner does not exist
[error] org.openjdk.jmh.runner.InfraControl

java:11: cannot find symbol
[error]   symbol:   class ThreadParams
[error]   location: package org.openjdk.jmh.infra
[error] org.openjdk.jmh.infra.ThreadParams

java:12: package org.openjdk.jmh.results does not exist
[error] org.openjdk.jmh.results.BenchmarkTaskResult

java:13: package org.openjdk.jmh.results does not exist
[error] org.openjdk.jmh.results.Result

java:15: package org.openjdk.jmh.results does not exist
[error] org.openjdk.jmh.results.AverageTimeResult

Hm, the project is tested using latest and we've also upgraded to it in Akka...
Is there any more details you could share? I'll look into it a bit later.

Thanks ! Few weeks back we upgraded to 0.2.2, that time there were no issues at all. We were using run and compile.
Until we upgraded yesterday (after seeing it in the Akka bench project). immediately noticed run needs to change to jmh:run and compile for jmh:compile. I tried clean ensured the .ivy2 caches with only proper version

Thanks for the hints, I don't see yet what might have gone wrong but will have a look. I'll keep you posted in this ticket.

One way to get around the issue was to add enablePlugins(JmhPlugin) to the root project in the build.sbt. Out benchmarks are not in the root project. This is not the case for 0.2.1 though it works fine.

Thanks a lot for the info! I'm a bit overwhelmed with tasks at the moment,
will try to investigate deeper as soon as I can. Thanks again for the
additional info, this helps a lot
On Aug 20, 2015 22:45, "Debajyoti Roλ" notifications@github.com wrote:

One way to get around the issue was to add enablePlugins(JmhPlugin) to
the root project in the build.sbt. Out benchmarks are not in the root
project. This is not the case for 0.2.1 though it works fine.
—
Reply to this email directly or view it on GitHub
https://github.com/ktoso/sbt-jmh/issues/57#issuecomment-133164958.

I'm having the same issue.
I've got a public repo in which you can reproduce this, if you haven't been able to.

Check out: https://github.com/japgolly/nyaya.git It uses sbt-jmh 0.2.2.
sbt benchmark/run. :star2: Everything works.
Change the version in project/plugins.sbt to 0.2.4.
sbt benchmark/run :boom:
sbt benchmark/jmh:run :boom:
sbt benchmark/jmh:compile :boom:

I suggest you upgrade first - there's really no reason to stay on a old version like that, we're currently at 2.11.

Note that we don't guarantee any more compatibility than JMH does, please refer to JMH documentation and release notes for migrating up

authors: japgolly ktoso roy-collective

repo: ktoso/sbt-jmh


text:
Bug search field on IE

Search field to facilitate the search for options until the ok time:
Firefox (ok)
Chrome (ok)
With problems:
Internet Explorer (is being fixed, for v1.1.1)

IE loses reference to the <li>  cached when we clear the list, then in IE and modal options will be filtered through the element visibility.
However, if liability to optimize the specific code, will soon in the next versions

repo: ktquez/pickout


text:
About the F30K dataset

I would like to ask you, is this the target feature data set obtained from the F30K data through the bottom-up attention model?

Yes. Image features extracted from faster r-cnn are included in the links provided by the authors

repo: kuanghuei/SCAN


text:
Pods and Deployments get recreated after 16h

Hello,
Following up on #471, is there way to deactivate this behavior or set it to a longer period?
We have some long running tasks >24hours, that are retried when a pods get terminated, creating an endless loop.

@zypriafl You have two upgrade processes that happen.
The OS and k3s. In your case, you may need to turn both off!
You can turn both off using different methods, see https://github.com/kube-hetzner/terraform-hcloud-kube-hetzner#turning-off-automatic-upgrade

Thanks for your help.

authors: mysticaltech zypriafl


text:
kube-vip to install VIP between clusters located in two different geographical locations

Is your feature request related to a problem? Please describe.
I have two sets of kubernetes clusters locates in two different regions with kube-vip installed on each cluster. I want use one of the clusters as an Active cluster and the other as a Standby cluster by using keepalived but that is not working as expected.
Describe the solution you'd like
I want kube-vip to assign a VIP to the control plane nodes of the Active cluster and when they fail the same VIP needs to be assigned to the control plane nodes of the Standby cluster. This way I want to achieve HA using kube-vip.
Describe alternatives you've considered
I have tried keepalived to drive the traffic between the VIPs of both the clusters but it is not successful.
Additional context
It would be very helpful if the VIP is assigned to one of the clusters based on some custom parameters like the latency etc

Old issue, closing. (please re-open if this is still a problem)

authors: reddybhavaniprasad thebsdbox

repo: kube-vip/kube-vip


text:
using random kubearmor GRPC server port

Feature Request
Short Description
Currently, the GRPC server port [is a configuration](https://github.com/kubearmor/KubeArmor/blob/bf39613c0c01e986d3e77d2f46a59c526cbf5907/KubeArmor/config/config.go#L79) and the default value is 32767.
This works fine on kubearmor in k8s mode where kubearmor is operating as a pod and the listen ports are deterministic within the pod.
However, in case of systemd/host-process mode of operation, it is possible that port 32767 might have been in use by some other process on the host and if it is in use, the kubearmor startup will fail.
Requirement of this task:

[ ] Ability to specify 0 as the GRPC port configuration in which case the bind should happen on the random port.
[ ] This port information should be kept in a pid file.
[ ] karmor cli tool will check for this pid file in case of k8s=false env and pick the port information from there to connect.

Is your feature request related to a problem? Please describe the use case.
It is possible that in systemd mode of invocation the port 32767 on the host is already in use. In such cases, kubearmor fails to start because of "address already in use" error.
Describe the solution you'd like

Ability to specify 0 as the GRPC port configuration in which case the bind should happen on the random port.
This port information should be kept in a pid file.
karmor cli tool will check for this pid file in case of k8s=false env and pick the port information from there to connect.

Describe alternatives you've considered
For pid file, check what is the appropriate location to keep the pid file.

@nyrahul is it better to use a user-defined port rather than a random port?
The port is configurable. Do we still need to support a random port too?

@nyrahul is it better to use a user-defined port rather than a random port? The port is configurable. Do we still need to support a random port too?

For systemd/host-process mode it is problem ... I have seen kubearmor failing due to port already in use several times (yesterday it happened with @daemon1024 during office hours demo) ... The user might not be able to understand the problem. I was thinking may be we could reduce this friction.

hello @nyrahul, I would like to try working on this issue

k8s=false

currently I am working on the karmor cli tool, I am not really sure where can I get this env or variables, should I add another flag for k8s env on the karmor log command? or where can I find this?

@nthnieljson Maybe we should just add this to the existing check without adding another flag.
https://github.com/kubearmor/kubearmor-client/blob/fb7ebec2070e21a2ee7d6df1e3213b767ccb4975/log/log.go#L48-L54
We should add another check to check for the pid file in opt/kubearmor/ directory, since that's where the files exist when KubeArmor runs in systemd mode ( Ref https://github.com/kubearmor/KubeArmor/blob/main/getting-started/kubearmor_vm.md )

okay, thanks for the guide!

I have submitted pull requests regarding this issue, please kindly review. Thanks

authors: daemon1024 nam-jaehyun nthnieljson nyrahul

repo: kubearmor/KubeArmor


text:
add Impl for llm edge benchmark suite

What type of PR is this?
/kind feature
What this PR does / why we need it:
add Impl for llm edge benchmark suite
Which issue(s) this PR fixes:
https://github.com/kubeedge/ianvs/pull/127

@hsj576 Could you please review this PR? I've made several documentation and configuration updates:

Comment cleanup in basemodel.py
Configuration parameter adjustments
Documentation improvements in README, including remove chinese part

Here's  screenshot of the benchmark ：

The results show the changes are working as expected,
Let me know if you need any additional information or clarification.

@MooreZheng I have already addressed this concern by squashing all commits into a single commit using rebase. The changes are now consolidated into one cohesive commit for better maintenance and clearer history. Please review the updated changes.

/lgtm

@XueSongTap might need one more review from @hsj576

/lgtm

/lgtm

@MooreZheng hi, i've changed print() using logger. Could you please review this PR? Let me know if you need any additional information or clarification.

/lgtm

/approve

authors: CreativityH MooreZheng XueSongTap hsj576

repo: kubeedge/ianvs


text:
How to build kubefirst with GitHub flavor?

Documentation for current install of kubefirst with Github flavor:
Build and Install
Required flags:
export KUBEFIRST_GITOPS_BRANCH='main' --> can be replaced by the --gitops-branch flag in the init command.
export KUBEFIRST_METAPHOR_BRANCH='main' --> can be replaced by the --metaphor-branch flag in the init command.
export KUBEFIRST_AWS_NODES_SPOT='true' --> can be replaced by the --aws-nodes-spot flag in the init command.
export GITHUB_AUTH_TOKEN='...' # Personal GitHub token

Optional flags:
export KUBEFIRST_S3_SUFFIX='...' --> can be replaced by the --s3-suffix flag in the init command.
export KUBEFIRST_CLUSTER_NAME='...' --> can be replaced by the --cluster-name flag in the init command.

PS: The following commands must be run from the Kubefirst root directory.
To build the application:
go build -ldflags="-X github.com/kubefirst/kubefirst/configs.K1Version=1.10.1" .

To run the installer with the above environment variables already set:
./kubefirst init --profile default --cloud aws --region $REGION \
    --admin-email $EMAIL --hosted-zone-name $HOSTED_ZONE_NAME \
    --github-user $GITHUB_USER --github-owner $GITHUB_OWNER

To run the installer without the above environment variables (only GITHUB_AUTH_TOKEN):
Note: GITHUB_USER and GITHUB_OWNER must exist before running this command. GITHUB_USER is the owner of  GITHUB_AUTH_TOKEN.
./kubefirst init --profile default --cloud aws --region $REGION \
    --admin-email $EMAIL --hosted-zone-name $HOSTED_ZONE --aws-nodes-spot \
    --cluster-name $CLUSTER_NAME --s3-suffix $S3_SUFFIX --github-user $GITHUB_USER \
    --github-owner $GITHUB_OWNER --metaphor-branch $METAPHOR_BRANCH --gitops-branch $GITOPS_BRANCH

To create kubefirst witth console
./kubefirst cluster create --enable-console

To create kubefirst witthout console
./kubefirst cluster create

SSL Backup
After a few minutes of creating the cluster, it is possible to backup the certificates using the following command:
./kubefirst backupSSL
After executing this command, an S3 bucket will be created in AWS with the name k1-$HOSTED_ZONE_NAME.
On the next install, the init command will look for an existing bucket in the cloud and reuse the certificate backups.
Destroy and Clean
To destroy all resources created by kubefirst create cluster:
./kubefirst cluster destroy

To destroy Github repositories:
./kubefirst action remove-github

To destroy the paths $HOME/.k1, $HOME/.kubefirst and buckets created by kubefirst init:
./kubefirst clean --destroy-buckets --destroy-confirm

To destroy only the paths $HOME/.k1 and $HOME/.kubefirst:
./kubefirst clean

Build and Install
Required flags:
export KUBEFIRST_GITOPS_BRANCH='main' --> can be replaced by the --gitops-branch flag in the init command.
export KUBEFIRST_METAPHOR_BRANCH='main' --> can be replaced by the metaphor-branch flag in the init command.
export KUBEFIRST_AWS_NODES_SPOT='true' --> can be replaced by the --aws-nodes-spot flag in the init command.

Optional flags:
export KUBEFIRST_S3_SUFFIX='...' --> can be replaced by the --s3-suffix flag in the init command.
export KUBEFIRST_CLUSTER_NAME='...' --> can be replaced by the --cluster-name flag in the init command.

PS: The following commands must be run from the Kubefirst root directory.
To build the installer with the above environment variables already set:
go build .
./kubefirst init --profile default --cloud aws --region $REGION \
    --admin-email $EMAIL --hosted-zone-name $HOSTED_ZONE

To build the installer without the above environment variables:
go build .
./kubefirst init --profile default  --cloud aws  --region $REGION \
    --admin-email $EMAIL  --hosted-zone-name $HOSTED_ZONE --aws-nodes-spot \
    --cluster-name $CLUSTER_NAME --s3-suffix $S3_SUFFIX

To create kubefirst witth console
./kubefirst cluster create --enable-console

Build and Install
Required flags:
export KUBEFIRST_GITOPS_BRANCH='main' --> can be replaced by the --gitops-branch flag in the init command.
export KUBEFIRST_METAPHOR_BRANCH='main' --> can be replaced by the metaphor-branch flag in the init command.
export KUBEFIRST_AWS_NODES_SPOT='true' --> can be replaced by the --aws-nodes-spot flag in the init command.
export GITHUB_AUTH_TOKEN='...' # Personal GitHub token

Optional flags:
export KUBEFIRST_S3_SUFFIX='...' --> can be replaced by the --s3-suffix flag in the init command.
export KUBEFIRST_CLUSTER_NAME='...' --> can be replaced by the --cluster-name flag in the init command.

PS: The following commands must be run from the Kubefirst root directory.
To build the installer with the above environment variables already set:
go build .
./kubefirst init --profile default --cloud aws --region $REGION \
    --admin-email $EMAIL --hosted-zone-name $HOSTED_ZONE_NAME \
    --github-user $GITHUB_USER --github-org $GITHUB_ORGANIZATION

To build the installer without the above environment variables (only GITHUB_AUTH_TOKEN):
go build .
./kubefirst init --profile default --cloud aws --region $REGION \
    --admin-email $EMAIL --hosted-zone-name $HOSTED_ZONE --aws-nodes-spot \
    --cluster-name $CLUSTER_NAME --s3-suffix $S3_SUFFIX --github-user $GITHUB_USER \
    --github-org $GITHUB_ORGANIZATION

To create kubefirst witth console
./kubefirst cluster create --enable-console

@marinhojess: are you planning to update the documentation yourself or do you want me to use what you wrote and do it myself?

authors: fharper marinhojess

repo: kubefirst/kubefirst


text:
add thesuperzapper to org

this adds me to the github org as a normal member

/assign @theadactyl

/ok-to-test
/lgtm

/lgtm
/approve

authors: Jeffwan jlewi thesuperzapper

repo: kubeflow/internal-acls


text:
S390x support

Multi-architecture support for model-registry
Description
Updated Dockerfile
Updated Makefile to use buildx for multi-arch image
Updated install_protoc scripts for multi-architecture

@tarilabs I have updated all the changes as you have requested in old PR ( https://github.com/kubeflow/model-registry/pull/62 )

This is the updated PR with all the comments suggested by @tarilabs in old PR https://github.com/kubeflow/model-registry/pull/62

Thank you @modassarrana89 for a refreshed PR including most of the previous comments!
I've dded commit 8bcd792 as I believe necessary for the scripts/install_protoc.sh script to correctly resolve the zip to download when used in a ARM based linux container.
The problem I see in the way this PR currently stands, is that the model-registry is not actually cross-compiled:
In other words: it looks to me model registry get compiled for the platform the build is currently on (in my screenshot, arm), and then the binary copied to linux/arm64,linux/amd64,linux/s390x,linux/ppc64le, which is unlikely to work.
Further, it looks to me cross-compilation would require something ~like this in the dockerfile:
ARG TARGETOS TARGETARCH
RUN CGO_ENABLED=1 GOOS=$TARGETOS GOARCH=$TARGETARCH make clean model-registry

but currently would fail with:
go: cannot install cross-compiled binaries when GOBIN is set

which is used as part of the Makefile.
I believe solutions could be along the lines of:

rework the build to avoid gobin IFF all the remainder buildx problems are solved after accounting for the above
use buildx for emulation rather than cross-compilation
other solution?

I believe a proper reproducible cross-platform build is needed, advise if you believe I might have missed on anything and how planning to solve for the mentioned issues.

Let me quickly test , once & get back on this

Thank you @modassarrana89 for a refreshed PR including most of the previous comments!
I've dded commit 8bcd792 as I believe necessary for the scripts/install_protoc.sh script to correctly resolve the zip to download when used in a ARM based linux container.
The problem I see in the way this PR currently stands, is that the model-registry is not actually cross-compiled:
In other words: it looks to me model registry get compiled for the platform the build is currently on (in my screenshot, arm), and then the binary copied to linux/arm64,linux/amd64,linux/s390x,linux/ppc64le, which is unlikely to work.
Further, it looks to me cross-compilation would require something ~like this in the dockerfile:
ARG TARGETOS TARGETARCH
RUN CGO_ENABLED=1 GOOS=$TARGETOS GOARCH=$TARGETARCH make clean model-registry

but currently would fail with:
go: cannot install cross-compiled binaries when GOBIN is set

which is used as part of the Makefile.
I believe solutions could be along the lines of:

rework the build to avoid gobin IFF all the remainder buildx problems are solved after accounting for the above
use buildx for emulation rather than cross-compilation
other solution?

I believe a proper reproducible cross-platform build is needed, advise if you believe I might have missed on anything and how planning to solve for the mentioned issues.

Let me quickly test , once & get back on this

Below Github action works fine for building & pushing multi - arch image
- name: Build and Push Image
        uses: docker/build-push-action@v3
        with:
          tags: ${{ env.IMAGE_NAME }}:${{ env.TAG }}
          platforms: linux/amd64,linux/s390x,linux/ppc64le
          push: true

If ok , we can update the github workflow for build and push to use this action & then it will automatically solves our problem.

Not seeing / nor understood how the new commit would solve for:
go: cannot install cross-compiled binaries when GOBIN is set

@tarilabs  Below Github action should works fine for building & pushing multi - arch image. Need to verify once . We can use this inplace of the current scripts for multi-arch image build procedure . If you guys are. fine with Github workflow change , I can quickly verify this approach & let you know the update.
- name: Build and Push Image
   uses: docker/build-push-action@v3
   with:
          tags: ${{ env.IMAGE_NAME }}:${{ env.TAG }}
          platforms: linux/amd64,linux/s390x,linux/ppc64le
          push: true

If you guys are. fine with Github workflow change , I can quickly verify this approach & let you know the update

We are looking into removing the GOBIN and local build toolchain, so to support more general multi-arch support, per KF 1.10 roadmap: https://github.com/kubeflow/model-registry/issues/175#:~:text=Multi-arch images - for the Go REST server specifically
We can keep this PR open, to revise this as we will rampup on those items.

If you guys are. fine with Github workflow change , I can quickly verify this approach & let you know the update

We are looking into removing the GOBIN and local build toolchain, so to support more general multi-arch support, per KF 1.10 roadmap: #175
We can keep this PR open, to revise this as we will rampup on those items.

Ok Great. But may i know whats the deadline would be

@tarilabs it would be great if you can share some update on  GOBIN removal  and local build toolchain.

@tarilabs it would be great if you can share some update on GOBIN removal and local build toolchain.

Sure!
We found in general gobin usage and cgo usage giving us some troubles while attempting to instruct for cross-compilation.
There is also another observation that generated source code are re-generated in the docker build phase itself, which is less ideal especially considering we have them already under VCS here in this git repo, in order to point to the actual sources for the bin/image we ship.
We have some contributors actively working on this front for which we can expect some further update, per PRs already iterated on, or being currently worked on right now.

source code are re-generated in the docker build phase itself

we have discussed previously that cross compilation is creating problem with current GOBIN setup. If GOBIN is not an issue , are you saying that cross-compilation will work

we have discussed previously that cross compilation is creating problem with current GOBIN setup. If GOBIN is not an issue , are you saying that cross-compilation will work

as mentioned in https://github.com/kubeflow/model-registry/pull/66#issuecomment-2317177110, gobin looks currently not an impediment to crosscompilation, so we're now looking to keep (gobin usage)
more updates to follow

repo: kubeflow/model-registry


text:
Configure Kubeflow with Amazon RDS

https://www.kubeflow.org/docs/distributions/aws/customizing-aws/rds/
The referenced changes in the ${CONFIG_FILE} are no longer valid, as the ${CONFIG_FILE} has changed.

AWS Distribution of Kubeflow-1.3.1 is live
To learn more about the new features and getting started with new capabilities, please refer to the documentation on Kubeflow.org website: https://www.kubeflow.org/docs/distributions/aws/ and checkout the what’s new under releases: https://github.com/awslabs/kubeflow-manifests/releases/tag/v1.3.1-aws-b1.0.0
For any issues, please refer to the help and feedback section: https://github.com/awslabs/kubeflow-manifests/tree/v1.3-branch#help--feedback
Please find the updated RDS deployment guide here - https://www.kubeflow.org/docs/distributions/aws/deploy/install-kubeflow/#deployment-options
/close

authors: surajkota zoltan-fedor

repo: kubeflow/website


text:
Scheduled functions (cronjobs) leave behind lots of 'trigger-*' jobs

After several days since I deployed a scheduled function in my cluster, there are hundreds of completed trigger Jobs left.
I'm wondering why the default history limit of k8s CronJobs not working?

@ccll I believe you're not running k8s v1.8. See this https://github.com/kubernetes/kubernetes/issues/52390#issuecomment-332654531
So the website says that but it applies for v1.8 and batch/v2beta1 cronjob. We're a bit behind of that as the batch/v2beta1 isn't supported yet. Will be soon :-)

We still should specify the maxJobsHistory for people using v1.7

@ngtuna Thanks, good to know that! k8s online docs are not versioned, so sometimes are misleading.

I am observing that trigger pods getting piled up as well. Any one else see this issue. I used "* * * * *"
trigger-get-python-1511433780-jph6l   1/1       Running       7          31m
trigger-get-python-1511433840-zgb9m   1/1       Running       6          30m
trigger-get-python-1511433900-xkqw7   1/1       Running       7          29m
trigger-get-python-1511433960-74pvf   1/1       Running       6          28m
trigger-get-python-1511434020-7g49d   1/1       Running       5          27m
trigger-get-python-1511434080-rq64v   1/1       Running       5          26m
trigger-get-python-1511434140-4tzw2   1/1       Running       3          25m
trigger-get-python-1511434200-bbrsd   1/1       Running       1          24m
trigger-get-python-1511434260-jdc8b   1/1       Running       0          23m
trigger-get-python-1511434320-qnjvh   1/1       Running       0          22m
trigger-get-python-1511434380-96jt5   1/1       Running       0          20m
trigger-get-python-1511434440-z2txv   1/1       Running       0          20m
trigger-get-python-1511434500-7kshw   1/1       Running       0          19m
trigger-get-python-1511434560-gkppk   1/1       Running       0          17m
trigger-get-python-1511434620-brvwh   1/1       Running       0          17m
trigger-get-python-1511434680-g8v2s   1/1       Running       0          16m
trigger-get-python-1511434740-g2nlr   1/1       Running       0          14m
trigger-get-python-1511434860-tg62r   1/1       Running       0          12m
trigger-get-python-1511434920-lmct8   1/1       Running       0          11m
trigger-get-python-1511434980-57w6b   1/1       Running       0          11m
trigger-get-python-1511435040-2d2h5   1/1       Running       0          9m
trigger-get-python-1511435100-qcmkv   1/1       Running       0          9m
trigger-get-python-1511435160-zn62b   1/1       Running       0          8m
trigger-get-python-1511435220-vb9bc   1/1       Running       0          7m
trigger-get-python-1511435280-2nxkm   1/1       Running       0          6m
trigger-get-python-1511435340-pf5w6   1/1       Running       0          5m
trigger-get-python-1511435400-wt842   1/1       Running       0          4m
trigger-get-python-1511435460-9tst9   1/1       Running       0          3m
trigger-get-python-1511435520-mwrxd   1/1       Running       0          1m
trigger-get-python-1511435580-vjpmv   1/1       Running       0          1m

@murali-reddy that seems to happen when the function failed to be executed. I could reproduce it introducing an error in the get-python function:
scheduled-get-python-5cb5db645c-rj8ps           0/1       Terminating        0          5m
trigger-scheduled-get-python-1511437740-f7dl5   0/1       CrashLoopBackOff   5          5m
trigger-scheduled-get-python-1511437800-zs5h6   0/1       CrashLoopBackOff   5          4m
trigger-scheduled-get-python-1511437860-lqvqh   0/1       CrashLoopBackOff   5          3m
trigger-scheduled-get-python-1511437920-n24zc   0/1       CrashLoopBackOff   4          2m
trigger-scheduled-get-python-1511437980-jv4xf   0/1       CrashLoopBackOff   3          1m
trigger-scheduled-get-python-1511438040-x2cpf   0/1       Error              2          22s

This will keep creating pods due to the restart policy that is set to restart on failure. Seems that is better to set it to never restart the job, what do you think?

Yes. Never restart the job is one possible solution. But this issue has catastrophic effect.

Are we dealing with below job semantics
When a Job completes, no more Pods are created, but the Pods are not deleted either.

I set the restarting policy to Never and added a ActiveDeadlineSeconds so the maximum number of jobs created is controlled.

Fixed with #445

Isn't that the default behavior ?
kubeless creates a CronJob object. On the provided schedule, the CronJob runs the Job (which is a Pod that does not restart).
So every "schedule" you will see a new Job.
What we need to do is add a Job cleanup policy, something that most likely is in the Job schema.
cc: successfulJobsHistoryLimit

ok never mind, that's what your fix does.

authors: andresmgot ccll murali-reddy ngtuna sebgoa

repo: kubeless/kubeless


text:
kube-ovn-controller 在大量 POD 场景下的内存占用异常问题

Expected Behavior
当存在大量 POD 时，占用内存 18G 左右，不知道占用是否正常。
删除 POD 后，占用的内存应该释放。
Actual Behavior
kube-ovn-controller 在大量 POD （1W）场景，占用内存 18G 左右，删除 POD 后，内存未释放。
Steps to Reproduce the Problem

使用 kubemark 创建大量 POD（1W），kubectl top pod 查看你内存如下

删除 POD 后，kubectl top pod 查看你内存如下

删除 POD 后，用 go pprof 分析 heap（IP:PORT/debug/pprof/heap）使用情况，看着好像 POD 缓存已经释放，如下

但是 kubectl top pod 查看内存并没有释放，具体见如下

使用 top 查看 kube-ovn-controller 的内存是正常的

查看 kube-ovn-controller 查看 crgoup 里面 memory.usage_in_bytes 内存异常。理论上 memory.stat 里面的 total_inactive_anon 应该会被自动释放（但是未释放）。

memory.usage_in_bytes 和 oom 有关，可能导致 kube-ovn-controller  被 oom，从而影响集群的稳定性。

Additional Info

Kubernetes version:
Output of kubectl version:
Client Version: version.Info{Major:"1", Minor:"23", GitVersion:"v1.23.6", GitCommit:"ad3338546da947756e8a88aa6822e9c11e7eac22", GitTreeState:"clean", BuildDate:"2022-04-14T08:49:13Z", GoVersion:"go1.17.9", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"23", GitVersion:"v1.23.6", GitCommit:"ad3338546da947756e8a88aa6822e9c11e7eac22", GitTreeState:"clean", BuildDate:"2022-04-14T08:43:11Z", GoVersion:"go1.17.9", Compiler:"gc", Platform:"linux/amd64"}

kube-ovn version:
1.9.2

operation-system/kernel version:
Output of awk -F '=' '/PRETTY_NAME/ { print $2 }' /etc/os-release:
Output of uname -r:
"Rocky Linux 8.5 (Green Obsidian)"
4.18.0-348.el8.0.2.x86_64

十分抱歉，在 “Steps to Reproduce the Problem” 步骤 6 中我写错了。
正确的是只能通过 echo 2 > /proc/sys/vm/drop_caches 释放内存而非 echo 1 > /proc/sys/vm/drop_caches。

我看了下 https://github.com/kubernetes/kubernetes/issues/43916，  应该和这个无关，这个 issue 中讨论的好像关于的是 page cache 的问题。
而我遇到的问题，是 inactive_anon 内存占用异常的问题。

目前看起来是操作系统相关的问题，并未在其他用户那里复现

authors: gugulee oilbeater

repo: kubeovn/kube-ovn


text:
fix: create lr-policy-route for serviceCidr and localDNS

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

What type of this PR
Examples of user facing changes:

Bug fixes

create lr-policy-route for serviceCidr when disable lb.
we had created port-group for all ports on node. like $node.<node_name>_ip4.
we know all serivce-cidr from controller config.
then when lb disabled, create lr-policy-route:
30000 ip4.src == $node.<node_name>_ip4 && ip4.dst == 10.96.0.0/12         reroute                <node-joinipv4>
30000 ip6.src == $node.<node_name>_ip6 && ip6.dst == dd:10:96::/112         reroute             <node-joinipv6>

when we create pod, port of pod will be added to port-group(node.<node_name>_ip4 or node.<node_name>_ip6). then will return to node though join subnet.
Which issue(s) this PR fixes:
Fixes #1789

I was wondering if it has any side effect if enable-lb is true

I was wondering if it has any side effect if enable-lb is true

如果 enable-lb == true, 不会下这几条策略路由；和之前没有区别。
其实如果 enable-lb == true, 下这几条策略路由也不会影响，因为 pod 访问会先到 logical_switch 的 lb，就已经 nat 成 endpoint 的 ip 了。
我想是否可以如下这么做，一起解决 #1277 localdns 的问题。

想法：
无论 enable-lb 是否开启，都在 ovn-cluster 的路由里加 策略路由如下
30000  ip4.src == $node.master_ip4 && (ip4.dst == 10.96.0.0/12 || ip4.dst == 169.254.25.10)         reroute       100.64.0.2

其中 10.96.0.0/12 是 service 的 ip 段
169.254.25.10 是 localdns 的 ip，可以添加配置项来给用户指定
$node.master_ip4 是 在 master 节点的 port-group
100.64.0.2 是 master 节点的 ovn0 ip

如果 pod 访问 service ip，那么在 lgocial_switch lb 就已经 nat 成endpoint ip
如果 pod 访问 localdns，那么会匹配到这条策略路由，然后走 ovn0 到宿主机
如果 enable-lb == false 且 pod 有 eip，那么会匹配这条策略路由，然后走 ovn0 到宿主机，然后 ipvs 或 iptables 做 lb。

@xujunjie-cover Good idea!

need more test. 现在存在一个问题：非默认 subnet 访问 service 时，lb 后到 ovn-cluster 匹配的是 eip 的静态路由，没有到默认子网

@oilbeater  help review
30000  ip4.src == $node.master_ip4 && (ip4.dst == 10.96.0.0/12 || ip4.dst == 169.254.25.10)         reroute       100.64.0.2

其中 10.96.0.0/12 是 service 的 ip 段
169.254.25.10 是 localdns 的 ip，可以添加配置项来给用户指定
$node.master_ip4 是 在 master 节点的 port-group
100.64.0.2 是 master 节点的 ovn0 ip

如果 pod 访问 service ip，那么在 lgocial_switch lb 就已经 nat 成endpoint ip
如果 pod 访问 localdns，那么会匹配到这条策略路由，然后走 ovn0 到宿主机
如果 enable-lb == false 且 pod 有 eip，那么会匹配这条策略路由，然后走 ovn0 到宿主机，然后 ipvs 或 iptables 做 lb。

@oilbeater help review
30000  ip4.src == $node.master_ip4 && (ip4.dst == 10.96.0.0/12 || ip4.dst == 169.254.25.10)         reroute       100.64.0.2

其中 10.96.0.0/12 是 service 的 ip 段
169.254.25.10 是 localdns 的 ip，可以添加配置项来给用户指定
$node.master_ip4 是 在 master 节点的 port-group
100.64.0.2 是 master 节点的 ovn0 ip

如果 pod 访问 service ip，那么在 lgocial_switch lb 就已经 nat 成endpoint ip 如果 pod 访问 localdns，那么会匹配到这条策略路由，然后走 ovn0 到宿主机 如果 enable-lb == false 且 pod 有 eip，那么会匹配这条策略路由，然后走 ovn0 到宿主机，然后 ipvs 或 iptables 做 lb。

看上去没问题

您好，这个能合入吗？

我们前阵子也在做类似的需求，我把默认vpc的策略路由和静态路由也放开了，允许用户可以编辑，我在想策略路由和静态路由是不是统一用vpc的spec 静态路由和策略路由来维护更好一些。

我们前阵子也在做类似的需求，我把默认vpc的策略路由和静态路由也放开了，允许用户可以编辑，我在想策略路由和静态路由是不是统一用vpc的spec 静态路由和策略路由来维护更好一些。

Good Idea!

authors: bobz965 oilbeater xujunjie-cover


text:
Enable dryrun for e2e operator webhook

What this PR does / why we need it:
This PR enables the dryrun option for the e2e operator webhook to handle requests with dryrun flag.
Which issue(s) this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close the issue(s) when PR gets merged):
Fixes #
Special notes for your reviewer:
Documentation:

Does this PR introduce a user-facing change?:

NONE

/retest

/retest

/lgtm

authors: jiachengxu nmiculinic

repo: kubermatic/kubecarrier


text:
Fix flatcar kubelet version detection

What this PR does / why we need it:
Which issue(s) this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close the issue(s) when PR gets merged):
Fixes #
Special notes for your reviewer:
Does this PR introduce a user-facing change?:

Fix flatcar kubelet version detection

/cherry-pick release/v1.0

repo: kubermatic/kubeone


text:
Automate generating terraform configs README files

What type of PR is this?
/kind documentation
What this PR does / why we need it:

To avoid forgetting to update the README file of the corresponding terraform config now we will fail the CI (verify-codegen).
Formalize the procedure of terraform config README generation

Which issue(s) this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close the issue(s) when PR gets merged):
Fixes #
Special notes for your reviewer:
Does this PR introduce a user-facing change?:

Automate generating terraform configs README files

looks good to me.


text:
pkg/util/etcdutil: improve etcd migration logs

After running into issues deploying self-hosted etcd on Tectonic, I saw
lots of error logs. I thought the logs could be improved and be more
consistent.
cc @hongchaodeng

lgtm after addressing the minor issues hongchao pointed out. thanks!

Thanks, @hongchaodeng and @xiang90. I addressed the nits. @yifan-gu or @pbx0 can someone with rights plz merge?

repo: kubernetes-incubator/bootkube


text:
Extract Status.LoadBalancer.Hostname from service annotations

On AWS, the loadbalancer is / will be / should be set up in the
hostname.

LGTM. Just have a minor thing regarding the test message. It's your decision @justinsb.

LGTM

one minor thing, maybe u can change the kubernetes fake client to use CoreV1 instead in this PR ?

authors: ideahitme justinsb linki

repo: kubernetes-incubator/external-dns


text:
Configuration/docs for apiEndpoints

I just got around to using the multiple API endpoints from https://github.com/kubernetes-incubator/kube-aws/pull/468. I have some issues configuring it to achieve the addition of a DNS name to the cert without another ELB.
The relevant details of my cluster.yaml are:
#externalDNSName: k8s-dev-v1.REDACTED
#createRecordSet: true
#recordSetTTL: 60
#hostedZone: ""
#hostedZoneId: REDACTED

apiEndpoints:
  - name: versioned
    createRecordSet: true
    dnsName: k8s-dev-v1.REDACTED
    hostedZone:
      id: REDACTED
    recordSetTTL: 60
  - name: unversioned
    dnsName: k8s-dev.REDACTED

worker:
  apiEndpointName: versioned
  nodePools:
    - name: worker-pool-a
    - name: worker-pool-b
    - name: worker-pool-c

The output of kube-aws validate is:
WARN: the worker node pool "worker-pool-a" is associated to a k8s API endpoint behind the DNS name "k8s-dev-v1.REDACTED" managed by YOU!
Please never point the DNS record for it to a different k8s cluster, especially when the name is a "stable" one which is shared among multiple k8s clusters for achieving blue-green deployments of k8s clusters!
kube-aws can't save users from mistakes like that
WARN: the worker node pool "worker-pool-b" is associated to a k8s API endpoint behind the DNS name "k8s-dev-v1.REDACTED" managed by YOU!
Please never point the DNS record for it to a different k8s cluster, especially when the name is a "stable" one which is shared among multiple k8s clusters for achieving blue-green deployments of k8s clusters!
kube-aws can't save users from mistakes like that
WARN: the worker node pool "worker-pool-c" is associated to a k8s API endpoint behind the DNS name "k8s-dev-v1.REDACTED" managed by YOU!
Please never point the DNS record for it to a different k8s cluster, especially when the name is a "stable" one which is shared among multiple k8s clusters for achieving blue-green deployments of k8s clusters!
kube-aws can't save users from mistakes like that
Error: Failed to initialize cluster driver: file cluster.yaml: unknown keys found in worker.nodePools[0].apiEndpoints[0]: createRecordSet, hostedZone, recordSetTTL

Side note - it seems the default cluster.yaml does not have all the details yet. For example worker.apiEndpointName which I found out about by accident:
Error: Failed to initialize cluster driver: file cluster.yaml: worker.apiEndpointName must not be empty when there're 2 or more API endpoints under the key `apiEndpoints` and one of worker.nodePools[] are missing apiEndpointName

Sorry if I had been making mistakes in cluster.yaml but your cluster.yaml should look like:
apiEndpoints:
  - name: versioned
    dnsName: k8s-dev-v1.REDACTED
    loadBalancer:
      createRecordSet: true
      hostedZone:
        id: REDACTED
      recordSetTTL: 60
  - name: unversioned
    dnsName: k8s-dev.REDACTED

Because a record set is created for a load balancer, rather than an api endpoint itself(IMHO)

And the unknown keys found in worker.nodePools[0].apiEndpoints[0] error is very odd. Seems like I made a bug there... It should only validate unknown keys in the top level apiEndpoints rather than the ones under worker.nodePools[]

I also found kubeconfig comes out with empty server but it may be related to the same issues:
- cluster:
    certificate-authority: credentials/ca.pem
    server: https://

Let me try what you mentioned above first and I'll see if it's resolved.

About loadBalancer - the template in default cluster.yaml is wrong but the examples just below it are correct, I had not spotted the difference. There's no validation errors for the apiEndpoints perhaps?

I can confirm with latest master I get the same error messages:
WARN: the worker node pool "worker-pool-a" is associated to a k8s API endpoint behind the DNS name "k8s-dev-v7.REDACTED" managed by YOU!
Please never point the DNS record for it to a different k8s cluster, especially when the name is a "stable" one which is shared among multiple k8s clusters for achieving blue-green deployments of k8s clusters!
kube-aws can't save users from mistakes like that
[...]
Error: Failed to initialize cluster driver: file cluster.yaml: unknown keys found in worker.nodePools[0].apiEndpoints[0]: createRecordSet, hostedZone, recordSetTTL

Moving createRecordSet, hostedZone and recordSetTTL works so at least it's ok if the config is valid. Will probably submit a PR to fix the default cluster.yaml but not sure about the validation part yet.

Thanks for your confirmation.
Just a quick reply but I've submitted the fix for the validation at
https://github.com/kubernetes-incubator/kube-aws/pull/521
Would you mind confirming if it works for you?
2017年4月11日(火) 10:34 Chris Knowles notifications@github.com:

I can confirm with latest master I get the same error messages:
WARN: the worker node pool "worker-pool-a" is associated to a k8s API endpoint behind the DNS name "k8s-dev-v7.REDACTED" managed by YOU!
Please never point the DNS record for it to a different k8s cluster, especially when the name is a "stable" one which is shared among multiple k8s clusters for achieving blue-green deployments of k8s clusters!
kube-aws can't save users from mistakes like that
[...]
Error: Failed to initialize cluster driver: file cluster.yaml: unknown keys found in worker.nodePools[0].apiEndpoints[0]: createRecordSet, hostedZone, recordSetTTL
Moving createRecordSet, hostedZone and recordSetTTL works so at least
it's ok if the config is valid. Will probably submit a PR to fix the
default cluster.yaml but not sure about the validation part yet.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/kubernetes-incubator/kube-aws/issues/520#issuecomment-293124427,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AABV-R9FvdHYYWd33zbg2zvrY0duvZdYks5rutisgaJpZM4M4d9H
.

@mumoshu sure, can take a look now.

@mumoshu ah yes the commit above. I saw that but for some reason I thought you'd merged it already 😆   I just built your branch and re-validate but I still get the same error using the invalid config above.

authors: c-knowles mumoshu

repo: kubernetes-incubator/kube-aws


text:
Centos 7.5 + vault for cert-manager failed. “Unable to find any of pip2, pip to use.  pip needs to be installed.“

BUG REPORT:
With cert_management: vault it failed. This is because vault installation need python modules (ie hvac) but pip is not installed by bootstrap
Environment:

On Premise:

OS (printf "$(uname -srm)\n$(cat /etc/os-release)\n"):

Linux 3.10.0-862.11.6.el7.x86_64 x86_64
NAME="CentOS Linux"
VERSION="7 (Core)"
ID="centos"
ID_LIKE="rhel fedora"
VERSION_ID="7"
PRETTY_NAME="CentOS Linux 7 (Core)"
ANSI_COLOR="0;31"
CPE_NAME="cpe:/o:centos:centos:7"
HOME_URL="https://www.centos.org/"
BUG_REPORT_URL="https://bugs.centos.org/"

CENTOS_MANTISBT_PROJECT="CentOS-7"
CENTOS_MANTISBT_PROJECT_VERSION="7"
REDHAT_SUPPORT_PRODUCT="centos"
REDHAT_SUPPORT_PRODUCT_VERSION="7"

cat /etc/redhat-release
CentOS Linux release 7.5.1804 (Core)

Version of Ansible (ansible --version):

ansible 2.6.1
  config file = /Users/ltupin/git/infrastructure/installation/infra-prod-kube/kubespray/ansible.cfg
  configured module search path = ['/Users/ltupin/git/infrastructure/installation/infra-prod-kube/kubespray/library']
  ansible python module location = /usr/local/Cellar/python3/3.6.0/Frameworks/Python.framework/Versions/3.6/lib/python3.6/site-packages/ansible
  executable location = /usr/local/bin/ansible
  python version = 3.6.0 (default, Dec 24 2016, 08:01:42) [GCC 4.2.1 Compatible Apple LLVM 8.0.0 (clang-800.0.42.1)]

Kubespray version (commit) (git rev-parse --short HEAD):
6b598eaa

Network plugin used:
calico
Copy of your inventory file:
cert_management: vault
Command used to invoke ansible:
ansible-playbook -i ${inventory} cluster.yml -vv

Output of ansible run:
FAILED! => {“changed”: false, “msg”: “Unable to find any of pip2, pip to use.  pip needs to be installed.“} error. Playbook not handle it ?

Anything else do we need to know:
By adding this check in bootstrap task it works :
- name: Install packages requirements for bootstrap
  yum:
    name: "{{ packages }}"
    state: present
  vars:
    packages:
      - libselinux-python
      - epel-release
      - python-pip

You have to set bootstrap_os.
https://github.com/kubernetes-incubator/kubespray/blob/master/inventory/sample/group_vars/all/all.yml#L5

It's already done. If I use cert as script everything works fine. Sorry I
didn't put all my variables.
Le lun. 24 sept. 2018 à 07:37, Marius Leustean notifications@github.com a
écrit :

You have to set bootstrap_os.
https://github.com/kubernetes-incubator/kubespray/blob/master/inventory/sample/group_vars/all/all.yml#L5
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/kubernetes-incubator/kubespray/issues/3374#issuecomment-423880531,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AA-D4plCEnbdELa1Cf1rwp5nUmrh90j3ks5ueG-ygaJpZM4W06se
.

authors: ltupin mariusleu

repo: kubernetes-incubator/kubespray


text:
Remove the redundant space

Remove the redundant space

/assign @mattymo


text:
adding cache around WAF API usage

Adding caches for WAF API usage.
The WAF API have a 1 TPS limitation, adding client-side cache to mitigate it.
The default cache timeout is 10 minutes, as long as user didn't manually adjust webACL on ALB from console/CLI, there won't be any cache issue.

/lgtm

Seems tests have been fixed.
/lgtm


text:
Scopes must be space-separated list

If you try to use commas as indicated in the documentation, you get an error similar to the following:
kubebuilder/controller "msg"="Reconciler error" "error"="failed to reconcile listeners due to failed to reconcile listener due to InvalidLoadBalancerAction: A scope cannot contain a comma. Separate multiple scopes using spaces\n\tstatus code: 400, request id: faaec23d-4bed-11e9-a3d9-25197b2b13db"

I signed it

/ok-to-test

/lgtm
/approve

authors: bigkraig cwegrzyn


text:
Triage for issues, cherry picking, and other plugins

What would you like to be added:

Upstream-style triage implemented for issues.
Cherry-picking enabled (e.g. /cherry-pick)
(optional) look for other convenient plugins and integrations we might benefit from

Why this is needed:
We currently do triage in a very manual way and it's a bit tedious.
Additional Notes:
https://github.com/kubernetes/test-infra/blob/master/config/prow/plugins.yaml

https://github.com/kubernetes/test-infra/pull/29270 is intended to resolve this.

repo: kubernetes-sigs/gateway-api


text:
Add a conformance test that checks adding and removing listeners

What type of PR is this?

/kind test
/area conformance
What this PR does / why we need it:
Adds a conformance test that tests adding and removing listeners.
https://github.com/kubernetes-sigs/gateway-api/issues/1607
Which issue(s) this PR fixes:

Fixes #1607
Does this PR introduce a user-facing change?:

NONE

The intent of the issue was to support arbitrary ports/listeners because there are implementations that only listen on port 80 and 443.

Sorry, the arbitrary ports detail wasn't clear to me from the issue this PR fixes. I've filed https://github.com/kubernetes-sigs/gateway-api/issues/1842 as a follow up, let me know if I missed anything.

authors: mmamczur robscott


text:
Disable HRQ e2e tests

HRQ isn't on in the default manifests so we shouldn't try to test it.
Tested: verified that the right number tests are "pending" when I run
make test-e2e. Didn't wait to verify exactly which ones they were.

/assign @erikgb
/assign @rjbez17
May I get a quick lgtm for this? The nightly e2e tests are broken because of it. Thanks!

/lgtm
Thanks!

authors: adrianludwin erikgb

repo: kubernetes-sigs/hierarchical-namespaces


text:
chore: Don't require message or reason to be set for NodeClaims

Fixes #N/A
Description
How was this change tested?
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 9069894508
Details

0 of 0   changed or added relevant lines in 0 files are covered.
2 unchanged lines in 1 file lost coverage.
Overall coverage remained the same at 78.527%

Files with Coverage Reduction
New Missed Lines
%

pkg/scheduling/requirements.go
2
97.98%

Totals

Change from base Build 9066200822:
0.0%

Covered Lines:
8316

Relevant Lines:
10590

💛  - Coveralls

authors: coveralls jonathan-innis

repo: kubernetes-sigs/karpenter


text:
Improve push/pull secret handling in signing

Re-work secret handling for pulling and pushing images Add support for dockerconfigjson and dockercfg style secrets Add support for multiple keys in a single secret (useful for pulling and pushing to different registries)
This also sets the stage for allowing service account secrets
We do this by mounting secrets in their own directories then reading all the files (keys) in that dir

/ok-to-test

@chr15p Why do we have all that logic to parse the secret? crane have support for directly using a dockerconfigjson file for accessing images. See https://github.com/ybettan/kernel-module-management/blob/af8eb8630fcd64cfcd483e99770941773c45d39a/internal/registry/registry.go#L142-L151.
Am I missing something?

@chr15p Why do we have all that logic to parse the secret? crane have support for directly using a dockerconfigjson file for accessing images. See https://github.com/ybettan/kernel-module-management/blob/af8eb8630fcd64cfcd483e99770941773c45d39a/internal/registry/registry.go#L142-L151.
Am I missing something?

You're missing a weird edge case interaction between k8s and crane used in a pod.
If you map a secret in as a volume the pod sees it as a directory named $SECRETNAME/ and then each secret key is a file within that ($SECRETNAME/$KEY).  We might need two secrets (one for pull, one for push, assuming we're pulling from one registry, and pushing to another), so two keys in the secret, so we get a directory with two files in it.
Crane's default keyring looks for credentials in a single file called config.json (the name is hardcoded) which is obviously a single file so if we used crane we could map one secret in, b ut not two, so we could pull, or push, but not both.
Unless I am missing something obviously!    (it would make me happy if I was!)
(I could implement my own version of the keyring interface, but at that point I have to do pretty much the same thing anyway i.e. get an authn.Authenticator and wrap it in a keyring, rather than just get an Authenticator and use it directly,  so I don't see the benefit)

You're missing a weird edge case interaction between k8s and crane used in a pod.

If you map a secret in as a volume the pod sees it as a directory named $SECRETNAME/ and then each secret key is a file within that ($SECRETNAME/$KEY). We might need two secrets (one for pull, one for push, assuming we're pulling from one registry, and pushing to another), so two keys in the secret, so we get a directory with two files in it.
Crane's default keyring looks for credentials in a single file called config.json (the name is hardcoded) which is obviously a single file so if we used crane we could map one secret in, b ut not two, so we could pull, or push, but not both.
Unless I am missing something obviously! (it would make me happy if I was!)
(I could implement my own version of the keyring interface, but at that point I have to do pretty much the same thing anyway i.e. get an authn.Authenticator and wrap it in a keyring, rather than just get an Authenticator and use it directly, so I don't see the benefit)
What happens if you use the spec.imagePullSecrets field instead of volumtes?
See https://kubernetes.io/docs/tasks/configure-pod-container/pull-image-private-registry/#create-a-pod-that-uses-your-secret.

I have rewritten the directory walking code based around Walkdir, I'm not sure its simpler but it is more idiomatic (or go-ey!), and avoids the need for global variables by running it inside a class.  It also means we only walk the directory once which is nicer.
It does mean all secrets need to be mounted in the same directory and we pass in a single "-secretsdir" rather than separate "-pullsecret" and "-pushsecret", which is maybe not quite as nice but (I think) worth it.  In OCP we will then need to mount the builder sa account secrets into the same dir (but thats a change for midstream not here)

/approve

After talking to @chr15p this is my understanding:

The sign job is using 2 pieces: the spec.imageRepoSecret and the build.Secret of the module.
KMM is starting the sign job and mounting the spec.ImageRepoSecret and build.Secret to the job.
the sign job is then combining all those files (secrets keys) into a single dockerconfigjson (or other format) and using it.

I would like to understand if it is possible and if it is, change it in the future (to not hold this PR) to:

KMM will start the sign job and will mount the build.secret but instead of mounting spec.imageRepoSecret it will pass it as a runtime arg to the sign binary (the secret name only) and the cluster context if needed.
The sign code will then get the keyChain based on the secret same way we are doing in KMM and pass it to crane as an option.
This will probably remove that whole parsing code no?!

WDYT? @chr15p @qbarrand @yevgeny-shnaidman

WDYT? @chr15p

The standard answer to "how do I access a secret within a job?"  is "mount it as a volume" and thats simple so that's how this started out, however things have evolved and its now got quite complicated (two formats for pull secrets doesn't help!).
To just pass in the secret name the signimage.go binary would need to act as a k8s client and so need the settings and creds to do that which has its own issues, but definitely worth a look.  But thats all for a future PR!

/lgtm

authors: chr15p qbarrand ybettan


text:
Adding an enhancement for checking image existence using the container-runtime.

/cc @yevgeny-shnaidman @mresvanis @TomerNewman

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 72.62%. Comparing base (fa23a9b) to head (ae33536).
Report is 131 commits behind head on main.

Additional details and impacted files
@@            Coverage Diff             @@
##             main     #915      +/-   ##
==========================================
- Coverage   79.09%   72.62%   -6.48%
==========================================
  Files          51       65      +14
  Lines        5109     4493     -616
==========================================
- Hits         4041     3263     -778
- Misses        882     1045     +163
+ Partials      186      185       -1

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

There is one  more scenario that we need to handle:

user creates a KMM module
Module NMC creates a MIC
MIC controller tries to pull the image, image is missing and the MIC status is updated accordingly
user creates an images in the repo
user triggers module's reconcilaition
MIC reconciliation is not triggered since MIC spec is not changed

We might consider adding some counter to the MIC spec , so that Module NMC might update it and thus trigger reconciliation.

There is one more scenario that we need to handle:
user creates a KMM module
Module NMC creates a MIC
MIC controller tries to pull the image, image is missing and the MIC status is updated accordingly
user creates an images in the repo
user triggers module's reconcilaition
MIC reconciliation is not triggered since MIC spec is not changed
We might consider adding some counter to the MIC spec , so that Module NMC might update it and thus trigger reconciliation.

What do you think about just adding the ImagePullPolicy from the module to the ModuleImagesConfig correct entry?
We are using this ImagePullPolicy in the init-container so we can use the same policy for checking if the image exists

Checking the image existence and pulling it will be consistent
We don't need to handle any user race condition - if he override the image, he should use ImagePullPolicy=always to always pull or delete the image on the node manually before re-triggering the reconciliation.

WDYT?

/lgtm


text:
Add the missing license header for source file

What type of PR is this?
/kind documentation
What this PR does / why we need it:
Which issue(s) this PR fixes:
Fixes #
Special notes for your reviewer:

/lgtm
/approve

authors: ahg-g jiwq

repo: kubernetes-sigs/kueue


text:
Update documentation links

What type of PR is this?
I updated the documentation links with https://kueue.sigs.k8s.io.
/kind documentation
What this PR does / why we need it:
Which issue(s) this PR fixes:

Fixes #
Special notes for your reviewer:

@alculquicondor Updated and squashed.


text:
HNC: Adapt to new PSP replacement

See new PSP replacement.
The change is about replacing current PSP, which is not namespaced, with namespace labels such as podsecurity.kubernetes.io/warn=restricted. The PodSecurityPolicy is deprecated as of Kubernetes v1.21, and will be removed in v1.25.
This may affect HNC in two aspects:

People will use these new labels to enforce pod security policies per namespace then. Since the label is on namespaces and HNC doesn't propagate labels on a subnamespace, there's no difference of HNC creating a new subnamespace or privileged users creating a new namespace without additional labels. However, users without privileges to create namespaces may not be able to update namespace labels. So we may need to enable them to self-serve namespaces with labels.

The other thing that may affect HNC is that if users use HNC to propagate pods, some propagation may fail because of the mismatching pod security policy label on the local child namespace.

I'd remove the bit about pods here since we don't consider this to be a
valid use case.
On Wed, 14 Apr 2021, 11:33 am Yiqi Gao, @.***> wrote:

See new PSP replacement
https://docs.google.com/document/d/1dpfDF3Dk4HhbQe74AyCpzUYMjp4ZhiEgGXSMpVWLlqQ/edit
.
The change is about replacing current PSP, which is not namespaced, with
namespace labels such as podsecurity.kubernetes.io/warn=restricted. The
PodSecurityPolicy is deprecated as of Kubernetes v1.21, and will be removed
in v1.25.
This may affect HNC in two aspects:

People will use these new labels to enforce pod security policies per
namespace then. Since the label is on namespaces and HNC doesn't propagate
labels on a subnamespace, there's no difference of HNC creating a new
subnamespace or privileged users creating a new namespace without
additional labels. However, users without privileges to create namespaces
may not be able to update namespace labels. So we may need to enable them
to self-serve namespaces with labels.
2.
The other thing that may affect HNC is that if users use HNC to
propagate pods, some propagation may fail because of the mismatching
pod security policy label on the local child namespace.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/kubernetes-sigs/multi-tenancy/issues/1473, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AE43PZAJK74HKQLKQHYAJQDTIWYU5ANCNFSM425UJKJA
.

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

repo: kubernetes-sigs/multi-tenancy


text:
Upgrade Go version to 1.22.5 to fix CVEs.

This commit addresses the following CVEs:
CVE-2024-24790 - https://security-tracker.debian.org/tracker/CVE-2024-24790
CVE-2024-24789 - https://security-tracker.debian.org/tracker/CVE-2024-24789

Hi @logicalhan and/or @dgrisonnet, please take a look at this pull request when you get a chance. Thanks!

repo: kubernetes-sigs/prometheus-adapter


text:
Upgrade Go dependencies.

Upgrade the Go version and move to Kubernetes 1.19. The latter will
allow us to adopt the standardized Condition type.
Signed-off-by: James Peach jpeach@vmware.com

/ok-to-test

Thanks!
/lgtm

/approve

authors: jpeach robscott

repo: kubernetes-sigs/service-apis


text:
[stable/cluster-autoscaler] Enable Autodiscovery

Background
Currently, autodiscovery is not exposed by the chart. Additionally, the pull-charts-e2e test fails because this chart does not provide enough defaults to start the pod.
What's this do

Uses upstream's default AWS ASG tags for autodiscovery of nodes. Enables it by default. The user must then set autoDiscovery.clusterName
Expands on several use cases and cleans up the readme
Spins along doing nothing until the k8s.io/cluster-autoscaler/enabled and kubernetes.io/cluster/<Values.autoDiscovery.clusterName> tags are found

How to review
Please see #3989 and #4077 for the major motivation.
Split into three commits, with 2eb1a4a containing all the code changes.
Alternatives considered
Providing a nonsense default ASG would also get the pod started.
Related
closes #4077
closes #2954 (actually fixed by #3248)
closes #3724
supersedes #3989
See also
Previous discussion about getting this chart to start
Why cluster name is not accessible
The upstream recommended configuration for cluster-autoscaler autodiscovery tags
The documentation for these tags

@sameersbn @prydonius closed #3989 in favour of this.

thanks @afirth
/ok-to-test

@afirth looks like this didn't work as we expected, now we're getting:
I0309 15:52:38.845] F0309 15:50:17.471835       1 cloud_provider_builder.go:112] Failed to create AWS cloud provider: Failed to get ASGs: NoCredentialProviders: no valid providers in chain. Deprecated.

Prydonius agreed. It seems it never will, which makes sense as the test AWS provider has no credentials (or ASGs to manage) and this causes cluster-autoscaler to exit immediately, as it should. I've tried another approach, wrapping the whole deployment in a conditional. This should let the test pass and warn "no pods created". Additionally, using required in the NOTES will hopefully alert the user, although I don't have the setup to run the test. This also keeps the current behaviour - do nothing by default - which I think is better for the user anyway. I'll finish this up and push this soon.

closed in favor of #4120

authors: afirth prydonius

repo: kubernetes/charts


text:
error running compiler

https://github.com/kubernetes/client-go/blob/6ee68ca5fd8355d024d02f9db0b3b667e8357a0f/rest/request.go#L598
compile: error running compiler: exit status 2
/root/.cache/bazel/_bazel_root/9fb8753853fa4f06dcf18e6226b8e4f5/execroot/__main__/vendor/k8s.io/client-go/rest/request.go:598:31: not enough arguments in call to watch.NewStreamWatcher
	have (*versioned.Decoder)
	want (watch.Decoder, watch.Reporter)

Is this my method wrong?

Duplicate of https://github.com/kubernetes/client-go/issues/584
Be sure you are using the tagged version of k8s.io/apimachinery which corresponds to the version of client-go you are using
/close

OK. I got the reason.
Thanks.

authors: liggitt snxq

repo: kubernetes/client-go


text:
the way cinder-endpoint to deploy provisioner that the image standalone-cinder-provisioner not support

Is this a BUG REPORT or FEATURE REQUEST?:
/kind bug

Uncomment only one, leave it on its own line:
/kind bug
/kind feature

What happened:
I use the cinder-endpoint way to deploy the provisioner,but found the image that quay.io/external_storage/standalone-cinder-provisioner:latest not updated and not supproted! then I plan to make a image use the master branch code,and clone the cloud-provider-openstack code then command the make,but found need glide,then install glide and make again,but found the log,can help me or I maybe wrong in some place,thanks
[INFO]	--> Fetching k8s.io/apiextensions-apiserver
[INFO]	--> Fetching k8s.io/kube-openapi
[INFO]	--> Fetching k8s.io/kubernetes
[WARN]	Unable to checkout golang.org/x/net
[ERROR]	Update failed for golang.org/x/net: Cannot detect VCS
[WARN]	Unable to checkout golang.org/x/crypto
[ERROR]	Update failed for golang.org/x/crypto: Cannot detect VCS
[WARN]	Unable to checkout golang.org/x/sys
[ERROR]	Update failed for golang.org/x/sys: Cannot detect VCS
[WARN]	Unable to checkout golang.org/x/text
[ERROR]	Update failed for golang.org/x/text: Cannot detect VCS
[WARN]	Unable to checkout google.golang.org/genproto
[ERROR]	Update failed for google.golang.org/genproto: Cannot detect VCS
[WARN]	Unable to checkout golang.org/x/time
[ERROR]	Update failed for golang.org/x/time: Cannot detect VCS
[WARN]	Unable to checkout google.golang.org/grpc
[ERROR]	Update failed for google.golang.org/grpc: Cannot detect VCS
What you expected to happen:
can provider a new image ?
How to reproduce it (as minimally and precisely as possible):
Anything else we need to know?:
Environment:

openstack-cloud-controller-manager version:
OS (e.g. from /etc/os-release):
Kernel (e.g. uname -a):
Install tools:
Others:

/assign @dims
thanks very much

/cc @j-griffith

[root@controller:/paasdata/cloud-provider-openstack-master]$ glide --version
glide version v0.13.1
[root@controller:/paasdata/cloud-provider-openstack-master]$ go version
go version go1.9.2 linux/amd64
[root@controller:/paasdata/cloud-provider-openstack-master]$ ls
bindep.txt  cmd      devstack  examples    glide.yaml  LICENSE   manifests  pkg        staging  vendor
cluster     contrib  docs      glide.lock  hack        Makefile  OWNERS     README.md  tools
[root@controller:/paasdata/cloud-provider-openstack-master]$ make
pip install Mercurial
Collecting Mercurial
Downloading http://1.1.1.1/pypi/packages/23/9f/79296aac5577fd2c9de7d754cb64807faf26cf02f4423ba2ac36cbebf053/mercurial-4.3.3.tar.gz (5.5MB)
100% |████████████████████████████████| 5.5MB 12.5MB/s
Complete output from command python setup.py egg_info:
running egg_info
creating pip-egg-info/mercurial.egg-info
writing pip-egg-info/mercurial.egg-info/PKG-INFO
writing top-level names to pip-egg-info/mercurial.egg-info/top_level.txt
writing dependency_links to pip-egg-info/mercurial.egg-info/dependency_links.txt
writing manifest file 'pip-egg-info/mercurial.egg-info/SOURCES.txt'
Python headers are required to build Mercurial but weren't found in /usr/include/python2.7/Python.h
----------------------------------------

Command "python setup.py egg_info" failed with error code 1 in /tmp/pip-build-FiMj5A/Mercurial/
make: *** [depend] Error 1
can help me?

install mercurial using apt : apt install mercurial and then re-run make

please see PR - https://github.com/kubernetes/cloud-provider-openstack/pull/104
/close

authors: dims jianglingxia

repo: kubernetes/cloud-provider-openstack


text:
trust-id not used in auth for CSI

/kind bug
What happened:
I'm working on a template with openstack magnum using CSI. Magnum provides a trustee to the template and this is used to have the cloud-config config file done.
The problem is that trust-id parameter is not used in the authentification process between the CSI pod and this leads to the following error :

I0405 11:07:46.749363       1 server.go:108] Listening for connections on address: &net.UnixAddr{Name:"/csi/csi.sock", Net:"unix"}
I0405 11:07:46.810438       1 utils.go:73] GRPC call: /csi.v1.Identity/Probe
I0405 11:07:46.810457       1 utils.go:74] GRPC request:
I0405 11:07:47.517388       1 identityserver.go:52] Failed to CreateOpenStackProvider: No suitable endpoint could be found in the service catalog.

in the pods log.
in the JSON sent from the pod to openstack we can see:

{"auth":{"identity":{"methods":["password"],"password":{"user":{"domain":{"id":"c5503d1bd8b14141b782cad252c6b7cb"},"name":"b67ae13d-5c93-4374-8902-712f291de94f_968b910e7f0b46b586ad967a1082a693","password":"CCC"}}}}}

we don't have any trust id.
If I reproduce those parameter using CLI in openstack I get

user@stack:~# openstack port list
The service catalog is empty.

If I add the
OS_TRUST_ID=xxx
in my CLI file, then it works fine
What you expected to happen:
CSI should work with a trustee user as it is stated in the docs
How to reproduce it (as minimally and precisely as possible):
create a trustee user, configure the cloud-config, launch a pod

looking at  csi/cinder/openstack/openstack.go
there is no TrustID    string gcfg:"trust-id" line in

type Config struct {
Global struct {

so that will probably not work


text:
[OCCM] Print error messages, when OpenStack client returns error

What this PR does / why we need it:
Now OCCM prints error message, when a required endpoint cannot be found.
Special notes for reviewers:
Due to #977 OCCM stopped to work silently, there were no errors showed in logs. It took a while to debug the root cause.
Release note:
[OCCM] Print error messages, when OpenStack client returns error

/cc @rfranzke
/assign @lingxiankong

/ok-to-test

/lgtm

/test cloud-provider-openstack-acceptance-test-csi-cinder

/test cloud-provider-openstack-unittest

/retest cloud-provider-openstack-acceptance-test-csi-cinder

/retest cloud-provider-openstack-unittest

@kayrus release note is not required for all PRs , required only for features and imp bugs . For this PR , release note can be NONE

/test cloud-provider-openstack-acceptance-test-csi-cinder

/test cloud-provider-openstack-unittest

@lingxiankong tests pass

/assign @lingxiankong

release note was deleted.
/lgtm
/approve

authors: jichenjc kayrus lingxiankong ramineni


text:
WIP [cinder-csi-plugin] re-enable Volume Expansion

What this PR does / why we need it:
We want to re-enable Volume Expansion. This is the first test if citynetwork does support this.
Which issue this PR fixes(if applicable):
fixes #1405
Special notes for reviewers:

Release note:

NONE

looks like test passed, this is still WIP?

authors: chrigl jichenjc


text:
Add/Update more CI jobs

Fixup 1.11 as we have a release-1.11 branch
Add new job for 1.12

Change-Id: Ida552559ad4dc130586654d666bdf347d8221720

What this PR does / why we need it:
Which issue this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close that issue when PR gets merged): fixes #
Special notes for your reviewer:
Release note:

NONE

self LGTM as this is an update to the test harness.


text:
network/?? measurements only contain type pod, no measurements for type node

When collecting stats with Heapster, metrics written to influxdb only contain network measurements for type pod.   Subsequently in Grafana the cluster dashboard contains no datapoints on the Network Graphs.
> show measurements
name: measurements
name
----
cpu/limit
cpu/node_allocatable
cpu/node_capacity
cpu/node_reservation
cpu/node_utilization
cpu/request
cpu/usage
cpu/usage_rate
filesystem/available
filesystem/limit
filesystem/usage
log/events
memory/limit
memory/major_page_faults
memory/major_page_faults_rate
memory/node_allocatable
memory/node_capacity
memory/node_reservation
memory/node_utilization
memory/page_faults
memory/page_faults_rate
memory/request
memory/usage
memory/working_set
network/rx
network/rx_errors
network/rx_errors_rate
network/rx_rate
network/tx
network/tx_errors
network/tx_errors_rate
network/tx_rate
uptime

$> show tag values on "k8s" with key = "type"
...
name: network/rx
key  value
---  -----
type pod

name: network/rx_errors
key  value
---  -----
type pod

name: network/rx_errors_rate
key  value
---  -----
type pod

name: network/rx_rate
key  value
---  -----
type pod

name: network/tx
key  value
---  -----
type pod

name: network/tx_errors
key  value
---  -----
type pod

name: network/tx_errors_rate
key  value
---  -----
type pod

name: network/tx_rate
key  value
---  -----
type pod

Output of heapster --version:
Running within a privileged docker container.
heapster-v1.3.0

Output of kubectl version:
$ kubectl version
Client Version: version.Info{Major:"1", Minor:"5", GitVersion:"v1.5.4", GitCommit:"7243c69eb523aa4377bce883e7c0dd76b84709a1", GitTreeState:"clean", BuildDate:"2017-03-07T23:53:09Z", GoVersion:"go1.7.4", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"5", GitVersion:"v1.5.2", GitCommit:"269f928217957e7126dc87e6adfa82242bfe5b1e", GitTreeState:"clean", BuildDate:"2017-07-03T15:31:10Z", GoVersion:"go1.7.4", Compiler:"gc", Platform:"linux/amd64"}

Hi @damianoneill
Thank you for submitting the issue.
Do you see the same behaviour on clusters with newer versions of Kubernetes?

Hi @cezarygerard the challenge is we are using redhat atomic and therefore the version of Kubernetes is managed by this container operating system.

@damianoneill forgive me if I've missed something here, but what's the expected result?  Network can only be measured on a per-pod basis (with cadvisor, at least), since it looks at the interfaces in the network namespace, and all containers in a pod share a netns.

authors: DirectXMan12 cezarygerard damianoneill

repo: kubernetes/heapster


text:
Add Prometheus metrics of Stackdriver sink performance

Metrics for monitoring Stackdriver sink performances: requests and timeseries sent count by result.

This change is

@k8s-bot test this

cc @crassirostris

LGTM


text:
Fix logging in influxdb sinks

Fixes #989

LGTM

authors: mwielgus piosz


text:
Client-side apply has a pathological case with deeply nested identical objects

Test case

Strip the description fields from https://raw.githubusercontent.com/kubernetes-sigs/kubebuilder/master/docs/book/src/multiversion-tutorial/testdata/project/config/crd/bases/batch.tutorial.kubebuilder.io_cronjobs.yaml (to make it fit in an annotation)
kubectl apply -f the above
kubectl apply -f the above again

Underlying issue
Deeply nested (e.g. validation for podspec) identical issues hit a pathological case in the json-patch library's merge patch generator, which recursively traverses every sub-tree to check if two json trees are identical
Evidence
You can attach an execution trace and use go tool trace to see this for yourself

runtime trace call patch
diff --git a/cmd/kubectl/kubectl.go b/cmd/kubectl/kubectl.go
index 53934ac2b0..fab992ad95 100644
--- a/cmd/kubectl/kubectl.go
+++ b/cmd/kubectl/kubectl.go
@@ -21,6 +21,9 @@ import (
 	"math/rand"
 	"os"
 	"time"
+	"runtime/trace"
+	"os/signal"
+	"syscall"

 	"github.com/spf13/pflag"

@@ -33,6 +36,16 @@ import (
 )

 func main() {
+	traceOut, err := os.Create("/tmp/kubectl.trace")
+	if err != nil {
+		panic(err)
+	}
+	defer traceOut.Close()
+	if err := trace.Start(traceOut); err != nil {
+		panic(err)
+	}
+	defer trace.Stop()
+
 	rand.Seed(time.Now().UnixNano())

 	command := cmd.NewDefaultKubectlCommand()
@@ -46,7 +59,17 @@ func main() {
 	logs.InitLogs()
 	defer logs.FlushLogs()

+	sigCh := make(chan os.Signal)
+	go func() {
+		<-sigCh
+		trace.Stop()
+		traceOut.Close()
+		panic("at the disco!")
+	}()
+	signal.Notify(sigCh, syscall.SIGINT, syscall.SIGTERM)
+
 	if err := command.Execute(); err != nil {
-		os.Exit(1)
+		//os.Exit(1)
+		return
 	}
 }

Potential fixes
Since Go's json serializer sorts the output keys, it should be possible to simply hash the textual representation of each subtree and use that for comparison.  On large nested subtrees that might yield a win.  Unclear what it'd do to the opposite case -- everything different.  You'd need a parser that mapped key to its value, though, which I don't think we currently have.
Also, this may be kind-of moot, since we'll be getting server-side apply, which doesn't suffer from this particular issue.

/assign @seans3

/sig cli
/area kubectl
/kind bug
/priority P2
This performance bug should be fixed by server-side apply.

follow-up:
I've found another work-around, with a bit more digging.  Namely:
diff --git a/vendor/github.com/evanphx/json-patch/merge.go b/vendor/github.com/evanphx/json-patch/merge.go
index 6806c4c200..07f5ee3b0d 100644
--- a/vendor/github.com/evanphx/json-patch/merge.go
+++ b/vendor/github.com/evanphx/json-patch/merge.go
@@ -286,25 +286,10 @@ func matchesValue(av, bv interface{}) bool {
        if reflect.TypeOf(av) != reflect.TypeOf(bv) {
                return false
        }
-       switch at := av.(type) {
-       case string:
-               bt := bv.(string)
-               if bt == at {
-                       return true
-               }
-       case float64:
-               bt := bv.(float64)
-               if bt == at {
-                       return true
-               }
-       case bool:
-               bt := bv.(bool)
-               if bt == at {
-                       return true
-               }
-       case nil:
-               // Both nil, fine.
+       if av == bv {
                return true
+       }
+       switch at := av.(type) {
        case map[string]interface{}:
                bt := bv.(map[string]interface{})
                for key := range at {

Which is fascinating.  It remains unclear to me why the switch is so slow.  Simply replacing the extra statements with a default case does NOT help:
diff --git a/vendor/github.com/evanphx/json-patch/merge.go b/vendor/github.com/evanphx/json-patch/merge.go
index 6806c4c200..4d157d5330 100644
--- a/vendor/github.com/evanphx/json-patch/merge.go
+++ b/vendor/github.com/evanphx/json-patch/merge.go
@@ -287,24 +287,6 @@ func matchesValue(av, bv interface{}) bool {
                return false
        }
        switch at := av.(type) {
-       case string:
-               bt := bv.(string)
-               if bt == at {
-                       return true
-               }
-       case float64:
-               bt := bv.(float64)
-               if bt == at {
-                       return true
-               }
-       case bool:
-               bt := bv.(bool)
-               if bt == at {
-                       return true
-               }
-       case nil:
-               // Both nil, fine.
-               return true
        case map[string]interface{}:
                bt := bv.(map[string]interface{})
                for key := range at {
@@ -321,6 +303,8 @@ func matchesValue(av, bv interface{}) bool {
        case []interface{}:
                bt := bv.([]interface{})
                return matchesArray(at, bt)
+       default:
+               return av == bv
        }
        return false
 }

implying it's the actual type switch that's slowing us down that much.
This is interesting since the equivalent reflect.DeepEqual call is roughly just as fast, but does something similar with reflection: https://golang.org/src/reflect/deepequal.go?s=6112:6149#L65
diff --git a/vendor/github.com/evanphx/json-patch/merge.go b/vendor/github.com/evanphx/json-patch/merge.go
index 6806c4c200..d4883efa75 100644
--- a/vendor/github.com/evanphx/json-patch/merge.go
+++ b/vendor/github.com/evanphx/json-patch/merge.go
@@ -283,46 +283,7 @@ func matchesArray(a, b []interface{}) bool {
 // The types of the values must match, otherwise it will always return false
 // If two map[string]interface{} are given, all elements must match.
 func matchesValue(av, bv interface{}) bool {
-	if reflect.TypeOf(av) != reflect.TypeOf(bv) {
-		return false
-	}
-	switch at := av.(type) {
-	case string:
-		bt := bv.(string)
-		if bt == at {
-			return true
-		}
-	case float64:
-		bt := bv.(float64)
-		if bt == at {
-			return true
-		}
-	case bool:
-		bt := bv.(bool)
-		if bt == at {
-			return true
-		}
-	case nil:
-		// Both nil, fine.
-		return true
-	case map[string]interface{}:
-		bt := bv.(map[string]interface{})
-		for key := range at {
-			if !matchesValue(at[key], bt[key]) {
-				return false
-			}
-		}
-		for key := range bt {
-			if !matchesValue(at[key], bt[key]) {
-				return false
-			}
-		}
-		return true
-	case []interface{}:
-		bt := bv.([]interface{})
-		return matchesArray(at, bt)
-	}
-	return false
+	return reflect.DeepEqual(av, bv)
 }

 // getDiff returns the (recursive) difference between a and b as a map[string]interface{}.

much thanks to go's cpu tracing and pprof for giving me a clue as to where to look

https://github.com/evanphx/json-patch/pull/87 <-- should fix the issue.  The dual traversal of maps was causing an exponential time complexity, which really only manifested seriously with lots of nested maps.

repo: kubernetes/kubectl


text:
[Golang] Fix hollow node pods busybox image pulls issue

Context: https://github.com/kubernetes/kubernetes/pull/95494 (this is what we miss in the k8s version used in Golang jobs). Two most recent job runs suffered from the lack of this PR:

https://prow.k8s.io/view/gcs/kubernetes-jenkins/logs/ci-golang-tip-k8s-1-18/1349312930264387584,
https://prow.k8s.io/view/gcs/kubernetes-jenkins/logs/ci-golang-tip-k8s-1-18/1349252286177611776.

/sig scalability
/assign @mm4tt

/lgtm
/approve

/lgtm
/approve

repo: kubernetes/perf-tests


text:
Add oxddr as a reviewer to clusterloader2, perfdash and probes.

/assign @wojtek-t

/lgtm
/approve

authors: oxddr wojtek-t


text:
Issue with k8s.io/docs/concepts/workloads/pods/ephemeral-containers/

This is a Bug Report

Problem:
The document says:

Ephemeral containers may not have ports, so fields such as ports, livenessProbe, readinessProbe are disallowed.
Pod resource allocations are immutable, so setting resources is disallowed.
For a complete list of allowed fields, see the EphemeralContainer reference documentation.

However, EphemeralContainer reference documentation lists the disallowed fields.
Proposed Solution:
EphemeralContainer reference documentation lists only allowed fields.
Page to Update:
https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.16/#ephemeralcontainer-v1-core

https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.16/#ephemeralcontainer-v1-core seems to list all the fields that EphemeralContainer recognises, noting that some are recognised but not allowed. To me that seems OK (I don't see what the shortcoming is for a reader).
Related: I'm not sure how feasible it is to change the way the reference information is generated. If it's easy to achieve, that's great.

I got it. Thanks.

authors: oke-py sftim

repo: kubernetes/website


text:
Issue with Kubectl not installed due to TLS error

This is a Bug Report

 I am trying to install the kubectl package on ubuntu but throws me an error of url: (60) SSL certificate problem: self signed certificate in certificate chain
More details here: https://curl.haxx.se/docs/sslcerts.html
curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the web page mentioned above.
Problem:
Getting issue while installing the kubectl package on ubuntu and shows me ssl cert error which do not authenticate with the remote server.
Proposed Solution:
Page to Update:
https://kubernetes.io/...

/triage support

@harshaltiwariACN, GitHub is not the right place for support requests.
If you're looking for help, check Stack Overflow
You can also post your question on the Kubernetes Slack or the Discuss Kubernetes forum.

/remove-lifecycle stale

This does seem more like a support request. @harshaltiwariACN if you have more details about this issue, please feel free to reopen the issue and add that information.
/close

authors: harshaltiwariACN irvifa sftim


text:
Issue with k8s.io/docs/tutorials/kubernetes-basics/expose/expose-interactive/

This is a Bug Report

Problem:
You say that we can use the labels to remove a service. But when I use the given label app=v1, the service is not removed and I receive the following message:
kubectl delete service -l app=v1
No resources found

Proposed Solution:
Change the text to explaining why using the given label does not work.
Page to Update:
https://kubernetes.io/docs/tutorials/kubernetes-basics/expose/ (interactive tutorial)

Do you strictly follow the interactive command window? The command does not exist in the terminal of this page.
kubectl delete service -l run=kubernetes-bootcamp

/triage needs-information

Yes. I followed the suggested command and it worked as it should. But when I read that we could use also the labels, I tried with the label app=v1 and it did not work. I think you can add some information regarding this, explaining that the labels will not work on that interactive window and we should only follow the suggested commands strictly as they are shown.

Interestingly, I add a label to an svc, and then view and delete resources through the label.

/triage support

remove /triage needs-information

/remove-triage needs-information

Strange... I tried again and same problem occurred:
$ kubectl get pods -l app=v1
NAME                                   READY   STATUS    RESTARTS   AGE
kubernetes-bootcamp-765bf4c7b4-kx595   1/1     Running   0          9m17s
$ kubectl delete service -l app=v1
No resources found

app=v1  belongs to pod, not service. You Can use kubectl get service -o yaml to check service labels.
/close

It can't be reproduced.
/close

authors: Cweiping cezane


text:
Add "resource" to glossary

This is a Feature Request

What would you like to be added

I'd like to distinguish "resource" and "object".
"Object" is defined in glossary.

An entity in the Kubernetes system. The Kubernetes API uses these entities to represent the state of your cluster.
A Kubernetes object is typically a “record of intent”—once you create the object, the Kubernetes control plane works constantly to ensure that the item it represents actually exists. By creating an object, you're effectively telling the Kubernetes system what you want that part of your cluster's workload to look like; this is your cluster's desired state.

"Create an object" and "create a resource" are both correct expression?
If so, are they same meaning?
I think "object" is suitable, but (Cluster)Role, audit policy have "resourceNames" field. It's confusing.
Why is this needed
A clear word definition may help understanding.
Comments

@oke-py so what I understood is that the following changes need to be made :

Definition of object and resource
Explanation of the terms "Creating an object" and "Creating a resource".

Please correct me if I'm wrong. I'll  send in a pull request

@oke-py so what I understood is that the following changes need to be made :

Definition of object and resource
Explanation of the terms "Creating an object" and "Creating a resource".

Please correct me if I'm wrong. I'll  send in a pull request

@Aut0R3V Thanks. Definition of object exists in glossary.

@Aut0R3V Thanks. Definition of object exists in glossary.

BTW: https://kubernetes.io/docs/reference/using-api/api-concepts/ covers some of resources vs. objects, and PR https://github.com/kubernetes/website/pull/25299 is a (work-in-progress) set of changes to help improve the way we explain it.

BTW: https://kubernetes.io/docs/reference/using-api/api-concepts/ covers some of resources vs. objects, and PR https://github.com/kubernetes/website/pull/25299 is a (work-in-progress) set of changes to help improve the way we explain it.

/triage accepted

/triage accepted

@sftim I just checked in #25299. Does this issue require a different commit or can this issue be closed?

@sftim I just checked in #25299. Does this issue require a different commit or can this issue be closed?

This does sound like a good idea to add. There are several specific meanings of “resource” in Kubernetes.
/remove-lifecycle rotten
/reopen
/language en
/kind feature
/priority important-longterm

/remove-lifecycle rotten

/remove-lifecycle rotten

Please refer to Tim's comment: https://github.com/kubernetes/website/issues/30092#issuecomment-944197249

Thanks. If I understand correctly, this issue should be closed, right?

In the glossary, we have an entry for resource quotas but not for resource.
I would definitely be happy for more entries to be added. When adding these, bear in mind that (like the English word), the Kubernetes jargon uses this term in different ways and to use different things.
/lifecycle frozen
I don't recommend closing this issue until the extra entries are added. #30092 was closed as duplicating existing issues; let's keep this one and use it to track the work. Once this closes, we can revisit https://github.com/kubernetes/website/issues/20074 and see if that is also good to close.

For me
Resources are equivalent to  Classes (Boilerplate)
Objects are equivalent to  objects (Instance)
CRDs for example provide the definition of objects
@sftim

/triage accepted

Help is welcome!

/help

Just for reference purpose, this is very good explanation done for objects and resources. Anyone working on this can get help using this one as well.


text:
[hi] Umbrella issue for translating "Administer a Cluster" section to Hindi

This is a Bug Report

Problem:

In Hindi version of the documentation, the section "Administer a Cluster" is still in english language.

When we click on "Administer a Cluster" section, it redirects to the english version of documentation.

Proposed Solution: We need to localize all the topics under Administer cluster section in Hindi.
Page to Update:
https://kubernetes.io/..

/remove-kind bug
/kind feature

/triage accepted

Any updates on this issue? It looks like the PR https://github.com/kubernetes/website/pull/41056 was closed because it hasn't been updated for a long time. @KashishLakhara04

authors: Babapool KashishLakhara04 mengjiao-liu


text:
Add hover effect on video in case studies

This is a feature request
Add hover effect on Kubernetes at box  video in case studies for user-friendly design
Image of a related issue

/language en

/area web-development

/language an
/assign

Raised PR at #44770

/priority awaiting-more-evidence
I don't object, but I think the site is fine if we don't do this.

I don't object, but I think the site is fine if we don't do this.

@sftim While I agree with you, I also think that introducing a hover effect could improve the overall user-friendly design.

/remove-language en
/sig docs

/kind feature

This doesn't feel like a priority
/close not-planned

authors: AmarNathChary aj11anuj sftim


text:
I want to add new translations, and I can't enter Slack

Discussed in https://github.com/kubernetes/website/discussions/44824
/kind support
Originally posted by @n1cklim
It seems that I need an @get-an-invite-at.slack.kubernetes.io mail to create an account.
I wanted to help with Spanish and Galician translations.

For a Slack invitation, visit https://slack.k8s.io/

/close not-planned