relay: reconsider healthcheck

With https://github.com/firezone/firezone/pull/1996, our health-check endpoint in the relay gets "even more" useless than what it currently is.
I am of the opinion that we shouldn't need a health-check and instead rely on instrumentation and monitoring on what the relay actually does. For startup, we already have the "log in" with the portal before the relay is made available.
Additionally, the relay will exit on any hard-error.
@AndrewDryga What do you think? Am I missing something that we need the health-check for?

Open to what @AndrewDryga thinks but I'm ok to bias towards removing this feature before launch if we're not sure we need it. Since the Relay will be self-hosted, we don't people to rely heavily on this feature before we remove it.

We discussed it in Slack, health check is needed because not all platforms will be able to monitor health by just seeing if the binary is running. They are also required to determine container readiness (if it's ready to be added to the load balancer) even for ourselves - GCE requires it.

Ah, I see. So this is really just a liveness probe that can be used to determine if the Relay is alive. Telemetry / actual health metrics will be reported by the OTEL stuff you guys are working on?

Ah, I see. So this is really just a liveness probe that can be used to determine if the Relay is alive. Telemetry / actual health metrics will be reported by the OTEL stuff you guys are working on?

Yes ideally OTEL or direct integration with Google's stuff but I'd like to be vendor-agnostic. Let's see if we can pull it off.


allow eksa-controller-manager management permissions

With the addition of full cluster lifecycle, the eksa-controller needs to be able to install / remove packages installations in the workload clusters it creates.
Issue #, if available:
Description of changes:
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

/lgtm

Doh, this was totally the wrong approach, as we discussed in standup, there are better ways.


Updating example 05 with images

Included codes to store post-processing images and publish in the documentation.

Closing this PR.


Bug: Incorrectly reports android deeplinks as invalid if contains anything other than application/json in the header

Services such as app.link return content-type headers: application/json; charset=utf-8 and work fine with ios and android.
Android yURL results currently wrongly state this is invalid.

Fix: https://github.com/chayev/yurl/pull/80

@aceslick911 do you have examples of a few domains where the content type is application/json; charset=utf-8?
For context - I based the validator on the spec defined by Android. It specifically says the content type should be application/json.
I'm open to the edit you suggested as I know that application/json; charset=utf-8 works as well. I just want some examples to validate against before making the call.

@aceslick911 let me know if you have any examples

Closing due to lack of response


Usage With Expo

Is this library compatible with expo?

I would like to know it as well: build.gradle and Android manifest are absent in my Expo project folder.


bus error (core dumped), when build with GPU support

I followed the installing from source tutorial, however in step
bazel-bin/tensorflow/cc/tutorials_example_trainer --use_gpu

I encountered the following message:
I tensorflow/stream_executor/dso_loader.cc:108] successfully opened CUDA library libcublas.so locally
[1]    5462 bus error (core dumped)  bazel-bin/tensorflow/cc/tutorials_example_trainer --use_gpu

Any helps would be great
Environment info
Operating System:  Ubuntu 16.04
Installed version of CUDA and cuDNN: CUDA 8.0, cuDNN 5
(please attach the output of ls -l /path/to/cuda/lib/libcud*):
/usr/local/cuda/lib64/libcudadevrt.a
/usr/local/cuda/lib64/libcudart.so
/usr/local/cuda/lib64/libcudart.so.8.0
/usr/local/cuda/lib64/libcudart.so.8.0.27
/usr/local/cuda/lib64/libcudart_static.a
/usr/local/cuda/lib64/libcudnn.so
/usr/local/cuda/lib64/libcudnn.so.5
/usr/local/cuda/lib64/libcudnn.so.5.0.5

If installed from sources, provide the commit hash:
e95f4e760c6b6713b6b686ebeff9a1586a5831dd
Steps to reproduce

flowed the tutorial of installing Tensorflow from source

What have you tried?

goolged around, but with no help

I don't think CUDA 8.0 is fully, if at all, supported yet.  CUDA 7.0 to 7.5 should work.


Renaming role of role_grants resource is causing an error

Provider Version
0.57.0
Terraform Version
1.2.9
Describe the bug
When renaming the role which is granted to other roles with the role_grants resource, an error is thrown:
│ Role 'FOO_TEST2' does not exist or not authorized.
│
│   with snowflake_role_grants.foo_to_bar,
│   on role_test.tf line 9, in resource "snowflake_role_grants" "foo_to_bar":
│    9: resource "snowflake_role_grants" "foo_to_bar" {

Expected behavior
Role is renamed without error.
Code samples and commands
Setup:
resource "snowflake_role" "foo_test" {
    name = "FOO_TEST2"
}

resource "snowflake_role" "bar_test" {
    name = "BAR_TEST2"
}

resource "snowflake_role_grants" "foo_to_bar" {
    role_name = snowflake_role.foo_test.name

    roles = [snowflake_role.bar_test.name]
}

Change name of snowflake_role.foo_test to e.g. "FOO_TEST".
Additional context
The problem is that the role_grants resource is not dropped before the role is renamed. A workaround is using a lifecycle policy, which forces the drop of the role_grants, when the name of the role is changed.

I haved created a PR for this issue: #1591


(QENG-2616) Telly - Cannot Find Test Files Using Beaker...

... 2.8+ Logs/JUnit Reports

beaker added a directory level that telly couldn't handle
addeds support for --dry-run, which just process the junit file
without creating a TestRail api connection or attempting to submit
results

Refer to this link for build results (access rights to CI server needed):
http://jenkins-qe.delivery.puppetlabs.net/job/qe_telly_btc-intn/3/
Test PASSed.


review version semantic

must be done before publishing to marketplace

ok,should be X.x.y, where
X = change to API, related to kettle ecosystem (i.e. new version of pdi, new plugin container, etc)
x = new functionality added to the plugin
y = patch, bug fixes


Can we rename the repo to "http-api-apiary-format"

Sorry to nick pick, I just feel that api suggests a whole set of things that this repo is not and is is hard to go from from "api" to "the http-api description in apiary format", which is what it is :)
Also added more stuff to the readme to point to the real spec -> https://github.com/ipfs/api/pull/18

I would be okay with http-api, but http-api-apiary-format is a bit over to top for my taste.

http-api is part of the specs repo, this repo will only contain a format that is compatible with apiary

ok :(

@RichardLitt do you agree? Thoughts?

I don't think that we should confine it to apiary - apiary is the format, which doesn't need to be in the title. Sort of like how we don't have website repos called 'website-html'. I think 'http-api' works just fine. Seeing as how this is both the spec and the current functionality, we should keep it as http. http-api would be ok, too. The implementation is what is currently in master; the adjustments to fit an ideal specification is what we will be working on in patches. Make sense?

then, what about http-api-spec?

:bike: :house: :bike: :house: :bike: :house: :bike: :house: :bike: :house: :bike: :house: :bike: :house: :bike: :house:

@diasdavid This isn't just a spec, though, or it would be in specs.
Better question: Is there any reason you want the api namespace open? This repo should house anything related to the API which is not in specs or the original go-ipfs, js-ipfs repos.

Agree with Richard. Original goal was to have more stuff here.
Or does apiary make it impossible, forcing the repo to be dedicated only to
it?
On Mon, Jan 11, 2016 at 16:49 Richard Littauer<EMAIL_ADDRESS>wrote:

@diasdavid https://github.com/diasdavid This isn't just a spec, though,
or it would be in specs.
Better question: Is there any reason you want the api namespace open?
This repo should house anything related to the API which is not in specs or
the original go-ipfs, js-ipfs repos.
—
Reply to this email directly or view it on GitHub
https://github.com/ipfs/api/issues/19#issuecomment-170701699.

Apiary doesn't exclude other stuff being in this repo.

Original goal was to have API specs in this repo (or it started when @Dignifiedquire opened it to make it work on Apiary and then it was moved here) then it was discussed and agreed on one of the IPFS Sprint Meetings in December that we would move the specs to specs repo, so that it continues easy to find and keeps everything organised. More context can be found here: https://github.com/ipfs/api/issues/11
Currently, this repo, only contains the HTTP API description, made in the format that Apiary expects, so that it works with their tooling, it doesn't hold any of the core API (programmatic interface), nor the CLI. That was moved, as agreed, to: https://github.com/ipfs/specs/tree/master/api and under update here: https://github.com/ipfs/specs/pull/65

@diasdavid What is confusing? What would you like the api namespace for? What tools do you think ought to belong in an api repo?
Specs go in specs, and the api endpoints go in go-ipfs and node-ipfs. Everything else related to the API should go in here.
I'm having some issues understanding your position. Do you think that another repo should hold the core api interface, or the CLI? What would that look like?

note: No idea that this would generate such a discussion, but seems good that we get to clarify some points :)

It would good for the purposes of this discussion, that we start being more explicit when we want to refer to the several apis, namely:

Core API - The API that is accessible by importing IPFS as a module, for example https://ipfs.io/ipfs/QmTkzDwWqPbnAh5YiV5VwcTLnGdwSNsNTn2aDxdXBFca7D/example#/ipfs/QmQwAP9vFjbCtKvD8RkJdCvPHqLQjZfW7Mqbbqx18zd8j7/api/service/readme.md, or when someone imports IPFS to use it own the browser.
HTTP-API - Our RPC over HTTP, the API that is being documented on this repo.
CLI API - The command line interface that IPFS offers (which inside uses the HTTP-API to talk with IPFS)

Having this clarified:

Specs go in specs, and the api endpoints go in go-ipfs and node-ipfs.

This is the Core API, and although there is no active work on standardizing it, other than our "interface-{transport, connection, stream-muxer, peer-routing, record-store}", because it is very in flux and no one is necessarily depending on it right now, but eventually it will be standardised so that developers can build applications embeding IPFS and trust that the core API will remain stable.

What would you like the api namespace for?

I just feel that the name is too generic and can easily mislead people coming to the repo.

Agreed about defining terms. I went for a run and thought about it, and I think that this particular bikeshed is a bit of an ego-sink for me, because the terms have not been clearly defined and I've put a lot of processing into circular systems here.
I understand what you mean by Core API in the first case; that is certainly not in this repo. I do not understand how the CLI API uses the HTTP API, or what the CLI API is. You mean the CLI commands that I know of as $ ipfs?

This is the Core API

It is unclear what this refers to, here. Again, apologies for asking, but what do you mean there?

...eventually it will be standardised...

Where? That ought to be here, I think. What would that standardization look like?

I just feel that the name is too generic and can easily mislead people coming to the repo.

Let's pretend it is six months from now. What else would we like to have, regarding documentation and APIs? Is there any chance that we won't change this back?

yeah @diasdavid is right. +1 on  "core api" "http api" and "cli api"
distinctions.
one goal was to  have "the core api" speced out in a repo somewhere. we can
put that in specs, though we began that work here i think.

more:

the "core api" is an interface defining what an IPFS node should do.
it's the thing we were writing out altogether (with @dignifiedquire and
others) in a hangout.
this "core api" in turn is implement in go-ipfs (as "the go-ipfs core
api") and in js-ipfs (as "the js-ipfs core api"), and can be used
programmatically as a library by importing the packages.
the "core api" in turn defines what the other apis ("http api" and "cli
api") can do. these others may be supersets or subsets, but they part
from the "core api".
the "http api" is "exposing the core api over http" and includes other
stuff. what's getting speced here.
the "cli api" is "exposing the core api over unix shell commands" -- and
yes, it's the $ ipfs add, cat, ls, ... commands.

hope this helps?

the "core api" is an interface defining what an IPFS node should do. it's the thing we were writing out altogether (with @dignifiedquire and others) in a hangout.

Check https://github.com/ipfs/specs/pull/65/files , specially the https://github.com/ipfs/specs/blob/ipfs/api/api/core/README.md
@RichardLitt I believe @jbenet answered your questions, let me know if there is still any question :)

@diasdavid Cool. Yes, that makes more sense. Thanks for being patient with me. :)

awesome :D :D I believe we reached the quorum to rename it to http-api-spec then :) changing it :D

Sorry, was just commenting when you closed it.
You know, I'm still not sure about this.
This repo is for the apiary format. However, we have a poor workflow around that. Currently, the master branch has an empty file. What I do then is I stub out the current API responses and status in another branch, and then PR into master. That PR then gets two types of comments: the first finding issues in my description, the second finding issues in the implementation. Ideally, only the first are dealt with, and then we merge. However, I then should make a second PR with only the second issues, and reference issues on go-ipfs about how to fix the implementation. This creates a lot of friction.
A much cleaner system would be to have two files: a current description, and a spec, also in apiary format. Any issues to the spec can be dealt with in their own issues, and any differences between spec and current implementation can be mentioned in their own relative PRs. This would mean that it would be much easier to spec out the current implementation without the friction of having people comment on issues which they really have with the spec, not with my description of the current implementation.
Proposal: Let's move the HTTP API specification here, in it's entirety. Then, we can have two files: spec.apib, and implementation.apib.
Alternate proposal: Let's delete this repository, and move the current implementation into specs. I think this would lead to a lot of noise in ipfs/specs, though.

The reason this is relevant is that it affects the name of the repo. I think the name should not be http-api-spec if the spec file isn't here. http-api works if the spec file is, too. http-api-description or http-api-doc or something is better suited for the current functionality.

cc @diasdavid

Currently, http-api state (how it is working currently), lives here. For context, as we discussed (sprint meetings + in person), once this documentation ends, we will work in a PR and per endpoint basis, fixing each HTTP-API endpoint and opening issues/PR on go-ipfs to fix its API

So what's the name you want to use now?


makeCall issue

public function makeCall(Request $request){
$callerId = 'client:quick_start';
$to = isset($_POST["to"]) ? $_POST["to"] : "";
if (!isset($to) || empty($to)) {
$to = isset($_GET["to"]) ? $_GET["to"] : "";
}
    /*
    * Use a valid Twilio number by adding to your account via https://www.twilio.com/console/phone-numbers/verified
    */
    $callerNumber = '1234567890';

    $response = new TwiML();
    if (!isset($to) || empty($to)) {
    $response->say('Congratulations! You have just made your first call! Good bye.');
    } else if (is_numeric($to)) {
    $dial = $response->dial(
        array(
        'callerId' => $callerNumber
        ));
    $dial->number($to);
    } else {
    $dial = $response->dial(
        array(
        'callerId' => $callerId
        ));
    $dial->client($to);
    }

    return $response;
}

I am getting error.

I am getting error with make call function. it always return error.  Error code are 11750, 52134

Hi @santanushyamal
While it's not very clear to figure out what's wrong from the code snippets you provided, the 11750 error code indicates that the TwiML response from your endpoint is too large for Twilio to process and you probably want to check that part.
The 52134 error means the PushKit device token from your iOS app is malformed and cannot be used for sending notification requests to Apple. Please make sure you are following the latest version of the Voice iOS quickstart for PushKit/CallKit integration.
Please provide Twilio Call SIDs where you are seeing errors. You can find Call SIDs either in the Xcode debugger or from the Twilio console.

Hi @bchen-twilio
I am getting error with makecall function and placecall function for client to client voice call. We have checked the twilio cosole Debugger. The error codes are 11750, 52134.
Below the code environment details.

Server programming language : PHP (LARAVEL)
APP :  iOS and Android.
Below are the code details of makeCall function and placeCall function.

public function makeCall(Request $request){
$callerId = $request->Caller;
$to = $request->to;
$callerNumber = '';
    $response = new VoiceResponse();
    if (!isset($to) || empty($to)) {
        $response->say('Congratulations! You have just made your first call! Good bye.');
    } else if (is_numeric($to)) {
        $dial = $response->dial($callerNumber);
        $dial->number($to);
    } else {
        $dial = $response->dial($callerId);
        $dial->client($to);
    }

    return $response;
}

////////////////////////////
public function placeCall(Request $request){
$identity = 'alice';
$callerNumber = '';
$callerId = $request->Caller;
$to = $request->to;
$client = new Client($this->key, $this->secret, $this->sid);
    $call = NULL;
    if (!isset($to) || empty($to)) {
    $call = $client->calls->create(
        'client'.$to, // Call this number
        $callerId,      // From a valid Twilio number
        array(
        'url' => 'https://'.$_SERVER['HTTP_HOST'].'/api/incoming'
        )
    );
    } else if (is_numeric($to)) {
    $call = $client->calls->create(
        $to,           // Call this number
        $callerNumber, // From a valid Twilio number
        array(
        'url' => 'https://'.$_SERVER['HTTP_HOST'].'/api/incoming'
        )
    );
    } else {
    $call = $client->calls->create(
        'client:'.$to, // Call this number
        $callerId,     // From a valid Twilio number
        array(
        'url' => 'https://'.$_SERVER['HTTP_HOST'].'/api/incoming'
        )
    );
    }

    print $call;
}

The endpoint of TwiML app is makeCall.
Call SID : CA5593ec91f4e94781495ffd8082fed19d

Thanks for the Call SID @santanushyamal.
Unfortunately Twilio was not able to save the TwiML response from your app endpoint because it is larger than 64kb. Can you please add some debug message and check the contents returned from your makeCall endpoint? It should look like this
<?xml version="1.0" encoding="UTF-8"?>
<Response>
    <Dial callId="client:alice">
        <Client>bob</Client>
    </Dial>
</Response>

When I call my placeCall function, it does not return any error code. But call did not connect. I got some response with SID. this SID is CA19bcc422a18fed44c09c42746690dcd1

Hi @santanushyamal
For the Call CA19bcc422a18fed44c09c42746690dcd1, it showed that there was no registration record for the client identity santanu you were trying to call. Please check if your mobile client is using the correct identity in the access token when calling the TwilioVoice.register() method.

Hi @bchen-twilio,
Thanks for your suggestions. We are still struggling with the 'Client to Client' audio call. We need your help.
Here are the details:

We have checked the iOS implementation and it is using push kit device token with data format.

We have checked the debug message and now the TwiML response returns from my server end-point (makeCall) -

Congratulations! You have just made your first call! Good bye.

Here is the CALL SID for your reference : CA2c383b33a396dbccdbcbc26d97d3476a
Awaiting for your response.
Thanks

To make client to client calls:

Create a Twilio TwiML Application using the makeCall endpoint as the Voice incoming URL in the Twilio dev console. This endpoint should return a TwiML containing the  verb.
Embed the Application SID in the access token when you try to make call using the TwilioVoice.connect() method. In the builder of TVOConnectOptions, you can specify additional information in the builder.params dictionary such as the receiver client identity.
The example makeCall endpoint should be able to parse the additional information out of the HTTP request parameters and determine the call receiver identity to be put inside the  verb.
If you register the mobile client with the correct identity in the access token, the client should receive the call notification.

Hi @bchen-twilio,
We have changed the identity value using the 'builder.params' dictionary in iOS. But the 'makeCall' API is always getting an empty value for the "To" field and it always shows "Congratulations! You have just made your first call! Good bye."
Let us know your suggestion regarding how we will get the "To" value in the "makeCall" API. We have attached the PHP 'accessToken' code for your reference.
CALL SID : CAb7d56e7951ce6d57d4ae7a15fd4b28f9
Here is the iOS code of performVoiceCall:
func performVoiceCall(uuid: UUID, client: String?, completionHandler: @escaping (Bool) -> Void) {
guard let accessToken = fetchAccessToken() else {
completionHandler(false)
return
}
    let connectOptions = TVOConnectOptions(accessToken: accessToken) { builder in
        builder.params = ["to": "bob"]
        builder.uuid = uuid
    }

    let call = TwilioVoice.connect(with: connectOptions, delegate: self)
    activeCall = call
    activeCalls[call.uuid.uuidString] = call
    callKitCompletionCallback = completionHandler
}

Here is the PHP code for generating access token:
public function accessToken(Request $request){
try{
$identity = $request->identity;
        // Create access token, which we will serialize and send to the client
        $token = new AccessToken($this->sid, $this->key, $this->secret, 3600, $identity);

        // Create Voice grant
        $voiceGrant = new VoiceGrant();
        $voiceGrant->setOutgoingApplicationSid($this->outGoingId);
        $voiceGrant->setPushCredentialSid($this->push_credential_sid);

        // Optional: add to allow incoming calls
        $voiceGrant->setIncomingAllow(true);

        // Add grant to token
        $token->addGrant($voiceGrant);

        // Serialize the token as a JWT
        return $token->toJWT();
        //echo $token->toJWT();
    }catch(Exception $e){
        return $e->getMessage();
    }
}

Thanks. Waiting for your response.

Hi @santanushyamal
Have you tried to extract the value on your sever endpoint using the lowercased to?

Hi @santanushyamal
I checked your Call SID and it doesn't seem very clear to me how the makeCall endpoint is used. I can see the makeCall endpoint was hit when the call was made, but it didn't return a TwiML directly. This is my hunch, but it seems that the makeCall endpoint URL you provided in the TwiML app uses a plain-text http and the request was redirected to the https endpoint. Can you try updating the link in your TwiML App with the secured link?

Hi @bchen-twilio,
Thanks for your suggestion. We have checked with http and https both. Results are the same.
The problem was related to makeCall endpoint (Error 11750) and now we have successfully done the audio call in iOS using APNS. But it is not working for android.
Can we use FCM PUSH_CREDENTIAL_SID for the iOS audio call?
It would be good if you suggest how we can use one PUSH_CREDENTIAL_SID for iOS and android both.
Thanks again.

Glad that the TwiML issue has been resolved @santanushyamal.
The Push Credentials are not sharable between iOS and Android mobile clients - you need to created separate Push Credentials using your FCM credentials and Apple VoIP certificate and use corresponding Push Credential SIDs in the access token in your Android and iOS mobile clients.
Since the original endpoint issue has been resolved, I will close this ticket. Please feel free to create new tickets here if you run into problem with the server components or the Android quickstart/iOS quickstart if you need platform specific help.
Cheers,
-bobie


Use inside nested component

Resolves #39 by allowing the parent passed as a new property parent (name can be considered to be more convenient):
<template>
    <my-custom-component>
        <v-runtime-template **:parent="this"** :template="template" />
    </my-custom-component>
</template>

Also resolves #22 as the parent property can be defined as a custom object containing the optional properties data, prop, options, or just {} for sandboxing.
Fixes #34 and fixes #31 by just defining them in the component:
  components: {},
  computed: {},
  methods: {},

Please add this to master branch quickly. I need these fixes for a project I'm currently working on.

When will it be Live?

Fixed on 1.7.1 6289c88c6812df2037f3e138e35fad75c4fd71cc by using parent property. See #41


TypeScript v4.6.2 is not supported for @typescript-eslint/typescript-stree.

WARNING: You are currently running a version of TypeScript which is not officially supported by @typescript-eslint/typescript-estree.

I'm having problems with lint in my project, is anyone else?

Umm, this isn't a TypeScript issue.  You need to take this up with whoever authored the eslint plugin you're having a problem with.

I got it, thanks.


Add Proper Authentication and Navbar

In this branch I did:

Add urls and Update index.js
Integrated necessary URLs and performed updates to the index.js file. This ensures proper routing and navigation within the application.

Add userSlice and Update store.js
Introduced the userSlice and concurrently updated the store.js to accommodate the new user-related state management functionalities.

Remove template Layout.jsx
Eliminated the deprecated Layout.jsx template, streamlining the project structure and reducing unnecessary code.

Add Login, Logout, Signup.jsx, and styles.
Introduced new components for user authentication, including Login.jsx, Logout.jsx, Signup.jsx, along with associated styles for a polished UI.

Add Navbar and its components.
Implemented the Navbar component and its related elements, enhancing the overall navigation and user experience.

Create Motorcycles.jsx and NotFound.jsx and styles.
Added the Motorcycles.jsx component, contributing to the application's functionality. Also, introduced a NotFound.jsx component for handling non-existent routes, accompanied by appropriate styles.

Update App.jsx and set routes.
Updated the App.jsx file to incorporate the newly added components and set up routes, ensuring seamless navigation through the application.

Conclusion
These changes collectively enhance the project's structure, introduce critical components, and improve overall user interaction. The addition of dependencies and the update to the app title contribute to the project's readiness for further development.

Hey @GhausAliKhan
🎉 Congratulations on the fantastic work in the latest branch! 🎉
Here's a quick shoutout to highlight the awesome contributions:
URL Magic and JS Mastery: Adding those URLs and updating the index.js? Pure genius move. Seamless routing and navigation? Nailed it!
State-of-the-Art State Management: The introduction of userSlice and the updates to store.js? Brilliant! The project's state is now as smooth as butter.
Out with the Old, In with the New: Kudos on ditching the outdated Layout.jsx! Streamlining the project structure like a pro. Less is more!
User Authentication Swagger: Login.jsx, Logout.jsx, Signup.jsx, and those sleek styles? Aesthetic AND functional. The app just got a major facelift!
Navigate with Style: The Navbar and its components are on point. Navigation game strong! 🧭
Adding Spice to Functionality: Motorcycles.jsx making its grand entrance!  We're all about that functionality.
Routing Mastery: Updating App.jsx for the new components and setting up routes? Smooth transitions guaranteed.
In conclusion, the project has hit a whole new level. 👏 Your hard work and attention to detail shine through, and the project is now poised for greatness!
Looking forward to seeing where this journey takes us next. Keep rocking it! 🚀


fix(layout): CardLarge remove Cell negative margins and fix by spec

Close #

Сlosed in favor https://github.com/taiga-family/taiga-ui/pull/9040


Implement initial support for bpftrace

From #1342
Implement support to run bpftrace scripts on the cluster. This initial support consists on running the bpftrace binary and showing the output to the user.
# run on a single node
$ kubectl gadget bpftrace --node foo -e `tracepoint...`

# run on multiple nodes
$ kubectl gadget bpftrace -e `tracepoint...`

This phase doesn't provide any support for filtering nor enriching data by namespace/pod/container etc.

I don't think we should call this gadget "bpftrace". The reason for this is that while we want to have compatibility with bpftrace, I don't think this will be sufficient for our needs. We already know we will need to add enrichment for containers and kubernetes. I think as we build this out we will find further things that we should add which takes us further from bpftrace
My proposal is that we call this gadget "script". When one calls this gadget with a single line script or file with a ".bt" extension which needs no enrichment then we only need bpftrace. But if it's run with a single line script or a file with an ".ig" extension which does need enrichment then we are no longer bpftrace-compatible.
But I think the real fun is what we may be able to do on top of all this by extending the scripting. That still needs brainstorming, though.


getSupportedListenerOptions is something very unique in the platform

There are plenty of APIs taking a dictionary as a param, yet I don't recall anything like getSupportedListenerOptions(). Do we really need it?

Yeah I wasn't sure how best to handle feature detection (#8).  If we go with your idea of a backwards-compatible hint (eg. #12) then perhaps we can get away without feature detection so maybe we need to resolve the debate in #2 before worrying about this.
But even if we go with a backwards compatible "hint", might there still not be scenarios where a library wants to know whether the hint is supported?  Eg. maybe if it knows performance will be improved it'll disable some minor feature in order to be able to take advantage of non-cancelable touch events.  But maybe that's too minor of a reason to justify.

I think before exposing getSupportedListenerOptions() to the platform this needs some more generic discussion whether we want to expose possible dictionary properties and their default values - not only in this API but in APIs in general.

Sounds like a good idea.  Let's try to resolve the debate in #2 first.  Then if we still need some form of feature detection I can start this discussion.  What do you think is the appropriate forum?

@foolip suggests (on whatwg list) putting getSupportedListenerOptions this on EventTarget instead of Event.

For just feature detection, you can use an object with getters on it.  That won't tell you the default values of the dictionary properties; just which dictionary properties are supported by the browser.

Oooh, cool - thank you!  I'm sold.

@bzbarsky Doesn't this rely on the implementation detail that they will be queried when addEventListener executes. Some implementations might wait until a property is queried or dispatchEvent to execute no? (I'm not sure on the details of the other implementations)

@dtapuska The dictionary properties must be queried before the spec algorithm of addEventListener executes.  That's not an implementation detail; it's a basic Web IDL spec requirement.  The timing is fully specified, the order in which the getters are executed is fully specified. Has to be that way, since getters can have arbitrary side-effects so you have to pin down the behavior completely to get anything resembling interop.


[driver] #1282 - Post Merge Update

- Post Merge review comments added.
- Formatting
- Function name & i/p parameter names are changed.

Signed-off-by: Sujatha Phatak<EMAIL_ADDRESS>

@atamazov @junliume @JehandadKhan : code review request. Thank you

@technicalgrp89  please monitor CI and make sure it passes:
http://micimaster.amd.com/blue/organizations/jenkins/MLLibs%2FMIOpen/detail/1282_postmerge_update/3/pipeline

@technicalgrp89 >  technicalgrp89 added the Review Required label 17 days ago
Do you really think we need this? The labels that require review are already marked in the list of pull requests, both textually ("Review required") and by a pictogram (:x:). And there is also an "Awaiting review from me" list.

@technicalgrp89

technicalgrp89 added the Review Required label 17 days ago

Do you really think we need this label? The labels that require review are already marked in the list of pull requests, both textually ("Review required") and by a pictogram (x). And there is also handy "Awaiting review from me" list.

Label removed.


Added 10 second delay between calls to provideDiagnosisKeys (fix #737)

Checklist

[x] Test your changes as thoroughly as possible before you commit them. Preferably, automate your test by unit/integration tests.
[x] If this PR comes from a fork, please Allow edits from maintainers
[x] Set a speaking title. Format: {task_name} (closes #{issue_number}). For example: Use logger (closes # 41)
[x] Link your Pull Request to an issue - Pull Requests that are not linked to an issue with you as an assignee will be closed, except for minor fixes for typos or grammar mistakes in documentation or code comments.
[x] Create Work In Progress [WIP] pull requests only if you need clarification or an explicit review before you can continue your work item.
[x] Make sure that your PR is not introducing unnecessary reformatting (e.g., introduced by on-save hooks in your IDE)
[x] Make sure that your PR does not contain changes in text files, therefore the PR must not contain changes in values/strings/* and / or assets/* (see issue #332 for further information)
[x] Make sure that your PR does not contain compiled sources (already set by the default .gitignore) and / or binary files

Description

Can no longer reproduce error 10 with 10 seconds delay between calls to provideDiagnosisKeys
fix #737
Note that I'm only able to test that it would work by accessing live instance of the app from Play Store and reverse-engineering (calling provideDiagnosisKeys on a client extracted from heap), cannot unfortunately deploy this fork and test it with the code changes introduced here unless I get ahold of signed apk with these changes

We will take care of testing this in detail on Monday.

Published scripts to reproduce it here: https://github.com/kbobrowski/en-api-exception-10-debug
Stack trace inside GMS: https://github.com/kbobrowski/en-api-exception-10-debug/blob/master/stack_trace.txt
Pipe operations (note that error only happens when PipedInputStream is closed before PipedOutputStream): https://github.com/kbobrowski/en-api-exception-10-debug/blob/master/pipes_0ms_delay.txt
This premature closing of PipedInputStream seems to never happen when delay is introduced: https://github.com/kbobrowski/en-api-exception-10-debug/blob/master/pipes_10000ms_delay.txt

@jakobmoellersap found an issue and patched it, PipedInputStream.read is buggy. I think we can expect fast patch by Google since it should be small change in Play Services implementation:
https://github.com/kbobrowski/en-api-exception-10-debug#bug-description
interesting part is that Google seems to be aware of this issue, they have workarounds for it GMS:
# bzin class

const-string v1, "#read(byte[]) returned invalid result: "

const-string v0, "\nThe InputStream implementation is buggy."

but in a place where EK Export v1 header is validated it does not seem to be handled properly - which results in not enough bytes read, throwing exception, closing pipe while handling this exception and in turn Pipe is closed exception being passed to CWA

Hi again, thanks for the Update. I could reproduce the issue and also agree with your analysis. Thus we will wait 1-2 more days for a fast track patch on Google Side in the hope of a fix just like they did on the "0 keys" issue. Also all of your analysis was forwarded to Google for more visibility and we keep updating as soon as we have more information we can share publicly. Sorry that we cannot share more at this point, but my hope is that we will never need to introduce this PR workaround.

@jakobmoellersap right, hopefully this workaround won't be needed, especially since it has a potential of breaking something on the devices which have no problem right now with error 10 (transaction timeout etc). As a backup solution also shorter delay may be considered (1-2 seconds) which won't solve the problem completely but it may make it couple of times less frequent such that at least on most of the days Diagnosis Keys would be successfully provided to the framework. But hopefully we'll see quick patch from Google

It's all probably because Android 6 is still using Apache Harmony-based Java implementation, and from 7 onwards OpenJDK is used, so I guess all Android 6 devices are affected

Interesting thought, but we also see this on other devices not based on Android 6. Maybe they are more likely to be affected due to Harmony but I wouldn't call it out as explicit cause just yet

If it's not a bug in Java implementation then maybe there is an issue with GMS implementation which causes PipedOutputStream to send not enough bytes. Would be interesting to find out what Google has changed in the upcoming update

Everything seems to be fine with Google's implementation, looks more like an issue with Java itself, here 4096 bytes come in to the pipe and 6 bytes come out:
1759123: java.io.PipedOutputStream@ded319d <- PipedOutputStream()
1759132: java.io.PipedInputStream@f8a2612 <- PipedInputStream(output_stream=java.io.PipedOutputStream@ded319d)
1759140: java.io.FileInputStream@957e1e3 :: read(buffer={length=4096}) = 4096
1759146: java.io.PipedOutputStream@ded319d :: write(buffer={length=4096}, offset=0, length=4096)
1759139: java.io.PipedInputStream@f8a2612 :: read(buffer={length=16}) = 6
1759154: Exception: Invalid file header length
1759156: java.io.PipedInputStream@f8a2612 :: close()
1759159: Exception: Pipe is closed
1759166: java.io.PipedOutputStream@ded319d :: close()
1759173: Exception: Unable to validate key file signature: Pipe is closed

In the end it looks like it's an implementation issue on Google's side.
PipedOutputStream.write(byte[] buffer, int offset, int length) will block until all bytes are sent,
PipedInputStream.read(byte[] buffer, int offset, int length) will block only until first byte is received, but will not block until length of bytes is received, so result of this method depends on a timing, if it is called too fast then it returns less than length bytes.
It corresponds to the definition in documentation, although documentation does not go out of its way to explain it.
This is expected behavior which happens in most of the cases:
https://github.com/kbobrowski/en-api-exception-10-debug/blob/master/trace_all_correct.txt
but this one seems to also be valid according to the docs:
https://github.com/kbobrowski/en-api-exception-10-debug/blob/master/trace_all_error.txt
In the latter case full header is still properly received by PipedInputStream, but read method was called too early and returned just one byte (or sometimes a bit more).
Difficult to say based on this why separating calls by a timeout seems to be fixing it, probably it has to do something with timing of the start of async task which reads files

As to why separating calls to provideDiagnosisKeys help:

I think what happens is this:
If phone is under high load (calling provideDiagnosisKeys frequently) or simply has weaker processor then there is slightly longer delay between constructing PipedInputStream and calling it's read method. During this delay first byte is already written to PipedInputStream by PipedOutputStream, and this part of the code in read method passes then very fast since in is already more than -1:
        try {
            int attempts = 3;
            while (in == -1) {
                // Are we at end of stream?
                if (isClosed) {
                    return -1;
                }
                if ((attempts-- <= 0) && lastWriter != null && !lastWriter.isAlive()) {
                    throw new IOException("Pipe broken");
                }
                // Notify callers of receive()
                notifyAll();
                wait(1000);
            }
        } catch (InterruptedException e) {
            IoUtils.throwInterruptedIoException();
        }

and then it flies through the rest of the method returning number less than 16. But if read is called before PipedOutputStream managed to write anything yet (time between constructing and calling method is very short), it will wait for first byte, and during this time much more than 16 bytes would already be written, so this method would return 16 as expected.

Tested it with whitelisted device and it does not look good, the error still happens even with large delay. Perhaps testing isolated provideDiagnosisKeys was making timing just right, which resulted in some rate of success, but testing this solution integrated into the app does not seem to solve the problem.
It's actually surprising that current implementation works at all, it looks like it is only thanks to the peculiarities of how PipedOutputStream and PipedInputStream interact in OpenJDK (former will block latter until everything is sent, this does not happen in Harmony). Closing - fix from Google should come very soon


feat: adding on-chain params to ics29 fee middleware

Description

Adding on-chain parameters to apps/29-fee including DistributionAddress field

ref: #1477

Before we can merge this PR, please make sure that all the following items have been
checked off. If any of the checklist items are not applicable, please leave them but
write a little note why.

[ ] Targeted PR against correct branch (see CONTRIBUTING.md)
[ ] Linked to Github issue with discussion and accepted design OR link to spec that describes this work.
[ ] Code follows the module structure standards.
[ ] Wrote unit and integration tests
[ ] Updated relevant documentation (docs/) or specification (x/<module>/spec/)
[ ] Added relevant godoc comments.
[ ] Added a relevant changelog entry to the Unreleased section in CHANGELOG.md
[ ] Re-reviewed Files changed in the Github PR explorer
[ ] Review Codecov Report in the comment section below once CI passes

Based on the discussion in #1477 I'll close this PR considering the choice of direction.
This PR could be resurrected in future for on-chain params for 29-fee as it covers the basic implementation


Parameter values in exp/.../xx.toml

I would like to ask how the values of the parameters in exp/.../xx.toml are obtained? When I reproduce the code, I want to use C.bins.count. The value of the parameter in the toml file is 125, but I don't know how this value is obtained.

For example, the value of the "count" parameter in the exp/transformer-q-l/adult/0_evaluation/0.toml file is 125. How is this value determined?

This section explains how such configs are obtained: link.

Namely, the value count=125 was tuned automatically based on the hyperparameter tuning
The hyperparameter tuning is defined by this config: link
The result of the tuning is here: link
the tuning_report['best']['config'] dictionary is the best configuration identified by the tuning algorithm; in particular, you can see the value "count": 125 there)

Does this help?

Feel free to reopen the issue if needed!

Thanks for your answer, much appreciated.


Find out how to set up certificates and serve the app via https

We need to find out how GZ infra handles TSL certificates and how we can integrate our app into that.
GZ infra could install certs into our VM, which we could then mount into the containers..?
Otherwise, we might have to create the certs ourselves..?
Should probably discuss this with GZ infra.

According to Holger we should get something ourselves via Lets encrypt.

This describes the process we probably have to do very nicely:
https://stackoverflow.com/a/40114717

These are the instructions to get the certificate: https://certbot.eff.org/instructions (I assume we have shell access.)
Software should be "Other" as we using a Docker setup and System I don't know.
Maybe someone with access @Holger-GZ can try to get a certificate and then we can do the nginx config.

I have shell access now so I'll take a look at this.

Turns out things are wayyyyyyy more complicated if you're not root, because certbot more or less requires root (or some super complicated and badly documented workarounds).
I've made some progress with acme.sh instead, and will try to get automated renewal working with that.

Made some progress, but gotta figure out how to use separate nginx configs for local, testing and prod.

The nginx config cleanup topic (#54) is done, so we can get back to working on certificates:

[ ] loading the manually created certificates into nginx
[ ] automating renewal


rest.ResponseWriter: add Write() function to conform to io.Writer interface

Hi,
In my project, I would like to pass an instance of rest.ResponseWriter to another function that expects to consume an io.Writer. roughly like so:
  86         rest.Get("/debug/metrics", func(w rest.ResponseWriter, r *rest.Request) {
  87             metrics.WriteJSONOnce(metrics.DefaultRegistry, w)
  88         }),

However, the following compilation error results on go version go1.6.2 linux/amd64:
worker/worker.go:87: cannot use w (type rest.ResponseWriter) as type io.Writer in argument to metrics.WriteJSONOnce:
        rest.ResponseWriter does not implement io.Writer (missing Write method)

This occurs because while a func Write(b []byte) (int, error) method exists, it is not explicitly listed in the type declaration.
This is a simple patch that adds the method signature to the rest.ResponseWriter type declaration.  With this, the application code on my end typechecks and a ResponseWriter is able to successfully be used by a function expecting an io.Writer type.
Thank you for writing a very useful project!
Nathan

hope it be merged soon

The solution for this is to use a type assertion, exactly like Go does it with net/http.
In net/http the responseWriter object provided as parameter of the handler implements many interfaces: ResponseWriter, RoundTripper, Hijacker, Flusher, ...
The same way, go-json-rest responseWriter implements many interfaces available via type assertions.
If you need the Flush() method just do w.(http.Flusher), if you need the Write() method just do w.(http.ResponseWriter).
The list of interfaces satisfied is documented in response.go, but given that this is the second time I explain this, I feel like it should be clearer in the documentation. I'll improve it.

@ant0ine just as http.ResponseWriter implements the Write() function through its interface so should rest.ResponseWriter. It makes sense that a "ResponseWriter" has a "Write" function. I don't understand why you'd want to force type assertion for two types that are somewhat the same. It makes sense to have them both satisfy each other's interface and the only thing that is missing is the code from this PR.
Up to you though.


Flutter 3.22 migration

Description
Flutter 3.22 migration
Related Issue
https://github.com/peiffer-innovations/json_dynamic_widget/issues/275
Checklist
Before you create this PR confirm that it meets all requirements listed below by checking the relevant checkboxes ([x]). This will ensure a smooth and quick review process.

[x] I read the Code Style Guide and followed the process outlined there for submitting PRs.
[x] All existing and new tests are passing.
[x] I updated/added relevant documentation (doc comments with ///).
[x] The analyzer (flutter analyze or dart analyze) does not report any problems on my PR.
[x] I updated pubspec.yaml with an appropriate new version according to the pub versioning philosophy.
[x] I updated CHANGELOG.md to add a description of the change.
[x] I am authorized to release this code under the MIT License and agree to do so

UI Change
Does your PR affect any UI screens?

[x] No, there are no UI impacts with this PR.

Before

After

Hello @jpeiffer -  could you review this PR?

Closing the PR since it was already solved.


BUG: Error: unknown command "initsystem" for "sealctl"

Sealos Version
4.4.0-beta3
How to reproduce the bug?
sealos run registry.cn-shanghai.aliyuncs.com/labring/k3s:v1.28.3

What is the expected behavior?
Install k3s success.
What do you see instead?
Install k3s failed.
root@ubuntu:~# sealos run registry.cn-shanghai.aliyuncs.com/labring/k3s:v1.28.3
2023-11-16T09:39:19 info Start to create a new cluster: master [<IP_ADDRESS>], worker [], registry <IP_ADDRESS>
2023-11-16T09:39:19 info Executing pipeline Check in CreateProcessor.
2023-11-16T09:39:19 info checker:hostname [<IP_ADDRESS>:22]
2023-11-16T09:39:19 info checker:timeSync [<IP_ADDRESS>:22]
2023-11-16T09:39:19 info Executing pipeline PreProcess in CreateProcessor.
2023-11-16T09:39:19 info Executing pipeline RunConfig in CreateProcessor.
2023-11-16T09:39:19 info Executing pipeline MountRootfs in CreateProcessor.
2023-11-16T09:39:23 info Executing pipeline MirrorRegistry in CreateProcessor.
2023-11-16T09:39:23 info trying default http mode to sync images to hosts [<IP_ADDRESS>:22]
2023-11-16T09:39:29 info Executing pipeline Bootstrap in CreateProcessor
Failed to stop registry.service: Unit registry.service not loaded.
Failed to stop image-cri-shim.service: Unit image-cri-shim.service not loaded.
 INFO [2023-11-16 09:39:29] >> Turn off all service for k3s
 INFO [2023-11-16 09:39:29] >> check root,port,cri success
2023-11-16T09:39:29 info domain sealos.hub:<IP_ADDRESS> append success
Created symlink /etc/systemd/system/multi-user.target.wants/registry.service → /etc/systemd/system/registry.service.
 INFO [2023-11-16 09:39:30] >> Health check registry!
 INFO [2023-11-16 09:39:30] >> registry is running
 INFO [2023-11-16 09:39:30] >> init registry success
 INFO [2023-11-16 09:39:30] >> using builtin containerd, skip init cri!
2023-11-16T09:39:30 info domain apiserver.cluster.local:<IP_ADDRESS> append success
Created symlink /etc/systemd/system/multi-user.target.wants/image-cri-shim.service → /etc/systemd/system/image-cri-shim.service.
 INFO [2023-11-16 09:39:31] >> Health check image-cri-shim!
 INFO [2023-11-16 09:39:31] >> image-cri-shim is running
 INFO [2023-11-16 09:39:31] >> init shim success
<IP_ADDRESS> localhost
::1 ip6-localhost ip6-loopback
Firewall stopped and disabled on system startup
* Applying /etc/sysctl.d/10-console-messages.conf ...
kernel.printk = 4 4 1 7
* Applying /etc/sysctl.d/10-ipv6-privacy.conf ...
net.ipv6.conf.all.use_tempaddr = 2
net.ipv6.conf.default.use_tempaddr = 2
* Applying /etc/sysctl.d/10-kernel-hardening.conf ...
kernel.kptr_restrict = 1
* Applying /etc/sysctl.d/10-magic-sysrq.conf ...
kernel.sysrq = 176
* Applying /etc/sysctl.d/10-network-security.conf ...
net.ipv4.conf.default.rp_filter = 2
net.ipv4.conf.all.rp_filter = 2
* Applying /etc/sysctl.d/10-ptrace.conf ...
kernel.yama.ptrace_scope = 1
* Applying /etc/sysctl.d/10-zeropage.conf ...
vm.mmap_min_addr = 65536
* Applying /usr/lib/sysctl.d/50-default.conf ...
kernel.core_uses_pid = 1
net.ipv4.conf.default.rp_filter = 2
net.ipv4.conf.default.accept_source_route = 0
sysctl: setting key "net.ipv4.conf.all.accept_source_route": Invalid argument
net.ipv4.conf.default.promote_secondaries = 1
sysctl: setting key "net.ipv4.conf.all.promote_secondaries": Invalid argument
net.ipv4.ping_group_range = 0<PHONE_NUMBER>
net.core.default_qdisc = fq_codel
fs.protected_hardlinks = 1
fs.protected_symlinks = 1
fs.protected_regular = 1
fs.protected_fifos = 1
* Applying /usr/lib/sysctl.d/50-pid-max.conf ...
kernel.pid_max = 4194304
* Applying /usr/lib/sysctl.d/99-protect-links.conf ...
fs.protected_fifos = 1
fs.protected_hardlinks = 1
fs.protected_regular = 2
fs.protected_symlinks = 1
* Applying /etc/sysctl.d/99-sysctl.conf ...
fs.file-max = 1048576 # sealos
net.bridge.bridge-nf-call-ip6tables = 1 # sealos
net.bridge.bridge-nf-call-iptables = 1 # sealos
net.core.somaxconn = 65535 # sealos
net.ipv4.conf.all.rp_filter = 0 # sealos
net.ipv4.ip_forward = 1 # sealos
net.ipv4.ip_local_port_range = 1024 65535 # sealos
net.ipv4.tcp_keepalive_intvl = 30 # sealos
net.ipv4.tcp_keepalive_time = 600 # sealos
net.ipv4.vs.conn_reuse_mode = 0 # sealos
net.ipv4.vs.conntrack = 1 # sealos
net.ipv6.conf.all.forwarding = 1 # sealos
* Applying /etc/sysctl.conf ...
fs.file-max = 1048576 # sealos
net.bridge.bridge-nf-call-ip6tables = 1 # sealos
net.bridge.bridge-nf-call-iptables = 1 # sealos
net.core.somaxconn = 65535 # sealos
net.ipv4.conf.all.rp_filter = 0 # sealos
net.ipv4.ip_forward = 1 # sealos
net.ipv4.ip_local_port_range = 1024 65535 # sealos
net.ipv4.tcp_keepalive_intvl = 30 # sealos
net.ipv4.tcp_keepalive_time = 600 # sealos
net.ipv4.vs.conn_reuse_mode = 0 # sealos
net.ipv4.vs.conntrack = 1 # sealos
net.ipv6.conf.all.forwarding = 1 # sealos
 INFO [2023-11-16 09:39:32] >> Creating /usr/bin/kubectl symlink to k3s
 INFO [2023-11-16 09:39:32] >> Creating /usr/bin/crictl symlink to k3s
 INFO [2023-11-16 09:39:32] >> Creating /usr/bin/ctr symlink to k3s
 INFO [2023-11-16 09:39:32] >> init k3s success
 INFO [2023-11-16 09:39:32] >> init rootfs success
2023-11-16T09:39:32 info Executing pipeline Init in CreateProcessor.
2023-11-16T09:39:32 info starting init master0
2023-11-16T09:39:32 info enable k3s service on <IP_ADDRESS>:22
Error: unknown command "initsystem" for "sealctl"
Run 'sealctl --help' for usage.
2023-11-16T09:39:32 error Applied to cluster error: failed to init master0: exit status 1
Error: failed to init master0: exit status 1

Operating environment
- Sealos version:
- Docker version:
- Kubernetes version:
- Operating system:
- Runtime environment:
- Cluster size:
- Additional information:

Additional information
No response

Same error in k3s:v1.27.7
root@ubuntu:~# sealos run registry.cn-shanghai.aliyuncs.com/labring/k3s:v1.27.7

应该是镜像版本有问题，你拉取个最新的镜像试试 。

Still not work.
root@ubuntu:~# sealos run docker.io/labring/k3s:v1.28.3 --debug
2023-12-05T15:39:09 debug using file /etc/containers/storage.conf as container storage config
2023-12-05T15:39:09 debug creating new cluster
2023-12-05T15:39:09 debug host <IP_ADDRESS>:22 is local, command via exec
2023-12-05T15:39:09 debug defaultPort: 22
2023-12-05T15:39:09 debug cluster info: apiVersion: apps.sealos.io/v1beta1
kind: Cluster
metadata:
  creationTimestamp: null
  name: default
spec:
  hosts:
  - ips:
    - <IP_ADDRESS>:22
    roles:
    - master
    - amd64
  image:
  - docker.io/labring/k3s:v1.28.3
  ssh: {}
status: {}

2023-12-05T15:39:09 info Start to create a new cluster: master [<IP_ADDRESS>], worker [], registry <IP_ADDRESS>
2023-12-05T15:39:09 info Executing pipeline Check in CreateProcessor.
2023-12-05T15:39:09 info checker:hostname [<IP_ADDRESS>:22]
2023-12-05T15:39:09 debug start to exec remote <IP_ADDRESS>:22 shell: hostname
2023-12-05T15:39:09 debug host <IP_ADDRESS>:22 is local, command via exec
2023-12-05T15:39:09 info checker:timeSync [<IP_ADDRESS>:22]
2023-12-05T15:39:09 debug start to exec remote <IP_ADDRESS>:22 shell: date +%s
2023-12-05T15:39:09 debug host <IP_ADDRESS>:22 is local, command via exec
2023-12-05T15:39:09 info Executing pipeline PreProcess in CreateProcessor.
2023-12-05T15:39:09 debug parse reference 29b3a7c11612e5ba26040fee687966d53f11f2d7daea9a9a2ec09e1bd654c7aa with transport containers-storage
2023-12-05T15:39:09 debug images 29b3a7c11612e5ba26040fee687966d53f11f2d7daea9a9a2ec09e1bd654c7aa are pulled
2023-12-05T15:39:09 debug Pull Policy for pull [missing]
2023-12-05T15:39:10 debug parse reference 29b3a7c11612e5ba26040fee687966d53f11f2d7daea9a9a2ec09e1bd654c7aa with transport containers-storage
2023-12-05T15:39:10 info Executing pipeline RunConfig in CreateProcessor.
2023-12-05T15:39:10 debug clusterfile config is empty!
2023-12-05T15:39:10 info Executing pipeline MountRootfs in CreateProcessor.
2023-12-05T15:39:10 debug render env dir: /var/lib/containers/storage/overlay/7dbc1375fb72e915d343d9eaa7d57ea0520ba87bd6c2cc661f0d39ceba003e8b/merged/etc
2023-12-05T15:39:10 debug render env dir: /var/lib/containers/storage/overlay/7dbc1375fb72e915d343d9eaa7d57ea0520ba87bd6c2cc661f0d39ceba003e8b/merged/scripts
2023-12-05T15:39:10 debug render env dir: /var/lib/containers/storage/overlay/7dbc1375fb72e915d343d9eaa7d57ea0520ba87bd6c2cc661f0d39ceba003e8b/merged/manifests
2023-12-05T15:39:10 debug send mount image, target: <IP_ADDRESS>:22, image: docker.io/labring/k3s:v1.28.3, type: rootfs
2023-12-05T15:39:10 debug local <IP_ADDRESS>:22 copy files src /var/lib/containers/storage/overlay/7dbc1375fb72e915d343d9eaa7d57ea0520ba87bd6c2cc661f0d39ceba003e8b/merged/Kubefile to dst /var/lib/sealos/data/default/rootfs/Kubefile
2023-12-05T15:39:10 debug local <IP_ADDRESS>:22 copy files src /var/lib/containers/storage/overlay/7dbc1375fb72e915d343d9eaa7d57ea0520ba87bd6c2cc661f0d39ceba003e8b/merged/README.md to dst /var/lib/sealos/data/default/rootfs/README.md
2023-12-05T15:39:10 debug local <IP_ADDRESS>:22 copy files src /var/lib/containers/storage/overlay/7dbc1375fb72e915d343d9eaa7d57ea0520ba87bd6c2cc661f0d39ceba003e8b/merged/bin to dst /var/lib/sealos/data/default/rootfs/bin
2023-12-05T15:39:11 debug local <IP_ADDRESS>:22 copy files src /var/lib/containers/storage/overlay/7dbc1375fb72e915d343d9eaa7d57ea0520ba87bd6c2cc661f0d39ceba003e8b/merged/cri to dst /var/lib/sealos/data/default/rootfs/cri
2023-12-05T15:39:11 debug local <IP_ADDRESS>:22 copy files src /var/lib/containers/storage/overlay/7dbc1375fb72e915d343d9eaa7d57ea0520ba87bd6c2cc661f0d39ceba003e8b/merged/etc to dst /var/lib/sealos/data/default/rootfs/etc
2023-12-05T15:39:11 debug local <IP_ADDRESS>:22 copy files src /var/lib/containers/storage/overlay/7dbc1375fb72e915d343d9eaa7d57ea0520ba87bd6c2cc661f0d39ceba003e8b/merged/images to dst /var/lib/sealos/data/default/rootfs/images
2023-12-05T15:39:11 debug local <IP_ADDRESS>:22 copy files src /var/lib/containers/storage/overlay/7dbc1375fb72e915d343d9eaa7d57ea0520ba87bd6c2cc661f0d39ceba003e8b/merged/opt to dst /var/lib/sealos/data/default/rootfs/opt
2023-12-05T15:39:12 debug local <IP_ADDRESS>:22 copy files src /var/lib/containers/storage/overlay/7dbc1375fb72e915d343d9eaa7d57ea0520ba87bd6c2cc661f0d39ceba003e8b/merged/scripts to dst /var/lib/sealos/data/default/rootfs/scripts
2023-12-05T15:39:12 info Executing pipeline MirrorRegistry in CreateProcessor.
2023-12-05T15:39:12 debug registry nodes is: [<IP_ADDRESS>:22]
2023-12-05T15:39:12 info trying default http mode to sync images to hosts [<IP_ADDRESS>:22]
2023-12-05T15:39:12 debug checking if endpoint http://<IP_ADDRESS>:5050 is alive
2023-12-05T15:39:12 debug running temporary registry on host <IP_ADDRESS>:22
2023-12-05T15:39:12 debug start to run command `/var/lib/sealos/data/default/rootfs/opt/sealctl registry serve filesystem -p 5050 --disable-logging=true /var/lib/sealos/data/default/rootfs/registry` via exec
2023-12-05T15:39:12 debug http endpoint http://<IP_ADDRESS>:5050 is alive
2023-12-05T15:39:12 debug checking if endpoint http://<IP_ADDRESS>:20437 is alive
2023-12-05T15:39:12 debug http endpoint http://<IP_ADDRESS>:20437 is alive
2023-12-05T15:39:12 debug syncing repos [{labring/lvscare  0 false false false} {pause  0 false false false} {rancher/klipper-helm  0 false false false} {rancher/klipper-lb  0 false false false} {rancher/local-path-provisioner  0 false false false} {rancher/mirrored-coredns-coredns  0 false false false} {rancher/mirrored-library-busybox  0 false false false} {rancher/mirrored-library-traefik  0 false false false} {rancher/mirrored-metrics-server  0 false false false}] from <IP_ADDRESS>:20437 to <IP_ADDRESS>:5050
2023-12-05T15:39:12 debug syncing <IP_ADDRESS>:5050/labring/lvscare:v4.3.7 with selection 1
2023-12-05T15:39:13 debug syncing <IP_ADDRESS>:5050/labring/lvscare:v4.3.7 with selection 0
2023-12-05T15:39:13 debug syncing <IP_ADDRESS>:5050/pause:3.9 with selection 1
2023-12-05T15:39:13 debug syncing <IP_ADDRESS>:5050/pause:3.9 with selection 0
2023-12-05T15:39:13 debug syncing <IP_ADDRESS>:5050/rancher/klipper-helm:v0.8.2-build20230815 with selection 1
2023-12-05T15:39:15 debug syncing <IP_ADDRESS>:5050/rancher/klipper-helm:v0.8.2-build20230815 with selection 0
2023-12-05T15:39:15 debug syncing <IP_ADDRESS>:5050/rancher/klipper-lb:v0.4.4 with selection 1
2023-12-05T15:39:15 debug syncing <IP_ADDRESS>:5050/rancher/klipper-lb:v0.4.4 with selection 0
2023-12-05T15:39:15 debug syncing <IP_ADDRESS>:5050/rancher/local-path-provisioner:v0.0.24 with selection 1
2023-12-05T15:39:16 debug syncing <IP_ADDRESS>:5050/rancher/local-path-provisioner:v0.0.24 with selection 0
2023-12-05T15:39:16 debug syncing <IP_ADDRESS>:5050/rancher/mirrored-coredns-coredns:1.10.1 with selection 1
2023-12-05T15:39:17 debug syncing <IP_ADDRESS>:5050/rancher/mirrored-coredns-coredns:1.10.1 with selection 0
2023-12-05T15:39:17 debug syncing <IP_ADDRESS>:5050/rancher/mirrored-library-busybox:1.36.1 with selection 1
2023-12-05T15:39:17 debug syncing <IP_ADDRESS>:5050/rancher/mirrored-library-busybox:1.36.1 with selection 0
2023-12-05T15:39:17 debug syncing <IP_ADDRESS>:5050/rancher/mirrored-library-traefik:2.10.5 with selection 1
2023-12-05T15:39:18 debug syncing <IP_ADDRESS>:5050/rancher/mirrored-library-traefik:2.10.5 with selection 0
2023-12-05T15:39:18 debug syncing <IP_ADDRESS>:5050/rancher/mirrored-metrics-server:v0.6.3 with selection 1
2023-12-05T15:39:19 debug syncing <IP_ADDRESS>:5050/rancher/mirrored-metrics-server:v0.6.3 with selection 0
2023-12-05T15:39:19 info Executing pipeline Bootstrap in CreateProcessor
2023-12-05T15:39:19 debug apply [default_checker registry_host_applier registry_applier initializer] on hosts [<IP_ADDRESS>:22]
2023-12-05T15:39:19 debug apply default_checker on host <IP_ADDRESS>:22
2023-12-05T15:39:19 debug start to run command `cd /var/lib/sealos/data/default/rootfs/scripts && export defaultVIP="<IP_ADDRESS>" registryDomain="sealos.hub" registryUsername="admin" sandboxImage="pause:3.9" registryPort="5000" SEALOS_SYS_CRI_ENDPOINT="/run/k3s/containerd/containerd.sock" SEALOS_SYS_RUN_MODE="master" registryPassword="passw0rd" SEALOS_SYS_KUBE_VERSION="v1.28.3" SEALOS_SYS_SEALOS_VERSION="4.3.7" registryConfig="/etc/registry" SEALOS_SYS_IMAGE_ENDPOINT="/var/run/image-cri-shim.sock" registryData="/var/lib/registry" ; bash check.sh $registryData` via exec
Failed to stop registry.service: Unit registry.service not loaded.
Failed to stop image-cri-shim.service: Unit image-cri-shim.service not loaded.
 INFO [2023-12-05 15:39:19] >> Turn off all service for k3s
 INFO [2023-12-05 15:39:19] >> check root,port,cri success
2023-12-05T15:39:19 debug apply registry_host_applier on host <IP_ADDRESS>:22
2023-12-05T15:39:19 debug host <IP_ADDRESS>:22 is local, command via exec
2023-12-05T15:39:19 debug registry config data info: # Copyright © 2022 sealos.
#
# Licensed under the Apache License, Version 2.0 (the "License");
# you may not use this file except in compliance with the License.
# You may obtain a copy of the License at
#
#     http://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS,
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
# See the License for the specific language governing permissions and
# limitations under the License.

domain: sealos.hub
port: "5000"
username: "admin"
password: "passw0rd"
data: "/var/lib/registry"

2023-12-05T15:39:19 debug show registry info, IP: <IP_ADDRESS>:22, Domain: sealos.hub, Data: /var/lib/registry
2023-12-05T15:39:19 debug start to run command `/var/lib/sealos/data/default/rootfs/opt/sealctl  hosts add --ip <IP_ADDRESS>  --domain sealos.hub` via exec
2023-12-05T15:39:19 info domain sealos.hub:<IP_ADDRESS> append success
2023-12-05T15:39:19 debug apply registry_applier on host <IP_ADDRESS>:22
2023-12-05T15:39:19 debug host <IP_ADDRESS>:22 is local, command via exec
2023-12-05T15:39:19 debug registry config data info: # Copyright © 2022 sealos.
#
# Licensed under the Apache License, Version 2.0 (the "License");
# you may not use this file except in compliance with the License.
# You may obtain a copy of the License at
#
#     http://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS,
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
# See the License for the specific language governing permissions and
# limitations under the License.

domain: sealos.hub
port: "5000"
username: "admin"
password: "passw0rd"
data: "/var/lib/registry"

2023-12-05T15:39:19 debug show registry info, IP: <IP_ADDRESS>:22, Domain: sealos.hub, Data: /var/lib/registry
2023-12-05T15:39:19 debug make soft link: rm -rf /var/lib/registry && ln -s /var/lib/sealos/data/default/rootfs/registry /var/lib/registry
2023-12-05T15:39:19 debug start to run command `rm -rf /var/lib/registry && ln -s /var/lib/sealos/data/default/rootfs/registry /var/lib/registry` via exec
2023-12-05T15:39:19 debug local <IP_ADDRESS>:22 copy files src /root/.sealos/default/etc/registry_htpasswd to dst /var/lib/sealos/data/default/rootfs/etc/registry_htpasswd
2023-12-05T15:39:19 debug start to run command `cd /var/lib/sealos/data/default/rootfs/scripts && export SEALOS_SYS_IMAGE_ENDPOINT="/var/run/image-cri-shim.sock" registryData="/var/lib/registry" registryConfig="/etc/registry" defaultVIP="<IP_ADDRESS>" registryDomain="sealos.hub" registryUsername="admin" registryPassword="passw0rd" SEALOS_SYS_KUBE_VERSION="v1.28.3" registryPort="5000" SEALOS_SYS_CRI_ENDPOINT="/run/k3s/containerd/containerd.sock" SEALOS_SYS_RUN_MODE="master" SEALOS_SYS_SEALOS_VERSION="4.3.7" sandboxImage="pause:3.9" ; bash init-registry.sh $registryData $registryConfig` via exec
Created symlink /etc/systemd/system/multi-user.target.wants/registry.service → /etc/systemd/system/registry.service.
 INFO [2023-12-05 15:39:20] >> Health check registry!
 INFO [2023-12-05 15:39:20] >> registry is running
 INFO [2023-12-05 15:39:20] >> init registry success
2023-12-05T15:39:20 debug apply initializer on host <IP_ADDRESS>:22
2023-12-05T15:39:20 debug start to run command `cd /var/lib/sealos/data/default/rootfs/scripts && export registryPort="5000" SEALOS_SYS_RUN_MODE="master" sandboxImage="pause:3.9" registryDomain="sealos.hub" registryUsername="admin" registryPassword="passw0rd" SEALOS_SYS_SEALOS_VERSION="4.3.7" registryData="/var/lib/registry" registryConfig="/etc/registry" SEALOS_SYS_IMAGE_ENDPOINT="/var/run/image-cri-shim.sock" defaultVIP="<IP_ADDRESS>" SEALOS_SYS_KUBE_VERSION="v1.28.3" SEALOS_SYS_CRI_ENDPOINT="/run/k3s/containerd/containerd.sock" ; bash init.sh` via exec
Created symlink /etc/systemd/system/multi-user.target.wants/image-cri-shim.service → /etc/systemd/system/image-cri-shim.service.
 INFO [2023-12-05 15:39:21] >> Health check image-cri-shim!
 INFO [2023-12-05 15:39:21] >> image-cri-shim is running
 INFO [2023-12-05 15:39:21] >> init shim success
<IP_ADDRESS> localhost
::1 ip6-localhost ip6-loopback
Firewall stopped and disabled on system startup
* Applying /etc/sysctl.d/10-console-messages.conf ...
kernel.printk = 4 4 1 7
* Applying /etc/sysctl.d/10-ipv6-privacy.conf ...
net.ipv6.conf.all.use_tempaddr = 2
net.ipv6.conf.default.use_tempaddr = 2
* Applying /etc/sysctl.d/10-kernel-hardening.conf ...
kernel.kptr_restrict = 1
* Applying /etc/sysctl.d/10-magic-sysrq.conf ...
kernel.sysrq = 176
* Applying /etc/sysctl.d/10-network-security.conf ...
net.ipv4.conf.default.rp_filter = 2
net.ipv4.conf.all.rp_filter = 2
* Applying /etc/sysctl.d/10-ptrace.conf ...
kernel.yama.ptrace_scope = 1
* Applying /etc/sysctl.d/10-zeropage.conf ...
vm.mmap_min_addr = 65536
* Applying /usr/lib/sysctl.d/50-default.conf ...
kernel.core_uses_pid = 1
net.ipv4.conf.default.rp_filter = 2
net.ipv4.conf.default.accept_source_route = 0
sysctl: setting key "net.ipv4.conf.all.accept_source_route": Invalid argument
net.ipv4.conf.default.promote_secondaries = 1
sysctl: setting key "net.ipv4.conf.all.promote_secondaries": Invalid argument
net.ipv4.ping_group_range = 0<PHONE_NUMBER>
net.core.default_qdisc = fq_codel
fs.protected_hardlinks = 1
fs.protected_symlinks = 1
fs.protected_regular = 1
fs.protected_fifos = 1
* Applying /usr/lib/sysctl.d/50-pid-max.conf ...
kernel.pid_max = 4194304
* Applying /usr/lib/sysctl.d/99-protect-links.conf ...
fs.protected_fifos = 1
fs.protected_hardlinks = 1
fs.protected_regular = 2
fs.protected_symlinks = 1
* Applying /etc/sysctl.d/99-sysctl.conf ...
fs.file-max = 1048576 # sealos
net.bridge.bridge-nf-call-ip6tables = 1 # sealos
net.bridge.bridge-nf-call-iptables = 1 # sealos
net.core.somaxconn = 65535 # sealos
net.ipv4.conf.all.rp_filter = 0 # sealos
net.ipv4.ip_forward = 1 # sealos
net.ipv4.ip_local_port_range = 1024 65535 # sealos
net.ipv4.tcp_keepalive_intvl = 30 # sealos
net.ipv4.tcp_keepalive_time = 600 # sealos
net.ipv4.vs.conn_reuse_mode = 0 # sealos
net.ipv4.vs.conntrack = 1 # sealos
net.ipv6.conf.all.forwarding = 1 # sealos
* Applying /etc/sysctl.conf ...
fs.file-max = 1048576 # sealos
net.bridge.bridge-nf-call-ip6tables = 1 # sealos
net.bridge.bridge-nf-call-iptables = 1 # sealos
net.core.somaxconn = 65535 # sealos
net.ipv4.conf.all.rp_filter = 0 # sealos
net.ipv4.ip_forward = 1 # sealos
net.ipv4.ip_local_port_range = 1024 65535 # sealos
net.ipv4.tcp_keepalive_intvl = 30 # sealos
net.ipv4.tcp_keepalive_time = 600 # sealos
net.ipv4.vs.conn_reuse_mode = 0 # sealos
net.ipv4.vs.conntrack = 1 # sealos
net.ipv6.conf.all.forwarding = 1 # sealos
 INFO [2023-12-05 15:39:22] >> Creating /usr/bin/kubectl symlink to k3s
 INFO [2023-12-05 15:39:22] >> Creating /usr/bin/crictl symlink to k3s
 INFO [2023-12-05 15:39:22] >> Creating /usr/bin/ctr symlink to k3s
 INFO [2023-12-05 15:39:22] >> init k3s success
 INFO [2023-12-05 15:39:22] >> init rootfs success
2023-12-05T15:39:22 info Executing pipeline Init in CreateProcessor.
2023-12-05T15:39:22 info start to copy kubeadm config to master0
2023-12-05T15:39:22 debug using default kubeadm config
2023-12-05T15:39:22 debug skip merging kubeadm configs from cause file /var/lib/sealos/data/default/rootfs/etc/kubeadm.yml not exists
2023-12-05T15:39:22 debug renderTextFromEnv: replaces: map[$(SEALOS_SYS_CRI_ENDPOINT):/run/k3s/containerd/containerd.sock $(SEALOS_SYS_IMAGE_ENDPOINT):/var/run/image-cri-shim.sock $(SEALOS_SYS_RUN_MODE):master $(defaultVIP):<IP_ADDRESS> $(registryConfig):/etc/registry $(registryData):/var/lib/registry $(registryDomain):sealos.hub $(registryPassword):passw0rd $(registryPort):5000 $(registryUsername):admin $(sandboxImage):pause:3.9 $SEALOS_SYS_CRI_ENDPOINT:/run/k3s/containerd/containerd.sock $SEALOS_SYS_IMAGE_ENDPOINT:/var/run/image-cri-shim.sock $SEALOS_SYS_RUN_MODE:master $defaultVIP:<IP_ADDRESS> $registryConfig:/etc/registry $registryData:/var/lib/registry $registryDomain:sealos.hub $registryPassword:passw0rd $registryPort:5000 $registryUsername:admin $sandboxImage:pause:3.9 ${SEALOS_SYS_CRI_ENDPOINT}:/run/k3s/containerd/containerd.sock ${SEALOS_SYS_IMAGE_ENDPOINT}:/var/run/image-cri-shim.sock ${SEALOS_SYS_RUN_MODE}:master ${defaultVIP}:<IP_ADDRESS> ${registryConfig}:/etc/registry ${registryData}:/var/lib/registry ${registryDomain}:sealos.hub ${registryPassword}:passw0rd ${registryPort}:5000 ${registryUsername}:admin ${sandboxImage}:pause:3.9] ; text: $defaultVIP
2023-12-05T15:39:22 debug get vip is <IP_ADDRESS>
2023-12-05T15:39:22 debug start to exec remote <IP_ADDRESS>:22 shell: /var/lib/sealos/data/default/rootfs/opt/sealctl cri socket
2023-12-05T15:39:22 debug host <IP_ADDRESS>:22 is local, command via exec
2023-12-05T15:39:22 debug get nodes [<IP_ADDRESS>:22] cri socket is [/run/containerd/containerd.sock]
2023-12-05T15:39:22 debug node: <IP_ADDRESS>:22 , criSocket: /run/containerd/containerd.sock
2023-12-05T15:39:22 debug start to exec remote <IP_ADDRESS>:22 shell: /var/lib/sealos/data/default/rootfs/opt/sealctl cri cgroup-driver --short
2023-12-05T15:39:22 debug host <IP_ADDRESS>:22 is local, command via exec
2023-12-05T15:39:25 debug failed to exec remote <IP_ADDRESS>:22 shell: /var/lib/sealos/data/default/rootfs/opt/sealctl cri cgroup-driver --short output: &{default} error: exit status 1
2023-12-05T15:39:25 error Applied to cluster error: failed to init generator config init kubeadm config error: exit status 1
2023-12-05T15:39:25 debug save objects into local: /root/.sealos/default/Clusterfile, objects: [apiVersion: apps.sealos.io/v1beta1
kind: Cluster
metadata:
  creationTimestamp: "2023-12-05T07:39:25Z"
  name: default
spec:
  hosts:
  - ips:
    - <IP_ADDRESS>:22
    roles:
    - master
    - amd64
  image:
  - docker.io/labring/k3s:v1.28.3
  ssh: {}
status:
  conditions:
  - lastHeartbeatTime: "2023-12-05T07:39:25Z"
    message: 'failed to init generator config init kubeadm config error: exit status
      1'
    reason: Apply Cluster
    status: "False"
    type: ApplyClusterError
  mounts:
  - env:
      SEALOS_SYS_CRI_ENDPOINT: /run/k3s/containerd/containerd.sock
      SEALOS_SYS_IMAGE_ENDPOINT: /var/run/image-cri-shim.sock
      SEALOS_SYS_RUN_MODE: master
      defaultVIP: <IP_ADDRESS>
      registryConfig: /etc/registry
      registryData: /var/lib/registry
      registryDomain: sealos.hub
      registryPassword: passw0rd
      registryPort: "5000"
      registryUsername: admin
      sandboxImage: pause:3.9
    imageName: docker.io/labring/k3s:v1.28.3
    labels:
      apps.sealos.io/distribution: k3s
      apps.sealos.io/type: rootfs
      apps.sealos.io/version: v1beta1
      check: check.sh $registryData
      clean: clean.sh
      clean-cri: clean-cri.sh
      clean-registry: clean-registry.sh $registryData $registryConfig
      image: ghcr.io/labring/lvscare:v4.3.7
      init: init.sh
      init-cri: init-cri.sh
      init-registry: init-registry.sh $registryData $registryConfig
      io.buildah.version: 1.30.0
      sealos.io.type: rootfs
      sealos.io.version: v1beta1
      version: v1.28.3
      vip: $defaultVIP
    mountPoint: /var/lib/containers/storage/overlay/7dbc1375fb72e915d343d9eaa7d57ea0520ba87bd6c2cc661f0d39ceba003e8b/merged
    name: default-vh72yaag
    type: rootfs
  phase: ClusterFailed
]
Error: failed to init generator config init kubeadm config error: exit status 1

sealos 版本不对 怎么还是用的k8s的逻辑

sealos 版本不对 怎么还是用的k8s的逻辑

sorry i use wrong sealos version.

At present, the official does not support running K3s images, and additional work is required to run them
wget https://github.com/labring/sealos/releases/download/v4.4.0-beta3/sealos_4.4.0-beta3_linux_amd64.tar.gz
tar -zxvf sealos_4.4.0-beta3_linux_amd64.tar.gz sealctl

# cat Kubefile
FROM docker.io/labring/k3s:v1.28.3
COPY sealctl opt/

sealos build -t sealos build -t registry.cn-shenzhen.aliyuncs.com/cnmirror/k3s:v1.28.3-patch
sealos run registry.cn-shenzhen.aliyuncs.com/cnmirror/k3s:v1.28.3-patch

It success
root@ubuntu:~# kubectl version
Client Version: v1.28.3+k3s2
Kustomize Version: v5.0.4-0.20230601165947-6ce0bf390ce3
Server Version: v1.28.3+k3s2
root@ubuntu:~# kubectl get nodes
NAME     STATUS   ROLES                       AGE     VERSION
ubuntu   Ready    control-plane,etcd,master   5m58s   v1.28.3+k3s2
root@ubuntu:~# kubectl get pods -A
NAMESPACE     NAME                      READY   STATUS    RESTARTS   AGE
kube-system   coredns-6799fbcd5-kr2km   1/1     Running   0          5m46s
nginx         nginx-5f4c4886ff-m79gj    1/1     Running   0          4m4s


Replace JDK internal ZipFileSystemProvider with FileSystems public API

Contains
Replaces the JDK internal ZipFileSystemProvider with the FileSystems public API. Since this classes will be hidden with Java 9 this change will be necessary.
Fixes #2354
How to test
Run the game and save a world.
Outstanding before merging
Nothing.

Can one of the admins please verify this patch?

Hi @theobisproject and thanks for the PR! Looks straight forward, going to trigger our bot testing :-)
@GooeyHub: ok to test
Interesting name by the way, isn't obis a package or org or something?

Hooray Jenkins reported success with all tests good!

Tested out locally real quick and merged! Added you to the credits as well :-)
Thanks again! Hoping to see more PRs, even if we are a bit overloaded at the moment ... :D

Hi @Cervator, thanks for merging this quickly. Obis is more or less a random pick of letters from my name so no "real" project.
But a quick Google search revealed a project for ocean biographic data with this abbreviation (http://www.iobis.org/) 😉


Documentation

It's been an obvious TODO for so long, but now as this project moves from a bunch of experimental code to something solid we should start documenting it.

[ ] Architecture overview
[ ] Full doc comment coverage

Closing because I noticed I already made #1


Client library

It'd be nice to be able to write GraphQL clients in Haskell. This could quite possibly be a separate project.

Yes, please! :pray: Otherwise, how do we write integration tests?

Is anyone aware of a haskell GraphQL client library?
https://haskell-graphql-api.readthedocs.io/en/latest/tutorial/Introduction.html#running-queries
Above link has an example for running queries but it's necessary to write the type out manually.


Fallback on slug not working with API

i'm using spree 4.3.2 with this gems. Backend working fine with fallback, but on API it doesn't work
Gemfile
gem 'spree_i18n', '~> 5.0' # remove any existing spree_i18n in Gemfile
gem 'friendly_id-mobility', git: 'https://github.com/mrbrdo/friendly_id-mobility', branch: 'master'
gem 'mobility', git: 'https://github.com/mrbrdo/mobility', branch: 'mrbrdo'
gem 'spree_mobility'

mobility.rb
Mobility.configure do
    plugins do
        fallbacks({ en: [:el], el: [:en] })
    end
end

For example i have a product with both data on english and greek language. The product have only one slug with locale el (greek) en is empty, when i call http://localhost:4000/api/v2/storefront/products/product1?locale=el it returns the result. But when i use ?locale=en the result is "The resource you were looking for could not be found."
When i use cli i get proper results
I18n.locale = :el
Spree::Product.friendly.find "product1" # it will return product with greek data and works with greek slug

I18n.locale = :en
Spree::Product.friendly.find "product1" # it will return product with english data  and works with greek slug

At the moment I am not using the API myself, I am using the legacy frontend. Due to time limitations I can't look into it myself, but if you manage to fix it I will be happy to merge it in. It seems like the way the API is finding the project bypasses the slug translations.

I will compare it to spree globalize and friendly-id globalize if i can find any solution from there.


add case-insensitive mode

Useful for matching/navigating xml document in a case-insensitive way (it does not affect parsing) #136
I had to add this for a project where server-side can't guarantee predictable casing.
i.e.
<section>
  <ParaM kind="person" age="33" />
  <Param kind="persoN" age="34" />
</section>

I also thought there are more efficient ways to do this like lowercasing values in parse however it would mean to loose information which is particularly important in the case of attribute and element values.

Hi @davibe - thanks for the PR!
I agree that lower-casing all values probably doesn't make sense. Maybe instead if there were a single method for looking so that the casing logic weren't duplicated would be better.
Last note - it looks like the CI build failed:
Compile Swift Module 'SWXMLHash' (2 sources)
/home/travis/build/drmohundro/SWXMLHash/Source/SWXMLHash.swift:293:55: error: missing argument for parameter 'caseInsensitive' in call
        let currentNode = parentStack.top().addElement(elementName, withAttributes: attributeNSDict)
                                                      ^
/home/travis/build/drmohundro/SWXMLHash/Source/SWXMLHash.swift:842:10: note: 'addElement(_:withAttributes:caseInsensitive:)' declared here
    func addElement(_ name: String, withAttributes attributes: NSDictionary, caseInsensitive:Bool) -> XMLElement {
         ^
/home/travis/build/drmohundro/SWXMLHash/Source/SWXMLHash.swift:374:55: error: missing argument for parameter 'caseInsensitive' in call
        let currentNode = parentStack.top().addElement(elementName, withAttributes: attributeNSDict)
                                                      ^
/home/travis/build/drmohundro/SWXMLHash/Source/SWXMLHash.swift:842:10: note: 'addElement(_:withAttributes:caseInsensitive:)' declared here
    func addElement(_ name: String, withAttributes attributes: NSDictionary, caseInsensitive:Bool) -> XMLElement {

Strange, tomorrow i fix CI build
Where would you put such centralized casing logic? I am not sure how to make the conf visible in inner classes without passing it down

Now the build failed for mysterious reasons that are not under my control
/Users/travis/.travis/job_stages: line 152: shell_session_update: command not found

@drmohundro

I rebased the patch on master removing conflicts.
I have fixed errors in ci due to my code. One is still there but i don't think my patch is causing it. Right ? /Users/travis/.travis/job_stages: line 152: shell_session_update: command not found
I have attempted to put the string case insensitive compare logic into one extension to kind of follow your suggestion. I still don't like the fact that i have to pass the caseInsensitive flag down like that.

Thanks @davibe! And yeah, I agree with you that passing down the flag doesn't make much sense... if you don't mind, I'd like to pull down your branch and experiment with extracting it somehow... like maybe having a single "key lookup" method that can be overwritten.
The general thought process I've got (which totally might not work) is something like:
// PSEUDOCODE
node.lookupByKey(key)

// under config, maybe?
fun lookupByKey(key: String) {
  if config.lookupByKey != nil {
    // call the case insensitive matcher (or a different one)
  }
  else {
    // default lookup
  }
}

Like I said, it might not work, but it would configurable which might allow for a totally separate approach where someone might be able to plug in their own key lookup method entirely.
Also, regarding the TravicCI build, I'm honestly not sure what that is... I agree that it doesn't seem to be related to your changes, but I'll dig on that, too.
Thanks for your patience!

@drmohundro how does node code access config ?
Are you suggesting to pass down the entire config object instead of just caseInsensitive flag ?
If you can suggest a way I can try something but otherwise I'd prefer to merge what we already have before new conflicts arise

@davibe yeah, thanks for helping me think through this - I had a simpler picture in my head, but you're correct. Besides, any sort of refactoring or re-implementation would be behind the public interface so it should be fine. I just pushed a tiny commit to hopefully prevent Travis from failing. Once that builds, I'll merge and push out 4.1.0.

Got the build passing! In case you were curious, the build error had nothing to do with shell_session_update, it was actually swiftlint - the errors were just further up in the build.
Your change is now live and tagged as 4.1.0. Thanks again!

Thank you @drmohundro !


Bug while running the merge profile list notebook

General Information:
Describe the bug:
dataprofiler.profilers.utils has changed to this dataprofiler.profilers.profiler_utils
ModuleNotFoundError                       Traceback (most recent call last)
Cell In[1], line 11
     10     import dataprofiler as dp
---> 11     from dataprofiler.profilers.utils import merge_profile_list
     12 except ImportError:

ModuleNotFoundError: No module named 'dataprofiler.profilers.utils'

During handling of the above exception, another exception occurred:

ModuleNotFoundError                       Traceback (most recent call last)
Cell In[1], line 14
     12 except ImportError:
     13     import dataprofiler as dp
---> 14     from dataprofiler.profilers.utils import merge_profile_list
     16 # remove extra tf loggin
     17 tf.compat.v1.logging.set_verbosity(tf.compat.v1.logging.ERROR)

ModuleNotFoundError: No module named 'dataprofiler.profilers.utils'

To Reproduce:
Checkout latest (0.10.3) version of the dataprofiler run notebook named merge_profile_list.ipynb
Expected behavior:
Failure on module import

Addressed this issue in this PR: https://github.com/capitalone/DataProfiler/pull/1018

Merged and resolved. Thanks @ksneab7 and @mxnavid


Spyder 2.3.8 can't start because QT_API is neither pyqt nor pyside; OS X 10.13.6 has pyqt5 instead

Issue Report Checklist

[ ] Searched the issues page for similar reports
[ ] Read the relevant sections of the Spyder Troubleshooting Guide and followed its advice
[ ] Reproduced the issue after updating with conda update spyder (or pip, if not using Anaconda)
[ ] Could not reproduce inside jupyter qtconsole (if console-related)
[ ] Tried basic troubleshooting (if a bug/error)

[ ] Restarted Spyder
[ ] Reset preferences with spyder --reset
[ ] Reinstalled the latest version of Anaconda
[ ] Tried the other applicable steps from the Troubleshooting Guide

[ ] Completed the Problem Description, Steps to Reproduce and Version sections below

Problem Description
I am on a mac, with the following specs/configuratoins:

OS X 10.13.6.
anaconda-navigator v 1.8.7
conda version 4.5.8
the root or base env has python 3.6.3 and I also have an env with python 3.4.5. because I support a machine that has that version.
spyder is version 2.3.8 in the python 3.4.5 env, and it is version 3.3.0 in the python 3.6.3 env.

I can start up spyder 3.3.0 just fine in the base env. However, when I try starting spyder 2.3.8 in the python 3.4.5 env from the command line, I get the error:
Traceback (most recent call last):
  File "/Users/paulcourtney/anaconda3/envs/Python_345/bin/spyder", line 3, in <module>
    start_app.main()
  File "/Users/paulcourtney/anaconda3/envs/Python_345/lib/python3.4/site-packages/spyderlib/start_app.py", line 114, in main
    from spyderlib import spyder
  File "/Users/paulcourtney/anaconda3/envs/Python_345/lib/python3.4/site-packages/spyderlib/spyder.py", line 48, in <module>
    requirements.check_qt()
  File "/Users/paulcourtney/anaconda3/envs/Python_345/lib/python3.4/site-packages/spyderlib/requirements.py", line 40, in check_qt
    from spyderlib import qt
  File "/Users/paulcourtney/anaconda3/envs/Python_345/lib/python3.4/site-packages/spyderlib/qt/__init__.py", line 12, in <module>
    assert os.environ['QT_API'] in ('pyqt', 'pyside')
AssertionError

So spyder 2.3.8 will not start.
I also did some sleuthing of similar problems (https://github.com/spyder-ide/spyder/issues/3171). I examined the QT_API environment variable in my mac and found it to be pyqt5. This explains to me why the assert is failing - neither pyqt nor pyside are found.
I also found that spyder 2.3.8 will sometimes fail when starting from Anaconda Navigator and sometimes successfully start. When it fails, the same error message is given.
What steps reproduce the problem?

Mac OS X 10.13.6 with Anaconda Navigator v 1.8.7
Use conda to create an env for python 3.4.5
Start spyder from the command line while in the python 3.4.5 env or start spyder from Anaconda Navigator with the Python 3.4.5 env selected.

What is the expected output? What do you see instead?
I should see Spyder start up. Instead I see the error message.
Paste Traceback/Error Below (if applicable)

Traceback (most recent call last):
  File "/Users/paulcourtney/anaconda3/envs/Python_345/bin/spyder", line 3, in <module>
    start_app.main()
  File "/Users/paulcourtney/anaconda3/envs/Python_345/lib/python3.4/site-packages/spyderlib/start_app.py", line 114, in main
    from spyderlib import spyder
  File "/Users/paulcourtney/anaconda3/envs/Python_345/lib/python3.4/site-packages/spyderlib/spyder.py", line 48, in <module>
    requirements.check_qt()
  File "/Users/paulcourtney/anaconda3/envs/Python_345/lib/python3.4/site-packages/spyderlib/requirements.py", line 40, in check_qt
    from spyderlib import qt
  File "/Users/paulcourtney/anaconda3/envs/Python_345/lib/python3.4/site-packages/spyderlib/qt/__init__.py", line 12, in <module>
    assert os.environ['QT_API'] in ('pyqt', 'pyside')
AssertionError

Versions

Spyder version: 2.3.8
Python version: 3.4.5
Qt version: 4.8.7
PyQt version: 4.11.4
Operating System name/version: OS X High Sierra 10.13.6

Dependencies

Note that these dependencies are courtesy of Spyder rather miraculously starting up from Anaconda Navigator.
IPython >=1.0      :  5.1.0 (OK)
jedi >=0.8.1;<0.9.0:  0.9.0 (NOK)
matplotlib >=1.0   :  None (NOK)
pandas >=0.13.1    :  None (NOK)
pep8 >=0.6         :  1.7.0 (OK)
psutil >=0.3       :  5.0.1 (OK)
pyflakes >=0.6.0   :  1.5.0 (OK)
pygments >=1.6     :  2.1.3 (OK)
pylint >=0.25      :  1.7.4 (OK)
qtconsole >=4.0    :  4.2.1 (OK)
rope >=0.9.2       :  0.9.4-1 (OK)
sphinx >=0.6.6     :  1.5.1 (OK)
sympy >=0.7.3      :  None (NOK)
zmq >=2.1.11       :  16.0.2 (OK)

We don't support that version anymore (it's more than 2 years old). Please use conda to install our latest version (3.3.0).


Fix MSXML conflict

See issue #37.

Well, I would have added this to the original issue, but it's closed.   Since I just happened to pick up a project that is still using TinyXML2 v3.0.0 (ikr), which still used TiXMLDocument, which was very unnatractive, I just renamed it to XMLDocument, and did this.
#include "tinyxml2.h"
using namespace tinyxml2;
#define XMLDocument tinyxml2::XMLDocument