text:
Not work after last update

After the last update (PHPStorm) all my run/debug configurations do not work.
Makefile Example:
docker_bin := $(shell command -v docker 2> /dev/null)

ps:	## Docker ps
	@$(docker_bin)  ps

Terminal command /usr/bin/make -f /home/klim/Nita/eks-project/e-server/cmd/Makefile ps works fine.
Run|debug conf - does not work with error:
/usr/bin/make -f /home/klim/Nita/eks-project/e-server/cmd/Makefile ps
make: ps: Command not found
make: *** [ps] Error 127
/home/klim/Nita/eks-project/e-server/cmd/Makefile:7: recipe for target 'ps' fail

What am I doing wrong?

The same.
Make process launched by last CLion does not able to run any system program.
Output:
/usr/bin/make -f /path/to/Makefile update_common
make: which: Command not found
make: rm: No such file or directory

MACOS10.15.7
Goland 2020.2.3  Build 202.7319.61
Makefile support 3.5.1
GNU Make 3.81

Environment variables not load ?

Same issue here on MacOS (Rider). It seems like it's started setting PATH to null. To confirm this, create a makefile with the following and set it up as a target with no environment variables set, but with "Include system environment variables" checked.
build:
	echo "$(PATH)"

The makefile echos null

I have the same issue.
Workaround in my case:
Option 1: start from terminal using make build
Option 2: rename my package.json in project root to package_.json (Which might be the cause)
Empting packae.json does not solve the problem.

Can confirm this is also an issue in Webstorm for me running MacOS (Cataline v10.15.7).
Trying to run just about any command errors out. For example:
test:
	which make

If I try to run this from the Makefile via the plugin I get:
/usr/bin/make -f /Users/dannyhinshaw/Desktop/Projects/project/Makefile test
which make
make: which: No such file or directory
make: *** [test] Error 1

Process finished with exit code 2

Per @jordwest suggestion I also run this for a test:
build:
	echo "$(PATH)"

Running this from the Makefile via Plugin results in this:
/usr/bin/make -f /Users/dannyhinshaw/Desktop/Projects/project/Makefile build
echo "/Users/dannyhinshaw/Desktop/Projects/docs-blog-gatsby/node_modules/.bin:null"
/Users/dannyhinshaw/Desktop/Projects/docs-blog-gatsby/node_modules/.bin:null

Process finished with exit code 0

Downgrade the plugin to previous version (3.5) is a good workaround

same issue, and go back to 3.5

is it possible related to this fix? because someone said GoLand works but other Intellij apps do not work.
https://youtrack.jetbrains.com/issue/GO-6982
https://github.com/kropp/intellij-makefile/commit/dd4912203084ad94abcfde7def4c72040aab0c1f

authors: DannyHinshaw EXHades canab jordwest klimby madaxel wadouk xinatcg

repo: kropp/intellij-makefile


text:
Obtain upstream ApiVersions when proxy is not SASL offloading

Type of change

Enhancement / new feature

Description
If Kroxylicious is not handling SASL offload (currently it never handles SASL offload) then we initiate NetFilter#selectServer if we receive an ApiVersions request and buffer the message. After the connect is successful we send the buffered message to the backend. We also install the ApiVersionsFilter if we are not handling SASL offload so that we are intersecting the Kroxylicious supported versions with the upstream versions without further configuration.
Closes #441
Additional Context
Why:
Currently Kroxylicious responds with a hardcoded ApiVersions response. This is intentional, to support the proxy handling SASL authentication before we make a connection to the upstream broker, protecting the broker from unauthorized requests and enabling NetFilter to use the authorized id as a criteria for backend server selection. The response is hardcoded to the ApiVersions values for a kafka 3.2 broker.
This means that if we are proxying a broker older than v3.2, Kroxy will be declaring it supports api versions that it doesn't know about, causing errors when you try to use a newer client that supports those newer API versions. Conversely if the backing broker is newer and supports new api versions, the client would be told that the broker only supports v3.2 APIs and the client can't take advantage of new APIs.
Checklist
Please go through this checklist and make sure all applicable tasks have been done

[ ] Write tests
[ ] Make sure all tests pass
[ ] Make sure all Sonar-Lint warnings are addressed or are justifiably ignored.
[ ] Update documentation
[ ] Reference relevant issue(s) and close them after merging
[ ] For user facing changes, update CHANGELOG.md (remember to include changes affecting the API of the test artefacts too).

Would be good to add an integration test.
Also, unsure if this is the right change. I see it as more of a delaying tactic to offer a smoother integration with Kafka as long as SASL offload is not offered.
We could also say we are happy for now with only supporting brokers >3.2 and using APIs at v3.2. Maybe an ugly way that could still support users accessing newer APIs would be to have a configurable level, virtual cluster abc supports v3.4.
There was also a suggestion in a PR of connecting to all/some brokers in the VirtualCluster to discover their ApiVersions and maintaining these persistent connections to track changes. This might be adequate though there are edge cases around feature flags and broker restarts.

Would be good to add an integration test.

+1
maybe mock server test candidate?
+1 Also, unsure if this is the right change. I see it as more of a delaying tactic to offer a smoother integration with Kafka as long as SASL offload is not offered.
I do think this is the right pragmatic step.

There was also a suggestion in a PR of connecting to all/some brokers in the VirtualCluster to discover their ApiVersions and maintaining these persistent connections to track changes.

I was thinking this was only necessary in the SASL offload case.

Also pushed up a test for a suspicious behaviour of the ApiVersionsFilter. That is that it does not remove unknown ApiKeys returned by the broker. If clients attempted to request these ApiKeys then Kroxylicious would throw an exception in the KafkaRequestDecoder when it's trying to determine what the ApiKey is. I think we should remove filter out unknown ApiKeys, removing them from the response.

source: gharchive/pull-request

authors: k-wall robobario

repo: kroxylicious/kroxylicious

license_type: permissive

license_source: github-api


text:
The extension doesn't work in incognito mode

Hi. After a week of using this extension, the extension has stopped working in incognito mode.
Win 10. Google Chrome 72.0.3626.96 (Official Build) (64-bit)

Hi,
I just tried with the same version as you and it worked fine.
What do you mean by "stopped working" ? Do you have an error ? Did the credentials stopped being sent ?
Is the extension allowed in incognito in the config: chrome://extensions/?id=ledpdddbhgkjamhagllpgabamgaadbff ? (if my link doesn't work, go to chrome://extensions/ and click "Details" on Mutlipass)

Hi krtek4.
I mean, that the extension I have worked in a normal browser mode and incognito mode. And the day before yesterday, this extension stopped working only in incognito mode. Data for HTTP not automatically filled in incognito mode but there're no any errors.

As far as I know, there are no differences between normal and incognito that could explain this.
Is the extension allowed in incognito ? Is the extension icon displayed in the top bar in incognito ?
Could you have any extension that modify the behavior of the browser in incognito mode ?
I tested again with multiple websites and a blank profile, the extension works fine in incognito for me on the same Chrome version.
Do you have friends and colleagues that can reproduce the faulty behavior ? Can you maybe try on another computer if the error persists ?

Yes. The extension allowed in incognito and the extension icon displayed in the top bar in incognito

I don't have any extension that modifies the behavior of the browser in incognito mode

In three of my five friends, this error is relevant

We reinstalled this extension and it didn't help.

Hi @Velikodn,
I tried again, but impossible for me to reproduce any kind of issue in incognito mode.
In order to help you debug this issue further could you provide me with the following:

Operating System you and your friends are runing
The list of websites for which the extension does not work
A screenshot of the dropdown menu opened in "normal" mode when a credential was sent (with the address bar visible), you should see a little green square on the bottom left of the icon
A screenshot of the dropdown menu opened in "incognito" mode

I'd also ask for the credentials, but I imagine this is not possible :)
I hope we can resolve this together.
Best,

Closing this as there was no further activity :)

source: gharchive/issue

license: WTFPL


text:
Clean up jobs in model cache agent

What this PR does / why we need it:
With the introduction of model cache agent, the download job is owned by the agent instead of the model cache CR, which means it would never get deleted once the model cache CR is deleted.
In this PR, the agent filter jobs by the node label and then delete jobs if the model name on the job does not exist in the LocalModelNode spec.
Which issue(s) this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close the issue(s) when PR gets merged):
Fixes #
Type of changes
Please delete options that are not relevant.

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

Feature/Issue validation/testing:
Please describe the tests that you ran to verify your changes and relevant result summary. Provide instructions so it can be reproduced.
Please also list any relevant details for your test configuration.
Added a new test case.
Manually create a model cache CR and delete it. Then make sure the jobs is removed.

Logs

Special notes for your reviewer:

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

Checklist:

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

Release note:

Re-running failed tests

/rerun-all - rerun all failed workflows.
/rerun-workflow <workflow name> - rerun a specific failed workflow. Only one workflow name can be specified. Multiple /rerun-workflow commands are allowed per comment.

/lgtm
/approve

repo: kserve/kserve


text:
3주차 실습

char을 문자를 저장할 변수 지정

double을 이용한 변수 초기화와 &&을 이용한 논리연산자

define을 이용한 매크로 설정은 다음에 해보겠습니다.

@swcho84

define을 통한 메크로 설정 후 다시해보았습니다.


text:
Git4idea deprecated cleanup

Removed usages of deprecated classes and utilities.

Merged manually.

authors: juliabeliaeva klikh

license: mit

license_source: bigquery


text:
about evaluation.py

ValueError: cannot reshape array of size 211730400 into shape (5000,36,2048)，what should I do?

I set up the wrong training epoches

repo: kuanghuei/SCAN


text:
View statistics of algorithm's pending requests in a table view

As a HKube manager I want to be able to view statistics of algorithm's pending requests in a table view, so that I can analyze the usage of HKube and hence its sizing.
User Story implementation details:
_statistics of algorithm's pending(state-received) requests means: _
1 Amount of algorithm's pending requests per minute
2 Maximum number of algorithm's pending requests in the chosen time frame
3. Each of the statistics information will be calculated separately per algorithm type.
4. Table view is detailed in #107

The user story was cancelled

The UC is cancelled

repo: kube-HPC/hkube

license: MIT


text:
The authorization cache key is only the user when it should be user+group+version+ns+action

If the first SAR allows the user to perform the action, the user will be allowed to do whatever request afterwards until the cache expires.
The same happens the other way around, if the first request of the user is denied, by a SAR, the rest of the requests of the user will be denied even if they have permission to do it.
I bwlieve we should store in the key cache all the following params:

user
group
version
namespace
action

I was thinking this while I was reviewing your PR about changing the verb for the SAR. This makes sense to me.

repo: kubearchive/kubearchive


text:
edgedns use node-local cache DNS

The kubernetes plugin of coredns is heavy on the edge, so we turned this plugin off.

/lgtm
/approve

authors: Poorunga khalid-jobs

repo: kubeedge/edgemesh


text:
Add Mapper SDK

What type of PR is this?
/kind feature
What this PR does / why we need it:
mapper SDK helps developers reduce the workload of developing mapper.
Which issue(s) this PR fixes:
Fixes https://github.com/kubeedge/mappers-go/issues/69
Special notes for your reviewer:

You can find more details in docs.
You can find a demo named virtualdevice-sdk in mappers/virtualdevice-sdk

hello, Qi @QiQi-OvO  . your commit should be provided with sign-off information. you can try to re-commit with this command git commit -s -m "XXX" or git commit -s --amend  and push your commit again.

/test all

@fisherxu please help to review this pr. thanks.

@chendave @fisherxu please help to review this pr. thanks.

authors: QiQi-OvO RyanZhaoXB

repo: kubeedge/mappers-go


text:
Add information on how to use Kubefirst with the cloud on the main branch in CONTRIBUTING.md

What type of suggestions?
Missing Information
What page is concerned?
https://github.com/kubefirst/kubefirst/blob/main/CONTRIBUTING.md
What is the issue?
Add information on how to use Kubefirst with the cloud on the main branch for contributors.
Code of Conduct

[X] I agree to follow this project's Code of Conduct

I have no idea what I meant by this 🤦♂

repo: kubefirst/docs


text:
Add goswamig to the member list

List of contributions:
Pipeline
https://github.com/kubeflow/pipelines/pull/3889
https://github.com/kubeflow/pipelines/pull/3865
https://github.com/kubeflow/pipelines/pull/3791
https://github.com/kubeflow/pipelines/pull/3792
https://github.com/kubeflow/pipelines/pull/3598
Websites
https://github.com/kubeflow/website/pull/3019
https://github.com/kubeflow/website/pull/1916

Thanks for your contribution!
/lgtm
/approve

authors: goswamig james-jwu

repo: kubeflow/internal-acls


text:
Cut Release 0.5.0-rc1 for torchserve integration test

Special notes for your reviewer:

Cut 0.5.0-rc1 release for testing torchserve integration https://github.com/kubeflow/kfserving/pull/1161
Merging logger to agent image https://github.com/kubeflow/kfserving/pull/1223
Kafka event source fixes https://github.com/kubeflow/kfserving/pull/1238

Release note:

Please see comment inline and provide clarification if entry for TorchServe needs to be added here as well

@chauhang it is already added here by @jagadeeshi2i , the generated release should already include it.

/test kubeflow-kfserving-presubmit-e2e

/LGTM

authors: yuzisun yuzliu

repo: kubeflow/kfserving


text:
Update pipeline API version

There is no change between 0.1.20 and 0.1.23
/assign @sarahmaddox

This change is

Thanks! Wow, all that work and it turns out to be just a 2-character change. :)
Fixes https://github.com/kubeflow/website/issues/992
/lgtm
/approve

authors: IronPan sarahmaddox

repo: kubeflow/website


text:
Katib: Update namespace in getting started guide

We discussed that we want to keep kubeflow namespace in Getting Started example, so users don't see errors who install Katib standalone.
/assign @tenzen-y @helenxie-bit @johnugeorge

It seems that I'm not approver in this docs directory.

@tenzen-y Feel free to open PR to update this OWNERs file: https://github.com/kubeflow/website/blob/master/content/en/docs/components/katib/OWNERS
/approve

authors: andreyvelich tenzen-y


text:
feat: Provide operating system from config

What this PR does / why we need it:
Many RHEL rebuilds are floating around and they all can be treated equal as "centos" for example.
Does this PR introduce a user-facing change?:

Provide operating system from config

/retest

/retest

@xmudrii rebased the PR against current master

repo: kubermatic/kubeone


text:
client dependencies are updated to v1.24.0

[x] kubernetes client dependencies are updated to v1.24.0

Signed-off-by: Humble Chirammal hchiramm@redhat.com

/kind cleanup

NONE

/assign @xing-yang
/assign @bswartz

/lgtm
/approve

authors: humblec xing-yang

repo: kubernetes-csi/lib-volume-populator


text:
Use kubernetes-client/gen generators to generate python client

ref: #243

Looks good, just one tiny typo. Haven't tried it though. We can let this merge and then fixup any issues. Will try to run it later this week

Thanks. I also removed unused files too (the ones that duplicates gen repo like preprocessing script). It is working, but I need to update third party resources in the gen repo. I am going to move the https://github.com/kubernetes-incubator/client-python/pull/283 to gen repo.

LGTM 👍

authors: dims mbohlool

repo: kubernetes-incubator/client-python


text:
Token expired and kube-aws exited when updating all instances

Hello.
I've hit an issue today while trying to update my cluster composed of 90 instances and two nodepools. I wanted to update the instance family of both nodepools, hence requiring a slow replacement of all the instances running.
Around exactly one hour later, kube-aws exited with error code 2 and showing the following message:
Error: Error updating cluster: ExpiredToken: The security token included in the request is expired
	status code: 403, request id: 901b76e8-814b-11e9-82e1-f33a99ce5b0c

However the upgrading process did not immediately stop on AWS side and I thought it was all going good, but suddently:
The following resource(s) failed to update: [Workers].

Received 24 SUCCESS signal(s) out of 37. Unable to satisfy 100% MinSuccessfulInstancesPercent requirement

Not sure if I understand the full picture but I guess that if kube-aws handled the token renewal gracefully instead of crashing, it would not happen.
FWIW, I'm using kube-aws v0.9.9 and I am aware that this is pretty old now (1.5 years at the time of writing this) but I have dug into the code and haven't found any change since then to handle expired tokens in the master branch.

The following workaround worked for me:

In kube-aws, add new nodepools
In AWS, scale up new autoscaling groups to the same value as old autoscaling groups
In AWS, scale down old autoscaling groups to 0, so that workloads get migrated to the new ones (this might take a while)
In kube-aws, remove old nodepools

Hey @PabloCastellano,
You're right, this looks like it may be an issue still. Want to take a crack at fixing it?

@dominicgunn I'm happy to help but I need some guidance. Where in the code would you handle the token renewal?

Sorry for taking a while to get back to you @PabloCastellano,
I'd take a look at awsconn.go, and perhaps cluster.go.
awsconn.go is currently responsible for creating the session, to it may make sense to try and provide some functionality there for ensuring it doesn't expire to keep as much of the session code in one place as possible.

/remove-lifecycle stale

authors: PabloCastellano dominicgunn

repo: kubernetes-incubator/kube-aws


text:
Local volume provisioner: tolerate NoSchedule

May be needed to create volumes on tainted nodes.

cla signed
On Mon, Jun 11, 2018 at 7:24 PM, k8s-ci-robot notifications@github.com
wrote:

Thanks for your pull request. Before we can look at your pull request,
you'll need to sign a Contributor License Agreement (CLA).
📝 Please follow instructions at
https://git.k8s.io/community/CLA.md#the-contributor-license-agreement
https://git.k8s.io/community/CLA.md#the-contributor-license-agreement to
sign the CLA.
It may take a couple minutes for the CLA signature to be fully registered;
after that, please reply here with a new comment and we'll verify. Thanks.

If you've already signed a CLA, it's possible we don't have your
GitHub username or you're using a different email address. Check your
existing CLA data and verify that your email is set on your git commits
https://help.github.com/articles/setting-your-email-in-git/.
If you signed the CLA as a corporation, please sign in with your
organization's credentials at https://identity.
linuxfoundation.org/projects/cncf
https://identity.linuxfoundation.org/projects/cncf to be authorized.
If you have done the above and are still having issues with the CLA
being reported as unsigned, please email the CNCF helpdesk:
helpdesk@rt.linuxfoundation.org helpdesk@rt.linuxfoundation.org

Instructions for interacting with me using PR comments are available here
https://git.k8s.io/community/contributors/guide/pull-requests.md. If
you have questions or suggestions related to my behavior, please file an
issue against the kubernetes/test-infra
https://github.com/kubernetes/test-infra/issues/new?title=Prow issue:
repository. I understand the commands that are listed here
https://go.k8s.io/bot-commands.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/kubernetes-incubator/kubespray/pull/2871#issuecomment-396417632,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AMYmOA8RSLv_Z52Za4shU35Ukkolo6CNks5t7vxKgaJpZM4Uji7f
.

I think, tolerations, nodeSelector and resources should be configurable for all kubernetes apps.

ci check this

ci check this

authors: chadswen fritchie oleh-ozimok

repo: kubernetes-incubator/kubespray


text:
Proposal: Consolidate Auth Info types into a single type

I propose that we consolidate these types into a single type. Dealing with the separately is a pain, and isn't providing any value.
type ClusterServiceBrokerAuthInfo struct {
	// ClusterBasicAuthConfigprovides configuration for basic authentication.
	Basic *ClusterBasicAuthConfig `json:"basic,omitempty"`
	// ClusterBearerTokenAuthConfig provides configuration to send an opaque value as a bearer token.
	// The value is referenced from the 'token' field of the given secret.  This value should only
	// contain the token value and not the `Bearer` scheme.
	Bearer *ClusterBearerTokenAuthConfig `json:"bearer,omitempty"`
}

type ServiceBrokerAuthInfo struct {
	// BasicAuthConfig provides configuration for basic authentication.
	Basic *BasicAuthConfig `json:"basic,omitempty"`
	// BearerTokenAuthConfig provides configuration to send an opaque value as a bearer token.
	// The value is referenced from the 'token' field of the given secret.  This value should only
	// contain the token value and not the `Bearer` scheme.
	Bearer *BearerTokenAuthConfig `json:"bearer,omitempty"`
}

type ClusterBearerTokenAuthConfig ...
type BearerTokenAuthConfig ...
type ClusterBasicAuthConfig ...
type BasicAuthConfig ...

Seems like it's all driven by the ObjectReference vs. LocalObjectReference deep within the final object graph. What if we implemented an interface or two on top of those and then used type assertions to get at the namespace if necessary? That way we could collapse a bunch of types and make it much easier for people to work with our API. Thoughts?

solid idea, makes sense to me

Cool, I'll take a stab at it and cc you on the PR.

repo: kubernetes-incubator/service-catalog


text:
List requests should return an empty array for items and not null

Example, if I request a list of service classes and there are none, the response should not have items: null it should have items: [] to be consistent with all k8s APIs.

@jpeeler interest in this?

I'll take it.

remember to add a test for it as well.

@jpeeler @pmorie can you add a milestone to this issue?

authors: MHBauer arschles jpeeler jwforres pmorie


text:
Implement orphan mitigation for instances

Orphan mitigation refers to cleaning up instances (and bindings) that may be in an 'orphaned' state, ie: broker operation timed out or failed, but work may have been done that needs to be cleaned up to ensure resources are not allocated but remain unutilized.  See the relevant portion of the OSB spec here.
Depends on #967 to implement correctly.
This is a must-have for beta, setting milestone accordingly.

I am going to take this one, self-assigning.

Proposal
Orphan mitigation for instances is performed when:

A provision call times out
A provision call returns 408
A provision call returns 2xx besides 200, 201, 202
A provision call returns 500

In this situation, the controller should delete the resource it created and continue trying to delete it until the broker responds with a success.
API expressions
When it is detected that orphan mitigation is required, the controller should set the ready condition to be false with a message and reason indicating orphan mitigation is required.
There should be an orphan mitigation condition that is also set with information about the orphan mitigation operation. (parity with async operations).
In order to ensure that the controller will correctly continue processing orphan mitigation until the broker returns success, there should be a status field added that represents whether orphan mitigation is in progress.
type ServiceInstanceStatus struct {
	// other fields omitted
	OrphanMitigationInProgress bool
}

OSB Clarification Required
Must Orphan mitigation be done using plan in the original request?
If so, it means that the plan must be stored for async provision operations:
type ServiceInstanceStatus struct {
	// other fields omitted

	// OrphanMitigationInProgress indicates that the controller
	// is currently cleaning up instances that may not have
	// been correctly created.
	OrphanMitigationInProgress bool

	// AsyncOperationPlan is the plan that the
	// instance was on in the current async operation.
	AsyncOperationPlan *string
}

Closed by #1248


text:
Update incorrect port

Update incorrect port in walkthrough

Oh wow, k8s bot is sizing things for us now.

authors: MHBauer mengqiy


text:
Follow constant convention for ErrorWithOriginatingIdentityReason

This PR is a

[ ] Feature Implementation
[ x ] Bug Fix
[ ] Documentation

What this PR does / why we need it:
All ServiceCatalog condition reasons are written in camel case, without spaces.
But errorwithOriginatingIdentity contains spaces.
Which issue(s) this PR fixes

Fixes #2530
Please leave this checklist in the PR comment so that maintainers can ensure a good PR.
Merge Checklist:

[ ] New feature

[ ] Tests
[ ] Documentation

[ ] SVCat CLI flag
[ ] Server Flag for config

[ ] Chart changes
[ ] removing a flag by marking deprecated and hiding to avoid
breaking the chart release and existing clients who provide a
flag that will get an error when they try to update

/ok-to-test

/lgtm
/approve

variable itself seems incorrectly named. not a reason or a message

Agreed @MHBauer , there are several similar variables here in the same situation.

@mhbauer, @jboyd01 see https://github.com/kubernetes-incubator/service-catalog/pull/2519


text:
replace haproxy with envoy (static configuration)

Switching to envoy will give us more features and also the capacity to configure remotely the loadbalancers
Fixes: #58, #57

Kubernetes e2e suite: [It] [sig-network] LoadBalancers should not have connectivity disruption during rolling update with externalTrafficPolicy=Cluster [Slow]

it is failing in all jobs that means most probably the healtchecker is not working

ok, found the bug, it was on the configuration , envoy has some hot restart mechanism that capture the HUP signal and does not allow to get the new config
Alos tested UDP and it works fine

And affinity working too ... added also examples and improve the resilience ... nice experience to learn the envoy APIs , super powerful and expressive though the documentation is super complex

green, I want to merge to unblock the CI testing, this way we can move on

repo: kubernetes-sigs/cloud-provider-kind


text:
🐛 add execution permission to ./scripts/ci-make.sh

What this PR does / why we need it:
Currently CI fails with
+ ./scripts/ci-make.sh /usr/local/bin/runner.sh: line 114: ./scripts/ci-make.sh: Permission denied
+ EXIT_VALUE=126

This PR adds mission permission to the script.

/retest

/cherry-pick release-0.3

We need this for release-0.3 as well https://github.com/kubernetes-sigs/cluster-api-operator/pull/147

repo: kubernetes-sigs/cluster-api-operator


text:
Add flag to allow userdata to be uncompressed

Issue #, if available: #215
Description of changes:
This PR adds a boolean flag to the CloudstackMachine spec that allows userdata to be uncompressed. This is required for ignition support (Flatcar f.e.)
Please let me know if this is complete, this is my first PR that touches the api.
Testing performed:
Compiled and build new CAPC container image (which also includes the changes from #214 btw), tested using kind and Cloudstack 4.17 using Flatcar stable 3374.2.3. Was able to spin up a full cluster using 3 control plane nodes and 2 workers.
I used the feature flag export EXP_KUBEADM_BOOTSTRAP_FORMAT_IGNITION=true and the following cluster template:
---
apiVersion: cluster.x-k8s.io/v1beta1
kind: Cluster
metadata:
  name: ${CLUSTER_NAME}
spec:
  clusterNetwork:
    pods:
      cidrBlocks:
        - 192.168.0.0/16
    serviceDomain: cluster.local
  infrastructureRef:
    apiVersion: infrastructure.cluster.x-k8s.io/v1beta2
    kind: CloudStackCluster
    name: ${CLUSTER_NAME}
  controlPlaneRef:
    kind: KubeadmControlPlane
    apiVersion: controlplane.cluster.x-k8s.io/v1beta1
    name: ${CLUSTER_NAME}-control-plane
---
apiVersion: infrastructure.cluster.x-k8s.io/v1beta2
kind: CloudStackCluster
metadata:
  name: ${CLUSTER_NAME}
spec:
  controlPlaneEndpoint:
    host: ${CLUSTER_ENDPOINT_IP}
    port: ${CLUSTER_ENDPOINT_PORT}
  failureDomains:
    - name: ${CLOUDSTACK_FD1_NAME=failure-domain-1}
      acsEndpoint:
        name: ${CLOUDSTACK_FD1_SECRET_NAME=cloudstack-credentials}
        namespace: ${CLOUDSTACK_FD1_SECRET_NAMESPACE=default}
      zone:
        name: ${CLOUDSTACK_ZONE_NAME}
        network:
          name: ${CLOUDSTACK_NETWORK_NAME}
---
apiVersion: controlplane.cluster.x-k8s.io/v1beta1
kind: KubeadmControlPlane
metadata:
  name: "${CLUSTER_NAME}-control-plane"
spec:
  kubeadmConfigSpec:
    format: ignition
    ignition:
      containerLinuxConfig:
        additionalConfig: |
          systemd:
            units:
            - name: kubeadm.service
              enabled: true
              dropins:
              - name: 10-flatcar.conf
                contents: |
                  [Unit]
                  Requires=containerd.service coreos-metadata.service
                  After=containerd.service coreos-metadata.service
                  [Service]
                  EnvironmentFile=/run/metadata/flatcar
            - name: coreos-metadata.service
              dropins:
              - name: 20-clct-provider-override.conf
                contents: |
                  [Service]
                  Environment=COREOS_METADATA_OPT_PROVIDER=--provider=cloudstack-metadata
            - name: coreos-metadata-sshkeys@.service
              enabled: true
              dropins:
              - name: 20-clct-provider-override.conf
                contents: |
                  [Service]
                  Environment=COREOS_METADATA_OPT_PROVIDER=--provider=cloudstack-metadata
    initConfiguration:
      nodeRegistration:
        kubeletExtraArgs:
          provider-id: "cloudstack:///$${COREOS_CLOUDSTACK_INSTANCE_ID}"
        name: $${COREOS_CLOUDSTACK_HOSTNAME}
    joinConfiguration:
      nodeRegistration:
        kubeletExtraArgs:
          provider-id: "cloudstack:///'$${COREOS_CLOUDSTACK_INSTANCE_ID}'"
        name: $${COREOS_CLOUDSTACK_HOSTNAME}
    preKubeadmCommands:
      - export COREOS_CLOUDSTACK_HOSTNAME=$${COREOS_CLOUDSTACK_HOSTNAME%.*}
      - export COREOS_CLOUDSTACK_INSTANCE_ID=$${COREOS_CLOUDSTACK_INSTANCE_ID%.*}
      - envsubst < /etc/kubeadm.yml > /etc/kubeadm.yml.tmp
      - mv /etc/kubeadm.yml.tmp /etc/kubeadm.yml
  machineTemplate:
    infrastructureRef:
      kind: CloudStackMachineTemplate
      apiVersion: infrastructure.cluster.x-k8s.io/v1beta2
      name: "${CLUSTER_NAME}-control-plane"
  replicas: ${CONTROL_PLANE_MACHINE_COUNT}
  version: ${KUBERNETES_VERSION}
---
apiVersion: infrastructure.cluster.x-k8s.io/v1beta2
kind: CloudStackMachineTemplate
metadata:
  name: ${CLUSTER_NAME}-control-plane
spec:
  template:
    spec:
      sshKey: ${CLOUDSTACK_SSH_KEY_NAME}
      uncompressedUserData: true
      offering:
        name: ${CLOUDSTACK_CONTROL_PLANE_MACHINE_OFFERING}
      template:
        name: ${CLOUDSTACK_TEMPLATE_NAME}
---
apiVersion: cluster.x-k8s.io/v1beta1
kind: MachineDeployment
metadata:
  name: "${CLUSTER_NAME}-md-0"
spec:
  clusterName: "${CLUSTER_NAME}"
  replicas: ${WORKER_MACHINE_COUNT}
  selector:
    matchLabels: null
  template:
    spec:
      clusterName: "${CLUSTER_NAME}"
      version: ${KUBERNETES_VERSION}
      bootstrap:
        configRef:
          apiVersion: bootstrap.cluster.x-k8s.io/v1beta1
          kind: KubeadmConfigTemplate
          name: "${CLUSTER_NAME}-md-0"
      infrastructureRef:
        name: "${CLUSTER_NAME}-md-0"
        apiVersion: infrastructure.cluster.x-k8s.io/v1beta2
        kind: CloudStackMachineTemplate
---
apiVersion: infrastructure.cluster.x-k8s.io/v1beta2
kind: CloudStackMachineTemplate
metadata:
  name: ${CLUSTER_NAME}-md-0
spec:
  template:
    spec:
      sshKey: ${CLOUDSTACK_SSH_KEY_NAME}
      uncompressedUserData: true
      offering:
        name: ${CLOUDSTACK_WORKER_MACHINE_OFFERING}
      template:
        name: ${CLOUDSTACK_TEMPLATE_NAME}
---
apiVersion: bootstrap.cluster.x-k8s.io/v1beta1
kind: KubeadmConfigTemplate
metadata:
  name: ${CLUSTER_NAME}-md-0
spec:
  template:
    spec:
      joinConfiguration:
        nodeRegistration:
          kubeletExtraArgs:
            provider-id: "cloudstack:///$${COREOS_CLOUDSTACK_INSTANCE_ID}"
          name: $${COREOS_CLOUDSTACK_HOSTNAME}
      preKubeadmCommands:
        - export COREOS_CLOUDSTACK_HOSTNAME=$${COREOS_CLOUDSTACK_HOSTNAME%.*}
        - export COREOS_CLOUDSTACK_INSTANCE_ID=$${COREOS_CLOUDSTACK_INSTANCE_ID%.*}
        - envsubst < /etc/kubeadm.yml > /etc/kubeadm.yml.tmp
        - mv /etc/kubeadm.yml.tmp /etc/kubeadm.yml
      format: ignition
      ignition:
        containerLinuxConfig:
          additionalConfig: |
            systemd:
              units:
              - name: kubeadm.service
                enabled: true
                dropins:
                - name: 10-flatcar.conf
                  contents: |
                    [Unit]
                    Requires=containerd.service coreos-metadata.service
                    After=containerd.service coreos-metadata.service
                    [Service]
                    EnvironmentFile=/run/metadata/flatcar
              - name: coreos-metadata.service
                dropins:
                - name: 20-clct-provider-override.conf
                  contents: |
                    [Service]
                    Environment=COREOS_METADATA_OPT_PROVIDER=--provider=cloudstack-metadata
              - name: coreos-metadata-sshkeys@.service
                enabled: true
                dropins:
                - name: 20-clct-provider-override.conf
                  contents: |
                    [Service]
                    Environment=COREOS_METADATA_OPT_PROVIDER=--provider=cloudstack-metadata

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

Is there anything i can do to move this forward? Are you OK with my comments?

/retest

@jweite-amazon I don't know how to fix these tests. It looks like the Go version of the tests is too old. Can you assist?

authors: hrak jweite-amazon


text:
1197: adding rm --dl (--deletelog) option

What type of PR is this?
/kind feature

What this PR does / why we need it:
Container log files are not deleted by the runtime, but the user might want to remove them alongside the container.
This PR introduces a new option to the rm command to delete the container log file and its rotations.
Failing to delete files doesn't fail the command and is only logged.
Which issue(s) this PR fixes:
Fixes #1197

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

Added `--deletelog, --dl` option to the `rm` command to also delete the container's log file.

@fformica, thank you for taking this on! Appreciated.
However, we can have a different spin on the problem at hand.
Generally, most of the time, users want to get everything (all the created artefacts) removed once the container is deleted, including the log files.
This should be the default behaviour, and it would follow the principle of least surprise here.
Now, the different spin I mentioned, would be now having an option to not delete logs, if requested. This would allow users to preserve log files should these be needed for something.
So we would have crictl rm --keep-logs or perhaps crictl rm --preseve-logs instead here.
What do you think?
@saschagrunert, thoughts?

I agree having it the other way around makes more sense. We just have to double check that we do not break anything in CI, and a highlighted release note that this is now the default behavior should be included.

Thanks for the feedback!
Side note, it looks like containerd currently doesn't set logPath, so I'll test that a bit (#1197 was observed on OpenShift).

@fformica do we need to change / enhance docs for this?

The crictl documentation doesn't explore the options for every command, so I don't think it's necessary to document this separately; I'm not sure though, so let me know if there's anything you think should be updated.

/approve
/lgtm

Sorry 😭 I only just noticed that by adding the dot I excluded the current log file...

No worries. 👍
Might be good to do some manual testing to confirm things work as expected.

authors: fformica kwilczynski saschagrunert

repo: kubernetes-sigs/cri-tools


text:
Update README.md

Fix dead link.

end

end

/lgtm

/lgtm

repo: kubernetes-sigs/descheduler


text:
Arguments not recognized

We are using E2E 0.0.4 on https://github.com/K8sbykeshed/k8s-service-lb-validator
I'm using go test ./... -args --skip-labels="type=cluster_ip" to skip tests with this label, but receiving the following error:
{"level":"info","ts":1637161494.262519,"caller":"matrix/manager.go:227","msg":"Server is ready","case":"81->80,TCP"}
flag provided but not defined: -skip-labels
Usage of /tmp/go-build1250012764/b001/k8s-service-lb-validator.test:
  -test.bench regexp
    	run only benchmarks matching regexp
  -test.benchmem
    	print memory allocations for benchmarks
  -test.benchtime d
    	run each benchmark for duration d (default 1s)
  -test.blockprofile file
    	write a goroutine blocking profile to file
  -test.blockprofilerate rate
    	set blocking profile rate (see runtime.SetBlockProfileRate) (default 1)
  -test.count n
    	run tests and benchmarks n times (default 1)
  -test.coverprofile file
    	write a coverage profile to file
  -test.cpu list

Wondering if some wrong bootstrap in our codebase.

missed the correct configuration from  the example: cfg, err := envconf.NewFromFlags(), this should fix the issue


text:
Add cli argument --disable-enforced-types

This kinda implements the request made in #104, as it makes it possible to disable the default enforced types roles and rolebindings with an additional cli argument --disable-enforced-types that can be used with the hnc-manager. The old behaviour (using enforcedTypes) is the default.
Tested: added new e2e tests and checked them against a vanilla k8s cluster. No issues found.

I'll try to implement the per-object-level filtering proposed by @adrianludwin in https://github.com/kubernetes-sigs/hierarchical-namespaces/issues/104#issuecomment-946865077 in another PR soon.
If there are any issues with this PR, please let me know. This being my first contribution to a k8s / cncf project, I've probably missed something ;)

Hmm, do we still need this if we have #125 ? I far prefer #125 to this change.

As discussed on #125 , we'll go with that solution instead of this one.
/close

authors: adrianludwin nobbs

repo: kubernetes-sigs/hierarchical-namespaces


text:
Add unit tests for ipvs backend

Unit tests need to be added for ipvs backend - https://github.com/kubernetes-sigs/kpng/tree/master/backends/ipvs-as-sink
For reference: Unit tests in ipvs mode for kube proxy - https://github.com/kubernetes/kubernetes/tree/master/pkg/proxy/ipvs

/assign

/cc @shaneutt

@yashsingh74 it sounded like at one point in the past you wanted to take this one on, is that still the case? Let us know if you're OK with us assigning someone else. :vulcan_salute:

authors: rajaskakodkar shaneutt yashsingh74

repo: kubernetes-sigs/kpng


text:
Replace direct modification of cohort resources in flavorassigner_test

What type of PR is this?
/kind cleanup

What this PR does / why we need it:
Avoid overriding CohortResources fields manually, set capacity and usage via ClusterQueues.
Which issue(s) this PR fixes:

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

NONE

/ok-to-test

/assign @gabesaba

Please update description with fixes #2502

/retest

/approve
Thanks!

authors: gabesaba mimowo mszadkow

repo: kubernetes-sigs/kueue


text:
No annotation for PodSets Info backup

What type of PR is this?
/kind cleanup

What this PR does / why we need it:
Remover the use of an annotation  for podSet info restoration.
Which issue(s) this PR fixes:

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

NONE

Can you drop the commit for finalizers? Or put it in a separate PR that we can consider for the next release?
I'm concerned that we don't have exhaustive testing around finalizers and that we are expecting the workload controllers to handle them. When dealing with finalizers, we have to consider that controllers could fail at any point, and there should be a mechanism to retry deleting the finalizers. In general, for kueue we have two scenarios: when removing jobs and when suspending jobs.
We are getting close to our target deadline for the release 0.4 and I think this PR is adding too much risk.

The finalizes are also helpful in  recovering from a "mid stop" error, essentially if a workload has the finalizer set  and isSuspended, then the restore of PodInfos and finalizer removal are done again.
If a job gets deleted, we select all of it's child workloads and remove the finalizers. This is tested in test/integration/controller/job/job_controller_test.go L1876.
But if you insist I can try to extract this in another PR

The finalizer part is now on #861

/retest

/approve
/lgtm

/retest

authors: alculquicondor trasc


text:
Add 1.26 release team shadow analysis config

Signed-off-by: leonardpahlke leonard.pahlke@googlemail.com
This PR adds the configuration for the 1.26 release team shadow application form.
cc @palnabarun

/cc @saschagrunert

Thanks @leonardpahlke !
/lgtm
/approve

authors: leonardpahlke puerco


text:
remove linters or fix em

Describe the bug. What is the current and expected behaviour?
looks like on simple PRs we get some verify/lint errors.  lets either remove the lints if unneeded or fix them.
Example https://github.com/kubernetes-sigs/windows-operational-readiness/pull/81
How to reproduce it (as minimally and precisely as possible)?
make a PR :)
As an example make a PR like the one above and you'll see the lint failures.  probably they are referencing pre-exisiting lint issues we've never tackled

/good-first-issue

I think this is already fixed.

Yes, this was fixed. Sorry I saw this late. See https://github.com/kubernetes-sigs/windows-operational-readiness/issues/78

/close

authors: jayunit100 tzifudzi yussufsh


text:
Dependency is not getting resolved while using with Helm install

Is this a request for help?:

Is this a BUG REPORT or FEATURE REQUEST? (choose one):
Bug

Version of Helm and Kubernetes:
helm version
Client: &version.Version{SemVer:"v2.8.1", GitCommit:"6af75a8fd72e2aa18a2b278cfe5c7a1c5feca7f2", GitTreeState:"clean"}
Serv

er: &version.Version{SemVer:"v2.8.1", GitCommit:"6af75a8fd72e2aa18a2b278cfe5c7a1c5feca7f2", GitTreeState:"clean"}
Which chart:
incubator/kafka
What happened:
Installing using below command say missing charts in requirements.yaml
helm install --name myzk incubator/kafka
Error: found in requirements.yaml, but missing in charts/ directory: zookeeper, schema-registry
What you expected to happen:
Install Kafka with Zookeeper dependency charts.
How to reproduce it (as minimally and precisely as possible):
Installed GKE and using Helm tarball, Added repo executed kafka charts.
Anything else we need to know:
NA

Hi,
I think this isn't bug, but one of the following scenarios:

You are trying to install the kafka chart from source code, instead from the release in the helm repo. If you want to this you have to run 'helm dependency update kafka' before installing.

You added the repo as stated in the README.md and you are trying to install from it, but since you are in /charts dir, helm first evaluates 'incubator/kafka' to the local source code directory, and thus failing for the same reason as 1. In this case you should try installing from another directory.

I got the same error when I tried to add one more sub-chart to a Helm chart
It says Error: found in requirements.yaml, but missing in charts/ directory: local-volume-provisioner, but this directory does exist and contains the sub-chart there.
helm version --tls
Client: &version.Version{SemVer:"v2.7.3", GitCommit:"27442e4cfd324d8f82f935fe0b7b492994d4c289", GitTreeState:"dirty"}
Server: &version.Version{SemVer:"v2.7.3", GitCommit:"27442e4cfd324d8f82f935fe0b7b492994d4c289", GitTreeState:"dirty"}

[root@test ]# ls
additionalFiles  david.install.log  README.md          templates             values.yaml
charts           LICENSE            requirements.lock  test.values.yaml
Chart.yaml       LICENSES           requirements.yaml  values-metadata.yaml
[root@test]# ls charts/local-volume-provisioner/
charts  Chart.yaml  local-storage-class.yaml  provisional_local_ssd_volumes.yaml  templates
[root@test]# helm install --debug . --tls -n test --values /tmp/test.values.yaml
[debug] Created tunnel using local port: '36996'

[debug] SERVER: "127.0.0.1:36996"

[debug] Original chart version: ""
[debug] Key="/root/.helm/key.pem", Cert="/root/.helm/cert.pem", CA="/root/.helm/ca.pem"

[debug] CHART PATH: /root/charts/test

Error: found in requirements.yaml, but missing in charts/ directory: local-volume-provisioner
[root@test ]#

authors: JMLizano dove-young ymallipe

repo: kubernetes/charts


text:
Typo fix in elastalert/README.md

Line 3:
"is" is missed.

/assign @mattfarina

/ok-to-test

authors: AdamDang spiffxp


text:
[wip] introduce incubator/drone

This is a re-write of #353, focusing on chart extensibility. This has not been tested on a kubernetes cluster just yet, just PR'ing this effort for other users' enjoyment.
TODO:

[ ] rewrite README.md, documenting a basic setup guide
[ ] add ingress resource to the chart

@bacongobbler Might want to add an optional ingress to enable giving it a FQDN. I have a good example of this over in the chronograf chart. Makes it easy to hook into something like nginx-ingress

Good point. I forgot to add that to the TODO list, but that is certainly on the radar. 👍

Setting up drone has a few parts:

Creating the version control webhook (GitHub,  Gitlab, etc...)
Creating DNS entry for that callback (hence the comment about using an Ingress Controller)
Creating drone server using the oauth2 data

As it is, his chart doesn't work. I think it's important to have a minimal chart that works out of the box.

Yes, I have been busy with other things... our company recently announced we were getting acquired by Microsoft so needless to say I've been super busy for the last bit :) hope to get back to a regular schedule soon so I can get back to this.

@bacongobbler  I have modified your chart to include the Ingress and the github envvars to be able to set up a simple example. @lachie83 told me to look at it and ... well, if you want my bits & bobs I can send you a PR

@bacongobbler gentle ping - hope you're able to pick this up again!

Hi! yes actually today would be a perfect day to pick this back up again. Thank you for the ping. :)

Yay! I'm excited for this one.

rebased on top of master and addressed all comments.

things to note since I last worked on this:

ingress is now a feature flag
sqlite is on by default, and WILL be lost on pod restart. This also means that the drone server is not horizontally scalable as each drone server instance has its own sqlite database. This is intentional, and admins are expected to extend the chart if they need mysql (or a PR would be nice)
README was slightly vamped to demonstrate how to install this chart

This looks great @bacongobbler. I'll try out the chart later and let you know how it goes.

@k8s-bot ok to test

@bacongobbler server pod failed to start when I tried:
$ k get po
NAME                                                          READY     STATUS             RESTARTS   AGE
kindred-seal-nginx-ingress-controller-2980483938-jc3rl        1/1       Running            0          1h
kindred-seal-nginx-ingress-default-backend-1014810329-n4rbf   1/1       Running            0          1h
nonplussed-poodle-drone-agent-1570746251-jws7v                1/1       Running            0          6s
nonplussed-poodle-drone-server-3022101740-d11rx               0/1       CrashLoopBackOff   1          6s

$ k logs nonplussed-poodle-drone-server-3022101740-d11rx
time="2017-06-10T06:53:11Z" level=error msg="sql: unknown driver \"sqlite\" (forgotten import?)"
time="2017-06-10T06:53:11Z" level=fatal msg="database connection failed"

Hey @bacongobbler, in case you weren't aware @ipedrazas put together a drone chart too, maybe useful for inspiration: https://github.com/kubecamp/drone-chart

Ping @bacongobbler

Couple of fixes done, as well as I changed the drone server to communicate with a docker-in-docker container running in the same pod as opposed to mounting the host socket from Kubernetes.

Only problem now is to document that the administrator needs to change some fields in values.yaml in order for drone to actually work. As it stands right now doing a bare install of drone will fail because no git repo is set up by default.
><> k get po
NAME                                  READY     STATUS             RESTARTS   AGE
drone-drone-agent-1938756360-wkn0n    2/2       Running            0          7m
drone-drone-server-3036973459-wk462   0/1       CrashLoopBackOff   5          7m
><> k logs drone-drone-server-3036973459-wk462
time="2017-07-06T16:57:32Z" level=fatal msg="version control system not configured"

I've added incubator/gogs as a dependency so it'll pass CI, but it appears that gogs has some issues of its own.
If anyone wants to take on this effort further, please let me know.

Whoa, I'm not sure I'd want to pull gogs in within the Drone releases we'll be creating during installation. gogs should be explicitly installed and managed in its own release. Accidentally nuking your gogs setup by removing Drone would be not great.
I assume this was meant to be an ease of use change, but I'd rather set the URL/API tokens like the other providers.

It's both an ease of use change + a way to get around how CI expects every chart to work out of the box with helm install. You can't install drone without pointing at something, so I chose something local. It's still the same experience needed to switch to github/bitbucket as before, just that there's something in the first place.
If you don't like the direction of this PR, please feel free to take it over!

Closing as stale.

authors: bacongobbler gtaylor ipedrazas jackzampolin mgoodness prydonius seanknox viglesiasce


text:
Add Snapshot support to Cinder/CSI

/kind feature
We're getting close to a consensus for the Snapshots spec in CSI:
https://github.com/container-storage-interface/spec/pull/207
Of course we'll want to implement this in the CSI driver here when it lands, but also in the meantime we'll need to implement the provider layer as well.
So, might as well start implementing an openstack_snapshots pkg and at least roughing in the CSI implementation.

/assign j-griffith

/featrue
Nice featrue!

repo: kubernetes/cloud-provider-openstack


text:
DOC: Add note about not contain blank in AZ

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

Release note:

NONE

@lingxiankong @ramineni not sure this is the right place to add ,please let me know your comments

@lingxiankong @ramineni not sure this is the right place to add ,please let me know your comments

Is it possible we also convert blank to -? The added description is not useful for the cloud admin as changing az name could involve lots of work that should be avoidable.

Is it possible we also convert blank to -? The added description is not useful for the cloud admin as changing az name could involve lots of work that should be avoidable.

Is it possible we also convert blank to -? The added description is not useful for the cloud admin as changing az name could involve lots of work that should be avoidable.

pleaes check https://github.com/kubernetes/cloud-provider-openstack/pull/1380
maybe you can comment on that issue so that we can combine the discussion together

Is it possible we also convert blank to -? The added description is not useful for the cloud admin as changing az name could involve lots of work that should be avoidable.

pleaes check https://github.com/kubernetes/cloud-provider-openstack/pull/1380
maybe you can comment on that issue so that we can combine the discussion together

Is it possible we also convert blank to -? The added description is not useful for the cloud admin as changing az name could involve lots of work that should be avoidable.

pleaes check #1380
maybe you can comment on that issue so that we can combine the discussion together

OK, it's marked as WIP, so I assumed you are still working on your side rather than ready for review and discussion.

Is it possible we also convert blank to -? The added description is not useful for the cloud admin as changing az name could involve lots of work that should be avoidable.

pleaes check #1380
maybe you can comment on that issue so that we can combine the discussion together

OK, it's marked as WIP, so I assumed you are still working on your side rather than ready for review and discussion.

Is it possible we also convert blank to -? The added description is not useful for the cloud admin as changing az name could involve lots of work that should be avoidable.

pleaes check #1380
maybe you can comment on that issue so that we can combine the discussion together

OK, it's marked as WIP, so I assumed you are still working on your side rather than ready for review and discussion.

yes, it's WIP because I hope to get some comments :) please help to comment on that, thanks

Is it possible we also convert blank to -? The added description is not useful for the cloud admin as changing az name could involve lots of work that should be avoidable.

pleaes check #1380
maybe you can comment on that issue so that we can combine the discussion together

OK, it's marked as WIP, so I assumed you are still working on your side rather than ready for review and discussion.

yes, it's WIP because I hope to get some comments :) please help to comment on that, thanks

/lgtm

/approve

authors: jichenjc lingxiankong ramineni


text:
Update sanity_test.go

ioutil.TempDir -->os.MkdirTemp,because ioutil.TempDir is deprecated
Signed-off-by: lixin18 68135097+lixin963@users.noreply.github.com

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

Release note:

NONE

/ok-to-test


text:
[release-1.30] Bump dependencies for 1.30.1

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

Release note:

NONE

/hold

/test openstack-cloud-controller-manager-e2e-test-release-130

/unhold

@zetaab @mdbooth please approve

cc @dulek

/lgtm
/approve

authors: dulek kayrus


text:
Why the rewrite directive change the matched URL code?

Hi,
We define Ingress rewrite annotation for our service. And get the nginx log below:
2016/11/16 08:42:36 [notice] 25#25: *14 rewritten data: "/action=encrypted&data=MzJ8mNJbn7G5d8dxZBSaBSMBM0dIdzC0Ovzv+TVHrfJi84M=", args: "", client: 15.107.4.151, server: shclitvm0647.hpeswlab.net, request: "GET /stproxyport/action=encrypted&data=MzJ8mNJbn7G5d8dxZBSaBSMBM0dIdzC0Ovzv%2BTVHrfJi84M%3D HTTP/1.1", host: "shclitvm0647.hpeswlab.net"
You can see that in the GET URL, the value of parameter "data" is MzJ8mNJbn7G5d8dxZBSaBSMBM0dIdzC0Ovzv%2BTVHrfJi84M%3D, but in the rewritten data, it becomes "MzJ8mNJbn7G5d8dxZBSaBSMBM0dIdzC0Ovzv+TVHrfJi84M=": %2B->+ and %3D ->=.
What happens? How can I keep it not changed?
Thanks

This is our problem. Close it.

repo: kubernetes/contrib


text:
Updated with correction for Ingress TLS spec

Documentation fix for error validating data: expected type array, for field spec.tls, got map; if you choose to ignore these errors, turn validation off with --validate=false

I signed it!

Thanks, LGTM

authors: bprashanth joonathan


text:
fix heapster-grafana-amd64 version

from non existing 4.2.0 to 4.0.2

This change is

@mmaquevice Thanks for your PR. Could you please sing the CLA. :)
According to #1624 , we have updated the heapster-grafana-amd64 image to v4.2.0. We may forget to push the corresponding image to gcr.io registry. @piosz @DirectXMan12 Could one of both of you check this? :)

needs to be @piosz -- I can't check gcr.io, AFAIK

Friendly ping @piosz :)

@marcinkubica Yes. The desired status is 4.2.0 image is also in the gcr.io. This can only be done for Google people. :)

#1689 and friends all seem to duplicate the work here.

I'll build 4.2.0 today or tomorrow. Sorry for the confusion, I was not aware of this issue.

I've build gcr.io/google-containers/heapster-grafana-amd64:v4.2.0.

repo: kubernetes/heapster


text:
Sort fileSsytemData by device

The Dashboard FileSystems change order all the time, is it possible to sort this array by the device and keep the order consistent across updates or is the order random on purpose?
see https://github.com/kubernetes/kube-ui/blob/master/master/shared/js/modules/services/cAdvisor.js#L126
var f = {
    device: data.device,
    filesystemNumber: i + 1,
    usage: data.usage,
    usageDescription: humanizeMetric(data.usage),
    capacity: data.capacity,
    capacityDescription: humanizeMetric(data.capacity),
    totalUsage: Math.floor((data.usage * 100.0) / data.capacity)
};

filesystemData.push(f);

I'd try to make the change and send a pull request, but my angular is rusty...

@so0k Ping me if you need help.

:+1: the Dashboard file system rings are basically useless on CoreOS, because of the jumping.
It would be even nicer if they showed up as the actual device/mount names, but I assume that should be a different ticket.

+1 for this.

+1

authors: SebastianM manojlds packetcollision preillyme so0k

repo: kubernetes/kube-ui


text:
kube-anywhere fails to deploy kubernetes cluster on master builds.

I am using kubernetes master builds to deploy kubernetes cluster. I see the API server fails to start on the kubernetes master. I see the following errors.
I0119 22:51:31.881006       5 interface.go:248] Default route transits interface "eth0"
I0119 22:51:31.881179       5 interface.go:93] Interface eth0 is up
I0119 22:51:31.881437       5 interface.go:138] Interface "eth0" has 2 addresses :[172.1.30.2/24 fe80::42:acff:fe01:1e02/64].
I0119 22:51:31.881474       5 interface.go:105] Checking addr  172.1.30.2/24.
I0119 22:51:31.881481       5 interface.go:114] IP found 172.1.30.2
I0119 22:51:31.881627       5 interface.go:144] valid IPv4 address for interface "eth0" found as 172.1.30.2.
I0119 22:51:31.881635       5 interface.go:254] Choosing IP 172.1.30.2
I0119 22:51:31.881660       5 services.go:51] Setting service IP to "10.0.0.1" (read-write).
I0119 22:51:31.889220       5 server.go:170] Initializing deserialization cache size based on 0MB limit
W0119 22:51:31.891010       5 config_selfclient.go:44] Failed to create secure local client, falling back to insecure local connection: failed to find certificate which matches "localhost"
I0119 22:51:31.891656       5 reflector.go:196] Starting reflector *api.ServiceAccount (0s) from k8s.io/kubernetes/plugin/pkg/admission/serviceaccount/admission.go:123
I0119 22:51:31.891708       5 reflector.go:196] Starting reflector *api.Secret (0s) from k8s.io/kubernetes/plugin/pkg/admission/serviceaccount/admission.go:143
I0119 22:51:31.891800       5 reflector.go:234] Listing and watching *api.ServiceAccount from k8s.io/kubernetes/plugin/pkg/admission/serviceaccount/admission.go:123
E0119 22:51:31.895589       5 reflector.go:199] k8s.io/kubernetes/plugin/pkg/admission/serviceaccount/admission.go:123: Failed to list *api.ServiceAccount: Get http://0.0.0.0:8080/api/v1/serviceaccounts?resourceVersion=0: dial tcp 0.0.0.0:8080: getsockopt: connection refused
I0119 22:51:31.895724       5 reflector.go:234] Listing and watching *api.Secret from k8s.io/kubernetes/plugin/pkg/admission/serviceaccount/admission.go:143
I0119 22:51:31.901574       5 reflector.go:196] Starting reflector *api.ResourceQuota (0s) from k8s.io/kubernetes/plugin/pkg/admission/resourcequota/resource_access.go:88
I0119 22:51:31.901870       5 reflector.go:234] Listing and watching *api.ResourceQuota from k8s.io/kubernetes/plugin/pkg/admission/resourcequota/resource_access.go:88
I0119 22:51:31.907498       5 server.go:328] Initializing cache sizes based on 0MB limit
I0119 22:51:31.907613       5 services.go:51] Setting service IP to "10.0.0.1" (read-write).
I0119 22:51:31.911287       5 storage_factory.go:242] storing { podtemplates} in v1, reading as __internal from { /registry [http://127.0.0.1:2379]    false 1000 <nil>}
E0119 22:51:31.913428       5 reflector.go:199] k8s.io/kubernetes/plugin/pkg/admission/serviceaccount/admission.go:143: Failed to list *api.Secret: Get http://0.0.0.0:8080/api/v1/secrets?fieldSelector=type%3Dkubernetes.io%2Fservice-account-token&resourceVersion=0: dial tcp 0.0.0.0:8080: getsockopt: connection refused
E0119 22:51:31.913898       5 reflector.go:199] k8s.io/kubernetes/plugin/pkg/admission/resourcequota/resource_access.go:88: Failed to list *api.ResourceQuota: Get http://0.0.0.0:8080/api/v1/resourcequotas?resourceVersion=0: dial tcp 0.0.0.0:8080: getsockopt: connection refused
I0119 22:51:31.916365       5 storage_factory.go:242] storing { events} in v1, reading as __internal from { /registry [http://127.0.0.1:2379]    false 1000 <nil>}
I0119 22:51:31.916529       5 compact.go:55] compactor already exists for endpoints [http://127.0.0.1:2379]
I0119 22:51:31.916593       5 storage_factory.go:242] storing { limitranges} in v1, reading as __internal from { /registry [http://127.0.0.1:2379]    false 1000 <nil>}
I0119 22:51:31.916855       5 reflector.go:234] Listing and watching *api.PodTemplate from pkg/storage/cacher.go:212
I0119 22:51:31.917040       5 compact.go:55] compactor already exists for endpoints [http://127.0.0.1:2379]
I0119 22:51:31.917425       5 storage_factory.go:242] storing { resourcequotas} in v1, reading as __internal from { /registry [http://127.0.0.1:2379]    false 1000 <nil>}
I0119 22:51:31.917589       5 compact.go:55] compactor already exists for endpoints [http://127.0.0.1:2379]
I0119 22:51:31.917607       5 reflector.go:234] Listing and watching *api.LimitRange from pkg/storage/cacher.go:212
I0119 22:51:31.917926       5 storage_factory.go:242] storing { secrets} in v1, reading as __internal from { /registry [http://127.0.0.1:2379]    false 1000 <nil>}
I0119 22:51:31.918102       5 compact.go:55] compactor already exists for endpoints [http://127.0.0.1:2379]
I0119 22:51:31.918118       5 reflector.go:234] Listing and watching *api.ResourceQuota from pkg/storage/cacher.go:212
I0119 22:51:31.918685       5 storage_factory.go:242] storing { serviceaccounts} in v1, reading as __internal from { /registry [http://127.0.0.1:2379]    false 1000 <nil>}
I0119 22:51:31.918844       5 compact.go:55] compactor already exists for endpoints [http://127.0.0.1:2379]
I0119 22:51:31.919012       5 reflector.go:234] Listing and watching *api.Secret from pkg/storage/cacher.go:212
I0119 22:51:31.919223       5 storage_factory.go:242] storing { persistentvolumes} in v1, reading as __internal from { /registry [http://127.0.0.1:2379]    false 1000 <nil>}
I0119 22:51:31.919366       5 compact.go:55] compactor already exists for endpoints [http://127.0.0.1:2379]
I0119 22:51:31.919566       5 reflector.go:234] Listing and watching *api.ServiceAccount from pkg/storage/cacher.go:212
I0119 22:51:31.919798       5 storage_factory.go:242] storing { persistentvolumeclaims} in v1, reading as __internal from { /registry [http://127.0.0.1:2379]    false 1000 <nil>}
I0119 22:51:31.919992       5 compact.go:55] compactor already exists for endpoints [http://127.0.0.1:2379]
I0119 22:51:31.920256       5 reflector.go:234] Listing and watching *api.PersistentVolume from pkg/storage/cacher.go:212
I0119 22:51:31.920393       5 storage_factory.go:242] storing { configmaps} in v1, reading as __internal from { /registry [http://127.0.0.1:2379]    false 1000 <nil>}
I0119 22:51:31.920535       5 compact.go:55] compactor already exists for endpoints [http://127.0.0.1:2379]
I0119 22:51:31.920780       5 storage_factory.go:242] storing { namespaces} in v1, reading as __internal from { /registry [http://127.0.0.1:2379]    false 1000 <nil>}
I0119 22:51:31.920912       5 reflector.go:234] Listing and watching *api.PersistentVolumeClaim from pkg/storage/cacher.go:212
I0119 22:51:31.920921       5 compact.go:55] compactor already exists for endpoints [http://127.0.0.1:2379]
I0119 22:51:31.921301       5 reflector.go:234] Listing and watching *api.ConfigMap from pkg/storage/cacher.go:212
I0119 22:51:31.921364       5 storage_factory.go:242] storing { endpoints} in v1, reading as __internal from { /registry [http://127.0.0.1:2379]    false 1000 <nil>}
I0119 22:51:31.921541       5 compact.go:55] compactor already exists for endpoints [http://127.0.0.1:2379]
I0119 22:51:31.921821       5 reflector.go:234] Listing and watching *api.Namespace from pkg/storage/cacher.go:212
I0119 22:51:31.921983       5 storage_factory.go:242] storing { nodes} in v1, reading as __internal from { /registry [http://127.0.0.1:2379]    false 1000 <nil>}
I0119 22:51:31.922131       5 compact.go:55] compactor already exists for endpoints [http://127.0.0.1:2379]
I0119 22:51:31.922357       5 reflector.go:234] Listing and watching *api.Endpoints from pkg/storage/cacher.go:212
I0119 22:51:31.922958       5 storage_factory.go:242] storing { pods} in v1, reading as __internal from { /registry [http://127.0.0.1:2379]    false 1000 <nil>}
I0119 22:51:31.923109       5 reflector.go:234] Listing and watching *api.Node from pkg/storage/cacher.go:212
I0119 22:51:31.923228       5 compact.go:55] compactor already exists for endpoints [http://127.0.0.1:2379]
I0119 22:51:31.923977       5 storage_factory.go:242] storing { services} in v1, reading as __internal from { /registry [http://127.0.0.1:2379]    false 1000 <nil>}
I0119 22:51:31.924099       5 compact.go:55] compactor already exists for endpoints [http://127.0.0.1:2379]
I0119 22:51:31.924372       5 reflector.go:234] Listing and watching *api.Pod from pkg/storage/cacher.go:212
I0119 22:51:31.925062       5 storage_factory.go:242] storing { services} in v1, reading as __internal from { /registry [http://127.0.0.1:2379]    false 1000 <nil>}
I0119 22:51:31.925224       5 reflector.go:234] Listing and watching *api.Service from pkg/storage/cacher.go:212
I0119 22:51:31.925325       5 compact.go:55] compactor already exists for endpoints [http://127.0.0.1:2379]
I0119 22:51:31.925546       5 compact.go:55] compactor already exists for endpoints [http://127.0.0.1:2379]
I0119 22:51:31.925619       5 storage_factory.go:242] storing { replicationcontrollers} in v1, reading as __internal from { /registry [http://127.0.0.1:2379]    false 1000 <nil>}
I0119 22:51:31.925848       5 compact.go:55] compactor already exists for endpoints [http://127.0.0.1:2379]
I0119 22:51:31.926805       5 reflector.go:234] Listing and watching *api.ReplicationController from pkg/storage/cacher.go:212
I0119 22:51:31.948621       5 storage_factory.go:242] storing {extensions thirdpartyresources} in extensions/v1beta1, reading as extensions/__internal from { /registry [http://127.0.0.1:2379]    false 1000 <nil>}
I0119 22:51:31.948823       5 storage_factory.go:242] storing {apps statefulsets} in apps/v1beta1, reading as apps/__internal from { /registry [http://127.0.0.1:2379]    false 1000 <nil>}
I0119 22:51:31.949469       5 compact.go:55] compactor already exists for endpoints [http://127.0.0.1:2379]
I0119 22:51:31.950421       5 master.go:317] Enabling API group "apps".
I0119 22:51:31.950500       5 master.go:317] Enabling API group "authentication.k8s.io".
I0119 22:51:31.950556       5 master.go:317] Enabling API group "authorization.k8s.io".
I0119 22:51:31.950675       5 reflector.go:234] Listing and watching *apps.StatefulSet from pkg/storage/cacher.go:212
I0119 22:51:31.950841       5 storage_factory.go:242] storing {autoscaling horizontalpodautoscalers} in autoscaling/v1, reading as autoscaling/__internal from { /registry [http://127.0.0.1:2379]    false 1000 <nil>}
I0119 22:51:31.951142       5 compact.go:55] compactor already exists for endpoints [http://127.0.0.1:2379]
I0119 22:51:31.952131       5 master.go:317] Enabling API group "autoscaling".
I0119 22:51:31.952259       5 storage_factory.go:242] storing {batch jobs} in batch/v1, reading as batch/__internal from { /registry [http://127.0.0.1:2379]    false 1000 <nil>}
I0119 22:51:31.952306       5 reflector.go:234] Listing and watching *autoscaling.HorizontalPodAutoscaler from pkg/storage/cacher.go:212
I0119 22:51:31.953125       5 compact.go:55] compactor already exists for endpoints [http://127.0.0.1:2379]
I0119 22:51:31.954074       5 master.go:317] Enabling API group "batch".
I0119 22:51:31.954387       5 reflector.go:234] Listing and watching *batch.Job from pkg/storage/cacher.go:212
I0119 22:51:31.954712       5 storage_factory.go:242] storing {certificates.k8s.io certificatesigningrequests} in certificates.k8s.io/v1alpha1, reading as certificates.k8s.io/__internal from { /registry [http://127.0.0.1:2379]    false 1000 <nil>}
I0119 22:51:31.955240       5 compact.go:55] compactor already exists for endpoints [http://127.0.0.1:2379]
I0119 22:51:31.955869       5 master.go:317] Enabling API group "certificates.k8s.io".
I0119 22:51:31.956039       5 storage_factory.go:242] storing {autoscaling horizontalpodautoscalers} in autoscaling/v1, reading as autoscaling/__internal from { /registry [http://127.0.0.1:2379]    false 1000 <nil>}
I0119 22:51:31.956144       5 reflector.go:234] Listing and watching *certificates.CertificateSigningRequest from pkg/storage/cacher.go:212
I0119 22:51:31.956351       5 compact.go:55] compactor already exists for endpoints [http://127.0.0.1:2379]
I0119 22:51:31.956561       5 storage_factory.go:242] storing { replicationcontrollers} in v1, reading as __internal from { /registry [http://127.0.0.1:2379]    false 1000 <nil>}
I0119 22:51:31.956885       5 reflector.go:234] Listing and watching *autoscaling.HorizontalPodAutoscaler from pkg/storage/cacher.go:212
I0119 22:51:31.956888       5 compact.go:55] compactor already exists for endpoints [http://127.0.0.1:2379]
I0119 22:51:31.957213       5 storage_factory.go:242] storing {extensions thirdpartyresources} in extensions/v1beta1, reading as extensions/__internal from { /registry [http://127.0.0.1:2379]    false 1000 <nil>}
I0119 22:51:31.957388       5 compact.go:55] compactor already exists for endpoints [http://127.0.0.1:2379]
I0119 22:51:31.957745       5 storage_factory.go:242] storing {extensions daemonsets} in extensions/v1beta1, reading as extensions/__internal from { /registry [http://127.0.0.1:2379]    false 1000 <nil>}
I0119 22:51:31.957988       5 compact.go:55] compactor already exists for endpoints [http://127.0.0.1:2379]
I0119 22:51:31.958061       5 reflector.go:234] Listing and watching *api.ReplicationController from pkg/storage/cacher.go:212
I0119 22:51:31.958838       5 storage_factory.go:242] storing {extensions deployments} in extensions/v1beta1, reading as extensions/__internal from { /registry [http://127.0.0.1:2379]    false 1000 <nil>}
I0119 22:51:31.959038       5 compact.go:55] compactor already exists for endpoints [http://127.0.0.1:2379]
I0119 22:51:31.959433       5 reflector.go:234] Listing and watching *extensions.DaemonSet from pkg/storage/cacher.go:212
I0119 22:51:31.972917       5 storage_factory.go:242] storing {extensions ingresses} in extensions/v1beta1, reading as extensions/__internal from { /registry [http://127.0.0.1:2379]    false 1000 <nil>}
I0119 22:51:31.973446       5 compact.go:55] compactor already exists for endpoints [http://127.0.0.1:2379]
I0119 22:51:31.973607       5 reflector.go:234] Listing and watching *extensions.Deployment from pkg/storage/cacher.go:212
I0119 22:51:31.974374       5 storage_factory.go:242] storing {extensions podsecuritypolicies} in extensions/v1beta1, reading as extensions/__internal from { /registry [http://127.0.0.1:2379]    false 1000 <nil>}
I0119 22:51:31.974510       5 compact.go:55] compactor already exists for endpoints [http://127.0.0.1:2379]
I0119 22:51:31.974868       5 reflector.go:234] Listing and watching *extensions.Ingress from pkg/storage/cacher.go:212
I0119 22:51:31.974944       5 storage_factory.go:242] storing {extensions replicasets} in extensions/v1beta1, reading as extensions/__internal from { /registry [http://127.0.0.1:2379]    false 1000 <nil>}
I0119 22:51:31.975008       5 compact.go:55] compactor already exists for endpoints [http://127.0.0.1:2379]
I0119 22:51:31.975221       5 reflector.go:234] Listing and watching *extensions.PodSecurityPolicy from pkg/storage/cacher.go:212
I0119 22:51:31.975256       5 reflector.go:234] Listing and watching *extensions.ReplicaSet from pkg/storage/cacher.go:212
I0119 22:51:31.975235       5 storage_factory.go:242] storing {extensions networkpolicies} in extensions/v1beta1, reading as extensions/__internal from { /registry [http://127.0.0.1:2379]    false 1000 <nil>}
I0119 22:51:31.975547       5 compact.go:55] compactor already exists for endpoints [http://127.0.0.1:2379]
I0119 22:51:31.975893       5 master.go:317] Enabling API group "extensions".
I0119 22:51:31.975970       5 storage_factory.go:242] storing {policy poddisruptionbudgets} in policy/v1beta1, reading as policy/__internal from { /registry [http://127.0.0.1:2379]    false 1000 <nil>}
I0119 22:51:31.976088       5 compact.go:55] compactor already exists for endpoints [http://127.0.0.1:2379]
I0119 22:51:31.976092       5 reflector.go:234] Listing and watching *extensions.NetworkPolicy from pkg/storage/cacher.go:212
I0119 22:51:31.976615       5 master.go:317] Enabling API group "policy".
I0119 22:51:31.976687       5 storage_factory.go:242] storing {rbac.authorization.k8s.io roles} in rbac.authorization.k8s.io/v1alpha1, reading as rbac.authorization.k8s.io/__internal from { /registry [http://127.0.0.1:2379]    false 1000 <nil>}
I0119 22:51:31.976865       5 compact.go:55] compactor already exists for endpoints [http://127.0.0.1:2379]
I0119 22:51:31.976726       5 reflector.go:234] Listing and watching *policy.PodDisruptionBudget from pkg/storage/cacher.go:212
I0119 22:51:31.977145       5 storage_factory.go:242] storing {rbac.authorization.k8s.io rolebindings} in rbac.authorization.k8s.io/v1alpha1, reading as rbac.authorization.k8s.io/__internal from { /registry [http://127.0.0.1:2379]    false 1000 <nil>}
I0119 22:51:31.977227       5 compact.go:55] compactor already exists for endpoints [http://127.0.0.1:2379]
I0119 22:51:31.977398       5 reflector.go:234] Listing and watching *rbac.Role from pkg/storage/cacher.go:212
I0119 22:51:31.977580       5 storage_factory.go:242] storing {rbac.authorization.k8s.io clusterroles} in rbac.authorization.k8s.io/v1alpha1, reading as rbac.authorization.k8s.io/__internal from { /registry [http://127.0.0.1:2379]    false 1000 <nil>}
I0119 22:51:31.977657       5 compact.go:55] compactor already exists for endpoints [http://127.0.0.1:2379]
I0119 22:51:31.977774       5 reflector.go:234] Listing and watching *rbac.RoleBinding from pkg/storage/cacher.go:212
I0119 22:51:31.977936       5 storage_factory.go:242] storing {rbac.authorization.k8s.io clusterrolebindings} in rbac.authorization.k8s.io/v1alpha1, reading as rbac.authorization.k8s.io/__internal from { /registry [http://127.0.0.1:2379]    false 1000 <nil>}
I0119 22:51:31.978022       5 compact.go:55] compactor already exists for endpoints [http://127.0.0.1:2379]
I0119 22:51:31.978142       5 reflector.go:234] Listing and watching *rbac.ClusterRole from pkg/storage/cacher.go:212
I0119 22:51:31.978302       5 master.go:317] Enabling API group "rbac.authorization.k8s.io".
I0119 22:51:31.978387       5 storage_factory.go:242] storing {storage.k8s.io storageclasses} in storage.k8s.io/v1beta1, reading as storage.k8s.io/__internal from { /registry [http://127.0.0.1:2379]    false 1000 <nil>}
I0119 22:51:31.978465       5 compact.go:55] compactor already exists for endpoints [http://127.0.0.1:2379]
I0119 22:51:31.978658       5 master.go:317] Enabling API group "storage.k8s.io".
I0119 22:51:31.978470       5 reflector.go:234] Listing and watching *rbac.ClusterRoleBinding from pkg/storage/cacher.go:212
I0119 22:51:31.978832       5 reflector.go:234] Listing and watching *storage.StorageClass from pkg/storage/cacher.go:212
I0119 22:51:31.998545       5 factory.go:96] Starting informer factory
I0119 22:51:31.998799       5 factory.go:100] Starting informer for *api.Namespace
I0119 22:51:31.999217       5 factory.go:100] Starting informer for *api.LimitRange
I0119 22:51:32.000154       5 reflector.go:196] Starting reflector *api.Namespace (10m0s) from pkg/controller/informers/factory.go:101
I0119 22:51:32.000499       5 reflector.go:234] Listing and watching *api.Namespace from pkg/controller/informers/factory.go:101
E0119 22:51:32.002009       5 reflector.go:199] pkg/controller/informers/factory.go:101: Failed to list *api.Namespace: Get http://0.0.0.0:8080/api/v1/namespaces?resourceVersion=0: dial tcp 0.0.0.0:8080: getsockopt: connection refused
I0119 22:51:32.002602       5 reflector.go:196] Starting reflector *api.LimitRange (10m0s) from pkg/controller/informers/factory.go:101
I0119 22:51:32.002647       5 reflector.go:234] Listing and watching *api.LimitRange from pkg/controller/informers/factory.go:101
E0119 22:51:32.003877       5 reflector.go:199] pkg/controller/informers/factory.go:101: Failed to list *api.LimitRange: Get http://0.0.0.0:8080/api/v1/limitranges?resourceVersion=0: dial tcp 0.0.0.0:8080: getsockopt: connection refused
[restful] 2017/01/19 22:51:32 log.go:30: [restful/swagger] listing is available at https://172.1.30.2:443/swaggerapi/
[restful] 2017/01/19 22:51:32 log.go:30: [restful/swagger] https://172.1.30.2:443/swaggerui/ is mapped to folder /swagger-ui/
I0119 22:51:32.141138       5 serve.go:79] Serving securely on 0.0.0.0:443
I0119 22:51:32.141378       5 serve.go:94] Serving insecurely on 0.0.0.0:8080
I0119 22:51:32.895865       5 reflector.go:234] Listing and watching *api.ServiceAccount from k8s.io/kubernetes/plugin/pkg/admission/serviceaccount/admission.go:123
I0119 22:51:32.913686       5 reflector.go:234] Listing and watching *api.Secret from k8s.io/kubernetes/plugin/pkg/admission/serviceaccount/admission.go:143
I0119 22:51:32.914414       5 reflector.go:234] Listing and watching *api.ResourceQuota from k8s.io/kubernetes/plugin/pkg/admission/resourcequota/resource_access.go:88
I0119 22:51:33.002289       5 reflector.go:234] Listing and watching *api.Namespace from pkg/controller/informers/factory.go:101
I0119 22:51:33.004067       5 reflector.go:234] Listing and watching *api.LimitRange from pkg/controller/informers/factory.go:101
I0119 22:51:52.058088       5 trace.go:61] Trace "Create /api/v1/namespaces/kube-system/pods" (started 2017-01-19 22:51:42.04873791 +0000 UTC):
[27.242µs] [27.242µs] About to convert to expected version
[8.857244ms] [8.830002ms] Conversion done
[10.009317768s] [10.000460524s] END
I0119 22:51:52.058315       5 panics.go:75] POST /api/v1/namespaces/kube-system/pods: (10.00980261s) 403 [[hyperkube/v1.6.0 (linux/amd64) kubernetes/8fa2358] 172.1.30.1:46640]
I0119 22:52:03.308605       5 trace.go:61] Trace "Create /api/v1/nodes" (started 2017-01-19 22:51:33.291306953 +0000 UTC):
[1.703632ms] [1.703632ms] About to convert to expected version
[16.396782ms] [14.69315ms] Conversion done
[16.468411ms] [71.629µs] About to store object in database
[30.017202969s] [30.000734558s] END
I0119 22:52:03.309663       5 panics.go:75] POST /api/v1/nodes: (30.018576506s) 504
goroutine 571 [running]:
k8s.io/kubernetes/vendor/k8s.io/apiserver/pkg/httplog.(*respLogger).recordStatus(0xc420dae5b0, 0x1f8)
	/go/src/k8s.io/kubernetes/_output/dockerized/go/src/k8s.io/kubernetes/vendor/k8s.io/apiserver/pkg/httplog/log.go:219 +0xbb
k8s.io/kubernetes/vendor/k8s.io/apiserver/pkg/httplog.(*respLogger).WriteHeader(0xc420dae5b0, 0x1f8)
	/go/src/k8s.io/kubernetes/_output/dockerized/go/src/k8s.io/kubernetes/vendor/k8s.io/apiserver/pkg/httplog/log.go:198 +0x35
k8s.io/kubernetes/vendor/k8s.io/apiserver/pkg/metrics.(*responseWriterDelegator).WriteHeader(0xc420f63350, 0x1f8)
	/go/src/k8s.io/kubernetes/_output/dockerized/go/src/k8s.io/kubernetes/vendor/k8s.io/apiserver/pkg/metrics/metrics.go:117 +0x45
k8s.io/kubernetes/pkg/genericapiserver/api/handlers/responsewriters.WriteObjectNegotiated(0x5ec3400, 0xc420efd440, 0x0, 0x0, 0x39e44c8, 0x2, 0x5ebc440, 0xc420deb2c0, 0xc421c5e000, 0x1f8, ...)
	/go/src/k8s.io/kubernetes/_output/dockerized/go/src/k8s.io/kubernetes/pkg/genericapiserver/api/handlers/responsewriters/writers.go:89 +0x162
k8s.io/kubernetes/pkg/genericapiserver/api/handlers/responsewriters.ErrorNegotiated(0x5e8f040, 0xc421318f00, 0x5ec3400, 0xc420efd440, 0x0, 0x0, 0x39e44c8, 0x2, 0x5ebc440, 0xc420deb2c0, ...)
	/go/src/k8s.io/kubernetes/_output/dockerized/go/src/k8s.io/kubernetes/pkg/genericapiserver/api/handlers/responsewriters/writers.go:106 +0x103
k8s.io/kubernetes/pkg/genericapiserver/api/handlers.(*RequestScope).err(0xc4209ec540, 0x5e8f040, 0xc421318f00, 0x5ebc440, 0xc420deb2c0, 0xc421c5e000)
	/go/src/k8s.io/kubernetes/_output/dockerized/go/src/k8s.io/kubernetes/pkg/genericapiserver/api/handlers/rest.go:93 +0xd7
k8s.io/kubernetes/pkg/genericapiserver/api/handlers.createHandler.func1(0xc420f63020, 0xc421c8f260)
	/go/src/k8s.io/kubernetes/_output/dockerized/go/src/k8s.io/kubernetes/pkg/genericapiserver/api/handlers/rest.go:426 +0xee2
k8s.io/kubernetes/vendor/k8s.io/apiserver/pkg/metrics.InstrumentRouteFunc.func1(0xc420f63020, 0xc421c8f260)
	/go/src/k8s.io/kubernetes/_output/dockerized/go/src/k8s.io/kubernetes/vendor/k8s.io/apiserver/pkg/metrics/metrics.go:101 +0x1f2
k8s.io/kubernetes/vendor/github.com/emicklei/go-restful.(*Container).dispatch(0xc4207cf8c0, 0x5ebc400, 0xc420dae5b0, 0xc421c5e000)
	/go/src/k8s.io/kubernetes/_output/dockerized/go/src/k8s.io/kubernetes/vendor/github.com/emicklei/go-restful/container.go:272 +0xba0
k8s.io/kubernetes/vendor/github.com/emicklei/go-restful.(*Container).(k8s.io/kubernetes/vendor/github.com/emicklei/go-restful.dispatch)-fm(0x5ebc400, 0xc420dae5b0, 0xc421c5e000)
	/go/src/k8s.io/kubernetes/_output/dockerized/go/src/k8s.io/kubernetes/vendor/github.com/emicklei/go-restful/container.go:120 +0x48
net/http.HandlerFunc.ServeHTTP(0xc4212347c0, 0x5ebc400, 0xc420dae5b0, 0xc421c5e000)
	/usr/local/go/src/net/http/server.go:1726 +0x44
net/http.(*ServeMux).ServeHTTP(0xc420d54ab0, 0x5ebc400, 0xc420dae5b0, 0xc421c5e000)
	/usr/local/go/src/net/http/server.go:2022 +0x7f
k8s.io/kubernetes/pkg/genericapiserver/api/filters.WithAuthorization.func1(0x5ebc400, 0xc420dae5b0, 0xc421c5e000)
	/go/src/k8s.io/kubernetes/_output/dockerized/go/src/k8s.io/kubernetes/pkg/genericapiserver/api/filters/authorization.go:50 +0x365
net/http.HandlerFunc.ServeHTTP(0xc42013c500, 0x5ebc400, 0xc420dae5b0, 0xc421c5e000)
	/usr/local/go/src/net/http/server.go:1726 +0x44
k8s.io/kubernetes/pkg/genericapiserver/api/filters.WithImpersonation.func1(0x5ebc400, 0xc420dae5b0, 0xc421c5e000)
	/go/src/k8s.io/kubernetes/_output/dockerized/go/src/k8s.io/kubernetes/pkg/genericapiserver/api/filters/impersonation.go:47 +0x1e4d
net/http.HandlerFunc.ServeHTTP(0xc42013c540, 0x5ebc400, 0xc420dae5b0, 0xc421c5e000)
	/usr/local/go/src/net/http/server.go:1726 +0x44
k8s.io/kubernetes/pkg/auth/handlers.WithAuthentication.func1(0x5ebc400, 0xc420dae5b0, 0xc421c5e000)
	/go/src/k8s.io/kubernetes/_output/dockerized/go/src/k8s.io/kubernetes/pkg/auth/handlers/handlers.go:73 +0x2c2
net/http.HandlerFunc.ServeHTTP(0xc42083da90, 0x5ebc400, 0xc420dae5b0, 0xc421c5e000)
	/usr/local/go/src/net/http/server.go:1726 +0x44
k8s.io/kubernetes/vendor/k8s.io/apiserver/pkg/request.WithRequestContext.func1(0x5ebc400, 0xc420dae5b0, 0xc421c5e000)
	/go/src/k8s.io/kubernetes/_output/dockerized/go/src/k8s.io/kubernetes/vendor/k8s.io/apiserver/pkg/request/requestcontext.go:107 +0xef
net/http.HandlerFunc.ServeHTTP(0xc420f26780, 0x5ebc400, 0xc420dae5b0, 0xc421c5e000)
	/usr/local/go/src/net/http/server.go:1726 +0x44
k8s.io/kubernetes/pkg/genericapiserver/filters.WithPanicRecovery.func1(0x5ebc400, 0xc420dae5b0, 0xc421c5e000)
	/go/src/k8s.io/kubernetes/_output/dockerized/go/src/k8s.io/kubernetes/pkg/genericapiserver/filters/panics.go:74 +0x24a
net/http.HandlerFunc.ServeHTTP(0xc420d55980, 0x7f9fda741298, 0xc420deb2b0, 0xc421c5e000)
	/usr/local/go/src/net/http/server.go:1726 +0x44
k8s.io/kubernetes/pkg/genericapiserver/filters.(*timeoutHandler).ServeHTTP.func1(0xc420f26820, 0x5ec4800, 0xc420deb2b0, 0xc421c5e000, 0xc421c8f200)
	/go/src/k8s.io/kubernetes/_output/dockerized/go/src/k8s.io/kubernetes/pkg/genericapiserver/filters/timeout.go:89 +0x8d
created by k8s.io/kubernetes/pkg/genericapiserver/filters.(*timeoutHandler).ServeHTTP
	/go/src/k8s.io/kubernetes/_output/dockerized/go/src/k8s.io/kubernetes/pkg/genericapiserver/filters/timeout.go:91 +0x1db

logging error output: "k8s\x00\n\f\n\x02v1\x12\x06Status\x12`\n\x04\n\x00\x12\x00\x12\aFailure\x1a9Timeout: request did not complete within allowed duration\"\aTimeout*\b\n\x00\x12\x00\x1a\x00(\x000\xf8\x03\x1a\x00\"\x00"
 [[hyperkube/v1.6.0 (linux/amd64) kubernetes/8fa2358] 172.1.30.1:56340]
I0119 22:52:03.395184       5 panics.go:75] PATCH /api/v1/namespaces/default/events/master.149b4d10d6e92d77: (30.002676558s) 504
goroutine 559 [running]:
k8s.io/kubernetes/vendor/k8s.io/apiserver/pkg/httplog.(*respLogger).recordStatus(0xc420dc0700, 0x1f8)
	/go/src/k8s.io/kubernetes/_output/dockerized/go/src/k8s.io/kubernetes/vendor/k8s.io/apiserver/pkg/httplog/log.go:219 +0xbb
k8s.io/kubernetes/vendor/k8s.io/apiserver/pkg/httplog.(*respLogger).WriteHeader(0xc420dc0700, 0x1f8)
	/go/src/k8s.io/kubernetes/_output/dockerized/go/src/k8s.io/kubernetes/vendor/k8s.io/apiserver/pkg/httplog/log.go:198 +0x35
k8s.io/kubernetes/vendor/k8s.io/apiserver/pkg/metrics.(*responseWriterDelegator).WriteHeader(0xc420ece420, 0x1f8)
	/go/src/k8s.io/kubernetes/_output/dockerized/go/src/k8s.io/kubernetes/vendor/k8s.io/apiserver/pkg/metrics/metrics.go:117 +0x45
k8s.io/kubernetes/pkg/genericapiserver/api/handlers/responsewriters.WriteObjectNegotiated(0x5ec3400, 0xc420efd440, 0x0, 0x0, 0x39e44c8, 0x2, 0x5ebc440, 0xc421dff358, 0xc421c5e1e0, 0x1f8, ...)
	/go/src/k8s.io/kubernetes/_output/dockerized/go/src/k8s.io/kubernetes/pkg/genericapiserver/api/handlers/responsewriters/writers.go:89 +0x162
k8s.io/kubernetes/pkg/genericapiserver/api/handlers/responsewriters.ErrorNegotiated(0x5e8f040, 0xc42099d400, 0x5ec3400, 0xc420efd440, 0x0, 0x0, 0x39e44c8, 0x2, 0x5ebc440, 0xc421dff358, ...)
	/go/src/k8s.io/kubernetes/_output/dockerized/go/src/k8s.io/kubernetes/pkg/genericapiserver/api/handlers/responsewriters/writers.go:106 +0x103
k8s.io/kubernetes/pkg/genericapiserver/api/handlers.(*RequestScope).err(0xc4201476c0, 0x5e8f040, 0xc42099d400, 0x5ebc440, 0xc421dff358, 0xc421c5e1e0)
	/go/src/k8s.io/kubernetes/_output/dockerized/go/src/k8s.io/kubernetes/pkg/genericapiserver/api/handlers/rest.go:93 +0xd7
k8s.io/kubernetes/pkg/genericapiserver/api/handlers.PatchResource.func1(0xc420d87da0, 0xc421bb6060)
	/go/src/k8s.io/kubernetes/_output/dockerized/go/src/k8s.io/kubernetes/pkg/genericapiserver/api/handlers/rest.go:521 +0xaf3
k8s.io/kubernetes/vendor/k8s.io/apiserver/pkg/metrics.InstrumentRouteFunc.func1(0xc420d87da0, 0xc421bb6060)
	/go/src/k8s.io/kubernetes/_output/dockerized/go/src/k8s.io/kubernetes/vendor/k8s.io/apiserver/pkg/metrics/metrics.go:101 +0x1f2
k8s.io/kubernetes/vendor/github.com/emicklei/go-restful.(*Container).dispatch(0xc4207cf8c0, 0x5ebc400, 0xc420dc0700, 0xc421c5e1e0)
	/go/src/k8s.io/kubernetes/_output/dockerized/go/src/k8s.io/kubernetes/vendor/github.com/emicklei/go-restful/container.go:272 +0xba0
k8s.io/kubernetes/vendor/github.com/emicklei/go-restful.(*Container).(k8s.io/kubernetes/vendor/github.com/emicklei/go-restful.dispatch)-fm(0x5ebc400, 0xc420dc0700, 0xc421c5e1e0)
	/go/src/k8s.io/kubernetes/_output/dockerized/go/src/k8s.io/kubernetes/vendor/github.com/emicklei/go-restful/container.go:120 +0x48
net/http.HandlerFunc.ServeHTTP(0xc4212347c0, 0x5ebc400, 0xc420dc0700, 0xc421c5e1e0)
	/usr/local/go/src/net/http/server.go:1726 +0x44
net/http.(*ServeMux).ServeHTTP(0xc420d54ab0, 0x5ebc400, 0xc420dc0700, 0xc421c5e1e0)
	/usr/local/go/src/net/http/server.go:2022 +0x7f
k8s.io/kubernetes/pkg/genericapiserver/filters.WithPanicRecovery.func1(0x5ebc400, 0xc420dc0700, 0xc421c5e1e0)
	/go/src/k8s.io/kubernetes/_output/dockerized/go/src/k8s.io/kubernetes/pkg/genericapiserver/filters/panics.go:74 +0x24a
net/http.HandlerFunc.ServeHTTP(0xc420d55a40, 0x7f9fda73fb90, 0xc421dff348, 0xc421c5e1e0)
	/usr/local/go/src/net/http/server.go:1726 +0x44
k8s.io/kubernetes/pkg/genericapiserver/filters.(*timeoutHandler).ServeHTTP.func1(0xc420f26940, 0x5ec47c0, 0xc421dff348, 0xc421c5e1e0, 0xc421ebdf20)
	/go/src/k8s.io/kubernetes/_output/dockerized/go/src/k8s.io/kubernetes/pkg/genericapiserver/filters/timeout.go:89 +0x8d
created by k8s.io/kubernetes/pkg/genericapiserver/filters.(*timeoutHandler).ServeHTTP
	/go/src/k8s.io/kubernetes/_output/dockerized/go/src/k8s.io/kubernetes/pkg/genericapiserver/filters/timeout.go:91 +0x1db

I have tried the following steps to deploy the kubernetes cluster on master builds.

Deploy kubernetes cluster using kube-anywhere on v1.5.1 kubernetes with vsphere cloud provider configured.
I see all the services are up and running perfectly fine.
Replace the gcr.io/google-containers/hyperkube-amd64:v1.5.1 image with my custom hyperkube image built using kubernetes master code base.
Update the manifests files in /etc/kubernetes/manifests to use the new hyperkube image based on master build.
Also update the kubelet.service to use the new hyperkube image based on master build.
Restart all the services.
After this, I see the apiserver container is started but goes to an unhealthy state (fails to start succesfully).

The following command fails as API server fails to start successfully.
-curl http://localhost:8080/api/v1/nodes
-curl http://localhost:8080/api/v1/namespaces/kube-system/pods/
I even tried removing the cloud provider configuration from all manifests files and kubelet service. Now, it is running with the kubernetes core only without any cloud provider configured.  I see the same errors again.
So, I feel this basically has to do something with the kubernetes core which fails to start the api server and is independent of the cloud provider.
@mikedanese : Can you please take a look at this.
P.S: kube-anywhere works perfectly fine on v1.5.1 and v1.5.2 (which was released 8 days ago).
@kerneltime

@mikedanese : Can you provide your input on this.?

@abrarshivani Can you update this with the CLI fixes that are needed?

PR https://github.com/kubernetes/kubernetes-anywhere/pull/326 fixes this.

authors: BaluDontu abrarshivani kerneltime

repo: kubernetes/kubernetes-anywhere


text:
Unable to create ingress deny policy from kubectl.

This is a...

[ ] Feature Request
[x] Bug Report

Problem:
Unable to create ingress deny policy from kubectl.
Proposed Solution:
Page to Update:
http://kubernetes.io/...

1.5.3

We have two namepaces  one is for MZ pods and onther is  for DMZ pods , I want to enable ingress deny policy in MZ from DMZ pods . All pods within same namespce will able to communicate with each other but DMZ should not allowed to communicate with MZ (except which are allowed).

@pradeeppandeyy this issue tracker is for documentation problems. If you're seeking help, please ask your question on StackOverflow, Slack or mailing list all of which are listed at the bottom of kubernetes.io page.

Closing.

authors: ahmetb jaredbhatti pradeeppandeyy


text:
Issue with k8s.io/docs/setup/

This is a...

[ ] Feature Request
[ ] Bug Report

Problem:
Proposed Solution:
Page to Update:
http://kubernetes.io/...

@zhanwei0 it looks like you tried to open an issue, but there's no content. Can this be closed, or is there an issue we should be aware of?


text:
Revert "ClusterLoader - Copying tests to head/ and legacy/"

Reverts kubernetes/perf-tests#450
I actually think this was a bad decision. https://github.com/kubernetes/perf-tests/issues/413#issuecomment-481654172 contains all the context.

/lgtm

authors: krzysied wojtek-t

repo: kubernetes/perf-tests


text:
Issue with k8s.io/docs/tutorials/stateless-application/expose-external-ip-address/

not getting the external ip

This is a...

[ ] Feature Request
[x ] Bug Report

Problem:
waited a few minutes, still not getting the external ip address
Proposed Solution:
Page to Update:
https://kubernetes.io/...

1.13 cluster with 3 nodes

Hi,
which cloud provider are you using?

Use a cloud provider like Google Kubernetes Engine or Amazon Web Services to create a Kubernetes cluster. This tutorial creates an external load balancer, which requires a cloud provider.

authors: menzellu sluetze

repo: kubernetes/website


text:
Search this site should be above the section

The page on the screenshot is https://kubernetes.io/docs/home/
This site is kubernetes.io.
This form searches within documentation, not this site:

Hi @532910
That search form searches the whole site. Can you give an example of how the search appears limited?
/triage needs-information

Yep, it's my fault. But I was confused by oder: Search this site should go before Documentation section.

If you can make a mockup or sketch of how you think the page should look instead, I think that'll really make it clear what you're not happy about with the existing page. Would you have time to do that?
(even a pencil sketch is fine!)

is any update there?

/remove-triage needs-information
/priority awaiting-more-evidence

@532910 thanks for the update. Can you briefly outline why you'd like this improvement made?

Can you briefly outline why you'd like this improvement made?

As it's a search through the documentation and not the entire site.

The hamburger button right to the search field shows full site menu. They are both in the same line, but have different places in the hierarchy. The hamburger button is the root, search field belongs to Documentation section.

The search field is a part of Documentation. So it must be under Documentation title, not vice versa.

Clear?

Here's what I think could work:

keep the search field where it is (it's part of Docsy)
add another search field in the top nav, that's shown even when Docsy's built-in search input is shown
add some code to sync things so that typing into either field changes the query in both

That feels like it'd achieve roughly what @532910 is asking for, without needing lots of deviation from upstream Docsy.

So what is the problem to hide Docsy's search field afterwards?

So what is the problem to hide Docsy's search field afterwards?

I guess we could hide Docsy's search field. What does that add, though? Also, does it break any viewing experience (eg mobile)?

Two search field are confusing and eat up space that is expensive on mobile.

/remove-lifecycle rotten


text:
ja: Make docs/concepts/cluster-administration/_index.md follow v1.19 of the original text

This is a Feature Request

What would you like to be added
Update docs/concepts/cluster-administration/_index.md to follow v1.19 of the original (English) text.
Why is this needed
content/ja/docs/concepts/cluster-administration/_index.md is outdated.
Comments
/language ja
/good-first-issue
File to update
https://github.com/kubernetes/website/tree/dev-1.19-ja.1/content/ja/docs/concepts/cluster-administration/_index.md
Original
https://github.com/kubernetes/website/tree/release-1.19/content/en/docs/concepts/cluster-administration/_index.md
diff between translated and v1.19
https://gist.github.com/6893f053d1e22259b0e959e0dee5107c
Note
Currently, we use dev-1.19-ja.1 branch. Please open a PR targeting the branch.
ref
https://kubernetes.io/ja/docs/contribute/localization/
If you have a question, feel free to ask us at slack.k8s.io #kubernetes-docs-ja channel.

/triage accepted

/assign

/close


text:
[hi] Localize content/en/docs/reference/scheduling/config.md to Hindi

This is a Feature Request
What would you like to be added

We need to localize content/en/docs/reference/scheduling/config.md to Hindi (content/hi/docs/reference/scheduling/config.md)

Why is this needed
This page has not translated in hindi yet
Comments
/language hi
/good-first-issue
/assign

/remove-good-first-issue

Hi @bishal7679 can I work on this issues

Hi @bishal7679 can I work on this issue

/triage accepted

/remove-lifecycle stale


text:
[ko] Translate the glossary term 'Dockershim, Helm Chart, HostAliases ... etc' into Korean

This is a Feature Request
What would you like to be added
Translate docs/reference/glossary/ {{ some_file }} into Korean
◾ Page: https://kubernetes.io/ko/docs/reference/glossary/?all=true

[x] Dockershim
◾ File: https://github.com/kubernetes/website/blob/dev-1.24-ko.2/content/en/docs/reference/glossary/dockershim.md
[x] Helm Chart
◾ File: https://github.com/kubernetes/website/blob/dev-1.24-ko.2/content/en/docs/reference/glossary/helm-chart.md
[x] HostAliases
◾ File: https://github.com/kubernetes/website/blob/dev-1.24-ko.2/content/en/docs/reference/glossary/host-aliases.md
[x] Kubeadm
◾ File: https://github.com/kubernetes/website/blob/dev-1.24-ko.2/content/en/docs/reference/glossary/kubeadm.md

Why is this needed
Not translated yet
Comments
/language ko
/assign

/triage accepted

Resolved by

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

/close

authors: Seo-yul jihoon-seo seokho-son