text:
Session substitution between workers

Mojolicious version: 6.58
Perl version: v5.20.2 built for x86_64-linux-gnu-thread-multi
Operating system: Linux version 3.16.0-4-amd64 (debian-kernel@lists.debian.org) (gcc version 4.8.4 (Debian 4.8.4-1) ) #1 SMP Debian 3.16.7-ckt11-1+deb8u6 (2015-11-09)

Sebastian, hi!
I don't know how can you reproduce it, so i'l just describe our rare, strange, but very critical trouble.
We are using sessions to authenticate users in our site. As we know, Mojo writes session code to browser cookies with encription, and rewrite it every request with the new value.
Sometimes (not often) it seems like Mojo write to cookie session code from ANOTHER user! Maybe, from another worker. One time it was a profile rewriting from user A to user B, when the both of users before this incident visited the same page... User B at this moment see on the page, that in his profile section already not his own, but user A login. After that user B has to to log out and log in again. Any time it looks good, but once profile substitution hapen again.
What a reason could in be?.. It's a real big security trouble. :(
PS: We are using Starman with 10 workers (Plack 1.0037).
Thank you! Alexey, Russia.
sub startup {
...
$self->sessions->cookie_name('sessioncode');
$self->sessions->default_expiration(60 * 60 * 24 * 365);
$self->sessions->cookie_domain($self->config->{cookiedomain});
Code, where we seting up session code:
$session = generate_session_id();
...
$self->session(
session => $session,
user_id => $user_id
);
Code, where we geting the session code:
sub setup_hooks {
my $self = shift;
# выполняется перед обработкой каждого запроса
$self->app->hook(before_dispatch => sub {
    my $c = shift;

...
my $session_code = $c->session->{session};

I'm afraid there is nothing we can do without a minimal example demonstrating the problem. That said, i very much doubt this could be a bug in Mojolicious. With Starman, every worker can only handle a single connection at a time, ruling out any possible data leakage between concurrently active connections. Btw. Session data is not encrypted, just cryptographically signed.

I don't believe that this is likely to be a Mojolicious issue. I can see two possible ways that application code or user behavior could cause something like this.
First, user behavior. Is it possible that you are testing this behavior in the same browser in separate tabs? Sometimes people are confused by the fact that cookie jars are global to the browser (or browser user session) and not the tab. I don't suspect you are doing this or you should be able to replicate regularly.
Second, application logic. If you have a global that stores the current user object and perhaps don't properly clean up after it this could certainly happen. Whether it be in a variable (package variable/closed over lexical) or even in a caching engine without proper isolation globals can cause leakage. In the case of a variable the leakage wouldn't cross workers and so would only happen occasionally when you happen to hit the same worker. An improperly isolated caching engine would cross workers and therefore I would expect (as with browser tabs) that replicating this would be easier.
I therefore suspect you are leaking user objects via a closed over lexical or package global, probably called $current_user or the like. If this is the case I highly recommend stuffing that information into the per-request stash on the controller object.

authors: crealist jberger kraih

repo: kraih/mojo


text:
Semicolon not supported as query string separator in 4.90

Tested with the following simple program:
use Mojolicious::Lite;

# Route with placeholder
get '/foo' => sub {
        my $c   = shift;
        my $foo = $c->param('foo');
        my $bar = $c->param('bar');
        $c->render(text => "Hello from $foo.  Bar = '$bar'.\n");
    };

# Start the Mojolicious command system
app->start;

using 4.63 it works:
$ curl 'localhost:3000/foo?foo=a&bar=b'
Hello from a.  Bar = 'b'.
$ curl 'localhost:3000/foo?foo=a;bar=b'
Hello from a.  Bar = 'b'.

but 4.90 does not recognize the semicolon separated parameter:
$ curl 'localhost:3000/foo?foo=a&bar=b'
Hello from a.  Bar = 'b'.
$ curl 'localhost:3000/foo?foo=a;bar=b'
Hello from a;bar=b.  Bar = ''.

Is support for the semicolon dropped or is this a regression? I did not check with other versions.

https://tools.ietf.org/html/rfc3986
The full specification allows for a wide variety of separators and and web server should attempt to be as allowing as possible to prevent issue.
Also ; are often used instead of & for embedded URIs within hrefs to prevent issues with HTML entity encoding. It is even recommended in the URI docs (https://metacpan.org/pod/URI#uri-query_form-hash-delim)

I understand this was done on purpose, and knowing @kraih, that is decision is probably final. For others that may have to interoperate with other systems that issue such URLs, support can be re-added with this patch:
diff --git a/lib/Mojo/Parameters.pm b/lib/Mojo/Parameters.pm
index c7de85c..cc6c24a 100644
--- a/lib/Mojo/Parameters.pm
+++ b/lib/Mojo/Parameters.pm
@@ -81,7 +81,7 @@ sub pairs {
     return $pairs unless length $str;

     my $charset = $self->charset;
-    for my $pair (split '&', $str) {
+    for my $pair (split /[&;]/, $str) {
       next unless $pair =~ /^([^=]+)(?:=(.*))?$/;
       my ($name, $value) = ($1, $2 // '');

The previous support was removed in: commit 2d1cf0eaa8abc78e44edf88dc0b4a14d4f451571

source: gharchive/issue

authors: Gilwyad pmorch ungrim97

license_type: permissive

license_source: bigquery


text:
Can't run build

Hi, I've just forked this repo (great work btw) and I'm running npm run build after installing everything and im getting the following error:
28 11 2017 17:42:11.819:WARN [reporter]: SourceMap position not found for trace: undefined
HeadlessChrome 0.0.0 (Mac OS X 10.12.6) ERROR
  Uncaught ReferenceError: __ALLOW_POSTMESSAGE_POPUP__ is not defined
  at test/test.js:1665

Please help :)
Full output:
> xcomponent-demo@1.0.1 build /Users/matimenich/playground/xcomponent-demo
> npm run test && npm run babel && npm run webpack

> xcomponent-demo@1.0.1 test /Users/matimenich/playground/xcomponent-demo
> npm run lint && npm run flow && npm run karma

> xcomponent-demo@1.0.1 lint /Users/matimenich/playground/xcomponent-demo
> eslint src/ test/ *.js

> xcomponent-demo@1.0.1 flow /Users/matimenich/playground/xcomponent-demo
> flow

No errors!

> xcomponent-demo@1.0.1 karma /Users/matimenich/playground/xcomponent-demo
> cross-env NODE_ENV=test babel-node --plugins=transform-es2015-modules-commonjs ./node_modules/.bin/karma start

28 11 2017 17:42:11.819:WARN [reporter]: SourceMap position not found for trace: undefined
HeadlessChrome 0.0.0 (Mac OS X 10.12.6) ERROR
  Uncaught ReferenceError: __ALLOW_POSTMESSAGE_POPUP__ is not defined
  at test/test.js:1665

HeadlessChrome 0.0.0 (Mac OS X 10.12.6): Executed 0 of 0 ERROR (0.337 secs / 0 secs)

npm ERR! code ELIFECYCLE
npm ERR! errno 1
npm ERR! xcomponent-demo@1.0.1 karma: `cross-env NODE_ENV=test babel-node --plugins=transform-es2015-modules-commonjs ./node_modules/.bin/karma start`
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the xcomponent-demo@1.0.1 karma script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.

npm ERR! A complete log of this run can be found in:
npm ERR!     /Users/matimenich/.npm/_logs/2017-11-28T20_42_12_045Z-debug.log
npm ERR! code ELIFECYCLE
npm ERR! errno 1
npm ERR! xcomponent-demo@1.0.1 test: `npm run lint && npm run flow && npm run karma`
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the xcomponent-demo@1.0.1 test script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.

npm ERR! A complete log of this run can be found in:
npm ERR!     /Users/matimenich/.npm/_logs/2017-11-28T20_42_12_087Z-debug.log
npm ERR! code ELIFECYCLE
npm ERR! errno 1
npm ERR! xcomponent-demo@1.0.1 build: `npm run test && npm run babel && npm run webpack`
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the xcomponent-demo@1.0.1 build script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.

npm ERR! A complete log of this run can be found in:
npm ERR!     /Users/matimenich/.npm/_logs/2017-11-28T20_42_12_123Z-debug.log

Good catch! fixed and published.

Great! Thank you 👍

authors: MatiMenich bluepnume

repo: krakenjs/xcomponent-demo

license_source: github-api


text:
fix: avoid throwing errors if container is no longer in page

We have identified a few errors that zoid throws that cannot be caught by the implementation code (render.catch() and close.catch()) during asynchronous dismounts. Although this can occur in every webpage, it's primarily an issue when using React as seen here: Issue #334
With this change, we first check if the container element has been removed from the DOM or the user has navigated away from the page mid-render. In these scenarios we should avoid throwing errors.
Here are 3 examples:
https://github.com/krakenjs/zoid/blob/main/src/parent/parent.js#L857
https://github.com/krakenjs/zoid/blob/main/src/parent/parent.js#L826
https://github.com/krakenjs/zoid/blob/main/src/parent/parent.js#L1172
These 3 error flows eventually cause the promise to be rejected since the render was never completed, and an error to be displayed on the console: https://github.com/krakenjs/zoid/blob/main/src/parent/parent.js#L732

I haven't looked into testing in Zoid so I don't know how reasonable this ask is: can we write a test for this?

I agree that it would be awesome to add a couple tests to cover this new logic. I'm really excited about this improvement. Great work so far @oscarleonnogales!

This is great, thanks everyone!

Codecov Report
Patch coverage: 100.00% and project coverage change: +0.01 :tada:

Comparison is base (31d59fb) 95.63% compared to head (a632f03) 95.64%.

:mega: This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more
Additional details and impacted files
@@            Coverage Diff             @@
##             main     #424      +/-   ##
==========================================
+ Coverage   95.63%   95.64%   +0.01%
==========================================
  Files          18       18
  Lines        1213     1217       +4
==========================================
+ Hits         1160     1164       +4
  Misses         53       53

Impacted Files
Coverage Δ

src/constants.js
100.00% <100.00%> (ø)

src/parent/parent.js
95.62% <100.00%> (+0.02%)
:arrow_up:

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.

Looks great man 🔥  Love that you moved the error messages into a const ⚡

source: gharchive/pull-request

authors: codecov-commenter gregjopa mdentremont oscarleonnogales spencersablan

repo: krakenjs/zoid


text:
Sheet Worker Conversion

This issue will be closed once I deem the sheet worker conversion to be completed.
Details: Sheet Worker Conversion Roadmap.

Wie weit bist du?
Bist du immernoch der einzige Aktive an diesem Projekt?
Was müsste man lernen um dir bei der Abarbeitung der Roadmap zu helfen?

Wie weit bist du?

Noch nicht angefangen. Wenn ich das aber mache, dann ziehe ich das auch quasi am Stück durch. Wird voraussichtlich aber eben vor Ende des Jahres nichts.

Bist du immernoch der einzige Aktive an diesem Projekt?

Ich arbeite aktuell allein an dem Charakterbogen. Es gab allerdings vor mir bereits einige andere, die den Großteil der Arbeit gemacht haben ;D

Was müsste man lernen um dir bei der Abarbeitung der Roadmap zu helfen?

Wenn du bereits in irgendeiner halbwegs verbreiteten Sprache programmieren kannst, ist das schon mal was. Kenntnisse in folgenden Bereichen ist notwendig:

JavaScript
HTML
CSS
Roll20

Kenntnisse in folgenden Bereichen sind sehr hilfreich:

Git (und GitHub)

Wie ich das genau machen will, habe ich allerdings nicht aufgeschrieben. ^_^ Ich würde sheetworker-autocalc zwar nutzen, aber nur lokal und in meinem Testspiel, bis ich das nicht mehr brauche. Nach Beendigung der Arbeiten wird sheetworker-autocalc nicht mehr benötigt und ich würde das entfernen. Grund dafür ist, dass rein aus einer Urheberrechtsperspektive das sheetworker-autocalc nämlich unter einer Lizenz steht, die nicht mit der für Charakterbögen seitens Roll20 durchgesetzten kompatibel ist.

Wenn ich mal wieder Zeit habe, werde ich mich mal in die Sprachen einarbeiten. Kann aber auch noch ein wenig dauern, ähnlich wie bei dir.

Hey ho!
Der letzte Commit liegt ja mittlerweile ein paar Monate zurück und da hier kein ausdrücklicher "help wanted"-Tag vorhanden ist, frage ich einfach mal nach, ob du hier Hilfe brauchst. Ich bin der Entwickler des Splittermond-Charakterbogens, an dem ich seit knapp 2 Jahren entwickle und der mittlerweile gut gereift ist. Allerdings spiele ich hin und wieder auch ganz gerne mal DSA und würde gerne mithelfen, den Bogen etwas praktischer zu machen. Wenn ich das richtig verstanden habe, ist die Sheet Worker Conversion deine Top Prio, die vor allem anderen gemacht werden soll. Falls Hilfe willkommen ist, könnte man sich ja vielleicht mal kurzschließen.
LG

Ich hatte heute ein bisschen Zeit und habe schonmal die Grundwerte (Attribute + Abgeleitete Werte) in Sheet Worker Skripts umgeschrieben. Ich hab außerdem, um ein Gefühl für den Charakterbogen zu bekommen, auch schon die Funktion implementiert, dass man eigene Meta-Talente hinzufügen kann. Außerdem werden bei den vorhandenen automatisch die richtigen Attribute eingetragen. Die automatische Berechnung des TaW ist nicht ganz einfach, weil bei der Jagd der Spieler z.B. die Wahl zwischen verschiedenen Fernkampffertigkeiten hat.

Danke für deine Hilfe ap3h3ad. Ich habe das in meinem jüngsten Video bereits angedeutet. Momentan sieht es bei mir wie folgt aus:

Meistern unserer DSA-Gruppe
Sammeln (und Erstellen) von Material für neue Videos der Meisterwerkstattreihe

Wenn das fertig ist (~2019), sieht mein Plan wie folgt aus:

"zweite Staffel" der Meisterwerkstatt produzieren
DSA4.1-Heldenbogen weiter verbessern

Da ich aber niemandem im Weg stehen möchte, würde ich mich natürlich freuen, wenn du den PR gegen mein Repository stellen könntest. Vor dem Wochenende werde ich aber vermutlich nicht dazu kommen mich darum zu kümmern :)
Vielen Dank schon mal :dragon_face:

Du kannst im Übrigen auch für einzelne Teile, die du fixst, Issues aufmachen, die deine Commits dann schließen. Wenn du im Issue auf dieses Issue verweist, sollte dieser Zusammenhang sogar sichtbar werden.

authors: Lorindion ap3h3ad kreuvf

license: mit


text:
TypeScript compiler errors on import

Hello!  Just about to go to bed, so probably tired and doing something silly.
When I try and use this from a TypeScript project (just importing the module https://github.com/jameswilddev/failed-install-repro/blob/master/index.ts), I see the following:
Module '"D:/a/failed-install-repro/failed-install-repro/node_modules/@types/sqlite3/index"' has no default export. Did you mean to use 'import { sqlite3 } from "D:/a/failed-install-repro/failed-install-repro/node_modules/@types/sqlite3/index"' instead?

(repro repository at: https://github.com/jameswilddev/failed-install-repro/runs/561090339?check_suite_focus=true)
Additionally, I had to add a dependency on sql-template-strings as its types were required by node-sqlite.

I'll take a look - I didn't have any problems when trying it out on my own projects, but maybe I overlooked something

Oh, I know what it is - make sure to read the project readme. I'm not sure if you're aware that v4 was just published. The usage is different, and you need to install sqlite3 along with sqlite.

I do see a bug with not having template strings installed, ill fix that

Ok, this should be fixed now.
No longer need to include sql-template-strings.
You do need to have sqlite3 installed, however, since you will need to inject it as a driver into the sqlite library (see this project readme on usage).

Thank you!

authors: jameswilddev theogravity

repo: kriasoft/node-sqlite


text:
Change /logout endpoint from GET to POST

See src/routes/account.js

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

Fixed in https://github.com/kriasoft/nodejs-api-starter/commit/2760695c0db29dcc4f60b27100256ad7f13ef375

repo: kriasoft/nodejs-api-starter


text:
Use of undeclared type 'UIWindowScene'

Hello,
just updated my pod to 3.4.2 and receiving an error while building "Use of undeclared type 'UIWindowScene'"
here is the code and error image link:
https://imgur.com/upPixUU

@SohaibSiddique
Version 3.4.2 can be used on Xcode 11.

@SohaibSiddique
Version 3.4.2 can be used on Xcode 11.

for now, downgrade to 3.4.1 after updating Xcode definitely will update pod to 3.4.2

authors: SohaibSiddique krimpedance

repo: krimpedance/KRProgressHUD


text:
Enhance - #90 Refactor strings and status codes

Summary
Response messages and status codes refactoring (Backend)
Description
This PR focuses on enhancing the backend by refactoring hardcoded response messages and HTTP status codes. The goal is to improve code maintainability and reduce the risk of errors due to inconsistent values. I have defined the status codes in the constant file already there, and made a new file for the messages, as it will grow over time.
Issue(s) Addressed
Closes #90
Prerequisites

[x] Have you followed all the CONTRIBUTING GUIDELINES?

@shmbajaj, can you kindly let me know your thoughts on this, LGTM though, wanted your POV.

@krishnaacharyaa @shmbajaj I have moved error messages to the constants file.

authors: Imrankhankhattar krishnaacharyaa

repo: krishnaacharyaa/wanderlust

license: MIT


text:
change tension of cardinal interpolation

cardinal interpolation has parameter "tensity" which allows to manipulate with length of tangens
as described here https://github.com/d3/d3-shape/blob/master/README.md#curves
it would be great be able to change it in angular2
thanks!

actually I need to prevent graph from falling below to zero


text:
private api btce

missing 'method' params in private method api.

Thanks! Will accept your pull request asap.

authors: kroitor tritoanst

repo: kroitor/ccxt


text:
Adding perf profile tab on Kruize UI & fixing RecommendationComp typo

Raising this PR to support Performance profile tab and minor typo changes in file names

@rbadagandi1 Please fix the conflicts

Conflicts resolved @dinogun. Please review.

repo: kruize/kruize-ui


text:
Are we taking right approach with junction lane routing UI overhaul?

Background: I used to play a game called Carmageddon at a friends house, then drive home afterwards while my brain was still in "collide with as many pedestrians as possible" mode. These days, it's C:SL and my brain is in "focus on the efficiency of the transit infrastructure" mode.

In C:SL we, as users, work from the 'mayor perspective' - looking from above and our focus is on getting that traffic flowing smoothly.
The existing TM:PE UI, however, is often done from 'driver perspective' - the view from being in a car on the road. That's why some of it (lane arrows and timed traffic lights in particular) are so cumbersome to use.
We definitely want UI interactions to work with the mayor perspective, but sometimes that disconnects with the driver perspective. How do we connect the two perspectives where necessary?
I'll use lane arrows as an illustration...
Lane arrows
We are overhauling this UI from driver perspective to mayor perspective. That's necessary, as it will make it easier to use, but this feature in particular has a big disconnect between the two perspectives:

Mayor: If you enter via this lane, you can exit via these segments
TM:PE: I will display an arrow in the relevant direction
Driver: I can exit via any segments in the general direction of the arrow

I think by a taking a mayor-only approach to the UI we've blurred the lines too much between lane arrows and lane connectors (my bad: I've been pushing towards that for ages but now realise it's wrong), and we've also omitted any sense of the driver perspective. As a result, I'm thinking we might be harming gameplay too.
Here's what I propose...
1 Select incoming lane
2. Click an outgoing lane
3. An arc visualises the 'general direction' (lane arrow direction)
4. All outgoing segments in that direction are treated as being selected
Hastily thrown together mockup - diver is entering from 0 and mayor clicked outgoing segment 1:

So the UI is still mayor perspective, but the arc shows driver perspective which is what ultimately decides the valid exit segments for that incoming lane.
This will also very clearly differentiate between lane arrows and lane connectors.
Lane connectors is more like painting dashed lines over the junction to more accurately control traffic flow:

Tagging #391

With my existing prototype (outdated now because master changed so much) it means i will need to show less lane curves (hey, they looked cool!) and add arcs for directions instead. This, in fact, might be a nice improvement to visualize what each arrow direction means.

Wait @aubergine10 do you also want an incoming arc? The thin light blue one. Selecting all lanes in the arc will defeat lane fine-tuning ability, where some lanes on some roads can be sent in different directions.

No, that was just an artifact of the graph I butchered to create a mockup image hehehe
Just going in game to get some screenshots

Also, I think we'd still need 'lane connector' style lines from incoming lanes to outgoing lanes, in particular so user can hover over nearby incoming lanes to see what they connect to. Also, hovering outgoing lanes should show which incoming lanes connect to them if possible?
Those lines serve another purpose too. For example, if I have a crossroads junction with all 4 lane 2-way roads, it would be good to show what the lanes are connecting to as it might not be immediately obvious from the arrows or direction arcs.
Rough mockup:

So if only one incoming lane makes the turn in given direction, it might lead to two outgoing lanes (I have no idea how this currently works - because there's no visualisation of it in-game). If two lanes go in a direction, then the outgoing lanes are sort of spread between them.
@VictorPhilipp did a good page explaining what happens - using lane connectors to illustrate his points hehe: https://tmpe.viathinksoft.com/wiki/index.php?title=Junction_%26_transition_routing


text:
Tram tracks - issues with Junction restrictions

Testing of PR https://github.com/krzychu124/Cities-Skylines-Traffic-Manager-President-Edition/pull/25 uncovered some issues relating to junction restrictions when roads include tram tracks.

Turn left/right on red
U-turns
etc.

We should also check whether we need to hide the turn-on-red UI for tram roads.


text:
Ta bort tidspunkt og legg til system

I møtet 22.06.2023 kom det fram at vi mangler feltet  i hent-meldinger og vi kom fram til at vi ikke trenger feltet .

Stenger denne da det er fikset, merget inn og releaset

repo: ks-no/fiks-arkiv-specification


text:
Replace Wicket with Vaadin

Problems with Wicket

See https://github.com/ksch-workflows/ksch-workflows/issues/85
Though Wicket is an active project, there are few people in the Wicket community.

Expected benefits with Vaadin

Vaadin applications can be developed with 100% Java code, without a big need for raw HTML and JavaScript. This might simplify creating new screens.
Vaadin has very powerful features like two-way-databind which makes it fairly easy to support also complex user interfaces like split-views if they turn out to be necessary.
The latest version of Vaadin is build on the Web Components standard. This might make it possible later to share HIS components with other projects which might even use different technologies. So in this way a health open source community could develop around this, where everybody works on the things for themselves but still each one benefits from the other's work.
More options to find contractors for building new features later on.

Risks

Vaadin was initially not considered because they reserve certain features for paid plans. Those paid plans might be affordable for one developer but not for a range of open source contributors. So we might run into a big paywall. Since there are at least three big open source projects using Vaadin that fear might not be reasonable: metl (GPL), cuba (Apache 2), mycollab (AGPL). Even though some of its sophisticated components are not available, there is a way to build similar ones from scratch. Also other limitations like the missing access to the TestBench tool seem to be replaceable with a combination of Testcontainers and Selenide.
Since Vaadin has more of an enterprise culture, it may also be required to pay for plugins from the Vaadin community. E.g. the plugin which is required to compile the project in production mode with Gradle costs about 100€ per year license fees.
Testing the user interface will be done with the Karibu Testing project. This is basically build by an individual developer who might decide at some day to discontinue working on it. Then this project would need to get forked and maintained by ourselves.

Experience with Vaadin
Good

The two-way data binding is really great
The layout manager are really great. This enables to build sophisticated user interfaces
Building on top of Web Components is really great. This enables the creation of a solid component library.

Not so good

Developing the code with TDD seems to be only practicable with the Karibu Testing library. This is maintained by an individual develop who might abandon the project at any point in time.
The application state is maintained in a deep structure of Java objects. This is not optimized to be accessible from unit tests. Often one needs to take recourse to enforcing access via the reflection API which may be brittle.
It's difficult or near impossible to preview the UI of individual page components (without starting the whole application)

Experience with Wicket
Good

Usage of plain HTML makes it easy to reason about
So far, after a little bit of research, every imagined functionality could be implemented with reasonable effort
The rendered HTML is easily accessible in unit tests

Not so good

Problem with page versions after parts of the page where updated with AJAX: http://mail-archives.apache.org/mod_mbox/wicket-dev/202001.mbox/<6e2353b5-461c-9205-b418-51b486a4b081%40ks-plus.org>
The framework is not in the main stream, so there are only relatively few people working with it.

Vaadin is a great framework. However, I was also happy with until I hit the problem with page reload described in GH-85. Since this was solved with the help of a Wicket developer, the main argument for this issue is invalidated.
Instead of spending more time on the evaluation of Vaadin I will push forward with the current Wicket based approach.
The first steps with Vaadin are on this branch for potential future considerations: https://github.com/ksch-workflows/ksch-workflows/tree/vaadin

repo: ksch-workflows/ksch-workflows


text:
Support for Nullable() types

Is there plan to add support for Nullable() types?

Hi. Yes, I will add support for Nullable types

Do you accept PR's?

Yes, of course

now I'm on vacation if you have to add support for Nullable types you can see array implementation (it is very similar to implements new type)  or wait a couple of weeks )

New types Nullable and UUID are available in master

Thank you for adding this feature.

authors: kenota kshvakov

repo: kshvakov/clickhouse


text:
Use Aer simulator

What to do.
It seems like the qiskit example tutorial performs a local statevector simulation according to comments below.

As we are performing a local statevector simulation, we will not set the estimator parameter; the network will create an instance of the reference Estimator primitive for us. If we needed to access cloud resources or Aer simulators, we would have to define the respective Estimator instances and pass them to the EstimatorQNN.
(From https://qiskit-community.github.io/qiskit-machine-learning/tutorials/01_neural_networks.html)

Use an Aer simulator.
Others
This is a sub-issue of #2.

This article may be useful: https://docs.quantum.ibm.com/guides/get-started-with-primitives.

Ran the new scripts and there are results below.
# Example as it is
Accuracy from the train data : 91.43%
Accuracy from the test data: 73.33%
Accuracy from the test data: 73.33%

# Aer Exact simulator (noiseless)
  example_estimator_qnn = QNNBuilder().get_example_exact_aer_estimator_qnn()
Accuracy from the train data : 77.14%
Accuracy from the test data: 66.67%
Accuracy from the test data: 66.67%

# Aer noisy simulator
Accuracy from the train data : 80.0%
Accuracy from the test data: 66.67%
Accuracy from the test data: 66.67%

I expected the exact aer simulator and the example as it is would be the same. Also, the exact one would be better than the noisy one. However, my expectation was not true.

Actually, I forgot to fix the random seeds.
# run_example_estimator_qnn.py
Accuracy from the train data : 82.86%
Accuracy from the test data: 53.33%
Accuracy from the test data: 53.33%

# run_example_exact_aer_estimator_qnn
Accuracy from the train data : 91.43%
Accuracy from the test data: 100.0%
Accuracy from the test data: 100.0%

# run_example_noisy_aer_estimator_qnn
Accuracy from the train data : 65.71%
Accuracy from the test data: 46.67%
Accuracy from the test data: 46.67%

Still, the exact one and the example as it is are different. Apparently, there is the approximation argument of qiskit_aer.primitives.Estimator and was False. The document said the combination of shots in run_options and approximation determine how to calculate the value. So, I tried different combinations as changing the source code itself, however, the values were still different.

Wait to finish the other issues related to #2.


text:
Rewrite integration tests to support ksonnet.next application structure

@hausdorff is on medical leave and won't be able to check in #153 for release.
This PR attempts to continue that work of removing the standalone -f flag and making the env arg mandatory, with an optional -c component flag.
====
Related to this change, the integration tests will also have to be rewritten.
ksonnet.next is centered around the application directory structure
generated during init, however the integration tests are still tightly
tied to the model from kubecfg, where the '-f' flag was the standard and
environments were not introduced.
This commit will add test fixtures to mock a ksonnet application
structure, and rewrite the existing apply and delete tests to support
this new model.
Signed-off-by: Jessica Yuen im.jessicayuen@gmail.com

@bryanl Could you take a look at this? It might be easier to review by commit. The commit authored with @hausdorff has already been reviewed in #153, so I'd put more focus on the other ones.

Should there be a namespace here?

@bryanl The namespace should be default if there isn't one specified by the current context. Did you create a new ksonnet app (using an older one might give you issues)?
➜  ksonnet git:(pr-153) ✗ ./ks init foo3
INFO  Using context 'dev-jess' from the kubeconfig file specified at the environment variable $KUBECONFIG
INFO  Creating a new app 'foo3' at path '/Users/jyuen/go/src/github.com/ksonnet/ksonnet/foo3'
INFO  Creating environment 'default' with namespace 'default', pointing at server at address 'https://kubecfg-t-apiloadb-1k1vqoxu7q212-666493100.us-west-2.elb.amazonaws.com'
INFO  Generating environment metadata at path '/Users/jyuen/go/src/github.com/ksonnet/ksonnet/foo3/environments/default'
INFO  ksonnet app successfully created! Next, try creating a component with `ks generate`.
➜  ksonnet git:(pr-153) ✗ cd foo3
➜  foo3 git:(pr-153) ✗ ../ks env list
NAME    NAMESPACE SERVER
====    ========= ======
default default   <redacted>

@jessicayuen I rebuilt it and tried again. While I'm looking, I'll see if I can understand why this happening.
[I] ⋊> ~/g/s/g/k/ksonnet on jessicayuen-pr-153  git rev-parse HEAD                                                                                16:50:03
cdecf56a5ca6f8cdf915c602c38dd8e92394f43d
[I] ⋊> ~/g/s/g/k/ksonnet on jessicayuen-pr-153  make ks                                                                                16:50:04
go build -o ks -ldflags="-X main.version=dev-2017-11-29T16:50:07-0500 "  .
[I] ⋊> ~/g/s/g/k/ksonnet on jessicayuen-pr-153  rm -rf mule                                                                                16:50:10
[I] ⋊> ~/g/s/g/k/ksonnet on jessicayuen-pr-153  ./ks init mule                                                                                16:50:16
INFO  Using context 'minikube' from the kubeconfig file specified at the environment variable $KUBECONFIG
INFO  Creating a new app 'mule' at path '/Users/bryan/go/src/github.com/ksonnet/ksonnet/mule'
INFO  Creating environment 'default' with namespace '', pointing at server at address 'https://192.168.99.100:8443'
INFO  Generating environment metadata at path '/Users/bryan/go/src/github.com/ksonnet/ksonnet/mule/environments/default'
INFO  ksonnet app successfully created! Next, try creating a component with `ks generate`.
[I] ⋊> ~/g/s/g/k/ksonnet on jessicayuen-pr-153  cd mule                                                                                16:50:20
[I] ⋊> ~/g/s/g/k/k/mule on jessicayuen-pr-153  ../ks env list                                                                                16:50:24
NAME    NAMESPACE SERVER
====    ========= ======
default           https://192.168.99.100:8443
[I] ⋊> ~/g/s/g/k/k/mule on jessicayuen-pr-153

authors: bryanl jessicayuen

repo: ksonnet/ksonnet


text:
KSCrash catch the crash, but the crash stack is empty

I get some crash report from our user, but I found that some of the crash stack is empty.

These are some of the raw json crash report.
1.txt
2.txt
3.txt

I get the same issue.

I meet the same problem. Anyone fix it?

Em maybe I fix the problem. I try to add a "kssc_initSelfThread(&g_stackCursor, 1);" in the function CPPExceptionTerminate in KSCrashMonitor_CPPException.cpp. And now I can get the crash stack.

I meet the same problem, but why?

I got the same issue and I'm going to fix it (if possible). Can someone steadily reproduce this issue?

I meet the same problem. Anyone fix it?

All three reports issue author provided are related to C++ exceptions. Has anyone received non-C++-crashes without backtrace?

@bamx23  #205 shows why C++ crashes can't get the crashed stack. i have a question , Until now, does the issue has been solved ? i can still get  a   empty stack  when C++ exceptions in embedded frameworks?

I'll take a look at this problem next week

@bamx23 i get a lot empty  crashed stack, "diagnosis": "Attempted to dereference null pointer."
empty.txt

If meet the empty stack for C++ exception, can find the reason on this issue. https://github.com/kstenerud/KSCrash/issues/205

Sorry, it would have been better to say "next month".
I've checked KSCrash on C++ crash from my sample app, but threads were ok. Could someone provide an example code that reproduces the problem?

@chzhij5 老哥，你们用的是哪个版本的ks？1.15.8？

Hi! We investigated the problem and possible solutions in our team. There is one:
During installation process of KSCrashMonitor_CPPException we can use a "hack" that is described and implemented in https://github.com/facebook/fishhook. It allows hooking any call of dynamically linked binary's function. So we hook __cxa_throw for all loaded binaries.
If any library has a weak symbol __cxa_throw (like KSCrash has currently) we will call it the same way we do it now. The order would be like [fishhooked one] -> [weak one] -> [libc++abi one].
The only problem that can't be solved is if some binary has strong  __cxa_throw symbol in it we can't hook it. But I think that there is no option to deal with such a situation.
@kstenerud, what do you think? We've read your post at stackoverflow, and it seems that the idea above may solve it, at least partially.
We can go ahead and create a pull-request where fishhook will be a dependancy of KSCrash(or KSCrash subspec like i.e. 'KSCrash/Recording/ImprovedCPPExceptionsHandling`).

[fishhooked one] -> [weak one] -> [libc++abi one].

We actually can call [libc++abi one] from  [fishhooked one] in case if [weak one] does not call it that satisfies @kstenerud's requirements.

That sounds good, we will have a try next week in our in-house app.

Here the PR: #375

@bamx23 I have KSCrash statically linked, but with Simulators, I get an empty stack trace. Works fine when testing on a device tho 🤷♂.

authors: CastleChe FadeFei GLinnik21 ZhiyuWong bamx23 chzhij5 guzuqing kingandyoga wanglichun yousefhamza

repo: kstenerud/KSCrash


text:
Update tolo.podspec

Updated to version 1.0.1

bump

repo: kswchoo/tolo


text:
🛑 upptime is down

In 9ea4d3e, upptime (https://upptime.js.org/docs/triggers) was down:

HTTP code: 530
Response time: 235 ms

Resolved: upptime is back up in 80d723e.


text:
Write an in-memory apiserver

What problem are you trying to solve?
A thing that continually comes up in the concept of controller testing is being able to run the reconciler and verify that it does the right thing.
In complex scenarios this is difficult for users to do right now without a semi-functioning apiserver.
We currently recommend using a mock client:
let (mock_service, handle) = tower_test::mock::pair::<Request<Body>, Response<Body>>();
let mock_client = Client::new(mock_service, "default");

and pass that into the reconciler's context where we intercept the api calls and return some reasonable information. See controller-rs's fixtures.rs and controller.rs for test invocations.
It is perfectly possible to do that in tests (and we do) like this particular wrapper around
tower_test::mock::Handle<Request<Body>, Response<Body>> responding to an Event
being POSTed, while also checking some properties of that data:
async fn handle_event_create(mut self, reason: String) -> Result<Self> {
    let (request, send) = self.0.next_request().await.expect("service not called");
    assert_eq!(request.method(), http::Method::POST);
    assert_eq!(
        request.uri().to_string(),
        format!("/apis/events.k8s.io/v1/namespaces/testns/events?")
    );
    // verify the event reason matches the expected
    let req_body = to_bytes(request.into_body()).await.unwrap();
    let postdata: serde_json::Value =
        serde_json::from_slice(&req_body).expect("valid event from runtime");
    dbg!("postdata for event: {}", postdata.clone());
    assert_eq!(
        postdata.get("reason").unwrap().as_str().map(String::from),
        Some(reason)
    );
    // then pass through the body
    send.send_response(Response::builder().body(Body::from(req_body)).unwrap());
    Ok(self)
}

The problem with this approach is that:

it is verbose (lots of Request / Body / Response / serde_json::Value fiddling)
it requires user tests implementing apiserver expected behavior
it mixes apiserver imitation behavior with test assertion logic

Describe the solution you'd like
Create a dumb, in-memory apiserver that does the bare minimum of what the apiserver does,
and presents a queryable interface that can give us what is in "its database" through some type downcasting.
This server could treat every object as a DynamicObject storing what it sees in a HashMap<ObjectRef, DynamicObject> as an initial memory backing.
If this was made pluggable into tower_test::mock, users can hook it into tests around a reconciler without the tests failing due to bad apiserver responses, without having to have users know all the ins and outs of apiserver mechanics (and crucially without giving them the opportunity to get this wrong).
Implementation
We would need at the very least implement basic functionality around metadata on objects:

POSTs need to fill in plausible creationTimestamp, uid, resourceVersion, generation, populate name from generateName
and prevent clients from overriding read-only values like creationTimestamp / uid / resource_version / generation
Respond to queries after storing the query result in the HashMap
DELETEs need to traverse ownerReferences

Implementing create/replace/delete/get calls on resources plus most calls on subresources "should not be too difficult" to do in this context and will benefit everyone.
The real problem here would be implementing patch in a sensible way:

json patches need to actually act on the dynamic object
apply patches need to follow kubernetes merge rules and actually do what the apiserver does
merge patches, strategic merges with patch strategies need to be followed

Some of this sounds very hard, but it's possible some of it can be cobbled together using existing ecosystem pieces like:

json patches from json-patch library
apply patches through k8s_openapi::DeepMerge (but it might force us out of dynamic objects for merge rules)

Anyway, just thought I would write down my thoughts on this. It feels possible, but certainly a bit of a spare time project. If anyone wants this, or would like to tackle this, let us know. I have too much on my plate for something like this right now, but personally I would love to have something like this if it can be done in a sane way.
Documentation, Adoption, Migration Strategy
can be integrated into controller-rs plus the controller guide on kube.rs as a start.

NB: Prior discussion around envtest https://github.com/kube-rs/kube/issues/382 went down a separate route of relying on cluster provisioning to do more integration style tests. This is a heavy weight solution that either re-uses the test environment or sets up one cluster per test, so we currently have left this style of test automation to CI actions provisioning a test cluster.
It is currently pretty easy to do this for a small amount of integration tests. We use this approach, and it does not require mock clients, but it does force us to consider how some tests might interact with others (limiting how deeply we can use this approach). This issue is instead trying to turn more complicated integration tests into true unit tests for users. Both style of tests have a place.

cc @chuckhend @sjmiller609

A perhaps more promising, and less work-involving way forward here for integration tests is to lean on; https://github.com/kubernetes-sigs/kwok/
kwok still creates some kind of cluster, but it seems to mock out a lot of the more node/pod related behaviour, and as such it could become a slightly more reliable integration method / serve as a de-facto mock server (that's kind of a real apiserver).
We have not done any particular testing of this yet (and it's currently in a super early release), but noting this down. Have closed our older kube-test / envtest proposals in the past.

Thanks for the suggestion on using KWOK @clux. It's working really well on my tests, and I spin up multiple clusters of it using testcontainers. If you would like I could create a PR adding documentation about it.

Another big fan of Kwok + TestContainers here. It works incredibly well for our testing against Kube Client API.
We deleted the prior Kube mocking efforts in favour of Kwok and haven't looked back.

Do any of you have some good links to CI setups using kube + kwok? My main concern of using this over unit tests / mock integration tests is that you don't have the same level of test isolation out of the box? Or is this something that can be fixed trivially elsewhere?

I'm also looking for a way to simplify unit testing. Do you think an interface similar to mockito adapted to kube/k8s would also work? I made a small proof of concept that looks like the following:
let mut pod = Pod::default();
pod.metadata.name = Some("foo".into());

let mut created_pod = pod.clone();
created_pod.metadata.creation_timestamp =
    Some(Time(Utc.with_ymd_and_hms(2014, 7, 8, 9, 10, 11).unwrap()));

let mock = MockClient::default();
mock.namespaced::<Pod>("default")
    .create(&PostParams::default(), &pod)
    .respond_with(&created_pod)
    .build();

let client = Client::new(mock, "default");
let api = Api::<Pod>::namespaced(client, "default");
let p = api.create(&PostParams::default(), &pod).await.unwrap();
assert_eq!(created_pod, p);

The MockClient also checks that method, uri, etc of the request match the expectation. Writing tests would still be a little verbose, but it gives users full control over how the mocked api server behaves and is less complicated than mimicking the api server.
I'm happy to work on this and open a PR, if you think that this makes sense.

authors: Bakrog clux ianstanton markdingram rorosen

repo: kube-rs/kube


text:
0.87 release planned 🎃

Quite a bit in the milestone now and seems like a good time to do another release. particularly since we got a fix in the controller scheduler (and another timeout pass-down "fix")
particular stuff worth highlighting imo:

socks5
auth plugin work (although still some WIP there in #1331)
Controller::reconcile_on change (breaking, but it's for an unstable interface)
dep upgrades, syn upgrade caused a break on #[kube(struct)]

will likely hit it up later this evening.

ugh, failed mid release:
error[E0425]: cannot find value `connector` in this scope
   --> src/client/builder.rs:123:51
    |
123 |         let mut connector = TimeoutConnector::new(connector);
    |                                                   ^^^^^^^^^ not found in this scope

kube-core was the only one that made it through. yanked it;
cargo yank --version 0.87.0 kube-core
    Updating crates.io index
        Yank kube-core@0.87.0

Ok, we somehow uncovered a fault in CI testing here;  cargo test -p kube-client --no-default-features fails. Annoying because we do actually try to do a no-default-feature build of kube (*), just not all the underlying crates...
The problem in this case is the socks5 PR removing these 2 lines: https://github.com/kube-rs/kube/pull/1311/files#diff-1ab2824dd0a6633b63d18104f91fc5e7dfb07bb14a80c956af7b8af33162813bL78-L79 which are not reinstated in the new make_generic_builder for all cases. I.e. we can't create the service anymore in the case of no tls stack. i.e.
Not decided what to do yet for the release. Either we temporarily backout the PR or fix forwards. cc @Razz4780 . In either case, not doing the release tonight.

Ok, we somehow uncovered a fault in CI testing here; cargo test -p kube-client --no-default-features fails. Annoying because we do actually try to do a no-default-feature build of kube (*), just not all the underlying crates...
The problem in this case is the socks5 PR removing these 2 lines: https://github.com/kube-rs/kube/pull/1311/files#diff-1ab2824dd0a6633b63d18104f91fc5e7dfb07bb14a80c956af7b8af33162813bL78-L79 which are not reinstated in the new make_generic_builder for all cases. I.e. we can't create the service anymore in the case of no tls stack. i.e.
Not decided what to do yet for the release. Either we temporarily backout the PR or fix forwards. cc @Razz4780 . In either case, not doing the release tonight.

Wait, what exactly is the problem? cargo test -p kube-client --no-default-features works on main. Those two lines are still there in TryFrom<Config> implementation for GenericService. make_generic_builder accepts the base connector as an argument.

uh, i think the problem is that the make_generic_builder expects to use the base_connector in one of the feature-flagged lines below in https://github.com/kube-rs/kube/blob/main/kube-client/src/client/builder.rs#L113-L116, but if neither are true, then you don't actually have the connector variable in scope. the cargo test command i wrote does indeed work though :confused:

this fails at root in main:
cargo test -p kube --no-default-features --features=client

Ah, that's right. https://github.com/kube-rs/kube/pull/1335 fixes the issue

Seems we have both arrived at the same fix: https://github.com/kube-rs/kube/pull/1334
Appreciate it!

Btw. one line in the related code seems fishy - https://github.com/kube-rs/kube/pull/1335/files#diff-1ab2824dd0a6633b63d18104f91fc5e7dfb07bb14a80c956af7b8af33162813bL118
if auth_layer.is_none() || config.cluster_url.scheme() == Some(&http::uri::Scheme::HTTPS) {
    // no tls stack situation only works on anonymous auth with http scheme
    return Err(Error::TlsRequired);
}

I haven't checked the code thoroughly, but based on the comment it seems to me that it should rather be something like
if auth_layer.is_some() || config.cluster_url.scheme() != Some(&http::uri::Scheme::HTTP) {
    // no tls stack situation only works on anonymous auth with http scheme
    return Err(Error::TlsRequired);
}

hm, good spot. i think the auth_layer check might be leftover from my initial experiments. i suspect it's a worthless check, and the scheme check is doing all the heavy lifting.  the https scheme should be the only necessary condition for triggering the error (you could actually have an auth layer with basic auth without using https - and that shouldn't throw here)

Hi @clux it seems like version 0.86 is yanked, but I could not find any notes on why. This issue only mentions about 0.87 (which is not even listed on crates.io), but what happened to 0.86?

Hey @goenning , it was yanked as a result of https://github.com/kube-rs/kube/issues/1316#issuecomment-1823007062 to try to avoid having more people being bitten by a pretty bad controller bug that was linked to that release.

authors: Razz4780 clux goenning


text:
[Request] 支持在版本数据集页面直接创建数据处理任务

🥰 需求描述 | Feature Description
用户为了创建数据处理任务，必须要离开数据集页面，不太友好。建议允许用户直接在版本数据集页面直接创建数据处理任务
🧐 解决方案 | Proposed Solution

📝 补充信息 | Additional Information
No response

@liutianyi0801

repo: kubeagi/ops-console


text:
CI failure: when create online calico cluster, failed because of the calico related image pull rate is too slow

the default timeout time is 300s, but the pull image procedure spend about 300s, so the creation of cluster fails

/kind test

we can use to https://gist.github.com/yankay/52ec6efe6d49631e5f673a22eb5b1ca5 , to speed up :-)

authors: wenting-guo yankay

repo: kubean-io/kubean


text:
Sink doesn't react to filters updating

If you update the filters in a KubeArchiveConfig that already exists, the sink will not react to the update and will continue to use the old filters. The sink should be able to update the filters when the ConfigMap is updated to include the updated filters.
The work around for updating the KubeArchiveConfig is to delete the KubeArchiveConfig and create a new one with the desired filters

This happens because the files created in from the mounted ConfigMap are symlinks, so the underlying file does not update, but the file that the symlinks are pointing to

Keep in mind that if this gets too complex maybe its better to receive the filters with a POST request from the operator.

authors: rh-hemartin skoved

repo: kubearchive/kubearchive


text:
Github Action Tasks for KubeArmor

[x] Build
make build
[ ] Build Individual Commits
Ref https://github.com/cilium/cilium/commit/6b07a00a174a6b9b0391c756641ac26f08bee233
[ ] Code Coverage

go tool coverage
codecov

[ ] CodeQL Analysis / GoSec
[x] Go related Checks

[x] lint
[x] mod tidy

[ ] Testing

[x] Unit Test
make testall
[ ] Auto testing framework
https://github.com/accuknox/KubeArmor/blob/master/contribution/testing_guide.md

[ ] For different kernel versions
Github Actions allows to specify ubuntu 18.04/ ubuntu 20.04 as such, I am not sure if we can configure kernel versions

[ ] File Headers
[ ] GKE Workflow

[ ] Expand to add Azure and AWS when supported

[ ] Slack Integration

@daemon1024 Can you check ci-go.yml again?

Hey @nam-jaehyun , I looked through the fails earlier. It's due to the missing go.sum file.
Since go.sum was in the .gitignore earlier there was no change introduced by go mod tidy but now since it's not there, due to the missing file, go mod tidy introduces a change and hence failing the test.

I should detail out the error message more. I will send in a patch with go.sum and some refinements in ci, if it's fine with you?

I updated ci-go.yml a bit. Please check the file again and update it if some updates are needed

did you miss committing something?

Need make build-test before running the tests now.

Is it possible to have a check logic or an option for that?
While we need the coverage in the GitHub action, we don't need that in a local development environment.

Makes sense. I will modify the script accordingly.

repo: kubearmor/KubeArmor


text:
Give option to use different namespace when installing/uninstalling

Usage:
For installing
karmor install -n {namespace}
for uninstalling:
karmor uninstall -n {namespace}
I have added namespace flag for uninstall as well although it wasn't specified in the issue https://github.com/kubearmor/kubearmor-client/issues/21. I can remove it if it's not required.
I have tested this on local kind cluster.

Fixed #21

repo: kubearmor/kubearmor-client


text:
updating nodelist to get podIP instead of hostIP

in preparation for #1392
Kubearmor soon will not be using hostNetwork=true
which would mean that the IP of kubearmor daemonset will not be same as the node
hence getting podIP instead on hostIP

Is it possible to handle both the scenarios? What is the PodIP value when hostNetwork=true?

I got a response on slack that the podIP is same as hostIP when hostNetwork=true. Thus this will handle both cases.

repo: kubearmor/kubearmor-relay-server


text:
fix: fix websocket url err

Signed-off-by: moweiwei mo.weiwei@99cloud.net

What type of PR is this?

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

Fixes #31
Special notes for reviewers:

Does this PR introduced a user-facing change?

Additional documentation, usage docs, etc.:

/lgtm
/approve

authors: lysign moweiwei

repo: kubeclipper-labs/console


text:
Colorize duration & quantity

Description

Durations (3d12h) and quantities (5Gi) have been lacking colors.
Before

After

Type of change
Please delete options that are not relevant.

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

What you changed

Added color matching on duration and quantity
Also treat invalid as null

Why you think we should change it
Clearer to see values like resource requests and limits in outputs like kubectl describe
Related issue (if exists)
Closes #72, closes #73

lgtm but I guess you need to re-generate the schema ?
You can merge when you're good

lgtm but I guess you need to re-generate the schema ? You can merge when you're good

Oh, right, missed that part :sweat_smile:

repo: kubecolor/kubecolor


text:
Install instructions for v8.0.0

Due to bugfix https://github.com/kubedb/cli/pull/243, follow the instructions below to install a working chart v0.8.0 .
Uninstall via Helm
$ helm delete --purge kubedb-operator
$ kubectl delete validatingwebhookconfiguration -l app=kubedb || true
$ kubectl delete mutatingwebhookconfiguration -l app=kubedb || true
$ kubectl delete apiservice -l app=kubedb

Install via Helm
$ git clone https://github.com/kubedb/cli.git
$ cd cli
$ git checkout 987837d26c0b92705a8bdafde89206e4448c710b

# Now install from local directory
$ helm install kubedb --name kubedb-operator \
  --set apiserver.ca="$(onessl get kube-ca)" \
  --set apiserver.enableValidatingWebhook=true \
  --set apiserver.enableMutatingWebhook=true

From @soosap
  # Install kubedb-operator from source
  $ cd /Users/soosap/Documents/KubernetesProjects
  $ git clone https://github.com/kubedb/cli.git
  $ cd cli
  $ git checkout 987837d26c0b92705a8bdafde89206e4448c710b
  $ curl -fsSL https://raw.githubusercontent.com/kubedb/cli/0.8.0/hack/deploy/kubedb.sh | bash -s -- --uninstall --namespace=kube-system
  $ helm install \
  --set apiserver.ca="$(onessl get kube-ca)" \
  --set apiserver.enableValidatingWebhook=true \
  --set apiserver.enableMutatingWebhook=true \
  --name=kubedb-operator \
  --namespace=kube-system \
  ./chart/kubedb

repo: kubedb/project


text:
[Postgresql] ARM support

I'm new to kubedb and would like to find out if i can use this to build a cluster of postgre database in my raspberry pi using kubernetes (microk8s) so far i have tried the examples but didn't get any good results.
Wanna check if there is or has anyone tried to set this up in raspberry pi.
Thanks,

The operator runs, with version 0.13 on. I was able to run the operator with my k3s cluster on Pi4s:
helm template --namespace kube-system --release-name kubedb --set nodeSelector="" --version v0.13.0-rc.0 appscode/kubedb  | kubectl apply -f
However, the kubedb database images are still x86_64 only, so the managed databases fail with:

yeah.. so i ended up creating my own image that could do master - slave in my k8s cluster


text:
fix: aws containerRegistryURL metaphor duplication

This PR replicates #1774, which was gcp-only, for aws based on the reports by @alechp .

may resolve #1801

When I try to execute this PR, fails on Applying AWS KMS:
##################################################...............] [16m24s]
Error: open ~/.k1/<MY_CLOUD_NAME>/gitops/registry/<MY_CLOUD_NAME>/components/vault/application.yaml: no such file or directory

Previously resolved this by updating path:

While this resolved the AWS KMS issue, it still resulted in a StatefulSet issue:

According to @jarededwards they're working on a related fix for Civo:

Thanks for this PR @cameronraysmith. I'll get someone from the engineering team to review it, but it seems like @alechp may have found an issue with it.

@cameronraysmith: sorry about that, just noticed your commit isn't signed. Can you force pushed a new signed one.
⚠ This PR contains unsigned commits. To get your PR merged, please sign those commits (git commit -S --amend --no-edit) and force push them to this branch (git push --force-with-lease).
If you're new to commit signing, there are different ways to set it up:

Sign commits with gpg

Follow the steps below to set up commit signing with gpg:

Generate a GPG key
Add the GPG key to your GitHub account
Configure git to use your GPG key for commit signing

Sign commits with ssh-agent

Follow the steps below to set up commit signing with ssh-agent:

Generate an SSH key and add it to ssh-agent
Add the SSH key to your GitHub account
Configure git to use your SSH key for commit signing

Sign commits with 1Password

You can also sign commits using 1Password, which lets you sign commits with biometrics without the signing key leaving the local 1Password process.
Learn how to use 1Password to sign your commits.

If you don't want to go that route, I can create a PR to fix this for you, but I would really prefer you have your username associated with the fix :D

authors: alechp cameronraysmith fharper

repo: kubefirst/kubefirst


text:
release kubeflow-fairing 0.7 and add doc links

What this PR does / why we need it:

Release kubeflow-fairing 0.7
Add link for kubeflow-fairing API docs.

Which issue(s) this PR fixes :
Fixes #411

This change is

/assign @abhi-g

/lgtm
/approve
@jinchihe  let's also work with @sarahmaddox to figure out how to host the html docs on kubeflow.org website.

authors: abhi-g jinchihe

repo: kubeflow/fairing


text:
update onnx to a version that supports the v1 url format

Updated the default version to the latest patch
Update the example as well
The example doesnt yet use the client to create the service - will make that change in a later PR
Fixes #415
/assign @animeshsingh

This change is

/lgtm
/approve

authors: ellis-bigelow rakelkar

repo: kubeflow/kfserving


text:
.travis.yml: Add failure notification in GitHub

TravisBuddy will comment on pull requests in your public repository everytime a test failed in one of them. The comment will include only the part of the build log that applies to your testing framework, so your contributors won't have to enter Travis's website and search the long and annoying build log for the reason the tests failed.

It will help us to know the failures of Travis builds in GitHub notification page.
Signed-off-by: Ce Gao gaoce@caicloud.io

This change is

/assign @ScorpioCPH

Hey @gaocegege,
Something went wrong with the build.
TravisCI finished with status errored, which means the build failed because something unrelated to the tests, like a problem a dependency or the build process itself.

Coverage increased (+11.8%) to 61.654% when pulling 89d3a9d3ccaa411c33af57691a11d89fdb510be7 on gaocegege:travis into 556e2fc544d46f06a1f8212008fbe60248474f7f on kubeflow:master.

/retest

/lgtm

/approve

authors: ScorpioCPH TravisBuddy coveralls gaocegege

repo: kubeflow/tf-operator


text:
End-to-end story to use components cohesively since we position Kubeflow as a comprehensive platform

This issue is stemmed from https://github.com/kubeflow/community/pull/440, Restructuring Kubeflow docs proposal.
We have many excellent components. It requires some coordination and cooperation to make components working together smoothly, expecially for users without extensive experiences. It might be a bit more than documentation.
In particular, what do we do to guide users to use all components cohesively? Could there be a overall playbook to lead users stepping through their journey for ML end-to-end? How can users use components in the correct orders? How can they take results from one component and feed them into the next component?

Thank you for starting this @davidyuyuan !
I hope we can create such a guide in the near future

authors: RFMVasconcelos davidyuyuan

repo: kubeflow/website


text:
Getting started guide does not refer ks

The guide does not refer to ks but it is needed.
The error can be found here: https://github.com/kubeflow/kubeflow/issues/3132

This change is

@jomach please sign the CLA (see link posted above by googlebot).
/ok-to-test

update cla

/lgtm
/approve

authors: abhi-g jomach


text:
fix: correct the priority of ACL associated with security group

Pull Request

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

What type of this PR
Examples of user facing changes:

Bug fixes

Which issue(s) this PR fixes
当判断安全组对应下发的ACL规则是否已经存在时，判断时使用的优先级应该
是SecurityGroupHighestPriority（2300）- sgRule.Priority，而非直接使用sgRule.Priority去匹配ACL

@bobz965 could you help review this？

we need a doc to clarify the priority in sg and subnet acl,  the priority usage is different in the two cases.

we  need to fix this in release-1.11

we need a doc to clarify the priority in sg and subnet acl, the priority usage is different in the two cases.

https://github.com/kubeovn/docs/pull/185

hi @zhangzujian , could you please help review?

repo: kubeovn/kube-ovn


text:
check if velero crd directory exists

What this PR does / why we need it:
The custom velero chart is replaced with v2.26 and charts/backup/velero/crd directory does not exist anymore. Added a control if the directory is there to run the kubectl command, previous KKP versions should work fine.
Otherwise deployBackup() fails on v2.26.

/lgtm

/approve

authors: dharapvj koksay

repo: kubermatic/community-components


text:
Support for kubernetes v1.23.0 in e2e tests

Signed-off-by: Waleed Malik ahmedwaleedmalik@gmail.com
What this PR does / why we need it:
Support for Kubernetes v1.23.0
Which issue(s) this PR fixes (optional, in fixes #<issue number> format, will close the issue(s) when PR gets merged):
Fixes #1151 #1157
Special notes for your reviewer:
Supported k8s versions have been synced with what we will support from the dashboard/API in KKP:
* v1.20.14
* v1.21.8
* v1.22.5
* v1.23.0

Optional Release Note:

* Support for v1.23.0
* Remove tests for v1.19.15
* Bump hetzner terraform provider to 1.31.0

/hold

/unhold

/retest

/retest

/retest

/retest

repo: kubermatic/machine-controller


text:
Always ensure to have machine-delete-finalizer

What this PR does / why we need it:
After creating a new provider instance we always want to have the
machine-delete-finalizer. Possible provider specific finalizers can't be
deleted without it.
We have noted this especially for azure clusters, where the machine-controller doesn't try to run deleteCloudProvider instance because the finalizer machine-delete-finalizer is missing.
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:
Optional Release Note:

NONE

/assign @xrstf

/ok-to-test
/test all

Is there any progress on this? :)

Hey @phiphi282. Let me see if I got your problem right. With some providers (at least Azure) the instance is created requiring clean-up and an error returned at the same time by Create method. Is it correct?

The problem is with the deletion of the machine-delete-finalizer.
If the provider instance is created but the function returns an error, the machine-delete-finalizer will be deleted.
The cleanupCloudProviderInstance function is only trying to delete the cloud-provider instance when having this finalizer though. At least for azure this keeps the instances from getting deleted because there are azure specific finalizers that don't get cleaned up as well.

@phiphi282 Ok, I think I got your point right. Having an error returned by provider.Create() method does not necessarily mean that the instance clean-up logic should not be run. I will dig a bit to understand when and why this check was added.
Do you have an example at hand of error that is returned with Azure provider.Create() where instance clean-up is needed?

I kind of forgot what we did exactly unfortunately, but we created and deleted some instances relatively fast. I think this caused the machine to be created on the azure side but without completely finishing the creation.
The machine already got all azure related finalizers attached to it already which kept the machine from being deleted.
cc @eduardostalinho Maybe you can describe a bit better what to do to create the error.

I'm afraid that I don't have the logs here anymore.
But I remember we tried to deete a cluster that wasn't created properly (or in time) because of prov.Create and the deletion hanged because of this finalizer missing.

I think that this PR risks to have side effects. The fact that cluster deletion hanged as mentioned bu @eduardostalinho is probably because the instance was created despite the error returned by Create method, and this was preventing the deletion of subnet or some other resources.
The problem I see is that when Create fails and no instance is actually created, the Cleanup method could fail: https://github.com/kubermatic/machine-controller/blob/aec77a532b33ae1f4a04c6f7ef52a25e5e6aea41/pkg/controller/machine/machine.go#L557
causing the machine deletion to hang.

@PhillipAmend @eduardostalinho What I propose is to keep this on hold at the moment, wait for a re-occurrence of the issues to have a better understanding of what happened. Is it ok for you?

@irozzo-1A From what I could see in the provider code all Delete function check the existence of the Instance on the provider side first.
e.g aws:
instance, err := p.get(machine)
if err != nil {
	if err == cloudprovidererrors.ErrInstanceNotFound {
		return true, nil
	}
	return false, err
}

With this the machine deletion should not be hanging because of a failed delete. If we don't try to delete the machine at all however (because of the missing finalizer) the machine deletion will definitely hang when there are still other finalizers on the machine.
I would be okay for me to wait a bit but we probably won't have re-occurrence of the issue from our side, since we are already using this fix (and from what we can tell it works fine on openstack, aws and azure at least).

Hi @phiphi282, I agree that if all Cleaup methods for all providers can run safely even when Create did not complete successfully this PR should not have side effects. Knowing that this is already tested on AWS, Openstack and Azure is also reassuring.
I will take another look beginning of next week.

/lgtm

/approve

Thx for this contribution @phiphi282. I double-checked and I think you were right, this should not have side-effects. If we will observer regressions for some providers won't be critical.


text:
Remove log-flush-frequency flag

bootkube imports indirectly k8s.io/kubernetes/pkg/util.logs, which is creating the global flag:
var logFlushFreq = pflag.Duration("log-flush-frequency", 5*time.Second, "Maximum number of seconds between log flushes")

As far as I can guess, this flag will not be used in bootkube, but it shows up through the Usage function.
$ ./bootkube version -h
Output version information

Usage:
  bootkube version [flags]

Global Flags:
      --log-flush-frequency=5s: Maximum number of seconds between log flushes

Can the flag be removed?

closed in https://github.com/kubernetes-incubator/bootkube/pull/143

authors: aaronlevy odacremolbap

repo: kubernetes-incubator/bootkube


text:
StopPodSandbox() fails if one of the containers already terminated

When doing the following sequence:
$ ocic pod create --config test/testdata/sandbox_config.json
4872be98ea3a0339d1caf3383b47c4618a67559d7f0cb326d088429e56ee5e5b

$ ocic container create --config test/testdata/container_config.json --pod 4872be98ea3a0339d1caf3383b47c4618a67559d7f0cb326d088429e56ee5e5b
fd344d78a53a974de5d0ebd02fdddb6f3f86a2ec06f17535dac11515aa9e5233

$ ocic  container start --id fd344d78a53a974de5d0ebd02fdddb6f3f86a2ec06f17535dac11515aa9e5233
fd344d78a53a974de5d0ebd02fdddb6f3f86a2ec06f17535dac11515aa9e5233

$ ocic pod stop --id 4872be98ea3a0339d1caf3383b47c4618a67559d7f0cb326d088429e56ee5e5b
FATA[0000] stopping the pod sandbox failed: rpc error: code = 2 desc = failed to stop container intel-5.test.ocid-podsandbox1-1-container1-1 in sandbox 4872be98ea3a0339d1caf3383b47c4618a67559d7f0cb326d088429e56ee5e5b: `/usr/local/sbin/runc kill intel-5.test.ocid-podsandbox1-1-container1-1` failed: exit status 1

And ocid gives me the following error:
container_linux.go:287: signaling init process caused "os: process already finished"

I feel creating, starting and terminating a container within a pod should not prevent us from stopping the pod. Please close this issue if this is a wrong assumption.

@runcom @mrunalp Also, are we expecting the sandbox networking namespace to be closed and removed on a StopPodSandbox() call ?

@sameo the reproducer you wrote in your first comment is not about network afaict, it's a wrong stuff happening within pod stop (which I'm trying to fix). Please open another issue for the netns issue.

@runcom oops, sorry wrong issue.

authors: runcom sameo

repo: kubernetes-incubator/cri-o


text:
1.9: container_status: expose LogPath as requested by the CRI

Signed-off-by: Antonio Murdaca runcom@redhat.com
Backport to 1.9
@runcom @rhatdan PTAL

/test all

/test integration_fedora

/test e2e_fedora

LGTM, silly us

/test integration_fedora
/test e2e_fedora

/retest

We are currently running into issues using crictl logs in our deployments and this ultimately seems to fix the issue. Are there plans to release a new 1.9.x? (we need that fix quite soon and I am considering to just patch our package for a given time)

We are currently running into issues using crictl logs in our deployments and this ultimately seems to fix the issue. Are there plans to release a new 1.9.x? (we need that fix quite soon and I am considering to just patch our package for a given time)

we  will tag a new 1.9.x release after we merge this for sure :)

/retest

Looks like we are hitting https://github.com/kubernetes/kubernetes/issues/58956 in the tests.

I have added a commit to update the k8s deps.

/test all

/test e2e_fedora

/test e2e_rhel

/test e2e

LGTM

/test e2e_rhel

This can be merged.

👍

authors: feiskyer mrunalp rhatdan runcom vrothberg


text:
Reserve resources for calico typha

Calico-typha does not have any reserved resource so it works in a best effort mode. Since it is a 'system service' it should have some resources reserved. What do you think?

Good idea!  In which case they should be configurable via the cluster.yaml so that users can increase them if the defaults prove too small.  Can you add them in as options?

Codecov Report

Merging #1607 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master    #1607   +/-   ##
=======================================
  Coverage   25.49%   25.49%
=======================================
  Files          97       97
  Lines        5060     5060
=======================================
  Hits         1290     1290
  Misses       3625     3625
  Partials      145      145

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 00746e2...a593004. Read the comment docs.

Any chance you could sign the CLA and address David's comments @zonzamas?

Hi, Im have it sing already with the other email I used to use to contribute to kube-aws. I will definitely revisit this when I have some free time or when I need it for my current company.

I signed it

Thanks @zonzamas, I'd still like to see this be configurable through cluster.yaml before merging. Could you take a look at doing that?

Sure, how about this?

/lgtm

Hi, many thanks - would you be so kind as to cherry-pick this change and PR to our v0.13.x branch and v0.14.x branch?  That way your change will go out with those upcoming updates rather than when v0.15.x is released.  Thanks for your contribution! 🙏

authors: DominicGunn codecov-io davidmccormick dominicgunn zonzamas

repo: kubernetes-incubator/kube-aws


text:
metrics-server pod status is CrashLoopBackOff

I deployed metric-server, but when I executed the kubectl get pod -n kube-system command, the status was displayed as CrashLoopBackOff and logs prompted the certificate and 443 questions
[root@k8s-master metrics-server]# kubectl logs metrics-server-v0.3.3-97f4998dd-hkzg7 -c metrics-server -n kube-system
Flag --deprecated-kubelet-completely-insecure has been deprecated, This is rarely the right option, since it leaves kubelet communication completely insecure.  If you encounter auth errors, make sure you've enabled token webhook auth on the Kubelet, and if you're in a test cluster with self-signed Kubelet certificates, consider using kubelet-insecure-tls instead.
I0707 12:42:21.147086       1 serving.go:312] Generated self-signed cert (apiserver.local.config/certificates/apiserver.crt, apiserver.local.config/certificates/apiserver.key)
I0707 12:42:21.720984       1 secure_serving.go:116] Serving securely on [::]:443

My kube-apiserver and mars-server configurations are as follows:
--etcd-cafile=/usr/local/etcd/ssl/ca.pem
--etcd-certfile=/usr/local/etcd/ssl/etcd.pem
--etcd-keyfile=/usr/local/etcd/ssl/etcd-key.pem
--requestheader-client-ca-file=/usr/local/kubernetes/ssl/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=/usr/local/kubernetes/ssl/kube-proxy.pem
--proxy-client-key-file=/usr/local/kubernetes/ssl/kube-proxy-key.pem
--enable-aggregator-routing=true"
The api-server service has been restarted after the configuration changes, and the service is running normally. So I don't know what the problem is yet

repo: kubernetes-incubator/metrics-server


text:
API server crashes when installed on Minikube

After installing service-catalog on Minikube running Kubernetes v1.7.0 (see install doc), the API server crashes with the following log message:
F0829 23:19:24.357279       1 server.go:128] error running server (cluster doesn't provide requestheader-client-ca-file)

This repros on Azure with ACS too.
uday@k8s-master-18734654-0:~/service-catalog/docs/certs$ kubectl logs -n catalog catalog-catalog-apiserver-694180667-prlf1 apiserver

I0928 11:30:15.117237       1 server.go:103] using etcd for storage
I0928 11:30:15.117668       1 run_server.go:105] Preparing to run API server
I0928 11:30:17.521780       1 round_trippers.go:386] curl -k -v -XGET  -H "Accept: application/json, */*" -H "User-Agent: apiserver/v1.7.0+$Format:%h$ (linux/amd64) kubernetes/$Format" -H "Authorization: Bearer eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJrdWJlcm5ldGVzL3NlcnZpY2VhY2NvdW50Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9uYW1lc3BhY2UiOiJjYXRhbG9nIiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9zZWNyZXQubmFtZSI6InNlcnZpY2UtY2F0YWxvZy1hcGlzZXJ2ZXItdG9rZW4tZDBkc2MiLCJrdWJlcm5ldGVzLmlvL3NlcnZpY2VhY2NvdW50L3NlcnZpY2UtYWNjb3VudC5uYW1lIjoic2VydmljZS1jYXRhbG9nLWFwaXNlcnZlciIsImt1YmVybmV0ZXMuaW8vc2VydmljZWFjY291bnQvc2VydmljZS1hY2NvdW50LnVpZCI6ImU3ZTFmYTU2LWE0M2YtMTFlNy1iOGM4LTAwMGQzYTJhYmUzZSIsInN1YiI6InN5c3RlbTpzZXJ2aWNlYWNjb3VudDpjYXRhbG9nOnNlcnZpY2UtY2F0YWxvZy1hcGlzZXJ2ZXIifQ.n4caJq2FwfpJHcGIublCrMRAzfyr6Dq9IpfqANV5OWHiRHds-YeaWCKu5pMxsdHnz_Hin8MznUMtFwjtgox9LgAeMJXG5JTzkyzCy03Ufq-dlUosSnFSnXhYQIjAxNmMnEGk5J9zuNNaK8yHvaEShofdq9eRdIkumnMVCrNfVnudoBu85VuNQd4NgNPJQclfbX-5pGJRJJ2-3lKDRd9_F4gsyACOCLxRwZ8ncSCtqfEPwvX8UyI_3T03efe_eH7xWyc-MIiQjSWFfuOQXqXqSBqUt_V0OjWH8Cf5BipepThdxkxu6xsogh778e9UyqPeTm0GU-eQUnPJ_lOvJEmghwKe_vzNysIOuBz7kBW6bSBFbBHjPRzeMFJkT4HmAAeq434850nohU41G9fUsHOwPHip53-uS3RoMtQRfruiNudXnvk4Ny45RX8XKHkB-uocrd9XM9Z5e95GS-_KcKTk_QUeIGCLuPZzqh2LANBflOcr3znODwQ_3yWVIbs8hv8bLjWQiTrf_H6IDICPMSZu2tq5CJe8NNITZPU-nk9gqBQSJcge2NM2p1l6wlOFL2T8pXMeTe-dXaCLsQAmn4MhQiQk1V-YXWE93Y3REXQxWtw0USy2lb8SLV1b9qMgu-k_lcsBe52D3YvsP1_w-VT967iwtZmtC5DiB2805cP9iAQ" https://10.0.0.1:443/api/v1/namespaces/kube-system/configmaps/extension-apiserver-authentication
I0928 11:30:17.709277       1 round_trippers.go:405] GET https://10.0.0.1:443/api/v1/namespaces/kube-system/configmaps/extension-apiserver-authentication 200 OK in 187 milliseconds
I0928 11:30:17.709370       1 round_trippers.go:411] Response Headers:
I0928 11:30:17.709391       1 round_trippers.go:414]     Content-Length: 2100
I0928 11:30:17.709404       1 round_trippers.go:414]     Date: Thu, 28 Sep 2017 11:30:17 GMT
I0928 11:30:17.709416       1 round_trippers.go:414]     Content-Type: application/json
I0928 11:30:17.709477       1 request.go:991] Response Body: {"kind":"ConfigMap","apiVersion":"v1","metadata":{"name":"extension-apiserver-authentication","namespace":"kube-system","selfLink":"/api/v1/namespaces/kube-system/configmaps/extension-apiserver-authentication","uid":"3b8be5bd-a3b2-11e7-b8c8-000d3a2abe3e","resourceVersion":"59","creationTimestamp":"2017-09-27T18:32:35Z"},"data":{"client-ca-file":"-----BEGIN CERTIFICATE-----\nMIIEyDCCArCgAwIBAgIRAMDdK12nWi0okA2Utqvc0v0wDQYJKoZIhvcNAQELBQAw\nDTELMAkGA1UEAxMCY2EwHhcNMTcwOTI3MTc1NzUyWhcNMTkwOTI3MTc1NzUyWjAN\nMQswCQYDVQQDEwJjYTCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBAJTv\n6XRh8I8QL8NJZwkDCxG7umZ9yDFXkmZECWS/Co8H4GsxY4mBo7MlfdEFvmVmP/DM\nED/gUQV4bUOMia2qnOq0JhwIw/F3snmAT713Qok7tABZntRWKFTx3lWhVZ9iSauJ\n2Et8XkKVybM1ahWgLdFAoKY5hCxbsVpDF8fvHDwrmjLrihc2tFlLZmEzj9Gh+ESj\neEieR2l1Weg160k/EuWWFjecJDvfWb6DuiGdYMmZFkuaXFvCfw2oc0SAGMZXXGYu\nrwHD2VItuU6JisoSQ0MbiFkMbipNOWVhOo6x/jI+kUQCkJG1SW5Wga9Eu25axnBa\n2VLJQRyrwsfBsfs9N2HiqBAPtaKtf09NnHbb2sFAsQQJteD9H+mEbnp/TXzy/NNB\nyPmVK8D5vc3u4Nx8xPca+Voxd5cgfyTuaFiMh9Gndd1niORCmRODtmR79W+EjotA\nocE3Kl60I7fOj7+wIw7oiMS5cXV/EuuiXgNIVlH2ENRd49V7BzZ1dGenOclRuH5b\nYA4MOy5IvZHTCZO6vg2zGP7UC8N0AqyZd4fiVamlBSOx59Amxi8M0ZQCpXLVdsKv\nv75g53750GciHmfA3B3hhzJLmocCOIYpnPyd7q0wb1alvqFMTfrnY0LK8WGRuDAD\nbT7A05clTmotxqQf/xbwg7z92RYQX0BB2JxRtElfAgMBAAGjIzAhMA4GA1UdDwEB\n/wQEAwICpDAPBgNVHRMBAf8EBTADAQH/MA0GCSqGSIb3DQEBCwUAA4ICAQAJFDgJ\n1N4H4TE9ghCCk5wlqEEPLeRfOeUGrJgJJq7FC2wtuyT3th/BS4yYkZXCiiPs0itd\nWOpsMNMpDuTSpKFcWSIWawUihv9kVplFAsIXZh626H1EjedR9LQQ3DhfnUMHTEAh\nwO8elCzH4Gvp3mC2qvpIDNBGd8Vit5ZNPVZr/Ax6ol/J4V7RnxDx5yk1aMvg4m9v\nA7cdx4MwiqUyxz1HfPMgjsGppj+fsAP40cEbGv/NdzveZkJqS0eGe+M8qHdkJnfq\n8izy8yZIzGze3hMNhHl7x60aDNnhoEU+ni3/ZGn+eD0End5HRWalsh2hnqKXnQ8V\nztFtLTIK+rmQ3sI9DndaxtujqnBBuMn0jkm2KwkxuPq1zEuIoO3krSd7jz+31JLH\nQf+6embqcQRMGwR1pXgFvlrpzfdxeMUnSQAVjAziVAarGTjpIdulY+fGD5bLdn+P\nRSHKwdbf2GRzAMZ3SaGEhTN9Obv1I1R3h2OQmH68Hz6LMc7hdVtaFE+scgRhuQvh\nRxiZIBaa1ZCTjDrQWns9psuAzvZBaHUYzf/6Ib5XEnO9IYoPqKW/75C1rFE15Ofx\nuxyTYwjEu7AVQ6WaPl5M5/afhBoOn0Hbu5eqVZCeRv4HwpQUYEbF8bwn/+q4gaHN\nLnYNf2CF9Ii7iDxqtGPwpeiGRTYc7MKfHGv8KQ==\n-----END CERTIFICATE-----\n"}}
I0928 11:30:17.710565       1 round_trippers.go:386] curl -k -v -XGET  -H "User-Agent: apiserver/v1.7.0+$Format:%h$ (linux/amd64) kubernetes/$Format" -H "Authorization: Bearer eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJrdWJlcm5ldGVzL3NlcnZpY2VhY2NvdW50Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9uYW1lc3BhY2UiOiJjYXRhbG9nIiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9zZWNyZXQubmFtZSI6InNlcnZpY2UtY2F0YWxvZy1hcGlzZXJ2ZXItdG9rZW4tZDBkc2MiLCJrdWJlcm5ldGVzLmlvL3NlcnZpY2VhY2NvdW50L3NlcnZpY2UtYWNjb3VudC5uYW1lIjoic2VydmljZS1jYXRhbG9nLWFwaXNlcnZlciIsImt1YmVybmV0ZXMuaW8vc2VydmljZWFjY291bnQvc2VydmljZS1hY2NvdW50LnVpZCI6ImU3ZTFmYTU2LWE0M2YtMTFlNy1iOGM4LTAwMGQzYTJhYmUzZSIsInN1YiI6InN5c3RlbTpzZXJ2aWNlYWNjb3VudDpjYXRhbG9nOnNlcnZpY2UtY2F0YWxvZy1hcGlzZXJ2ZXIifQ.n4caJq2FwfpJHcGIublCrMRAzfyr6Dq9IpfqANV5OWHiRHds-YeaWCKu5pMxsdHnz_Hin8MznUMtFwjtgox9LgAeMJXG5JTzkyzCy03Ufq-dlUosSnFSnXhYQIjAxNmMnEGk5J9zuNNaK8yHvaEShofdq9eRdIkumnMVCrNfVnudoBu85VuNQd4NgNPJQclfbX-5pGJRJJ2-3lKDRd9_F4gsyACOCLxRwZ8ncSCtqfEPwvX8UyI_3T03efe_eH7xWyc-MIiQjSWFfuOQXqXqSBqUt_V0OjWH8Cf5BipepThdxkxu6xsogh778e9UyqPeTm0GU-eQUnPJ_lOvJEmghwKe_vzNysIOuBz7kBW6bSBFbBHjPRzeMFJkT4HmAAeq434850nohU41G9fUsHOwPHip53-uS3RoMtQRfruiNudXnvk4Ny45RX8XKHkB-uocrd9XM9Z5e95GS-_KcKTk_QUeIGCLuPZzqh2LANBflOcr3znODwQ_3yWVIbs8hv8bLjWQiTrf_H6IDICPMSZu2tq5CJe8NNITZPU-nk9gqBQSJcge2NM2p1l6wlOFL2T8pXMeTe-dXaCLsQAmn4MhQiQk1V-YXWE93Y3REXQxWtw0USy2lb8SLV1b9qMgu-k_lcsBe52D3YvsP1_w-VT967iwtZmtC5DiB2805cP9iAQ" -H "Accept: application/json, */*" https://10.0.0.1:443/api/v1/namespaces/kube-system/configmaps/extension-apiserver-authentication
I0928 11:30:17.815406       1 round_trippers.go:405] GET https://10.0.0.1:443/api/v1/namespaces/kube-system/configmaps/extension-apiserver-authentication 200 OK in 104 milliseconds
I0928 11:30:17.815426       1 round_trippers.go:411] Response Headers:
I0928 11:30:17.815430       1 round_trippers.go:414]     Content-Type: application/json
I0928 11:30:17.815433       1 round_trippers.go:414]     Content-Length: 2100
I0928 11:30:17.815436       1 round_trippers.go:414]     Date: Thu, 28 Sep 2017 11:30:17 GMT
I0928 11:30:17.815466       1 request.go:991] Response Body: {"kind":"ConfigMap","apiVersion":"v1","metadata":{"name":"extension-apiserver-authentication","namespace":"kube-system","selfLink":"/api/v1/namespaces/kube-system/configmaps/extension-apiserver-authentication","uid":"3b8be5bd-a3b2-11e7-b8c8-000d3a2abe3e","resourceVersion":"59","creationTimestamp":"2017-09-27T18:32:35Z"},"data":{"client-ca-file":"-----BEGIN CERTIFICATE-----\nMIIEyDCCArCgAwIBAgIRAMDdK12nWi0okA2Utqvc0v0wDQYJKoZIhvcNAQELBQAw\nDTELMAkGA1UEAxMCY2EwHhcNMTcwOTI3MTc1NzUyWhcNMTkwOTI3MTc1NzUyWjAN\nMQswCQYDVQQDEwJjYTCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBAJTv\n6XRh8I8QL8NJZwkDCxG7umZ9yDFXkmZECWS/Co8H4GsxY4mBo7MlfdEFvmVmP/DM\nED/gUQV4bUOMia2qnOq0JhwIw/F3snmAT713Qok7tABZntRWKFTx3lWhVZ9iSauJ\n2Et8XkKVybM1ahWgLdFAoKY5hCxbsVpDF8fvHDwrmjLrihc2tFlLZmEzj9Gh+ESj\neEieR2l1Weg160k/EuWWFjecJDvfWb6DuiGdYMmZFkuaXFvCfw2oc0SAGMZXXGYu\nrwHD2VItuU6JisoSQ0MbiFkMbipNOWVhOo6x/jI+kUQCkJG1SW5Wga9Eu25axnBa\n2VLJQRyrwsfBsfs9N2HiqBAPtaKtf09NnHbb2sFAsQQJteD9H+mEbnp/TXzy/NNB\nyPmVK8D5vc3u4Nx8xPca+Voxd5cgfyTuaFiMh9Gndd1niORCmRODtmR79W+EjotA\nocE3Kl60I7fOj7+wIw7oiMS5cXV/EuuiXgNIVlH2ENRd49V7BzZ1dGenOclRuH5b\nYA4MOy5IvZHTCZO6vg2zGP7UC8N0AqyZd4fiVamlBSOx59Amxi8M0ZQCpXLVdsKv\nv75g53750GciHmfA3B3hhzJLmocCOIYpnPyd7q0wb1alvqFMTfrnY0LK8WGRuDAD\nbT7A05clTmotxqQf/xbwg7z92RYQX0BB2JxRtElfAgMBAAGjIzAhMA4GA1UdDwEB\n/wQEAwICpDAPBgNVHRMBAf8EBTADAQH/MA0GCSqGSIb3DQEBCwUAA4ICAQAJFDgJ\n1N4H4TE9ghCCk5wlqEEPLeRfOeUGrJgJJq7FC2wtuyT3th/BS4yYkZXCiiPs0itd\nWOpsMNMpDuTSpKFcWSIWawUihv9kVplFAsIXZh626H1EjedR9LQQ3DhfnUMHTEAh\nwO8elCzH4Gvp3mC2qvpIDNBGd8Vit5ZNPVZr/Ax6ol/J4V7RnxDx5yk1aMvg4m9v\nA7cdx4MwiqUyxz1HfPMgjsGppj+fsAP40cEbGv/NdzveZkJqS0eGe+M8qHdkJnfq\n8izy8yZIzGze3hMNhHl7x60aDNnhoEU+ni3/ZGn+eD0End5HRWalsh2hnqKXnQ8V\nztFtLTIK+rmQ3sI9DndaxtujqnBBuMn0jkm2KwkxuPq1zEuIoO3krSd7jz+31JLH\nQf+6embqcQRMGwR1pXgFvlrpzfdxeMUnSQAVjAziVAarGTjpIdulY+fGD5bLdn+P\nRSHKwdbf2GRzAMZ3SaGEhTN9Obv1I1R3h2OQmH68Hz6LMc7hdVtaFE+scgRhuQvh\nRxiZIBaa1ZCTjDrQWns9psuAzvZBaHUYzf/6Ib5XEnO9IYoPqKW/75C1rFE15Ofx\nuxyTYwjEu7AVQ6WaPl5M5/afhBoOn0Hbu5eqVZCeRv4HwpQUYEbF8bwn/+q4gaHN\nLnYNf2CF9Ii7iDxqtGPwpeiGRTYc7MKfHGv8KQ==\n-----END CERTIFICATE-----\n"}}
F0928 11:30:17.915883       1 server.go:131] error running server (cluster doesn't provide requestheader-client-ca-file)

Oooh! Thanks @uday31in! We were talking about closing this yesterday. Does #1173 help you?

I have used following command from PR however PODS are still failing with error below:
uday@k8s-master-18734654-0:~/service-catalog/docs/certs$ helm install ../../charts/catalog  --name ${HELM_RELEASE_NAME} --namespace ${SVCCAT_NAMESPACE}     --set apiserver.auth.enabled=true         --set useAggregator=true         --set apiserver.tls.ca=$(base64 --wrap 0 ${SC_SERVING_CA})         --set apiserver.tls.cert=$(base64 --wrap 0 ${SC_SERVING_CERT})         --set apiserver.tls.key=$(base64 --wrap 0 ${SC_SERVING_KEY})         --set apiserver.tls.requestHeaderCA=$(base64 --wrap 0  ${SC_SERVING_CA})
I0928 16:24:42.328013       1 util.go:145] Admission control plugin names: [KubernetesNamespaceLifecycle DefaultServicePlan ServiceInstanceCredentialsLifecycle ServicePlanChangeValidator BrokerAuthSarCheck KubernetesNamespaceLifecycle DefaultServicePlan ServiceInstanceCredentialsLifecycle ServicePlanChangeValidator BrokerAuthSarCheck]
F0928 16:24:42.328247       1 server.go:128] error running server (failed to initialize admission: Unknown admission plugin: ServiceInstanceCredentialsLifecycle)

Is this still an issue?  Might have to be in 0.1.1 if no one can get to it first.

Fixed in latest release of Minikube, closing

authors: MHBauer arschles pmorie uday31in

repo: kubernetes-incubator/service-catalog


text:
Add fields scope and namespace to svcat describe class output

This PR is a

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

What this PR does / why we need it:
This PR add two new fields scope and namespace to the svcat describe command.
Which issue(s) this PR fixes

Fixes #2215
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

/cc @carolynvs

@carolynvs, addressed your comments, PTAL

@jboyd01, could you take a look at this whenever you find some time?

/assign @jboyd01, @carolynvs
This is ready for a final review! 😄

/assign @jboyd01
Could you PTAL?


text:
Re-consider build dependency on tonistiigi/xx

We added a build tool for cross-compilation in https://github.com/kubernetes-sigs/blixt/pull/184:
https://github.com/kubernetes-sigs/blixt/blob/5428487fe560e05dac5eea7c7fd8d22d50388cd5/controlplane/Dockerfile#L1
This is a follow up on our previous conversation to make sure we don't forget to re-assess this dependency, and given it's place in the supply-chain decide definitively whether we need it or whether it would be straightforward to supply something ourselves.

/triage needs-information

Can I take ownership of this issue ?

repo: kubernetes-sigs/blixt


text:
kubefnord join failed

root@gyliu-dev1:~/go/src/github.com/kubernetes-sigs/federation-v2# ./bin/kubefnord join cluster138.k8s.local --host-cluster-context cluster138.k8s.local --add-to-registry --v=2
ERROR: logging before flag.Parse: I0705 06:17:36.583065    3075 join.go:125] Defaulting cluster context to joining cluster name cluster138.k8s.local
ERROR: logging before flag.Parse: I0705 06:17:36.583150    3075 join.go:129] Args and flags: name cluster138.k8s.local, host: cluster138.k8s.local, host-system-namespace: federation-system, kubeconfig: , cluster-context: cluster138.k8s.local, secret-name: , dry-run: false
ERROR: logging before flag.Parse: I0705 06:17:36.589103    3075 join.go:183] Performing preflight checks.
ERROR: logging before flag.Parse: I0705 06:17:36.611982    3075 join.go:270] Registering cluster with the cluster registry.
ERROR: logging before flag.Parse: I0705 06:17:36.621322    3075 join.go:278] Registered cluster with the cluster registry.
ERROR: logging before flag.Parse: I0705 06:17:36.621351    3075 join.go:204] Creating federation-system namespace in joining cluster
ERROR: logging before flag.Parse: I0705 06:17:36.636999    3075 join.go:212] Created federation-system namespace in joining cluster
ERROR: logging before flag.Parse: I0705 06:17:36.637048    3075 join.go:215] Creating cluster credentials secret
ERROR: logging before flag.Parse: I0705 06:17:36.637059    3075 join.go:404] Creating service account in joining cluster
ERROR: logging before flag.Parse: I0705 06:17:36.652299    3075 join.go:413] Created service account in joining cluster
ERROR: logging before flag.Parse: I0705 06:17:36.652333    3075 join.go:415] Creating role binding for service account in joining cluster
ERROR: logging before flag.Parse: I0705 06:17:36.676963    3075 join.go:525] Could not create cluster role binding for service account in joining cluster: ClusterRoleBinding.rbac.authorization.k8s.io "federation-controller-manager:cluster138.k8s.local-cluster138.k8s.local" is invalid: subjects[0].namespace: Required value
ERROR: logging before flag.Parse: I0705 06:17:36.677000    3075 join.go:420] Error creating role binding for service account in joining cluster: ClusterRoleBinding.rbac.authorization.k8s.io "federation-controller-manager:cluster138.k8s.local-cluster138.k8s.local" is invalid: subjects[0].namespace: Required value
ERROR: logging before flag.Parse: I0705 06:17:36.677011    3075 join.go:221] Could not create cluster credentials secret: ClusterRoleBinding.rbac.authorization.k8s.io "federation-controller-manager:cluster138.k8s.local-cluster138.k8s.local" is invalid: subjects[0].namespace: Required value
ERROR: logging before flag.Parse: F0705 06:17:36.677025    3075 join.go:105] error: ClusterRoleBinding.rbac.authorization.k8s.io "federation-controller-manager:cluster138.k8s.local-cluster138.k8s.local" is invalid: subjects[0].namespace: Required value

/assign


text:
HTTPRequestRedirectFilter allows for wildcard hostnames

What happened:
Looking through the HTTPRequestRedirectFilter spec, the Hostname used has a default kubebuilder validation regex which would allow a user to specify a redirect of *.foo.com which might not make sense as a redirect hostname.
Controllers could catch this and set a condition, we could update the field to use a new hostname type which removes the ability to have a wildcard in the value, or maybe there's a use-case I'm not thinking of that folks would want this?
What you expected to happen:
Hostnames with wildcards would be rejected.
How to reproduce it (as minimally and precisely as possible):
Here's a sample HTTPRoute:
kind: HTTPRoute
apiVersion: gateway.networking.k8s.io/v1alpha2
metadata:
  name: kuard
  namespace: projectcontour
  labels:
    app: kuard
spec:
  parentRefs:
  - group: gateway.networking.k8s.io
    kind: Gateway
    name: contour
  hostnames:
  - "local.projectcontour.io"
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /
    filters:
      - requestRedirect:
          hostname: "*.stevesloka.com"
          scheme: https
          statusCode: 302
        type: RequestRedirect
    backendRefs:
    - kind: Service
      name: kuard
      port: 80

Right now Contour configures Envoy:
$ curl -i local.projectcontour.io
HTTP/1.1 302 Found
location: https://*.stevesloka.com/
vary: Accept-Encoding
date: Tue, 30 Nov 2021 17:37:35 GMT
server: envoy
content-length: 0

But doesn't route properly:

Controllers could catch this and set a condition, we could update the field to use a new hostname type which removes the ability to have a wildcard in the value, or maybe there's a use-case I'm not thinking of that folks would want this?

https://github.com/kubernetes-sigs/gateway-api/blob/88013b553e8c30d27a4cab49e2fb9e52b016dbc8/apis/v1alpha2/httproute_types.go#L678-L685
My reading of the spec is the hostname of the request should be used as is - not the hostname defined in the route rule. So if the request is foo.example.com and the route hostname is *.example.com, the location header has foo.exampl.com as the hostname.

I agree with what you said @hbagdi, maybe we're confusing two different bits.
In my example above, my route hostname is local.projectcontour.io which is matched on the incoming request, but the route match has a redirect to *.stevesloka.com, so the response has the HTTP 302 set with a Location: *.stevesloka.com which would be invalid (or just not make much sense).

Yeah, I agree that the hostname in a redirect shouldn't be able to be a wildcard, it should be a precise hostname.

Ah, I understood this wrong.
This needs an update to the validation function for HTTPRoute which then should be executed in the validation webhook.

Could we just introduce a new type referenced here (https://github.com/kubernetes-sigs/gateway-api/blob/06754c50eb5a0e351203e31d60ce0517daeba735/apis/v1alpha2/httproute_types.go#L743) which removes the wildcard from the beginning? This way you would't need the admission controller change at all and just rely on the kubebuilder validation.
Happy to work on this!

Could we just introduce a new type

Agree, this is probably the best approach. Maybe we have WildcardHostname to represent the current value and Hostname that does not allow for wildcard values.

Yup makes sense to me. I can take this up and get it updated.

authors: hbagdi robscott stevesloka youngnick

repo: kubernetes-sigs/gateway-api


text:
add a tensorflow example and update task documentation

Fixes #78
I wanted to add some documentation updates to tasks also as the above story says "to add a task" but we had no writeup in tasks.  I decided to link to examples and write some words around these examples.
Added a really simple example for Tensorflow.  I used https://github.com/kubeflow/training-operator/blob/master/examples/tensorflow/simple.yaml as a template.
There are some issues with this one actually.
The logs of the pods have some warnings around deprecations.
[ec2-user@ip-172-31-93-184 jobset-kevin]$ kubectl logs tensorflow-tensorflow-0-0-5l6bb
WARNING:tensorflow:From /var/tf_mnist/mnist_with_summaries.py:39: read_data_sets (from tensorflow.contrib.learn.python.learn.datasets.mnist) is deprecated and will be removed in a future version.
Instructions for updating:
Please use alternatives such as official/mnist/dataset.py from tensorflow/models.
WARNING:tensorflow:From /usr/local/lib/python2.7/dist-packages/tensorflow/contrib/learn/python/learn/datasets/mnist.py:260: maybe_download (from tensorflow.contrib.learn.python.learn.datasets.base) is deprecated and will be removed in a future version.
Instructions for updating:
Please write your own downloading logic.
WARNING:tensorflow:From /usr/local/lib/python2.7/dist-packages/tensorflow/contrib/learn/python/learn/datasets/base.py:252: wrapped_fn (from tensorflow.contrib.learn.python.learn.datasets.base) is deprecated and will be removed in a future version.
Instructions for updating:
Please use urllib or similar directly.
WARNING:tensorflow:From /usr/local/lib/python2.7/dist-packages/tensorflow/contrib/learn/python/learn/datasets/mnist.py:262: extract_images (from tensorflow.contrib.learn.python.learn.datasets.mnist) is deprecated and will be removed in a future version.
Instructions for updating:
Please use tf.data to implement this functionality.
WARNING:tensorflow:From /usr/local/lib/python2.7/dist-packages/tensorflow/contrib/learn/python/learn/datasets/mnist.py:267: extract_labels (from tensorflow.contrib.learn.python.learn.datasets.mnist) is deprecated and will be removed in a future version.
Instructions for updating:
Please use tf.data to implement this functionality.
WARNING:tensorflow:From /usr/local/lib/python2.7/dist-packages/tensorflow/contrib/learn/python/learn/datasets/mnist.py:290: __init__ (from tensorflow.contrib.learn.python.learn.datasets.mnist) is deprecated and will be removed in a future version.
Instructions for updating:
Please use alternatives such as official/mnist/dataset.py from tensorflow/models.
2023-08-10 13:42:32.288488: I tensorflow/core/platform/cpu_feature_guard.cc:141] Your CPU supports instructions that this TensorFlow binary was not compiled to use: AVX2 AVX512F FMA

@danielvegamyhre or @ahg-g any outstanding items on this PR?

/lgtm
/approve
/label tide/merge-method-squash

repo: kubernetes-sigs/jobset