Emit default case for exhaustive switches on JS backend

The JVM backend always emits this default case if a switch does not have an explicit else case:
else throw new .com.redhat.ceylon.compiler.java.language.EnumeratedTypeError("Supposedly exhaustive switch was not exhaustive");

I think it would be a good idea to do this on the JS backend as well. After all, the JS platform makes even less guarantees at runtime than the JVM (e. g. no guarantee that a String member actually contains a String value), and so a switch might not be exhaustive not only due to compiler bugs (e. g. #6311), but also simply because other parts of the program might not adhere to Ceylon’s typing rules (for example, TypeScript enums are just glorified integers, and there’s nothing to prevent someone from assigning 1337 to an enum with only the cases 0 and 1).

This should be a bug IMO, given the language guarantee and the type of bugs that may result when it is not met.

If I can easily create an example that makes the need for this obvious, I'll implement it.

The JS backend already adds this check when dealing with dynamic types.

However, if you do this, with no dynamic blocks:
String|Integer foo() => "It's a string";

shared void run() {
    switch(x=foo())
    case (is Integer) {
      print("It's an int");
    }
    case (is String) {
      print("It's a string");
    }
    print("realmente fue ``className(foo())``");
}

And then override foo with a native file ``function foo() { return 3.14; }` then the switch won't cover that case and it's going to be hell to debug. So I guess this might be necessary after all.

Thanks!


Too many open files error

Failed to annotate block: INTERNAL: Failed to create a pipe for interprocess communication between llvm-exegesis and the benchmarking subprocess: Too many open files

More investigation is needed. Probably an issue on the LLVM side, but opening here first in case there is some complicated interaction.

This is an upstream issue: https://github.com/llvm/llvm-project/issues/86583.

Closed by #115.


Brave/BAT verify ipfs.io and the other websites

Our brave 🦁 friends invited us to verify our websites so that we could collect Brave Tokens. More than collecting the tokens, it is a good way for us to give feedback to their platform by experimenting with it first hand.
Apparently the process is simple, we just need to go to https://publishers.basicattentiontoken.org/
@lgierth thoughts?

Can we limit this to certain subpages? It's okay to have ipfs.io and other project websites covered by this, but it's not okay for us to get paid for gateway content.

Anybody feel free to pick this up - I can help out with the DNS records for verification.

Hi, @lgierth I work at Brave and am on the BAT team. Adding some info from our end re: intent and utility.
To clarify, verification should only apply to the ipfs.io website, and is not intended to be applied for gateway content.
If gateway content is hosted with the ipfs.io domain, LMK. If this is the case, I can inquire internally to determine if we can potentially blacklist any subdomains or other URLs from eligibility if they use ipfs.io in addition to the project website.
If it's too much hassle, or a blocker for your use case, not the end of the world. Totally understand respect (and share) the concern wrt gateway content.
If I can be of any assistance with the process or questions, feel free to tag me here. Happy to help from our end.

If gateway content is hosted with the ipfs.io domain, LMK

Yeah that's the case :) We have the project website https://ipfs.io, and then content at e.g. https://ipfs.io/ipfs/QmPCawMTd7csXKf7QVr2B1QRDZxdPeWxtE4EpkDRYtJWty - the paths involved here are /ipfs, /ipns, /ws, and /api. We will be separating this soon though, aiming for end-of-year. These four paths will then be redirected to https://dweb.link
What do you think?

Closing this for now - I'm sure we'll get back to it :100:


[WIP] Document release steps

What this PR does / why we need it:
Attempts to document release procedure, and separate what concerns contributors (versioning policy and branch workflow) versus what concerns maintainers.
This doc is in GitBook but these changes need discussion: the procedure is my guess, I haven't done it so I'll need your help to correct errors and omissions.
A couple of remarks or observations with what I have here:

I'm not sure that the conventional Maven SNAPSHOT dance has been practiced consistently to this point. We could discuss alternatives, but so long as we intend to use it, tagged release commits ideally ought to not contain -SNAPSHOT in the POM. I've suggested a procedure that maintains this, but it's unfortunately a lot of ceremony when you have branch protection, the snapshot dance, and changelog update (2 PRs, several redundant CI builds). Some ceremony is warranted for major releases I think, but it'd be nice if it could be one PR somehow.
One redundant build is inevitable with the snapshot convention I think, even if branch protection was skipped: CI passed on latest master, but a commit is needed to remove -SNAPSHOT before tagging.

A shortcoming with the changelog generator seems to be that, as far as I understand, the released version needs to be tagged (and pushed to GitHub?) before you run it. Ideally IMO changelog would precede the tagged commit, even makes a good candidate to be the tagged release commit along with version string updates.
Having a changelog to scan is helpful before making a version number decision, to review the Semantic Versioning implications of the release. You could run the tool in dry-run stdout mode for that I guess, but if you wanted to commit it before the act of tagging, you'll be left manually editing the file with the intended version number.

Which issue(s) this PR fixes:
Relates to #442, subsequent private conversation about whether others with certain maintainer rights are able to make releases.
Does this PR introduce a user-facing change?:
NONE

/test test-end-to-end-batch

@ches I need to merge some changes into this same markdown doc, although its more structural. You will probably have to refactor your PR slightly, but it shouldnt be too hard.

I need to merge some changes into this same markdown doc, although its more structural. You will probably have to refactor your PR slightly, but it shouldnt be too hard.

No worries, let me know when it's in. If you're not already doing something similar, as per https://github.com/gojek/feast/issues/420#issuecomment-586101133 I was going to basically pull out everything above the "Development" header to a new Getting Started or Quick Start page, then tweak Contributing with some new introduction.
Those are probably fairly uncontroversial changes / can be iterated on without discussion, unlike the release procedure.

I need to merge some changes into this same markdown doc, although its more structural. You will probably have to refactor your PR slightly, but it shouldnt be too hard.

No worries, let me know when it's in. If you're not already doing something similar, as per #420 (comment) I was going to basically pull out everything above the "Development" header to a new Getting Started or Quick Start page, then tweak Contributing with some new introduction.
Those are probably fairly uncontroversial changes / can be iterated on without discussion through GitBook, unlike the release procedure.

I submitted my changes. Gitbook also has "dropdown" menu items now, so we can organize all of this information under a nice heading if you think that makes sense.
Feel free to make edits as necessary.

What this PR does / why we need it:
Attempts to document release procedure, and separate what concerns contributors (versioning policy and branch workflow) versus what concerns maintainers.
This doc is in GitBook but these changes need discussion: the procedure is my guess, I haven't done it so I'll need your help to correct errors and omissions.
A couple of remarks or observations with what I have here:

I'm not sure that the conventional Maven SNAPSHOT dance has been practiced consistently to this point. We could discuss alternatives, but so long as we intend to use it, tagged release commits ideally ought to not contain -SNAPSHOT in the POM. I've suggested a procedure that maintains this, but it's unfortunately a lot of ceremony when you have branch protection, the snapshot dance, and changelog update (2 PRs, several redundant CI builds). Some ceremony is warranted for major releases I think, but it'd be nice if it could be one PR somehow.

The release automation right now is a little bit manual still. Do you have examples of how this can be rolled into a single PR? Perhaps just making sure everyone agrees to and follows a process is a start, which is why I like this PR. Ideally this would be automated away from people, but I think we have lower hanging fruit right now.

One redundant build is inevitable with the snapshot convention I think, even if branch protection was skipped: CI passed on latest master, but a commit is needed to remove -SNAPSHOT before tagging.

A shortcoming with the changelog generator seems to be that, as far as I understand, the released version needs to be tagged (and pushed to GitHub?) before you run it. Ideally IMO changelog would precede the tagged commit, even makes a good candidate to be the tagged release commit along with version string updates.

Yes, having it be the tagged commit makes sense to me as well.

Quoting @woop from #442 because I think it's more contextual here:

I'm trying to figure out what all the missing pieces are here. @ches is it possible for you to enumerate your uncertainties? Or if you have certainties (like access you need) then you could also let me know and I will try to address them.

I think what I'd like to suggest at this point is for someone who has actually released Feast before to follow this PR's guide to make a release for v0.3.6 / 0.3.7, fill in anything missing in my doc as you go, and send a PR against this one that fills in the gaps. Basically, I don't know what I don't know 😊
Before we postulate how process/automation could potentially be improved, let's first accurately capture how it actually works at present. Hopefully that breaks the impasse.

I don't know what I don't know

Touché.

follow this PR's guide to make a release for v0.3.6 / 0.3.7, fill in anything missing in my doc as you go

Sure, makes sense. We are also in a bit of crunch mode right now, so I do apologize for the lack of attention here. Hoping to swing back to this soon.

A shortcoming with the changelog generator seems to be that, as far as I understand, the released version needs to be tagged (and pushed to GitHub?) before you run it.

It seems like the changelog generator has an unreleased section that it generates. If we are assuming that all unreleased changes would make it into the release, then I think it solves the problem.
For example I just ran it
# Changelog

## [Unreleased](https://github.com/gojek/feast/tree/HEAD)

[Full Changelog](https://github.com/gojek/feast/compare/v0.4.7...HEAD)

**Closed issues:**

- Feast Core: Dataflow Runner fails to start job with no translator registered error. [\#642](https://github.com/gojek/feast/issues/642)
- Feast Serving not registering store in Feast Core [\#640](https://github.com/gojek/feast/issues/640)
[SNIP]

**Merged pull requests:**

- Fix config validation for feast.jobs.metrics.host [\#662](https://github.com/gojek/feast/pull/662) ([davidheryanto](https://github.com/davidheryanto))
- Docker compose bug fix  [\#661](https://github.com/gojek/feast/pull/661) ([woop](https://github.com/woop))
- Upgrade github checkout action to v2 [\#660](https://github.com/gojek/feast/pull/660) ([khorshuheng](https://github.com/khorshuheng))

Even makes a good candidate to be the tagged release commit along with version string updates.

If the above holds true, then we could use the changelog generator to create the changelog. Push it with the version string updates. Review it. Get it merged. Push the tag.
But the problem is we still need the pom.xml / Snapshot addition after that, right? I don't see a way around having two PRs, unless we just want to push straight to master to add that back in.
Overall I think the process you have described makes sense. Changes/additions

Update the order of events to include the changelog in the release commit
Add more details on how to generate the changelog. I think this can be a different section altogether. You can just link to the header.
Add more details on how to document the GitHub release summary page.

Once we have updated the above, somebody should then walk through it.

Generating a Change Log
We use an open source change log generator to generate change logs. The process still requires a little bit of manual effort.

Create a GitHub token as per these instructions . This is used as an input argument (-t) to the changelog generator.
The change log generator will look for unreleased changes on a specific branch. This will be master for a major/minor release, or it will be a release branch (v0.4-branch) for a patch release. You will need to set this using the --release-branch argument.
It is also advised to set a proposed version. This is the version that you will be releasing. The version can still be changed at a later date. Please use --future-release to set this version using semver format.
Update the  arguments below and run the command to generate the change log to the console.

docker run -it --rm ferrarimarco/github-changelog-generator \
--user gojek \
--project feast  \
--release-branch <release-branch-to-find-changes>  \
--future-release <proposed-release-version>  \
--unreleased-only  \
--no-issues  \
--bug-labels kind/bug  \
--enhancement-labels kind/feature  \
--breaking-labels compat/breaking  \
-t <your-github-token>  \
--max-issues 1 \
-o

Please review each change log item.

Make sure that sentences are grammatically correct and well formatted (although we will try to enforce this at the PR review stage).
Make sure that each item is categorized correctly. You will see the following categories: Breaking changes, Implemented enhancements, Fixed bugs, and Merged pull requests. Any unlabeled PRs will be found in Merged pull requests. It's important to make sure that any breaking changes, enhancements, or bug fixes are pulled up to the correct categories. Housekeeping, tech debt clearing, infra changes, or refactoring do not count as enhancements. Only enhancements a user benefits from should be listed in that category.

One open question: Which changelog do we update? Clearly we want to update the master branch, but is it sufficient to only update master and the respective release branch? If we have to update master then we would be updating the change log in three places, and we need 3 PRs.

/test test-end-to-end

I've updated the guide. You might want to have a quick look. It works fine for the most part. I think we should perhaps resolve conflicts and merge this in, and then add more details on which artifacts are being produced. That might be a separate section though.

Thanks for the updates! LGTM, I will fix the conflicts shortly.

Rebased, and moved this to the broken out release-process.md that exists now. Master still has the monolithic contributing/contributing.md where this patch still applied and broken out pages with the same information (some of which missed good updates to the monolith I think).
That'll get sorted out, but now it's easier to port to the v0.4-branch docs that are live on GitBook. I can send a PR for that as well.

Thanks @ches. I can help with cleanup. For the time being I'd just like to get this merged in. We won't lose it, I promise :)

/lgtm

/approved

/approve


Unresolved external symbol errors

I tried to install x64 of boost and OpenSSL they have build the files but the build tool version of the lib files seem to be v140 I'm not sure if that's what is causing my errors but doesn't seem to make all the lib files in boost-filesystem unsure if other have built okay or not!

All vc14* for port boost lib build will be uniformly changed to vc140. Currently, other downstream dependencies use boost normally. So this problem may be due to other reasons. Could you provide logs to help debug the issue?

So i change the project to debug and it built but the release version doesn't build at all!

@XECTRA-RAW Could you please provide the build logs for debug? See #30604 on how to append logs.


#158111459 An admin can view all the users requests

What does this PR do?
Allows a logged in Admin to view all the requests made by the users.
Description of Task to be completed?

View all requests.
Ensuring token is passed to the header.
Ensure only admin can view.

How should this be manually tested?
$ git clone https://github.com/dalaineme/m-tracker.git

$ cd m-tracker

Create a virtual environment
$ python3.6 -m venv venv

Activate a virtual environment
$ source venv/bin/activate

Install project dependencies
$ pip install -r requirements.txt

Run the server
$ python run.py

Using postman, send a GET request to the URL _http://<IP_ADDRESS>:5000/api/v1/requests_
Refer to the screenshots below.
Any background context you want to provide?
Authorization header MUST be provided
What are the relevant pivotal tracker stories?
https://www.pivotaltracker.com/story/show/158111459
Screenshots
Success.

No requests found.

Normal user trying to access the endpoint.

Pull Request Test Coverage Report for Build 183

37 of 37 (100.0%)  changed or added relevant lines in 4 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.4%) to 96.601%

Totals

Change from base Build 177:
0.4%

Covered Lines:
341

Relevant Lines:
353

💛  - Coveralls

Pull Request Test Coverage Report for Build 183

37 of 37 (100.0%)  changed or added relevant lines in 4 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.4%) to 96.601%

Totals

Change from base Build 177:
0.4%

Covered Lines:
341

Relevant Lines:
353

💛  - Coveralls


test_cli Fix Assertion error due to path mismatch

running test_cli locally results in an assertion error, because it is testing against the wrong folder.
steps to reproduce:

go to by $ cd invoice2data/tests
$ python test_cli.py

results in
======================================================================
FAIL: test_copy (__main__.TestCLI)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "test_cli.py", line 136, in test_copy
    self.assertEqual(i, len(get_sample_files('.json')))
AssertionError: 0 != 6

----------------------------------------------------------------------

This fix let it test against the created folder. By using the same variable.

force pushing to trigger tests

@bosd: does this problem (AssertionError) occur if you run tests using python -m tests.test_cli ?

does this problem (AssertionError) occur if you run tests using python -m tests.test_cli ?

Just tested both cases:

Before this commit. Running python -m tests.test_cli returns OK.
After this commit python -m tests.test_cli returns FAILED :exclamation: .

So we can conclude that:

Better not merge this commit.
Call unittests with:
python -m tests.test_cli
python -m unittest tests/test_cli.py
python -m unittest discover

Better improve documentation how to properly run the tests.
As a side note. Would expect that python -m unittest invoice2data would work. But it actually won't call any test.


Test with odo pipeline create prototype

The bootstrap branch in https://github.com/rhd-gitops-example/odo shows how odo pipelines bootstrap (init) can be used to create a gitops repo that should be compatible with our promote verb. Check that this is still the case. Can we script a manual test for this?

Notes:

installed binami-labs sealed secrets
created a secret containing access token to access github (foo)
ran odo pipelines init --gitops-repo owner/repo --gitops-webhook-secret foo

Results in the following creation

directories contain pre-configured yaml that can applied to the system, e.g an eventlistener for the repo specified on the odo command. There are 2 pipleines, one for dry run and one for "deploy from push" essentially a kubctl apply...
steps:
  - args:
    - apply
    - --dry-run=$(inputs.params.DRYRUN)
    - -n
    - $(inputs.params.NAMESPACE)
    - -k
    - $(inputs.params.PATHTODEPLOYMENT)
    command:
    - kubectl
    image: quay.io/redhat-developer/k8s-kubectl
    name: run-kubectl
    resources: {}
    workingDir: /workspace/source

Chatted with Kevin about this (because we were looking for the app/deployment structure to be created rather than the tekton artefacts), and he pointed me to a tool in his repo "manifestor" which takes a yaml input and outputs a directory structure akin to what was required.

https://github.com/bigkevmcd/manifestor
ran manifestor bootstrap ./input-yaml ./outputdir

for input:
environments:
  - name: development
    pipelines:
      integration:
        template: dev-ci-template
        binding: dev-ci-binding
      deployment:
        template: dev-cd-template
        binding: dev-cd-binding
    apps:
      - name: my-app-1
        services:
          - name: app-1-service-http
            source_url: https://github.com/myproject/myservice.git
          - name: app-1-service-metrics
      - name: my-app-2
        services:
          - name: app-2-service
  - name: staging
    apps:
      - name: my-app-1
        services:
          - name: app-1-service-http
  - name: production
    apps:
      - name: my-app-1
        services:
          - name: app-1-service-http
          - name: app-1-service-metrics
            config_repo:
              url: https://github.com/testing/testing
              ref: master
              path: config

output is:

sample expanded output:

I'm closing this as I haven't done anything more on it and not been instructed to do so.


Currently I am trying to use overflow scroll in a react application, but it doesn't seem to be working.

Environment

npx envinfo --system --binaries --npmPackages styled-components,babel-plugin-styled-components --markdown --clipboard
Reproduction

https://codesandbox.io/s/styled-components-base-gc367
Steps to reproduce
Create a styled component in react
Add this block of code to the your styled component
  -ms-overflow-style: none; /* for Internet Explorer, Edge */
  scrollbar-width: none; /* for Firefox */
  ::-webkit-scrollbar {
    display: none; /* for Chrome, Safari, and Opera */
}

Render component
Expected Behavior
Actual Behavior

Hey,
do adding
export default styled.section`
padding: 4em;
background: papayawhip;

overflow: scroll;
height: 25px; --> any height that ensures the text overflows the container
`;
to Wrapped.js not work? Working for me


Float64 support for cap-mbps parameter

I've made changes for cap-mbps to support float64, particularly for scenarios where bandwidth is severely limited and there's a necessity to limit bandwidth to a fraction of 1 mbps.

 Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.:x: 9137 sign nowYou have signed the CLA already but the status is still pending? Let us recheck it.

Thanks @9137 .  I'm not sure if we'll get this reviewed and included in 10.4 (As you can see from the PR list, there are a lot that won't make it into that release).  But we do appreciate your contribution and will take a look at it after we have finished release 10.4 (in not earlier).

Thanks @9137 . I'm not sure if we'll get this reviewed and included in 10.4 (As you can see from the PR list, there are a lot that won't make it into that release). But we do appreciate your contribution and will take a look at it after we have finished release 10.4 (in not earlier).

No worries, that's not an issue. Thanks for looking into my PR and feel free to let me know if it requires some tweaking.

Oh, and please retarget this PR to the dev branch. Everything goes there. Then gets merged to Master at release time.

Oh, and please retarget this PR to the dev branch. Everything goes there. Then gets merged to Master at release time.

I'll close this PR and re-open a new one from dev branch in this case.

https://github.com/Azure/azure-storage-azcopy/pull/924


TWEAK: Check for errors when preparing statement.

@cpacia Please review. Wasn't sure if there was a reason this was skipped or if it was just an oversight.

Changes Unknown when pulling 4646521e928191061d7e310fe2c6879dfd83f7cd on TS_err_check into ** on master**.


[stable/external-dns]: fix checksum on annotations

What this PR does / why we need it:
Truncating may not work as the hash may start with a number, which would also be invalid. AS far as I looked into the other charts, those things are usually on pod annotations, which cause the same effect and accepts virtually everything.
Which issue this PR fixes

fixes https://github.com/helm/charts/issues/15011

Special notes for your reviewer:
I tested it on a k3d cluster with:
helm install --namespace default --name dns ./stable/external-dns --set podAnnotations.foo=bar

and
helm upgrade --namespace default dns ./stable/external-dns --set podAnnotations.foo=bar --set aws.credentials.secretKey=aaaaaaaaaa --set aws.credentials.accessKey=aaaaaaaaaaaaaaaab

seemed to work as expected.
Checklist
[Place an '[x]' (no spaces) in all applicable fields. Please remove unrelated fields.]

[x] DCO signed
[x] Chart Version bumped
[x] Variables are documented in the README.md
[x] Title of the PR starts with chart name (e.g. [stable/chart])

/assign @tompizmor

Thanks for the PR. As you mention, I have also seen those checksum checks in podAnnotations rather than labels.


Add a heartbeat between spfs-monitor and spfs-fuse

As mentioned in #895, there are cases where spfs-fuse never shuts down. An easy way to repro this is to kill -9 the spfs-monitor process, so it doesn't get a chance to clean up the runtime normally.
We observe spfs-fuse processes accumulating over time on our CI runners. It could be from users canceling pipelines (maybe the runner does a kill -9 of all the child processes?). It is also extremely common for zombie runtimes to accumulate over time (not just on CI runners), perhaps spfs-monitor is crashing / failing to cleanup commonly?
This is a proof of concept and enabling this or tuning the timing of the heartbeat and timeout should be a configurable thing but these are hard coded for now.

I think the biggest concern is linking the lifetime of spfs-fuse to spfs-monitor. At face value that's what we want in order to solve the zombie spfs-fuse problem, but if spfs-monitor is crashing unexpectedly which the runtime is still in use then the fuse filesystem would be shutting down prematurely.
If spfs-monitor is crashing that's a serious problem that needs to be sorted out. This heartbeat link may be dangerous until that happens. But is it crashing, or is it getting killed? This is unclear. If it is getting killed (with -9) because a job is killed in CI or on the farm or whatever, then before this change spfs-fuse would keep running forever, and after this change it would terminate.


Only store 2 days nearest log

This is my config to .Net Project.
The log only stored 2 days nearest.
Example in 2 days : 11/18/2019 and 11/19/2019, 2 log  files will be created and stored. But in 11/20/2019 when I do somthing , The log file of  11/18/2019 will be replaced by log file of  11/20/2019.
Can you find to me what wrong in my config, I also used maxArchiveFiles="10" but it not working.
I looking forward to receive your response.
Thanks a lot.

Hi, Please fill in the template.


dev - prepping link fixes

Yay for links.

Looks great.

Got most things un-broken, and some links to RTD.  Let's merge this, then spend some time fixing things for better non-RTD navigation.

So, I looked at dev and it appeared to fix most of the links. However, this stripped a LOT of the usability out of this. I will merge this as a bandaid, but please hold off on making any other major changes in the interim, especially without following the community best-practice of getting two +1s from other people for major changes or merges.
I will take the next step of doing a wip or dev branch to do the next gen stuff that we can work from content and structure-wise.


Put back partners logos

Put back partners logos, previously removed by #1375. This is a simple test to see if the CircleCI tests are going to fail.
Issues this PR resolves

#1377

Checklist

[x] Code review by me
[ ] Hand tested by me
[ ] I'm proud of my work
[ ] Code review by reviewer
[ ] Hand tested by reviewer
[ ] CircleCi tests are passing
[ ] Ready to merge

The problem is confirmed...

@dependabot rebase


Reinstate interstitial page turned on for links to Console

The Chore
Create a PR with the interstitial page reimplemented for all links out to console ready to be released when trading goes live and the mainnet version of Console is deployed.
Tasks

[ ] Update the content - the last version of the content was amended to be accurate for fairground (which is hosted by Vega) whilst we had it up to test it. The content needs to go back to what it said originally:

[ ] Ensure the internationalisation side of things are complete - I believe the outstanding banner had already been implemented but may not yet be live

[ ] Establish whether we need to do anything in terms of the domain of the interstitial page - see [slack thread] (https://vegaprotocol.slack.com/archives/C8WS7M50E/p1680779647790959?thread_ts=1680772807.430259&cid=C8WS7M50E) from early April that seems to imply that interstitial page should be hosted on a separate domain

But we do need to host the "interstitial" page that will redirect to dapps like Console somewhere (redirect.vega.xyz?)
We will also want vega.trading and possibly console.vega.xyz to redirect to the IPFS Console via the interstitial page at [redirect.vega.xyz]

[ ] Review with Matt, Edd and Barney to make sure they are happy with it

History
In case you're bored and want a long meandering read:
https://vegaprotocol.slack.com/archives/C02KUFHDYAC/p1674081362797829
https://github.com/vegaprotocol/vega.xyz/issues/246
https://github.com/vegaprotocol/vega.xyz/issues/390
https://github.com/vegaprotocol/vega.xyz/pull/395

Combined into #552


macOS oc login error: net/http: TLS handshake timeout

General information

OS: macOS Catalina 10.15.6
Hypervisor: hyperkit
Did you run crc setup before starting it (Yes/No)? YES

CRC version
CodeReady Containers version: 1.14.0+36ad776
OpenShift version: 4.5.4 (embedded in binary)

CRC status
DEBU CodeReady Containers version: 1.14.0+36ad776
DEBU OpenShift version: 4.5.4 (embedded in binary)
DEBU About to run SSH command with hidden output
DEBU SSH command succeeded
DEBU kube-apiserver operator is degraded, Reason: NodeInstaller_InstallerPodFailed
DEBU kube-apiserver operator is still progressing, Reason: NodeInstaller
DEBU operator-lifecycle-manager-packageserver operator not available, Reason:
DEBU operator-lifecycle-manager-packageserver operator is still progressing, Reason:
DEBU About to run SSH command:
df -B1 --output=size,used,target /sysroot | tail -1
DEBU SSH command results: err: <nil>, output:<PHONE_NUMBER>0<PHONE_NUMBER>4 /sysroot
CRC VM:          Running
OpenShift:       Degraded
Disk Usage:      13.01GB of 32.72GB (Inside the CRC VM)
Cache Usage:     13.1GB
Cache Directory: /Users/luca/.crc/cache

CRC config
# Put the output of `crc config view`

Host Operating System
ProductName:	Mac OS X
ProductVersion:	10.15.6
BuildVersion:	19G2021

Steps to reproduce
crc console open console on my browser (Safari) and I can connect without problems with developer and kubeadmin users
oc login via CLI does not work with the following error:
~/Utils/OpenShift/crc-macos-1.14.0-amd64 % oc login -u developer -p developer https://api.crc.testing:6443
error: net/http: TLS handshake timeout
~/Utils/OpenShift/crc-macos-1.14.0-amd64 % oc login -u kubeadmin -p DhjTx-8gIJC-2h2tK-eksGY https://api.crc.testing:6443
error: net/http: TLS handshake timeout

Update.
Using the oc command installed via HomeBrew the issue is not present and I can connect via CLI:
~/Utils/OpenShift/crc-macos-1.14.0-amd64 % **/usr/local/bin/oc version
Client Version: version.Info{Major:"4", Minor:"1+", GitVersion:"v4.1.0+b4261e0", GitCommit:"b4261e07ed", GitTreeState:"clean", BuildDate:"2019-10-06T23:21:44Z", GoVersion:"go1.13.1", Compiler:"gc", Platform:"darwin/amd64"}**
~/Utils/OpenShift/crc-macos-1.14.0-amd64 % oc login -u developer -p developer https://api.crc.testing:6443
The server uses a certificate signed by an unknown authority.
You can bypass the certificate check, but any data you send to the server could be intercepted by others.
Use insecure connections? (y/n): y

Login successful.

You don't have any projects. You can try to create a new project, by running

    oc new-project <projectname>

Welcome! See 'oc help' to get started.
~/Utils/OpenShift/crc-macos-1.14.0-amd64 % crc console --credentials
~/Utils/OpenShift/crc-macos-1.14.0-amd64 % oc get co
Error from server (Forbidden): clusteroperators.config.openshift.io is forbidden: User "developer" cannot list resource "clusteroperators" in API group "config.openshift.io" at the cluster scope

@savonarola27 The one which you got from homebrew is quite old (4.1.0), we will verify in the mac the one which we extract as part of crc, also meanwhile can you check your mac settings (privacy) if by any chance oc is blocked?

mhhhh I think that there are no security & privacy settings issues because iTerm2 (the app which I use as terminal console) has Full Disk Access permission.
Basic operations work without problem:
~/Utils/OpenShift/crc-macos-1.14.0-amd64 % /Users/luca/.crc/bin/oc/oc
OpenShift Client

This client helps you develop, build, deploy, and run your applications on any
OpenShift or Kubernetes cluster. It also includes the administrative
commands for managing a cluster under the 'adm' subcommand.

To familiarize yourself with OpenShift, login to your cluster and try creating a sample application:

    oc login mycluster.mycompany.com
    oc new-project my-example
    oc new-app django-psql-example
    oc logs -f bc/django-psql-example

To see what has been created, run:

    oc status

and get a command shell inside one of the created containers with:

    oc rsh dc/postgresql

To see the list of available toolchains for building applications, run:

    oc new-app -L

Since OpenShift runs on top of Kubernetes, your favorite kubectl commands are also present in oc,
allowing you to quickly switch between development and debugging. You can also run kubectl directly
against any OpenShift cluster using the kubeconfig file created by 'oc login'.

For more on OpenShift, see the documentation at https://docs.openshift.com.

To see the full list of commands supported, run 'oc --help'.
~/Utils/OpenShift/crc-macos-1.14.0-amd64 % /Users/luca/.crc/bin/oc/oc version
Client Version: 4.5.4
Kubernetes Version: v1.18.3+012b3ec

More info:
~/Utils/OpenShift/crc-macos-1.14.0-amd64 % oc login -u developer -p developer https://api.crc.testing:6443
error: net/http: TLS handshake timeout
~/Utils/OpenShift/crc-macos-1.14.0-amd64 % oc login -u developer -p developer https://api.crc.testing:6443 --loglevel=10
I0820 13:56:11.537056   38094 loader.go:375] Config loaded from file:  /Users/luca/.kube/config
I0820 13:56:11.539503   38094 round_trippers.go:423] curl -k -v -XHEAD  'https://api.crc.testing:6443/'
I0820 13:56:21.546951   38094 round_trippers.go:443] HEAD https://api.crc.testing:6443/  in 10007 milliseconds
I0820 13:56:21.546998   38094 round_trippers.go:449] Response Headers:
F0820 13:56:21.548845   38094 helpers.go:115] error: net/http: TLS handshake timeout

I think the problem is in the curl call but I don't know why. It seems that handshake is successful.
~/Utils/OpenShift/crc-macos-1.14.0-amd64 % curl -k -v -XHEAD  'https://api.crc.testing:6443/'
Warning: Setting custom HTTP method to HEAD with -X/--request may not work the
Warning: way you want. Consider using -I/--head instead.
*   Trying <IP_ADDRESS>...
* TCP_NODELAY set
* Connected to api.crc.testing (<IP_ADDRESS>) port 6443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/cert.pem
  CApath: none
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Request CERT (13):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Certificate (11):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
* ALPN, server accepted to use h2
* Server certificate:
*  subject: CN=api.crc.testing
*  start date: Aug 19 13:09:40 2020 GMT
*  expire date: Sep 18 13:09:41 2020 GMT
*  issuer: OU=openshift; CN=kube-apiserver-lb-signer
*  SSL certificate verify result: self signed certificate in certificate chain (19), continuing anyway.
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x7fe6cd008600)
> HEAD / HTTP/2
> Host: api.crc.testing:6443
> User-Agent: curl/7.64.1
> Accept: */*
>
* Connection state changed (MAX_CONCURRENT_STREAMS == 2000)!
< HTTP/2 403
< audit-id: d81ad7ae-6d40-4e67-8984-291f809be6fb
< cache-control: no-cache, private
< content-type: application/json
< x-content-type-options: nosniff
< x-kubernetes-pf-flowschema-uid: 57e81c82-2a88-4658-822f-41806736f6ff
< x-kubernetes-pf-prioritylevel-uid: 9d3b9d61-319a-4254-87e3-a746607c7e0e
< content-length: 234
< date: Thu, 20 Aug 2020 11:56:41 GMT
<
* transfer closed with 234 bytes remaining to read
* stopped the pause stream!
* Connection #0 to host api.crc.testing left intact
curl: (18) transfer closed with 234 bytes remaining to read
* Closing connection 0

@savonarola27 can you try to download the latest version of oc client binary http://mirror.openshift.com/pub/openshift-v4/clients/ocp/4.5.7/openshift-client-mac-4.5.7.tar.gz and then try with it, to understand it is issue with a specific version of oc command?

Unfortunately I have the same error:
~/Utils/OpenShift/crc-macos-1.14.0-amd64 % ~/Utils/OpenShift/oc/oc login -u developer -p developer https://api.crc.testing:6443 --loglevel=10
I0820 14:13:46.931012   39518 loader.go:375] Config loaded from file:  /Users/luca/.kube/config
I0820 14:13:46.933689   39518 round_trippers.go:423] curl -k -v -XHEAD  'https://api.crc.testing:6443/'
I0820 14:13:56.946061   39518 round_trippers.go:443] HEAD https://api.crc.testing:6443/  in 10012 milliseconds
I0820 14:13:56.946106   39518 round_trippers.go:449] Response Headers:
F0820 14:13:56.947515   39518 helpers.go:115] error: net/http: TLS handshake timeout

~/Utils/OpenShift/crc-macos-1.14.0-amd64 % ~/Utils/OpenShift/oc/oc version
Client Version: 4.5.7
Kubernetes Version: v1.18.3+012b3ec

I still think the problem is with the "curl -k -v -XHEAD  'https://api.crc.testing:6443/'" command... I want to try with a different version with it. I don't remember if I use the brew version or the macOS one. I will let you know.

For reference. Even with the brew version of curl (7.72.0) or the macOS version (7.64.1) the issue persists.
~/Utils/OpenShift/crc-macos-1.14.0-amd64 % eval $(crc oc-env)
~/Utils/OpenShift/crc-macos-1.14.0-amd64 % curl --version
curl 7.64.1 (x86_64-apple-darwin19.0) libcurl/7.64.1 (SecureTransport) LibreSSL/2.8.3 zlib/1.2.11 nghttp2/1.39.2
Release-Date: 2019-03-27
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtsp smb smbs smtp smtps telnet tftp
Features: AsynchDNS GSS-API HTTP2 HTTPS-proxy IPv6 Kerberos Largefile libz MultiSSL NTLM NTLM_WB SPNEGO SSL UnixSockets
~/Utils/OpenShift/crc-macos-1.14.0-amd64 % export PATH=$PATH:$(pwd)
~/Utils/OpenShift/crc-macos-1.14.0-amd64 % oc login -u developer -p developer https://api.crc.testing:6443 --loglevel=10
I0820 14:43:07.992077   42804 loader.go:375] Config loaded from file:  /Users/luca/.kube/config
I0820 14:43:07.995641   42804 round_trippers.go:423] curl -k -v -XHEAD  'https://api.crc.testing:6443/'
I0820 14:43:18.028882   42804 round_trippers.go:443] HEAD https://api.crc.testing:6443/  in 10032 milliseconds
I0820 14:43:18.028919   42804 round_trippers.go:449] Response Headers:
F0820 14:43:18.032890   42804 helpers.go:115] error: net/http: TLS handshake timeout
~/Utils/OpenShift/crc-macos-1.14.0-amd64 % curl -k -v -XHEAD  'https://api.crc.testing:6443/'
Warning: Setting custom HTTP method to HEAD with -X/--request may not work the
Warning: way you want. Consider using -I/--head instead.
*   Trying <IP_ADDRESS>...
* TCP_NODELAY set
* Connected to api.crc.testing (<IP_ADDRESS>) port 6443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/cert.pem
  CApath: none
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Request CERT (13):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Certificate (11):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
* ALPN, server accepted to use h2
* Server certificate:
*  subject: CN=api.crc.testing
*  start date: Aug 19 13:09:40 2020 GMT
*  expire date: Sep 18 13:09:41 2020 GMT
*  issuer: OU=openshift; CN=kube-apiserver-lb-signer
*  SSL certificate verify result: self signed certificate in certificate chain (19), continuing anyway.
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x7fd76b809000)
> HEAD / HTTP/2
> Host: api.crc.testing:6443
> User-Agent: curl/7.64.1
> Accept: */*
>
* Connection state changed (MAX_CONCURRENT_STREAMS == 2000)!
< HTTP/2 403
< audit-id: 3e93a1bf-201c-4f74-bcb5-dd0ffbeccd83
< cache-control: no-cache, private
< content-type: application/json
< x-content-type-options: nosniff
< x-kubernetes-pf-flowschema-uid: 57e81c82-2a88-4658-822f-41806736f6ff
< x-kubernetes-pf-prioritylevel-uid: 9d3b9d61-319a-4254-87e3-a746607c7e0e
< content-length: 234
< date: Thu, 20 Aug 2020 12:43:35 GMT
<
* transfer closed with 234 bytes remaining to read
* stopped the pause stream!
* Connection #0 to host api.crc.testing left intact
curl: (18) transfer closed with 234 bytes remaining to read
* Closing connection 0

~/Utils/OpenShift/crc-macos-1.14.0-amd64 % export PATH="/usr/local/opt/curl/bin:$PATH"
~/Utils/OpenShift/crc-macos-1.14.0-amd64 % curl --version
curl 7.72.0 (x86_64-apple-darwin19.5.0) libcurl/7.72.0 SecureTransport zlib/1.2.11
Release-Date: 2020-08-19
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtsp smb smbs smtp smtps telnet tftp
Features: AsynchDNS IPv6 Largefile libz NTLM NTLM_WB SSL UnixSockets
~/Utils/OpenShift/crc-macos-1.14.0-amd64 % oc login -u developer -p developer https://api.crc.testing:6443 --loglevel=10
I0820 14:44:05.549293   43002 loader.go:375] Config loaded from file:  /Users/luca/.kube/config
I0820 14:44:05.558081   43002 round_trippers.go:423] curl -k -v -XHEAD  'https://api.crc.testing:6443/'
I0820 14:44:15.591075   43002 round_trippers.go:443] HEAD https://api.crc.testing:6443/  in 10032 milliseconds
I0820 14:44:15.591127   43002 round_trippers.go:449] Response Headers:
F0820 14:44:15.593094   43002 helpers.go:115] error: net/http: TLS handshake timeout
~/Utils/OpenShift/crc-macos-1.14.0-amd64 % curl -k -v -XHEAD 'https://api.crc.testing:6443/'
Warning: Setting custom HTTP method to HEAD with -X/--request may not work the
Warning: way you want. Consider using -I/--head instead.
*   Trying <IP_ADDRESS>:6443...
* Connected to api.crc.testing (<IP_ADDRESS>) port 6443 (#0)
* ALPN, offering http/1.1
* WARNING: disabling hostname validation also disables SNI.
* TLS 1.2 connection using TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
* Server certificate: <IP_ADDRESS>
* Server certificate: kube-apiserver-service-network-signer
> HEAD / HTTP/1.1
> Host: api.crc.testing:6443
> User-Agent: curl/7.72.0
> Accept: */*
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 403 Forbidden
< Audit-Id: 8d3755ce-97ad-4ad0-8059-7289891aa691
< Cache-Control: no-cache, private
< Content-Type: application/json
< X-Content-Type-Options: nosniff
< X-Kubernetes-Pf-Flowschema-Uid: 57e81c82-2a88-4658-822f-41806736f6ff
< X-Kubernetes-Pf-Prioritylevel-Uid: 9d3b9d61-319a-4254-87e3-a746607c7e0e
< Date: Thu, 20 Aug 2020 12:44:22 GMT
< Content-Length: 234
<

^C

Unfortunately I have the same error:
~/Utils/OpenShift/crc-macos-1.14.0-amd64 % ~/Utils/OpenShift/oc/oc login -u developer -p developer https://api.crc.testing:6443 --loglevel=10
I0820 14:13:46.931012   39518 loader.go:375] Config loaded from file:  /Users/luca/.kube/config
I0820 14:13:46.933689   39518 round_trippers.go:423] curl -k -v -XHEAD  'https://api.crc.testing:6443/'
I0820 14:13:56.946061   39518 round_trippers.go:443] HEAD https://api.crc.testing:6443/  in 10012 milliseconds
I0820 14:13:56.946106   39518 round_trippers.go:449] Response Headers:
F0820 14:13:56.947515   39518 helpers.go:115] error: net/http: TLS handshake timeout

~/Utils/OpenShift/crc-macos-1.14.0-amd64 % ~/Utils/OpenShift/oc/oc version
Client Version: 4.5.7
Kubernetes Version: v1.18.3+012b3ec

I still think the problem is with the "curl -k -v -XHEAD 'https://api.crc.testing:6443/'" command... I want to try with a different version with it. I don't remember if I use the brew version or the macOS one. I will let you know.

I'm not sure the curl messages are related to the TLS handshake timeout error, the latter is likely to be an error from go TLS package. No idea what code is triggering this error though from your logs :(
One thing which comes to mind, but which could be unrelated: official oc builds are built without CGO_ENABLED, I don't know if your binaries built from brew are built with or without CGO_ENABLED. When building with CGO_ENABLED, /etc/resolver is used for name resolution, when building without CGO_ENABLED, /etc/resolver is not used, and only /etc/resolv.conf is used (+/etc/hosts). curl always uses /etc/resolver if I remember correctly.
Might be worth trying oc login https://<IP_ADDRESS>:6443 to see if this behaves better (but this may fail in totally different ways ;)

The behaviour is the same:
~/Utils/OpenShift/crc-macos-1.14.0-amd64 % oc login -u developer -p developer https://api.crc.testing:6443
error: net/http: TLS handshake timeout
~/Utils/OpenShift/crc-macos-1.14.0-amd64 % oc login -u developer -p developer https://<IP_ADDRESS>:6443
error: net/http: TLS handshake timeout

What does CRC need to work properly? That oc command uses the /etc/resolver or not?

That oc command uses the /etc/resolver or not?

Both should work

@savonarola27 does @cfergeau suggestion helped you or you still have same issue?

Unfortunately also removing the ~/.kube folder the issue persists.
What I have done:

remove the ~/.kube folder
start crc
eval $(crc oc-env)
login with oc command embedded in crc -> TLS handshake timeout
remove oc embedded command from $PATH
login with brew version of oc command -> LOGIN OK
NOTE: at this step the brew oc command create the ~./kube folder
again eval $(crc oc-env)
login with oc command embedded in crc -> TLS handshake timeout

Here the output for reference:
~/Utils/OpenShift/crc/crc-macos-1.14.0-amd64 % crc oc-env
export PATH="/Users/luca/.crc/bin/oc:$PATH"
# Run this command to configure your shell:
# eval $(crc oc-env)
~/Utils/OpenShift/crc/crc-macos-1.14.0-amd64 % eval $(crc oc-env)
~/Utils/OpenShift/crc/crc-macos-1.14.0-amd64 % oc login -u developer -p developer https://api.crc.testing:6443
error: net/http: TLS handshake timeout
~/Utils/OpenShift/crc/crc-macos-1.14.0-amd64 % echo $PATH
/Users/luca/.crc/bin/oc:/usr/local/sbin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/Applications/VMware Fusion.app/Contents/Public:/Users/luca/Utils/OpenShift/crc/crc-macos-1.14.0-amd64
~/Utils/OpenShift/crc/crc-macos-1.14.0-amd64 % export PATH="/usr/local/sbin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/Applications/VMware Fusion.app/Contents/Public:/Users/luca/Utils/OpenShift/crc/crc-macos-1.14.0-amd64"
~/Utils/OpenShift/crc/crc-macos-1.14.0-amd64 % which oc
/usr/local/bin/oc
~/Utils/OpenShift/crc/crc-macos-1.14.0-amd64 % oc login -u developer -p developer https://api.crc.testing:6443
The server uses a certificate signed by an unknown authority.
You can bypass the certificate check, but any data you send to the server could be intercepted by others.
Use insecure connections? (y/n): y

Login successful.

You don't have any projects. You can try to create a new project, by running

    oc new-project <projectname>

Welcome! See 'oc help' to get started.
~/Utils/OpenShift/crc/crc-macos-1.14.0-amd64 % eval $(crc oc-env)
~/Utils/OpenShift/crc/crc-macos-1.14.0-amd64 % which oc
/Users/luca/.crc/bin/oc/oc
~/Utils/OpenShift/crc/crc-macos-1.14.0-amd64 % oc login -u developer -p developer https://api.crc.testing:6443
error: net/http: TLS handshake timeout

I tried the new version (1.15) and the problem is no more present!

oc login works after crc start with the newer version? That's odd...

Yes but the problem is present also with "odo" command (latest version):
~/Utils/OpenShift/crc/crc-macos-1.15.0-amd64 % crc oc-env
export PATH="/Users/luca/.crc/bin/oc:$PATH"
# Run this command to configure your shell:
# eval $(crc oc-env)

~/Utils/OpenShift/crc/crc-macos-1.15.0-amd64 % eval $(crc oc-env)

~/Utils/OpenShift/crc/crc-macos-1.15.0-amd64 % oc login -u developer -p developer https://api.crc.testing:6443
Login successful.

You don't have any projects. You can try to create a new project, by running

    oc new-project <projectname>

~/Utils/OpenShift/crc/crc-macos-1.15.0-amd64 % which oc
/Users/luca/.crc/bin/oc/oc

~/Utils/OpenShift/crc/crc-macos-1.15.0-amd64 % oc api-resources
NAME                                  SHORTNAMES       APIGROUP                              NAMESPACED   KIND
bindings                                                                                true         Binding
componentstatuses                     cs                                                     false        ComponentStatus
configmaps                            cm                                                     true         ConfigMap
endpoints                             ep                                                     true         Endpoints
...

~/Utils/OpenShift/crc/crc-macos-1.15.0-amd64 % odo login -u developer -p developer
Connecting to the OpenShift cluster

 ✗  net/http: TLS handshake timeout

@savonarola27 Can you create the issue on odo side because odo is now not using oc under the hood but perform the actual login kind of same way which oc does.


Fix init command for default style - fixes #4722

The empty dependency string was tripping up package managers. Fixes #4722

@adrianhelvikspond we'll need to fix this in build-registry. okay for me to push the fix to this pr?

Absolutely 🙂


[chore] Add connecting to Strapi section to README

What does it do?
Adds a section describing how the design system can be connected to Strapi for testing in the CMS
Why is it needed?
Testing in isolation using Storybook is great but you might also want to test your work in the CMS
How to test it?
Make a change somewhere in the design system, then follow the steps to link the design system to your Strapi application. Verify the local version of the DS is being used.

More or less the same as https://github.com/joshuaellis/strapi-design-system#connecting-to-strapi

It wouldn't make this about the monorepo but more about how to link it in general, otherwise I'd prefer to move this into the contributor docs of the monorepo (because the DS is supposed to be independent from the monorepo). What do you think?

That's a good point. I think making it more general to Strapi is a good idea but not so general that people think they can (or should) use the DS in any React application. What if I adapted what I have here to have instructions for both the monorepo and Strapi applications/plugins?

Yeah I think that could work. If you split it up anyways I think I'd prefer to have the strapi specific part in the contributor docs and the general part in the DS.

Hey @gu-stav thanks for the approval, but I had worked on your feedback yesterday and did the contributor docs yesterday. Let me know what you think. This PR https://github.com/strapi/strapi/pull/15439 will need to be merged first and I guess we will have to wait for the release and website deploy since I link to it here.

@markkaylor Are you going to refactor this still (take out the Strapi specific part and link to the contributor docs instead + write more generalized docs)?

@gu-stav I did link to the contributor docs for the monorepo here and then left more general instructions for connecting to a Strapi application or plugin. I thought that was the idea but I guess I misunderstood your comment here. I can make it more general to any React application but I do feel the strapi-design-system is quite specific to Strapi

Hi @gu-stav have you had a chance to take another look? If the content looks good to you I was thinking the CONTRIBUTING.md might be a better place for this.


STORM-1202: Migrate APIs to org.apache.storm, but try to provide some form of backwards compatability

This is not a typical pull request, because changing the packages is a huge task, and keeping it upmerged while this is reviewed and other patches goes in is a huge task, and error prone.
Instead the actual changes to the package/namespace is done by running
./dev-tools/move_packages.sh ./
you can wipe all of the changes clean again (Including any modifications on your branch that you have not checked in) by running
./dev-tools/cleanup.sh ./
once the changes are approved/committed these two scripts should be removed.
The other code is intended to provide a single executable that can shade a user jar so instead of using backtype.storm and storm.trident it uses org.apache.storm and org.apache.storm.trident.
These are off by default by can be enabled by adding
client.jartransformer.class: "org.apache.storm.hack.StormShadeTransformer"

to storm.yaml.  I would expect all of the code related to this to be removed when we go to the 2.0 release.
I have tested this by running a 0.10.0-SNAPSHOT storm starter topologies against a cluster running this patch (along with the move_package.sh executed).

Because this is a non-backwards compatible change, and the mailing lists have discussed moving the version numbers over to 1.0.0-SNAPSHOT I am happy to make that change here too, but I wanted to hold off and get feedback from others before doing so.

I am a +1. I like this backward compatibility feature for smooth migration to package renaming. The changes look good to me. I ran some tests with topology jar compiled on 0.10.x and it works as expected.

The test failures appear to be unrelated.

Looks OK to me overall.
It would be nice to have a follow-on Jira Issue or Sub-Task to remove/revert the changes we need to bootstrap the testing for this (dev-tools, etc.).

I have tested this by running a 0.10.0-SNAPSHOT storm starter topologies against a cluster running this patch (along with the move_package.sh executed).

We found that with word_count, the .clj source file had been removed from the transformed jar, but we expected that this .clj would be present, but transformed.

OK I finally tracked down some intermittent failures I was seeing when running the clojure word count example.  It looks like there is an issue in clojure where how we are doing the require does not seem to be thread safe.
We should be good to go now if @d2r you want to take a final look.  The previous failure is not related and is one of the random storm-kafka failures.

I just filed http://dev.clojure.org/jira/browse/CLJ-1876 for the issue I was seeing with the require.

Downloaded 0.11 source & pulled in this branch
ran the move_packages.sh, build and unpacked the tarball
launched daemons from the unpacked 0.11+hack build
downloaded 0.10 release tarball and unpacked it separately
Used the 0.11+hack bin/storm to launch the 0.10 storm.starter.clj.word_count

-> Client failed because of missing StormSubmitter package (good/expected)

Did the same adding -c client.jartransformer.class=org.apache.storm.hack.StormShadeTransformer

-> topology submitted and ran OK
Checked the stormjar.jar in the supervisor's stormdist directory and looked at the word_count.clj source file inside it, and the source had been rewritten from backtype.storm.... to org.apache.storm...

The one suggestion is to add to Config what the hack implementation class is (the intended value of the config) for the use case.  Otherwise users might need to hunt around to find the class we provide.
Once that's added, +1

@d2r done I updated the comment in Config.


keydb-server v5.3.3 very slow

Same https://github.com/JohnSully/KeyDB/issues/130#issuecomment-574614789
# memtier_benchmark -s test-host -p6379 -P redis -c 30 -t 30 -n 1000 --ratio 1:2 --data-size-range=4-204 --data-size-pattern=S --key-minimum=200 --key-maximum=400 --hide-histogram -x 3
[RUN #1] Preparing benchmark client...
[RUN #1] Launching threads now...
^CUN #1 6%,  71 secs] 30 threads:       58259 ops,     899 (avg:     810) ops/sec, 80.58KB/sec (avg: 66.55KB/sec), 1133.03 (avg: 1104.90) msec latencyyy

USEASM=true or false - does not affect
If in config server-threads=1 - performance is normal (as redis):
AGGREGATED AVERAGE RESULTS (3 runs)
=========================================================================
Type         Ops/sec     Hits/sec   Misses/sec      Latency       KB/sec
-------------------------------------------------------------------------
Sets        23052.81          ---          ---     13.35467      3253.80
Gets        45967.58      1487.79     44479.79     13.32900      1817.44
Waits           0.00          ---          ---      0.00000          ---
Totals      69020.39      1487.79     44479.79     13.33733      5071.24

Hi @rnz
This is an extreme performance degradation which is very unusual.  A few questions:

What is the output of 'free' on your machine?
Using htop are all cores busy?

I have the same problem but only with the Active-Replica.
Worst run took 5365x longer than the average latency.
The standalone performs much better.
Worst run took 204x longer than the average latency.
The products in my web-shop load much faster with an standalone than with an Active-replica behind a HAproxy

Hi JohnSully

This is an extreme performance degradation which is very unusual. A few questions:

What is the output of 'free' on your machine?
Using htop are all cores busy?

this machine have next free and LA:
# free -m
              total        used        free      shared  buff/cache   available
Mem:        2052078      149123     1881819       15906       21135     1887161
Swap:             0           0           0
# uptime
 19:31:13 up 105 days,  2:30,  1 user,  load average: 10,50, 10,64, 12,18

lxc container which incapsulate keydb have next output of free:
# free -m
              total        used        free      shared  buff/cache   available
Mem:           4096         101        3750         240         243        3994
Swap:             0           0           0
# uptime
 17:04:14 up 11 days, 19:16,  1 user,  load average: 7,85, 10,55, 10,56

This machine have running multiple containers distributed over the cores(cpu core/threads 64/128), lxc container with keydb have id 358:
# pct cpusets
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
112:                                                                                68                                                                90                                                                                121                     127
115:                                                                                51                         60 61                                                 78                            88          92                                  103                     109
125:                                                                                44                                                    62                               73                   80    82                                                                                115                     121 122
131:                  8                                                                                89
145:  0                                                                                38
156:  0     3         8      11 12 13 14 15             20                                           35                41    43                                     56                                              72          76                                                                                117
172:                                                                                47                                                                                84
182:  0                                                                      27                                                                                65 66
204:                                                                               29                                           44                                                                                98            102
213:        3                                                 22          26                                           41
223:                                        16    18
257:          4                                                                                41 42 43 44       47 48    50 51    53 54       57 58                                                                               85                      93    95
261:                                                                                56 57
263:    1 2   4 5 6     9 10 11 12    14 15    17 18    20    22    24 25 26 27 28    30 31 32    34 35 36 37                                                             58                                        72 73 74 75
264:    1     4 5       9                                                                                38    40                                                                                74    76    78 79 80 81 82    84 85       88 89       92 93 94 95                 101 102 103     105 106 107     109 110 111 112 113         116     118 119                 124 125 126
268:                      10 11 12    14             19          23                29                                              45 46 47    49          53 54 55                                  67    69                      77    79          83                                              99     101         104 105                 110 111 112 113 114     116         119
270:                                                                                60 61
285:                                                                         27                                                                                62                68                                                                                118
296:                      10                   17    19                               30                                     43                                              59                                                                                104                                     114
303:              6 7                                                           28          32                                                                                90 91                   98                                                                                120
304:                                                                                36 37       40                46
307:                                                       21                                                    39       42                48          52                                                       71          75                                  87                         96 97       100                             108
310:                                                                                30             35                                        49                                           64
315:                                                       21                                                    39                                     52             57                63                      71          75                                  87                         96 97       100                             108
317:      2                                                   22                                                                                55                                                                                127
318:                                                                   25                                                 42                                                                64                                                                86
319:                                                                                63                                                                                96          100                             108
320:              6                                                                      31       34                                                                                94
321:    1 2 3   5 6 7 8            13    15 16 17 18 19 20 21    23 24          28 29             34    36 37 38 39 40             45 46       49 50 51 52       55          59          63    65 66 67    69 70    72          76 77          81    83       86 87          91       94       97 98 99         102     104     106 107                         114 115     117         120     122 123 124 125 126
322:                    9                                              25                      33                                                                   56                      64                70                                              86                                                                                117
329:                7              13       16                                                                                123
341:                                                             23    25                31 32 33                                  45                                                                                106                                                                     124
349:                                                                24                         33                                                                                109             113
358:            5       9                                                       28                                                                                83                                                                                118     120
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Typical stats on machine (one slice accumulated per process by atop):
PRC | sys   66m51s | user  41m01s  |              | #proc   4170 | #trun     15  | #tslpi  8392 |              | #tslpu     1  | #zombie    0 | clones 237e3 |               | #exit >66873 |
CPU | sys     343% | user    429%  | irq    1116% |              | idle  10864%  | wait     47% |              |               | steal     0% | guest     3% | avgf 1.37GHz  | avgscal  62% |
CPL | avg1   24.74 | avg5   15.33  |              | avg15  13.81 |               |              | csw 58222625 | intr 24958e4  |              |              | numcpu   128  |              |
MEM | tot     2.0T | free    1.8T  | cache  16.9G | dirty   0.5M | buff    6.7M  | slab   12.6G | slrec   3.6G | shmem  15.5G  | shrss   9.0M | vmbal   0.0M | hptot   0.0M  | hpuse   0.0M |
SWP | tot     0.0M | free    0.0M  |              |              |               |              |              |               |              |              | vmcom 159.8G  | vmlim   3.9T |
DSK |          sdc | busy     48%  | read   36078 |              | write 371984  | KiB/r      7 | KiB/w     28 | MBr/s    0.5  | MBw/s   17.4 |              | avq     1.62  | avio 0.69 ms |
DSK |          sdb | busy      0%  | read      15 |              | write   3405  | KiB/r      6 | KiB/w      4 | MBr/s    0.0  | MBw/s    0.0 |              | avq     1.78  | avio 0.15 ms |
DSK |          sda | busy      0%  | read       9 |              | write   3678  | KiB/r      7 | KiB/w      4 | MBr/s    0.0  | MBw/s    0.0 |              | avq     1.57  | avio 0.13 ms |
NFC | rpc      273 | read       0  | write      0 |              | retxmit    0  | autref   273 |              |               |              |              |               |              |
NET | transport    | tcpi  187624  | tcpo  219780 | udpi  132976 | udpo  118569  | tcpao    434 | tcppo  15914 | tcprs     10  | tcpie      0 | tcpor    118 | udpnp      0  | udpie      0 |
NET | network      | ipi   352149  | ipo   309548 |              | ipfrw      0  | deliv 327738 |              |               |              |              | icmpi    141  | icmpo      1 |
NET | tap224i  45% | pcki      99  | pcko 1856199 | sp   10 Mbps | si    0 Kbps  | so 4574 Kbps | coll       0 | mlti       0  | erri       0 | erro       0 | drpi       0  | drpo       0 |
NET | enp49s0   4% | pcki 15208e4  | pcko 75122e3 | sp   10 Gbps | si  472 Mbps  | so  238 Mbps | coll       0 | mlti   42877  | erri       0 | erro       0 | drpi       0  | drpo       0 |
Only 66873 exited processes handled -- 166576 skipped!
NPROCS        SYSCPU         USRCPU          VSIZE          RSIZE          PSIZE         SWAPSZ          RDDSK          WRDSK          RNET          SNET          CPU        CMD        1/46
   223         6m05s         14m35s          88.2G          12.5G           3.6G             0K          60.2G          1576K             0             0         211%        webapi
   234         3m12s         11m38s          96.9G          19.0G          14.2G             0K          25.3G           1.1G             0             0         151%        python3
    96        10m23s          0.00s             0K             0K             0K             0K             0K             0K             0             0         106%        z_wr_iss
     5        49.07s          7m02s           3.9G         323.3M         316.2M             0K             0K         67719K             0             0          80%        python
   419         1m51s          2m45s         195.1G          11.0G           1.9G             0K           2.2G         15862K             0             0          47%        php-fpm7.2
   682         3m17s         73.03s          83.9G           4.7G           1.0G             0K           2.7G          11.6G             0             0          46%        nginx
    96         4m05s          0.00s             0K             0K             0K             0K             0K             0K             0             0          42%        dp_sync_taskq
     1         2m57s          0.00s             0K             0K             0K             0K             0K             0K             0             0          30%        ksoftirqd/25
     1         2m53s          0.00s             0K             0K             0K             0K             0K             0K             0             0          29%        ksoftirqd/26
     1         2m44s          0.00s             0K             0K             0K             0K             0K             0K             0             0          28%        ksoftirqd/31
     1         2m37s          0.00s             0K             0K             0K             0K             0K             0K             0             0          27%        ksoftirqd/29
     1         2m26s          0.00s             0K             0K             0K             0K             0K             0K             0             0          25%        ksoftirqd/24
     1         2m15s          0.00s             0K             0K             0K             0K             0K             0K             0             0          23%        ksoftirqd/30
     1         2m11s          0.00s             0K             0K             0K             0K             0K             0K             0             0          22%        ksoftirqd/90
     1         2m01s          0.00s             0K             0K             0K             0K             0K             0K             0             0          20%        ksoftirqd/92
     1         1m51s          0.00s             0K             0K             0K             0K             0K             0K             0             0          19%        ksoftirqd/27
     1        84.92s          0.00s             0K             0K             0K             0K             0K             0K             0             0          14%        ksoftirqd/89
     1        65.32s          0.00s             0K             0K             0K             0K             0K             0K             0             0          11%        ksoftirqd/93
     1        33.90s         30.73s           9.0G           5.1G           5.1G             0K             0K          2464K             0             0          11%        kvm
     1        59.70s          0.00s             0K             0K             0K             0K             0K             0K             0             0          10%        ksoftirqd/88
     1        57.40s          0.00s             0K             0K             0K             0K             0K             0K             0             0          10%        ksoftirqd/94
  1445        35.56s         21.37s         497.0M         93616K         74898K             0K           5.1G             0K             0             0          10%        pvestatd
     1        47.95s          0.00s             0K             0K             0K             0K             0K             0K             0             0           8%        ksoftirqd/28
     1        46.28s          0.00s             0K             0K             0K             0K             0K             0K             0             0           8%        ksoftirqd/91
     1        41.92s          0.00s             0K             0K             0K             0K             0K             0K             0             0           7%        ksoftirqd/95
     2        31.49s          0.00s             0K             0K             0K             0K             0K             0K             0             0           5%        vhost-17783
   129         7.98s         21.91s         169.3G           9.5G           7.5G             0K            84K             0K             0             0           5%        node
    15         3.95s         25.87s         862.3M         244.5M         254.7M             0K          3331K         53505K             0             0           5%        gitlab-ci-mult
     5         2.98s         26.10s         439.9M         113.2M         104.0M             0K             0K         15411K             0             0           5%        supervisord
   737        22.21s          3.79s           2.9G         120.3M         34318K             0K          21.8G             0K             0             0           4%        zabbix_agentd
     1        10.05s         14.91s          56.1G           9.2G           9.2G             0K           448K           496K             0             0           4%        java
     1        23.48s          0.00s             0K             0K             0K             0K             8K             0K             0             0           4%        txg_sync
    28        13.09s          7.59s           3.2G           1.5G         926.5M             0K           156K             0K             0             0           4%        systemd-journa

This fix is targeted for 6.0-RC2.  I just published RC1 but it may not fully resolve this issue yet.

@rnz
I've been able to reproduce your issue but I have to oversubscribe my machine to do so.  In this scenario any of the first 3 numbers in 'cat /proc/loadavg' are > the the number of cores on my system.  In this scenario the more server threads the worse performance becomes.
LXC don't show full system load so its possible you may have to check on the host.  Additionally if CPU pinning is enabled (either in the container or with KeyDB's server-thread-affinity option) then this scenario may still occur even at lower averages when the kernel can't properly balance threads across cores.
Your machine has 64 cores so its quite surprising to see this which is leading me to believe possibly this is a core pinning issue.
Another possibility I'm looking at is a NUMA related issue, is your machine a dual socket one?  Is it a first gen EPYC?

New branch mcs_lock should help a bit in this scenario.  Unfortunately not the silver bullet I was hoping for but I'm seeing 20% perf improvements in some cases.
Still we need to migrate to a proper scalable lock regardless.

@rnz
Here's what I think the main issue is:
The output of pct cpusets
358:            5       9                                                       28                                                                                83                                                                                118     120
You have cores very far apart almost certainly on different NUMA nodes. You should pin your KeyDB container to contiguous cores on the same all NUMA node+socket.  The KeyDB spinlock will result in extremely high traffic across NUMA nodes resulting in terrible performance.  The mcs_lock branch will probably help quite a bit here (and I am curious if you have the time to try it).  But even then you'll be better off having everything together on the same node.
My recommendation is to pin your KeyDB container to contiguous cores that don't cross NUMA boundaries.

@JohnSully

Another possibility I'm looking at is a NUMA related issue, is your machine a dual socket one? Is it a first gen EPYC?
Yes our machine have dual socket with EPYC first gen:

# lscpu
Architecture:          x86_64
CPU op-mode(s):        32-bit, 64-bit
Byte Order:            Little Endian
CPU(s):                128
On-line CPU(s) list:   0-127
Thread(s) per core:    2
Core(s) per socket:    32
Socket(s):             2
NUMA node(s):          8
Vendor ID:             AuthenticAMD
CPU family:            23
Model:                 1
Model name:            AMD EPYC 7501 32-Core Processor
Stepping:              2
CPU MHz:               1156.293
CPU max MHz:           2000,0000
CPU min MHz:           1200,0000
BogoMIPS:              4000.20
Virtualization:        AMD-V
L1d cache:             32K
L1i cache:             64K
L2 cache:              512K
L3 cache:              8192K
NUMA node0 CPU(s):     0-7,64-71
NUMA node1 CPU(s):     8-15,72-79
NUMA node2 CPU(s):     16-23,80-87
NUMA node3 CPU(s):     24-31,88-95
NUMA node4 CPU(s):     32-39,96-103
NUMA node5 CPU(s):     40-47,104-111
NUMA node6 CPU(s):     48-55,112-119
NUMA node7 CPU(s):     56-63,120-127
Flags:                 fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good nopl nonstop_tsc cpuid extd_apicid amd_dcm aperfmperf pni pclmulqdq monitor ssse3 fma cx16 sse4_1 sse4_2 movbe popcnt aes xsave avx f16c rdrand lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw skinit wdt tce topoext perfctr_core perfctr_nb bpext perfctr_llc mwaitx cpb hw_pstate ssbd ibpb vmmcall fsgsbase bmi1 avx2 smep bmi2 rdseed adx smap clflushopt sha_ni xsaveopt xsavec xgetbv1 xsaves clzero irperf xsaveerptr arat npt lbrv svm_lock nrip_save tsc_scale vmcb_clean flushbyasid decodeassists pausefilter pfthreshold avic v_vmsave_vmload vgif overflow_recov succor smca

The mcs_lock branch will probably help quite a bit here (and I am curious if you have the time to try it). But even then you'll be better off having everything together on the same node.
I have time

I try mcs_lock branch - same result - slow. But I add to container 14 cores (summary 20 cores, before 6 cores) and performance (with server-threads=8 and server-thread-affinity=false) is restored:
# time memtier_benchmark -s test-host -p6379 -Predis -c 10 -t 100 -n 10000 --ratio 1:3 --data-size-range=4-512 --data-size-pattern=S --key-minimum=100 --key-maximum=300 --key-pattern=G:G --key-stddev=10 --key-median=200 --hide-histogram -x 1
[RUN #1] Preparing benchmark client...
[RUN #1] Launching threads now...
[RUN #1 100%,  95 secs]  0 threads:    10000000 ops,  385219 (avg:  104813) ops/sec, 108.13MB/sec (avg: 29.23MB/sec),  2.59 (avg:  9.54) msec latencyyy

100       Threads
10        Connections per thread
10000     Requests per client

ALL STATS
=========================================================================
Type         Ops/sec     Hits/sec   Misses/sec      Latency       KB/sec
-------------------------------------------------------------------------
Sets        26949.45          ---          ---      9.52400      7892.10
Gets        80848.34     79576.00      1272.35      9.54100     22896.72
Waits           0.00          ---          ---      0.00000          ---
Totals     107797.79     79576.00      1272.35      9.53600     30788.82

I add more cores (60):
# time memtier_benchmark -s test-host -p6379 -Predis -c 10 -t 100 -n 10000 --ratio 1:3 --data-size-range=4-512 --data-size-pattern=S --key-minimum=100 --key-maximum=300 --key-pattern=G:G --key-stddev=10 --key-median=200 --hide-histogram -x 1
[RUN #1] Preparing benchmark client...
[RUN #1] Launching threads now...
[RUN #1 100%,  55 secs]  0 threads:    10000000 ops,  249905 (avg:  181520) ops/sec, 70.31MB/sec (avg: 51.19MB/sec),  4.00 (avg:  5.50) msec latencyy

100       Threads
10        Connections per thread
10000     Requests per client

ALL STATS
=========================================================================
Type         Ops/sec     Hits/sec   Misses/sec      Latency       KB/sec
-------------------------------------------------------------------------
Sets        46943.47          ---          ---      5.52300     13747.32
Gets       140830.42    140285.88       544.54      5.49800     40481.25
Waits           0.00          ---          ---      0.00000          ---
Totals     187773.90    140285.88       544.54      5.50400     54228.57

real    0m58,634s
user    2m18,966s
sys     7m17,709s

Add 100 cores:
root@n01-test-memtier:~# time memtier_benchmark -s test-host -p6379 -Predis -c 10 -t 100 -n 10000 --ratio 1:3 --data-size-range=4-512 --data-size-pattern=S --key-minimum=100 --key-maximum=300 --key-pattern=G:G --key-stddev=10 --key-median=200 --hide-histogram -x 1
[RUN #1] Preparing benchmark client...
[RUN #1] Launching threads now...
[RUN #1 100%,  30 secs]  0 threads:    10000000 ops,  380500 (avg:  332537) ops/sec, 106.57MB/sec (avg: 93.78MB/sec),  2.63 (avg:  3.00) msec latency

100       Threads
10        Connections per thread
10000     Requests per client

ALL STATS
=========================================================================
Type         Ops/sec     Hits/sec   Misses/sec      Latency       KB/sec
-------------------------------------------------------------------------
Sets        87799.37          ---          ---      3.01000     25711.91
Gets       263398.12    262379.65      1018.47      3.00100     75712.93
Waits           0.00          ---          ---      0.00000          ---
Totals     351197.50    262379.65      1018.47      3.00300    101424.84

real    0m33,588s
user    2m5,727s
sys     6m46,574s

@rnz
The other recommendation is to leave at least 1 core free for the kernel to use for network IO, so if you have 8 cores assigned use 7 server threads.

Hi @rnz I think this issue is related to configuration and not KeyDB.  It's super important not to run KeyDB with more threads than cores.  To keep it on the same NUMA node, and its also optimal to ensure that there is an extra core or two available in the VM/container for kernel tasks as the kernel must still perform work to handle the network load.


PR - Fix debug arraylist and clean up code

Removed ChatUtils.java due to it being un-needed.
Fixed Debug ArrayList not updating on reload

Approved on @Timmy109's behalf


Add PivotChart to widgets, make widgets default view for any dataset

[ ] Add PivotChart to widgets.
PivotChart is much universal, it must be part of widgets

maybe widgets is worse than PivotChart but that's a different question

[ ] select table tab by default currently it selects none, and it's not clear for first-time users, wtf are these tiny icons ;]

[ ] store the selected tab in cell metadata, and reopen the same
[ ] if cell only creates vars but return is Unit, do not display the last val created: val someDf = ...
spark RDDs/DataFrames are suposed to be lazy
[ ] make widgets default view for any dataset. as a consequence, later, widgets (or their better future replacement) could be the default view for displaying any dataset (instead of a table now), so then users may switch between different views WITHOUT rerunning spark tasks! :sunny:

@andypetrella

:+1:  !!!


Add website to readme

right now, people who find us through the github page (I mentioned Sia in a reddit comment earlier today) don't have any way to find the website and download the binaries.

The website is given in the repo description.


List.last should have a setter, too

Iterable.last is read-only: makes sense.
List.last is read-only, too :( does not make sense as Iterable vs List is unmodifiable vs modifiable interface-wise.
Please add a setter. It's sad to have to use weird workarounds to set the last element in a List.

Adding something to the List interface at this point will mean that all existing list implementations are now incomplete. List is an interface that is often implemented by libraries, so there is a high bar for allowing changes.
That said, I completely agree that it should be there (and first= too).
See: https://codereview.chromium.org/315173005/

This happened! Thanks @lrhn!


Add elapsed time information to running load test dashboard

I thought it might be useful to see the elapsed time information in the current load test dashboard.
Screenshot attached

A useful feature indeed! But the current/old UI is being replaced. Can you implement it for the new one instead? https://docs.locust.io/en/stable/developing-locust.html?highlight=Modern#making-changes-to-locust-s-modern-web-ui

Sure, I'll try...

I'm closing this, as the old UI is being retired, we're not taking in new changes for it. But a similar change for the new one would be great!


IProvider.GetExtent() to MRect

This also fixes a bug in forms where lat and lon order was wrong. This bug was introduced weeks ago.


Can not provide the kubeconfig file when creating an import cluster

Rancher versions:
rancher/server 04/02
Steps to Reproduce:

Click "Add Cluster"
Choose "Import" and click "Create"
It jumps to the following page and I can't provide the kubeconfig file for the import cluster.

Importing a config was intentionally removed.  Common sources of configs like minikube and gke are not usable on their own because they refer to external files or executables.

Do we still support import an existing cluster?  How can I import an existing cluster?

@zionwu it looks like you're having some weird issue with import UI screen. I am able to see the kubectl apply commands

Yes, it is working on rancher/server:master 04/03


XBUTTON1 and XBUTTON2 to switch between scripts

XBUTTON1 and XBUTTON2 can be used in the script editor, method overview item list and scripts list.

See also https://github.com/godotengine/godot/pull/36910 which implements the same feature, but makes it optional to prevent interfering with VoIP programs if desired by the user.

I didn't see that. Whichever is best then.

Superseded by #36910. Thanks for the contribution nevertheless!


Gitea looks up a public key with id X in the database, while authorized_keys contains key-Y

Gitea version (or commit ref): 1.11.4 arm-6
Git version: 2.20.1
Operating system: Raspbian GNU/Linux 10 (buster)
Database (use [x]):

[ ] PostgreSQL
[x] MySQL
[ ] MSSQL
[ ] SQLite

Can you reproduce the bug at https://try.gitea.io:

[ ] Yes (provide example URL)
[ ] No
[x] Not relevant

Log gist: I couldn't get the log to to show anything useful w.r.t. the issue

Description
My authorized_keys file contains:
# gitea public key
command="/usr/local/bin/gitea --config='/etc/gitea/app.ini' serv key-4",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty ...

And the database table public_key has a single record with id 4.
However, when I attempt to do a git push over SSH, I get this error, caused by this error:

Unauthorized
Cannot find key: 1

After updating the database record's id to 1, the git push works, even though the authorized_keys file still contains key-4.
So it seems that, somewhere between parsing the key-4 argument, and doing the lookup in the database, the 4 gets converted into 1.
Screenshots
n/a

Either that's not the authorized_keys file Gitea is actually using or for some reason (e.g. restore from backup) the file became out of sync with regards to the database. There's a "sync authorized keys" command in the site admin menu you can use to make sure they're in sync.

It's neither of these, unfortunately. As explained, the authorized_keys file and the database were in sync, both had id 4, but it didn't work. Only after manually changing the id of the database record to 1, did it work again.
So after your response, here's what I did:

ran the script "Update the '.ssh/authorized_keys' file with Gitea SSH keys. (Not needed for the built-in SSH server.)". Now both the file and database had id 1 again
removed, and readded the SSH key. Now both the file and database had id 5. This is the same situation as I had initially with id 4, and SSH is broken at this point because Gitea still looks up id 1
changed the database record manually again to id 1, leaving the file untouched at id 5. Now SSH works again

If it's not specific to my Gitea instance, this should be easy to reproduce: add an SSH key, remove it, and add the same SSH key again. At this point, both the authorized_keys file and the database should have the same id, which should be a value > 1, but SSH should be broken.

This still sounds like a configuration problem. Is it possible that the gitea process that is running is not the same process that runs when ssh is invoked?

Sorry, I meant is it the same executable file.

With sudo find / -type f -executable -name '*gitea*', there's a single result (ignoring the hooks): /usr/local/bin/gitea
Doing ps -F -p $(pgrep gitea), the result is:

UID        PID  PPID  C    SZ   RSS PSR STIME TTY          TIME CMD
git        447     1  2<PHONE_NUMBER>4  3 May01 ?        01:37:38 /usr/local/bin/gitea web --config /etc/gitea/app.ini

So there's a single executable file, and there's a single process that has been running since May 1.
Would you mind trying to reproduce? As far as I know, there's nothing particular about my installation, so I believe it should be doable.

I've just tried this on master, release/v1.11 and v1.11.4 and cannot reproduce.

There is something odd about your authorized_keys I suspect. Are you sure that Gitea is writing to the correct authorized_keys file and that you're sshing to the correct user?

My bad, I found the problem... I'm using an SSH certificate which contains the command to use. So the authorized_keys file isn't used at all & gitea receives key-1 because that's what's in the certificate.
My apologies for the inconvenience.


Failed cause connection unstable

Hi sir, i wanna ask, can the script paused when my connection is failed?

Hi! You can regenerate another JSON by completing steps 2-4 in order to create a new list of users to unfollow.


Roll engine ff1bcdc00941..53620352ad4b (16 commits)

https://github.com/flutter/engine/compare/ff1bcdc00941...53620352ad4b
git log ff1bcdc00941188ba27123a4857b443e3c9392bb..53620352ad4b6e4460f2240730a5417743cc524d --no-merges --oneline
53620352a Roll src/third_party/dart aacc0b0709..b23817105c (8 commits)
046b3cd28 Get rid of the macro for accessing the current test name. (flutter/engine#8500)
533ca016e Roll src/third_party/skia 6b797fec83f0..2f08a4043b26 (8 commits) (flutter/engine#8501)
612abee90 Wire up support for Dart fixtures in shell_unittests. (flutter/engine#8497)
dbcfc504c Android Embedding PR26: Offer an async version of FlutterMain's ensure initialization complete. (flutter/engine#8465)
a930ca893 Roll src/third_party/dart 8e4dcf48c4..aacc0b0709 (4 commits)
acfc83179 Roll src/third_party/skia 602df41025ea..6b797fec83f0 (19 commits) (flutter/engine#8494)
3558fa65a [Docs] Correcting link to contributing guide. (flutter/engine#8472)
0bf708ee1 Refactor ios play input sound logic. (flutter/engine#7783)
78bd318c9 Add Locale.toLanguageTag() (flutter/engine#8421)
efb3b003f Roll src/third_party/dart 8e0a669e74..8e4dcf48c4 (8 commits)
075b4899d Support ContextWrapper when FlutterView is instantiated within a Fragment. (flutter/engine#7776)
85ca8c485 Roll src/third_party/skia 053b2939938c..602df41025ea (21 commits) (flutter/engine#8492)
a6b8e70ad Remove unused variable (flutter/engine#8490)
377dc6400 Roll src/third_party/dart 86b5304ccd..8e0a669e74 (6 commits)
7ee3a31c5 Roll src/third_party/dart 907c514c89..86b5304ccd (27 commits)
The AutoRoll server is located here: https://autoroll.skia.org/r/flutter-engine-flutter-autoroll
Documentation for the AutoRoller is here:
https://skia.googlesource.com/buildbot/+/master/autoroll/README.md
If the roll is causing failures, please contact the current sheriff (jsimmons@google.com), and stop
the roller if necessary.

Trybots failed. These were the failed builds: https://cirrus-ci.com/task/5694352809525248

Commit queue failed; closing this roll.


onEnterRules not considered when determining new line indentation

Hitting enter adds extra whitespace when onEnterRule reduces indent on previous blank line.  For example, with typescript and PHP, this happens after single line if statements and after JSDoc/PHPDoc.

Does this issue occur when all extensions are disabled?: Yes

VS Code Version: 1.62.0
OS Version: macOS Big Sur

Steps to Reproduce A:

Use the following type script rule.
Place mouse on line 3.
Hit Enter.  Line 4 will start with a tab.

If you hit enter on
if (1)
	console.log('test');

Steps to Reproduce B:

Use the following type script rule.
Place mouse on line 4.
Hit Enter.  Line 5 will start with a single space.

/**
 * JSDoc
 */

This feature request is now a candidate for our backlog. The community has 60 days to upvote the issue. If it receives 20 upvotes we will move it to our backlog. If not, we will close it. To learn more about how we handle feature requests, please see our documentation.
Happy Coding!

The indentation rules have highest priority when calculating auto indent, and those regex based indentation rules are not great as they don't know anything about context. You might find it work better when changing the auto indent setting to "editor.autoIndent": "advanced", which will skip the indentation rules but only check brackets and onEnterRules.

Thanks for commenting, @rebornix. That does prevent the excess tab from being added. Unfortunately, it also prevents the indentation rules, which are also useful. For example, in PHP, the rules cause it to indent after if (true):, else:, etc.
https://github.com/microsoft/vscode/blob/09c0b1f799d75edf284bc89c824bdd724c5b0fa7/extensions/php/language-configuration.json#L27-L30
I get why setting it to advanced helps in my example because it trigger this code:
https://github.com/microsoft/vscode/blob/09c0b1f799d75edf284bc89c824bdd724c5b0fa7/src/vs/editor/common/languages/autoIndent.ts#L80-L82
However, I was struggling with why the full mode would add the tab. I think I see it now. It assumes you want to keep the indent of the last non-blank line. That seems sensible.  I see it also has the following code to try to increase or decrease the indent:
https://github.com/microsoft/vscode/blob/09c0b1f799d75edf284bc89c824bdd724c5b0fa7/src/vs/editor/common/languages/autoIndent.ts#L119-L131
It seems like the issue here that I think you're eluding to is that decreaseIndentPattern cannot be defined to deindent after if (1)\ncode; because it only sees one line.


New version: TinyCraft.TinyRDM version 1.1.13

Created by 🥟 Dumplings in workflow run #5336.
Logs
Updated: 1.1.12 → 1.1.13
Submitting WinGet manifests

Microsoft Reviewers: Open in CodeFlow

@wingetbot run