Update storage-quickstart-blobs-nodejs.md

complete npm install command to include @azure/storage-blob package

@JKornberg : Thanks for your contribution! The author(s) have been notified to review your proposed change.

#label:"aq-pr-triaged"

Hi @JKornberg I know this is from some time back, but I'd love your help with this. If the package is already listed in the dependencies of the pacakge.json file, why refer to it specifically in the install command? Thx!

Hi @JKornberg I know this is from some time back, but I'd love your help with this. If the package is already listed in the dependencies of the pacakge.json file, why refer to it specifically in the install command? Thx!

To be honest, I have no memory of making this change or why I made this change.


Enhancement - Allow vehicles with more than 4 parts

This enhancement is useful for trains and trams, but maybe it needs a new DAT format.
When you create a custom DAT file with your own train, you are limited to 4 wagons. For example, if you try to create a DAT file for a Velaro (8 coaches), you need two DAT files, one for the first 4 coaches and the second for the other 4 coaches. A TGV Atlatique is even worse, you need 3 DAT files.
This is a problem when the maximum number of vehicles is 220 (including ships, planes, and road vehicles) and you cannot use livery selection option (like OpenTTD), only change the Company colors.
The biggest problem is that I believe that DAT files are limited to 4 parts.

AFAIC, the .DAT format supports 4 different types of coaches. That's how it functions in RCT2 as well.
Taking the APT as an example: it has 3 coach types: front/back, middle power car, and regular passenger coach.

Thanks, I know that it was difficult.

I find it hard to believe that a Velaro would have eight different coaches. 8 coaches, yes, but not eight different ones. Taking the APT as an example again, you can build an 8-coach train, which consists of 3 different coaches.

A Velaro could have a different number of coaches depending on level of detail that you want, but I think that it could have six or seven coaches:

Front (white lights)
Rear (red lights)
Second coach (with pantograph down)
Second coach from end (with pantograph up)
Third coach from end (with protuberance on roof for )
Third coach from end (common with previous coach, with the reversed flag on)
Middle coaches with plain roof (but it could have a bar, with different windows)

But if the current DAT format allows to define vehicles with more than four parts (with a maximum of four different parts), a lot of trains could be added in two vehicles. My biggest problem is that I don't know the limits of the DAT files when I made a new train.

The limit is 4 vehicle body's per dat.

Ok, 4 different vehicles OR 4 vehicles / DAT.
Maybe in the future this could be raised, but I suppose that the priority is create a game with it's own code. Meanwhile, I can try to provide a useful set of free license DAT files.


prevent Iterable recursion in effect data types

closing in favour of https://github.com/Effect-TS/effect/pull/2625


Data Science with Python : Numpy Cheatsheet

Welcome to 'DSWP' Team, good to see you here
This issue will helps readers in gaining all the guidance that one needs to know about An Introduction to Numpy Cheatsheet. Tutorial to An Introduction to Numpy Cheatsheet and how it's applied using code snippets.
To get assigned to this issue, add your serial numbers mentioned in the spreadsheet of "Data Science with Python", the approach one would follow and choice you prefer (Documentation, Audio, Video). You can go with all three or any number of options you're interested to work on.
If you had referred any resources, add them up in "DS Resources". Similarly if you had used datasets, include them in "DS Datasets".
Domain : Machine Learning
Mentors Assigned : Gauri Bharadwaj / Shivang Dubey
Points to Note :
The issues will be assigned on a first come first serve basis, 1 Issue == 1 PR.
"Issue Title" and "PR Title should be the same. Include issue number along with it.
Changes should be made inside the Datascience_With_Python/ directory & Datascience_With_Python branch.
Follow Contributing Guidelines & Code of Conduct before start Contributing.
This issue is only for 'GWOC' contributors of 'DSWP' domain.
All the best. Enjoy your open source journey ahead. 😎

I would Like to work on this issue @prathimacode-hub
Name: Sakalya
Serial Number: 62 Batch2
Type: Documentation
Approach:

Explanation of what is Numpy module in Python
Explaining its uses and importance
Exploring the functions in Numpy with implementation in Python

Issue assigned to @Sakalya100 for documentation

hello, I am S.Harihara Sudhan. I would like to do documentation on this issue. My approach would be how the numpy is used for different aspects including array manipulation, data types, sorting arrays and different array methods with a code snippet for each.

Documentation is already taken. @hariharas-wq

hello, i am anam hayat. could i take the audio on this issue?
batch 21

An update on my end. I am having my exams. So it is a bit delayed. Apologies. I will make the PR as soon as possible. Hope that is fine @prathimacode-hub


[Bug] rocksdbcq batch dispatch should be removed

Before Creating the Bug Report

[X] I found a bug, not just asking a question, which should be created in GitHub Discussions.

[X] I have searched the GitHub Issues and GitHub Discussions  of this repository and believe that this is not a duplicate.

[X] I have confirmed that this bug belongs to the current repository, not other repositories of RocketMQ.

Runtime platform environment
all
RocketMQ version
all
JDK Version
all
Describe the Bug
RocksDBConsumeQueueStore 中在处理dispatchRequest时候会有一个攒批的动作，这里的初衷是为了提高效率，但是实际上并不会起到什么作用，因为rocksdb首先写入的memtable，这是纯内存操作，不会有多少性能损耗。而且这里还有导致一个bug，就是消息比较少的情况，攒批可能会比较久，这样会导致消息消费延迟，严重的话会导致最后15条消息一直消费不到。
In RocksDBConsumeQueueStore, there is a batching action when handling dispatchRequest. The original intention here is to improve efficiency, but in reality, it doesn't have much effect because RocksDB first writes to the memtable, which is a pure memory operation and doesn't incur much performance overhead. Additionally, this can lead to a bug where, in cases of fewer messages, batching might take a long time, resulting in message consumption delays. In severe cases, the last 15 messages might never be consumed.
Steps to Reproduce
对于攒批我们一般的处理方式是设置超时时间，当时间超过最大超市时间则强制刷新，但是putMessagePositionInfoWrapper没有专门的线程去定时刷新，而是由dispatchRequest触发的，当没有消息的时候，设置超时时间也没有用，所以我们在这里应该直接将这个batch去掉
For batching, our usual approach is to set a timeout, forcing a flush when the time exceeds the maximum timeout. However, putMessagePositionInfoWrapper does not have a dedicated thread for periodic flushing; instead, it is triggered by dispatchRequest. When there are no messages, setting a timeout is ineffective. Therefore, we should remove the batch directly in this case.
What Did You Expect to See?
nothing
What Did You See Instead?
nothing
Additional Context
nothing

我发现不存在该问题，因为doReput中最终会调用finishCommitLogDispatch方法


Fluidity connectors

[ ] P1 connector (iTokens)
[ ] P3 connector (Uniswap borrowings)

Will add more details here

P1 connector
Contract to interact with - here
Functions:-

supply - for this
withdraw - for this
withdrawItoken - for this
claimRewards - for this

P3 connector
Contract to interact with - here
Functions:-

supplyNft - transfer the NFT to P3 address using safeTransferFrom function of this contract. P3 address - here
withdrawNft - for this
transferPosition - for this
addLiquidity - for this
removeLiquidity - for this
borrow - for this
payback - for this
collectFees - for this
depositNftToStaker - for this
withdrawNftFromStaker - for this
stake - for this
unstake for this
claimStakingRewards - for this
claimBorrowingRewards - for this
claimBorrowingRewards - for this
liquidate0 - for this
liquidate1 - for this


New screenshot that removes AppOptics

Related to #25. A new project screenshot is needed that:

Removes AppOptics mention
Includes mention of other service meshes than Istio.

With the new build available, time to grab a new one.


OpenSora training/inference with FiT-Like pipeline

What does this PR do?

Fixes # (issue)
Adds # (feature)
Before submitting

[ ] This PR fixes a typo or improves the docs (you can dismiss the other checks if that's the case).
[ ] Did you read the contributor guideline?
[ ] Did you make sure to update the documentation with your changes? E.g. record bug fixes or new features in What's New. Here are the
documentation guidelines
[ ] Did you build and run the code without any errors?
[ ] Did you report the running environment (NPU type/MS version) and performance in the doc? (better record it for data loading, model inference, or training tasks)
[ ] Did you write any new necessary tests?

Who can review?
Anyone in the community is free to review the PR once the tests have passed. Feel free to tag
members/contributors who may be interested in your PR.
@xxx

pls rebase on the latest code and supplement the training results and performance.

done


[WIP] Modular functional approach to createComponent()

The following general benefits of this approach should be considered:

Component's element is always the top-level one in the rendered components tree (not wrapped by other components, such as FelaTheme and Fela<...> responsible for applying styles)

thus, it seems that there is no need in the following wrapped props definitions anymore:

  UIComponent.wrappedComponent = `${Component.displayName || Component.name || 'Anonymous'}`
  UIComponent.wrappedComponentPropTypes = Component.propTypes
  UIComponent.wrappedComponentDefaultProps = Component.defaultProps
  UIComponent.wrappedComponentAutoControlledProps = Component.autoControlledProps

number of components in the rendered tree is minimal possible (lesser than we have now with current createElement implementation, the same as we would have with base class)
props are not "polluted" with the styling members, such as ''styles" and "variables" - it is up to client code how to consume them
all the logic is provided in dedicated isolated functions, as well as are separated static and instance-related aspects of this general functionality

I think the intent here is correct and we should explore it moving forward.  I'll continue updating the components we have now to use the base component pattern first.  Afterward, I think we can explore different APIs to expose to users for creating components.

I do think the number of function calls and API surface area need to be reduced for the user.

agree - but still, with this approach, essentially, we are still exposing just single function to the client. At the same time we would be able to overcome those problems of existing createElement function that are mentioned above.
Speaking of base component pattern - the only thing that I am really worrying about is that all the concepts will be coupled within this single implementation, something that we should keep an eye on.
With that being said, agree to proceed with base component pattern - this was just an attempt to provide additional point of view on this problem.

Agree with your sentiments and doubts.  We'll keep this functional idea in the back of our heads and we try the base component pattern.


Bug: Doppler env vars get exported along with secrets

Is there an existing issue for this?

[X] I have searched the existing issues

Orb version
1.3.0
Current behavior
When the load_secrets command is invoked the following doppler command gets executed:
doppler secrets download --no-file --format env > dopplerenv
Source: https://github.com/ft-circleci-orbs/doppler-circleci-orb/blob/a156fa0809694c0d7ee0dba40224aef960a9f02a/src/scripts/load_secrets_to_env.sh#L3C1-L3C41
The output of which might be something like this:
DOPPLER_CONFIG="dev_rob"
DOPPLER_ENVIRONMENT="dev"
DOPPLER_PROJECT="isolated-dev-env-examples"
SUPER_SECRET="Hi, Rob"

Notice the DOPPLER prefixed env vars. These aren't project secrets, but metadata about the Doppler project, environment and config. These then get converted into export statements and written to $BASH_ENV to make them available.
The problem with this is that the presence of these env vars impacts any future calls to load_secrets. For example, if you need to pull secrets from 2 different projects or configs within the same CircleCI job an error will result.
See this thread from Kiya:
https://financialtimes.slack.com/archives/C02ST9MNV0S/p1698242227874879
Minimum reproduction config
Invoke load_secrets more than once in the same job using different tokens:
  steps:
    - checkout
    - doppler-circleci/install
    - doppler-circleci/load_secrets:
         doppler_token: DOPPLER_TOKEN_SHARED
    - doppler-circleci/load_secrets:
         doppler_token: DOPPLER_TOKEN_TEST

Other
I suspect the fix is to remove the DOPPLER_* variables before we write to $BASH_ENV e.g.
doppler secrets download --no-file --format env | grep -v 'DOPPLER_CONFIG|DOPPLER_PROJECT|DOPPLER_ENVIRONMENT' > dopplerenv
We should also delete the dopplerenv file after exporting to $BASH_ENV, so it's not on the file system and therefore cannot be cached inadvertently.

Fixed in - https://github.com/ft-circleci-orbs/doppler-circleci-orb/pull/10
Update to v1.4 to allow loading secrets from multiple Doppler configs


Add startTimeout configuration value on startOptions

It is required to customize the timeout for Arweave app

Can we keep the default to be much lower?
this will have an impact on all the other apps.. and will make CI and development painful.. beyond this specific case


@mockType can not work well.

I tried to use mockType feature but it won't work well when using @mockType. I found out it should be !mockType instead after I looked into the code base. The fast way to verify this error is to run the following typescript definition on https://google.github.io/intermock/.
But I also found one existing feature PR11 to support @mockType. Maybe because you guys have not republish to npm lol.
the error one
interface Host {
  /** @mockType {internet.ipv6} */
  addr: string;
}

the right one
interface Host {
  /** !mockType {internet.ipv6} */
  addr: string;
}

FWIW - I can confirm from testing today that the jsdoc format (using @) works when building the library from source.

Sorry I'll update library on NPM as soon as I can.

Ok it's been updated https://www.npmjs.com/package/intermock

@ryanmcdermott thanks man.


Allow fixed source data to start from 0 row.

Some sources does not have header lines (brfss for example), but fixed source requires it. Change fixed source to allow souces without header lines.

Done.


retain state of howfairis results for every URL

table with urls as rows, compliance string '11001'
_report = [
  {
    url: https:something somethin
    retrieved_on: datetimeutc
    compliance: as a string
  }
]

Results is printed to terminal and part of report.


does Typezor supports minimal api's, getting the routeUrl for minimal api's?

You cannot use it to URL route for minimal API because it supports only static C# code analysis. You can try to use Swagger for minimal APIs to generate code


[Doc] add up starrocks_audit_tbl__ stmt from string to VARCHAR(1048576) aft…

…er version 2.1 because string default length is 65533, it will cause stmt truncated if sql stmt's length exceed 65533
Fixes #issue
What type of PR is this:

[ ] BugFix
[ ] Feature
[ ] Enhancement
[ ] Refactor
[ ] UT
[x] Doc
[ ] Tool

Checklist:

[ ] I have added test cases for my bug fix or my new feature
[ ] This pr will affect users' behaviors
[ ] This pr needs user documentation (for new or modified features or behaviors)

[ ] I have added documentation for my new feature or new function

Bugfix cherry-pick branch check:

[ ] I have checked the version labels which the pr will be auto-backported to the target branch

[ ] 3.1
[ ] 3.0
[ ] 2.5
[ ] 2.4

Hi @hellolilyliuyi @amber-create, PTAL.

Thank you for your contribution. This change has been integrated in https://github.com/StarRocks/starrocks/pull/41655. Closing the PR.


[EUWE] Chargebacks for SCVMM (rollup-less) [2/2]

Continuation of #13419. However, much smaller. Most of the changes here go to specs.
This fixes issues we had in handling time during chargeback calculations.
This is equivalent of backporting the following prs and resolving conflicts.
https://github.com/ManageIQ/manageiq/pull/12807
https://github.com/ManageIQ/manageiq/pull/13144
https://github.com/ManageIQ/manageiq/pull/13134
https://github.com/ManageIQ/manageiq/pull/13373
https://github.com/ManageIQ/manageiq/pull/13451
@miq-bot add_label chargebacks,

@miq-bot assign @simaishi
/cc @lpichler @gtanzillo


Typo fix

Fix citation to Bahdanau et al. in sequence to sequence documentation

Can one of the admins verify this patch?


Fix to overlapped header in version 0.3.1.

This is from the latest version 0.3.1.
It works fine in Storybook and in a react-native project this is what it looks like.

This is caused by an extra View under the TouchableOpacity in CalendarHeader.tsx.

Nice. Thanks!

published in v0.3.2


Refactor step to conform to ideal step architecture

Checklist

[x] I've read and followed the Contribution Guidelines
[ ] step.yml and README.md is updated with the changes (if needed)

Version

Requires a PATCH version update
Context

Refactored to ideal step architecture conforming to the 4 basic functions for execution: process config, install dependencies, run, and export outputs (nothing to export for this step so it's skipped)
Changes

This is an initial PR to conform to 4 basic functions of step execution. A later PR will be opened to move functions to their own step package.
Investigation details

Decisions

Just a general observation before digging deeper into the actual changes: it would make sense to split up the single main.go file into smaller pieces, such as config.go, dependencies.go.


New Blog: "AI Chatbot Competition -- Metaverse启动机之重构现世！"

title: "AI Chatbot Competition -- Metaverse启动机之重构现世！"
author: valerieeeee
categories: article
tags:

baidu
ai
news
featured
chatbot
competition

Thank you very much for publishing the newest Wechaty + Paddle ML Chatbot competition announcement!


bpf: migrate tail call maps to avoid altering currently loaded ones

See commit msgs.
Fixes: #13015
When this is merged, we can consider backporting also #14044 to v1.8.

test-me-please

I just noticed this still needs to move the cilium_policy deletion to after the base data path has been loaded.

test-me-please

test-me-please

test-me-please

test-me-please

test-me-please

retest-4.19

What is missing in this PR?

What is missing in this PR?

@brb We need to fix the failing tests.

@brb We need to fix the failing tests.

test-me-please

test-me-please

The tests are locally failing with many missed tail call drops. I'm taking a look.

OK, I have an explanation why we see Missed tail call drops in this PR.
When we load bpf_host on a native device (e.g. eth0) for the first time, the following is executed by the cilium-agent:
$ cilium-map-migrate -s 42/bpf_netdev_eth0.o
$ tc filter replace dev eth0 ingress prio 1 handle 1 bpf da obj 42/bpf_netdev_eth0.o sec from-netdev
$ cilium-map-migrate -e 42/bpf_netdev_eth0.o -r 0

$ cilium-map-migrate -s 42/bpf_netdev_eth0.o
# renames /sys/fs/bpf/tc/globals/cilium_calls_netdev_00666{,:pending} <-- it's being used by bpf_netdev_eth0[from-netdev]@eth0[ingress]
$ tc filter replace dev eth0 egress prio 1 handle 1 bpf da obj 42/bpf_netdev_eth0.o sec to-netdev
# creates /sys/fs/bpf/tc/globals/cilium_calls_netdev_00666 <-- it's being used by bpf_netdev_eth0[to-netdev]@eth0[egress]
$ cilium-map-migrate -e 42/bpf_netdev_eth0.o -r 0
# deletes /sys/fs/bpf/tc/globals/cilium_calls_netdev_00666:pending (used by bpf_netdev_eth0[from-netdev])

Because BPF maps of the BPF_MAP_TYPE_PROG_ARRAY type are removed immediately once they are unpinned (regardless of the refcount), we get the missed tail calls on the ingress of eth0.
The same problem should arise with bpf_lxc.

Tentatively closing this as there's now a proposal at https://github.com/cilium/cilium/pull/17744, and the code in this PR no longer exists in the tree.


helm render with --repo fails to find Chart.yaml with a values file in subdirectory with the same name as the chart

Output of helm version: version.BuildInfo{Version:"v3.5.4", GitCommit:"1b5edb69df3d3a08df77c9902dc17af864ff05d1", GitTreeState:"clean", GoVersion:"go1.15.11"}
Output of kubectl version: Server Version: version.Info{Major:"1", Minor:"18+", GitVersion:"v1.18.9-eks-d1db3c", GitCommit:"d1db3c46e55f95d6a7d3e5578689371318f95ff9", GitTreeState:"clean", BuildDate:"2020-10-20T22:18:07Z", GoVersion:"go1.13.15", Compiler:"gc", Platform:"linux/amd64"}
Cloud Provider/Platform (AKS, GKE, Minikube etc.): EKS
Y'all, this is a really bizarre one.
helm render fails when you use --repo, and provide a values file that is in a subdirectory with the same name as the chart name (not release name), that is exactly one layer deeper than the current directory. Consider a directory tree:
% tree helm-bug
helm-bug
└── cert-manager
    └── values.yaml

1 directory, 1 file

values.yaml is empty here; its content doesn't matter.
This works fine:
helm template cert-manager cert-manager --repo https://charts.jetstack.io -f helm-bug/cert-manager/values.yaml

If I change directory into helm-bug/cert-manager/, this works fine:
helm template cert-manager cert-manager --repo https://charts.jetstack.io -f values.yaml

If I change directory into helm-bug/, this works fine:
helm repo add jetstack https://charts.jetstack.io
helm repo update
helm template cert-manager jetstack/cert-manager -f cert-manager/values.yaml

However, if I change directory into helm-bug/, none of the following work:
helm template cert-manager cert-manager --repo https://charts.jetstack.io -f cert-manager/values.yaml
helm template cert-manager cert-manager --repo https://charts.jetstack.io -f ./cert-manager/values.yaml
helm template cert-manager cert-manager --repo https://charts.jetstack.io -f "$(readlink -f cert-manager/values.yaml)"

Moreover, if I rename the cert-manager directory to certmanager, it works fine. Similarly, if I omit the values file, this works fine:
helm template cert-manager cert-manager --repo https://charts.jetstack.io

So something about passing that values file in makes helm look for the chart locally instead of in the repo that I've told it to use.
Debug output is pretty terse:
% helm --debug template cert-manager cert-manager --repo https://charts.jetstack.io -f cert-manager/values.yaml
install.go:173: [debug] Original chart version: ""
install.go:190: [debug] CHART PATH: /home/stpierre/helm-bug/cert-manager

Error: Chart.yaml file is missing
helm.go:81: [debug] Chart.yaml file is missing
helm.sh/helm/v3/pkg/chart/loader.LoadFiles
        /home/circleci/helm.sh/helm/pkg/chart/loader/load.go:158
helm.sh/helm/v3/pkg/chart/loader.LoadDir
        /home/circleci/helm.sh/helm/pkg/chart/loader/directory.go:119
helm.sh/helm/v3/pkg/chart/loader.DirLoader.Load
        /home/circleci/helm.sh/helm/pkg/chart/loader/directory.go:41
helm.sh/helm/v3/pkg/chart/loader.Load
        /home/circleci/helm.sh/helm/pkg/chart/loader/load.go:62
main.runInstall
        /home/circleci/helm.sh/helm/cmd/helm/install.go:199
main.newTemplateCmd.func2
        /home/circleci/helm.sh/helm/cmd/helm/template.go:73
github.com/spf13/cobra.(*Command).execute
        /go/pkg/mod/github.com/spf13/cobra@v1.1.1/command.go:850
github.com/spf13/cobra.(*Command).ExecuteC
        /go/pkg/mod/github.com/spf13/cobra@v1.1.1/command.go:958
github.com/spf13/cobra.(*Command).Execute
        /go/pkg/mod/github.com/spf13/cobra@v1.1.1/command.go:895
main.main
        /home/circleci/helm.sh/helm/cmd/helm/helm.go:80
runtime.main
        /usr/local/go/src/runtime/proc.go:204
runtime.goexit
        /usr/local/go/src/runtime/asm_amd64.s:1374

That seems to indicate that it's looking for the Chart.yaml in the same directory as values.yaml instead of in the remote chart.
There are workarounds available, but the command I've given is run by skaffold so unfortunately the least disruptive one -- adding the repo and templating the chart from there -- isn't an option.

Okay, looks like I was wrong and screwed something up while trying to test this; you do not have to pass in a values file to trigger this. If a subdirectory with the same name as the chart exists, that's sufficient to trigger this bug. So it's not as complicated as I originally thought, but that also means that it's more annoying to work around.

Another easy reproducer:
$ helm repo add "stable" "https://charts.helm.sh/stable" --force-update
$ helm template nginx stable/nginx-ingress | tail -n 2
WARNING: This chart is deprecated
      serviceAccountName: nginx-nginx-ingress-backend
      terminationGracePeriodSeconds: 60
$ mkdir stable
$ helm template nginx stable/nginx-ingress | tail -n 2
WARNING: This chart is deprecated
      serviceAccountName: nginx-nginx-ingress-backend
      terminationGracePeriodSeconds: 60
$ mkdir nginx-ingress
$ helm template nginx stable/nginx-ingress | tail -n 2
WARNING: This chart is deprecated
      serviceAccountName: nginx-nginx-ingress-backend
      terminationGracePeriodSeconds: 60
$ mkdir stable/nginx-ingress
$ helm template nginx stable/nginx-ingress | tail -n 2
Error: Chart.yaml file is missing

The problem is that  stable/nginx-ingress is mistaken for a relative path.
cmd/helm/install.go
185         cp, err := client.ChartPathOptions.LocateChart(chart, settings)
186         if err != nil {
187                 return nil, err
188         }
189
190         debug("CHART PATH: %s\n", cp)

See here:
622 // LocateChart looks for a chart directory in known places, and returns either the full path or an error.
623 //
624 // This does not ensure that the chart is well-formed; only that the requested filename exists.
625 //
626 // Order of resolution:
627 // - relative to current working directory
628 // - if path is absolute or begins with '.', error out here
629 // - URL
630 //
631 // If 'verify' was set on ChartPathOptions, this will attempt to also verify the chart.
632 func (c *ChartPathOptions) LocateChart(name string, settings *cli.EnvSettings) (string, error) {
636         if _, err := os.Stat(name); err == nil {
637                 abs, err := filepath.Abs(name)
638                 if err != nil {
639                         return abs, err
640                 }
641                 if c.Verify {
642                         if _, err := downloader.VerifyChart(abs, c.Keyring); err != nil {
643                                 return "", err
644                         }
645                 }
646                 return abs, nil
647         }
(...)

So this may work as designed, I'll let the repository / project owners comment on that.

Thanks for all the work here.
First, Helm handling path/to/chart and ./path/to/chart the same for relative paths is intentional. It's not just Helm but the handling built into the Go standard library. Many applications are this way in Go and in other languages. It is fairly common to handle them the same.
A bug I see is that path/to/chart and ./path/to/chart should have the same error message. That is why I marked it as a bug.
This is mostly a works as designed situation with what I would call a small bug being discovered.

The bug to me feels like the user explicitly specifying a repository to use, but that being ignored. Is there a use case for providing --repo, but using the local path instead?

You can have a repo on local disk and reference that. When I am testing I regularly do this.

I'm not sure why you'd need the repo in that case. If you tell it to use your local repo, but there's a matching local directory, it will always ignore your --repo flag and look in the current directory first.
So: What's the use case for specifying --repo when you know or expect that it will be ignored? Could we at least emit a warning when the user has signaled their explicit intention to use a repo that isn't the current working directory, but helm ignores their intentions and uses the current working directory instead? It's an awful UX, and the least we could do is alert the user that helm is ignoring their explicit request.

Hi,
So something like that?
$ bin/helm template cert-manager cert-manager --repo https://charts.jetstack.io -f values.yaml
WARNING: Chart found at local path '/home/akaris/development/helm/cert-manager'. Ignoring Repository URL 'https://charts.jetstack.io.'
Error: open values.yaml: no such file or directory

Andreas

Not as good as a fix IMO, but definitely an improvement. It would have saved me a bunch of troubleshooting time a couple of days ago for sure. :joy:

Thanks for all the work here.
First, Helm handling path/to/chart and ./path/to/chart the same for relative paths is intentional. It's not just Helm but the handling built into the Go standard library. Many applications are this way in Go and in other languages. It is fairly common to handle them the same.
A bug I see is that path/to/chart and ./path/to/chart should have the same error message. That is why I marked it as a bug.
This is mostly a works as designed situation with what I would call a small bug being discovered.

It should be a problem caused by --repo (if you use --repo, you should not check the chart locally).

FYI - I think it should be reopened as I have just encountered the same issue in version 2.11.0
provider "registry.terraform.io/hashicorp/helm" {
  version = "2.11.0"
  ...

I used the same module folder name as the chart name and it fails to find the Chart.yaml file. Renaming the module folder to something different makes it work.

I also think this should be reopened, experienced it today as well. This should not be intended behaviour.


Render from stdin

https://github.com/tiangolo/typer/issues/345

https://github.com/tiangolo/typer/issues/177

https://github.com/pallets/click/issues/1144

Wansn't really happy with any of the above solutions. Can we just use a callback instead along with click.open_file? The callback will check if isatty and stdin, then return "-". Use in conjuction with allow_dash=True for typer.Argument.


Fix docker generated file permissions

Description

When docker runs as root and creates files on a mounted volume, those files will have root:root permissions and will not be able to be modified or deleted by a regular user on the computer. See https://github.com/WordPress/openverse-api/runs/7526184802?check_suite_focus=true for example.
We can fix the permissions by running as a non-root user. See how this is done for the frontend: https://github.com/WordPress/openverse-frontend/blob/c4a117a11ddda2d0085506c88284db43e2784223/docker-compose.playwright.yml#L11
Reproduction

Run the API via docker and then try to delete the files it creates as a normal user on your computer. It should fail similarly to in the GitHub action linked above.
Resolution

[ ] 🙋 I would be interested in resolving this bug.

Rising to high priority🔺 because it's making our CI pipeline fail.


Inconsistent gauges after hot-restart on endpoints /clusters and /stats/prometheus

Description:
After hot-restart, gauges, especially upstream_cx_active on /stats/prometheus endpoint, do not reset themselves. Values from previous instances are added to current.
Sending POST to /reset_counters does not reset gauges either.
Should envoy behave like this?
It can be easily reproduced by checking /stats/prometheus metrics, before and after hot-restart and comparing them to cx_active returned /clusters admin endpoint
curl http://localhost:8001/stats/prometheus 2>/dev/null | grep 'upstream_cx_active

Repro steps:

checkout branch hot_restart_container of respository https://github.com/andrzejwaw/envoy/tree/hot_restart_container

in envoy/examples/front-proxy execute
docker-compose-up

send some request to services
wrk -t12 -c400 -d30s http://localhost:8000/service/1

check metrics:
$ curl http://localhost:8001/stats/prometheus 2>/dev/null | grep 'upstream_cx_active' | grep service1
envoy_cluster_upstream_cx_active{envoy_cluster_name="service1"} 6
$ curl http://localhost:8001/clusters 2>/dev/null | grep 'cx_active' | grep service1
service1::<IP_ADDRESS>:80::cx_active::6

make a hot-restart (send SIGHUP signal to hot-restarter.py process) and wait for it (up to one minute):

check metrics:
After hot-restart gauge upstream_cx from /stats/prometheus is inconsistent with cx_active from /clusters endpoint:
$ curl http://localhost:8001/stats/prometheus 2>/dev/null | grep 'upstream_cx_active' | grep service1
envoy_cluster_upstream_cx_active{envoy_cluster_name="service1"} 6

$ curl http://localhost:8001/clusters 2>/dev/null | grep 'cx_active' | grep service1
service1::<IP_ADDRESS>:80::cx_active::0

this makes it difficult to analyze the metrics

send more requests
wrk -t12 -c400 -d30s http://localhost:8000/service/1

check metrics:
$ curl http://localhost:8001/stats/prometheus 2>/dev/null | grep 'upstream_cx_active' | grep service1
envoy_cluster_upstream_cx_active{envoy_cluster_name="service1"} 12

$ curl http://localhost:8001/clusters 2>/dev/null | grep 'cx_active' | grep service1
service1::<IP_ADDRESS>:80::cx_active::6

I was expecting that after hot-restart both cx_active values from /stats/prometheus endpoint and /clusters endpoint will be equal to 0.

Hi @andrzejwaw,
FYI, Statistics and some locks are kept in a shared memory region which means gauges will be consistent across both processes as restart is taking place.
If you want to reset the metrics go to the admin page and click on "reset counters".

Thanks for the report, @andrzejwaw
@mk46 stats are not kept in shared memory any longer. They are synced via RPC from parent to child during hot-restart.
Gauge behavior depends on how it was declared. The one referenced here is:
GAUGE(upstream_cx_active, Accumulate)

which means that it accumulates across a hot-restart. There are also gauges that are declared as NeverImport:
GAUGE(membership_total, NeverImport)

/reset_counters does not reset gauges. Are you requesting /reset_gauges? I'm not sure that makes sense for a Gauge in general, and this one in particular, to be honest.
I'm not totally following your example. Are you saying the gauges are wrong? I'm not an expert on the semantics of upstream_cx_active. Is that measuring the L4 connections to an upstream? If that's the case I'd expect the connection to the upstream to be opened in response to an initial downstream request, and to stay open. I'd expect the count representing the sum of parent/child connections to upstreams to be reflected in the child-envoy stat. However, I think I might also expect that as the parent shuts down, it would drop its upstream connections, decrement the gauge, and have that decrement propagate to the child.
I don't know if Envoy has a test for that flow. Is that the issue? I could imagine there could be a bug where the connections to the upstream are shut down but the gauge-decrement is not propagated to the child, but I'm not sure.

@jmarant Thanks, I get that from docs and a blog written by @mattklein123 on hot restart. RPC and shared memory both used in parent-child communication. If my understanding is not correct then need to change https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/operations/hot_restart

If my understanding is not correct then need to change https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/operations/hot_restart

Yes this page is out of date. Either myself or @jmarantz will fix it. Thank you for bring it to our attention!

Looks like this is similar to my this issue https://github.com/envoyproxy/envoy/issues/9070#issuecomment-614427664

Hi, I've updated branch hot_restart_container of respository https://github.com/andrzejwaw/envoy/tree/hot_restart_container
with added paramters --parent-shutdown-time-s 15 --drain-time-s 10 and made a script for tests ( /opt/envoy/examples/front-proxy/test.sh )
so more tests can be done easly. Also used netstats to check active connections.
As @jmarantz said

However, I think I might also expect that as the parent shuts down, it would drop its upstream connections, decrement the gauge, and have that decrement propagate to the child.

I expected also, that after parents shutdown, gauge value will drop, so in example i've set parent shutdown time and drain time.
In pseudo code test looks like:
show_metrics
make_some_requests
show_metrics

make_hot_restart
check_envoys_uptime_and_wait_for_parent_to_die
show_metrics

make_some_requests
show_metrics
sleep_seconds

make_hot_restart
check_envoys_uptime_and_wait_for_parent_to_die
show_metrics

And last checking of metrics result is:
### 04/20/20.09:51:54:168121200: Show metrics ###
/clusters cx-active:
service1::<IP_ADDRESS>:80::cx_active::0
/stats/prometheus cx-active:
envoy_cluster_upstream_cx_active{envoy_cluster_name="service1"} 12
netstat -tup -W:
tcp        0      0 d16c99ec5c1f:39758      front-proxy_service1_1.front-proxy_envoymesh:http TIME_WAIT   -
tcp        0      0 d16c99ec5c1f:54156      front-proxy_service1_1.front-proxy_envoymesh:http TIME_WAIT   -
tcp        0      0 d16c99ec5c1f:54012      front-proxy_service1_1.front-proxy_envoymesh:http TIME_WAIT   -
tcp        0      0 d16c99ec5c1f:54154      front-proxy_service1_1.front-proxy_envoymesh:http TIME_WAIT   -
tcp        0      0 d16c99ec5c1f:39866      front-proxy_service1_1.front-proxy_envoymesh:http TIME_WAIT   -
tcp        0      0 d16c99ec5c1f:39762      front-proxy_service1_1.front-proxy_envoymesh:http TIME_WAIT   -
tcp        0      0 d16c99ec5c1f:39764      front-proxy_service1_1.front-proxy_envoymesh:http TIME_WAIT   -
tcp        0      0 d16c99ec5c1f:54018      front-proxy_service1_1.front-proxy_envoymesh:http TIME_WAIT   -
tcp        0      0 d16c99ec5c1f:39760      front-proxy_service1_1.front-proxy_envoymesh:http TIME_WAIT   -
tcp        0      0 d16c99ec5c1f:54244      front-proxy_service1_1.front-proxy_envoymesh:http TIME_WAIT   -
tcp        0      0 d16c99ec5c1f:39766      front-proxy_service1_1.front-proxy_envoymesh:http TIME_WAIT   -
tcp        0      0 d16c99ec5c1f:54230      front-proxy_service1_1.front-proxy_envoymesh:http TIME_WAIT   -

So, as we see netstat and clusters show all connection closed, gauge is not.
@mattklein123 I think it is more concerns area/stats then area/docs. The gauge is more inconsistent on every hot-restart. It is hard to relay on that metric, if you do not know that hot-restart was done.
And here are full details of execution /opt/envoy/examples/front-proxy/test.sh within envoy container:
# bash /opt/envoy/examples/front-proxy/test.sh

### 04/20/20.09:50:47:941460000: Show metrics ###
/clusters cx-active:
service1::<IP_ADDRESS>:80::cx_active::0
/stats/prometheus cx-active:
envoy_cluster_upstream_cx_active{envoy_cluster_name="service1"} 0
netstat -tup -W:

### 04/20/20.09:50:48:001711900: Send some requests ###
Running 10s test @ http://localhost:80/service/1
  12 threads and 400 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency   554.77ms  272.50ms   1.57s    67.48%
    Req/Sec    79.98     67.17   310.00     68.62%
  6818 requests in 10.09s, 1.68MB read
  Non-2xx or 3xx responses: 3733
Requests/sec:    676.05
Transfer/sec:    170.77KB

### 04/20/20.09:50:58:377360300: Show metrics ###
/clusters cx-active:
service1::<IP_ADDRESS>:80::cx_active::6
/stats/prometheus cx-active:
envoy_cluster_upstream_cx_active{envoy_cluster_name="service1"} 6
netstat -tup -W:
tcp        0      0 d16c99ec5c1f:39758      front-proxy_service1_1.front-proxy_envoymesh:http ESTABLISHED 8/envoy
tcp        0      0 d16c99ec5c1f:39866      front-proxy_service1_1.front-proxy_envoymesh:http ESTABLISHED 8/envoy
tcp        0      0 d16c99ec5c1f:39762      front-proxy_service1_1.front-proxy_envoymesh:http ESTABLISHED 8/envoy
tcp     2107      0 d16c99ec5c1f:39764      front-proxy_service1_1.front-proxy_envoymesh:http ESTABLISHED 8/envoy
tcp        0      0 d16c99ec5c1f:39760      front-proxy_service1_1.front-proxy_envoymesh:http ESTABLISHED 8/envoy
tcp        0     39 d16c99ec5c1f:39766      front-proxy_service1_1.front-proxy_envoymesh:http ESTABLISHED 8/envoy

### 04/20/20.09:50:58:502086800: making hot-restart, sending sighup to pid: 6 ###

### 04/20/20.09:50:58:510403800: Checking envoys exists  ###
UID        PID  PPID  C STIME TTY          TIME CMD
root         8     7  4 09:48 ?        00:00:07 /usr/local/bin/envoy -l debug -c /etc/front-envoy.yaml --service-cluster front-proxy --service-node front-proxy-id --base-id 1 --restart-epoch 0 --parent-shutdown-time-s 15 --drain-time-s 10
{
  "restart_epoch": 0,
  "uptime_current_epoch": "168s",
  "uptime_all_epochs": "168s"
}
Parent still exist

04/20/20.09:50:58:544930900 Sleep for 3

### 04/20/20.09:51:01:551883300: Checking envoys exists  ###
UID        PID  PPID  C STIME TTY          TIME CMD
root         8     7  4 09:48 ?        00:00:08 /usr/local/bin/envoy -l debug -c /etc/front-envoy.yaml --service-cluster front-proxy --service-node front-proxy-id --base-id 1 --restart-epoch 0 --parent-shutdown-time-s 15 --drain-time-s 10
root        92    85  3 09:50 ?        00:00:00 /usr/local/bin/envoy -l debug -c /etc/front-envoy.yaml --service-cluster front-proxy --service-node front-proxy-id --base-id 1 --restart-epoch 1 --parent-shutdown-time-s 15 --drain-time-s 10
{
  "restart_epoch": 1,
  "uptime_current_epoch": "3s",
  "uptime_all_epochs": "171s"
}
Parent still exist

04/20/20.09:51:01:582125300 Sleep for 3

### 04/20/20.09:51:04:587994300: Checking envoys exists  ###
UID        PID  PPID  C STIME TTY          TIME CMD
root         8     7  4 09:48 ?        00:00:08 /usr/local/bin/envoy -l debug -c /etc/front-envoy.yaml --service-cluster front-proxy --service-node front-proxy-id --base-id 1 --restart-epoch 0 --parent-shutdown-time-s 15 --drain-time-s 10
root        92    85  2 09:50 ?        00:00:00 /usr/local/bin/envoy -l debug -c /etc/front-envoy.yaml --service-cluster front-proxy --service-node front-proxy-id --base-id 1 --restart-epoch 1 --parent-shutdown-time-s 15 --drain-time-s 10
{
  "restart_epoch": 1,
  "uptime_current_epoch": "6s",
  "uptime_all_epochs": "174s"
}
Parent still exist

04/20/20.09:51:04:618059600 Sleep for 3

### 04/20/20.09:51:07:623789800: Checking envoys exists  ###
UID        PID  PPID  C STIME TTY          TIME CMD
root         8     7  4 09:48 ?        00:00:08 /usr/local/bin/envoy -l debug -c /etc/front-envoy.yaml --service-cluster front-proxy --service-node front-proxy-id --base-id 1 --restart-epoch 0 --parent-shutdown-time-s 15 --drain-time-s 10
root        92    85  1 09:50 ?        00:00:00 /usr/local/bin/envoy -l debug -c /etc/front-envoy.yaml --service-cluster front-proxy --service-node front-proxy-id --base-id 1 --restart-epoch 1 --parent-shutdown-time-s 15 --drain-time-s 10
{
  "restart_epoch": 1,
  "uptime_current_epoch": "9s",
  "uptime_all_epochs": "177s"
}
Parent still exist

04/20/20.09:51:07:651508000 Sleep for 3

### 04/20/20.09:51:10:656398400: Checking envoys exists  ###
UID        PID  PPID  C STIME TTY          TIME CMD
root         8     7  4 09:48 ?        00:00:08 /usr/local/bin/envoy -l debug -c /etc/front-envoy.yaml --service-cluster front-proxy --service-node front-proxy-id --base-id 1 --restart-epoch 0 --parent-shutdown-time-s 15 --drain-time-s 10
root        92    85  1 09:50 ?        00:00:00 /usr/local/bin/envoy -l debug -c /etc/front-envoy.yaml --service-cluster front-proxy --service-node front-proxy-id --base-id 1 --restart-epoch 1 --parent-shutdown-time-s 15 --drain-time-s 10
{
  "restart_epoch": 1,
  "uptime_current_epoch": "12s",
  "uptime_all_epochs": "180s"
}
Parent still exist

04/20/20.09:51:10:680607500 Sleep for 3

### 04/20/20.09:51:13:685911200: Checking envoys exists  ###
UID        PID  PPID  C STIME TTY          TIME CMD
root        92    85  1 09:50 ?        00:00:00 /usr/local/bin/envoy -l debug -c /etc/front-envoy.yaml --service-cluster front-proxy --service-node front-proxy-id --base-id 1 --restart-epoch 1 --parent-shutdown-time-s 15 --drain-time-s 10
{
  "restart_epoch": 1,
  "uptime_current_epoch": "15s",
  "uptime_all_epochs": "183s"
}

### 04/20/20.09:51:13:712590300: Show metrics ###
/clusters cx-active:
service1::<IP_ADDRESS>:80::cx_active::0
/stats/prometheus cx-active:
envoy_cluster_upstream_cx_active{envoy_cluster_name="service1"} 6
netstat -tup -W:
tcp        0      0 d16c99ec5c1f:39758      front-proxy_service1_1.front-proxy_envoymesh:http TIME_WAIT   -
tcp        0      0 d16c99ec5c1f:39866      front-proxy_service1_1.front-proxy_envoymesh:http TIME_WAIT   -
tcp        0      0 d16c99ec5c1f:39762      front-proxy_service1_1.front-proxy_envoymesh:http TIME_WAIT   -
tcp        0      0 d16c99ec5c1f:39764      front-proxy_service1_1.front-proxy_envoymesh:http TIME_WAIT   -
tcp        0      0 d16c99ec5c1f:39760      front-proxy_service1_1.front-proxy_envoymesh:http TIME_WAIT   -
tcp        0      0 d16c99ec5c1f:39766      front-proxy_service1_1.front-proxy_envoymesh:http TIME_WAIT   -

### 04/20/20.09:51:13:760103000: Send some requests ###
Running 10s test @ http://localhost:80/service/1
  12 threads and 400 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency   360.33ms  214.69ms   1.02s    71.23%
    Req/Sec    91.88     81.16   420.00     80.17%
  7504 requests in 10.05s, 1.87MB read
  Non-2xx or 3xx responses: 7504
Requests/sec:    746.40
Transfer/sec:    190.15KB

### 04/20/20.09:51:23:892664300: Show metrics ###
/clusters cx-active:
service1::<IP_ADDRESS>:80::cx_active::6
/stats/prometheus cx-active:
envoy_cluster_upstream_cx_active{envoy_cluster_name="service1"} 12
netstat -tup -W:
tcp        0      0 d16c99ec5c1f:39758      front-proxy_service1_1.front-proxy_envoymesh:http TIME_WAIT   -
tcp        0      0 d16c99ec5c1f:54156      front-proxy_service1_1.front-proxy_envoymesh:http ESTABLISHED 92/envoy
tcp        0      0 d16c99ec5c1f:54012      front-proxy_service1_1.front-proxy_envoymesh:http ESTABLISHED 92/envoy
tcp        0      0 d16c99ec5c1f:54154      front-proxy_service1_1.front-proxy_envoymesh:http ESTABLISHED 92/envoy
tcp        0      0 d16c99ec5c1f:39866      front-proxy_service1_1.front-proxy_envoymesh:http TIME_WAIT   -
tcp        0      0 d16c99ec5c1f:39762      front-proxy_service1_1.front-proxy_envoymesh:http TIME_WAIT   -
tcp        0      0 d16c99ec5c1f:39764      front-proxy_service1_1.front-proxy_envoymesh:http TIME_WAIT   -
tcp        0      0 d16c99ec5c1f:54018      front-proxy_service1_1.front-proxy_envoymesh:http ESTABLISHED 92/envoy
tcp        0      0 d16c99ec5c1f:39760      front-proxy_service1_1.front-proxy_envoymesh:http TIME_WAIT   -
tcp        0      0 d16c99ec5c1f:54244      front-proxy_service1_1.front-proxy_envoymesh:http ESTABLISHED 92/envoy
tcp        0      0 d16c99ec5c1f:39766      front-proxy_service1_1.front-proxy_envoymesh:http TIME_WAIT   -
tcp        0      0 d16c99ec5c1f:54230      front-proxy_service1_1.front-proxy_envoymesh:http ESTABLISHED 92/envoy

04/20/20.09:51:23:972571300 Sleep for 15

### 04/20/20.09:51:38:982699000: making hot-restart, sending sighup to pid: 6 ###

### 04/20/20.09:51:38:989809100: Checking envoys exists  ###
UID        PID  PPID  C STIME TTY          TIME CMD
root        92    85 14 09:50 ?        00:00:06 /usr/local/bin/envoy -l debug -c /etc/front-envoy.yaml --service-cluster front-proxy --service-node front-proxy-id --base-id 1 --restart-epoch 1 --parent-shutdown-time-s 15 --drain-time-s 10
{
  "restart_epoch": 1,
  "uptime_current_epoch": "41s",
  "uptime_all_epochs": "209s"
}
Parent still exist

04/20/20.09:51:39:016859000 Sleep for 3

### 04/20/20.09:51:42:021225400: Checking envoys exists  ###
UID        PID  PPID  C STIME TTY          TIME CMD
root        92    85 13 09:50 ?        00:00:06 /usr/local/bin/envoy -l debug -c /etc/front-envoy.yaml --service-cluster front-proxy --service-node front-proxy-id --base-id 1 --restart-epoch 1 --parent-shutdown-time-s 15 --drain-time-s 10
root       245   238  2 09:51 ?        00:00:00 /usr/local/bin/envoy -l debug -c /etc/front-envoy.yaml --service-cluster front-proxy --service-node front-proxy-id --base-id 1 --restart-epoch 2 --parent-shutdown-time-s 15 --drain-time-s 10
{
  "restart_epoch": 2,
  "uptime_current_epoch": "3s",
  "uptime_all_epochs": "212s"
}
Parent still exist

04/20/20.09:51:42:052572600 Sleep for 3

### 04/20/20.09:51:45:026936100: Checking envoys exists  ###
UID        PID  PPID  C STIME TTY          TIME CMD
root        92    85 12 09:50 ?        00:00:06 /usr/local/bin/envoy -l debug -c /etc/front-envoy.yaml --service-cluster front-proxy --service-node front-proxy-id --base-id 1 --restart-epoch 1 --parent-shutdown-time-s 15 --drain-time-s 10
root       245   238  1 09:51 ?        00:00:00 /usr/local/bin/envoy -l debug -c /etc/front-envoy.yaml --service-cluster front-proxy --service-node front-proxy-id --base-id 1 --restart-epoch 2 --parent-shutdown-time-s 15 --drain-time-s 10
{
  "restart_epoch": 2,
  "uptime_current_epoch": "6s",
  "uptime_all_epochs": "215s"
}
Parent still exist

04/20/20.09:51:45:056065700 Sleep for 3

### 04/20/20.09:51:48:063366100: Checking envoys exists  ###
UID        PID  PPID  C STIME TTY          TIME CMD
root        92    85 12 09:50 ?        00:00:06 /usr/local/bin/envoy -l debug -c /etc/front-envoy.yaml --service-cluster front-proxy --service-node front-proxy-id --base-id 1 --restart-epoch 1 --parent-shutdown-time-s 15 --drain-time-s 10
root       245   238  1 09:51 ?        00:00:00 /usr/local/bin/envoy -l debug -c /etc/front-envoy.yaml --service-cluster front-proxy --service-node front-proxy-id --base-id 1 --restart-epoch 2 --parent-shutdown-time-s 15 --drain-time-s 10
{
  "restart_epoch": 2,
  "uptime_current_epoch": "9s",
  "uptime_all_epochs": "218s"
}
Parent still exist

04/20/20.09:51:48:095245600 Sleep for 3

### 04/20/20.09:51:51:101464800: Checking envoys exists  ###
UID        PID  PPID  C STIME TTY          TIME CMD
root        92    85 11 09:50 ?        00:00:06 /usr/local/bin/envoy -l debug -c /etc/front-envoy.yaml --service-cluster front-proxy --service-node front-proxy-id --base-id 1 --restart-epoch 1 --parent-shutdown-time-s 15 --drain-time-s 10
root       245   238  1 09:51 ?        00:00:00 /usr/local/bin/envoy -l debug -c /etc/front-envoy.yaml --service-cluster front-proxy --service-node front-proxy-id --base-id 1 --restart-epoch 2 --parent-shutdown-time-s 15 --drain-time-s 10
{
  "restart_epoch": 2,
  "uptime_current_epoch": "12s",
  "uptime_all_epochs": "221s"
}
Parent still exist

04/20/20.09:51:51:135300500 Sleep for 3

### 04/20/20.09:51:54:141039300: Checking envoys exists  ###
UID        PID  PPID  C STIME TTY          TIME CMD
root       245   238  1 09:51 ?        00:00:00 /usr/local/bin/envoy -l debug -c /etc/front-envoy.yaml --service-cluster front-proxy --service-node front-proxy-id --base-id 1 --restart-epoch 2 --parent-shutdown-time-s 15 --drain-time-s 10
{
  "restart_epoch": 2,
  "uptime_current_epoch": "15s",
  "uptime_all_epochs": "224s"
}

### 04/20/20.09:51:54:168121200: Show metrics ###
/clusters cx-active:
service1::<IP_ADDRESS>:80::cx_active::0
/stats/prometheus cx-active:
envoy_cluster_upstream_cx_active{envoy_cluster_name="service1"} 12
netstat -tup -W:
tcp        0      0 d16c99ec5c1f:39758      front-proxy_service1_1.front-proxy_envoymesh:http TIME_WAIT   -
tcp        0      0 d16c99ec5c1f:54156      front-proxy_service1_1.front-proxy_envoymesh:http TIME_WAIT   -
tcp        0      0 d16c99ec5c1f:54012      front-proxy_service1_1.front-proxy_envoymesh:http TIME_WAIT   -
tcp        0      0 d16c99ec5c1f:54154      front-proxy_service1_1.front-proxy_envoymesh:http TIME_WAIT   -
tcp        0      0 d16c99ec5c1f:39866      front-proxy_service1_1.front-proxy_envoymesh:http TIME_WAIT   -
tcp        0      0 d16c99ec5c1f:39762      front-proxy_service1_1.front-proxy_envoymesh:http TIME_WAIT   -
tcp        0      0 d16c99ec5c1f:39764      front-proxy_service1_1.front-proxy_envoymesh:http TIME_WAIT   -
tcp        0      0 d16c99ec5c1f:54018      front-proxy_service1_1.front-proxy_envoymesh:http TIME_WAIT   -
tcp        0      0 d16c99ec5c1f:39760      front-proxy_service1_1.front-proxy_envoymesh:http TIME_WAIT   -
tcp        0      0 d16c99ec5c1f:54244      front-proxy_service1_1.front-proxy_envoymesh:http TIME_WAIT   -
tcp        0      0 d16c99ec5c1f:39766      front-proxy_service1_1.front-proxy_envoymesh:http TIME_WAIT   -
tcp        0      0 d16c99ec5c1f:54230      front-proxy_service1_1.front-proxy_envoymesh:http TIME_WAIT   -

@andrzejwaw can you please summarize what you think the bug is? Which stat(s) are broken?
@jmarantz I suspect the issue here is that we are missing the final flush before the parent shuts down. This was never a problem previously with shared memory. I wonder if when the parent is actually gone for accumulate gauges we need to actually do a final subtraction or something like that?

That was my suspicion as well, and I want need to review the 2s complement logic when we are transmitting a decremented gauge.
Do you have a recommendation of what needs to be modified to kick off a final flush?

Do you have a recommendation of what needs to be modified to kick off a final flush?

I think there are probably 2 options:

See the logic around sendParentTerminateRequest and startParentShutdownSequence. I think as part of this flow you could do a final stats fetch and update, but TBH I think this will a) be difficult and b) still not catch all the stat decrements.
When you know the parent is going away, force decrement any remaining parent gauge deltas on accumulate gauges to reconcile the parent going away. This is what I think we should do.

@mattklein123 I noticed the problem on upstream_cx_active and lb_subsets gauges from /stats/prometheus. But probably it affects all accumulate gauges.
Gauge upstream_cx_active should report open connections for upstream also after hot-restart, it does not. After hot-restart it holds values from parent (even if parent died). Should drop values after parent shutdown.
Gauge lb_subsets - should be constant after each hot-restart. Now, after each restart value is incremented.

@andrzejwaw thanks, I think we know what the issue is. Hopefully @jmarantz can work on a fix.

I have started working on this. Doesn't look too hard, except for the integration test :)

The code, per Matt's option 2 above, was easy enough. But I added some logging to see what was going on in the integration test, and felt like ti was doing the wrong thing. e.g.
[2020-05-22 16:43:50.496][844][error][misc] [source/common/stats/stat_merger.cc:147] JOSH: subtracting<PHONE_NUMBER> from gauge server.days_until_first_cert_expiring with current value<PHONE_NUMBER>

Probably that gauge should be labeled NeverImport; it was likely an oversight to accumulate those.
Another case is:
[2020-05-22 16:43:50.497][844][error][misc] [source/common/stats/stat_merger.cc:147] JOSH: subtracting 8388608 from gauge server.memory_heap_size with current value 6291456

Probably NeverImport for that too, though I can kind of see why you might think that makes sense to accumulate.
Maybe it should be an ASSERT failure to call set() on a Gauge that's allocated with Accumulate.
Another one is the gauge I added to track hot_restart_generation, which uses Accumulate to add values from the parent. I think that will start to fail if I zero out parent contribution, though for some reason hotrestart_test worked for me. I have a feeling I was polling the child value before the parent had exited in the test. I guess we could just use separate logic to track that, though I think implementing that as an imported gauge, as I did, had some test coverage value.

I think this can largely be a question of refinement at this point. But @mattklein123 could use your opinion on whether this is the right direction. I'm changing a fairly large number of Accumulate stats to NeverImport. Some of them seem fairly obvious that we should never have been importing them. In one case (health check) there was custom logic to defeat sharing across hot-restart parent/child, which I think it was correct to simply remove. In others (connection counts etc) the combined count might be useful, but there were so many calls to Gauge::set() that were violating my new assertion that I had to just switch them to NeverImport.
We could, I guess, leave the ones we think make sense as Accumulate but still call set(), and just remove the assert after having done the audit. But I think any time we are calling Gauge::set() with an Accumulate stat it deserves some scrutiny. WDTY?

WiP PR here: https://github.com/envoyproxy/envoy/pull/11301


Remove .required class from label?

How can I remove .required class from label?
I want the presence validation in my main form, but i need to remove .required from search form
<%= f.select :status, Campaign.statuses.collect{|status, i| [t(status), i] }, {include_blank: 'All', label_class: 'control-label'}, {name: :status, wrapper_class: 'col-md-6'} %>

Still render with . required
<label class="control-label control-label required" for="campaign_status">Status</label>

Hi @Stajor, right now it is determined solely on the field having a presence validator -- there is no way to exclude it.
A couple of thoughts:

we figure out how to exclude it :-)
you try a different version of CSS that doesn't select the Status label when in a Search form
avoid using the presence validator on the Status field if in Search mode

Just curious.  The Status field is required but the class is causing you grief or you don't want to show an '*'?  Do you have different logic making the Status field optional when in the Search context?

Yes the field is optional only in search context.
For now I can fix it with css.
I'm waiting for next update :)
Thank you for great and useful gem


Incorrect type for sendDocument’s result

Sending a WebP video or photo, or a .tgs file returns a StickerMessage, not DocumentMessage.

In the types or at runtime?

Types.


[plot] Provide colormap API to reach color from data

There is no obvious way to reach a color from few data from the Colormap object.
My main target is to display the color of a single picked data.
applyToData is only applied to the full data.
This method could take an optional min/max range.

This should provide a consistent way with #2855 in order to reduce code overhead.
And with #2739

Here is my trick but it will not work for min/max based on statistics
value = 100
colormap = item.getColormap()
vmin, vmax = colormap.getColormapRange(item.getValueData(copy=False))
colors = colormap.applyToData(numpy.array([value, vmin, vmax]))
color = colors[0]

The Colormap objects have no connection with items and so with data.
It has the advantage of describing what is wanted rather than what is actually displayed... but this is also a limitation.
We need to think a bit on this. I see different options:

keep some internal state (e.g., range or mean/std of last transformed dataset),
add a new class that binds a colormap to some data,
add a method in the item to get the color of one or many data elemets (in the end, it seems that it is what you need).

I was thinking about passing the item or the min/max range as a param.


Terminal Output Logging Functionality

Description of the new feature/enhancement
Something that is really missing from the terminal is a logging option for all the output that is currently displayed in the screen. Either plain output or with timestamps of the time the command was issued. It can be saved either in raw format or saving also the colours and other characters from the terminal.

The problem is that there isn't a solid way to log the output on the terminal. On some linux devices you can use the script program but it is buggy and requires a lot of changes to make it work as intended. There are other terminal emulators that provide this functionality and it is amazing, as it allows to check all the logs of all sessions. One emulator that is doing this is MobaXterm. Below is an image from that feature settings.

I would like to add an option on the profile selection (or anywhere that is relevant) asking for similar parameters either where the red box is, or on the advanced tab.

The feature should have the option to be enabled by default , select the format (plain or rich text) and the location of the files that will be saved. Also, it would be good to give the option to name the logs with parameters like: timestamp when the session started, username and host (like the title on the terminal windows).
I am not sure if it is duplicate, i searched but i couldn't find a similar issue. If it is please close it

See issue #9700.

Thanks for the feature request! (and thanks for the link James!)
Linked this up as a nested item in #9700. I'll keep this open since I like having smaller chunks of work tracked across separate issues.

Is this effort still alive?

Disappointed to discover auto-logging doesn't exist yet.  Any ETA?


Add support for Jenkins 2.X and Java 11

This badge plugin was developed to solve a specific need:

Show more badges from a Jenkins build (which are normally used in Enterprise scenarios tied to internal version control)

This project started in 2017 and successfully added the test coverage and test number badges for the 1.X version of Jenkins. Since then, it hasn't seen much love.
Fast forward today, Jenkins is on the 2.X architecture the following were never fixed:

Inject tests are still disabled
Still using workarounds for VIEW permissions
Unit tests (aren't really unit tests) and actually spin up a jenkins server and just test if badges can render
Java 8 is now on Java 13 (which this can't build on...)
The plugin works on 2.X, but makes it impossible to add new dependency packages
Fails static analysis
Never hosted on jenkinsci :(
Don't upload .hpi to github releases

@chetanddesai - Is this project still being used inside of Intuit? It may be a good opportunity to get some help so @rguenthe could get his #60 re-accepted

It also looks like https://wiki.jenkins.io/display/JENKINS/Embeddable+Build+Status+Plugin added support for Jenkins 2.X so we could create a branch and see if that helps us

It also looks like https://wiki.jenkins.io/display/JENKINS/Embeddable+Build+Status+Plugin drastically changed and is more flexible. This plugin may not be needed anymore.


Add support for JAVA8_HOME config

Adds JAVA8_HOME config support to allowe users to
specify the location of java

You should also add tests for this.

Applied changes. Remaining to add tests.

Much better, you should look at writing product tests now

Added test cases, @cawallin , @rschlussel , @ebd2

You should run make lint and fix the formatting, but aside from minor comments, this looks good.

Addressed all the comments. @cawallin , @rschlussel , @ebd2

Applied all the changes. @cawallin @rschlussel @ebd2

Applied all changes, @cawallin , @rschlussel , @ebd2

Looks good to me.

looks good

@kkc00  -- can you squash together all of your commits and then push --force to this branch?
@rschlussel  or @ebd2  -- can you merge his change in? Kamal isn't a part of the prestodb group (yet)

@cawallin , squashed all the commits and did push --force to the latest commit (after rebase).


Search in a Bitonic Array

Given an array arr[] that is increasing first and then decreasing and a number key, find the index of the number in the array if present, else return -1.
Input 1 :  arr[] = {-3, 9, 8, 20, 17, 5, 1};
key = 20
Output 1  : Found at index 3
Input 2 :  arr[] = {5, 6, 7, 8, 9, 10, 1, 2, 3};
key = 30
Output 2  : Not Found
Can I Work on this issue @amritansh22 ?

Yes sure. I have assigned the issue to you.

Thanks a lot.


apply_diff() needs to use and update node cache file

Per email thread, the diff processing is missing two key features in order to process way geometries:

Ability to use a node cache file that was initially created with apply_file(..., idx='dense_file_array,node.cache') when the diff file contains ways without relevant nodes
Ability to update that node cache file with the new node location

I ended up rewriting diff download and applying algorithm. This is slightly worse because it does not use the MergeReader, but I suspect there is relatively little value in de-dupping values before processing
        repserv = ReplicationServer(self.options.osm_updater_url)
        seqid = .... # First sequence ID to get
        state = None

        while True:

            # must not read data newer than the published sequence id
            # or we might end up reading partial data

            sleep = True
            if state is None:
                state = repserv.get_state_info()
            if state is not None and seqid <= state.sequence:
                try:
                    diffdata = repserv.get_diff_block(seqid)
                except:
                    diffdata = ''

                # We assume there are no empty diff files
                if len(diffdata) > 0:
                    self.apply_buffer(diffdata, repserv.diff_type, locations=True, idx=self.get_index_string())
                    seqid += 1
                    sleep = False

            if state is not None and seqid > state.sequence:
                state = None # Refresh state

            if sleep:
                time.sleep(60)


[BACKLOG-14138] use square icon in spoon

Build Completed
:white_check_mark: This pull request has passed all validations.
Build Commands
ant -Dtestreports.dir=bin/reports/unit-test -f ui/build.xml clean-all resolve jacoco && ant -Dtestreports.dir=bin/reports/integration-test -f ui/build.xml jacoco-integration checkstyle publish-local

Cleanup Commands
rm -r ~/.ivy2/local || echo no publish local to remove

Changed files
  ui/src/org/pentaho/di/ui/spoon/Spoon.java

Unit test coverage change
These statistics help you identify how your changes have affected the coverage of the following files. If a file is not in this list, then its coverage was not affected by your changes. To get some help interpreting these metrics, please refer to Jacoco's documentation.
org.pentaho.di.ui.spoon.Spoon

Instruction Change:  + .00%
Line Change:  + .00%

@bmorrise @mdamour1976 please review


Provide correct parameters to ERC 1155 bridge actions

Map token action
This PR fixes the issue in map token action for ERC 1155. The problem was that ChildERC1155Predicate expected data in the following format:
abi.encode(bytes32 sig, address rootToken, string name, string uri)

whereas RootERC1155Predicate was sending data in the following format (basically name and uri parameters were missing):
abi.encode(bytes32 sig, address rootToken)

NOTES:

Also for some reason, uri function expects token id as a parameter, although the default ERC1155 implementation does not utilize that parameter, but returns a single URI it holds. Therefore I just hardcoded token id value to 1.

Batch withdrawal action
Batch withdrawal also contained non-aligned parameters on the root chain vs the child chain predicates.
ChildERC1155Predicate was sending data in incorrect format (amounts were omitted):
abi.encode(bytes32 sig, address rootToken, address sender, address[] receivers, uint256[] tokenIds)

whereas RootERC1155Predicate was expecting the correct data:
abi.encode(bytes32 sig, address rootToken, address sender, address[] receivers, uint256[] tokenIds, uint256[] amounts)

Closing this in favour of #208 Some minor changes and error-handling issues have been resolved.