text:
Request to add 4-bit AdamW

Paper or Code
Paper: Memory Efficient Optimizers with 4-bit States
Code : https://github.com/thu-ml/low-bit-optimizers/blob/main/lpmm/optim/optimizer.py

thanks for the request! it requires cuda files to compile like bitsandbytes optimizer, so it's complicated to move entire implementations into this project, instead, maybe we can support the optimizer like this example, that manually install or compile, and use it through pytorch-optimizer.
I'll figure it out how to smoothly support this in pytorch-optimizer :)
thank you!

Liked the idea of supporting it like the example.
Maybe even easier, make the FR to bnb and include it here?

Liked the idea of supporting it like the example.
Maybe even easier, make the FR to bnb and include it here?
Made the FR to TimDettmers/bitsandbytes#775

that's a great idea! it'd be much better that bnb supports 4-bit optimizers

@LiutongZhou hi! I came across that torchao library supports 8/4bit, fp8 optimizers. still, they are pure Python implementations rather than custom CUDA kernels, I think using that library would be better than lpmm in terms of active maintenance, usability, and popularity.
if there's a better choice, I'll consider changing to another option later!

authors: LiutongZhou kozistr


text:
Feature request. Readings in MWh

Just an idea.
I am a big fan of your integration and use it for both heat and water. A great help in the quest to save energy - for the good of our spendings and our Planet.
Now time has come to get an overview of this years consumption. On the bill and on the eForsyning website the energy consumption is calculated in MWh, whereas the sensors created by your integration is in kWh.
Of course it is fairly easy to make a template toi change the values, but would it be an idea that the user could choose between getting the numbers in MWh or kwh?
And the data received from the API is in MWh as far as I can see
Wish you a Merry Christmas
Lars B

Yes, data is coming in as MWh.  Once HA only worked in kWh, so I changed it to this to be compatible.  Also for me personally kWh makes more sense as my house uses <50 kWh per day which makes all those decimals just a hassle.
Displaying totals in MWh though could be something.

In release v1.1.3 I made an update to the sensors with a "suggested unit of measurement" in MWh for all sensors except daily difference.  I just cannot figure out how that is used inside HA.  Numbers from the API driver is still reported in kWh as a common unit, but that should not hinder HA in converting it to MWh.

Tried ver 1.1.3. Cannot find the "suggested unit of measurement" in the log.  Is it an attribute to the sensors?

Hmm, I need to double check as I don't recall seeing any warning on my test instance.
I am on the latest HA version which has this property for sensors:
https://github.com/kpoppel/homeassistant-eforsyning/blob/aad3ff54d409ebf546840fa28e085452f64400fb/custom_components/eforsyning/const.py#L113

My latest data is from yesterday and I installed the new version yesterday. If data was fetched before the update, it might be the reason that I cannot see 'suggested_unit....'
Lets see tomorrow

Tried again today. No success. There are no "suggested_unit...." in my sensors.
But doesn't really matter. As I can understand this feature needs a lot of work from you. It is rather easy to make templates that change the unit from kWh to MWh. So it is not worth it.
But thank you anyway

I get a little wiser every time I work on this integration, and at the same time Home Assistant is largely a moving target so every time something new appears.
Let's keep the issue open and I will keep it in mind whenever I make updates.

Good news!  Unit conversion is rolled out in the UI little by little, so template sensors for unit conversion should become a thing of the past.  On 2022.12.8 or later for instance, it is already there on the water and temperature sensor types:

So this issue will solve itself.  2023.1 does not have it yet, let's see if 2023.2 does for energy sensors.

You were right. Using beta 2023.2 and now it is possible to change unit fra kWh to kWh - and a lot of other things
Closing
Thanks

source: gharchive/issue

repo: kpoppel/homeassistant-eforsyning

license_type: permissive

license_source: github-api


text:
Drawer inadvertently intercepts events.

React doesn't actually add event handlers directly to the target nodes. Instead it adds all listeners on the document element.
Manually adding listeners here intercepts any listeners on child elements e.g.:
<Drawer>
    <DrawerContent>
         console.log('Never called')}>Broken Link
    </DrawerContent>
</Drawer

React automatically handles correct bubbling of events from child to parent to grandparent so it is safe to use standard props mechanism.

I've been playing with this library and testing different components as you've added them and like it so far and pretty excited to use it.
There was just this bug which got me tearing my hair out, going round in circles and diving deep into the react codebase to find out exactly how it handles events.
Hope this helps. If you any more help with testing other PRs etc. I'm happy to pitch in.

I really appreciate your opinion, thank you for your analysis. I've reread the React recommendations and found out that using of addEventListener is not advised.
I've changed commit message for changelog and merge everything to master

source: gharchive/pull-request

license: mit

license_source: bigquery


text:
cannot find rcrt1.o

I'm attempting to build tini from source during a YOCTO build. I'm getting this error:
/home/richquackenbush/boondocks-build/tmp/work/cortexa7hf-neon-vfpv4-poky-linux-gnueabi/tini/0.14.0-r0/recipe-sysroot-native/usr/bin/arm-poky-linux-gnueabi/../../libexec/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/7.3.0/ld: cannot find rcrt1.o: No such file or directory

Is there an obvious dependency I'm missing?

Can you provide more detail regarding how you're building Tini here? With what you provided, there isn't much to go on unfortunately.

My guess here is that you're trying to do a static build, which probably doesn't play very well in an environment like Yocto that already manages a lot of the build environment.

Ahh - this does appear to be a YOCTO related issue. I'm able to build tini fine outside of that environment. Thanks for the clue!

:+1:

authors: krallin rquackenbush

repo: krallin/tini


text:
Minor changes to make compatible with Keras 2.3.1

I updated the line "lr *= ..." to "lr.assign(lr * ...)".
I replaced K.get_variable_shape with K.int_shape in a number of places.
These changes allow the file to be used with Keras 2.3+

Thanks for the fixes @henry-eigen. They work fine when using SGDWithWeightnorm but I still get some errors when running the example with AdamWithWeightnorm.

Whoops, I didn't test that initially. I recommitted, and it should work now.

Great, thanks for your contribution!

authors: henry-eigen krasserm

repo: krasserm/weightnorm

license: MIT


text:
Fix undefined method `rich_file'

Fix undefined method `rich_file' for Rich::RichFile using Paperclip.
Minimal version of pull request #145. Was enough for me to fix the problem.

Full and up-to-date version of this pull request is #203.

repo: kreativgebiet/rich


text:
Improve release process

Currently the release process has a few small hickups:

Use https://github.com/caarlos0/svu for proper and clean parsing/creation of semver tags
Improve process by automatically bumping version inside https://github.com/kreuzwerker/m1-terraform-provider-helper/blob/main/cmd/version.go

Implemented with https://github.com/kreuzwerker/m1-terraform-provider-helper/commit/e68c0f69a670bec438099f72998eca46a5948436


text:
Update package.json: deploy moved from bash to node

I'd also like to take this opportunity to say that this is the best starter project in the world and you are the best human for open sourcing it!

Thanks, Charilie! Much appreciate it. Feel free to get in touch if you bump into any issues or have a feature suggestion (Skype: koistya).

authors: cmmartin koistya

repo: kriasoft/nodejs-api-starter


text:
Middlware approach context.next and redirection

I'm submitting a ...
bug?

[x ] bug report
[x] feature request
[ ] other (Please do not submit support requests here (below))

Notes:

Please do not use the issue tracker for personal support requests (use
Gitter,
HackHands or
Codementor).

Please do not derail or troll issues. Keep the discussion on topic and
respect the opinions of others.

Please do not open issues or pull requests regarding the code in
path-to-regexp
(open them in their respective repositories).

Bug reports
A bug is a demonstrable problem that is caused by the code in the repository.
Good bug reports are extremely helpful - thank you!
Guidelines for bug reports:

Use the GitHub issue search — check if the issue has already been
reported.

DONE

Check if the issue has been fixed — try to reproduce it using the
latest master or development branch in the repository.

Isolate the problem — ideally create a reduced test
case and a live example.

A good bug report shouldn't leave others needing to chase you up for more
information. Please try to be as detailed as possible in your report. What is
your environment? What steps will reproduce the issue? What browser(s) and OS
experience the problem? What would you expect to be the outcome? All these
details will help people to fix any potential bugs.
Example:

Short and descriptive example bug report title
A summary of the issue and the browser/OS environment in which it occurs. If
suitable, include the steps required to reproduce the bug.

I include the example: https://stackblitz.com/edit/demo-universal-router-react
I use your middleware approach with "context.next" to build the routes. In this manner, I can't redirect. To see this: select the "routeNext" in the "renderRoute" method, and choose "mode:A" for redirection, and anything else if not. This fails.
I included the "good" example of redirection without "next". For this, choose "route" in the renderRoute, and you can play with the "mode:A" for redirecting or not.
Not sure of what the parser does with the condition  "if (true) return {redirect: "/"}". It seems to only append the key "redirect"  but does not replace them all. The error message you get is: "Objects are not valid as a React child (found: object with keys {redirect})"

This is the first step
This is the second step
Further steps, etc.

<url> - a link to the reduced test case
Any other information you want to share that is relevant to the issue being
reported. This might include the lines of code that you have identified as
causing the bug, and potential solutions (and your opinions on their
merits).

Feature requests
Feature requests are welcome. But take a moment to find out whether your idea
fits with the scope and aims of the project. It's up to you to make a strong
case to convince the project's developers of the merits of this feature. Please
provide as much detail and context as possible.

You are seeng the errors because you are actually trying to render <NavNext>{{ redirect: "" }}</NavNext> which is not allowed in React.js.
The "next" function of a middleware action gets a child route result as is:
- const component = await next(true);
+ const component = { redirect: "" };

We have some docs about redirects here: https://github.com/kriasoft/universal-router/blob/master/docs/redirects.md

Ah thks, yes stupid! I did not look at what component looked like...Sorry.const component = await next(true); if (component.redirect) { return component; } return component && {component}; },
works because I add condition in router.resolve. Thks for the help.    Le samedi 19 décembre 2020 à 22:13:03 UTC+1, Vladimir Kutepov notifications@github.com a écrit :
You are seeng the errors because you are actually trying to render {{ redirect: "" }} which is not allowed in React.js.
The "next" function of a middleware action gets a child route result as is:

const component = await next(true);

const component = { redirect: "" };
We have some docs about redirects here: https://github.com/kriasoft/universal-router/blob/master/docs/redirects.md

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or unsubscribe.

authors: frenzzy ndrean

repo: kriasoft/universal-router


text:
Add issue template

Can we please add an issue template to the repository?
I want it to be as short as possible! The only things I can think of to add (at this point) would be the following
Use issues for anything. They can be for features, questions, ideas, or just to say hi.
We will close issues we think no longer require work, and we might change issue titles or descriptions to help other users find what they need. We love you, and think your issue title is great, but we sometimes know what the underlying bug is, and can relabel it accordingly.

If you submit a bug, include any information you think is relevant to recreate, or analyze.

**But most importantly... share your version (git commit sha) in your issue!**

Closing because of #230 and #232

repo: kris-nova/kubicorn


text:
[FEATURE]: Integrate Dependabot for Automated Dependency Updates

Description
Keeping the project's dependencies up to date can be a challenging task, especially when done manually. To streamline and automate this process, we propose integrating Dependabot.
Use Case
We need to add Dependabot to our project as it will significantly aid in keeping our dependencies current. Once activated, Dependabot will automatically submit pull requests (PRs) whenever there are outdated dependencies identified in our package.json file.
This automated approach will enhance our project's stability, security, and overall maintenance by ensuring that we are always using the latest and most secure versions of our dependencies.
Proposed Solution
No response
Additional Information
Checklist

[X] I am willing to work on this issue
[X] I am a GSSoC'24 contributor

Attachments
No response

Good thought @harmeetsingh11

This automated approach will enhance our project's stability, security, and overall maintenance by ensuring that we are always using the latest and most secure versions of our dependencies.

But we don't require, because there are high chances things break if there is a breaking changes, so i am fine having 2yrs old dependency if it just working fine.
Feel free to pick up any other issues

repo: krishnaacharyaa/wanderlust


text:
Largest Sum Contiguous Subarray in Java

Largest Sum Contiguous Subarray in Java
Assigned Issue Number?
#119
Language Opted?
Java
Number of files added or updated?
1
Name of these files?
Data_Structures => Array => Largest_Sum_Contiguous_Subarray => Largest Sum Contiguous Subarray.java
Checklist

[x] I was assigned for this otherwise my PR will be rejected.
[x] I've read the contribution guidelines.
[x] I've referred the correct issue number.
[x] I've filled up this entire template correctly.

:star2: this repository and support.

Have to resolve an issue

Have to resolve an issue

@sanskriti0512 👍🏼


text:
update from upstream

chore(deps): update returntocorp/semgrep docker tag to v1.61.1
chore(deps): update dorny/paths-filter action to v3.0.1
chore(deps): update github/codeql-action action to v3.24.2
chore(deps): update github/codeql-action action to v3.24.3
chore(deps): update rust:1.76.0 docker digest to a71cd88
chore: explicitely set prettierrc's path
chore(deps): lock file maintenance
chore(deps): update returntocorp/semgrep docker tag to v1.62.0
chore(deps): update rui314/setup-mold digest to 910273f
chore(deps): update github/codeql-action action to v3.24.5
chore(deps): lock file maintenance
chore(deps): update actions/download-artifact action to v4.1.3
chore(deps): update docker/setup-buildx-action action to v3.1.0
chore(deps): update enricomi/publish-unit-test-result-action action to v2.15.0
chore(deps): update returntocorp/semgrep docker tag to v1.63.0
chore: align title
chore(deps): update enricomi/publish-unit-test-result-action action to v2.15.1
chore(deps): update npm to >=10.5.0
chore(deps): update github/codeql-action action to v3.24.6
chore(deps): update actions/cache action to v4.0.1
chore(deps): update rui314/setup-mold digest to c9803d2
chore(deps): update actions/download-artifact action to v4.1.4
chore(deps): update dorny/paths-filter action to v3.0.2
chore(deps): lock file maintenance
chore(deps): update mcr.microsoft.com/devcontainers/rust:1-1-bullseye docker digest to 77b7c17
chore(deps): lock file maintenance
chore(deps): update returntocorp/semgrep docker tag to v1.64.0
chore(deps): update docker/build-push-action action to v5.2.0
chore(deps): update rui314/setup-mold digest to 65ebd6e
chore(deps): lock file maintenance
chore(deps): update returntocorp/semgrep docker tag to v1.65.0
chore(deps): update rust:1.76.0 docker digest to 969ca54
chore(deps): update actions/checkout action to v4.1.2
chore(deps): update rust:1.76.0 docker digest to 2d1630a
chore(deps): update github/codeql-action action to v3.24.7
chore(deps): update rust:1.76.0 docker digest to af1e799
chore(deps): update rust:1.76.0 docker digest to d36f9d8
chore(deps): update docker/login-action action to v3.1.0
chore(deps): update docker/build-push-action action to v5.3.0
chore(deps): update docker/setup-buildx-action action to v3.2.0
fix(deps): update rust crate color-eyre to 0.6.3
chore(deps): update dependency @semantic-release/github to v10
chore(deps): update dependency semantic-release to v23.0.3
chore(deps): update dependency semantic-release to v23.0.4
chore(deps): lock file maintenance
chore(deps): update dependency @semantic-release/commit-analyzer to v12
chore(deps): update dependency semantic-release to v23.0.5
chore(deps): update github/codeql-action action to v3.24.8
chore(deps): update actions/cache action to v4.0.2
chore(deps): update returntocorp/semgrep docker tag to v1.66.0
chore(deps): update enricomi/publish-unit-test-result-action action to v2.16.0
fix: don't set shell, not needed in semgrep container
fix: separate scan and fixup, as the scan container doesn't have bash / jq anymore
fix: only upload sarif file itself
fix: set unpack folder, not filepath
chore: checkout to satisfy the codeql tool
chore(deps): update enricomi/publish-unit-test-result-action action to v2.16.1
chore(deps): update rust to v1.77.0
chore(deps): update github/codeql-action action to v3.24.9
chore: rename semgrep job to make it register with semgrep
chore: use semgrep action, not container
chore(deps): update returntocorp/semgrep-action digest to 713efdd
chore: back to container, the action is outdated
chore: add category
chore: semgrep 1 job
chore: fix filename

Pull Request Test Coverage Report for Build 8396101497
Details

0 of 0   changed or added relevant lines in 0 files are covered.
27 unchanged lines in 9 files lost coverage.
Overall coverage decreased (-2.3%) to 43.317%

Files with Coverage Reduction
New Missed Lines
%

src/listener.rs
1
0.0%

src/main.rs
1
0.0%

src/sender.rs
1
0.0%

src/config.rs
2
68.75%

src/traits/display_as_debug.rs
2
96.49%

tests/integration_tests.rs
2
83.33%

src/line.rs
3
84.62%

src/client_queue.rs
4
0.0%

src/cli.rs
11
94.35%

Totals

Change from base Build 8391391420:
-2.3%

Covered Lines:
431

Relevant Lines:
995

💛  - Coveralls

:tada: This PR is included in version 1.1.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:

authors: coveralls kristof-mattei

repo: kristof-mattei/endless-ssh-rs


text:
Added supported_features (required in HA from 0.59)

Backporting changes added in 0.59.

+1 tested the changes when it was still a pull request and all UI elements worked as expected

Thanks to both of you!

authors: Boltgolt costastf mlowijs

repo: krocat/ToonHA


text:
Logos repository

Are the logo's referenced in the LogoUrl, e.g. https://i.imgur.com/RoM9XUq.png, stored in a repository somewhere? If not, can they be stored in a repository so I can place them on my own static server? I'd rather not use an external url and I'd like to have the opportunity to inspect these files.

The logos are currently stored in GitHub CDN. Because the library avoids referencing the disk at all costs, if you want to serve them from your static server, you will have to download them all with a webpage-downloader, or save the page with your browser to your hard disk and rewrite the urls to serve from your static path programmatically. Serving the logos is actually beyond the scope of the library itself.

Does that answer your question? Above is an example of how you can save all logos to your disk  with Chrome, easily.

Can you not place them in the gh-pages branch, e.g. https://github.com/kroitor/ccxt/tree/gh-pages, so we can checkout the files that way and you can still serve them using github cdn.

I'm not placing them in a branch, actually. They're in GitHub CDN, independent of the repository.

Above is an example of how you can save all logos to your disk with Chrome, easily.

Instead of having to download them myself manually one by one, why not have them in a repository so I can run a virus-scanner on it etc.

You don't have to download them manually one by one, you just download the whole GitHub page with Chrome to your disk in one click basically. Have you tried saving a webpage in Chrome before?

Have you tried saving a webpage in Chrome before?

hehe, check my github profile if you have any doubts about that ;)
It's just that I'm using an opensource API here and I'd like to have control over all aspects including the images, for all I know the image file can be malicious. Or am I weird for thinking that? ;)

All you have to do is to navigate to https://github.com/kroitor/ccxt with chrome or any other browser, click the page with your right mouse button or in file menu select 'save as' or 'save page as' and choose a destination on your disk, and voila, it will download and save all logos there. Then you can check them all with your antivirus software in one go.

If those images are malicious, I would crack your browser, because your Chrome did download them to show them to you when you opened the library page on GitHub. So, if you're afraid of being cracked by a jpeg on the internet – (if that is possible at all) - you were hacked already by simply visiting the page, that contains those JPEGs.

If I'm going to download them perhaps an option to specify the base url for the logoUrl would be useful, e.g. http://localhost/vGwurP0.png instead of https://i.imgur.com/vGwurP0.png.

You can rewrite the base url for the logos with a very basic regexp. Is that a problem?

No I guess not. Thanks for your feedback.

Ok, I'm sorry for not being very helpful here, but the task of optimizing the logo delivery is indeed beyond the purpose of the library itself.

let logo = market.logo
let path = logo.split ('/')
let filename = path[path.length - 1]
let your_static_url = 'https://YOUR_BASE_PATH/path/to/' + filename

# Python
logo = market.logo
path = logo.split ('/')
filename = path[len (path) - 1];
your_static_url = 'https://YOUR_BASE_PATH/path/to' + filename

authors: kroitor thijstriemstra

repo: kroitor/ccxt


text:
please create a nuget package from this

title says it all

I've made a node. Will get to it soon.

Hi. Thanks for a great project. Any progress on this issue?

Hi. Thanks for a great project. Any progress on this issue?
Hey @yngvesl
Someone else is already using a Nuget package with the ID "SMART.Net" for another unrelated project.
I'm looking into renaming the project and publishing a NuGet package.

@penCsharpener , @yngvesl
Latest Nuget available here -> https://www.nuget.org/packages/Krugertech.IO.Smart
Note that

The namespace has been updated from Simplified.IO to Krugertech.IO.
Usage changed from Smart.GetDrives() to SmartDrive.GetDrives()

can anybody please help me to get the Nuget packet installed in VB NET (framework 2.0)?
i get error:

@Matzeeee Hi There. The minimum supported .NET Framework version is 4.7.2.
You will need to upgrade your Framework version in order to use it.

for me it works with .NET 4.7.2

authors: Matzeeee krugertech penCsharpener yngvesl


text:
Rejecting the Promise when API calls return an error.

fixes #6

Is this getting merged ?

Is this tested? Can I pull?

Sry for the long wait guys, I reviewed and will merge asap if possible.

done!

authors: johnthillaye krystianity nicolasgarnier tuloski

repo: krystianity/node-bitstamp


text:
[823] Optional / Closure recognition

I think this should fix #823

mind taking a look whether the logic makes sense @sunshinejr ?

repo: krzysztofzablocki/Sourcery


text:
bug: bad duration displayed when inactive

It display bad duration when service goes from UP to INACTIVE.

Duration displayed seems to equals to UP duration + INACTIVE duration (instead of INACTIVE duration only)

changed_at update is missing in inactive handler.

repo: kslimani/heartbeat


text:
Can't get crash log when SWIFT_OBJC_INTEROP_MODE set to objcxx

Xcode15 can mix swift and c++, change project SWIFT_OBJC_INTEROP_MODE from objc to objcxx, then KSCrash can't catch the crashes, Is there any idea to fix it?
For Xcode15:
https://developer.apple.com/videos/play/wwdc2023/10172/

Hello!
Currently, Swift/C++ interoperability, especially in the way KSCrash interacts with these settings, hasn't been fully explored or supported.
You might want to try an experimental feature in KSCrash that enables catching C++ exceptions in dynamic libraries. Specifically, the function enableSwapOfCxaThrow might help.

repo: kstenerud/KSCrash


text:
Implement stats API, closes #26

See #26

Please make sure all response structure fields are public. Otherwise it looks good to me.

Cherry picked Vinatorul@a87c5984672f4e06ce7bd0543a7b15b45138540b as 67d23193a77b5e167b438cedbbded7b772067749.

TODO:

[ ] use chrono::NaiveDate in Get request (date_from and date_to fields)
[ ] use chrono::NaiveDate in Period response type (day field)
[ ] reuse DemoSex and DemoAgeRange in DemoSexAgeRange type

authors: Vinatorul kstep

repo: kstep/vkrs


text:
demo 直接闪退

11-15 12:43:15.897 1348-2628/? E/JobSchedulerService: jobid:20536
java.lang.IllegalStateException: Same jobid in systemuid.
at com.android.server.job.JobSchedulerService.scheduleAsPackage(JobSchedulerService.java:710)
at com.android.server.job.JobSchedulerService$JobSchedulerStub.schedule(JobSchedulerService.java:1904)
at android.app.JobSchedulerImpl.schedule(JobSchedulerImpl.java:44)
at com.android.server.backup.FullBackupJob.schedule(FullBackupJob.java:52)
at com.android.server.backup.BackupManagerService$4.run(BackupManagerService.java:5417)
at android.os.Handler.handleCallback(Handler.java:789)
at android.os.Handler.dispatchMessage(Handler.java:98)
at android.os.Looper.loop(Looper.java:164)
at android.os.HandlerThread.run(HandlerThread.java:65)
11-15 12:43:16.750 531-5797/? E/msm8974_platform: platform_check_backends_match: Invalid snd_device =
11-15 12:43:16.756 531-5797/? E/msm8974_platform: platform_get_snd_device_backend_index: BE DAI Name Table is not present
11-15 12:43:16.756 531-5797/? E/audio_hw_utils: send_app_type_cfg_for_device: Couldn't get the backend index for snd device speaker ret=-14
11-15 12:43:16.759 549-603/? E/ANDR-PERF-RESOURCEQS: Failed to apply optimization [4, 0]
11-15 12:43:16.936 549-603/? E/ANDR-PERF-OPTSHANDLER: perf_lock_rel: updated /sys/class/scsi_host/host0/../../../clkscale_enable with 1
return value 2
11-15 12:43:19.173 549-603/? E/ANDR-PERF-OPTSHANDLER: perf_lock_rel: updated /sys/class/scsi_host/host0/../../../clkscale_enable with 1
return value 2
11-15 12:43:30.043 1840-2690/com.ksyun.player.demo E/KSYMediaPlayer: moov atom not found
KSYProbe: avformat_open_input failed!
11-15 12:43:30.519 1840-2702/com.ksyun.player.demo A/libc: Fatal signal 11 (SIGSEGV), code 1, fault addr 0x14 in tid 2702 (AsyncTask #3)
11-15 12:43:30.583 2715-2715/? A/DEBUG: *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
11-15 12:43:30.584 2715-2715/? A/DEBUG: Build fingerprint: 'OnePlus/OnePlus3/OnePlus3T:8.0.0/OPR1.170623.032/06151230:user/release-keys'
Revision: '0'
ABI: 'arm64'
pid: 1840, tid: 2702, name: AsyncTask #3  >>> com.ksyun.player.demo <<<
signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x14
Cause: null pointer dereference
x0   0000007ee4d67c00  x1   0000000000000000  x2   0000000000000000  x3   0000000000000000
x4   0000000000000500  x5   0000000000000000  x6   0000007ee46a7400  x7   0000000000000004
x8   00000000ffffffff  x9   0000000000000000  x10  0000000000000005  x11  0000000000000010
x12  0000007ee31b7a68  x13  0000000000000000  x14  0000007f08bf76b4  x15  0000000000000000
x16  0000007ee26b13f0  x17  0000007f08b69bb0  x18  0000007ee2ef80c8  x19  0000000000000000
x20  0000000000000000  x21  0000007ee4d6b400  x22  0000007ee26b1000  x23  0000000000000000
x24  00000000000002c0  x25  0000000000000000  x26  0000000000000160  x27  00000000004c4b40
x28  0000007ee4d67c00  x29  0000007ee2ef7ee8  x30  0000007ee219f674
sp   0000007ee2ef7c10  pc   0000007ee219f688  pstate 0000000020000000
11-15 12:43:30.586 2715-2715/? A/DEBUG: backtrace:
#00 pc 000000000011c688  /data/app/com.ksyun.player.demo-ymv3WslMbWD87YY26ietEA==/lib/arm64/libksyplayer.so (ksy_get_thumbnail+332)
#01 pc 0000000000102e20  /data/app/com.ksyun.player.demo-ymv3WslMbWD87YY26ietEA==/lib/arm64/libksyplayer.so
#02 pc 000000000000f32c  /data/app/com.ksyun.player.demo-ymv3WslMbWD87YY26ietEA==/oat/arm64/base.odex (offset 0xf000)
11-15 12:43:31.756 1016-1016/? E//system/bin/tombstoned: Tombstone written to: /data/tombstones//tombstone_01
11-15 12:43:31.826 1348-1706/? E/InputDispatcher: channel '79c0ddf com.ksyun.player.demo/com.ksyun.player.demo.activity.MainActivity (server)' ~ Channel is unrecoverably broken and will be disposed!
11-15 12:43:34.396 4289-4289/? E/ContentDetectionService: updateSceneDetectionState() - No SceneDetector
11-15 12:43:35.342 532-2506/? E/vendor.qti.bluetooth@1.0-wake_lock: Release wakelock is released

替换大的so后正常，设置2倍速以后声音完全没法听，我用jikplayer编译的2倍速声音就很正常，而且同一个视频 会卡主画面，ijkplayer编译的正常


text:
🛑 Gitlab is down

In d6f5d0d, Gitlab (http://scm.chelsea.kt.co.kr) was down:

HTTP code: 200
Response time: 1606 ms

Resolved: Gitlab is back up in 34b3c0d.

repo: kt-chelsea/status


text:
Need help with correct code

I have code in PowerShell:
$Path = "C:\Program Files\Unity\????.?.*f1\Editor\unity.exe
$filesList = Get-ChildItem -Path $Path -Force -Recurse
How can I find all files unity.exe using this path with wildcards?
This code found nothing:
string[] matchingFiles = Glob.Files(@"C:\", @"Program Files\Unity\????.?.*f1\Editor\unity.exe").ToArray();

@GitUser200607 can you give an example path that you would expect to be matched?

"C:\Program Files\Unity\2021.3.9f1\Editor\Unity.exe"

repo: kthompson/glob


text:
pipeline execution option should be merged with the pipeline original option

Describe the bug
pipeline execution option should be merged with the pipeline original option
if executing  pipeline with partial options it overwrites the pipeline original options with defaults
To Reproduce
change "simple" pipeline ttl to 600
execute simple pipeline without ttl
{
    "name": "simple",
    "flowInput": {
        "files": {
            "link": "links-1"
        }
    },
    "options": {

        "progressVerbosityLevel": "debug"
    },
    "priority": 3
}

the pipeline will be executed with ttl 3600 (the default )

This issue probably created after #716  issue

@tamir321
I just upgraded the api-server version

@tamir321
Done

Tested on systemVersion: "v2.0.128",
fullSystemVersion: "v2.0.128-1618153188549",

repo: kube-HPC/hkube


text:
[docs] fix indentations in theory_of_airgapped_package.md

What type of PR is this?
/kind cleanup
/kind documentation
What this PR does / why we need it:
The current list is not good enough:

Local preview is good now.

/lgtm

/lgtm

authors: ErikJiang hangscer8 windsonsea

repo: kubean-io/kubean


text:
remove unused jsonPath code

Which Issue(s) this Pull Request Resolves

Resolves #569
Release Note

NONE

Notes for Reviewers

This PR is just removing unused code

Thanks for taking the time to remove dead code.

authors: rh-hemartin skoved

repo: kubearchive/kubearchive


text:
ksp-audit-stig-rhel-v-230337

Pr link: https://github.com/kubearmor/policy-templates/pull/459/files

Closing this since unsuccessful logon attempts can't be detected via KubeArmor as of now.

repo: kubearmor/policy-templates


text:
Move the K8s manifests for github sync into internal-acls.

This localizes the code in a single place which will make them
easier to find and maintain going forward.

Fix #249

/assign @chensun
/assign @Bobgy

/lgtm

authors: chensun jlewi

repo: kubeflow/internal-acls


text:
[enhancement] Set StartTime for TFJob status

In v1alpha2 the tfJob's StartTime is not set, and we should set it.
/cc @ScorpioCPH

Yes, let's set it after all pods are active.

Close by #504

authors: ScorpioCPH gaocegege

repo: kubeflow/tf-operator


text:
Adopting coschduling plugins

What this PR does / why we need it:
Adopts updated kubeflow/common with PodGroupControl designed for more generic gang-schedulers.
Follow up on #1526.
Also, reviewers can check the coscheduling feature with the scheduler-plugins in the following steps:
$ kind create cluster --image kindest/node:v1.24.7
$ git clone git@github.com:kubernetes-sigs/scheduler-plugins.git
$ cd scheduler-plugins/manifests/install/charts
$ helm install scheduler-plugins as-a-second-scheduler/
$ kubectl apply -k "github.com/tenzen-y/training-operator/manifests/overlays/standalone?ref=coscheduling"
$ kubectl patch -n kubeflow deployments training-operator -p '{"spec":{"template":{"spec":{"containers":[{"command":["/manager","--gang-scheduler-name=scheduler-plugins"],"image":"ytenzen/training-operator:test","name":"training-operator", "imagePullPolicy": "Always"}]}}}}'
$ cat <<EOF | kubectl apply -f -
apiVersion: "kubeflow.org/v1"
kind: TFJob
metadata:
  name: tfjob-simple
  namespace: kubeflow
spec:
  runPolicy:
    schedulingPolicy:
      minAvailable: 10
  tfReplicaSpecs:
    Worker:
      replicas: 2
      restartPolicy: OnFailure
      template:
        spec:
          schedulerName: scheduler-plugins-scheduler
          containers:
          - name: tensorflow
            image: gcr.io/kubeflow-ci/tf-mnist-with-summaries:1.0
            command:
            - "python"
            - "/var/tf_mnist/mnist_with_summaries.py"
EOF
$ kubectl get pods -n kubeflow
NAME                                 READY   STATUS    RESTARTS   AGE
tfjob-simple-worker-0                0/1     Pending   0          7m37s
tfjob-simple-worker-1                0/1     Pending   0          7m37s
training-operator-67cc5b6584-t7qtl   1/1     Running   0          8m39s
$ kubectl describe pods -n kubeflow tfjob-simple-worker-0 | grep -A10  Events
Events:
  Type     Reason            Age    From                         Message
  ----     ------            ----   ----                         -------
  Warning  FailedScheduling  8m26s  scheduler-plugins-scheduler  0/1 nodes are available: 1 pre-filter pod tfjob-simple-worker-0 cannot find enough sibling pods, current pods number: 1, minMember of group: 10. preemption: 0/1 nodes are available: 1 Preemption is not helpful for scheduling., PodGroup kubeflow/tfjob-simple gets rejected due to Pod tfjob-simple-worker-0 is unschedulable even after PostFilter, not eligible due to failed to read from cycleState
  Warning  FailedScheduling  2m57s  scheduler-plugins-scheduler  0/1 nodes are available: 1 pre-filter pod tfjob-simple-worker-0 cannot find enough sibling pods, current pods number: 2, minMember of group: 10. preemption: 0/1 nodes are available: 1 Preemption is not helpful for scheduling., PodGroup kubeflow/tfjob-simple gets rejected due to Pod tfjob-simple-worker-0 is unschedulable even after PostFilter, not eligible due to failed to read from cycleState

Which issue(s) this PR fixes (optional, in Fixes #<issue number>, #<issue number>, ... format, will close the issue(s) when PR gets merged):
Fixes #1722
Checklist:

[ ] Docs included if any changes are user facing

Pull Request Test Coverage Report for Build 3920653750

16 of 49 (32.65%)  changed or added relevant lines in 7 files are covered.
6 unchanged lines in 3 files lost coverage.
Overall coverage increased (+0.2%) to 39.383%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

pkg/controller.v1/mxnet/mxjob_controller.go
0
3
0.0%

pkg/controller.v1/xgboost/xgboostjob_controller.go
0
3
0.0%

pkg/controller.v1/tensorflow/tfjob_controller.go
4
9
44.44%

pkg/controller.v1/mpi/mpijob_controller.go
6
16
37.5%

pkg/controller.v1/register_controller.go
0
12
0.0%

Files with Coverage Reduction
New Missed Lines
%

pkg/controller.v1/register_controller.go
1
50.0%

pkg/controller.v1/mpi/mpijob_controller.go
2
77.47%

pkg/common/util/scheduler.go
3
0%

Totals

Change from base Build 3894456879:
0.2%

Covered Lines:
2669

Relevant Lines:
6777

💛  - Coveralls

Pull Request Test Coverage Report for Build 3920653750

16 of 49 (32.65%)  changed or added relevant lines in 7 files are covered.
6 unchanged lines in 3 files lost coverage.
Overall coverage increased (+0.2%) to 39.383%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

pkg/controller.v1/mxnet/mxjob_controller.go
0
3
0.0%

pkg/controller.v1/xgboost/xgboostjob_controller.go
0
3
0.0%

pkg/controller.v1/tensorflow/tfjob_controller.go
4
9
44.44%

pkg/controller.v1/mpi/mpijob_controller.go
6
16
37.5%

pkg/controller.v1/register_controller.go
0
12
0.0%

Files with Coverage Reduction
New Missed Lines
%

pkg/controller.v1/register_controller.go
1
50.0%

pkg/controller.v1/mpi/mpijob_controller.go
2
77.47%

pkg/common/util/scheduler.go
3
0%

Totals

Change from base Build 3894456879:
0.2%

Covered Lines:
2669

Relevant Lines:
6777

💛  - Coveralls

/hold for https://github.com/kubeflow/common/pull/203

This PR is ready for review. PTAL.
/assign @johnugeorge @zw0610 @terrytangyuan @gaocegege

@zw0610 @johnugeorge @terrytangyuan Please take a look. I would like to include PodGroup with the scheduler-plugin feature in this release.

@tenzen-y What is the best way to add e2e test for this?
Also, can you update docs in a separate PR? (In kubeflow/website?)

What is the best way to add e2e test for this?

Maybe, we could run e2e test by updating integration-tests.yaml like the following:
...
jobs:
  integration-test:
    runs-on: ubuntu-latest
    strategy:
      fail-fast: false
      matrix:
        kubernetes-version: ["v1.23.12", "v1.24.6", "v1.25.2"]
+       gang-scheduler-name: ["none", "scheduler-plugins"]
    steps:
      - name: Checkout
...
      - name: Deploy training operator
        run: |
          ./scripts/gha/setup-training-operator.sh
        env:
          KIND_CLUSTER: training-operator-cluster
          TRAINING_CI_IMAGE: kubeflowtraining/training-operator:test
+         GANG_SCHEDULER_NAME: ${{ matrix.gang-scheduler-name }}
...

Also, can you update docs in a separate PR? (In kubeflow/website?)

Yes, sure.
@johnugeorge

@tenzen-y You can use this release https://github.com/kubeflow/common/releases/tag/v0.4.6
Note: You need to take changes for HPA fixes from https://github.com/kubeflow/training-operator/pull/1732 as the release contains HPA selector field change as well.

@tenzen-y You can use this release https://github.com/kubeflow/common/releases/tag/v0.4.6
Note: You need to take changes for HPA fixes from #1732 as the release contains HPA selector field change as well.

@johnugeorge Thanks for letting me know.
I will upgrade kubeflow/common version after #1732 is merged.

@tenzen-y You can use this release https://github.com/kubeflow/common/releases/tag/v0.4.6
Note: You need to take changes for HPA fixes from #1732 as the release contains HPA selector field change as well.

@johnugeorge Thanks for letting me know. I will upgrade kubeflow/common version after #1732 is merged.

Instead, can you pick required changes from https://github.com/kubeflow/training-operator/pull/1732 and merge this into PR?  Else, many changes from this PR are required to make #1732  mergeable .

@tenzen-y You can use this release https://github.com/kubeflow/common/releases/tag/v0.4.6
Note: You need to take changes for HPA fixes from #1732 as the release contains HPA selector field change as well.

@johnugeorge Thanks for letting me know. I will upgrade kubeflow/common version after #1732 is merged.

Instead, can you pick required changes from #1732 and merge this into PR? Else, many changes from this PR are required to make #1732 mergeable .

@johnugeorge Ah, I see. You are right. I will pick up the HPA changes.

@johnugeorge Completed.

What is the best way to add e2e test for this?

Maybe, we could run e2e test by updating integration-tests.yaml like the following:
...
jobs:
  integration-test:
    runs-on: ubuntu-latest
    strategy:
      fail-fast: false
      matrix:
        kubernetes-version: ["v1.23.12", "v1.24.6", "v1.25.2"]
+       gang-scheduler-name: ["none", "scheduler-plugins"]
    steps:
      - name: Checkout
...
      - name: Deploy training operator
        run: |
          ./scripts/gha/setup-training-operator.sh
        env:
          KIND_CLUSTER: training-operator-cluster
          TRAINING_CI_IMAGE: kubeflowtraining/training-operator:test
+         GANG_SCHEDULER_NAME: ${{ matrix.gang-scheduler-name }}
...

Also, can you update docs in a separate PR? (In kubeflow/website?)

Yes, sure.
@johnugeorge

Do you plan to add CI tests in this PR or separate one ?

What is the best way to add e2e test for this?

Maybe, we could run e2e test by updating integration-tests.yaml like the following:
...
jobs:
  integration-test:
    runs-on: ubuntu-latest
    strategy:
      fail-fast: false
      matrix:
        kubernetes-version: ["v1.23.12", "v1.24.6", "v1.25.2"]
+       gang-scheduler-name: ["none", "scheduler-plugins"]
    steps:
      - name: Checkout
...
      - name: Deploy training operator
        run: |
          ./scripts/gha/setup-training-operator.sh
        env:
          KIND_CLUSTER: training-operator-cluster
          TRAINING_CI_IMAGE: kubeflowtraining/training-operator:test
+         GANG_SCHEDULER_NAME: ${{ matrix.gang-scheduler-name }}
...

Also, can you update docs in a separate PR? (In kubeflow/website?)

Yes, sure.
@johnugeorge

@johnugeorge I will work on E2E on another PR.

@johnugeorge Rebased.

Great work @tenzen-y Thank you for adding this feature
/lgtm
/approve

Great work @tenzen-y Thank you for adding this feature
/lgtm /approve

@johnugeorge
Thanks for the quick and detailed review!
I'll create a PR to add E2E test for scheduler-plugins by the end of Monday.

/hold cancel

authors: coveralls johnugeorge tenzen-y

repo: kubeflow/training-operator


text:
Describe about menu customization

Cluster admin can customize the menu bar by ConfigMap from KF1.3 (some parts of this feature was already available in KF1.2).
Since it is not written in the current documentation, this PR add a document about it.

Centraldashboard: update menu items in manifests #5706https://github.com/kubeflow/kubeflow/pull/5706

In addition, recent update improved the capability to support namespaced menu items. I wrote it about it too.

Make it possible to add Namespaced menu items #5871https://github.com/kubeflow/kubeflow/pull/5871

(Since I'm not a native English speaker, I appreciate if some reviewers correct unnatural sentences.)

@toshi-k I believe this sort of information should go under the Components / Central Dashboard section, rather than Further Setup and Troubleshooting:
https://www.kubeflow.org/docs/components/central-dash/

@thesuperzapper I've never seen that page before, but I totally agree with you. I moved the new document to the section for the central dashboard.
@RFMVasconcelos Could you review or LGTM my latest PR ?

@RFMVasconcelos Thank you for your review. I updated my PR as you proposed. Please review my latest PR again.

Awesome @toshi-k !
Thank you for contributing this to the community :)
/lgtm
/approve

authors: RFMVasconcelos thesuperzapper toshi-k

repo: kubeflow/website


text:
[BUG] DHCP server doesn't work!

Kube-OVN Version
v1.12.25
Kubernetes Version
v1.30.5+k3s1
Operation-system/Kernel Version
ubuntu 20.04 LTS
Description
When i enable the DHCP for a subnet with custom provider, it not works.
Steps To Reproduce
This is my subnet:
apiVersion: kubeovn.io/v1
kind: Subnet
metadata:
  name: subnet-1707237939748
spec:
  cidrBlock: 172.17.17.0/24
  default: false
  dhcpV4Options: lease_time=3600,router=172.17.17.1,server_id=169.254.0.254,server_mac=00:00:00:2E:2F:B8
  disableGatewayCheck: true
  enableDHCP: true
  excludeIps:
  - 172.17.17.1
  gateway: 172.17.17.1
  gatewayNode: ""
  gatewayType: distributed
  natOutgoing: false
  private: false
  protocol: IPv4
  provider: default.1707237939748.ovn
  vpc: vpc1707237939748

And the NAD :
apiVersion: v1
items:
- apiVersion: k8s.cni.cncf.io/v1
  kind: NetworkAttachmentDefinition
  metadata:
    name: default
    namespace: "1707237939748"
  spec:
    config: '{ "cniVersion": "0.3.0", "type": "kube-ovn", "provider": "default.1707237939748.ovn",
      "server_socket": "/run/openvswitch/kube-ovn-daemon.sock" }'

The first KubeVirt VM NIC is connected to the default subnet. and the second to the the subnet-1707237939748 using multus.
Current Behavior
The VM doesn't set the default gateway.
and when try to see the DHCP server, It seems the default DHCP server hasn't replaced, but there's located:
$ kubectl ko nbctl list dhcp_options
_uuid               : 247d72c3-41fd-4778-a0c6-d0c9a932f2a1
cidr                : "172.17.17.0/24"
external_ids        : {ls=subnet-1707237939748, protocol=IPv4, vendor=kube-ovn}
options             : {lease_time="3600", router="172.17.17.1", server_id="169.254.0.254", server_mac="00:00:00:2E:2F:B8"}

$ dhclient -d -nw enp1s0

Internet Systems Consortium DHCP Client 4.4.1
Copyright 2004-2018 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/

Listening on LPF/enp1s0/ae:6b:32:af:33:9a
Sending on   LPF/enp1s0/ae:6b:32:af:33:9a
Sending on   Socket/fallback
DHCPREQUEST for 172.17.17.7 on enp1s0 to 255.255.255.255 port 67 (xid=0x68d8136a)
DHCPACK of 172.17.17.7 from 169.254.75.10 (xid=0x6a13d868)
RTNETLINK answers: File exists
bound to 172.17.17.7 -- renewal in 37158937 seconds.

Expected Behavior
To set the default gateway.

The VM doesn't set the default gateway.

What does this mean? Result of command dhclient -d -nw enp1s0 shows that the ovn dhcp server is working on enp1s0.

The VM doesn't set the default gateway.

What does this mean? Result of command dhclient -d -nw enp1s0 shows that the ovn dhcp server is working on enp1s0.

It's not that DHCP server: 169.254.75.10

I cannot reproduce this problem in my KIND cluster. Here is my test resources:
apiVersion: kubeovn.io/v1
kind: Vpc
metadata:
  name: vpc1
spec: {}
---
apiVersion: kubeovn.io/v1
kind: Subnet
metadata:
  name: subnet1
spec:
  cidrBlock: 172.17.17.0/24
  default: false
  dhcpV4Options: lease_time=3600,router=172.17.17.1,server_id=169.254.0.254,server_mac=00:00:00:2E:2F:B8
  disableGatewayCheck: true
  enableDHCP: true
  excludeIps:
  - 172.17.17.1
  gateway: 172.17.17.1
  gatewayNode: ""
  gatewayType: distributed
  natOutgoing: false
  private: false
  protocol: IPv4
  provider: nad.default.ovn
  vpc: vpc1
---
apiVersion: k8s.cni.cncf.io/v1
kind: NetworkAttachmentDefinition
metadata:
  name: nad
  namespace: default
spec:
  config: '{ "cniVersion": "0.3.0", "type": "kube-ovn", "provider": "nad.default.ovn",
    "server_socket": "/run/openvswitch/kube-ovn-daemon.sock" }'
---
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: pod1
  namespace: default
spec:
  selector:
    matchLabels:
      app: kubeovn
  template:
    metadata:
      labels:
        app: kubeovn
      annotations:
        k8s.v1.cni.cncf.io/networks: default/nad
    spec:
      terminationGracePeriodSeconds: 0
      containers:
      - name: pod
        imagePullPolicy: Never
        image: kubeovn/kube-ovn:v1.12.25
        securityContext:
          privileged: true
        command:
          - sleep
          - "10000"

Test result:
$ ip -c a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
20: eth0@if21: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1400 qdisc noqueue state UP group default
    link/ether 26:4c:31:f9:d2:c5 brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet 10.16.0.8/16 brd 10.16.255.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::244c:31ff:fef9:d2c5/64 scope link
       valid_lft forever preferred_lft forever
22: net1@if23: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1400 qdisc noqueue state UP group default
    link/ether 8a:8d:60:3c:0b:82 brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet 172.17.17.2/24 brd 172.17.17.255 scope global net1
       valid_lft forever preferred_lft forever
    inet6 fe80::888d:60ff:fe3c:b82/64 scope link
       valid_lft forever preferred_lft forever
$ ip a del 172.17.17.2/24 dev net1
$ ip -c a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
20: eth0@if21: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1400 qdisc noqueue state UP group default
    link/ether 26:4c:31:f9:d2:c5 brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet 10.16.0.8/16 brd 10.16.255.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::244c:31ff:fef9:d2c5/64 scope link
       valid_lft forever preferred_lft forever
22: net1@if23: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1400 qdisc noqueue state UP group default
    link/ether 8a:8d:60:3c:0b:82 brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet6 fe80::888d:60ff:fe3c:b82/64 scope link
       valid_lft forever preferred_lft forever
$ dhcpcd net1
dhcpcd-10.0.6 starting
DUID 00:01:00:01:2e:97:9f:34:8a:8d:60:3c:0b:82
net1: IAID 60:3c:0b:82
net1: soliciting an IPv6 router
net1: soliciting a DHCP lease
net1: offered 172.17.17.2 from 169.254.0.254
net1: probing address 172.17.17.2/24
net1: leased 172.17.17.2 for 3600 seconds
net1: adding route to 172.17.17.0/24
net1: adding default route via 172.17.17.1
Dropped protocol specifier '.dhcp' from 'net1.dhcp'. Using 'net1' (ifindex=22).
$ ip -c a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
20: eth0@if21: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1400 qdisc noqueue state UP group default
    link/ether 26:4c:31:f9:d2:c5 brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet 10.16.0.8/16 brd 10.16.255.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::244c:31ff:fef9:d2c5/64 scope link
       valid_lft forever preferred_lft forever
22: net1@if23: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1400 qdisc noqueue state UP group default
    link/ether 8a:8d:60:3c:0b:82 brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet 172.17.17.2/24 brd 172.17.17.255 scope global dynamic noprefixroute net1
       valid_lft 3396sec preferred_lft 2946sec
    inet6 fe80::888d:60ff:fe3c:b82/64 scope link
       valid_lft forever preferred_lft forever
$ ip -c r
default via 10.16.0.1 dev eth0
default via 172.17.17.1 dev net1 proto dhcp src 172.17.17.2 metric 1022
10.16.0.0/16 dev eth0 proto kernel scope link src 10.16.0.8
172.17.17.0/24 dev net1 proto dhcp scope link src 172.17.17.2 metric 1022

You are using kubevirt so the DHCP is provided by kubevirt.

Routes in the VM is not conntrolled by CNI.

You are using kubevirt so the DHCP is provided by kubevirt.

Thanks for clarifying.

authors: cybercoder zhangzujian

repo: kubeovn/kube-ovn


text:
[BUG] k8s和openstack打通后，vm侧不能通过SwitchLBRule的vip请求pod服务

Kube-OVN Version
v1.12.29
Kubernetes Version
v1.30
Operation-system/Kernel Version
Ubuntu 24.04.1 LTS
Description
我现在按照文档通过共享底层 OVN方式已经将k8s和openstack进行打通

pod请求vm：

vm请求pod：

同时，我创建了nginx deployment，并配置了SwitchLBRule

同namespace下也有svc生成：

现在在vm侧通过vip请求不通：

同namespace下的busybox pod通过vip请求是通的：

想问下是怎么回事？相关信息

Steps To Reproduce
无
Current Behavior
vm侧不能通过curl vip的方式请求nginx pod
Expected Behavior
希望vm侧能通过curl vip的方式成功请求nginx pod


text:
Canal CNI defective in rare cases

What happened:
When installing a KubeOne cluster, in rare cases the Canal CNI pods are shown to be running but not usable. The entire KubeOne installation fails when deploying the machine-controller in this case. Machine-controller and CoreDNS pods stay in pending state due to the following condition:
Failed to create pod sandbox: rpc error: code = Unknown desc = [failed to set up sandbox container "6675d4875be32a0a78d89e208f3fb61d09b72e597e6565ee14121e69336006f8" network for pod "coredns-6955765f44-pggjl": networkPlugin cni failed to set up pod "coredns-6955765f44-pggjl_kube-system" network: error getting ClusterInformation: resource does not exist: ClusterInformation(default) with error: the server could not find the requested resource (get ClusterInformations.crd.projectcalico.org default), failed to clean up sandbox container "6675d4875be32a0a78d89e208f3fb61d09b72e597e6565ee14121e69336006f8" network for pod "coredns-6955765f44-pggjl": networkPlugin cni failed to teardown pod "coredns-6955765f44-pggjl_kube-system" network: error getting ClusterInformation: resource does not exist: ClusterInformation(default) with error: the server could not find the requested resource (get ClusterInformations.crd.projectcalico.org default)]
Canal's calico container logs the following error:
2020-06-24 11:20:44.067 [ERROR][8] client.go 251: Error creating cluster information config ClusterInformation=&v3.ClusterInformation{TypeMeta:v1.TypeMeta{Kind:"ClusterInformation", APIVersion:"projectcalico.org/v3"}, ObjectMeta:v1.ObjectMeta{Name:"default", GenerateName:"", Namespace:"", SelfLink:"", UID:"4e7c4b94-e00d-437b-959a-e277c807caf7", ResourceVersion:"", Generation:0, CreationTimestamp:v1.Time{Time:time.Time{wall:0xbfb4eba303d8c464, ext:6639844301, loc:(*time.Location)(0x2d61840)}}, DeletionTimestamp:(*v1.Time)(nil), DeletionGracePeriodSeconds:(*int64)(nil), Labels:map[string]string(nil), Annotations:map[string]string(nil), OwnerReferences:[]v1.OwnerReference(nil), Initializers:(*v1.Initializers)(nil), Finalizers:[]string(nil), ClusterName:"", ManagedFields:[]v1.ManagedFieldsEntry(nil)}, Spec:v3.ClusterInformationSpec{ClusterGUID:"f1988d2388444411b0bd7f42db3471f8", ClusterType:"k8s,canal,kdd", CalicoVersion:"v3.10.0", DatastoreReady:(*bool)(0xc0002b2973)}} error=resource does not exist: ClusterInformation(default) with error: the server could not find the requested resource (post ClusterInformations.crd.projectcalico.org)
The CRDs in question are available after this. So this looks like a race condition, caused by CRDs not usable yet when the calico container is started. Deleting the canal pods solves the problem.
What is the expected behavior:
Maybe separating the CRD deployment and waiting until it is actually available makes the cluster creation more robust.
How to reproduce the issue:
Appears occasionally during a kubeone install
Anything else we need to know?
Might be reinforced by an unresponsive etcd ring due to https://github.com/kubermatic/kubeone/issues/915
Information about the environment:
KubeOne version (kubeone version): v1.0.0-alpha.6
Operating system: CentOS (master)
Provider you're deploying cluster on: Azure
Operating system you're deploying on: OSX

I've just had the same situation on AWS running Flatcar.

Maybe separating the CRD deployment and waiting until it is actually available makes the cluster creation more robust.

I was convinced we already doing this. But it turned out to be a fantasy :D

authors: chrkl kron4eg xmudrii

repo: kubermatic/kubeone


text:
Use kubeone-e2e:v0.1.23 is some postsubmits

What type of PR is this?
/kind regression
What this PR does / why we need it:
To use updated GOCACHE with newer Go version (currently 1.18.3), otherwise gocache is always outdated.
Which issue(s) this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close the issue(s) when PR gets merged):
Fixes #
Special notes for your reviewer:
Does this PR introduce a user-facing change?:

NONE

/approve


text:
Flatcar: explicitly stop masked units on first boot

Signed-off-by: Waleed Malik ahmedwaleedmalik@gmail.com
What this PR does / why we need it:
When we are using ignition for provisioning on flatcar nodes we conditionally mask the following services:

update-engine.service
locksmithd.service

Although just masking them isn't sufficient since that won't "stop" the services from running on the first boot.
Which issue(s) this PR fixes (optional, in fixes #<issue number> format, will close the issue(s) when PR gets merged):
Fixes #
Special notes for your reviewer:
This is a follow up for https://github.com/kubermatic/machine-controller/pull/1219 that fixes this issue when we are using ignition as provisioning utility.
The new service is intentionally named just setup since I wanted the name to be generic.
Optional Release Note:

NONE

@ahmedwaleedmalik is this one still WIP or Ready for review?

@ahmedwaleedmalik is this one still WIP or Ready for review?

It's ready for review now. I mistakenly asked for a review before updating the fixtures.

/retest

/retest

authors: ahmedwaleedmalik mlavacca

repo: kubermatic/machine-controller


text:
Add the howto-provider to the README

Make the howto-provider visible on the README
 none

/retest
/override dco

/lgtm
/approve

authors: alvaroaleman scheeles


text:
Use podAntiAffinity to schedule control plane pods to different nodes.

Without podAntiAffinity, the scheduler might schedule kube-scheduler and kube-controller-manager to the same node. When this node is down, we might lose all kube-scheduler or kube-controller-manager at once. The cluster will have problem recover from this failure.
With this patch, the scheduler will schedule control plane pods into different nodes making the cluster more reliable.

ok to test

Anti-affinity will no longer be based on an annotation in v1.6, so the plan was to wait to add this functionality until v1.6.0 ships (likely a couple weeks): See https://groups.google.com/forum/#!msg/kubernetes-dev/-fwfHQtm9GE/H1TU4yqiBAAJ

Added the issue to the milestone tracking the changes we want to get in with the v1.6.0 release: https://github.com/kubernetes-incubator/bootkube/milestone/3

rktbot run tests

@aaronlevy Sorry I didn't notice the issue. I can make some changes to this pr after v1.6 release if you want.

Sure. I'll leave this open to track that

This was implemented in https://github.com/kubernetes-incubator/bootkube/pull/421.

Closed in https://github.com/kubernetes-incubator/bootkube/pull/421

authors: aaronlevy adieu pbx0 squat

repo: kubernetes-incubator/bootkube


text:
Can't acess  /apis/metrics.k8s.io/  from apiserver

Hi All,
I just upgrade the k8s to 1.8.1 from 1.7.5, and deployed metrics-server with the default deployment manifes in the repo. right now I can't get metrics from /apis/metrics.k8s.io/v1beta1/nodes or /apis/metrics.k8s.io/v1beta1/pods.
#curl --cacert ca.pem --cert apiserver.pem --key apiserver-key.pem  https://10.58.137.243:6443/apis/metrics.k8s.io/v1beta1/nodes
{
  "kind": "Status",
  "apiVersion": "v1",
  "metadata": {

  },
  "status": "Failure",
  "message": "nodes.metrics.k8s.io is forbidden: User \"xxx\" cannot list nodes.metrics.k8s.io at the cluster scope",
  "reason": "Forbidden",
  "details": {
    "group": "metrics.k8s.io",
    "kind": "nodes"
  },
  "code": 403

xxx: is the node FQDN
and I use the apiserver key/cert in the command parameter.
also apiserver append following parameters
      --requestheader-client-ca-file=/srv/kubernetes/ca.pem
      --requestheader-allowed-names=aggregator
      --requestheader-extra-headers-prefix=X-Remote-Extra-
      --requestheader-group-headers=X-Remote-Group
      --requestheader-username-headers=X-Remote-User
      --proxy-client-cert-file=/srv/kubernetes/kubelet-cert.pem
      --proxy-client-key-file=/srv/kubernetes/kubelet-key.pem

As I just upgrade from previous cluster, I don't create a second CA authority for metrics-server. how to leverage the current CA to make it work ?

do I need to create a second cert/key  or users signed by the currentl CA  to get access the metrics-server?  additional cluster role needed ?

Can we just use currently cert/key/ users to access these metrics? since current use can aceess the other apis exposed by apiserver

k8s info:
 kubectl version
Client Version: version.Info{Major:"1", Minor:"8", GitVersion:"v1.8.1", GitCommit:"f38e43b221d08850172a9a4ea785a86a3ffa3b3a", GitTreeState:"clean", BuildDate:"2017-10-11T23:27:35Z", GoVersion:"go1.8.3", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"8", GitVersion:"v1.8.1", GitCommit:"f38e43b221d08850172a9a4ea785a86a3ffa3b3a", GitTreeState:"clean", BuildDate:"2017-10-11T23:16:41Z", GoVersion:"go1.8.3", Compiler:"gc", Platform:"linux/amd64"}

docker info:
#  docker info
Containers: 171
 Running: 83
 Paused: 0
 Stopped: 88
Images: 456
Server Version: 1.12.6
Storage Driver: aufs
 Root Dir: /var/lib/docker/aufs
 Backing Filesystem: xfs
 Dirs: 1061
 Dirperm1 Supported: true
Logging Driver: journald
Cgroup Driver: systemd
Plugins:
 Volume: local
 Network: host null bridge overlay
Swarm: inactive
Runtimes: runc
Default Runtime: runc
Security Options: apparmor seccomp
Kernel Version: 4.8.0-58-generic
Operating System: Ubuntu 16.04.3 LTS
OSType: linux
Architecture: x86_64
CPUs: 32
Total Memory: 62.79 GiB
Name: cnpvgl56588417
ID: RBIH:KI5N:HFUQ:JBTQ:ENOS:QLZV:T3T2:TGXT:VM5H:SWVO:ARDN:W33P
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): true
 File Descriptors: 383
 Goroutines: 360
 System Time: 2017-10-17T17:39:26.358987804+08:00
 EventsListeners: 0
Http Proxy: http://proxy.pvgl.sap.corp:8080
Https Proxy: http://proxy.pvgl.sap.corp:8080
No Proxy: registry.gcsc.sap.corp
Registry: https://index.docker.io/v1/
WARNING: No swap limit support
Insecure Registries:
 127.0.0.0/8

Ok, there's a few issues with your setup:

curl --cacert ca.pem --cert apiserver.pem --key apiserver-key.pem  https://10.58.137.243:6443/apis/metrics.k8s.io/v1beta1/nodes

Where are apiserver.pem and apiserver-key.pem coming from?  Are they client certificates for users who should be able to connect?

User "xxx" cannot list nodes.metrics.k8s.io at the cluster scope"

The user will be the user associated with the client certificates provided.  You'll need to make sure that the user has permission to access the metrics APIs.  If you've properly reconciled the default policy, only cluster-reader, cluster-admins, and the HPA controller service account will have permission to fetch metrics by default.

--requestheader-client-ca-file=/srv/kubernetes/ca.pem

This is incorrect.  Your requestheader CA should never be the same as your serving CA.  Please take a look at https://github.com/kubernetes-incubator/apiserver-builder/blob/master/docs/concepts/auth.md for more information.

As I just upgrade from previous cluster, I don't create a second CA authority for metrics-server. how to leverage the current CA to make it work ?

Assuming you have the three different CAs already available (requestheader client CA, normal client CA, serving CA), you won't need any new CA certs.  You can use the serving CA to sign the serving certificates for metrics-server (see the above link)

do I need to create a second cert/key or users signed by the currentl CA to get access the metrics-server? additional cluster role needed ?

See above.

Can we just use currently cert/key/ users to access these metrics? since current use can aceess the other apis exposed by apiserver

Whatever user you're using needs to have permissions.  If it's cluster-admin or cluster-reader, you should be all set.  Otherwise, you'll need to grant it additional permissions.

thank, I finnally got resoved this issue.

@jenningsloy318 for the future references - could you please explain what you did?

My front-proxy-client certs on the new masters weren't valid.  I only copied pki/{ca,sa}.* since I was following the 1.10 version of the docs - needed front-proxy-ca.* as well which the 1.11 docs mention.  Sorry for the noise.
openssl verify -CAfile /etc/kubernetes/front-proxy-ca.crt /etc/kubernetes-worker/pki/front-proxy-client.crt
/etc/kubernetes-worker/pki/front-proxy-client.crt: CN = front-proxy-client
error 7 at 0 depth lookup:certificate signature failure

repo: kubernetes-incubator/metrics-server


text:
Fix NewFor to GetRESTOptions

This PR is a

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

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

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

[ ] New feature

[ ] Tests
[ ] Documentation

[ ] SVCat CLI flag
[ ] Server Flag for config

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

/ok-to-test
/lgtm

/check-cla

authors: luksa wayilau

repo: kubernetes-incubator/service-catalog


text:
Fix usage of finalizers

Fix usage of finalizers

The "kubernetes" finalizer is a special finalizer token not meant for use by other projects.
The finalizer token values should also be qualified names.
Updated the code  to use sets for handling finalizers (ordering is not required)

@MHBauer -- the finalizer token "kubernetes" is used in namespace deletion which predates objectmeta.finalizers, but may converge in the future, so i do not want catalog to use it.  the only other two finalizer tokens that are delivered in the core are related to garbage collection and are "orphan" and "foregroundDeletion".  any finalizer token not in the core should be a qualified name with a prefix.  for example, federation uses a finalizer token "federation.kubernetes.io/delete-from-underlying-clusters" with proper qualified prefixing.

@arschles -- updated.  for reference, ordering does not matter in finalizers list.

@derekwaynecarr Is there a finalizers document somewhere that has
 any finalizer token not in the core should be a qualified name with a prefix. for example, federation uses a finalizer token "federation.kubernetes.io/delete-from-underlying-clusters" with proper qualified prefixing.

in it? Seems like a great example that would help anybody coming along to write or understand finalizers in the future.

authors: MHBauer derekwaynecarr


text:
chore: add kwok + kind github action

Fixes #N/A
Description
This stages a workflow to be able to run the kwok controller in kind clusters. This just sets up the environment, and disables the presubmit, so that we're not creating kind clusters without actually running any tests on them.
How was this change tested?
testing GHA on my own fork
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 8946234624
Details

0 of 0   changed or added relevant lines in 0 files are covered.
4 unchanged lines in 2 files lost coverage.
Overall coverage decreased (-0.04%) to 78.822%

Files with Coverage Reduction
New Missed Lines
%

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

pkg/controllers/node/termination/terminator/eviction.go
2
88.89%

Totals

Change from base Build 8916772215:
-0.04%

Covered Lines:
8348

Relevant Lines:
10591

💛  - Coveralls

closing because i cut from the wrong branch :(

authors: coveralls njtran

repo: kubernetes-sigs/karpenter


text:
fix: remove refs issue

This PR fixes a removeRefs issue.
It looks like we need to reset extensions before comparing with an empty schema.
Fixes https://github.com/kubernetes-sigs/kubectl-validate/issues/54

Looks like in this bug's case the schema for the field that's being resolve looks like:
"strategy": {
    "allOf": [
      {
        "$ref": "#/components/schemas/io.k8s.api.apps.v1.DeploymentStrategy"
      }
    ],
    "default": {},
    "description": "The deployment strategy to use to replace existing pods with new ones.",
    "x-kubernetes-patch-strategy": "retainKeys"
},

This bug can happen if there is a field-level override of the referred schema. I am curious if other cases like this exist. The proposed solution would lose the information that the field uses retainKeys. I can imagine other field-level extensions useful for validation that would be lost here like x-kubernetes-validations or x-kuberenetes-list-type. The original code also erroneous strips the Default value, which is another bug.
This part of the code is completely a hack to satisfy the requirements of structural schema which does not like new properties inside allOf (structural schema is required to run validators). Upstream we have a loose plan to add validation that does not require the structural schema and operates instead on kube-openapi for both CRs and native types. This goal is long away, so we have this hack.
xref: https://github.com/kubernetes/kubernetes/issues/106387
xref: https://github.com/kubernetes/kube-openapi/pull/298
I'm thinking if we see a schema that meets the following conditions:

len(s.allOf) = 1
len(s.allOf[0].Ref) > 0

Then it should just be interpreted as a ref without any additional checks. We can be confident in this approach since k8s apiserver is the only source of $refs, and it always wraps them in a single element allOf.
We should create a copy of the referred schema, and set all non-empty properties of the field's override schema onto the referred schema.
So in the case of strategy above:

vCopy := removeRefs(s.allOf[0].Ref)
vCopy.Default = s.Default
vCopy.Description = s.Description
for k, v in range s.Extensions: vCopy.Extensions[k] = v (may need to copy vCopy.Extensions too to avoid changing the original map)

@alexzielenski i'm not very familiar with this code, I tried to follow your explanations but tests are failing, would you mind giving a look please ?

If you base on #60 I think some of the issues can go away. That would just leave the last comment from my last review to resolve

/close
I think all the changes from this PR were merged in #67 and #60

/close
I think all the changes from this PR were merged in #67 and #60

authors: alexzielenski eddycharly

repo: kubernetes-sigs/kubectl-validate


text:
chore: disable CrossClusterDiscovery feature by default

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 #
By the reactions in GH https://github.com/kubernetes-sigs/kubefed/issues/1283, this feature does not seem to be used. It is an alpha feature that is handling certain features that should not be tackled by kubefed, but instead use other tools such as Istio.
I am disabling it by default for now. Note that, this feature is in an alpha stage so it could be deleted in the future reduce the maintenance burden.
related to https://github.com/kubernetes-sigs/kubefed/issues/1283
Special notes for your reviewer:

The in-memory controller errors are failing. I'll check how to enable the feature only for those tests.

Thanks @hectorj2f
This seems like a valid thing to do as of now.
/lgtm

repo: kubernetes-sigs/kubefed


text:
HNC: Add critical condition to both culprit namespaces when they cause a cycle.

Right now if setting the parent of a namespace causes a cycle, only the parent will get CritParentInvalid condition. When restarting HNC, it is nondeterministic which namespace in the cycle will have CritParentInvalid condition. For details, see discussions in #660.
Ideally, if we set parent of a to b and it causes a cycle, the condition should be on both a and b and not on other namespaces in the cycle. Furthermore, the locations of the condition should not change when restarting HNC.
Since it is possible that b might be a descendant of a but not a child of a, we will change the condition name to exclude the word "parent", e.g., CritCycle.

cc:
@adrianludwin
@adrianchung
@yiqigao217

repo: kubernetes-sigs/multi-tenancy


text:
Ssh state management

Creates a new state provider abstraction for SSH state related things (keys and config)
Removes confusing unused SSH agent support
Reduces the frequency of reading and writing SSH files from / to disk
Creates strong types for SSH public keys and private keys to avoid
mistakes mixing them up
Introduces a new SSH keypair type
Splits key loading and writing logic from business logic for preparing
the keys for use
Stops mounting the user's ~/.ssh directory which they might quite rightly be concerned about and moves all the SSH config and keys into the ~/.kubesim folder for consistency
Renames the go module to match the repo (from controlplaneio/simulator-standalone)
Fixes flickering unit tests because of pre-existing SSH keys

Everything should just work the same from the users perspective (other than the move of the location of the SSH keys and config, but that's not obvious to them)

I'm about to force push to fix the conflict and squash the WIP commit that crept in

Hmm, this is happening because I have moved the SSH keys into the kubesim folder and you have an existing bastion.tfvars file telling simulator its in the ~/.ssh folder.  The cleaned up log is:
No file exists at
/home/launch/.ssh/cp_simulator_rsa

which is true!  I no longer mount ~/.ssh

Ok this should now be fixed.  I've updated the correct new location for the ssh key everywhere

well you have fixed the initial problem, now got an issue launching a scenario:
INFO[2020-03-12T14:20:18Z] Running terraform output INFO[2020-03-12T14:20:21Z] Finding details of scenario                   ScenarioID=policy-fire-support INFO[2020-03-12T14:20:21Z] Updating SSH config INFO[2020-03-12T14:20:21Z] Keyscanning bastion and updating known hosts  BastionIP=15.188.146.250 INFO[2020-03-12T14:20:21Z] Setting up the scenario on the cluster        Scenario="Policy Fire Support" ERRO[2020-03-12T14:20:21Z] Cannot connect to 172.31.2.95                 Args="[--master 172.31.2.95 --bastion 15.188.146.250 --nodes 172.31.2.163,172.31.2.55 policy-fire-support]" Command=./perturb.sh ERRO[2020-03-12T14:20:21Z] Error launching scenario                      Error="Error running perturb with simulator.PerturbOptions{Bastion:net.IP{0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0xff, 0xff, 0xf, 0xbc, 0x92, 0xfa}, Master:net.IP{0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0xff, 0xff, 0xac, 0x1f, 0x2, 0x5f}, Slaves:[]net.IP{net.IP{0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0xff, 0xff, 0xac, 0x1f, 0x2, 0xa3}, net.IP{0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0xff, 0xff, 0xac, 0x1f, 0x2, 0x37}}, ScenarioName:\"policy-fire-support\"}: Error waiting for child process ./perturb.sh: exit status 3"
simulator ssh attack works fine btw

This is now fixed

authors: jondkent raoulmillais

repo: kubernetes-simulator/simulator


text:
Keycloak requires additional permissions for installation

Is this a request for help?:
No
Is this a BUG REPORT or FEATURE REQUEST? (choose one):
BUG REPORT

Version of Helm and Kubernetes:
$ helm version
Client: &version.Version{SemVer:"v2.8.2", GitCommit:"a80231648a1473929271764b920a8e346f6de844", GitTreeState:"clean"}
Server: &version.Version{SemVer:"v2.8.2", GitCommit:"a80231648a1473929271764b920a8e346f6de844", GitTreeState:"clean"}

# minikube
$ kubectl version
Client Version: version.Info{Major:"1", Minor:"10", GitVersion:"v1.10.0", GitCommit:"fc32d2f3698e36b93322a3465f63a14e9f0eaead", GitTreeState:"clean", BuildDate:"2018-03-27T00:14:31Z", GoVersion:"go1.9.4", Compiler:"gc", Platform:"darwin/amd64"}
Server Version: version.Info{Major:"", Minor:"", GitVersion:"v1.9.4", GitCommit:"bee2d1505c4fe820744d26d41ecd3fdd4a3d6546", GitTreeState:"clean", BuildDate:"2018-03-21T21:48:36Z", GoVersion:"go1.9.1", Compiler:"gc", Platform:"linux/amd64"}

Which chart:
incubator/keycloak
What happened:
Error:
$ helm install incubator/keycloak
Error: release kissable-anaconda failed: roles.rbac.authorization.k8s.io "keycloak-kissable-an" is forbidden: attempt to grant extra privileges: [PolicyRule{Resources:["pods"], APIGroups:[""], Verbs:["list"]}] user=&{system:serviceaccount:kube-system:default ee372f23-3c94-11e8-9d70-080027f5fb92 [system:serviceaccounts system:serviceaccounts:kube-system system:authenticated] map[]} ownerrules=[] ruleResolutionErrors=[]

What you expected to happen:
No error
How to reproduce it (as minimally and precisely as possible):
$ helm repo add incubator http://storage.googleapis.com/kubernetes-charts-incubator
$ helm install incubator/keycloak

Anything else we need to know:
No

Is RBAC enabled on your cluster? Otherwise you should set rbac.enabled=false and serviceAccount.create=false.
With #5372, RBAC will no longer be required for this chart.

authors: saplla unguiculus

repo: kubernetes/charts


text:
[stable/prestashop] Set dependencies to the latest version

What this PR does / why we need it:
Which issue this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close that issue when PR gets merged): fixes #
Special notes for your reviewer:
Logs:
Welcome to the Bitnami prestashop container
Subscribe to project updates by watching https://github.com/bitnami/bitnami-docker-prestashop
Submit issues and feature requests at https://github.com/bitnami/bitnami-docker-prestashop/issues

WARN  ==> You set the environment variable ALLOW_EMPTY_PASSWORD=yes. For safety reasons, do not use this flag in a production environment.
nami    INFO  Initializing apache
apache  INFO  ==> Patching httpoxy...
nami    INFO  apache successfully initialized
nami    INFO  Initializing php
nami    INFO  php successfully initialized
nami    INFO  Initializing mysql-client
nami    INFO  mysql-client successfully initialized
nami    INFO  Initializing prestashop
mysql-c INFO  Trying to connect to MySQL server
mysql-c INFO  Found MySQL server listening at coiled-possum-mariadb:3306
mysql-c INFO  MySQL server listening and working at coiled-possum-mariadb:3306
prestas INFO  Configuring webserver...
prestas INFO  Configuring PHP settings...
prestas INFO  Configuring PrestaShop...
prestas INFO
prestas INFO  ########################################################################
prestas INFO   Installation parameters for prestashop:
prestas INFO     First Name: Bitnami
prestas INFO     Last Name: User
prestas INFO     Email: user@example.com
prestas INFO     Password: **********
prestas INFO     Shop Name: PrestaShop
prestas INFO     Admin URL: http://35.204.241.98/administration
prestas INFO   (Passwords are not shown for security reasons)
prestas INFO  ########################################################################
prestas INFO
nami    INFO  prestashop successfully initialized
INFO  ==> Starting prestashop...

/ok-to-test
/lgtm

authors: carrodher javsalgar


text:
Implement KCM -> CCM Migration

Implementation of KEP https://github.com/kubernetes/cloud-provider/issues/11
TODO (andrewsykim): add more description

At least alpha for v1.15
/milestone v1.15
/priority critical-urgent

/close dupe of https://github.com/kubernetes/cloud-provider/issues/11

repo: kubernetes/cloud-provider


text:
Nginx Ingress Controller - Option to disable interception of errors

It seems to me right now there is no way to configure the nginx ingress controller to not intercept errors and serve them from the default/error backend.
In our case this is problematic. Our backends serve meaningful error pages for 500 errors which contain exception ids which help us debugging problems when customers create support requests.
We also have a JSON API backend where 404 error contain additional information that help api clients to fail more gracefully.
How about adding an option to (potentially partially) disable the error interception ?
I can submit an initial PR of this would be considered useful.

@databus23 this is the list of the intercepted errors https://github.com/kubernetes/contrib/blob/master/ingress/controllers/nginx/nginx.tmpl#L129 . Just in case error 500 is not intercepted.
You want multiple options (one per error) or a global flag?

You want multiple options (one per error) or a global flag?

I meant option in the nginx configmap

@aledbf Ups missed that one. Ok, so 500 errors should work, I actually never tested this. But we have had problems with 404 and 403 errors where backend developers where unhappy that there response didn't get served to the client. For a start I would like a global flag to have nginx not mingle any responses. Having this configurable per error or even per backend would be nice to have.

@databus23 I will add a global option and one per intercepted error today

repo: kubernetes/contrib


text:
Ping people when flaky issues don't get attention

This change is

LGTM after fixes to never ping conditions and comments

Review status: 0 of 3 files reviewed at latest revision, 9 unresolved discussions, some commit checks failed.

mungegithub/mungers/nag-flake-issues.go, line 63 [r3] (raw file):

// Initialize will initialize the munger
func (NagFlakeIssues) Initialize(config *mgh.Config, features *features.Features) error {

Is this because it implements some interface?  If so, can you do the compile time checking thing: var _ InterfaceType = &NagFlakeIssues{}

mungegithub/mungers/nag-flake-issues.go, line 74 [r3] (raw file):

findTimePeriod

Plz add a comment describing what this method is supposed to do

mungegithub/mungers/nag-flake-issues.go, line 79 [r3] (raw file):

		return defaultTimePeriod
	}
	period, ok := timePeriods[priorities[0]]

What happens if there are multiple priority labels

mungegithub/mungers/nag-flake-issues.go, line 104 [r3] (raw file):

	notif := pinger.SetTimePeriod(findTimePeriod(obj.Issue.Labels)).PingNotification(
		comments,
		mungerutil.GetIssueUsers(obj.Issue).Assignees.Mention().Join(),

Pull this out into a variable for self documenting code

Comments from Reviewable

Review status: 0 of 3 files reviewed at latest revision, 9 unresolved discussions, some commit checks failed.

mungegithub/mungers/nag-flake-issues.go, line 86 [r1] (raw file):
Previously, grodrigues3 wrote…
> probably still want to ping even if no priority set.

Done.

mungegithub/mungers/nag-flake-issues.go, line 90 [r1] (raw file):
Previously, grodrigues3 wrote…
> same

Done.

mungegithub/mungers/nag-flake-issues.go, line 107 [r1] (raw file):
Previously, grodrigues3 wrote…
> write a comment to describe the functionality of this

Done.

mungegithub/mungers/nag-flake-issues.go, line 63 [r3] (raw file):
Previously, pwittrock (Phillip Wittrock) wrote…
> Is this because it implements some interface?  If so, can you do the compile time checking thing: `var _ InterfaceType = &NagFlakeIssues{}`

Yeah, this is not something we've been doing in other mungers, but I really like that.

Comments from Reviewable

@pwittrock Updated

+lgtm

Reviewed 2 of 2 files at r3, 1 of 1 files at r4.
Review status: all files reviewed at latest revision, 5 unresolved discussions.

Comments from Reviewable

authors: apelisse grodrigues3 pwittrock


text:
Extend docs-no-retest munger to allow OWNERS

There's no point in running e2e on OWNERS file changes.
Properly, this should be renamed and use a different label - we have both "retest not required" and "...-docs-only", but the distinction seems silly to me.

This change is

/lgtm

authors: eparis k8s-reviewable thockin


text:
Use Travis to deploy Docker containers to registry on every change to master

I'd like to see deployment-manager use TravisCI to push Docker images to a Docker registry so that people using and/or testing Deployment Manager can have an expectation of consistent and up-to-date versions.
What container registry should be used to be consistent with Kubernetes proper and auxiliary Kubernetes components?

This seems related to #209

authors: sgoings vaikas-google

repo: kubernetes/deployment-manager


text:
Typo fix: occurence->occurrence

line 5444: occurence->occurrence

/ok-to-test
@AdamDang Could you amend the 2nd commit message?

authors: AdamDang idealhack

repo: kubernetes/federation


text:
fix typo metric_resolution argument

fix document of heapster argument metric_resolution

This change is

@TinySong Could you please also change --metric_resolution to --metric-resolution. As heapster command line argument will replace all _ with -.

/ok-to-test

authors: TinySong andyxning k8s-reviewable

repo: kubernetes/heapster


text:
Helm create say creating but doesnt create

Helm was installed through kubespray playbook
[root@# helm create mojo
Creating mojo
[root]# ll
total 0
[root]#
helm version
Client: &version.Version{SemVer:"v2.6.1", GitCommit:"bbc1f71dc03afc5f00c6ac84b9308f8ecb4f39ac", GitTreeState:"clean"}
Server: &version.Version{SemVer:"v2.6.1", GitCommit:"bbc1f71dc03afc5f00c6ac84b9308f8ecb4f39ac", GitTreeState:"clean"}
If I create manually and then run helm install
it says , no Charts.yaml found.

When you say

If I create manually and then run helm install

How are you creating the chart manually, and are you supplying the directory name to helm install? Can you please provide steps on how you installed the Helm client? As far as I understand kubespray it only sets up tiller which is the server-side side of helm, which is not required for helm create.
For example, you should be able to do the following:
$ git clone https://github.com/kubernetes/charts
$ helm install charts/stable/mailhog

And it should install the mailhog chart on your cluster.

I'm going to close this ticket due to inactivity, but please re-open if this still needs to be addressed. Thanks!

authors: bacongobbler rishiraaz

repo: kubernetes/helm


text:
replace FAILED deployments with helm upgrade --install --force

When using helm upgrade --install, if the first release fails, Helm will respond with an error saying that it cannot upgrade from an unknown state.
With this feature, helm upgrade --install --force automates the same process as helm delete && helm install --replace. It will mark the previous release as DELETED, delete any existing resources inside Kubernetes, then replace it as if it was a fresh install. It will then mark the FAILED release as SUPERSEDED. I did not want to make this the default behaviour of helm upgrade --install because this is a destructive operation that deletes resources in Kubernetes, and the operator should opt into and accept this behaviour.
closes #3353
refs discussion in #3437

Forward note: I'm a little iffy on marking the previous release as SUPERSEDED.

Can this be the default behaviour if there is only 1 release prior and it failed? Seems to be the most common case so far.
Beyond that, I agree with it not being the default behaviour.

Can this be the default behaviour if there is only 1 release prior and it failed? Seems to be the most common case so far.

That is good feedback, thanks @helgi. I'd be a little concerned about the behaviour being inconsistent for users though. In this case, a user can expect helm upgrade --install to "fix" the first failed release, but it will continue to fail on subsequent releases with no feedback on how to fix that. I'd kinda prefer to make it explicitly opt-in as a feature flag, but I'd love to hear any feedback on whether that's important!

Perhaps we can decide at a later date if we should do that based on others' feedback in 2.8.2. How does that sound?

Yeah, I considered the inconsistency and cringed as I wrote that message. The scenario I run into a little too often (for comfort) is engineers throwing together a new helm chart and not running it in minikube but rather putting it directly into the dev CI system (copy pasta basically), which leads to failed first deployment a lot of the time.
The user generally has no idea why it failed and why their future pushes do not fix the issue, and even when they have done the fix before (helm delete --purge) it is forgotten a lot of the time. Basically, first time deploy clumsiness UX issues.
I'm happy with deferring the decision but I did want to bring up the use case

k, addressed all comments. New stuff since the last round of reviews:

the old release finishes in state DELETED instead of state SUPERSEDED, modelling what helm install --replace would do
due to the wonky semantics of this feature flag, pre/post delete and install hooks are run, not pre/post upgrade hooks
m0ar Star Wars references in the tests for @thomastaylor312's enjoyment

Should be good for another round of reviews

Am I write in reading this as --force will only ever cause a delete and redeploy when the first deploy has failed?
so if i have a chart deployed, break it, and then upgrade it, it will be fixed, not recreated?

@bacongobbler I'm also confused regarding this change.
helm upgrade --install

if release v1 failed, release v2 will fail because the operation is considered unsafe
if release v4 succeeded and release v5 failed, release v6 will succeed based off of release v4  ?

helm upgrade --install --force

if release v1 failed, release v2 will succeed because release v1 is deleted first
if release v4 succeeded and release v5 failed, release v6 will succeed based off of release ...  ?
does it delete the pre-existing release?
does it cause downtime?

Is the --force flag safe to use all the time, expecting that it only destroys kubernetes resources when the very first release fails?

helm update --install with the --force flag automates what one would do to "fix" a failed upgrade. --force is just a helm delete && helm install --replace, and it only kicks in when the release failed to deploy. It only causes downtime if your application would go into a failed state. --force just attempts to fix it. If your application would normally upgrade gracefully, there's no downtime.

and no, it kicks in any time a release fails.

is case 2 accurate?
I'm already lost as to whether helm rolls back release versions on failure

We're still on Helm v2.7.0 because the current upgrade-over-failure behavior appears to be safer for our use case than deleting a deployment.
Our releases usually fail due to hooks, but our hooks are idempotent Jobs, so it's usually pretty safe to upgrade right over them.
If I'm understanding the new behavior correctly, I believe it would be possible for a Deployment to be deleted and for no Pods to be available to serve traffic mid-deployment if a hook failed on the previous deployment.

To answer case 2, helm upgrade --install --force will upgrade as normal, so it'll use v4 to upgrade. However, should v6 fail, that's when the --force flag kicks in and I'm not 100% sure I can recall exactly what happens. It's been a little while so I'll have to look through the code again to answer your question. Feel like looking at it together at KubeCon? :)

:+1: yep, I'm curious
looking forward to it

If I'm understanding the new behavior correctly, I believe it would be possible for a Deployment to be deleted and for no Pods to be available to serve traffic mid-release if a hook failed on the previous release.

It seems from https://github.com/kubernetes/helm/issues/3208#issuecomment-390340881 that this might be the case when using upgrade install --force.
This flag is pretty dangerous.

authors: bacongobbler helgi mcfedr stealthybox


text:
Change recorder event scheme

fixes #758

This change is

@jcmoraisjr this PR fixes the error in the event recorder

Coverage decreased (-0.05%) to 46.578% when pulling 797560ab8cdb43dbc4ea668433f6d75533b4e97a on aledbf:refactor-locks into 9bdbba42c6ce08af58109223707c047e064aa7bf on kubernetes:master.

authors: aledbf coveralls k8s-reviewable

repo: kubernetes/ingress


text:
kubectl can output object as JSON, but not as YAML.

YAML is a superset of JSON, so everything that can be output as JSON can be output as YAML (for example, it can be the same serialized JSON string).
However, kubectl fails to output some objects as YAML.
$ kubectl get wf load-predict-pipeline-logreg-d4gbj --output yaml
error: error converting JSON to YAML: %!(EXTRA *errors.errorString=yaml: control characters are not allowed)

$ kubectl get wf load-predict-pipeline-logreg-d4gbj --output json
...
                    "parameters": [
                        {
                            "name": "preprocessor-x-output",
                            "value": "�\u0003cpandas.core.frame\nDataFrame\nq\u0000)�q\u0001}q\u0002(X\u0005\u0000\u0000\u0000_dataq\u0003cpandas.core.internals.managers\nBlockManager\nq\u0004)�q\u0005(]q\u0006(cpandas.core.indexes.base\n_new_Index\nq\u0007cpandas.core.indexes.base\nIndex\nq\u0008}q\t(X\u0004\u0000\u0000\u0000dataq\ncnumpy.core.multiarray\n_reconstruct\nq\u000bcnumpy\nndarray
...

Hi @Ark-kun Can you provide a reproducible example and the version of kubectl you are using by running kubectl version?

Closing since the author did not respond. Feel free to reopen if you have more insights.
/close

authors: Ark-kun brianpursley soltysh

repo: kubernetes/kubectl


text:
Broken links

For example, http://kubernetes.io/docs/user-guide/managing-deployments/ contains a number of broken links, mostly referenced to kubectl.
Is there a way to detect all broken links?
@kubernetes/docs @pwittrock

Yup. I'll reopen #102 and pick this up again.

Fixed, thanks!

authors: janetkuo johndmulhausen pwittrock


text:
Add support for integers in Exec measurement

Using an integer as a value in Exec measurement command throws a type assertion error.
Let's parse values as strings, as expected.
GetStringArray is only used in Exec measurement, so I feel confident with changing behavior of this function.

/assign @mborsz

/lgtm
/approve
/hold
Let's wait for Monday with merge.

/unhold

authors: jprzychodzen marseel

repo: kubernetes/perf-tests


text:
Create a task page for using finalizers to control deletion

Relates to #28870
Overview
While we have a great blog post about using finalizers, we should formalize that in our docs. #28870 added a concept page for Finalizers. We should add on to that with a task to use them. Source material from the blog post + elsewhere.
/assign
/triage accepted
/sig docs
/cc @sftim

/wg api-expression

/remove-lifecycle rotten

/remove-lifecycle stale

I'm wondering what a good use case for this would be. Like, how would we structure this task? What's a scenario where this would be useful?

This task is useful for somebody implementing a Kubernetes extension or this task is useful for a cluster operator wondering about why things aren't deleting the way they expect.
Not sure which audience to focus on. Thoughts?
/remove-lifecycle rotten

This task is useful for somebody implementing a Kubernetes extension or this task is useful for a cluster operator wondering about why things aren't deleting the way they expect.
Not sure which audience to focus on. Thoughts?
/remove-lifecycle rotten

I feel like the more common use case is the cluster operator, but that reads more like a troubleshooting task no? How to identify finalizers and figure out why they're there?

Maybe a tutorial page would be better.

Yeah this would work better as a tutorial focusing on a specific scenario

/remove-lifecycle stale

/remove-lifecycle rotten

authors: sftim shannonxtreme tengqm

repo: kubernetes/website


text:
The "To" version for removed feature gate HugePageStorageMediumSize is wrong

This is a Bug Report
Problem:
At https://kubernetes.io/docs/reference/command-line-tools-reference/feature-gates-removed/ the "To" version for feature gate HugePageStorageMediumSize  is listed as 1.24, however, on kubelet 1.24.4 I get the following error log:
2022-12-15T02:57:08.113 controller-0 kubelet[1218042]: info Error: failed to set feature gates from initial flags-based config: unrecognized feature gate: HugePageStorageMediumSize
Proposed Solution:
Change the "To" version to 1.23
Page to Update:
https://kubernetes.io/docs/reference/command-line-tools-reference/feature-gates-removed/

Kubernetes Version: 1.24.4

Support for this feature gate was removed in commit 0447c48a which precedes the 1.24.0 branch.

/language en

/sig node

This feature was indeed removed from Kubernetes version 1.24.
See the PR for more details: https://github.com/kubernetes/kubernetes/pull/104120
But according to the definition of "To", there are no errors in the document.
The "To" column, if not empty, contains the last Kubernetes release in which you can still use a feature gate. If the feature stage is either "Deprecated" or "GA", the "To" column is the Kubernetes release when the feature is removed.

My bad, I overlooked the difference if the feature stage is "GA".
I would suggest though that the semantics are confusing since in some cases it's the last release where you can use it, and in some cases it's the first release where you can't use it.
Arguably it would be better for consistency if the "to" release was always the last release in which you could still use the feature gate.  That way "from" and "two" would be inclusive endpoints in all cases.

Confusingly, the other feature gate I was interested in ("TTLAfterFinished") is also GA, and shows 1.24 in the "to" field, but is still usable in 1.24.  The entry for it in kube_features.go reads:
TTLAfterFinished:                               {Default: true, PreRelease: featuregate.GA, LockToDefault: true}, // remove in 1.25

So given that the comment says "remove in 1.25" shouldn't it show 1.25 on https://kubernetes.io/docs/reference/command-line-tools-reference/feature-gates-removed/ ?

@cbf123 The comment // remove in 1.25 doesn't matter. It is a reminder to those developers. However, sometimes they simply forget to remove the gate, or in more general, they forget to land these changes. We have to check if the gate is still  there in the release-1.25 branch.

/triage not-reproducible
Please file a separate issue to report an issue with TTLAfterFinished.

/close

authors: SergeyKanzhelev cbf123 mengjiao-liu sftim tengqm