text:
Duplicate @RequestBody parameter generated with the name 'body'

Fixes #746 #257

When using version 3.1.8, the annotation @RequestHeader("Accept") still generates a body parameter which then collides with a separate @RequestBody parameter.

authors: bratwurzt ladrl

repo: kongchen/swagger-maven-plugin


text:
Variant in CASP9 can't be found by rsID search

Works if you search by the variant
http://exac.broadinstitute.org/variant/1-15832495-T-G
Although the variant is listed correctly as rs146054764, a search by the rsID returns no results

Fixed in most recent commit.

source: gharchive/issue

authors: konradjk monkollek

license: mit

license_type: permissive

license_source: bigquery


text:
Fix/remove leftover pry

And point terminal success url to production

LGTM

source: gharchive/pull-request

authors: jakolehm kke

repo: kontena/kontena

license_source: github-api


text:
Analytics service is down and the Migration Toolkit cannot be run

Brief bug description
At the time of writing this issue, the endpoint that is hit to track analytics of this library is down.
While the endpoint is likely to come back online soon, I think the CLI should run regardless and continue even if analytics cannot be tracked.
Repro steps
Run any command from migration toolkit
Expected behavior
Commands run properly regardless of analytics endpoint health.
Test environment
All environments
Additional context
A quick workaround is to manually instantiate a manager then run the command via code.
Screenshots
N/A

Thank you, I've updated the code to handle these exceptions gracefully :)

authors: Enngage nkooman-bzs

repo: kontent-ai/kontent-ai-migration-toolkit

license: MIT


text:
DOMParser is not defined

Brief bug description
Tree shaking is not applied in the case of @kontent-ai\rich-text-resolver\dist\cjs\src\parser\browser\rich-text-browser-parser.js.
Repro steps
https://github.com/kontent-ai/gatsby-packages/pull/236/files#diff-8fff385791166d8060e27ff7becf1ea3c8193ee0b83a480c5e77b0c385e5a686R99-R113

fixed as a part of #17

repo: kontent-ai/rich-text-resolver-js


text:
[BUG] Gradle analysis taking too long to complete

Is there an existing issue for this?

[X] I have searched the existing issues

Konveyor version
0.5-beta2
Priority
Critical
Current Behavior
Currently, the analysis of the tackle-testapp-public in its gradle form takes too long to complete. This might be related to this bug opened in the hub:
https://github.com/konveyor/tackle2-hub/issues/667
Expected Behavior
Gradle analysis shouldn't take too much longer than Maven analysis.
How Reproducible
Always (Default)
Steps To Reproduce
Analyze tackle-testapp-public on its main branch (Maven) and then on its gradle branch (Gradle). Compare the time it takes for both to run.
Environment
No response
Anything else?
No response

Can't reproduce anymore in the latest d/s

repo: konveyor/analyzer-lsp


text:
feat: support multi architecture image builds

Signed-off-by: Mehant Kammakomati kmehant@gmail.com

WIP: please do not merge


text:
Failure exporter framework not prescriptive enough

As seen with #211 , we need to enhance the abstract class for the failure provider to force the implementer to include app logic

Related to #225

@mpryc @mateusoliveira43 @KevinMGranger the #211 describes steps to create service-now dev account. We probably want to look at the service now failure exporter code and adjust it with the rest of the exporters.

@etsauer could you tell us what do you mean by "include app logic" ?

authors: KevinMGranger etsauer mpryc

repo: konveyor/pelorus


text:
Edit Toolbar Configuration button is ignored.

The Edit Toolbar shows up whether or not you toggle the "Turn on editor toolbar" button.
Also, when using simple text area, you have no toolbar (maybe it's always been like that?).

Thank you Mark. I will investigate.

The Edit Toolbar shows up whether or not you toggle the "Turn on editor toolbar" button.
Thank you I will investigate and back to you.

Also, when using simple text area, you have no toolbar (maybe it's always been like that?).
Yes, the simple editor has no toolbar! It is a simple text area!

issue fixed in TW-Section 1.1.1

authors: Marxsal kookma

repo: kookma/TW-Section


text:
科学上网插件对客户端设置访问控制后分流不彻底

我的nas上跑BT下载，所以我设置nas的访问控制为“不通过ss“但是一旦开启bt下载，机场端的审计记录上就会有我进行BT的下载的记录，导致我的账号有被机场封禁的可能。
我该如何设置才能让nas端与科学上网的线路彻底隔离？

我按现在网络结构猜想了一下，应该是IPv6的数据没有被过滤掉，希望更新插件对于IPv6的访问控制，谢谢

repo: koolshare/ledesoft


text:
Fixing API Spec

This PR introduces final breaking changes to the specifications and brings the API into a stable state. After that, more changes might be introduced, but not in a breaking way.
The following changes are planned (checked means ready for review)

[x] Authencation service
[x] Mood diary
[x] Wiki Service
[x] User Service
[x] Motivator Service (Starkmacher)

For those services, after merging the PR, @kopfsachen-dev/backend shall commit to not introduce any additional services in a breaking way.
⚠ Remark:
After the PR got approved, I will mark all endpoints that are not yet in a stable state in any environment as deprecated. The deprecation notice gets removed, as soon as a service is deployed in a stable state. After removing deprecation notices from all services/endpoints, the deprecated tag will be used in the intended way.

@theEpsilon: The authentication documentation is updated and I consider it finished. Please review that part.

A few things are missing:

The request body property "csrf_token": "<token>" is required in the browser flow submissions for registration and login
Each browser-related submit request (Reg, Login, Logout) needs the headers: Accept: application/json, Content-Type: application/json
Login submit flow is missing the request body definition:
{   "identifier":"<accountKey>",   "method": "password",   "password":"<md5(accountKey)>",   "csrf_token": "<token>"   }

Apart from that, auth part looks good

@theEpsilon: The authentication documentation is updated and I consider it finished. Please review that part.

A few things are missing:

Thanks you very much @theEpsilon. All of your feedback should be implemented. Could you check again? :)

Might be worth mentioning the JSON headers in every request. If they are not present, the server will send redirects which are undiserable in our use case.
Specifically those headers are required:
Accept: application/json in:

GET /self-service/registration/browser
GET /self-service/login/browser
GET /self-service/logout/browser

Content-Type: application/json in:

POST /self-service/registration
POST /self-service/login

Everything else is fine!

Cuz it seems like these header declarations are not visible in the spec visualization (?) I can see them in the code though. Everything else is fine!

In OpenAPI v3 you set the a content-type for each operations requestBody and responses. The requester has to set the HTTP Accepts and Content-Type headers accordingly. Standard compliant code generations tools should also act that way. Therefore, the x-accepts and x-contentType properties are actually not needed, i've just added them for compatibility with tools not complying fully to the open api spec. Anyway, they are not shown in the Swagger UI specifically as a requirement.
I agree that this can be misleading and added a few more words on the descriptions of the endpoints you mentioned and hope that it's clear now. Thank you for all the work you put into it :)

As I included the requested changes, this PR closes #20.

I consider the spec done and stable for 1.0 release. Please review.

Some remarks on the (semantic) versioning of the API. A major release (First of the two numbers in the version string) indicates the introduction of breaking changes, why a minor release shall be compatible to all prior versions of the API of the same major relase. Thats why i bumped the version to 1.0.

@MHajoha Many thanks for you quick review of the changes and the approval. I've implemented you're feedback :)
I request a frontend review again for the browser teams. Particularly interesting for you could be, that the browser authentication flow is now described in detail in the spec. In case of struggling with the actual implementation, you can get some inspiration from mindtastic/stagefright (credits to @theEpsilon who implemented the API connection on this demo).

lgtm

authors: Siar-Akbayin jgraeger theEpsilon

repo: kopfsachen-dev/api


text:
Minimal example doesn't seems to work

I've done this minimal example (1.0.1) and I get the following error at runtime:
import Graphics.Element exposing (..)
import Sha

main : Element
main = show (Sha.digest "hex" (Sha.createHash "hello"))

hello is not supported (we accept pull requests)

Sha.createHash accepts one of these hash algorithms: ["sha1", "sha", "sha256", "sha512"]. These are same as sha.js's supported hashes.
https://github.com/crypto-browserify/sha.js#supported-hashes
examples:

https://github.com/koyachi/elm-sha/blob/master/examples/Main.elm
https://github.com/koyachi/elm-sha/blob/master/tests/Test.elm

Ooops, really sorry I didn't quite understood the API correctly. It works like a charm.
You might be able to enforce good usage by creating data structure instead of String:
type HashType = SHA1 | SHA | SHA256 | SHA512
with
createHash : HashType -> Hash
And certainly the same for digest:
type Digest = HEX | B64 | BIN
Best,
Y.

You might be able to enforce good usage by creating data structure instead of String:
type HashType = SHA1 | SHA | SHA256 | SHA512
with
createHash : HashType -> Hash
And certainly the same for digest:
type Digest = HEX | B64 | BIN

Ah, yes. Specifying Hash Algorithm and Digest Encoding with string is not Elm-way.
I'll fix this with elm-sha Ver.1.0.2.
Thanks!

authors: koyachi yogsototh

repo: koyachi/elm-sha


text:
Update thread.rs

Tiny change to allow compilation

Didn't know people used this crate. Thanks. Won't be able to cargo publish until later however.

Would love to see the blazingly-fastness from your work get adopted into more commonly used runtimes.
Or to see this mature :)
Tempted to share how the benches look on my machine, but I'll stick to your decision of not sharing one isolated case :+1:

repo: kprotty/uasync


text:
Possible GTFS Loader Bugs

Two possible bugs with loading and embedding GTFS data with GTFS2VEC loader and embedder:

GTFSLoader uses df.pivot_table() to calculate the hourly embedding features from the static feed, which gives NaN values for hours/stops that don't have trips. For _load_trips this is filled with 0, but for _load_directions it should be an empty set, which as far as I can tell is not possible using df.pivot_table(). I handled this in GTFS2VecEmbedder by filtering NaN values as they are reduced. I also added an initial value because in a few cases there were hours with no trips at all.
GTFS2VecEmbedder expects a features GeoDataFrame with an index that matches the joint GeoDataFrame, which is checked in _validate_indexes. GTFSLoader assigns the features GeoDataFrame an index of None. I just changed it to assign the FEATURE_ID constant.

from pathlib import Path
from srai.embedders import GTFS2VecEmbedder
from srai.joiners import IntersectionJoiner
from srai.loaders import GTFSLoader, download_file
from srai.neighbourhoods.h3_neighbourhood import H3Neighbourhood
from srai.regionalizers import H3Regionalizer
import geopandas as gpd
from shapely.geometry import Polygon
from srai.constants import WGS84_CRS

# Load GTFS from example notebook
wroclaw_gtfs = Path().resolve() / "files" / "example.zip"
gtfs_url = "https://transitfeeds.com/p/mpk-wroc-aw/663/20221221/download"
download_file(gtfs_url, wroclaw_gtfs.as_posix())
gtfs_loader = GTFSLoader()
features = gtfs_loader.load(wroclaw_gtfs)

print(features.index.name) # None

# Get H3 embedding regions covering the GTFS bounding box, join with features
min_x, min_y = features.geometry.bounds[['minx', 'miny']].min()
max_x, max_y = features.geometry.bounds[['maxx', 'maxy']].max()
geo = Polygon((
    (min_x, min_y),
    (min_x, max_y),
    (max_x, max_y),
    (max_x, min_y),
    (min_x, min_y)
))
area = gpd.GeoDataFrame(
    {'region_id': ['Wroclaw_test'],
     'geometry': [geo]},
     crs=WGS84_CRS
)
area.set_index('region_id', inplace=True)
regionalizer = H3Regionalizer(resolution=8)
joiner = IntersectionJoiner()
regions = regionalizer.transform(area)
neighbourhood = H3Neighbourhood(regions_gdf=regions)
joint = joiner.transform(regions, features)

# Fit embedder
embedder = GTFS2VecEmbedder(hidden_size=2, embedding_size=4)
embedder.fit(regions, features, joint)
embeddings_gtfs = embedder.transform(regions, features, joint)

# ValueError: features_gdf must have a named index.

features.index.name = 'feature_id'
embedder = GTFS2VecEmbedder(hidden_size=2, embedding_size=4)
embedder.fit(regions, features, joint)
embeddings_gtfs = embedder.transform(regions, features, joint)

# TypeError: descriptor 'union' for 'set' objects doesn't apply to a 'float' object

Hi @zackAemmer
Thanks a lot for finding and fixing those bugs. It's a great contribution!
Everything looks good to me. I added the CHANGELOG entry and will merge and ship those changes with the next release.

Awesome!

authors: piotrgramacki zackAemmer

repo: kraina-ai/srai


text:
Setting the height-dimension in percentage does not work

I was trying to set the dimensions of the zoid by using the percentages as suggested by the docs. Setting the width to '100%' does work but whenever I change the height-dimension to a percentage, the iframe does not show up. It only works with pixels. I'm currently using Zoid in a React-environment.
Code for reference:
    dimensions: {
      width: '800px',
      height: '100%',
    },

How you did resolve this?

repo: krakenjs/zoid


text:
FR: Open in popup?

Possible feature request?
New to Statamic here and I really like this add-on. What would be really neat, is if it were possible to open the palette in a popup to select a color, then hide the palette but showing the activate color being used.
When using Bard or similar to build pay layours, the picker takes up a lot of real estate, especially if used multiple times in a layout.
Just an idea!

@minemindmedia I like this idea. I'm not sure if I'll have bandwidth for it soon, but I'll try to explore the option.

That's awesome!

@minemindmedia Hows this look? https://d.pr/v/4VvrPx

@minemindmedia Would it be better without the extra button? just show an icon to choose the color?
https://d.pr/v/addpRf

Sorry for the multiple posts... @minemindmedia what about this?
https://d.pr/v/vdnhVd

Hi @vmitchell85
Sorry for the late response! Looks great man!
I think any of those would be awesome.

repo: krakero/tailwind-fieldtype


text:
PHP Fatal error:  Uncaught GuzzleHttp\Exception\ConnectException: cURL error 7

Getting this exception in apache2 error.log:
PHP Fatal error:  Uncaught GuzzleHttp\\Exception\\ConnectException: cURL error 7: Failed to connect to oauth2.googleapis.com port 443: Connection timed out (see https://curl.haxx.se/libcurl/c/libcurl-errors.html) in /var/www/html/beta/v1/vendor/guzzlehttp/guzzle/src/Handler/CurlFactory.php:200\nStack trace:\n#0 /var/www/html/beta/v1/vendor/guzzlehttp/guzzle/src/Handler/CurlFactory.php(155): GuzzleHttp\\Handler\\CurlFactory::createRejection(Object(GuzzleHttp\\Handler\\EasyHandle), Array)\n#1 /var/www/html/beta/v1/vendor/guzzlehttp/guzzle/src/Handler/CurlFactory.php(105): GuzzleHttp\\Handler\\CurlFactory::finishError(Object(GuzzleHttp\\Handler\\CurlHandler), Object(GuzzleHttp\\Handler\\EasyHandle), Object(GuzzleHttp\\Handler\\CurlFactory))\n#2 /var/www/html/beta/v1/vendor/guzzlehttp/guzzle/src/Handler/CurlHandler.php(43): GuzzleHttp\\Handler\\CurlFactory::finish(Object(GuzzleHttp\\Handler\\CurlHandler), Object(GuzzleHttp\\Handler\\EasyHandle), Object(GuzzleHttp\\Handler\\CurlFactory))\n#3 /var/www/html/beta/v1/vendor/guzzlehttp/guzzle/src/Handler/Proxy.ph in /var/www/html/beta/v1/vendor/kreait/firebase-php/src/Firebase/Exception/DatabaseApiExceptionConverter.php on line 49
To Reproduce
I did not find why it actually happening. :(
Environment:

OS: Ubuntu 18.04,
PHP version: [e.g. 7.3.8]
Firebase SDK Version: latest

There‘s unfortunately not much I can help you with - if the request to the Google APIs fails, it could have several reasons: bad internet connection, a firewall, your IP could be blocked from accessing the services, ...

Okay, but is there any way to set custom timeout duration to the firebase requests?

https://firebase-php.readthedocs.io/en/stable/setup.html#http-client-options-and-middlewares

I am also getting the below exception.
{ 	"File": "\/var\/www\/html\/local\/vendor\/kreait\/firebase-php\/src\/Firebase\/Exception\/DatabaseApiExceptionConverter.php", 	"Line": 49, 	"Message": "Unable to connect to the API: cURL error 7: Failed to connect to oauth2.googleapis.com port 443: Connection timed out (see http:\/\/curl.haxx.se\/libcurl\/c\/libcurl-errors.html)" }
kreait/firebase:
php: 7.1
Connection code like
$serviceAccount = ServiceAccount::fromJsonFile($firebase_path);                 $firebase = (new Factory)                     ->withServiceAccount($serviceAccount)                     ->withDatabaseUri($firebase_database_path)                     ->create();                 $database = $firebase->getDatabase();
It was working fine before, but getting error from last week.

It's the same kind of error as before - on the machine the code is running on, a connection to the Google API was not possible... unfortunately that's nothing that we can fix in code.

please cheak your url。I said this because I got messages like you and found a space between “ and h....

authors: ahqmrf danyjadhav helojianxin jeromegamez

repo: kreait/firebase-php


text:
Develop

Checklist:

[ ] Have you added an explanation of what your changes do and why you'd like them to be included?
[ ] Have you updated or added documentation for the change, as applicable?
[ ] Have you tested your changes on all related environments with successful results, as applicable?

Type of Changes:

[ ] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)

What is the current behavior? (link to any open issues here)
What is the new behavior (if this is a feature change)?
Other information:

/test image

repo: krestomatio/moodle-operator


text:
Problems with continuous operation

KRProgressHUD.dismiss {}
KRProgressHUD.showImage(#imageLiteral(resourceName: "toast_error"), message:  message)

the hud can't display.

@springlo
Please use it.
KRProgressHUD.dismiss {
    KRProgressHUD.showImage(#imageLiteral(resourceName: "toast_error"), message:  message)
}

No response.

authors: krimpedance springlo

repo: krimpedance/KRProgressHUD


text:
Request: Add @lsprr As A Contributor

Add @lsprr As A Contributor For #32

@all-contributors add @Isprr for documentation

@all-contirbutors add @lsprr for doc

@all-contributors add @lsprr for doc


text:
Add gene set enrichment

If we add the ability for the user to supply a network, we should figure out how to add gene set enrichment as a page of results since model similarity won't be a thing we can do

features and issues deferred for rewrite --closing here.

authors: ChristopherMancuso billspat


text:
Zoom feature fails on delayed data load

When data is loaded after chart initializations, zoom feature fails:
Uncaught TypeError: Cannot read property 'call' of undefined angular-nvd3.js:587
Plunker:
http://plnkr.co/edit/HmfNd4NzXMFZr36YNXbm?p=preview

Thanks, I will fix it in the near future.

authors: juja krispo


text:
Export pull_layer & auth API

Export pull_blob API
1. Container images will share layers, the API should support the scenario which don't need pull all the layers.
2. Container image size may vary from megabyte to gigabyte, export pull_layer API can allow the user to the following layer decompress/unpack/store operations in parallel.
Export auth API
For some container image service which support ondemand layer pull like:
* stargz https://github.com/containerd/stargz-snapshotter
* Nydus Image Service https://github.com/dragonflyoss/image-service
export auth API is a requirement when token is expired.

I seem to remember there being a reason why these methods were not public. @bacongobbler or @radu-matei was there a reason either of you remember why these were private?

Yes - some of that conversation can be found here: https://github.com/krustlet/krustlet/pull/564

Basically the user should not be given any control over auth - we know what endpoints do and do not need authentication, so the call to auth should be hidden behind methods like pull.
As for exposing pull_layer... I don't see how this is useful unless you're trying to write an abstraction over the existing Client. It doesn't make a ton of sense because you still have no way to push or pull manifests, and push_layer is still hidden. We need to decide whether we allow others to write their own clients on top of oci-distribution, or we are the ones publishing an OCI client, exposing only the high-level concepts like client.pull() and client.push() (which is the current design today).

export pull_layer and auth API can allow the user to do the following layer decompress/unpack/store operations in parallel.

Is there a compromise we can make here? I think that should be something pull can handle. It's already async anyways.

If it helps contextualize the OP's desire, one of my hopeful use-cases when consuming this crate is a flavor/variant of https://oras.land/ - specifically with the goal of usage for smarter CI caching. This means that I may be running my caching utility in memory-constrained contexts while also dealing with up-to-multi-gigabyte payloads when considering the "image" as a whole. One of the possible optimizations under those constraints would be for me to be able to stream individual layers to decompress and write to disk during the logical pull operation, so that I never need to buffer an entire layer payload in-memory. I have an analogous desire during pushing as well due to the same memory constraints, where I wouldn't wish to hold those entire layers in-memory all at once. I'd have to know the checksum ahead of time for the push per the registry API, but that doesn't directly require me to hold the payload in memory.
Most of these ideas appear incompatible with this crate's implementation details today, which I understand has been mostly informed by krustlet's usecase and contending with much smaller WASM artifacts.
(I recognize that my goals are not inherently this project's goals and may need to find my own way as a result if the examples I've offered are not compelling-enough.)

one of my hopeful use-cases when consuming this crate is a flavor/variant of https://oras.land/ - specifically with the goal of usage for smarter CI caching.

We've discussed the idea with a few of the ORAS maintainers. They were interested in oci-distribution being the basis of a Rust client for ORAS. oras-rs imported krustlet (including oci-distribution) as a subtree project, but hasn't seen any activity since that point. I assume the goal was to copy oci-distribution as a starting point for a Rust client. If you're looking for an oras-go-alike client but for Rust, I'd ask them about their plans with that repository.
As oras-rs matures, I could see much of oci-distribution being ported over to oras-rs. Implementing the entire OCI distribution spec is one of our stated goals.

One of the possible optimizations under those constraints would be for me to be able to stream individual layers to decompress and write to disk during the logical pull operation, so that I never need to buffer an entire layer payload in-memory. I have an analogous desire during pushing as well due to the same memory constraints, where I wouldn't wish to hold those entire layers in-memory all at once. I'd have to know the checksum ahead of time for the push per the registry API, but that doesn't directly require me to hold the payload in memory.

I don't see how exposing methods like pull_image_layer and auth help you in that regard unless you're embedding Client within another Client, calling methods like auth to fetch credentials and pass that back to the exterior client. That just seems wonky. But perhaps we can decouple these methods away from the internal logic of the Client and into its own module. Kinda like how oras-go has its own standalone Copy that isn't tied to a Client struct. That might help you re-use some of oci-distribution's client logic.
We could also abstract some of the Client's methods into different Trait which would give you the high-level constraints like pull and push, then it'd be up to you to determine the underlying behaviour. That way the existing Client doesn't have to leak implementation details like pull_manifest and auth back to the caller. I'd imagine we would want to have those as separate traits so users can implement a read-only client.

can allow the user to do the following layer decompress/unpack/store operations in parallel.

Is there a compromise we can make here? I think that should be something pull can handle. It's already async anyways. Parallelizing the layer pull/unpack/store operations within pull should accomplish the same thing as what's requested here.

Yes, current pull API is already async, but we need wait all the layers are pulled before next operations. Many containers image support encrypted layers, decryption and decompression are time consuming and these operations depends on other crates which different users may have different selections.
Another reason we want export pull_layer API is many container stack support on demand pull like stargz-snapshotter, we will not pull all the layers at the beginning, and will pull the layers on demand.

I think we're in agreement here. I want to re-think the design approach though.

I don't see how exposing methods like pull_image_layer and auth could help you unless you're embedding Client within another Client, calling methods like auth to fetch credentials and pass that back to the exterior client. That just seems wonky from a design perspective. But perhaps we can decouple these methods away from the internal logic of the Client and into its own module.

Do you have an example how you plan to use auth and pull_image_layer in your project?

I think we're in agreement here. I want to re-think the design approach though.

I don't see how exposing methods like pull_image_layer and auth could help you unless you're embedding Client within another Client, calling methods like auth to fetch credentials and pass that back to the exterior client. That just seems wonky from a design perspective. But perhaps we can decouple these methods away from the internal logic of the Client and into its own module.

Would you mind weighing in on this? Do you have an example how you plan to use auth and pull_image_layer in your project? Perhaps that may help clarify your use case.

For parallel image layer data processing, we may don't need use auth API, and pull_layer API self param can not be mutable like current implementation in pull_layer API, we will do the work as below:
let mut client = Client::default();
// Authenticate when pull_manifest_and_config
let (manifest, digest, config) = client
        .pull_manifest_and_config(&reference, &RegistryAuth::Anonymous)
        .await?;

let layers = manifest.layers.into_iter().map(|layer| {
    let this = &client;
    async move {
        this.pull_layer(image, &layer.digest, &mut out).await?;
        decrypt_layer()
        decompress_layer()
        unpack_layer()
    }
});

For on demand pull, we may need auth when token is expired:
// on demand pull like when the token is expired
let op = RegistryOperation::Pull;
client
    .auth(&reference, &RegistryAuth::Anonymous, op)
    .await?;
client.pull_layer(image, &layer.digest, &mut out).await?;

We can also hiden the auth for pull_layer API like below, but the self will be mutable since token may updated, now this pull_layer API will can not used in the first senario when we want pull in parallel, any suggestions when we want support both? I found export auth and pull_layer API can do the job, but not sure whether it is the righ way:
    pub async fn pull_layer<T: AsyncWrite + Unpin>(
        &mut self,
        image: &Reference,
        auth: &RegistryAuth,
        digest: &str,
        mut out: T,
    ) -> anyhow::Result<()> {
        let op = RegistryOperation::Pull;
        if !self.tokens.contains_key(image, op) {
            self.auth(image, auth, op).await?;
        }

        self._pull_layer(image, digest, out)
            .await?;

        Ok(())
    }

    async fn _pull_layer<T: AsyncWrite + Unpin>(
         &self,

Okay. I've thought about this for a while... I'd be okay with exposing these APIs as it does not appear there's a good alternative other than a huge refactor of the crate to match the design I proposed earlier.
If you can remove all of the additional changes made to this PR and keep it to the bare minimum (marking these functions as pub), that would be appreciated. We can discuss the design decisions behind some of the other changes in another PR if you'd like to still propose those, but they appear orthogonal to the original ask.
Thanks!

For on demand pull, we may need auth when token is expired

Can't we just address that in the calling code by checking the token's expiration date? That would mean you can just call pull without having to embed auth/pull_layer yourself.

For parallel image layer data processing,

I still don't understand why this can't be handled in oci-distribution. Why does this have to be orchestrated from another library? Why can't a pull fetch multiple layers in parallel? Why does this have to be done at a higher level?

For on demand pull, we may need auth when token is expired

Can't we just address that in the calling code by checking the token's expiration date? That would mean you can just call pull without having to embed auth/pull_layer yourself.

Yes, we can do that way, but current TokenCache in client module is not public and TokenCache itself is only visible in current crate by design:
pub(crate) struct TokenCache {

For parallel image layer data processing,

I still don't understand why this can't be handled in oci-distribution. Why does this have to be orchestrated from another library? Why can't a pull fetch multiple layers in parallel? Why does this have to be done at a higher level?
We could just implement some form of middleware pattern so that pull can call a function on each layer. That way you can still call decrypt/decompress/unpack on each layer, and it'd all be performed in parallel. Would that solve your issue?
https://doc.rust-lang.org/book/ch19-05-advanced-functions-and-closures.html

Thanks for your suggestions. Yes, we can pass functions to current pull API, but we have two concerns, first is we modify the interface of an key public API, next is after we processed the layer data, the pull API return value will also need be changed based on the user's needs.

@bacongobbler  Another concern is container image layers are shared, after we pull the image manifests,  we also need check whether the host already have shared layers pulled by other containers, and we only need pulling the missed parts of the layers.
Image service/runtime are operate at image layer level and image distribution may also need export the layer related API.

Hi @bacongobbler @thomastaylor312 @flavio I rebased the PR and updated the commit message, please review.

Yeah I think this is fine for now. We should just be careful as we approach 1.0 as we decide whether or not the pull_layer function should be exported or not

I still disagree with this change in relation to oci-distribution's current API, but I don't really have the time right now to make contributions for further improvements. I'm fine with this going through for now. We can make changes to this API in future iterations since we haven't hit 1.0 yet, so there's plenty of time to refactor if necessary.
I see one code regression that I'd like to see changed. Otherwise this looks good to go.

Thanks Matt, fully agree to keep auth() clean as you requested, just updated the PR.

@thomastaylor312 and @flavio do you have any ideas/concerns about this change?

@bacongobbler This good to go from your end?

@bacongobbler @thomastaylor312 @flavio Thanks, much appreciated!

authors: arronwy bacongobbler shanesveller thomastaylor312

repo: krustlet/oci-distribution


text:
Cargoload of trains/trucks

Fix that cargo trains drive with around with really low loads of cargo. (1 - 30 %)
Automatically select appropriate vehicle for load --> a van for a small load, a truck for a large load. (i've made difference in capacity in AVO, sadly i get trucks loaded for 50%, instead of a van, loaded for 100%), while vans would probably mean faster delivery.

https://github.com/VictorPhilipp/Cities-Skylines-Traffic-Manager-President-Edition/issues/123

Duplicate of #170

Closing this as duplicate of 170


text:
Create YZEncoder class

Summary
Create YXEcnoder class, which is used in the original quclassi paper.

merged to the main branch.


text:
I want to lock global_mrb

Hi!
We implemented it because we want to lock global_mrb when using it with multithreading.
https://github.com/ksss/mruby-signal/blob/master/src/signal.c#L558
↑ code is executed at mrb_open to prevent global_mrb from being rewritten.

sample.rb

def run_with_signal msec_timer, signal
  @timer_thread = Thread.new msec_timer, 1000, signal do |timer, interval, sig|
    loop_time = 0
    # calculate by usec
    while loop_time < timer * 1000
      loop_time += usleep interval
    end
    Process.kill sig, Process.pid
  end
  Signal.mrb_state_unlock
end

Signal.trap(:USR1) do |signo|
  puts "catch signal from timer thread"
  exit
end
Signal.mrb_state_lock

run_with_signal 1000, :USR1

puts "waiting timer"
loop { sleep 1 }

@pyama86 Thank you for using this library.
Agree
This library expects to work same as CRuby's Signal.
$ cat t.rb
# mattn/mruby-thread
# matsumotory/mruby-sleep
# iij/mruby-process
def run_with_signal(signal)
  Thread.new(signal) do |sig|
    sleep 1
    Process.kill sig, Process.pid
  end
end

Signal.trap(:USR1) do |signo|
  puts "catch signal from timer thread"
  exit
end

run_with_signal :USR1

puts "waiting timer"
loop { sleep 1 }

$ mruby t.rb
waiting timer
SignalException: SIGUSR1
[2]    65470 abort      mruby t.rb

$ ruby t.rb
waiting timer
catch signal from timer thread

So, It's not expected behavior. I agree with you on this issue.
Negative
This library expects to work same as CRuby's Signal.
So, I'm negative to add methods what CRuby's Signal doesn't have.
Proposal
I admit that mruby-signal and multi mrb_state are incompatible.
So, I propose this patch.
diff --git a/src/signal.c b/src/signal.c
index 1a3da25..38b3127 100644
--- a/src/signal.c
+++ b/src/signal.c
@@ -165,7 +165,7 @@ static const struct signals {
   {NULL, 0}
 };

-static mrb_state *global_mrb;
+static mrb_state *initial_mrb = NULL;

 static const char*
 signo2signm(mrb_int no)
@@ -228,7 +228,7 @@ static sighandler_t mrb_signal(mrb_state *mrb, int signum, sighandler_t handler)
 static RETSIGTYPE
 sighandler(int sig)
 {
-  mrb_state *mrb = global_mrb;
+  mrb_state *mrb = initial_mrb;
   struct RClass *mrb_mSignal = mrb_module_get(mrb, "Signal");
   mrb_value trap_list = mrb_iv_get(mrb, mrb_obj_value(mrb_mSignal), mrb_intern_lit(mrb, "trap_list"));
   mrb_value command = mrb_ary_ref(mrb, trap_list, sig);
@@ -373,7 +373,6 @@ mrb_signal(mrb_state *mrb, int signum, sighandler_t handler)
 {
   struct sigaction sigact, old;

-  global_mrb = mrb;
   sigemptyset(&sigact.sa_mask);
   sigact.sa_handler = handler;
   sigact.sa_flags = 0;
@@ -546,6 +545,8 @@ install_sighandler(mrb_state *mrb, int signum, sighandler_t handler)

 void
 mrb_mruby_signal_gem_init(mrb_state* mrb) {
+  if (initial_mrb == NULL) initial_mrb = mrb;
+
   struct RClass *signal = mrb_define_module(mrb, "Signal");
   mrb_obj_iv_set(mrb, (struct RObject *)signal, mrb_intern_lit(mrb, "trap_list"), mrb_ary_new_capa(mrb, NSIG));

Does this solve your problem?

Yes! I will solve my problem.Rather, I want them to do so.

Would you try this? https://github.com/ksss/mruby-signal/commit/be8980cdad5e58c7526698c9c06aa90c0e3bf18d
(CI maybe relates to mruby-onig-regexp and maybe solved recently)

This worked perfectly!
Thanks.

✨

repo: ksss/mruby-signal


text:
Pointer deref crash in KSReachableOperationKSCrash

Hi,
We have recently seen a crash coming from inside the KSReachableOperationKSCrash initWithHost method. Not really sure how to reliably reproduce but seems to occasionally happen on app launch. We're using KSCrash 1.15.16 with Carthage.
Here's an example backtrace:
  0	          libobjc.A.dylib	0x1b290dd6	objc_msgSend
  1	                  KSCrash	  0xbd68cf	__60-[KSReachableOperationKSCrash initWithHost:allowWWAN:block:]_block_invoke
  2	                  KSCrash	  0xbd6503	-[KSReachabilityKSCrash onReachabilityFlagsChanged:]
  3	                  KSCrash	  0xbd6279	__49-[KSReachabilityKSCrash initWithReachabilityRef:]_block_invoke_2
  4	        libdispatch.dylib	0x1b6c9797	_dispatch_call_block_and_release
  5	        libdispatch.dylib	0x1b6c9783	_dispatch_client_callout
  6	        libdispatch.dylib	0x1b6cdd05	_dispatch_main_queue_callback_4CF
  7	           CoreFoundation	0x1bfb7d69	__CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__
  8	           CoreFoundation	0x1bfb5e19	__CFRunLoopRun
  9	           CoreFoundation	0x1bf091af	CFRunLoopRunSpecific
 10	           CoreFoundation	0x1bf08fd1	CFRunLoopRunInMode
 11	         GraphicsServices	0x1d6b3b41	GSEventRunModal
 12	                    UIKit	0x21291a53	UIApplicationMain

Here's a snippet of the report that was generated by KSCrash:
{
        "diagnosis": "Attempted to dereference garbage pointer 0x4d.",
        "error": {
            "address": 77,
            "mach": {
                "code": 1,
                "exception": 1,
                "exception_name": "EXC_BAD_ACCESS",
                "subcode": 0
            },
            "signal": {
                "code": 0,
                "code_name": "BUS_NOOP",
                "name": "SIGBUS",
                "signal": 10
            },
            "type": "mach"
        }
}

We also managed to catch it on the debugger:

At first guess, it looks like the blockSelf reference has been freed.
If this is the most likely case, would adding a guard be a sufficient solution? Happy to submit a PR to that effect if so.
Thanks,
Chris

I think should use '__weak' to replace '__unsafe_unretained' in line 320。

authors: cgwyllie iOkay

repo: kstenerud/KSCrash


text:
dev goes out of bounds on devices

In Simulation.cpp this line appears twice: auto dev = jobs[job].tasks[jobs[job].cur].device; followed by some form of devices[dev]. When stepping though however, dev is sometimes outside the bounds of devices.
Job: 3 dev: 2 size: 2
Job: 3 dev: 2 size: 2
Job: 4 dev: 2 size: 2
Job: 6 dev: 2 size: 2
Job: 3 dev: 2 size: 2
Job: 3 dev: 2 size: 2
Job: 4 dev: 2 size: 2
Job: 1 dev: 2 size: 2
Job: 9 dev: 2 size: 2
Job: 9 dev: 2 size: 2

This out of bounds dev and devices appears to be in my stack trace for a segmantation fault error in the fiforeadyqueue::next method. So I can confirm its happening.

fix:
Task.cpp : 10
std::uniform_int_distribution<> dist(low, high - 1);
Task.cpp : 37
auto max = type == cs3100::Task::Type::CPU ? maxPage : maxDevice - 1;

In my program your second fix does the trick but implementing the first fix in any combination causes seg faults in all cases. Can anybody else confirm?

I changed it, only the one from line 37 is needed

repo: ksundberg/CourseMaterials


text:
Cannot update the device post initial install

Hello
For some reason the update has stopped working. I changed the code, but even though it says it compiled and OTA pushed through ESPHome, the device is still not updated - old sensor names.
I tried deleting the device and recreating it in ESPHome, but its still the same thing - no update

What version of libretuya and what chip are you using? What board name did you choose?

turned out to be a device specific issue - if you hold the button after powering it off and then plugging back in with button pressed, it will start to use firmware. So its loading it, but not using is for some reason.
Closing the issue

This is very weird, can you tell me more about this device? Is it Realtek or Beken?

Beken

Then it's not really possible to update depending on the button presses. The bootloader should update the firmware as soon as it receives it.


text:
update etcd package

This change is

/deploy

repo: kube-HPC/hkube


text:
[Bug]: autoscaler workers not working?

Description
Hi there,
It seems I cannot create autoscaler nodepools without creating at least one non-autoscaler node? This was working in an older version.
Kube.tf file
module "kube-hetzner" {
  source = "kube-hetzner/kube-hetzner/hcloud"
  version = "2.1.0"

  initial_k3s_channel = "v1.25"

  hcloud_token = var.hcloud_token

  cluster_name = "${var.stage}-${var.region}"
  base_domain  = var.domain

  network_region     = var.region
  load_balancer_type = var.lb_type

  lb_hostname            = local.lb_hostname
  load_balancer_location = local.locations[var.region][0]

  control_plane_nodepools = [
    for cp in range(3) :
    {
      name        = "control-plane-${var.stage}-${var.region}-${cp}",
      server_type = var.cp_type,
      location    = local.locations[var.region][cp % length(local.locations[var.region])],
      labels      = [],
      taints      = [],
      count       = 1
    }
  ]

  autoscaler_nodepools = [
    for cp in range(3) :
    {
      name        = "autoscaler-${cp}"
      server_type = var.agent_type
      location    = local.locations[var.region][cp % length(local.locations[var.region])],
      min_nodes   = 0
      max_nodes   = 5
    }
  ]

  agent_nodepools = [
    {
      name        = "agent-small",
      server_type = var.agent_type
      location    = "fsn1",
      labels      = [],
      taints      = [],
      count       = 0 // working when setting to > 0
    }
  ]

  ingress_controller   = "nginx"
  use_control_plane_lb = true
  cni_plugin           = "cilium"
  enable_cert_manager  = false

  create_kubeconfig    = false
  create_kustomization = false

  ssh_public_key  = file("${var.ssh_key}.pub")
  ssh_private_key = file(var.ssh_key)

  providers = {
    hcloud = hcloud
  }

}

variable "lb_type" {
  default = "lb11"
}

variable "cp_type" {
  default = "cpx11"
}

variable "agent_type" {
  default = "cpx31"
}

locals {
  lb_hostname = "lb-${var.stage}-${var.region}.${var.domain}"

  # https://docs.hetzner.com/cloud/general/locations/
  locations = {
    "eu-central" = ["fsn1", "nbg1", "hel1"],
    "us-east"    = ["ash"],
    "us-west"    = ["hil"],
  }
}

Screenshots
No response
Platform
Mac

@stubbi You have to check the autoscaler pod logs, see what is happening.

@stubbi Was your previews try with cilium too? Try without cilium, and as started about, the key is probably in the logs of the autoscaler pod.

authors: mysticaltech stubbi


text:
Bug 1927850: Bump the github.com/gogo/protobuf dependency to v1.3.2

Ensure the github.com/gogo/protobuf dependency uses the v1.3.2 version.
This was done by running the following commands locally:
# Get the newer version of the protobuf implicit dependency.
$ go get github.com/gogo/protobuf@v1.3.2
$ go mod vendor && go mod tidy && go mod verify
# Verify the version is correctly pinned.
$ go list -mod=readonly -m all | grep gogo/protobuf
github.com/gogo/protobuf v1.3.2 => github.com/gogo/protobuf v1.3.2

/bugzilla refresh

/cherry-pick release-4.7

repo: kube-reporting/helm


text:
fix: simplify the code

Fix #128

https://go.dev/play/p/0KAEYU0Eivx
package main

import "fmt"

func main() {
	var labels map[string]string
	if labels["xxx"] != "xxx" {
		if labels == nil {
			labels = make(map[string]string)
		}
		labels["xxx"] = "yyy"
	}
	fmt.Println(labels)
}

no panic here....

maybe refactor:?

authors: Abirdcfly bjwswang dayuy

repo: kubebb/core


text:
Add Percona XtraDB Docs

Signed-off-by: Md. Alif Biswas alif@appscode.com

Before Merge

Need to update the parent repository

Folder name is updated from percona-xtradb to perconaxtradb (Got rid of the hyphen)
Codespan schema check is failing from ProxySQL end

repo: kubedb/docs


text:
Inference result is not output in lifelong learning thermal comfort case

What happened:
I correctly installed Sedna and KubeEdge. And tried running Lifelong Learning Thermal Comfort Prediction case.
I found that the pods for training and evaluation were working fine, but the inferring pod remained running and was never completed, and did not output results to the designated "/output/deployment" directory.

I looked at the log of the pod responsible for inference and no valuable information was found.
What you expected to happen:
Run this case correctly, both training and inference.
How to reproduce it (as minimally and precisely as possible):

I have written a blog including everything about installation and the running of this lifelong learning case, which can be used for reproduction.
Log of the pod responsible for inference
log of inference pod.txt

Environment:
Sedna Versionv0.5.1
KubeEdge Versionv1.10.0

My issue is similar to https://github.com/kubeedge/sedna/issues/380#issue-1452864350

@jaypume might help to take a look at it

This issue has been solved, and the reference result can be found here.
Thanks all.

authors: MooreZheng qxygxt

repo: kubeedge/sedna


text:
Implementation for injecting storage-initializer

In the #18, I proposed to add an init-containers to download dataset/models before running workers.
Then we need to inject the storage-initializer to workers.
the simply way
The obvious way to implement it is to modify the creating-worker logic in each collaboration features in GM.
I can abstract the common logic to one func/file.
its pros: simply and quick
its cons: need to modify the gm
the more decouple way
Another good way I found is to leverage the k8s admission hooks used by the kfserving.
its pros: decoupling with each collaboration features
its cons: add extra a webhook server; more code worker
What I decide to do now
For simplicity, firstly to implement the simply way, then evolute to the admission hook way when needed since injecting code can be reused.

kfserving storage-initializer implementation see this pr https://github.com/kubeflow/kfserving/pull/156.

/close
closed by #52


text:
Add gitops & metaphor repository names as flags for create

What is your feature idea?
Problem:

Gitops & metaphor repository names are hard-coded

Screenshot:

Solution:

Add --gitopsRepoName flag
Add --metaphorRepoName flag
Keep "gitops" & "metaphor" as sane defaults

Impacted files:

There might be more, just what I found off initial search

https://github.com/kubefirst/kubefirst/blob/a47ff7fa7d222555c9cd31ef066b4910368cc796/cmd/google/create.go#L66
https://github.com/kubefirst/kubefirst/blob/a47ff7fa7d222555c9cd31ef066b4910368cc796/cmd/digitalocean/create.go#L67
https://github.com/kubefirst/kubefirst/blob/a47ff7fa7d222555c9cd31ef066b4910368cc796/cmd/civo/create.go#L61
https://github.com/kubefirst/kubefirst/blob/a47ff7fa7d222555c9cd31ef066b4910368cc796/cmd/k3s/create.go#L67
https://github.com/kubefirst/kubefirst/blob/a47ff7fa7d222555c9cd31ef066b4910368cc796/cmd/akamai/create.go#L61
https://github.com/kubefirst/kubefirst/blob/a47ff7fa7d222555c9cd31ef066b4910368cc796/cmd/vultr/create.go#L68
https://github.com/kubefirst/kubefirst/blob/a47ff7fa7d222555c9cd31ef066b4910368cc796/cmd/aws/create.go#L90

Why is it needed?
Why:

maintaining multiple gitops repos for different clouds/regions
maintaining associated metaphor repos for different clouds/regions
mitigating risk of deletion when working with deletes (eg. spinning up a gitops directory on my local github to test something and then stressing that cleanup commands could nuke something on organization's github if I'm not careful)

Is this missing feature preventing you from using kubefirst?

[ ] Yes

Code of Conduct

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

Started fork: https://github.com/alechp/kubefirst/tree/feat/repository-name-flags-for-digitalocean

Still failing here:

Happy to keep exploring. Pointers to save time would be nice
Inside gitShim/init.go I see Repositories[] being referenced & looped through to check whether the repositories exist:

Updated the newRepositories here:

Noticed that the success message has a hard-coded gitops/metaphor. Which makes sense, but don't think that would impact create

I am not setting the flag with Viper in flags.go, but from what I can tell that's not necessary...? Perhaps I'm wrong

I didn't define it in apiTypes.ClusterDefinition which might be the issue (not sure how this impacts gitShim, but maybe the check that throws is being done elsewhere):

Thanks for this feature suggestion @alechp. Could you split those in two issues please as they will need different work in different places. Mainly, the gitops one will require a lot more work since it's hardcoded in multiples places.

Hey @fharper went ahead and split it into 3 issues (three requirements to enable deploying more than one gitops cluster per github organization):

https://github.com/kubefirst/kubefirst/issues/2210
https://github.com/kubefirst/kubefirst/issues/2211
https://github.com/kubefirst/kubefirst/issues/2212

Thanks a lot, and sorry for the additional work 😅
Will close this one now.

authors: alechp fharper

repo: kubefirst/kubefirst


text:
Add VaniHaripriya as a Kubeflow Member

Resolves #719
Contributions

https://github.com/kubeflow/pipelines/pull/11300
https://github.com/kubeflow/pipelines/pull/11295
https://github.com/kubeflow/pipelines/pull/11262
https://github.com/kubeflow/pipelines/pull/11066

pytest Output:
$ pytest test_org_yaml.py
============================================================================================================ test session starts =============================================================================================================
platform linux -- Python 3.11.9, pytest-7.4.3, pluggy-1.3.0
rootdir: /home/vmudadla/OpenshiftAI/internal-acls/github-orgs
collected 1 item

test_org_yaml.py .                                                                                [100%]

============================================================================================================= 1 passed in 0.15s ==============================================================================================================

Make sure to sign off your commit @VaniHaripriya :)

cc @terrytangyuan

/ok-to-test

authors: DharmitD VaniHaripriya hbelmiro

repo: kubeflow/internal-acls


text:
KEP-2170: Adding validation webhook for v2 trainjob

Adds validation webhook for v2 trainjob

What this PR does / why we need it:
Which issue(s) this PR fixes (optional, in Fixes #<issue number>, #<issue number>, ... format, will close the issue(s) when PR gets merged):
Fixes #
Checklist:

[ ] Docs included if any changes are user facing

cc @tenzen-y @andreyvelich

Pull Request Test Coverage Report for Build 11522449031
Details

6 of 6 (100.0%)  changed or added relevant lines in 1 file are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 100.0%

Totals

Change from base Build 11507477280:
0.0%

Covered Lines:
78

Relevant Lines:
78

💛  - Coveralls

authors: akshaychitneni coveralls

repo: kubeflow/training-operator


text:
Install Kubeflow on OpenShift

The Link
(https://raw.githubusercontent.com/opendatahub-io/manifests/v1.3-branch/distributions/kfdef/kfctl_openshift_v1.3.0.yaml).
on page
https://www.kubeflow.org/docs/distributions/openshift/install-kubeflow/
is dead. 404. Seemls like the closing bracket got included in the link somehow.

@nakfour have you seen this issue on the OpenShift Docs ?
/platform Openshift
/priority p2
/kind bug

@kilmarnock thanks for filing this. We'll get it fixed.
@nakfour I'll fix the broken link, but I wanted to check in to see whether we should go ahead and update this page for Kubeflow 1.4.

authors: jbottum kilmarnock shannonbradshaw

repo: kubeflow/website


text:
mysql Backup&Restore procedure

Hey,
we are trying to restore kubeflow mysql db. Is a mysql dump enogh to backup?
we are dealing with the current error after restore:
Error: failed to generate Pipeline graph.
An error occurred
Cannot read property 'spec' of undefine

/assign @IronPan

I found that if I add a pipeline, backup the mysql DB, delete the pipeline then restore, that pipeline will return the erro above.
all the other pipelines, which were not deleted, just backed and restored, are ok.

Hey guys, any suggestions?
I need to know what that delete button does when a pipeline is deleted.
Because it's sure deletes more than something in mysql.
In this way I can prepare some consistent backups.
TY
//George

/cc @paveldournov Do you have any suggestions for this problem? Many thanks, Sarah

Hey Sarah, thank you, that would be really helpful to find out the missing dependency when we delete a pipeline

just to double check did you follow up this instruction or some other ways
https://www.kubeflow.org/docs/pipelines/upgrade/

aha, so I can get a backup of all pipeline with Reinstalling Kubeflow Pipelines ?
I just did a mysql dump, deleted a pipeline, and restore the dump, and I saw the delete pipeline is not consistent after restore.

authors: IronPan sarahmaddox xaoo


text:
update Argo Executors link

fix issue https://github.com/kubeflow/website/issues/2901

/assign @RFMVasconcelos

cc @RFMVasconcelos

cc @RFMVasconcelos

сс @Bobgy

Thank you @Arhell!
/lgtm
/approve

authors: Arhell Bobgy


text:
Update docs for MXNet Jobs

Fix issues in existing doc. Address part of https://github.com/kubeflow/website/issues/2915
/cc @johnugeorge @andreyvelich

/lgtm

authors: Jeffwan johnugeorge


text:
Fixed assumption that KFAPP variable includes path

Fixes https://github.com/kubeflow/website/issues/422

This change is

Preview: https://deploy-preview-774--competent-brattain-de2d6d.netlify.com/docs/gke/cloud-filestore/

/assign @joeliedtke

/lgtm
/approve

/approve cancel

/lgtm cancel

/approve

authors: joeliedtke sarahmaddox


text:
Update Kong http-trigger configuration

Issue Ref: None
Description:
Update Kong http-trigger documentation to use new CRDs for Consumers and Credentials.
This removes the need to make HTTP requests to the admin API.
TODOs:

[X] Ready to review

awesome, thanks @aledbf

authors: aledbf andresmgot

repo: kubeless/kubeless


text:
ignore pod not scheduled when reconcile subnet

What type of this PR

Bug fixes

1、when reconcile subnet, all pods in this subnet will be checked and add to port-group. Should ignore pod which has not been scheduled to node.
2、 This is caused by https://github.com/kubeovn/kube-ovn/pull/1655
Which issue(s) this PR fixes:
Fixes #(issue-number)

已回合release-1.10 和 release-1.9 分支

repo: kubeovn/kube-ovn


text:
fix checkSBBindings error when hostname is not nodeName

in some case the k8s spec.nodeName is not same with a hostname,
then the sbctl could not get the chassis uuid, the check process
will fail here.
A workaroud solution is that try to get chassis name first from encap
table and then do the left lookup.
It is not a good solution. When we use a second nic and change the encap
ip to the second nic, it could not work either.
Signed-off-by: Wan Junjie wanjunjie@bytedance.com

The start-ovs.sh will use nodeName to set the hostname in ovn-sb. They should be same in theory
https://github.com/kubeovn/kube-ovn/blob/8c5ae3131711a350852aadc5aaefd6522123bccf/dist/images/start-ovs.sh#L100

@oilbeater you are right，will do that. Close.

authors: junka oilbeater


text:
Connection refused for k8s api

Currently getting this error. Wondering if there's another setup to be aware
    "kuberhealthy/pod-restarts": {
      "OK": false,
      "Errors": [
        "Get https://172.20.0.1:443/api/v1/events?fieldSelector=type%3DWarning: dial tcp 172.20.0.1:443: connect: connection refused"
      ],
      "RunDuration": "",
      "Namespace": "kuberhealthy",
      "Node": "",
      "LastRun": "2021-08-20T16:31:28Z",
      "AuthoritativePod": "kuberhealthy-55d8dc7cff-zp8mj",
      "uuid": "d15d798a-385b-4a9c-bcf7-4941dad5e11d"
    },

Hello @pragmaticivan, could you please provide what Cluster OS, k8s version, and pod-restarts version you are using?

pod-restarts version: kuberhealthy/pod-restarts-check:v2.5.0
Server Version: version.Info{Major:"1", Minor:"17+", GitVersion:"v1.17.17-eks-087e67", GitCommit:"087e67e479962798594218dc6d99923f410c145e", GitTreeState:"clean", BuildDate:"2021-07-31T01:39:55Z", GoVersion:"go1.13.15", Compiler:"gc", Platform:"linux/amd64"}

This seems like a generic 'kubernetes client could not talk to the Kubernetes API' error.  I am not sure Kuberhealthy code could cause this one... Maybe there is a NetworkPolicy in place somewhere?

authors: integrii jonnydawg pragmaticivan

repo: kuberhealthy/kuberhealthy


text:
Install cri-tools on Amazon Linux 2

What this PR does / why we need it:
Amazon Linux 2 doesn't install crictl by default. We use crictl to restart the API server if it's affected by #1222. Additionally, kubeadm verifies is crictl present if containerd is used.
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 #1281
Does this PR introduce a user-facing change?:
Install cri-tools (crictl) on Amazon Linux 2. This fixes the issue with provisioning Kubernetes and Amazon EKS-D clusters on Amazon Linux 2

/assign @kron4eg

/hold
to manually test the changes

/retest

/retest
/hold cancel

/cherrypick release/v1.2

repo: kubermatic/kubeone


text:
Reconcile DynamicWorkers

Which issue(s) this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close the issue(s) when PR gets merged):
xref #531
Does this PR introduce a user-facing change?:
NONE

/assign @kron4eg

/close
We'll take another approach to this.


text:
What's the future of this client and how does it compare to pykube?

I'm currently using this client for my Kubernetes Operational View dashboard, but I will probably switch to pykube as it looks much cleaner (e.g. config loading does not modify a global object), directly uses requests (which I'm using too) and supports insecure-skip-tls-verify (see #99).
Did you consider merging this client with pykube or what are compelling arguments to use client-python instead of pykube?

Most part of this client is auto-generated. That distinguish it from pykube. Generating it make it easier for us to keep it in sync with API changes in main repo.
Having said that, I have no problem supporting features of pykube here if I get time or get somebody contributes.
About your specific concerns, our config loader has a version to load configs in a local config object instead of global one (and there is an example for that in examples folder). I plan to support insecure-skip-tls-verify when I got time. I considered using requests instead of what we have right now (urllib3) but didn't see compelling reasons yet to spend time on it.

@mbohlool thanks for the quick answer :smile:

Sure.

authors: hjacobs mbohlool

repo: kubernetes-incubator/client-python


text:
Should provide other ways to specify the scaling target beside name.

As the scaling target's name could be changed, autoscaler should provide other ways for user to specify what the target is. One candidate would be label selector.
Take kube-dns as an example, we could use label k8s-app: kube-dns to select the target ReplicationController/Deployment, and don't need to restart autoscaler to change the input argument everytime when the target name is changed.

I think this is a much-needed feature. We have a cluster with multiple nodepools and we would like to scale independently for each of these node pools. Having a label selector to filter the number of nodes allows for scaling in such scenarios.

@vijaygos For you use case, is that https://github.com/kubernetes-incubator/cluster-proportional-autoscaler/pull/55 (filter node based on labels)?

Yes. This would work. I just realized that the change  went in recently.
Thanks for adding that. Much appreciated.

@vijaygos In case you don't want to build it from head, I will publish a new image includes that change very soon.

Would it be possible for you to comment on your timeline for a formal release?

@vijaygos I just did --- images below should be available now:

k8s.gcr.io/cluster-proportional-autoscaler-amd64:1.5.0
k8s.gcr.io/cluster-proportional-autoscaler-arm:1.5.0
k8s.gcr.io/cluster-proportional-autoscaler-arm6464:1.5.0
k8s.gcr.io/cluster-proportional-autoscaler-ppc64le:1.5.0

Awesome! Thanks@MrHohn for the quick turnaround.

authors: MrHohn vijaygos


text:
grpc crash when trying to start a pod

This happens on master if you just try to start a pod with one of the tesdata configurations:
% sudo ./ocid --debug
E1220 01:21:23.830356     990 ocicni.go:136] error updating cni config: No networks found in /etc/cni/net.d
DEBU[2016-12-20 01:21:23.831441299+11:00] sandboxes: map[]
DEBU[2016-12-20 01:21:23.831471271+11:00] containers: &{map[] {{0 0} 0 0 0 0}}
DEBU[2016-12-20 01:21:27.103103358+11:00] RunPodSandboxRequest config:<metadata:<name:"podsandbox1" uid:"redhat-test-ocid" namespace:"redhat.test.ocid" attempt:1 > hostname:"ocic_host" log_directory:"." port_mappings:<protocol:UDP container_port:80 host_port:4888 host_ip:"192.168.0.33" > port_mappings:<protocol:2 container_port:81 host_port:4889 host_ip:"192.168.0.33" > labels:<key:"group" value:"test" > annotations:<key:"owner" value:"hmeng" > annotations:<key:"security.alpha.kubernetes.io/seccomp/pod" value:"unconfined" > annotations:<key:"security.alpha.kubernetes.io/sysctls" value:"kernel.shm_rmid_forced=1,net.ipv4.ip_local_port_range=1024 65000" > annotations:<key:"security.alpha.kubernetes.io/unsafe-sysctls" value:"kernel.msgmax=8192" > linux:<cgroup_parent:"/ocid-podsandbox1" security_context:<namespace_options:<host_network:false host_pid:false host_ipc:false > > > >
DEBU[2016-12-20 01:21:27.105374620+11:00] copying infra rootfs binary: /usr/libexec/ocid/pause -> /var/lib/ocid/graph/vfs/pause/rootfs/pause
2016/12/20 01:21:27 grpc: Server failed to encode response proto: Marshal called with nil

With the key command being:
% sudo ./ocic pod run --config test/testdata/sandbox_config.json
2016/12/20 01:21:27 transport: http2Client.notifyError got notified that the client transport was broken EOF.
2016/12/20 01:21:27 grpc: addrConn.resetTransport failed to create client transport: connection error: desc = "transport: dial unix /var/run/ocid.sock: connect: connection refused"; Reconnecting to {"/var/run/ocid.sock" <nil>}
FATA[0000] Creating the pod sandbox failed: rpc error: code = 13 desc = transport is closing

.. looking .. (thanks)

I'm bisecting right now. Gimme a sec. :P

Can't reproduce on master though :confused:

No networks found in /etc/cni/net.d

maybe caused by missing cni networks?

@runcom Okay, it just started working again. I had to fix up ocid.conf to correctly refer to the right binaries (this was a new box).
Looks like it's a configuration issue, but I'm confused why I got that error which then crashed the daemon. Seems like a really nasty failure mode.

Looks like it's a configuration issue, but I'm confused why I got that error which then crashed the daemon. Seems like a really nasty failure mode.

welcome to grpc nil marshaling

@runcom It's also caused when conmon exits with a non-zero exit code. I hit it with #162 (which I've since fixed) when it would crash due to the log path being wrong.

I just met the same issue on the master.
# git log -1
commit 6133465e420d387c977271111a3e1bccc316ac08
Merge: ac7943c 8e1af36
Author: Mrunal Patel <mrunal@me.com>
Date:   Wed Dec 21 11:20:08 2016 -0800

    Merge pull request #292 from sameo/topic/network-bats

    Additional networking tests

The issue can be reproduced by running two ocid process on the latest branch.
Steps:

Start ocid by systemd, # systemctl start ocid
Run ocid in terminal, # ocid --debug
Run ocic will hit the issue.

@cyphar @gouyang is this still an issue?

I can still hit the issue by the steps I described above.

@gouyang Still an issue?

The issue is gone on the master.

authors: cyphar feiskyer gouyang rhatdan runcom

repo: kubernetes-incubator/cri-o


text:
[1.11] Update ocicni to latest

Signed-off-by: Mrunal Patel mrunalp@gmail.com

/test all

LGTM assuming happy tests

LGTM

authors: TomSweeneyRedHat mrunalp rhatdan


text:
flex: Add PV name to delete

PV name is required even when deleting as much as provisioning.
I added the PV Name to the Delete function in the same way as the provision.go source.
This is the tested output.
2018-07-31 07:29:33 flex[37]: delete() called: {"kubernetes.io/pvOrVolumeName":"pvc-6e9b3727-9493-11e8-afe6-525400d87180"}
2018-07-31 07:29:33 flex[37]: log() called: {"status": "Success"}

/lgtm

repo: kubernetes-incubator/external-storage


text:
[draft] Release v2.1.0 proposal

https://github.com/kubernetes-incubator/kargo/releases/tag/v2.1.0

Here's a list of changes to add:
We need to move rkt to experimental feature list. It's not the default deployment type. And it only works right now with Flannel/Canal
We upgraded etcd to v3.0.12
Other noteworthy changes:
Added the nginx proxy to provide k8s apiserver HA
Removed the etcd-proxy
Improved docker container download and sync
Improved scale deployment time
Enabled fact caching by default
Added optional SSH bastion configuration

@mattymo note that in Kargo etcd_version: v3.0.6

Oops we should update it soon, but it's not a blocker for release

@mattymo thanks, updates done

authors: bogdando mattymo

repo: kubernetes-incubator/kargo


text:
update docs/conversion.md

docs/conversion.md is slightly out of the for example tmpfs is as unsupported

we can close this now

done

authors: kadel surajnarwade

repo: kubernetes-incubator/kompose


text:
Change menu to left side

This commit changes the menu to the left side rather than on top,
syncing with cdrage/minimal branch / style.

This syncs to the changes I made upstream at https://github.com/cdrage/minimal
It will now look like this:

this looks cool, LGTM :+1:

authors: cdrage surajnarwade


text:
Retry on 504 errors when fetching Container Linux AMIs

Closes #440

Codecov Report

Merging #442 into master will increase coverage by 0.08%.
The diff coverage is 100%.

@@            Coverage Diff             @@
##           master     #442      +/-   ##
==========================================
+ Coverage   40.79%   40.88%   +0.08%
==========================================
  Files          37       37
  Lines        2662     2666       +4
==========================================
+ Hits         1086     1090       +4
  Misses       1418     1418
  Partials      158      158

Impacted Files
Coverage Δ

coreos/amiregistry/reliable_http.go
82.35% <100%> (+5.42%)
:arrow_up:

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update cc7e1da...c9da13c. Read the comment docs.

authors: codecov-io mumoshu

repo: kubernetes-incubator/kube-aws


text:
Add azure-container-registry-config for Azure

Seperated out KUBELET_CLOUDPROVIDER env var assignment when cloud_provider equals azure
Appended azure-container-registry-config parameter

Please sign CLA

Signed CLA

/check-cla

it can be that CLA is signed with different e-mail than commit is done?

/check-cla

ci check this

can you please rebase

/lgtm

/approve

authors: Atoms gitphill mattymo

repo: kubernetes-incubator/kubespray


text:
Add zsh completion to svcat

closes: #1912
This is my first PR for svcat.
Issue 1912 requires two steps to close:

[x] 1. bump spf13/cobra to 0.0.1 (or above)
[x] 2. add zsh completion - zsh completion for svcat is added

Hi @carolynvs  I wasn't able to get the GenZshCompletion() working a few iterations back so I ended up implementing the kubectl / helm way (which does indeed work).
As requested I re-implemented using cobra's GenZshCompletion.  It doesn't seem to be working for me still but you can pull and try it. We can always revert back to the previous change if you confirm using GenZshCompletion() is no good.

@carolynvs

yes!
svcat get b actually has two options: bindings and brokers. so can confirm:
svcat get b --> shows on next line:  bindings  brokers
svcat get bi --> svcat get bindings
svcat get br --> svcat get brokers

LGTM, but I'll let folks from another org give the final LGTM label

authors: arschles kikisdeliveryservice

repo: kubernetes-incubator/service-catalog


text:
CloudStackMachine could not be deleted when using invalid serviceOffing

/kind bug
What steps did you take and what happened:
[A clear and concise description of what the bug is.]
E2E testing detects a bug that when invalid serviceOffering is configured to create CloudStackMachine. This CloudStackMachine could not be deleted due to missing instanceID.
What did you expect to happen:
CloudStackMachine should be deleted successfully without stopping cluster deletion.
Anything else you would like to add:
[Miscellaneous information that will assist in solving the issue.]
This is for admin doc purpose, a PR had been created to address this:https://github.com/kubernetes-sigs/cluster-api-provider-cloudstack/pull/201
Environment:

Cluster-api-provider-cloudstack version:
Kubernetes version: (use kubectl version):
OS (e.g. from /etc/os-release):

This issue seems to be addressed by #201 already. Does it need to stay open?

authors: hrak wanyufe


text:
symlink Permission denied occurs when pull using the Crictl command

What happened:
When using docker pull, the image is pulled normally, but when using Crictl to pull the image, the following symlink permission denied error occurs.
$sudo crictl pull  docker.io/calico/node:v3.25.1
DEBU[0000] get image connection
DEBU[0000] PullImageRequest: &PullImageRequest{Image:&ImageSpec{Image:docker.io/calico/node:v3.25.1,Annotations:map[string]string{},},Auth:nil,SandboxConfig:nil,}
E0917 23:55:07.345848   21476 remote_image.go:171] "PullImage from image service failed" err="rpc error: code = Unknown desc = failed to pull and unpack image \"docker.io/calico/node:v3.25.1\": failed to extract layer sha256:b1d7f02a32791d579abb161bccbf82ba1deaa7fb57805c93e84ddd30f0cb9560: mount callback failed on /var/lib/containerd/tmpmounts/containerd-mount3830924437: symlink /usr/lib/systemd/system/reboot.target /var/lib/containerd/tmpmounts/containerd-mount3830924437/etc/systemd/system/ctrl-alt-del.target: permission denied: unknown" image="docker.io/calico/node:v3.25.1"
FATA[0001] pulling image: rpc error: code = Unknown desc = failed to pull and unpack image "docker.io/calico/node:v3.25.1": failed to extract layer sha256:b1d7f02a32791d579abb161bccbf82ba1deaa7fb57805c93e84ddd30f0cb9560: mount callback failed on /var/lib/containerd/tmpmounts/containerd-mount3830924437: symlink /usr/lib/systemd/system/reboot.target /var/lib/containerd/tmpmounts/containerd-mount3830924437/etc/systemd/system/ctrl-alt-del.target: permission denied: unknown

What you expected to happen:
The docker image should pull normally.
How to reproduce it (as minimally and precisely as possible):
$ sudo crictl pull  docker.io/calico/node:v3.25.1
Anything else we need to know?:
Environment:

Container runtime or hardware configuration:

OS (e.g: cat /etc/os-release):
NAME="CentOS Linux"
VERSION="7 (Core)"
ID="centos"
ID_LIKE="rhel fedora"
VERSION_ID="7"
PRETTY_NAME="CentOS Linux 7 (Core)"
ANSI_COLOR="0;31"
CPE_NAME="cpe:/o:centos:centos:7"
HOME_URL="https://www.centos.org/"
BUG_REPORT_URL="https://bugs.centos.org/"
CENTOS_MANTISBT_PROJECT="CentOS-7"
CENTOS_MANTISBT_PROJECT_VERSION="7"
REDHAT_SUPPORT_PRODUCT="centos"
REDHAT_SUPPORT_PRODUCT_VERSION="7"

Kernel (e.g. uname -a):
Linux 3.10.0-1160.59.1.el7.x86_64 #1 SMP Wed Feb 23 16:47:03 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux

Others:

Docker version 24.0.6, build ed223bc
containerd containerd.io 1.6.22 8165feabfdfe38c65b599c4993d227328c231fca
crictl version v1.26.0
kubernetes-cni   1.2.0-0
kubeadm  1.28.2-0
kubectl   1.28.2-0
kubelet  1.28.2-0

Hey @byeong0, thank you for the report! This looks like an issue with containerd rather than cri-tools.

I checked on Containerd 1.6.18 and sudo crictl pull docker.io/calico/node:v3.25.1 worked. Can you check with ctr with verbose logging? Is there an issue with any other images?

/close
to continue on this, please open the bug in Containerd repository or ask at Containerd slack for support.

authors: SergeyKanzhelev byeong0 saschagrunert

repo: kubernetes-sigs/cri-tools


text:
Switch from glog to klog

#695 is WIP, but this switch to use klog is needed in order to enable webhook dependencies in a follow-up PR.
Posting on behalf of @pmorie who did the work.
Fixes #694

@font I guess neither you nor @pmorie noticed that @poothia had already started work on this, and that I made the following suggestion:
https://github.com/kubernetes-sigs/federation-v2/pull/695#issuecomment-477244315

@font I guess neither you nor @pmorie noticed that @poothia had already started work on this in #695?
@poothia fyi, you can close yours.

@marun I made a comment about it that it looks like it is WIP and hasn't been updated recently. It's not my intent to take the work from @poothia (apologies!), it was more to see it through since a follow-up PR for the webhook framework which depends on it is forthcoming.

@marun @xunpan I've pushed a commit that reorders things based on our converged convention. We should really document that in the development guide.

Thanks @font and @pmorie!
/lgtm

authors: font marun


text:
GRPCRoute timeout - GEP-3139

What type of PR is this?
/kind gep
What this PR does / why we need it:
Staying consistent with the HTTPRoute timeout feature, opening a GEP to allow for GRPCRoute timeouts
Which issue(s) this PR fixes:

Fixes # https://github.com/kubernetes-sigs/gateway-api/issues/3139
Does this PR introduce a user-facing change?:

cc @robscott @arkodg

thanks for authoring this GEP @xtineskim and @gnossen for reviewing this in depth !
thinking out loud for gRPC timeouts, thoughts on the below semantics for GRPCRoute ?

If no timeout section is defined,  rely on grpc-timeout header for deciding a per request timeout https://github.com/grpc/grpc/blob/master/doc/PROTOCOL-HTTP2.md#requests
timeouts.maxStreamDuration which overrides grpc-timeout header timeout and instead enforces a HTTP/2 stream duration timeout

Thanks @arkodg 😄 !
for your point here:

timeouts.maxStreamDuration which overrides grpc-timeout header timeout and instead enforces a HTTP/2 stream duration timeout
I wonder if this should be the opposite - if a request were to propagate to another service, could it just continually be growing in duration 🤔

Thanks @arkodg 😄 ! for your point here:

timeouts.maxStreamDuration which overrides grpc-timeout header timeout and instead enforces a HTTP/2 stream duration timeout

I wonder if this should be the opposite - if a request were to propagate to another service, could it just continually be growing in duration 🤔

i meant the timeouts.maxStreamDuration would override the timeout value defined in the header, but not overwrite the grpc-timeout header itself

/remove-lifecycle stale

authors: arkodg mikemorris xtineskim

repo: kubernetes-sigs/gateway-api


text:
Another round of v1alpha2 cleanup

What type of PR is this?
/kind cleanup
What this PR does / why we need it:
This takes care of another big chunk of feedback from #780 as well as some of the items in #790.
Does this PR introduce a user-facing change?:
* "Controller" has been renamed to "ControllerName"
* "Admitted" condition has been renamed to "Accepted" and now defaults to an "Unknown" state instead of "False"

@youngnick @hbagdi @howardjohn Thanks for the great feedback on this! I think I've responded to everything, PTAL.

I think you got it @robscott, nice work.
/lgtm
/hold
for another lgtm though.

Just a couple of formatting nits.
/lgtm

/lgtm
/hold cancel

authors: jpeach robscott youngnick


text:
Correct kpng api subcommand

subcommands are conflicting, and I spent like 3 hours to figure out why :P

do not merge yet, forgot another part here :/

/close

will fix other things here before :D

repo: kubernetes-sigs/kpng


text:
Remove static headerfiles

Remove static headerfiles and instead rely on
UAPI from https://github.com/libbpf/libbpf/tree/master/include/uapi/linux
bpf helpers from https://github.com/libbpf/libbpf/tree/master/src
from libbpf version v0.8.0
Add new make target which handles downloading these headers if needed

/hold
I want to get some more opinions before merging this

/un-hold

/remove hold

/unhold

/lgtm

authors: astoycos dougsland


text:
update(docs): update readme to explain what it is briefly

What type of PR is this?

/kind documentation
What this PR does / why we need it:
update docs to explain what it is briefly
Which issue(s) this PR fixes:

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

Sorry, opened it because I wanted to check the bot's behavior. Actually, it's WIP yet.
/hold

/kind documentation
/unhold

/label tide/merge-method-squash

PTAL @kerthcet @codefromthecrypt

@kerthcet could you check this one again please?

/lgtm
/label tide/merge-method-squash

authors: kerthcet sanposhiho


text:
Updates wazero to 1.2.1

What type of PR is this?
/kind cleanup
What this PR does / why we need it:
We're constantly tracking performance concerns and updating to the latest wazero release makes notable improvements without any change to the guest.
Which issue(s) this PR fixes:
Special notes for your reviewer:
Performance related changes in the latest patch were thanks to @ncruces
Does this PR introduce a user-facing change?
NONE
What are the benchmark results of this change?
goos: darwin
goarch: arm64
pkg: sigs.k8s.io/kube-scheduler-wasm-extension/internal/e2e
                                               │  v1.2.0.txt  │            v1.2.1.txt             │
                                               │    sec/op    │   sec/op     vs base              │
PluginFilter/noop-wat/params:_small-12           267.4n ±  2%   257.6n ± 4%  -3.65% (p=0.024 n=6)
PluginFilter/noop-wat/params:_real-12            270.4n ±  1%   270.1n ± 1%       ~ (p=0.623 n=6)
PluginFilter/noop/params:_small-12               333.2n ±  1%   329.2n ± 0%  -1.19% (p=0.002 n=6)
PluginFilter/noop/params:_real-12                337.0n ±  0%   336.2n ± 1%       ~ (p=0.701 n=6)
PluginFilter/test/params:_small-12               6.770µ ±  0%   6.279µ ± 0%  -7.25% (p=0.002 n=6)
PluginFilter/test/params:_real-12                122.6µ ±  5%   114.7µ ± 1%  -6.51% (p=0.002 n=6)
PluginScore/noop-wat/params:_small-12            256.2n ±  2%   257.8n ± 0%       ~ (p=0.327 n=6)
PluginScore/noop-wat/params:_real-12             260.2n ±  1%   260.6n ± 2%       ~ (p=0.331 n=6)
PluginScore/noop/params:_small-12                374.0n ±  1%   375.4n ± 1%       ~ (p=0.626 n=6)
PluginScore/noop/params:_real-12                 343.2n ±  1%   348.3n ± 1%  +1.49% (p=0.004 n=6)
PluginScore/test/params:_small-12                3.786µ ±  1%   3.604µ ± 0%  -4.82% (p=0.002 n=6)
PluginScore/test/params:_real-12                 43.48µ ± 16%   46.18µ ± 1%       ~ (p=0.394 n=6)
PluginFilterAndScore/noop-wat/params:_small-12   378.8n ±  3%   376.1n ± 1%       ~ (p=0.061 n=6)
PluginFilterAndScore/noop-wat/params:_real-12    382.1n ±  1%   380.9n ± 0%       ~ (p=0.074 n=6)
PluginFilterAndScore/noop/params:_small-12       576.7n ±  1%   578.0n ± 1%       ~ (p=0.260 n=6)
PluginFilterAndScore/noop/params:_real-12        543.1n ±  1%   543.4n ± 0%       ~ (p=0.509 n=6)
PluginFilterAndScore/test/params:_small-12       10.62µ ±  0%   10.06µ ± 1%  -5.23% (p=0.002 n=6)
PluginFilterAndScore/test/params:_real-12        176.5µ ±  0%   168.0µ ± 1%  -4.80% (p=0.002 n=6)
geomean                                          1.450µ         1.429µ       -1.48%

/lgtm

authors: codefromthecrypt sanposhiho


text:
Fix Flaky test: Kueue when Creating a Job With Queueing [It] Should unsuspend a job and set nodeSelectors

What type of PR is this?
/kind bug

What this PR does / why we need it:
Create const LongTimeout for e2e test.
Pods in test sometimes takes long time because of the image pulling.
Which issue(s) this PR fixes:

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

NONE

/ok-to-test

/approve
+1 on @mimowo's suggestion

There is another flaky test: https://github.com/kubernetes-sigs/kueue/issues/1027
/retest

At this point I think it is better to implement pre-pull. I will open an Issue

authors: BinL233 alculquicondor mimowo tenzen-y

repo: kubernetes-sigs/kueue


text:
Add dependabot npm configuration for the site directory.

What type of PR is this?
/kind cleanup

What this PR does / why we need it:
Add dependabot npm configuration for the site directory.
Which issue(s) this PR fixes:

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

NONE

/cc @tenzen-y @mimowo

/lgtm
Thanks!

/approve

authors: mbobrovskyi mimowo


text:
Update latest version to v0.8.3

What type of PR is this?
/kind documentation
What this PR does / why we need it:
Which issue(s) this PR fixes:

Part-of https://github.com/kubernetes-sigs/kueue/issues/3441
Special notes for your reviewer:
Does this PR introduce a user-facing change?

NONE

/hold for official release
/assign @mimowo

/cherry-pick website

/hold cancel

/lgtm
/approve

authors: mimowo tenzen-y


text:
Bump k8s.io deps to v0.26.1

What type of PR is this?
/kind cleanup

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

Fixes https://github.com/kubernetes-sigs/kueue/pull/586
Special notes for your reviewer:

can you bump all the k8s libraries together?

/retest

Failed test: https://prow.k8s.io/view/gs/kubernetes-jenkins/pr-logs/pull/kubernetes-sigs_kueue/588/pull-kueue-test-unit-main/1628060447326343168

The test error was introduced in https://github.com/kubernetes-sigs/controller-runtime/pull/2025, for fakeClient will check the indexes but we didn't register any in unit tests.

But we can register these indexes when building the client.

Yes, the test error fixed.

All addressed except https://github.com/kubernetes-sigs/kueue/pull/588#discussion_r1114570049.

/lgtm

@kerthcet we can also get rid of checks like this:
https://github.com/kubernetes-sigs/kueue/blob/c45d3dd98e3cae593e844092e2f334879a40ce7c/pkg/queue/manager.go#L172

authors: alculquicondor kerthcet


text:
Update readme expression

What type of PR is this?
/kind documentation

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

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

/ok-to-test

authors: kerthcet liurupeng

repo: kubernetes-sigs/lws