text:
Make the async APIs completely parallel

This removes the point of coordination introduced in
a9c2f5b9893bd52e01c1d7bc5636f8bd2e77a2e0 when making the APIs
thread-safe, by changing the updates to the result array from sync to
async.

Thanks @krisk! Mind publishing a new version?

repo: krisk/fuse-swift

license: mit


text:
Why return function ref ?

Now, we need to start altering our "then" methods so that they return promises for the return value of their given callback. The "ref" case is simple. We'll coerce the return value of the callback to a promise and return that immediately.
var ref = function (value) {
    if (value && typeof value.then === "function")
        return value;
    return {
        then: function (callback) {
            return ref(callback(value));
        }
    };
};

I try only to use "return callback(value)", It doesn't seem to be a problem，Can you provide an example （" return callback(value) ")?
Thanks.

Could you elaborate? It's not clear to me what you are trying to achieve and how Q is involved in it

Could you elaborate? It's not clear to me what you are trying to achieve and how Q is involved in it

design/README.md
That's one of the things I'm confused about with this document (design/README.md).

If you don't call ref on the callback value, the callback might not return a promise and then you wouldn't be able to call p.then(...).then(...)

If you don't call ref on the callback value, the callback might not return a promise and then you wouldn't be able to call p.then(...).then(...)

I try only to use "return callback(value)". it would be able to call p.then(...).then(...)
https://jsbin.com/qapiqexoza/edit?html,js,console,output
Can you provide an example where it doesn't work？

p.then(() => 1) would return 1, would it not?
Of course, there is a school of thought that promises should be strict monads, in which case, the author of the callback would be obliged to wrap/lift the return value in order to satisfy the type of then (which would decompose into map and flatMap).
So p.then(() => ref(1)) would return a promise.

p.then(() => 1) would return 1, would it not?
Of course, there is a school of thought that promises should be strict monads, in which case, the author of the callback would be obliged to wrap/lift the return value in order to satisfy the type of then (which would decompose into map and flatMap).
So p.then(() => ref(1)) would return a promise.

promise: {
            then: function (_callback) {
                let result = defer();
                let callback = function (value) {
                    result.resolve(_callback(value));
                };
                if (pending) {
                    pending.push(callback);
                } else {
                    value.then(callback);
                }
                return result.promise;
            }
        }

So p.then(() => 1) would return a promise.
There is an example in https://jsbin.com/cozuluxido/3/edit?html,js,console,output

source: gharchive/issue

authors: indown kriskowal wmertens

repo: kriskowal/q

license_type: permissive

license_source: bigquery


text:
[feature request] browser addon

In a perfect world, I'd be able to turn this on for a page, or even attach it to a component via the react dev tools.
Being able to "hook into" using Geiger without changing my package dependencies would be nice.
How much work are we talking? Does anyone already know any blockers?

Heh, that would be cool but it certainly doesn't sound like a trivial task to me...

Yeah, the easiest way to do this is probably to get really popular and then have the react devtools team interested in building the functionality in directly. "Not planned" would be totally understandable here, especially since this package installs smaller than several single files I have in my repo.

Still, thanks for the idea!

authors: david-morris kristiandupont

repo: kristiandupont/react-geiger

license: MIT

license_source: github-api


text:
[BUG] - Compilation Issue

Description
When trying to build the humble branch of the kuka_drivers, the packages kuka_iiqka_eac_driver and kuka_external_control_sdk_examples fail to build and complain about mismatching function arguments from the SDK.
KUKA robot OS
iiQKA
KUKA robot OS version
KUKA Linux OS 2.0.14
KUKA external interface version
ExternalControl.API 1.0.3
Affected robot model(s)
iisy R1300
Version or commit hash of the driver
humble
Setup
Bug during compilation

Reproduction steps
colcon build --packages-select kuka_iiqka_eac_driver

Logs
Starting >>> kuka_iiqka_eac_driver
--- stderr: kuka_iiqka_eac_driver
/home/ekampourakis/kuka_ws/src/kuka_drivers/kuka_iiqka_eac_driver/src/hardware_interface.cpp: In member function ‘virtual hardware_interface::return_type kuka_eac::KukaEACHardwareInterface::read(const rclcpp::Time&, const rclcpp::Duration&)’:
/home/ekampourakis/kuka_ws/src/kuka_drivers/kuka_iiqka_eac_driver/src/hardware_interface.cpp:240:42: error: request for member ‘begin’ in ‘(& req_message)->kuka::external::control::BaseMotionState::GetMeasuredPositions()’, which is of pointer type ‘const std::vector<double>*’ (maybe you meant to use ‘->’ ?)
  240 |       req_message.GetMeasuredPositions().begin(), req_message.GetMeasuredPositions().end(),
      |                                          ^~~~~
/home/ekampourakis/kuka_ws/src/kuka_drivers/kuka_iiqka_eac_driver/src/hardware_interface.cpp:240:86: error: request for member ‘end’ in ‘(& req_message)->kuka::external::control::BaseMotionState::GetMeasuredPositions()’, which is of pointer type ‘const std::vector<double>*’ (maybe you meant to use ‘->’ ?)
  240 |       req_message.GetMeasuredPositions().begin(), req_message.GetMeasuredPositions().end(),
      |                                                                                ^~~
/home/ekampourakis/kuka_ws/src/kuka_drivers/kuka_iiqka_eac_driver/src/hardware_interface.cpp:243:40: error: request for member ‘begin’ in ‘(& req_message)->kuka::external::control::BaseMotionState::GetMeasuredTorques()’, which is of pointer type ‘const std::vector<double>*’ (maybe you meant to use ‘->’ ?)
  243 |       req_message.GetMeasuredTorques().begin(), req_message.GetMeasuredTorques().end(),
      |                                        ^~~~~
/home/ekampourakis/kuka_ws/src/kuka_drivers/kuka_iiqka_eac_driver/src/hardware_interface.cpp:243:82: error: request for member ‘end’ in ‘(& req_message)->kuka::external::control::BaseMotionState::GetMeasuredTorques()’, which is of pointer type ‘const std::vector<double>*’ (maybe you meant to use ‘->’ ?)
  243 |       req_message.GetMeasuredTorques().begin(), req_message.GetMeasuredTorques().end(),
      |                                                                                ^~~
/home/ekampourakis/kuka_ws/src/kuka_drivers/kuka_iiqka_eac_driver/src/hardware_interface.cpp: In member function ‘virtual hardware_interface::return_type kuka_eac::KukaEACHardwareInterface::write(const rclcpp::Time&, const rclcpp::Duration&)’:
/home/ekampourakis/kuka_ws/src/kuka_drivers/kuka_iiqka_eac_driver/src/hardware_interface.cpp:269:56: error: no matching function for call to ‘kuka::external::control::BaseControlSignal::AddJointPositionValues(std::vector<double>::iterator, std::vector<double>::iterator)’
  269 |   robot_ptr_->GetControlSignal().AddJointPositionValues(
      |   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^
  270 |     hw_position_commands_.begin(), hw_position_commands_.end());
      |     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from /home/ekampourakis/.local/include/kuka/external-control-sdk/common/irobot.h:23,
                 from /home/ekampourakis/.local/include/kuka/external-control-sdk/iiqka/sdk.h:18,
                 from /home/ekampourakis/kuka_ws/src/kuka_drivers/kuka_iiqka_eac_driver/include/kuka_iiqka_eac_driver/event_observer.hpp:21,
                 from /home/ekampourakis/kuka_ws/src/kuka_drivers/kuka_iiqka_eac_driver/src/hardware_interface.cpp:25:
/home/ekampourakis/.local/include/kuka/external-control-sdk/common/message_builder.h:58:8: note: candidate: ‘void kuka::external::control::BaseControlSignal::AddJointPositionValues(std::vector<double>&)’
   58 |   void AddJointPositionValues(std::vector<double>& joint_position_values) {
      |        ^~~~~~~~~~~~~~~~~~~~~~
/home/ekampourakis/.local/include/kuka/external-control-sdk/common/message_builder.h:58:8: note:   candidate expects 1 argument, 2 provided
/home/ekampourakis/kuka_ws/src/kuka_drivers/kuka_iiqka_eac_driver/src/hardware_interface.cpp:271:49: error: no matching function for call to ‘kuka::external::control::BaseControlSignal::AddTorqueValues(std::vector<double>::iterator, std::vector<double>::iterator)’
  271 |   robot_ptr_->GetControlSignal().AddTorqueValues(
      |   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^
  272 |     hw_torque_commands_.begin(), hw_torque_commands_.end());
      |     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from /home/ekampourakis/.local/include/kuka/external-control-sdk/common/irobot.h:23,
                 from /home/ekampourakis/.local/include/kuka/external-control-sdk/iiqka/sdk.h:18,
                 from /home/ekampourakis/kuka_ws/src/kuka_drivers/kuka_iiqka_eac_driver/include/kuka_iiqka_eac_driver/event_observer.hpp:21,
                 from /home/ekampourakis/kuka_ws/src/kuka_drivers/kuka_iiqka_eac_driver/src/hardware_interface.cpp:25:
/home/ekampourakis/.local/include/kuka/external-control-sdk/common/message_builder.h:67:8: note: candidate: ‘void kuka::external::control::BaseControlSignal::AddTorqueValues(std::vector<double>&)’
   67 |   void AddTorqueValues(std::vector<double>& joint_torque_values) {
      |        ^~~~~~~~~~~~~~~
/home/ekampourakis/.local/include/kuka/external-control-sdk/common/message_builder.h:67:8: note:   candidate expects 1 argument, 2 provided
/home/ekampourakis/kuka_ws/src/kuka_drivers/kuka_iiqka_eac_driver/src/hardware_interface.cpp:273:62: error: no matching function for call to ‘kuka::external::control::BaseControlSignal::AddStiffnessAndDampingValues(std::vector<double>::iterator, std::vector<double>::iterator, std::vector<double>::iterator, std::vector<double>::iterator)’
  273 |   robot_ptr_->GetControlSignal().AddStiffnessAndDampingValues(
      |   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^
  274 |     hw_stiffness_commands_.begin(), hw_stiffness_commands_.end(), hw_damping_commands_.begin(),
      |     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  275 |     hw_damping_commands_.end());
      |     ~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from /home/ekampourakis/.local/include/kuka/external-control-sdk/common/irobot.h:23,
                 from /home/ekampourakis/.local/include/kuka/external-control-sdk/iiqka/sdk.h:18,
                 from /home/ekampourakis/kuka_ws/src/kuka_drivers/kuka_iiqka_eac_driver/include/kuka_iiqka_eac_driver/event_observer.hpp:21,
                 from /home/ekampourakis/kuka_ws/src/kuka_drivers/kuka_iiqka_eac_driver/src/hardware_interface.cpp:25:
/home/ekampourakis/.local/include/kuka/external-control-sdk/common/message_builder.h:85:8: note: candidate: ‘void kuka::external::control::BaseControlSignal::AddStiffnessAndDampingValues(std::vector<double>&, std::vector<double>&)’
   85 |   void AddStiffnessAndDampingValues(std::vector<double>& stiffness_values,
      |        ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/ekampourakis/.local/include/kuka/external-control-sdk/common/message_builder.h:85:8: note:   candidate expects 2 arguments, 4 provided
gmake[2]: *** [CMakeFiles/kuka_iiqka_eac_driver.dir/build.make:76: CMakeFiles/kuka_iiqka_eac_driver.dir/src/hardware_interface.cpp.o] Error 1
gmake[1]: *** [CMakeFiles/Makefile2:139: CMakeFiles/kuka_iiqka_eac_driver.dir/all] Error 2
gmake: *** [Makefile:146: all] Error 2
---
Failed   <<< kuka_iiqka_eac_driver [2.05s, exited with code 2]

Summary: 0 packages finished [2.23s]
  1 package failed: kuka_iiqka_eac_driver
  1 package had stderr output: kuka_iiqka_eac_driver

Hi, please update your external-control-sdk repo, as that seems to be outdated.
On master, the GetMeasuredPositions function is not a pointer, this is what causes your issue

Thanks for the prompt reply, switching to the master branch fixed the compilation issue with the driver but the SDK examples continue to fail.
Consider updating the installation instructions to point to the proper branch.
I am closing this issue.
Thanks again

authors: Svastits ekampourakis


text:
Added password utility

This utility ensures the creation of well-encrypted password hashes,
salts, and encrypted passwords.

Coverage remained the same at 100.0% when pulling c7f88778d9887c276dc54c76c49d7675af8d5fc5 on feature/password_util into 108275f3994edd6cbc35e4cdafce32046c097cc6 on develop.

source: gharchive/pull-request

authors: coveralls krotscheck


text:
Watch for the service account token to be ready

Instead of using a sleep use an actual watcher to ensure that the token
is ready before proceeding.
Closes #403
Signed-off-by: Nitish Malhotra nitish.malhotra@gmail.com

Hi @nitishm. Sorry for the late response.
Generally speaking we ask for unit tests to accompany any changes. That way we can ensure future changes won't introduce a code regression, and we have some context around why certain changes were made in the past. Would you mind writing some tests? Thanks!

Looking at this closer... It might be too difficult to implement tests for the tests. I think we can make an exception here.

authors: bacongobbler nitishm

repo: krustlet/krustlet


text:
System.DateTime filtering issue

This is a long-standing known issue.
System.DateTime.ToString and string System.DateTime in F# produce different results.
This causes problems, for example, when filtering with Get-ChildItem's LastWriteTime and similar.
Example of differences.
> System.DateTime.Now.ToString();;
val it: string = "2024-02-12 17:15:15"

> string System.DateTime.Now;;
val it: string = "02/12/2024 17:15:22"

The difference arises because the ToString method in .NET uses the current culture setting.
My setting is following.
> [System.Threading.Thread]::CurrentThread.CurrentCulture.DateTimeFormat.ShortDatePattern
yyyy-MM-dd

> [System.Globalization.CultureInfo]::GetCultureInfo('en-US').DateTimeFormat.ShortDatePattern
M/d/yyyy

repo: krymtkts/pocof


text:
Add support to return the version of stable Chrome

Thanks for the useful module.
I found that this issue will return the Canary version of Chrome if I installed both the stable version and the Canary version. Because the chrome finder defined the priority of the installation and the Canary version has a high priority.
https://github.com/GoogleChrome/chrome-launcher/blob/b8c89f84a39c2f4ed4dd547be5dce2d83da54424/src/chrome-finder.ts#L21
So, I add an option { stable: true } to return the stable version.
I also removed the chrome-remote-interface module, the version can be got without launch the Chrome in the background. It should be much faster now.

Hi @ksathyanm, do you have any plan to merge this?
would you prefer to take any other approach?
should we solve the conflict to unblock this?

authors: dpordomingo yuezk

repo: ksathyanm/find-chrome-version


text:
Adding multi-arch support for linux-ppc64le for qpext

What this PR does / why we need it:

Updating the dockerfile of qpext to be platform independent (dropping goos and goarch, go is smart enough  to understand current platform)
adding support for linux-ppc64le  in github action to release multi-arch docker images

Which issue(s) this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close the issue(s) when PR gets merged):
Fixes #
Type of changes
Please delete options that are not relevant.

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

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

[ ] Test A

[ ] Test B

Logs

Special notes for your reviewer:

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

Checklist:

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

Release note:

/lgtm
/approve

authors: adilhusain-s yuzisun

repo: kserve/kserve


text:
Change certificate to ca_bundle in json style of s3 storageSecret

What this PR does / why we need it:
Which issue(s) this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close the issue(s) when PR gets merged):
Fixes #https://github.com/kserve/kserve/issues/3462
Type of changes
Please delete options that are not relevant.

[ ] Bug fix (non-breaking change which fixes an issue)
[x] 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:
The certifcate in kserve was useless until this PR(https://github.com/kserve/kserve/pull/3250) merged. Even after the merge, certificate can not be used solely so changing the field does not impact anything.

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:

/approve

authors: Jooho yuzisun


text:
Fix up for merging objects

Process was using wrong modified document
Added support for using open api schema
Merger now can retrieve original object

note I'm not 100% sure how to test this, so I did a bunch of manual testing and it didn't seem to break anything.
Signed-off-by: bryanl bryanliles@gmail.com

Pull Request Test Coverage Report for Build 1179

17 of 45 (37.78%)  changed or added relevant lines in 2 files are covered.
3 unchanged lines in 1 file lost coverage.
Overall coverage decreased (-0.08%) to 71.283%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

pkg/cluster/merger.go
11
20
55.0%

pkg/cluster/tagger.go
6
25
24.0%

Files with Coverage Reduction
New Missed Lines
%

pkg/cluster/merger.go
3
46.47%

Totals

Change from base Build 1178:
-0.08%

Covered Lines:
11843

Relevant Lines:
16614

💛  - Coveralls

authors: bryanl coveralls

repo: ksonnet/ksonnet


text:
Command to generate synthesis from Tacotron-2 MELS ?

Hi
I am unable to figure out how to generate a synthesis with these parameters using the MELS spectrogram generated by Tacotron-2
parser.add_argument('--data_path', type=str, default='./DATASETS/ljspeech/', help='Dataset Path')
parser.add_argument('--sample_path', type=str, default='./samples', help='Sample Path')
parser.add_argument('--model_name', type=str, default='flowavenet', help='Model Name')
parser.add_argument('--num_samples', type=int, default=10, help='# of audio samples')
parser.add_argument('--load_step', type=int, default=0, help='Load Step')
parser.add_argument('--temp', type=float, default=0.8, help='Temperature')
parser.add_argument('--load', '-l', type=str, default='./params', help='Checkpoint path to resume / test.')
parser.add_argument('--n_layer', type=int, default=2, help='Number of layers')
parser.add_argument('--n_flow', type=int, default=6, help='Number of layers')
parser.add_argument('--n_block', type=int, default=8, help='Number of layers')
parser.add_argument('--cin_channels', type=int, default=80, help='Cin Channels')
parser.add_argument('--block_per_split', type=int, default=4, help='Block per split')
parser.add_argument('--num_workers', type=int, default=0, help='Number of workers')
parser.add_argument('--log', type=str, default='./log', help='Log folder.')
Where is the parameter for the MELS?
Does anyone have an example commandline?
Many Thanks
Joshua

You can see from the preprocessing.py that this repo uses a normalized version of the mel-spec on a decibel-scale (similar to r9y9's wavenet_vocoder repo). The preprocessing pipeline in this repo is mostly hard-wired.
NVIDIA's Tacotron 2 implementation uses a log-scale version of the mel-spec so it is not directly applicable unless you re-normalize them. You would need to train the model using the log-scale mel-spec to ensure the compatibility between them.


text:
Upgrade golangci lint version

This pull request upgrades the golangci lint version.

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

Project coverage is 88.98%. Comparing base (b0c4460) to head (2a0d06d).
Report is 21 commits behind head on main.

Additional details and impacted files
@@            Coverage Diff             @@
##             main      #16      +/-   ##
==========================================
- Coverage   90.85%   88.98%   -1.88%
==========================================
  Files           3        3
  Lines         350      363      +13
==========================================
+ Hits          318      323       +5
- Misses         24       30       +6
- Partials        8       10       +2

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

authors: codecov-commenter ksysoev

repo: ksysoev/deriv-api


text:
🛑 MatterMost is down

In c0745e2, MatterMost (http://chat.chelsea.kt.co.kr/login) was down:

HTTP code: 0
Response time: 0 ms

Resolved: MatterMost is back up in 4913576.

repo: kt-chelsea/status


text:
CMake Error: install TARGETS given target "uvc_static" which does not exist

-- The C compiler identification is GNU 6.3.0
-- The CXX compiler identification is GNU 6.3.0
-- Check for working C compiler: /usr/bin/x86_64-pc-linux-gnu-gcc
-- Check for working C compiler: /usr/bin/x86_64-pc-linux-gnu-gcc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /usr/bin/x86_64-pc-linux-gnu-g++
-- Check for working CXX compiler: /usr/bin/x86_64-pc-linux-gnu-g++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Found PkgConfig: x86_64-pc-linux-gnu-pkg-config (found version "0.29.2")
-- Checking for module 'libusb-1.0'
--   Found libusb-1.0, version 1.0.21
-- Checking for module 'libjpeg'
--   Found libjpeg, version 1.5.2
-- Building libuvc with JPEG support.
CMake Error at CMakeLists.txt:95 (install):
  install TARGETS given target "uvc_static" which does not exist in this
  directory.

-- <<< Gentoo configuration >>>
Build type      Gentoo
Install path    /usr
Compiler flags:
C               -march=core-avx2 -O2 -pipe
C++             -march=core-avx2 -O2 -pipe
Linker flags:
Executable      -Wl,-O1 -Wl,--as-needed
Module          -Wl,-O1 -Wl,--as-needed
Shared          -Wl,-O1 -Wl,--as-needed

-- Configuring incomplete, errors occurred!

Could you please try again with the changes I just pushed? Shared-only and static-only builds were broken.

It seems everything ok. Thanks.

authors: ktossell reagentoo

repo: ktossell/libuvc


text:
Support having multiple swagger docs

What is the problem this feature would solve?
It seems like kubb currently only supports one input (oai) file. It would be great if it supported multiple different oai docs at once.
External documents/projects?
No response
What is the feature you are proposing to solve the problem?
No response
What alternatives have you considered?
No response

For this you can use multiple configs as an array, see https://kubb.dev/guide/configure#multiple-plugins

Thanks @stijnvanhulle :)

repo: kubb-labs/kubb


text:
[BUG] Deletion of Role/Rolebinding through kube-burner causes fatal error

Bug Description
Deletion of created Role/RoleBinding through a kube-burner job causes fatal error
Output of kube-burner version
Version: 1.10.4
Git Commit: 2b0a32be8f0b3a3df2328e4aecc9da06da742666
Build Date: 2024-07-12T19:25:04Z
Go Version: go1.21.12
OS/Arch: linux amd64
Describe the bug
Deleting Role/Rolebindings using kube-burner causes a fatal exit with the following error message
time="2024-07-23 09:33:19" level=info msg="🔥 Starting kube-burner (1.2.9@4a36d42712bd22e9308035149a3de93b33896f54) with UUID a5311366-1b07-4052-a942-a59dc20ca6ad" file="job.go:99"
time="2024-07-23 09:33:19" level=fatal msg="no matches for kind \"RoleBinding\" in group \"\"" file="delete.go:44"

To Reproduce
Steps to reproduce the behavior:

Create a Kube-burner custom workload that uses Role/Rolebindings, such as the kubectlapp workload in the templates available here
Attempt to delete the created role/rolebindings using kube-burner using a delete job such as

---
jobs:
  - name: remove-roles
    qps: 2
    burst: 2
    jobType: delete
    waitForDeletion: true
    objects:
      - kind: RoleBinding
        labelSelector: {kube-burner-job: du-workload}
      - kind: Role
        labelSelector: {kube-burner-job: du-workload}

Expected behavior
Safe deletion of role/rolebinding objects created with a kube-burner job using a template.
Only way currently to do this is to select and delete each one tediously, such as,
[kni@registry du-intensive]$ oc delete -n workload rolebinding pod-reader-binding-1
rolebinding.rbac.authorization.k8s.io "pod-reader-binding-1" deleted
[kni@registry du-intensive]$ oc delete -n workload rolebinding pod-reader-binding-2
rolebinding.rbac.authorization.k8s.io "pod-reader-binding-2" deleted

Screenshots or output
If applicable, add screenshots or kube-burner output to help explain your problem.

Hey @abraham2512 , as per the output suggests, kube-burner wasn't able to find the specified resources (Rolebinding and Role), that's expected and is because you need to configure apiVersion .
Which is the following for both resources:
apiVersion: rbac.authorization.k8s.io/v1

More info at docs https://kube-burner.github.io/kube-burner/latest/reference/configuration/#delete
Please, let me know if that solved your issue.

Hi @rsevilla87, thank you! Specifying the correct apiVersion deleted the roles/rolebindings.

repo: kube-burner/kube-burner


text:
[Bug]: docker.io/hetznercloud/cluster-autoscaler will be removed

Description
I recently got an email from Hetzner explaining the following:
Dear ___

Based on our API monitoring, you are using Kubernetes cluster-autoscaler in your Hetzner Cloud projects. The Hetzner provider in current versions of cluster-autoscaler has a bug and relies on the CX11 server type, which we scheduled for removal from our ordering options on 6 September 2024. To prevent any disruptions for you, we kept the CX11 server type available for your account.

The Kubernetes community has now released new versions of cluster-autoscaler that fix this bug. Please upgrade to the these versions before 4 November 2024.

The following versions include the patches:

    ≥ 1.28.7
    ≥ 1.29.5
    ≥ 1.30.2
    ≥ 1.31.1

We will remove your access to the CX11 server type after 4 November 2024. If you are still using unpatched versions of cluster-autoscaler, they will stop working.

If you were using the alternative container images we provided ([docker.io/hetznercloud/cluster-autoscaler](http://docker.io/hetznercloud/cluster-autoscaler)), please switch back to the images built by the Kubernetes community ([registry.k8s.io/autoscaling/cluster-autoscaler](http://registry.k8s.io/autoscaling/cluster-autoscaler)). We will remove the alternative container images on 19 November 2024.

You can find more information at the following links:

    https://docs.hetzner.cloud/changelog#2024-08-30-bug-cx11-removal-will-break-certain-versions-of-cluster-autoscaler
    https://github.com/kubernetes/autoscaler/issues/7210
    https://docs.hetzner.cloud/changelog#2024-06-06-old-server-types-with-shared-intel-vcpus-are-deprecated

We will be happy to help you with any questions. Please write us a support request by logging onto your account: https://console.hetzner.cloud/support

Thank you for your understanding.

Kind regards

Hetzner Online

This explains that  docker.io/hetznercloud/cluster-autoscaler will be removed on 19 November 2024. Meaning, [the default cluster_autoscaler_image variable](  default     = "docker.io/hetznercloud/cluster-autoscaler") will break.
Kube.tf file
n/a

Screenshots
No response
Platform
n/a

Opened PR #1506 that should fix this.

Existing auto scaling clusters are now failing since November 4 due to this because information related to CX11 can no longer be retrieved.

authors: BrammyS lpellegr


text:
upstream reports expiration field docs

Lindsey had written docs for downstream so just adding them verbatim to repo.

/lgtm

/retest

/lgtm

/lgtm
/approve

/retest

/override ci/prow/metering-e2e-aws

/override ci/prow/metering-upgrade-aws

repo: kube-reporting/metering-operator


text:
Contributing.md and DCO

Based on simpler requirements and discussion after https://github.com/kube-rs/kube-rs/issues/585#issuecomment-892070891

Ok, the DCO does take a bit of work for users the first time. The instructions for the last commit is clear:
git commit --amend --signoff
git push -f

but if you have more than one commit you actually have to:
git rebase --exec 'git commit --amend --no-edit -n --signoff' -i origin/master
git push -f

repo: kube-rs/kube-rs


text:
the two edge node edgemesh-agent peer ID is same

1. my issues
why the two edge node edgemesh-agent peer ID is same ?
the same peer ID: QmS8zXjedoqHhagXVPje4SMx6cReYfNryxqM5JGzZYAWAw
Where is the configuration wrong?

EdgeMesh version: release-1.8
Kubernetes version (use kubectl version): 1.19
KubeEdge version(e.g. cloudcore --version and edgecore --version): 1.8
cloud node(master)
ip: 39.130.243.252(172.24.178.41)
0.0.0.0:20004   edgemesh-server
0.0.0.0:20006   edgemesh-agent

edge node1(ynu-jxnode)
ip: 172.24.178.51
0.0.0.0:20006   edgemesh-agent

edge node2(yunnanzt)
ip: 172.16.70.201
0.0.0.0:20006   edgemesh-agent

[root@master ~]# kubectl get node
master          Ready    master         92d       v1.14.1                   172.24.178.41
ynu-jxnode     Ready    agent,edge   6d17h     v1.19.3-kubeedge-v1.8.2   172.24.5.21
yunnanzt       Ready    agent,edge   13d       v1.19.3-kubeedge-v1.8.2    172.16.70.201

[root@master ~]# kubectl get secret -n kubeedge edgemeshaddrsecret -o yaml
master: eyJJRCI6IlFtWXpxV2lHRGdYRTg0SEp1ZUt5eW91aU1na1FLY2JpSlpTRnl5TTFSRTZGWnYiLCJBZGRycyI6WyIvaXA0LzE3Mi4yNC4xNzguNDEvdGNwLzIwMDA2IiwiL2lwNC8xMjcuMC4wLjEvdGNwLzIwMDA2IiwiL2lwNC8xNzIuMjQuMTc4LjQxL3RjcC8yMDAwNC9wMnAvUW1mVE1kU1pDRkhWdnhVTW5zdFlqbUZZUjdxVXFMUU5KckFXOEE1M21CWEN2VC9wMnAtY2lyY3VpdCIsIi9pcDQvMTI3LjAuMC4xL3RjcC8yMDAwNC9wMnAvUW1mVE1kU1pDRkhWdnhVTW5zdFlqbUZZUjdxVXFMUU5KckFXOEE1M21CWEN2VC9wMnAtY2lyY3VpdCIsIi9pcDQvMzkuMTMwLjI0My4yNTIvdGNwLzIwMDA0L3AycC9RbWZUTWRTWkNGSFZ2eFVNbnN0WWptRllSN3FVcUxRTkpyQVc4QTUzbUJYQ3ZUL3AycC1jaXJjdWl0Il19
ynu-jxnode: eyJJRCI6IlFtUzh6WGplZG9xSGhhZ1hWUGplNFNNeDZjUmVZZk5yeXhxTTVKR3paWUFXQXciLCJBZGRycyI6WyIvaXA0LzE3Mi4yNC4xNzguNTEvdGNwLzIwMDA2IiwiL2lwNC8xMjcuMC4wLjEvdGNwLzIwMDA2IiwiL2lwNC8zOS4xMjkuNS45L3RjcC8yMDAwNiIsIi9pcDQvMTcyLjI0LjE3OC40MS90Y3AvMjAwMDQvcDJwL1FtZlRNZFNaQ0ZIVnZ4VU1uc3RZam1GWVI3cVVxTFFOSnJBVzhBNTNtQlhDdlQvcDJwLWNpcmN1aXQiLCIvaXA0LzEyNy4wLjAuMS90Y3AvMjAwMDQvcDJwL1FtZlRNZFNaQ0ZIVnZ4VU1uc3RZam1GWVI3cVVxTFFOSnJBVzhBNTNtQlhDdlQvcDJwLWNpcmN1aXQiLCIvaXA0LzM5LjEzMC4yNDMuMjUyL3RjcC8yMDAwNC9wMnAvUW1mVE1kU1pDRkhWdnhVTW5zdFlqbUZZUjdxVXFMUU5KckFXOEE1M21CWEN2VC9wMnAtY2lyY3VpdCJdfQ==
yunnanzt: eyJJRCI6IlFtUzh6WGplZG9xSGhhZ1hWUGplNFNNeDZjUmVZZk5yeXhxTTVKR3paWUFXQXciLCJBZGRycyI6WyIvaXA0LzE3Mi4xNi43MC4yMDEvdGNwLzIwMDA2IiwiL2lwNC8xMjcuMC4wLjEvdGNwLzIwMDA2IiwiL2lwNC8xODMuMjI0LjgyLjIwMi90Y3AvMjA4MCIsIi9pcDQvMTcyLjI0LjE3OC40MS90Y3AvMjAwMDQvcDJwL1FtZlRNZFNaQ0ZIVnZ4VU1uc3RZam1GWVI3cVVxTFFOSnJBVzhBNTNtQlhDdlQvcDJwLWNpcmN1aXQiLCIvaXA0LzEyNy4wLjAuMS90Y3AvMjAwMDQvcDJwL1FtZlRNZFNaQ0ZIVnZ4VU1uc3RZam1GWVI3cVVxTFFOSnJBVzhBNTNtQlhDdlQvcDJwLWNpcmN1aXQiLCIvaXA0LzM5LjEzMC4yNDMuMjUyL3RjcC8yMDAwNC9wMnAvUW1mVE1kU1pDRkhWdnhVTW5zdFlqbUZZUjdxVXFMUU5KckFXOEE1M21CWEN2VC9wMnAtY2lyY3VpdCJdfQ==

###Base64 decode
master:
{"ID":"QmYzqWiGDgXE84HJueKyyouiMgkQKcbiJZSFyyM1RE6FZv","Addrs":["/ip4/172.24.178.41/tcp/20006","/ip4/127.0.0.1/tcp/20006","/ip4/172.24.178.41/tcp/20004/p2p/QmfTMdSZCFHVvxUMnstYjmFYR7qUqLQNJrAW8A53mBXCvT/p2p-circuit","/ip4/127.0.0.1/tcp/20004/p2p/QmfTMdSZCFHVvxUMnstYjmFYR7qUqLQNJrAW8A53mBXCvT/p2p-circuit","/ip4/39.130.243.252/tcp/20004/p2p/QmfTMdSZCFHVvxUMnstYjmFYR7qUqLQNJrAW8A53mBXCvT/p2p-circuit"]}

ynu-jxnode:
{"ID":"QmS8zXjedoqHhagXVPje4SMx6cReYfNryxqM5JGzZYAWAw","Addrs":["/ip4/172.24.178.51/tcp/20006","/ip4/127.0.0.1/tcp/20006","/ip4/39.129.5.9/tcp/20006","/ip4/172.24.178.41/tcp/20004/p2p/QmfTMdSZCFHVvxUMnstYjmFYR7qUqLQNJrAW8A53mBXCvT/p2p-circuit","/ip4/127.0.0.1/tcp/20004/p2p/QmfTMdSZCFHVvxUMnstYjmFYR7qUqLQNJrAW8A53mBXCvT/p2p-circuit","/ip4/39.130.243.252/tcp/20004/p2p/QmfTMdSZCFHVvxUMnstYjmFYR7qUqLQNJrAW8A53mBXCvT/p2p-circuit"]}

yunnanzt:
{"ID":"QmS8zXjedoqHhagXVPje4SMx6cReYfNryxqM5JGzZYAWAw","Addrs":["/ip4/172.16.70.201/tcp/20006","/ip4/127.0.0.1/tcp/20006","/ip4/183.224.82.202/tcp/2080","/ip4/172.24.178.41/tcp/20004/p2p/QmfTMdSZCFHVvxUMnstYjmFYR7qUqLQNJrAW8A53mBXCvT/p2p-circuit","/ip4/127.0.0.1/tcp/20004/p2p/QmfTMdSZCFHVvxUMnstYjmFYR7qUqLQNJrAW8A53mBXCvT/p2p-circuit","/ip4/39.130.243.252/tcp/20004/p2p/QmfTMdSZCFHVvxUMnstYjmFYR7qUqLQNJrAW8A53mBXCvT/p2p-circuit"]}

2. nodeName config
https://zhuanlan.zhihu.com/p/585749690
peer ID是根据节点名称哈希出来的，相同的节点名称会哈希出相同的peer ID
配置似乎没有问题, 节点名是动态获取的
vi 07-daemonset-edge.yaml
......
        image: kubeedge/edgemesh-agent:v1.8.0
        env:
            - name: MY_NODE_NAME
              valueFrom:
                fieldRef:
                  fieldPath: spec.nodeName
......

looking forward to your help.

配置不对，>=1.12.0后 使用NODE_NAME环境变量，而不是MY_NODE_NAME

配置不对，>=1.12.0后 使用NODE_NAME环境变量，而不是MY_NODE_NAME
我用的edgemesh 版本是v1.8

配置不对，>=1.12.0后 使用NODE_NAME环境变量，而不是MY_NODE_NAME

我用的edgemesh 版本是v1.8     k8s版本1.14

https://zhuanlan.zhihu.com/p/585749690
peer ID是根据节点名称哈希出来的，相同的节点名称会哈希出相同的peer ID

上面这段话，针对>=1.12.0写的，其他版本没有这个。建议升级使用搞版本

https://zhuanlan.zhihu.com/p/585749690
peer ID是根据节点名称哈希出来的，相同的节点名称会哈希出相同的peer ID

上面这段话，针对>=1.12.0写的，其他版本没有这个。建议升级使用高版本

这个是客户环境， 升级k8s成本很高.
想知道 低版本peer ID的生成规则是怎样的？

升级edgemesh版本。低版本生成peer ID见https://github.com/kubeedge/edgemesh/blob/release-1.8/agent/pkg/tunnel/module.go#L49

目前故障是2个边缘节点edgemesh-agent,
重启A，B上的svc服务就正常, A上的svc不正常。
重启B，A上的svc服务就正常, B上的svc不正常。

请提供日志

repo: kubeedge/edgemesh


text:
OAS: add generic artifacts routes

Closes: #369
Description
Implements generic artifact routes as proposed.
There will be a follow-up to add new methods to the Python client as well.
How Has This Been Tested?
Updated unit tests to cover new core methods.
Merge criteria:

All the commits have been signed-off  (To pass the DCO check)

[ ] The commits have meaningful messages; the author will squash them after approval or in case of manual merges will ask to merge with squash.
[ ] Testing instructions have been added in the PR body (for PRs involving changes that are not immediately obvious).
[ ] The developer has manually tested the changes and verified that the changes work.
[ ] Code changes follow the kubeflow contribution guidelines.

If you have UI changes

[ ] The developer has added tests or explained why testing cannot be added.
[ ] Included any necessary screenshots or gifs if it was a UI change.
[ ] Verify that UI/UX changes conform the UX guidelines for Kubeflow.

#406 (comment) +1
thank you again @isinyaaa /lgtm
focusing on the Go side, anything 👀 worth noting @Al-Pragliola ?
I see the new routes and I don't see changes to the path of the existing REST apis, beyond that
	if artifact == nil {
		return nil, fmt.Errorf("invalid artifact pointer, can't upsert nil: %w", api.ErrBadRequest)
	}

so I'm good with merging asap, I just wanted to double-check this understanding

Looks Good To Me 👍

authors: Al-Pragliola isinyaaa

repo: kubeflow/model-registry


text:
Update kubeflow common to 0.3.2

As titled, upgrade kubeflow common to 0.3.2.

Coverage remained the same at 71.59% when pulling 4c879588b9af706447f839c02273a9da90482f0e on shaowei-su:shaowei--update-common-0.3.2 into 5f002e4a3377c98d74ab267851fa4536061fcc6c on kubeflow:master.

Coverage remained the same at 71.59% when pulling 4c879588b9af706447f839c02273a9da90482f0e on shaowei-su:shaowei--update-common-0.3.2 into 5f002e4a3377c98d74ab267851fa4536061fcc6c on kubeflow:master.

authors: coveralls shaowei-su

repo: kubeflow/tf-operator


text:
Update training operator release process

This is a follow up of @terrytangyuan's requests in https://github.com/kubeflow/tf-operator/pull/1339#pullrequestreview-723776607
I add the release scripts in repo

Change release process
Check in python tool to generate changelog
Fix v1.2.0 changlog

/cc @kubeflow/wg-training-leads

/approve


text:
[v2alpha] Move GV related codebase

Move GV related codebase in v2alpha

What this PR does / why we need it:
Address: https://github.com/kubeflow/training-operator/pull/2273#discussion_r1796036566
Which issue(s) this PR fixes (optional, in Fixes #<issue number>, #<issue number>, ... format, will close the issue(s) when PR gets merged):
Fixes #
Checklist:

[ ] Docs included if any changes are user facing

Pull Request Test Coverage Report for Build 11300603714
Warning: This coverage report may be inaccurate.
This pull request's base commit is no longer the HEAD commit of its target branch. This means it includes changes from outside the original pull request, including, potentially, unrelated coverage changes.

For more information on this, see Tracking coverage changes with pull request builds.
To avoid this issue with future PRs, see these Recommended CI Configurations.
For a quick fix, rebase this PR at GitHub. Your next report should be accurate.

Details

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

Totals

Change from base Build 11297771461:
0.0%

Covered Lines:
66

Relevant Lines:
66

💛  - Coveralls

repo: kubeflow/training-operator


text:
Updated notebook setup guide for Kubeflow 1.0.0 UI

Fixes https://github.com/kubeflow/website/issues/1761
Fixes https://github.com/kubeflow/website/issues/1507
A number of options have changed in the notebook setup for Kubeflow 1.0.0. This PR updates the setup guide accordingly.

This change is

Preview: https://deploy-preview-1762--competent-brattain-de2d6d.netlify.com/docs/notebooks/setup/
@kimwnasptd Please would you review this PR and LGTM if you're happy with the updates?
/cc @kimwnasptd

/assign @abhi-g
@abhi-g Could you take a look at this PR or assign someone else to do so? I'm not having much luck finding a reviewer. :)

Sorry for the delay @sarahmaddox taking a look right now :)

/assign @kimwnasptd
/unassign @abhi-g
Thanks @kimwnasptd PTAL

/lgtm

Thanks @kimwnasptd !
/approve

authors: kimwnasptd sarahmaddox

repo: kubeflow/website


text:
Update GKE getting started guide and accessing UIs page.

Replace instructions for building kfctl with instructions for
downloading kfctl prebuilt binaries

Update the page about accessing UIs.

Split the GKE getting started guide into multiple sub pages

Fix #529

This change is

/assign @gabrielwen
/assign @sarahmaddox
I think this is ready for review.

Preview: https://deploy-preview-568--competent-brattain-de2d6d.netlify.com/docs/started/gcp/

Thanks @jlewi! I have some general comments before doing a full review:

Now that the GCP getting-started guide is a set of docs rather than a single doc, I think we should move the entire set into the GKE section and just put a summary page into the getting-started section.

We need more guidance at the end of each doc about where people should go next. For example, at the end of the GCP setup doc we should give people guidance about their choices and link to the IAP/UI/CLI docs appropriately.

There are a few tech writing tweaks that I'd like to make, but it may be more efficient to merge this PR and then for me to send you a follow-up PR with the fixes.

Let me know what you think.

I like the idea of organizing all of the GKE related information in one section. I'll make that change.

@sarahmaddox I re-organized the pages to put all of them in GKE section. Do you want to take a look while I work on the other changes?
The existing link
https://www.kubeflow.org/docs/started/getting-started-gke/
Is still there but has a link to the new section. Do we still need a redirect somewhere to point to the new docs? I think that is the only link that changed.

Thanks! I'll LGTM it and leave you to approve it when you've received all the reviews you want.
/lgtm

@gabrielwen I think this is ready for review.

/lgtm

/approve

authors: gabrielwen jlewi sarahmaddox


text:
Update hyperparameter.md

Fixed broken link in docs

This change is

I signed it!

/assign @paveldournov

/assign
/ok-to-test
/lgtm
/approve

Thanks!

authors: michalbrys sarahmaddox


text:
如何使用单机玩k8s

我们需要在本地安装测试gcs，请问如何单机安装使用k8s呀？

可以参照我们的安装文档https://kubegene.io/docs/started/getting-started-minikube/

或者你可以通过 kind 启动测试机集群

$ GO111MODULE="on" go get sigs.k8s.io/kind@v0.4.0

$ kind create cluster

我通过 GO111MODULE="on" go get sigs.k8s.io/kind@v0.4.0 来安装，然后就报错了。
xugangmacbook:node_modules xugang$ GO111MODULE="on" go get sigs.k8s.io/kind@v0.4.0
go get sigs.k8s.io/kind@v0.4.0: unrecognized import path "sigs.k8s.io/kind" (https fetch: Get https://sigs.k8s.io/kind?go-get=1: dial tcp 35.201.71.162:443: i/o timeout)

应该是网络访问问题，你需要设置代理， 了解一下goproxy https://goproxy.io/

minikube好像是在单机上安装虚拟机构建的集群，如果是真实的多物理机集群，是否必须要k8s？如果是k3s这种轻量级Kubernetes发行版是否可以用，毕竟安装安装的k8s好像很麻烦？

authors: Zhu-Ying hzxuzhonghu xug15

repo: kubegene/kubegene


text:
Fixed the issue of metrics for golang runtime

Issue Ref: https://github.com/kubeless/kubeless/issues/1020
Description: Removed promhttp.Handler from kubeless/runtime/stable/golang/kubeless.tpl.go and put it inside the pkg/function-proxy/utils/proxy-utils.go so that it can scrape the registered metrics.
This should make it possible to get the registered metrics by doing a simple curl on the http-function-port/metrics
TODOs:

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

anyone looking for the fix can apply this in their cluster in the meantime while there is no new release:
https://2824-73902337-gh.circle-artifacts.com/0/build-manifests/kubeless.yaml and restart the kubeless-controller-manager pod.

repo: kubeless/kubeless


text:
go package management is experiencing issues and cannot download the dependencies.

git clone https://github.com/kubeovn/kube-ovn
....
....
cd kube-ovn
git checkout v1.12.11
go mod tidy
...
...
go: github.com/moby/ipvs@v1.1.0 requires
        github.com/vishvananda/netlink@v1.1.0 (replaced by github.com/kubeovn/netlink@v0.0.0-20230322092337-960188369daf): reading https://goproxy.io/github.com/kubeovn/netlink/@v/v0.0.0-20230322092337-960188369daf.mod: 404 Not Found
        server response: not found: github.com/kubeovn/netlink@v0.0.0-20230322092337-960188369daf: invalid version: unknown revision 960188369daf

git checkout v1.11.16
...
...go: github.com/Mellanox/sriovnet@v1.1.0 requires
        github.com/vishvananda/netlink@v1.1.1-0.20211101163509-b10eb8fe5cf6 (replaced by github.com/kubeovn/netlink@v0.0.0-20230322092337-960188369daf): reading https://goproxy.io/github.com/kubeovn/netlink/@v/v0.0.0-20230322092337-960188369daf.mod: 404 Not Found
        server response: not found: github.com/kubeovn/netlink@v0.0.0-20230322092337-960188369daf: invalid version: unknown revision 960188369daf

# get https://goproxy.io/github.com/kubeovn/netlink/@v/v0.0.0-20230322092337-960188369daf.mod: 404 Not Found (0.862s)
# get https://goproxy.io/github.com/kubeovn/libovsdb/@v/v0.0.0-20230517064328-9d5a1383643f.mod: 404 Not Found (0.867s)

Why?

master branch, commit: 748aac73a9ef231e8218c7ff764081171f36ebae
go: github.com/danwinship/knftables@v0.0.13: reading https://goproxy.io/github.com/danwinship/knftables/@v/v0.0.13.info: 404 Not Found
	server response: not found: github.com/danwinship/knftables@v0.0.13: invalid version: unknown revision v0.0.13
go: github.com/veraison/go-cose@v1.2.0: reading https://goproxy.io/github.com/veraison/go-cose/@v/v1.2.0.info: 404 Not Found
	server response: not found: github.com/veraison/go-cose@v1.2.0: invalid version: unknown revision v1.2.0

@zhangzujian It seems I can't download dependencies in any version. What should I do?

I successfully downloaded the dependencies using make release. I'm not sure how this differs from go mod tidy, but it does work.

repo: kubeovn/kube-ovn


text:
Fix defaults not being honored by new_client_from_config

Fixes https://github.com/kubernetes-client/python/issues/597
This change seems to have broken defaults being honored by new_client_from_config. This switches it to allow the default values to be used.

Signed.

repo: kubernetes-client/python-base


text:
use CSI connection lib

Mostly followed kubernetes-csi/external-attacher#123 with the exception of adding the reconnect callback on connection loss. Left it out because it doesn't handle address starting with unix:// so the unit tests would fail:
--- FAIL: TestGetNodeID (0.00s)
    connection_test.go:90: OnConnectionLoss callback only supported for unix:// addresses

Left that option out for now. If it's important I can refactor the tests to use a different address?
/assign @msau42 @jsafrane

/lgtm
/approve

authors: andrewsykim jsafrane

repo: kubernetes-csi/cluster-driver-registrar


text:
Add extra info to verbose requests to PodSandboxStatus

What I did

I added version info in a JSON object to this response when verbose is set to true here.

How I did it

I added some tests to cover the functionality before changing it, these tests include some fixture that maybe could be good to move to some other place.

How to verify it

The tests should be enough, but if that grpc endpoing can be easilly called it should return the version info in a JSON object.
If PodSandboxStatusRequest.Verbose is true now we are returning the cri-o
version in a JSON object for debug purposes. In the future extra information
(to be defined) should be added to the response

Description for the changelog

Add extra info to verbose requests to PodSandboxStatus

Extra notes

We should probably add more info to that endpoint, but I don't know what should be shown there.
I know that adding an extra vendored dependency could be painful in a big project, but I strongly recommend this: https://github.com/stretchr/testify to don't duplicate asserts logic.
As I previously mentioned, some of the fixtures I added could be helpful in some other place (or maybe there are already there and I didn't know it).

The tests are failing on Travis because it seems the user running the test don't have permissions to chown on /tmp. I honestly don't know how to get around this issue, on my machine I am using a container as root.
I am also using vfs instead other option to avoid an error here: https://github.com/kubernetes-incubator/cri-o/blob/master/vendor/github.com/containers/storage/drivers/driver.go#L221
How this testing can be performed in some other way to make it pass on CI?

/ok-to-test

@agonzalezro We'll have to check if travis supports any tmp directory.

Apparently you can set TMPDIR=/tmp in .travis.yml file as environment variable.

@mrunalp I tried to change the test to use $TMPDIR but it didn't work.
Do you have any other idea about how to work this around? Do you have or can think on a better way to "mock" this?

I did the requested changes, however I don't know how to solve the issue
with the chown. If you are ok with tunning the tests as root, at leat tor
try, I can do the needed change.

--
@agonzalezro http://twitter.com/agonzalezro or my blog
http://agonzalezro.github.io/

Not sure how you can do a chown with out running as privileged, you need CAP_CHOWN, although I don't see where it is failing.  I did not understand the second part of your comment.

Sorry, I wrote the message from the email (I edited the previous comment).
Where I said "tunning" I meant "running", add a sudo to the make test instruction inside the .travis.yml file.

@agonzalezro I think you need to run tests as root.

I think you need to run tests as root.

I agree, see my sudo make testunit in .travis.yml suggestion.

With sudo everything becomes green :) Thanks to all!

LGTM
@mrunalp @runcom PTAL
Do we need to run e2e tests?

@agonzalezro I think you should rebase this PR>

@rhatdan done

/test all

I can only see the Jenkins results.
And what I see there seems like a timeout. Is that really related with my tests or is it a glitch in the integration tests?

Most likely the same issue we have been seeing on RHEL,  There seems to be a race condition bug in the kernel.  There is an issue talking about it.
/test integration_rhel

Passes all tests.
Merging.

authors: agonzalezro mrunalp rhatdan wking

repo: kubernetes-incubator/cri-o


text:
Fix container_name incorrectly being generated

Checks to see if "container_name" is used correctly in a docker-compose
file conversion and updates the changes respectively in the outputted
artifact files.
For example with container_name set as myfoobarname, the change will
correctly update the "containerNames" portion of the deployment-config
for OpenShift.
"imageChangeParams": {
"automatic": true,
"containerNames": [
"myfoobarname"
],
"from": {
"kind": "ImageStreamTag",
"name": "rabbit:3.6.1"
}
}
Closes https://github.com/kubernetes-incubator/kompose/issues/301

Coverage decreased (-0.06%) to 34.954% when pulling ee2946c810082be662b59b91b8245f8fae3717a5 on cdrage:namespace-bug into 04a3131834cddfb1af42b63b21641fbbf84a4a9d on kubernetes-incubator:master.

@surajssd @kadel Can you guys have a look at this one?

LGTM, @cdrage but need to satisfy coveralls :(

Coveralls is OK, don't trust that number.  ;-)
It decreased because there were no tests before ;-)

@kadel but merging is blocked !

@surajssd as part of your review, you have to approve changes. see  https://help.github.com/articles/about-pull-request-reviews/

authors: cdrage coveralls kadel pradeepto surajssd

repo: kubernetes-incubator/kompose


text:
Update doc with better console output and add note on deployment config

Adds note on Deployment Config as well as updates console output for
Kubernetes example

LGTM. But @surajnarwade @surajssd @containscafeine Can one of you review and approve this? Thanks.

LGTM :)

authors: cdrage pradeepto surajnarwade


text:
Generate a ~/.kube/config file for users?

This is an enhancement request - since the playbooks have all the info needed to generate a kubectl configuration file, this would be a nice to have to drop in the ~/.kube/ dir either on the nodes or in the directory where the playbooks were run. Remote kubectl access would be the norm in my mind

It's pretty 'simple' - once cargo is done you want to grab these from the master:

/etc/kubernetes/ssl/admin-key.pem
/etc/kubernetes/ssl/ca.pem
/etc/kubernetes/ssl/admin.pem

The user can then run:
kubectl config set-cluster default-cluster --server=https://${MASTER} \
    --certificate-authority=/path/to/ca.pem

kubectl config set-credentials default-admin \
    --certificate-authority=/path/to/ca.pem \
    --client-key=/path/to/admin-key.pem \
    --client-certificate=/path/to/admin.pem

kubectl config set-credentials default-admin \
    --certificate-authority=/path/to/ca.pem \
    --client-key=/path/to/admin-key.pem \
    --client-certificate=/path/to/admin.pem

kubectl config set-context default-system --cluster=default-cluster --user=default-admin
kubectl config use-context default-system

Yes good idea, maybe a role named postinstall with the insecure_registry needed by @rsmitty in #256.

Would you be interested in me updating my merge request to setup the
postinstall role to come at the very end? Would at least create the
structure for this to be added.
On May 21, 2016 03:38, "Smaine Kahlouch" notifications@github.com wrote:

Yes good idea, maybe a role named postinstall with the insecure_registry
needed by @rsmitty https://github.com/rsmitty in #256
https://github.com/kubespray/kargo/pull/256.
—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
https://github.com/kubespray/kargo/issues/257#issuecomment-220764098

I have some thoughts in this. My open contrail playbook request had this
because open contrail needs extra stuff at the end.
Though for docker I think we have a different problem to think about.
I'll try and elaborate later today
Greg
On Saturday, May 21, 2016, Spencer Smith notifications@github.com wrote:

Would you be interested in me updating my merge request to setup the
postinstall role to come at the very end? Would at least create the
structure for this to be added.
On May 21, 2016 03:38, "Smaine Kahlouch" <notifications@github.com
<javascript:_e(%7B%7D,'cvml','notifications@github.com');>> wrote:

Yes good idea, maybe a role named postinstall with the insecure_registry
needed by @rsmitty https://github.com/rsmitty in #256
https://github.com/kubespray/kargo/pull/256.
—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
https://github.com/kubespray/kargo/issues/257#issuecomment-220764098

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
https://github.com/kubespray/kargo/issues/257#issuecomment-220785294

+1   in the very least @jnoller 's comment should be added to the docs

I had an almost similar/related request for kargo-cli https://github.com/kubespray/kargo-cli/issues/19

I've added pull #288 to address grabbing the certs, but we'll want to also update the docs to show @jnoller's commands with the output/certs/ directory.

Or at the very least, when the ansible playbook run is complete, do as #534 would be nice.

I have automated the process with a makefile, it's for a provisioner I made for cloudatcost, I've been meaning to make all this a module like GCE or AWS that could be invoked instead, but I haven't gotten around to it, and have merely bolted on some extra steps using bash.
it looks like this:
kargoConfig:
	$(eval TMP := $(shell mktemp -d --suffix=DOCKERTMP))
	$(eval SSH_PORT := $(shell cat SSH_PORT))
	$(eval PWD := $(shell pwd))
	head -n1 workingList > $(TMP)/masterList
	echo  '#!/bin/bash' > $(TMP)/mkargo.sh
	echo 'export ANSIBLE_SCP_IF_SSH=y'>> $(TMP)/mkargo.sh
	while read SID HOSTNAME NAME IP ROOTPASSWORD ID; \
		do \
		mkdir -p certs/$$NAME ; \
	    echo "scp -P $(SSH_PORT) root@$$IP:/etc/kubernetes/ssl/admin-key.pem certs/$$NAME/" >> $(TMP)/mkargo.sh ; \
	    echo "scp -P $(SSH_PORT) root@$$IP:/etc/kubernetes/ssl/ca.pem certs/$$NAME/" >> $(TMP)/mkargo.sh ; \
	    echo "scp -P $(SSH_PORT) root@$$IP:/etc/kubernetes/ssl/admin.pem certs/$$NAME/" >> $(TMP)/mkargo.sh ; \
		echo -n "kubectl config set-cluster default-cluster " >> $(TMP)/mkargo.sh ; \
		echo -n " --kubeconfig=/root/.kube/config " >> $(TMP)/mkargo.sh ; \
		echo -n " --embed-certs=true  " >> $(TMP)/mkargo.sh ; \
		echo -n " --server=https://$$IP " >> $(TMP)/mkargo.sh ; \
		echo " --certificate-authority=$(PWD)/certs/$$NAME/ca.pem " >> $(TMP)/mkargo.sh ; \
		echo -n "kubectl config set-credentials default-admin " >> $(TMP)/mkargo.sh ; \
		echo -n " --kubeconfig=/root/.kube/config " >> $(TMP)/mkargo.sh ; \
		echo -n " --embed-certs=true " >> $(TMP)/mkargo.sh ; \
		echo -n " --certificate-authority=$(PWD)/certs/$$NAME/ca.pem " >> $(TMP)/mkargo.sh ; \
		echo -n " --client-key=$(PWD)/certs/$$NAME/admin-key.pem " >> $(TMP)/mkargo.sh ; \
		echo " --client-certificate=$(PWD)/certs/$$NAME/admin.pem " >> $(TMP)/mkargo.sh ; \
		echo -n "kubectl config set-context default-system " >> $(TMP)/mkargo.sh ; \
		echo -n " --kubeconfig=/root/.kube/config " >> $(TMP)/mkargo.sh ; \
		echo " --cluster=default-cluster --user=default-admin " >> $(TMP)/mkargo.sh ; \
		echo "kubectl config use-context default-system " >> $(TMP)/mkargo.sh ; \
		done < $(TMP)/masterList
	@bash $(TMP)/mkargo.sh
@rm -Rf $(TMP)

https://github.com/joshuacox/mkcloudatcost

Here is an ansible way of fetching and setting up a kubectl config for kargo:
---
- hosts: kube-master[0]
  gather_facts: no
  become: yes
  tasks:
    - fetch:
        src: "/etc/kubernetes/ssl/{{ item }}.pem"
        dest: "{{ playbook_dir }}/kubectl/{{ item }}.pem"
        flat: True
      with_items:
        - admin-{{ inventory_hostname }}-key
        - admin-{{ inventory_hostname }}
        - ca
    - name: export hostname
      set_fact:
        kubectl_name: "{{ inventory_hostname }}"

- hosts: localhost
  connection: local
  vars:
    kubectl_name: "{{ hostvars[groups['kube-master'][0]].kubectl_name }}"
  tasks:
    - name: check if context exists
      command: kubectl config get-contexts kargo
      register: kctl
      failed_when: kctl.rc == 0
    - block:
      - name: create cluster kargo
        command: kubectl config set-cluster kargo-admin --certificate-authority={{ playbook_dir }}/kubectl/ca.pem
      - name: create credentials kargo-admin
        command: kubectl config set-credentials kargo-admin --certificate-authority={{ playbook_dir }}/kubectl/ca.pem --client-key={{ playbook_dir }}/kubectl/admin-{{ kubectl_name }}-key.pem --client-certificate={{ playbook_dir }}/kubectl/admin-{{ kubectl_name }}.pem
      - name: create context kargo
        command: kubectl config set-context kargo --cluster=kargo-cluster --user=kargo-admin
      when: kctl.rc != 0

It took me 20 mins to get the vagrant setup going, so i can try out kargo.
It took me over 2 hours to work out how to configure kubectl to connect to the vagrant cluster from the host.
Imho, a fix to this would really improve the out-of-the-box experience for new users and would help attract even more users for the project.
Btw, thanks @jnoller !  👍   (p.s. you might want to remove one of the two set-credentials commands)

API moved to port 6443 according to #1083

I second @gsaslis , at work we runs kops and it generates the config, but I wanted something for personal use. Everything went fine until it was time to kubectl. I have it working now thanks to this post and a guy in the slack channel but I still have questions. I have 3 masters so I have a key set per master, is that normal?

@shadycuz I think it is. Personally this is really a very time consuming and frustrating step. Hope this is getting some attention :)

@jnoller So. I still have a lot of trouble with the kubectl config.
My small script looks like the following:
`
export MASTER_HOST='kube-admin-node1'
export CA_CERT='/path/to/admin-node1/ca.pem'
export ADMIN_KEY='/path/to/admin-node1-key.pem'
export ADMIN_CERT='/path/to/admin-node1.pem '
kubectl config set-cluster default-cluster --server=https://${MASTER_HOST}:6443
--certificate-authority=${CA_CERT}
kubectl config set-credentials default-admin
--certificate-authority=${CA_CERT}
--client-key=${ADMIN_KEY}
--client-certificate=${ADMIN_CERT}
kubectl config set-context default-system --cluster=default-cluster --user=default-admin
kubectl config use-context default-system
`
First problem was that I ran into a certificate conflict (tried to connect with IP to server)
`
kubectl get node
Unable to connect to the server: x509: cannot validate certificate for XX.XX.XX.XX because it doesn't contain any IP SANs`
"Fixed" this with editing the /etc/hosts to
XX.XX.XX.XX   kube-admin-node1
Now I get the following error:
`
kubectl get node
Unable to connect to the server: x509: certificate signed by unknown authority`
Maybe someone has an idea for this.
Greetings
~ ArgonQQ

This took some of my time as well, here is easy solution (tested with kubernetes v1.6.7):

Make sure your server reachable on port 6443 (centos may have firewall)

$ curl -k https://YOUR_MASTER_PUBLIC_IP:6443
Unauthorized

Create ~/.kube/config:

apiVersion: v1
clusters:
- cluster:
    # needed if you get error "Unable to connect to the server: x509: certificate signed by unknown authority"
    insecure-skip-tls-verify: true
    # port 6443 is for secure connection
    server: https://YOUR_MASTER_PUBLIC_IP:6443
  name: kubernetes
contexts:
- context:
    cluster: kubernetes
    user: kubernetes-admin
  name: kubernetes-admin@kubernetes
current-context: kubernetes-admin@kubernetes
kind: Config
preferences: {}
users:
- name: kubernetes-admin
  user:
    client-certificate-data: LS0tLS1CRUdJTi... (base64 /etc/kubernetes/ssl/node-node1.pem)
    client-key-data: LS0tLS1CRUdJTiBS.. (base64 /etc/kubernetes/ssl/node-node1-key.pem)

Inline certificates:

Set client-certificate-data: with output of:
cat /etc/kubernetes/ssl/node-node1.pem | base64 -w 0

Set client-certificate-data with output of:
cat /etc/kubernetes/ssl/node-node1-key.pem | base64 -w 0

Make sure it's running:
$ kubectl get nodes
NAME      STATUS    AGE       VERSION
my-kube   Ready     2h        v1.6.7+coreos.0

If you save config with other name then can tell kubectl via env variable:
export KUBECONFIG=/path/to/kubectl_config

@Paxa That's more of an dirty hack than a real solution :smile: . I am still trying to investigate how to get kubectl up and running without using insecure-skip-tls-verify: true.
Why are you trying to base64 the certificates?
simply replace client-certificate-data with client-certificate  and client-key-data with client-key and the full path behind. That's a cleaner solution, at least that's what I am doing.
Greetings
~ ArgonQQ

@ArgonQQ I prefer to have all in 1 file instead, easier to share with my team
We can use real certificate instead of insecure-skip-tls-verify:
apiVersion: v1
clusters:
- cluster:
    certificate-authority: /etc/kubernetes/ssl/ca.pem # copy this file from server, can be stored anywhere
    server: https://YOUR_MASTER_PUBLIC_IP:6443

In my case cloud service gives public IP different then IP in ifconfig so I need to specify public IP on setup and I always forget :(

@Paxa That's true. All in one has its benefits too :+1:
If I copy the ca file from the master and setup the master ip the only thing I get in response is:
Unable to connect to the server: x509: certificate signed by unknown authority
Maybe you have any idea what I am doing wrong.
Greetings
~ ArgonQQ

@Paxa That's true. All in one has its benefits too 👍

If I copy the ca file from the master and setup the master ip the only thing I get in response is:
Unable to connect to the server: x509: certificate signed by unknown authority
Maybe you have any idea what I am doing wrong.
Greetings
~ ArgonQQ
Same here

I see that this issue is quite popular and nobody has contributed a working solution yet. I will make a PR with the following approach:
Create /etc/kubernetes/admin-kubeconfig.yaml which points to the first master (or loadbalancer if defined) with all the cert content baked in base64 format.
Copy the above file to /root/.kube/config
(above two will be enabled by default)
Create an optional play in the playbook to download kubectl and copy the kubeconfig to the ansible host which is running the playbook.

@mattymo https://github.com/kubernetes-incubator/kubespray/issues/1247

For all those who might be wondering if this is implemented. https://github.com/kubernetes-incubator/kubespray/pull/1647

@jnoller I dont have anything at /etc/kubernetes/ssl, but there are some certs in /etc/kubernetes/pki:
apiserver.crt
apiserver.key
apiserver-kubelet-client.crt
apiserver-kubelet-client.key
ca.crt
ca.key
front-proxy-ca.crt
front-proxy-ca.key
front-proxy-client.crt
front-proxy-client.key
sa.key
sa.pub

This certificates suites the snippet you posted?

I found this issue googling, I noticed some certs on one of my masters at /srv/kubernetes/
apiserver-aggregator-ca.cert apiserver-aggregator.cert apiserver-aggregator.key assets basic_auth.csv ca.crt ca.key known_tokens.csv proxy-client.cert proxy-client.key server.cert server.key

Just copy /etc/kubernetes/admin.conf from one of the master node as ~/.kube/config works for me

I have working setup kubectl with vagrant. On vagrant host I can use kubectl (after I have copied content with:  vagrant ssh k8s-1 -c "cat ~/.kube/config" >kubespray  && export KUBECONFIG=kubespray). How do I access cluster from outside vagrant host?

@atrakic I guess it's too late, or you already know this. But here the information about you said.
See Accessing Kubernetes API in this document :
kubespray guide
You can copy just from your inventory directory, rather than copying from vm. Or, you can use just binary in your inventory directory.

authors: ArgonQQ DanielRamosAcosta Paxa Smana Starefossen adamcstephens anencore94 atrakic chrisevett delfer galthaus gsaslis jcsirot jnoller joshuacox mattymo rsmitty sc68cal shadycuz xech3l0nx yifeikong

repo: kubernetes-incubator/kubespray


text:
Update published label prefix.

Fixes #27.

Changed prefix from node.alpha.intel.com/nfd to
node.alpha.kubernetes-incubator.io/nfd

Hold until a decision in #27.

Unblocking this one.

@balajismaniam ok to review

FWIW, LGTM.

/lgtm

authors: ConnorDoyle balajismaniam jeremyeder


text:
Release 1.0.0 part 2/3: helm and kustomize

Part of Release v1.0.0

/ok-to-test

/approve
/lgtm

authors: hughdanliu jacobwolfaws


text:
Increase default timeout on Windows

Signed-off-by: James Sturtevant jstur@microsoft.com

What type of PR is this?
/kind bug

What this PR does / why we need it:
Most interactions against Windows containers take longer than 2s. This increases the default so the user experience on Windows is better without having to modify every command or know to create a config file with the timeout.
When creating the first pod it can take a long time to pull due to image container sizes so the timeout here is very high to handle this scenario.  Starting a Pod can take longer than 2s even when the image is already pulled.
Which issue(s) this PR fixes:

Special notes for your reviewer:
/cc @dcantah @marosset
/sig windows
Does this PR introduce a user-facing change?

Increase default timeout to 200s when running on Windows

200s is just to account for the first pull of the pause image on RunPodSandbox I assume?

Ahh, it's in the description

I'd also like to add that if you forget to increase the timeout when creating a new pod or starting a container on Windows if the operation times out it is very tedious to try and clean up the failed operation.
This has personally caused me some frustration in the past.

/sig windows

I'd also like to add that if you forget to increase the timeout when creating a new pod or starting a container on Windows if the operation times out it is very tedious to try and clean up the failed operation.
This has personally caused me some frustration in the past.

In what way? Was this the "doesn't have {insert specific metadata field}" error we'd ran into before when testing things via crictl? I'd think that'd also hold true for Linux. I just remember crictl rm not functioning because it whined we didn't fill in every field, but nothing Windows specific

e "doesn't have {insert specific metadata field}" error we'd ran in

Yes it was that error. It may hold try for Linux but I have never encountered the issue on Linux w/ the default timeout :P

Fair enough LOL

/lgtm
@saschagrunert PTAL

authors: dcantah haircommander jsturtevant marosset

repo: kubernetes-sigs/cri-tools


text:
Descheduler | LowNodeUtilization Strategy - all nodes over utilized, no obvious message stating pods cannot be evicted

Is your feature request related to a problem? Please describe.
It's not obvious from looking at the log data from the container that there are no nodes available to evict pods to
We have the example log data where a number of nodes show "is over utilized with usage" but because all nodes are over utilized NO pods are evicted
I0217 12:00:13.698734       1 lownodeutilization.go:200] Node "ip-??-??-??-??.eu-west-1.compute.internal" is over utilized with usage: api.ResourceThresholds{"cpu":91.42857142857143, "memory":41.426692748347975, "pods":86.20689655172414}
I0217 12:00:13.698915       1 lownodeutilization.go:200] Node "ip-??-??-??-??.eu-west-1.compute.internal" is over utilized with usage: api.ResourceThresholds{"cpu":99.14285714285714, "memory":36.14741291652306, "pods":37.93103448275862}
I0217 12:00:13.699248       1 lownodeutilization.go:200] Node "ip-??-??-??-??.eu-west-1.compute.internal" is over utilized with usage: api.ResourceThresholds{"cpu":83.42857142857143, "memory":63.22589876113411, "pods":37.142857142857146}

No pods being evicted is fine - looking at the cluster it makes sense, but initially it was NOT so clear.
Would it be wise to add some log data to the logging that this is what is happening here?
Describe the solution you'd like
As suggest by @damemi (discussed on kubernetes slack channel #sig-scheduling) we could add the example text "All nodes overutilized, no evictions possible".
We might even be able to optimize the strategy for unnecessary work with that check too
Describe alternatives you've considered
N/A
What version of descheduler are you using?
descheduler version: 0.19.0
Additional context
As discussed here on slack - https://kubernetes.slack.com/archives/C09TP78DV/p1613593842089500

@martinwoods  It's supposed to log No node is underutilized, nothing to do here......, can you check your logs again to make sure that there's no more message? FYI, we do a few check here to avoid some unnecessary work.

@lixiang233 thanks for the reply
Yes you're right the message No node is underutilized, nothing to do here is logged e.g.
I0219 09:45:08.502255       1 lownodeutilization.go:105] No node is underutilized, nothing to do here, you might tune your thresholds further

And I have seen this message before raising this issue and I'll explain why I raised this even though this message does exist
Lets take my example yaml:
    LowNodeUtilization:
      enabled: true
      params:
        nodeResourceUtilizationThresholds:
          thresholds:
            cpu: 20
            memory: 20
            pods: 20
          targetThresholds:
            cpu: 70
            memory: 70
            pods: 75

As per the functionality there are two types of thresholds, the first is thresholds and the second targetThresholds
From looking at the log the message No node is underutilized, nothing to do here would refer to the first threshold thresholds as in Underutilized
As you can see from the below log the message is preceeded by the settings for underutilization:
    I0219 09:45:08.502197       1 lownodeutilization.go:101] Criteria for a node under utilization: CPU: 20, Mem: 20, Pods: 20
    I0219 09:45:08.502255       1 lownodeutilization.go:105] No node is underutilized, nothing to do here, you might tune your thresholds further

And the second threshold targetThresholds should have a different message as it's related to Overutilization as in the settings below
    targetThresholds:
        cpu: 70
        memory: 70
        pods: 75

As per the github documentation here:
"There is another configurable threshold, targetThresholds, that is used to compute those potential nodes from where pods could be evicted.
If a node's usage is above targetThreshold for any (cpu, memory, or number of pods), the node is considered over utilized"
Is my understanding correct?
If it is, again I don't think it's clear from the log data that the nodes which are overutilized don't have the cabability to evict pods to elsewhere
Look forward to your reply
Many thanks

Perhaps the documentation could be more explicit about the fact that overutilized nodes only evict toward underutilized nodes. If that distinction is clear, I think the logs tell you everything you need to know

@martinwoods  In this strategy, nodes are devided into 3 types: underutilized, overutilized and appropriately utilized. As @damemi said, pods can only be evicted from overutilized nodes to underutilized nodes, thus we should make  sure that both number of underutilized nodes and  overutilized nodes are non-zero before evicting any pod, number of underutilized nodes is checked first, so in your case, you only got messages related to underutilization.
@damemi  +1 for mention this in logs and I noticed that current logs can be optimized, I'll help to fix this.

authors: damemi lixiang233 martinwoods

repo: kubernetes-sigs/descheduler


text:
topologyspreadconstraint: support matchLabelKeys

Closes #1171
In Kubernetes 1.27, this feature flag was graduated to beta and it respects topology spread constraints during rolling upgrades. Descheduler currently does not honor this and apps could get unnecessary evictions during rolling upgrade
Ref: https://github.com/kubernetes/enhancements/issues/3243

/cc @ingvagabund

This
/lgtm
would it make sense to add a bit about this in our docs?

@knelasevero updated the docs.
Would you please take a look? also @ingvagabund need help moving this forward since this was officially supported in 1.27 but not in Descheduler 0.27 and 0.28

/lgtm
/hold
Hold for a bit to see if Jan has any comments, we can merge by eow if no comments or when another person has eyes on it

/approve
/hold cancel

@a7i this looks great. Thank you for all the refactoring.

authors: a7i ingvagabund knelasevero


text:
Refactored & Implemented new features for ServiceDNS

Ref: https://github.com/kubernetes-sigs/federation-v2/issues/348
/cc @danehans @pmorie @kubernetes-sigs/federation-v2-maintainers

/cc @danehans
now that he's a k-sigs member

authors: cblecker shashidharatd


text:
gRPC conformance: specify appProtocol

What type of PR is this?
/area conformance
What this PR does / why we need it:
This is already used for infra-backend, and is codified in Kubenetes (https://kubernetes.io/docs/concepts/services-networking/service/#application-protocol)
Which issue(s) this PR fixes:

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

Thanks @howardjohn!
/cc @dprotaso @gnossen @tao12345666333

Makes sense to use the standard
/approve

/lgtm

authors: dprotaso howardjohn keithmattix robscott

repo: kubernetes-sigs/gateway-api


text:
chore: Drop conversion webhooks

Fixes #N/A
Description
Dropping conversion webhook.
How was this change tested?
Manually tested
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

Pull Request Test Coverage Report for Build 10533702236
Details

0 of 1 (0.0%)  changed or added relevant line in 1 file are covered.
14 unchanged lines in 3 files lost coverage.
Overall coverage increased (+0.5%) to 78.34%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

pkg/operator/operator.go
0
1
0.0%

Files with Coverage Reduction
New Missed Lines
%

pkg/controllers/provisioning/scheduling/nodeclaim.go
2
89.13%

pkg/operator/injection/injection.go
4
33.33%

pkg/apis/v1beta1/duration.go
8
47.37%

Totals

Change from base Build 10499123622:
0.5%

Covered Lines:
8644

Relevant Lines:
11034

💛  - Coveralls

repo: kubernetes-sigs/karpenter


text:
Add an enabling the feturegate note to the setup a job admission policy docs

What type of PR is this?
/kind documentation
What this PR does / why we need it:
It would be helpful to understand in advance which feature gates are necessary for the ValidatingAdmissonPolicy.
Which issue(s) this PR fixes:

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

NONE

/cherry-pick website

/assign @trasc

repo: kubernetes-sigs/kueue


text:
feat: add Tiny button next to each feature for Documentation link

Implemented issue #25. Will open URL like https://minikube.sigs.k8s.io/docs/commands/XXX using the default browser.

ping @medyagh

hi @zitudu thank you for this contribution can we make the icon smaller and tiny and also change the grapgic to look like documentation?

The link button is now smaller and align bottom.

The external link symbol is widely used to open resource links, such as the minikube-gui documentation page also uses this symbol. Any suggestions, please?

ping @medyagh @spowelljr

Hi @medyagh I'm still waiting for your reply. Could you please tell me more information about this issue?

sorry @zitudu for the long wait, can we change the icon to something else? maybe "i" information icon ?

maybe "i" information icon ? and maybe it should be gray and only be Darker if you Hover over it it. and then it should tooltip "documentation"

Changes made according to the above description. Is this what we expected?

@zitudu thanks for the new update, looks better but the build failed, plz take a look

In file included from src/window.h:41:
In file included from src/basicview.h:23:
src/linkbutton.h:36:41: error: non-virtual member function marked 'override' hides virtual member function
    void enterEvent(QEnterEvent *event) override;
                                        ^
/Users/runner/work/minikube-gui/Qt/5.15.2/clang_64/lib/QtWidgets.framework/Headers/qwidget.h:631:18: note: hidden overloaded virtual function 'QWidget::enterEvent' declared here: type mismatch at 1st parameter ('QEvent *' vs 'QEnterEvent *')
    virtual void enterEvent(QEvent *event);
                 ^
1 error generated

@medyagh This is due to the different signatures of this method in qt5 and qt6. I added support for qt5 and built it successfully locally.

authors: medyagh zitudu

repo: kubernetes-sigs/minikube-gui


text:
Ingress not working post RBAC version install

Request for help: Yes
Version of Helm and Kubernetes:
Helm 2.9.1, Kubernetes 1.9.2 (Azure AKS)
Which chart:
Nginx-ingress
What happened:
Our previous installation of nginx-ingress (tag 0.13.0 in the values file) worked perfectly with Ingress inside Azure AKS, forwarding to our web application pod via a hostname. We upgraded to the latest chart and had to disable RBAC (as opposed to the default in the values.yml file) due to AKS not supporting it yet, so we installed it with RBAC turned off entirely.
What you expected to happen:
Ingress should continue to work as it did previously, with traffic routing correctly.
How to reproduce it (as minimally and precisely as possible):
We are simply trying to do basic host-name routing via nginx-ingress, we reproduce it in our system by there being a timeout and no logs in the nginx-controller pod to suggest it attempted to route traffic, we also get the following error logs which did not happen before:
I0516 09:21:02.507860       5 status.go:356] updating Ingress default/my-web status to [{ }]
I0516 09:21:02.508848       5 status.go:356] updating Ingress default/kube-lego-nginx status to [{ }]
I0516 09:21:02.516179       5 event.go:218] Event(v1.ObjectReference{Kind:"Ingress", Namespace:"default", Name:"vanquis-web", UID:"25f40927-58dc-11e8-ac5d-0a58ac1f0ce3", APIVersion:"extensions", ResourceVersion:"121858", FieldPath:""}): type: 'Normal' reason: 'UPDATE' Ingress default/my-web
W0516 09:21:02.516777       5 controller.go:700] error obtaining service endpoints: error getting service default/vanquis-web from the cache: service default/my-web was not found
I0516 09:21:02.567789       5 event.go:218] Event(v1.ObjectReference{Kind:"Ingress", Namespace:"default", Name:"kube-lego-nginx", UID:"9956f045-582c-11e8-a826-0a58ac1f0cdc", APIVersion:"extensions", ResourceVersion:"121859", FieldPath:""}): type: 'Normal' reason: 'UPDATE' Ingress default/kube-lego-nginx
Anything else we need to know:
It looks like ingress rules are never executed, so nginx never routes the traffic? We cannot even hit default backend either.
We have RBAC turned off and never used to see log entries suggesting that we couldn't obtain service endpoints until upgrading to the latest version.

Ingress RBAC was reactivated by default:
https://github.com/kubernetes/charts/commit/c60086ec0b260996281d337d67f2361f826f7029

authors: alexvicegrab omgsarge

repo: kubernetes/charts


text:
Allow resource-specific opt-in for Istio auto-inject

This PR allows configuring Istio initializer for resource-specific opt-in.
helm install --set initializer.enabled=true --set initializer.policy=disabled incubator/istio

@lachie83 PTAL

@frankbu LGTM. Thanks! Can you bump the chart version and get your CLA sorted and we'll get this merged.

@lachie83 Done and done.

/lgtm


text:
[occm] SG rules not removed with manage-security-groups and Octavia

Is this a BUG REPORT or FEATURE REQUEST?:
/kind bug
What happened:
(I only see that in the code, haven't reproduced it in practice yet)
Seems like with #1984 once you enable manage-security-groups with Octavia, the SG rules are never removed. This means that each edit of the Service's .spec.ports will create a new SG rule, while outdated ones will not be removed, potentially leading to unexpected traffic being open.
What you expected to happen:
The SG rules got to be fully reevaluated each time Service is changed.
How to reproduce it:
Create a Service when manage-security-groups is on. Modify the Service's .spec.ports changing a port number. Observe that new SG rule is created, but the one with old port number stays.
Anything else we need to know?:
Environment:

openstack-cloud-controller-manager(or other related binary) version: Current
OpenStack version: Any with Octavia

/remove-lifecycle stale

/remove-lifecycle stale
Still valid, I will work on this soon.

/remove-lifecycle stale

/assign

authors: dulek mdbooth shaardie

repo: kubernetes/cloud-provider-openstack


text:
Project architecture design document

This is architecture proposal for MVP version of the product. When MVP
is done it'll be revisited to verify whether it (still) works well.

@bgrant0607 @PeWu @mgr01 @gmarek @jwforres @lavalamp @jimmidyson @preillyme @emacias
CCing folks that expressed interest in this project and its architecture.

LGTM

:+1:

LGTM

cc @smarterclayton

Merging this, as this is the architecture we ended with.

authors: bgrant0607 bryk jimmidyson jwforres preillyme

repo: kubernetes/console


text:
Added new feature to handle test options.

The required-retest-contexts are used by several mungers. Previously, it was a global variable which would get referenced irrespective of the parameters supplied via the command-line.
We abstract the retest-context flag out as a feature that the mungers that want to can access them.
In future, if multiple mungers start to use any other test related parameters, they could be added into the test-options feature.

@apelisse @lavalamp PTAL

This is somewhat a nit. But please use an empty line after the first line of your commit message. It makes it much easier to read in the console.

looks OK to me. @eparis?

LGTM

authors: apelisse foxish lavalamp

repo: kubernetes/contrib


text:
Updates Ansible Vagrant Documentation

93aae647510d29426c0de8d1c6bec875941 updated the default
package_manager. This commit updates the Vagrant doc to support
this new default setting.
8417f092090067dbbf8096815d50edaf77bfea2f introduced a Vagrant doc
bug. This commit updates references to Core OS 7 and coreos7 being
the default Vagrant image to fix this bug.

cc @rutsky @stephenrlouie

@danehans, thanks for noticing this!
LGTM

authors: danehans rutsky


text:
helm get manifest only seems to work with DEPLOYED release

Using master.
When helm install/upgrade fails and release is marked as FAILED, doing
helm get manifest <release_name>
returns me:
[storage] 2017/05/31 16:28:14 Getting deployed release from "<release_name>" history
Error: release: "<release_name>" not found

I had hoped it will store failed manifests as well but doesn't seem like it.

I'm looking into this. As a workaround, you can use helm get manifest --revision $REVISION_ID $RELEASE_NAME, where $REVISION_ID is the revision from helm history $RELEASE_NAME

authors: kiich technosophos

repo: kubernetes/helm


text:
When helm deletes something, maybe pass --include-initialized

Hard to summarize this one.
I happened to install a release into an environment with Istio's automatic injection in play.
My chart ideally would not be Istio-aware.
Anyway, something about Istio caused my installation to fail.  Specifically, a Job created as a Helm hook could not be created.  Helm dutifully failed the install.
I did helm delete --purge my-release to clean up.
I checked to see that this worked by running commands like kubectl get -a jobs, which reported no resources found.  So it looked like everything cleaned up.  But then on a whim I tried kubectl get -a job name-of-helm-hook-job, and that returned a status that showed my failed job.  So helm delete --purge did not clean everything up.
Many, many, many discussions later, I found that to find this job I have to do kubectl get --include-uninitialized -a jobs.  Similarly, I would expect that whatever delete operation Helm performs under the covers should do the equivalent of, for example, kubectl delete --include-uninitialized some-resource-name.
I don't know how this all interacts with the fact that initializers are in alpha status but figured I'd file the issue here and let others smarter than I figure out the ramifications.  :-)

Hmm, sounds a lot like https://github.com/kubernetes/helm/issues/3017. Essentially objects that are related to the installation to the chart but weren't directly tied to the release (in this case, a Job kicked off by a hook) aren't being cleaned up on helm delete.
Perhaps we can inject some labels into all objects "installed" by helm, which then we can just use those label selectors to perform an uninstall, falling back to the old behaviour if those labels are not found. A "mark and sweep", if you will.
How does that sound?

authors: bacongobbler ljnelson


text:
Optionally search for and merge config files from a directory

What would you like to be added: Kubectl should optionally search for and merge config files from a directory (~/.kube/configs/ ?)
Why is this needed: Perhaps my ignorance is showing, but I find managing multiple configs a hassle. I'm aware of the $KUBECONFIG env variable, but that doesn't seem sufficient to me. Having to make configuration changes to my shell scripts just to persist the clusters that I'm working on for the day or week is clunky.
Rather, if kubectl searched through ~/.kube/configs/ and used any valid config in that directory as part of its merge process, I wouldn't need to customize any variables and could add and remove clusters from all of my tools and terminals very easily.

Good request. We're tracking this over at #569. There are a few suggestions in that thread that might hold you over in the meantime.
/triage duplicate
/close

authors: eddiezane tedtramonte

repo: kubernetes/kubectl


text:
vSphere: Add error exit in configure script to prevent silent failure

Now if any commands in the configure script fail, the install hangs since the script doesn't return any error:
https://github.com/kubernetes/kubernetes-anywhere/issues/299
This PR adds error exit handling in configure script for vSphere provider in order to prevent silent failures.

@abrarshivani @kerneltime

@abrarshivani @kerneltime
All the comments are addressed. Please review again thanks :)

repo: kubernetes/kubernetes-anywhere


text:
docs/getting-started-guides/cloudstack
docs/getting-started-guides/docker
docs/getting-started-guides/docker-multinode/deployDNS
docs/getting-started-guides/docker-multinode/testing
docs/getting-started-guides/mesos
docs/user-guide/compute-resources
docs/user-guide/connecting-to-applications-port-forward
docs/user-guide/deploying-applications
docs/user-guide/kubectl/kubectl_get
docs/user-guide/production-pods
docs/user-guide/walkthrough/k8s201
docs/user-guide/walkthrough/README
All appear to have liquid force like tags, aka: {{ which likely require a {% raw %}
@johndmulhausen added:
$25 bounty for anyone who submits a PR that ads {% raw %}{% endraw %} in the codeblocks that have liquid-esque tags inside them, so that the text won't be hidden on the site.
Please reference issue #81 in your PR

Hate hidden text I suppose I'll do some commits for the non-generated stuff.  I presume that's docs/* where there is no .files_generated file in the directory....

@mikebrow thanks so much! And guess what? This issue was tagged with a $25 bounty, so I'll be sending a coupon code for free Google Cloud Platform hosting time. Thanks for your efforts!

I am continuing on this issue.  These looks complete:
docs/getting-started-guides/cloudstack
docs/getting-started-guides/docker
docs/getting-started-guides/docker-multinode/deployDNS
docs/getting-started-guides/docker-multinode/testing
docs/getting-started-guides/mesos
docs/user-guide/compute-resources
docs/user-guide/connecting-to-applications-port-forward
docs/user-guide/deploying-applications
Starting with
docs/user-guide/kubectl/kubectl_get
docs/user-guide/production-pods
docs/user-guide/walkthrough/k8s201
docs/user-guide/walkthrough/README

as far as I can tell these have all been completed.  The final file docs/user-guide/walkthrough/README appears to have been deprecated.

Thanks for the final fixes, m8ryx!

authors: eparis johndmulhausen m8ryx mikebrow


text:
update kubernetes.md

Deployed in 16.04/16.10 ubuntu-server LXC template (PROXMOX)
after installing everything docker version is different depending on if you use:
apt install docker-engine
or
apt install docker.io
Different docker version will break kube-proxy after initial deployment with needed tweaks for use of Canal (cidr-range), and --skip-preflight-checks also added to init.
Without kube-proxy cluster becomes unusable after deployment, also nodes can't join.
when deployed in LXC with arguments:
lxc.aa_profile: unconfined
lxc.cgroup.devices.allow: a
lxc.cap.drop:
lxc.cgroup.devices.deny:
lxc.mount.auto: proc:rw sys:ro cgroup:ro
lxc.kmsg: 0
lxc.autodev: 1

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
For 1.7 Features: set Milestone to 1.7 and Base Branch to release-1.7
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
NOTE: Please check the “Allow edits from maintainers” box below to allow
reviewers fix problems on your patch and speed up the review process.
Please delete this note before submitting the pull request.

This change is

already signed the CLA

@gattytto Can you resolve the conflict when you get a chance. Thx

how?

@gattytto Looks like that file was moved and renamed to: /docs/setup/independent/install-kubeadm.md. You should apply the changes there. Let me know if you need any help. Cheers

I think this is not what we want. We specifically want users to use the docker package that we vet and test against.

authors: chenopis gattytto mikedanese


text:
Reverting state at release-1.13 branch

Once again (after adding #952 fix)

Revert the state to the same commit as 1.15
Revert {load,density}/config.yaml to cd2363 (around when v1.14.0 was added to k/k)

ref #797
/cc oxddr

/cc mm4tt

/approve
/lgtm

repo: kubernetes/perf-tests


text:
metrics-scraper :Unable to initialize database tables

This is a Bug Report

Problem:
container image for kubernetes-metrics-scraper will error :
{"level":"fatal","msg":"Unable to initialize database tables: Binary was compiled with 'CGO_ENABLED=0', go-sqlite3 requires cgo to work. This is a stub","time":"2019-08-30T07:55:11Z"}
Proposed Solution:
Build container image with CGO_ENABLED=1. Will require cross compile gcc
Page to Update:
https://kubernetes.io/...

GitVersion:"v1.15.0", GitCommit:"e8462b5b5dc2584fdcd18e6bcfe9f1e4d970a529", GitTreeState:"clean", BuildDate:"2019-06-19T16:32:14Z", GoVersion:"go1.12.5", Compiler:"gc", Platform:"linux/s390x"

Image:          kubernetesui/metrics-scraper:v1.0.0
Image ID:       docker-pullable://kubernetesui/metrics-scraper@sha256:d62574b33b50e1af00ce5e6ec4301491ae97288f7b7167a46a49ee480a8250a4

Hi @diederichm -
This issue sounds more like a request for support and less
like an issue specifically for docs. I encourage you to bring
your question to the #kubernetes-users channel in
Kubernetes slack. You can also search
resources like
Stack Overflow
for answers to similar questions.
You can also open issues for Kubernetes functionality in
https://github.com/kubernetes/kubernetes  or the the kubernetes-metrics-scaper in https://github.com/kubernetes/dashboard/issues.
If this is a documentation issue, please re-open this issue.
/close

authors: aimeeu diederichm

repo: kubernetes/website


text:
rename master-node-communication in control-plane-node-communication

This is a Bug Report

Problem:
master-node-communication.md file has been changed to control-plane-node-communication in en/ directory.
Proposed Solution:
Change the filename as control-plane-node-communication.md
Page to Update:
https://kubernetes.io/ko/docs/concepts/architecture/master-node-communication/

/language ko

/assign


text:
Issue with k8s.io/de/docs/tasks/administer-cluster/

The site is completely empty ;)

/kind bug
/language de

/priority backlog

/assign

authors: KilimAnnejaro sftim valentinlehmann


text:
Update horizontal-pod-autoscale-walkthrough.md

As per the error described in https://github.com/LevelUpEducation/kubernetes-demo/issues/31, guidance was to add the generator explicitly:
kubectl run --generator=run-pod/v1 -i --tty load-generator --image=busybox /bin/sh
But I prefer the example from the run docs https://jamesdefabia.github.io/docs/user-guide/kubectl/kubectl_run/:
kubectl run -i --tty busybox --image=busybox --restart=Never

"I signed it

/retest

/assign @kbarnard10

@matt-sm any thoughts on @sftim 's feedback? We'd love to get this merged!

I have updated with @sftim's suggestions

Docs looks good
/lgtm
/approve

authors: irvifa matt-sm zparnold


text:
[zh] translate content/zh/docs/reference/scheduling/config.md

Problem:
https://kubernetes.io/zh/docs/reference/scheduling/  is missing in Chinese version.
See  more: https://kubernetes.io/zh/docs/reference/scheduling/
Proposed Solution:
Add /docs/tasks/configmap-secret/ to zh version with three articles to be translated.

[x] /zh/docs/reference/scheduling/config.md

Page to Update:
https://kubernetes.io/zh/docs/reference/scheduling/config
Additional Information:
this PR fix https://github.com/kubernetes/website/issues/24018, this should be merged after https://github.com/kubernetes/website/pull/24045 get merged.

/assign @tengqm @tanjunchen
Please take a look at this PR  as well as https://github.com/kubernetes/website/pull/24045

/lgtm
/approve

authors: howieyuen tengqm


text:
Update contribute/generate-ref-docs/quickstart.md

Update content/en/docs/contribute/generate-ref-docs/quickstart.md

Add a line export GO111MODULE=auto
(since if GO111MODULE=on, the ./update-imported-docs.py will fail.)
Related issue: https://github.com/kubernetes-sigs/reference-docs/issues/217

~Update imported docs~
~(How-to: https://kubernetes.io/docs/contribute/generate-ref-docs/quickstart/)~

~FYI: Imported docs are quite outdated.~
~For example: website/content/en/docs/reference/setup-tools/kubeadm/generated/ last updated on 4 Dec 2020~

~Somehow related with the PR #26979~

Hi @jihoon-seo .
Would you include only the change to the script in this PR?
Are you planning to build the reference documentation as part of the 1.21 release?

Holding for review
/hold

Hi @kbhawkey . Thank you for your comment.

I ran the script with providing K8s version as 1.20 to build the reference documentation from the source codes of K8s release 1.20.

Like this: ./update-imported-docs.py reference.yml 1.20
(FYI: Providing K8s version as 1.20.5 instead of 1.20 gives the same result)

If this PR is merged to kubernetes/website:master,
the reference documentation changes will affect the pages in https://kubernetes.io,
which is serving the docs for K8s v1.20 now.

I am not sure whether I should continue to include only the change to the script in this PR or not.
Please let me know.
Thanks!

👋 @jihoon-seo .
Are you building the reference docs for 1.21? The reference docs do not need to be rebuilt for 1.20?
Is there a release candidate available for v1.21?

Hi @kbhawkey . Thank you for your comment again.

Are you building the reference docs for 1.21?

=> No, I was not building the reference docs for 1.21.
I was building the reference docs for 1.20.

Is there a release candidate available for v1.21?

=> AFAIK, there isn't.

The reference docs do not need to be rebuilt for 1.20

=> Okay I got it.
I modified this PR to include only the change to the contribute/generate-ref-docs/quickstart.md.
Please take a look.
Thanks!

👋 @jihoon-seo .
I plan to close this pull request. At this point, the Quick Start page does not reflect the current reference docs generation.
I suggest to fully update the page or possibly log an issue.
Feel free to reopen this PR.
/close

authors: jihoon-seo kbhawkey


text:
Updating --cascade=false to --cascade=orphan

Cascade=false is deprecated in kubectl 1.21, according to Bug https://github.com/kubernetes/website/issues/27920

I have already sign up for the CLA.

/check-cla

/check-cla

Any trouble getting the CLA signed? Can we help?
/check-cla

Any trouble getting the CLA signed? Can we help?
/check-cla

Hi Tim! I have checked the CNCF website again and I thought it was just to sign up, I had not signed the CLA. I have done it now so hopefully this time it will work :smile:
/check-cla

authors: froblesmartin sftim


text:
Update README.md

I have suggested few changes in README.md.
Kindly review.

Signed the CLA ........

/check-cla

Hi @ss1208 , please sign the CLA for this PR to be reviewed.
A PR wrangler may close this PR within 7 days if the CLA has not been signed. You can re-open the PR when the CLA has been signed

Hi @ss1208 , since there has been no action to sign the CLA, I am closing this PR
Feel free to re-open the PR when you have signed the CLA
/close


text:
[zh] Update volume-pvc-datasource.md

Signed-off-by: Guangwen Feng fenggw-fnst@cn.fujitsu.com
en PR https://github.com/kubernetes/website/pull/30517/files#diff-647141ed78f8a5ca7d9432e1485180c011ba3c5e0365f71c30f36f5420447c5d
/assign @tengqm
PTAL, thanks.

Thanks.
/lgtm
/approve

authors: fenggw-fnst tengqm


text:
Promote SuspendJob to GA

xref: kubernetes/kubernetes#108129

/lgtm

@tengqm planning to close this?

@tengqm planning to close this?

Either one can be closed. My PR contains some format tweaks, in addition to the main topic.

Code PR in https://github.com/kubernetes/kubernetes/pull/108129 is merged
/approve

authors: mehabhalodiya reylejano tengqm


text:
WIP: introduce NodeInclusionPolicy in PodTopologySpread

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

part of https://github.com/kubernetes/enhancements/issues/3094#issuecomment-1082526739

/assing
/hold for exception, this KEP has been removed from the milestone
/sig-scheduling

close as Exception is rejected. I'll create a new one to release v1.25 then.

/milestone clear

authors: PI-Victor kerthcet mehabhalodiya