add blog for how to speed up pod startup from kubelet side

This blog post discusses methods to speed up pod start-up from the kubelet side, including

enabling parallel image pulls, setting a limit on the number of parallel image pulls at the node level (Limit added in v1.27)
increasing default API QPS limits for Kubelet(bump in v1.27)
using Evented PLEG. (to beta in v1.27)
pod resource limit (most likely the CPU limit will influence it; BTW we changed the throttling factor for cgroup v2 memory, if pod uses a lot of memory during startup, this may be a possible factor)

It also involves the metrics/log of pod startup SLO/SLI.
Other factors that may impact pod startup include container runtime, disk speed, CPU and memory resources on the node.
/cc @ruiwen-zhao @SergeyKanzhelev @harche @wojtek-t

Thanks for the effort!
/lgtm

@SergeyKanzhelev
I add another factor that is also changed in v1.27.

pod resource limit (most likely the CPU limit will influence it; BTW we changed the throttling factor for cgroup v2 memory, if pod uses a lot of memory during startup, this may be a possible factor)

The SELinux Relabeling with Mount Options feature moved to Beta in v1.27. This feature speeds up container startup by mounting volumes with the correct SELInux label instead of changing each file on the volumes recursively.
https://github.com/kubernetes/kubernetes/pull/116425
@jsafrane I think this feature also helped speed up pod startup.
I will add this in the end of the blog later.

Updated.

LGTM from docs perspective.

/hold
pending assignment of a publication date

I change the publication date to 2023-04-11 as the title changed to 1.27 updates on speeding up Pod startup.

/hold
pending assignment of a publication date

I changed to date to 04-14. Is this OK?

/assign @ruiwen-zhao @SergeyKanzhelev @sftim

/lgtm
And since 1.27 is released now, this blog should be ready to be published. Thanks for all the effort Paco!

/lgtm cancel

I don't think this article was one that the release comms team are tracking.
We should try to involve that team in planning articles that are linked to a release. Please say Hi in #release-comms on Kubernetes Slack and discuss a way forward. If you've already got in contact there, could you have one more go?
I like the ambition to cover more than one KEP in a single article; that's what readers will want. However, I can see that two KEPS covered here already have announcement articles signed off.

Thanks for the information. I will check with #release-commons

Hello, The publication date for this article is 15-05-2023 (May 15).
Thank you!

Nice. Then I can follow it asap after the kubecon.

Hello, The publication date for this article is 15-05-2023 (May 15).

The date is updated.

/lgtm

/lgtm

/hold cancel
/approve


Testimonial page is needed

Testimonial page is needed for the website for the Smooth work of the page (Testimonial.html)

hi @AFEEF12345 , please assign this to me

Already Completed


Article tags

Please make tags reusable (you probably were going to do that) and embed them in the meta-data of the page, so search engines can also read them! :)

Sounds good, thanks for the suggestion! =)

It's unlikely this will be implemented in Alpha 1, so moving this to Alpha 2 instead.


Use faster version of ed25619 library

A bunch of the ed25519 stuff was dramatically improved for performance with these changes (unsure of original source, might be good to track down for licensing reasons):
https://raw.githubusercontent.com/warner/git-lockup/575b4beae8797fee4c7daa07a5ce0e33667b3c1f/src/ed25519.py
This gives what seems to be a 10x increase in performance for my machine in generating a new monero address using python code.

Another version with the speed improvements can be found here:
https://github.com/warner/python-pure25519/blob/master/misc/djbec.py

Thanks! I'm definitely aware of these improvements, and have been considering implementing them. Long term, I think the best thing to do will ultimately be using the same C++ libraries as the core Monero code, since they are built to resist timing attacks. But as long as I'm using a python implementation, I might as well use the fastest one, huh?


webpack error

UnoCSS version
0.53.1
Describe the bug
This problem can occur at any time when import css file or modify some configuration, it seems to be no trace
TypeError: Cannot read properties of undefined (reading 'unocss:webpack')
    at Object.transform (E:\app\node_modules\.pnpm\unplugin@1.3.1\node_modules\unplugin\dist\webpack\loaders\transform.js:89:50)
    at LOADER_EXECUTION (E:\app\node_modules\.pnpm\loader-runner@4.3.0\node_modules\loader-runner\lib\LoaderRunner.js:132:14)
    at runSyncOrAsync (E:\app\node_modules\.pnpm\loader-runner@4.3.0\node_modules\loader-runner\lib\LoaderRunner.js:133:4)
    at iterateNormalLoaders (E:\app\node_modules\.pnpm\loader-runner@4.3.0\node_modules\loader-runner\lib\LoaderRunner.js:251:2)
    at E:\app\node_modules\.pnpm\loader-runner@4.3.0\node_modules\loader-runner\lib\LoaderRunner.js:224:4
    at FSReqCallback.readFileAfterClose [as oncomplete] (node:internal/fs/read_file_context:68:3)

Reproduction
~
System Info
win11
webpack 5.87.0
@unocss/webpack : 0.53.1,
Validations

[X] Read the Contributing Guidelines.
[X] Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
[X] Check that this is a concrete bug. For Q&A open a GitHub Discussion or join our Discord Chat Server.
[X] The provided reproduction is a minimal reproducible example of the bug.

i has a same problem

would u use thread-loader in webpack?

would u use thread-loader in webpack? i have same question after useing thread-lodaer.

yes, the same problem occurred if using thread-loader

您会在 webpack 中使用 thread-loader 吗？使用 thread-lodaer 后，我也有同样的问题。

相同问题，去除thread-loader可以


docs: code layout map

Added a map of the codebase to layout.md
The image source is a GraphML file generated in yEd but renderable by any graphml compatible editor.
The layout has been updated to include the storage refactor.

The graphml source and rendered version could be moved to the assets folder if desired, but I left them close to the relevant documentation.

hey @igaray just checking in! any plans to break this down in smaller diagrams / mermaid etc., or should we assign someone else? I think @0xKitsune might be interested. thanks for putting in the initial work!!

I think @0xKitsune might be interested. thanks for putting in the initial work but yeah things are prob gonna change a bunch and i'd prefer we start pushing for mermaid diagrams in line with the code...lmk!

If it is up for grabs, I would be happy to jump on it. I am looking at the next part of the docs to work on. At the moment, I'm just finishing up ramping on some materials related to the P2P protocol.

I'd say go for it unless @igaray responds by the time you're done 🙏

Heyo o/ end of year was pretty crazy, I'll have a much more time now for all of this.
I agree with everything @mattsse said, in fact I wish these diagrams could be autogenerated but that's just the world we live in.
I'll start with one and we'll see how it goes, and for now I'll close this PR.
Thanks for the feedback!

I'll start with one and we'll see how it goes, and for now I'll close this PR.

Give Mermaid a try!
https://github.com/paradigmxyz/reth/blob/346d50ebf4e32610fbf966b96ed4a8462ee15971/crates/net/network/src/fetch/client.rs#L22


erro: scores, dt_box_lidar, types, pred_dict = proc_1.run(np_p, frame)

length of proc_1.run(np_p, frame) is 10 :

how should I modify, thanks~

Hi @mendoza-G ！We are grateful for your efforts in helping improve this open-source project during your personal time.
Welcome to join OpenMMLab Special Interest Group (SIG) private channel on Discord, where you can share your experiences, ideas, and build connections with like-minded peers. To join the SIG channel, simply message moderator— OpenMMLab on Discord or briefly share your open-source contributions in the #introductions channel and we will assist you. Look forward to seeing you there! Join us ：https://discord.gg/UjgXkPWNqA
If you have a WeChat account，welcome to join our community on WeChat. You can add our assistant ：openmmlabwx. Please add "mmsig + Github ID" as a remark when adding friends：）
Thank you again for your contribution❤


Produce message to all partitions

Description
I have multiple consumers (same group) consumming on a topic with mutiple partitions.
I'm in a model like request/reply, one consumer trigger a request and each consumers receive a separate set of messages.
At the end of request, the producer is sending an EndOfRequest message, problem is only one consumer will get this message.
I would like to know what is the appropiate way to allow all consumers receive the EndOfRequest message.
Can a producer send one message to all available partitions on a topic ??
note: kafka native EOF handler can not be used as multiple requests could be processed at the same time so even if a request is done the partition could be not empty.
Checklist
Please provide the following information:

[ ] A complete (i.e. we can run it), minimal program demonstrating the problem. No need to supply a project file.
[latest ] Confluent.Kafka nuget version.
[ ] Apache Kafka version.
[ ] Client configuration.
[ linux/windows] Operating system.
[ ] Provide logs (with "debug" : "..." as necessary in configuration).
[ ] Provide broker log excerpts.
[ ] Critical issue.

I would like to know what is the appropiate way to allow all consumers receive the EndOfRequest message.

i'm not completely following your requirements, but this may be a case where the ability of the consumer to override the partitions assigned to it by the group may be useful. In the assign / revoke handlers, you can return the actual set of partitions that should be assigned to be read from, and this may be different from the set assigned to you by the group (note: the java client doesn't allow you to do this). You can adjust the sets to always include a particular 'control' partition (may be a separate topic). but note that ordering guarantees are per-partition only.
you could also maybe write a message to every partition, not just one of them (you can produce explicitly to a topic/partition using Produce or ProduceAsync). you can determine how many partitions a topic has on the fly using AdminClient.GetMetadata.

Which version would you recommend that allows message partition assignment in the producer?   I am still using 1.0.0-beta and sending such messages via:
var drb = KafkaProducer.ProduceAsync(mypartition, msg);
drb.ContinueWith(task =>{})
1.0.0-beta has been working great but noticed we lost message partition assignments in later builds.  Thanks!


docs: Update return type

Pull Request Test Coverage Report for Build<PHONE_NUMBER>
Details

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 99.286%

Totals

Change from base Build<PHONE_NUMBER>:
0.0%

Covered Lines:
139

Relevant Lines:
140

💛  - Coveralls


Implement :On error [exit | ignore] command

go-sqlcmd currently does not have support for :on error command.
:On Error[ exit | ignore]
Sets the action to be performed when an error occurs during script or batch execution.
When the exit option is used, sqlcmd exits with the appropriate error value.
When the ignore option is used, sqlcmd ignores the error and continues executing the batch or script. By default, an error message is printed.

Can be closed as #166 #181 #192 addressed this.


Issue with Docker Build on MACOS

Docker build is erroring out with the following error:
" **_****> [builder 3/3] RUN ./build.sh:
#0 0.099 /juno
#0 0.102 qemu-x86_64: Could not open '/lib64/ld-linux-x86-64.so.2': No such file or directory
Dockerfile:35
33 |     COPY /build.sh /build.sh
34 |
35 | >>> RUN ./build.sh
36 |

37

ERROR: failed to solve: process "/bin/sh -c ./build.sh" did not complete successfully: exit code: 255"

make: *** [build] Error 1****_**

Please suggest any resolution. Docker version is 24.0.2.
Thanks
Abhishek Mittal
Detailed log below
cd /Users/I589015/go-dev-juno/junodb/docker/build/src/juno; echo git rev-parse --short=8 HEAD 2> /dev/null >> /Users/I589015/go-dev-juno/junodb/docker/build/src/juno/git_revision.txt ;
if [ -f /Users/I589015/go-dev-juno/junodb/docker/build/src/juno/third_party/apply_patch.sh ]; then /Users/I589015/go-dev-juno/junodb/docker/build/src/juno/third_party/apply_patch.sh ; fi ;
Cloning into 'rocksdb'...
remote: Enumerating objects: 122556, done.
remote: Counting objects: 100% (607/607), done.
remote: Compressing objects: 100% (400/400), done.
remote: Total 122556 (delta 292), reused 376 (delta 172), pack-reused 121949
Receiving objects: 100% (122556/122556), 201.69 MiB | 300.00 KiB/s, done.
Resolving deltas: 100% (93758/93758), done.
Note: switching to '72cf57d4b40e5c809839afc1c62dc13e533b8ec6'.
You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by switching back to a branch.
If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -c with the switch command. Example:
git switch -c
Or undo this operation with:
git switch -
Turn off this advice by setting config variable advice.detachedHead to false
Cloning into 'forked/tecbot/gorocksdb'...
remote: Enumerating objects: 928, done.
remote: Total 928 (delta 0), reused 0 (delta 0), pack-reused 928
Receiving objects: 100% (928/928), 379.25 KiB | 1016.00 KiB/s, done.
Resolving deltas: 100% (573/573), done.
Note: switching to '57a309fefefb9c03d6dcc11a0e5705fc4711b46d'.
You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by switching back to a branch.
If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -c with the switch command. Example:
git switch -c
Or undo this operation with:
git switch -
Turn off this advice by setting config variable advice.detachedHead to false
HEAD is now at 57a309f Merge pull request #106 from JelteF/patch-1
wget --no-check-certificate https://dl.google.com/go/go1.18.2.linux-amd64.tar.gz -O /Users/I589015/go-dev-juno/junodb/docker/build/go1.18.2.linux-amd64.tar.gz ;
--2023-07-09 19:50:22--  https://dl.google.com/go/go1.18.2.linux-amd64.tar.gz
Resolving dl.google.com (dl.google.com)... <IP_ADDRESS>
Connecting to dl.google.com (dl.google.com)|<IP_ADDRESS>|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 141732542 (135M) [application/x-gzip]
Saving to: ‘/Users/I589015/go-dev-juno/junodb/docker/build/go1.18.2.linux-amd64.tar.gz’
/Users/I589015/go-dev-juno/junodb/docke 100%[===============================================================================>] 135.17M  11.0MB/s    in 13s
2023-07-09 19:50:35 (10.8 MB/s) - ‘/Users/I589015/go-dev-juno/junodb/docker/build/go1.18.2.linux-amd64.tar.gz’ saved [141732542/141732542]
TODO --
cd build && docker build --build-arg GOLANG_VERSION=1.18.2 --tag
ghcr.io/paypal/junodb/juno-dev:latest --target juno-dev .
[+] Building 4.3s (15/15) FINISHED
=> [internal] load build definition from Dockerfile                                                                                0.0s
=> => transferring dockerfile: 858B                                                                                0.0s
=> [internal] load .dockerignore                                                                                0.0s
=> => transferring context: 2B                                                                                0.0s
=> [internal] load metadata for docker.io/library/ubuntu:20.04                                                                                3.4s
=> [auth] library/ubuntu:pull token for registry-1.docker.io                                                                                0.0s
=> [juno-base 1/4] FROM docker.io/library/ubuntu:20.04@sha256:c9820a44b950956a790c354700c1166a7ec648bc0d215fa438d3a339812f1d01                            0.0s
=> [internal] load build context                                                                                0.8s
=> => transferring context: 13.63MB                                                                                0.8s
=> CACHED [juno-base 2/4] RUN apt-get update && DEBIAN_FRONTEND=noninteractive apt-get -qq install -y  cmake  g++  make  wget                             0.0s
=> CACHED [juno-base 3/4] COPY /go1.18.2.linux-amd64.tar.gz /                                                                                0.0s
=> CACHED [juno-base 4/4] RUN tar xzvf go1.18.2.linux-amd64.tar.gz -C /usr/local/                                                                         0.0s
=> CACHED [juno-dev-base 1/4] COPY /src/juno/third_party/rocksdb /vendor/src/rocksdb                                                                      0.0s
=> CACHED [juno-dev-base 2/4] WORKDIR /vendor/src/rocksdb                                                                                0.0s
=> CACHED [juno-dev-base 3/4] RUN make static_lib; make INSTALL_PATH=/vendor/rocksdb install-static                                                       0.0s
=> CACHED [juno-dev 1/2] COPY --from=juno-dev-base /vendor/rocksdb/include /usr/local/include                                                             0.0s
=> CACHED [juno-dev 2/2] COPY --from=juno-dev-base /vendor/rocksdb/lib /usr/local/lib                                                                     0.0s
=> exporting to image                                                                                0.0s
=> => exporting layers                                                                                0.0s
=> => writing image sha256:3c85febcc62fd66fd243fbb12a22a1123ae9ddd88a7cb5546f68da9452891a83                                                               0.0s
=> => naming to ghcr.io/paypal/junodb/juno-dev:latest                                                                                0.0s
cd build && docker build --build-arg GOLANG_VERSION=1.18.2 --tag
ghcr.io/paypal/junodb/juno-build:latest --target builder .
[+] Building 1.9s (16/16) FINISHED
=> [internal] load .dockerignore                                                                                0.0s
=> => transferring context: 2B                                                                                0.0s
=> [internal] load build definition from Dockerfile                                                                                0.0s
=> => transferring dockerfile: 858B                                                                                0.0s
=> [internal] load metadata for docker.io/library/ubuntu:20.04                                                                                0.5s
=> [juno-base 1/4] FROM docker.io/library/ubuntu:20.04@sha256:c9820a44b950956a790c354700c1166a7ec648bc0d215fa438d3a339812f1d01                            0.0s
=> [internal] load build context                                                                                0.9s
=> => transferring context: 63.02MB                                                                                0.9s
=> CACHED [juno-base 2/4] RUN apt-get update && DEBIAN_FRONTEND=noninteractive apt-get -qq install -y  cmake  g++  make  wget                             0.0s
=> CACHED [juno-base 3/4] COPY /go1.18.2.linux-amd64.tar.gz /                                                                                0.0s
=> CACHED [juno-base 4/4] RUN tar xzvf go1.18.2.linux-amd64.tar.gz -C /usr/local/                                                                         0.0s
=> CACHED [juno-dev-base 1/4] COPY /src/juno/third_party/rocksdb /vendor/src/rocksdb                                                                      0.0s
=> CACHED [juno-dev-base 2/4] WORKDIR /vendor/src/rocksdb                                                                                0.0s
=> CACHED [juno-dev-base 3/4] RUN make static_lib; make INSTALL_PATH=/vendor/rocksdb install-static                                                       0.0s
=> CACHED [juno-dev 1/2] COPY --from=juno-dev-base /vendor/rocksdb/include /usr/local/include                                                             0.0s
=> CACHED [juno-dev 2/2] COPY --from=juno-dev-base /vendor/rocksdb/lib /usr/local/lib                                                                     0.0s
=> [builder 1/3] COPY /src/juno /juno                                                                                0.3s
=> [builder 2/3] COPY /build.sh /build.sh                                                                                0.0s
=> ERROR [builder 3/3] RUN ./build.sh                                                                                0.1s

[builder 3/3] RUN ./build.sh:
#0 0.099 /juno
#0 0.102 qemu-x86_64: Could not open '/lib64/ld-linux-x86-64.so.2': No such file or directory

Dockerfile:35
33 |     COPY /build.sh /build.sh
34 |
35 | >>> RUN ./build.sh
36 |

37

ERROR: failed to solve: process "/bin/sh -c ./build.sh" did not complete successfully: exit code: 255

make: *** [build] Error 1

Hi @abhishek0909, I'm using macOS and I'm able to successfully set up and run JunoDB, I mentioned in my blog post you can check it here https://amustaque97.github.io/run-junodb-on-macos/

Hi @abhishek0909 were you able to figure out?

Solution to Could not open '/lib64/ld-linux-x86-64.so.2': No such file or directory
The main problem was that /lib64/ld-linux-x86-64.so.2 was not supplied with the default image and it would create problems when running it on M1 Apple chip.
I was able to fix it by adding --platform=linux/amd64 in junodb/docker/build/Dockerfile and my build was successful.


Fsnotify on hooks path

Description
Currently hooks are loaded at startup, which means that when someone places a hook inside the hook directory, they need to restart CRI-O.
Adding a hook after CRI-O starts is something that will happen when paired with the Kubernetes device plugin feature.
The device plugin is a daemonset deployed by the cluster administrator at any time during the cluster lifecycle that is expected to:

install drivers (e.g: NVIDIA drivers)
Detect and report devices to the Kubelet (e.g: NVIDIA GPUs)
Add additional runtime parameters to the CRI spec to advertise the device in the container

Currently the CRI spec doesn't support pre-start hook so we are going through annotations and CRI-O hooks.
As restarting CRI-O is a pretty disruptive behavior, it would be better if the hooks could be reloaded when a new one gets added to the hooks directories.

We can certainly look into this but I also want to understand more about the issues cri-o arises when it restarts, could you open more issues? :)

We can certainly look into this but I also want to understand more about the issues cri-o arises when it restarts, could you open more issues? :)

No issues arises when restarting CRI-O, we're just not really comfortable asking our user to restart CRI-O manually or requesting the permissions for our container to do it programatically.
It's also a bit complicated to have a reliable way to restart programatically CRI-O

That makes total sense, I thought there were issues when restarting it, Nevermind then

Sounds good! @RenaudWasTaken any chance you could work on that?

I can test it but I can't work on it, I've started the process internally to contribute to CRI-O but it usually takes a few weeks :(


Intermittent failure: RuntimeError: InternalServerError: TypeError: 'NoneType' object is not subscriptable

When I run a simple regression or classification test, I get the error:
RuntimeError: InternalServerError: TypeError: 'NoneType' object is not subscriptable
This happens roughly half the time. If I run the same task again, it often completes just fine or sometimes fails with the above error.
Happy to help you debug this if need be.

We'll be onto it. If you could help show an example, that would be great!

Here is some code that will reproduce the issue. I also attached a zip file with the data in it. You will need to unzip the file and put it beside this script. Good luck!
from tabpfn_client import set_access_token, TabPFNClassifier, TabPFNRegressor
from sklearn.metrics import mean_absolute_error, accuracy_score
import numpy as np
import pickle
token = 'your token here'
def main():
set_access_token(token)
with open('data.pkl', 'rb') as f:
    data = pickle.load(f)

# regress column 11
regressor = TabPFNRegressor()
regressor.fit(
    np.ascontiguousarray(data['x_train'][:, 0 : 11]),
    np.ascontiguousarray(data['x_train'][:, 11])
)
predictions1 = regressor.predict_full(np.ascontiguousarray(data['x_test'][:, 0 : 11]))
mae_1 = mean_absolute_error(np.ascontiguousarray(data['x_test'][:, 11]), predictions1['median'])
print("MAE = {}".format(mae_1))

# need to put the regression predictions into x_test
data['x_test'][:, 11] = predictions1['median']
data['xtest'] = np.ascontiguousarray(data['x_test'])

# classify the y column
classifier = TabPFNClassifier()
classifier.fit(data['x_train'], data['y_train'])
probabilities = classifier.predict_proba(data['x_test'])
predictions_2 = np.argmax(probabilities, axis=-1)
accuracy_1 = accuracy_score(data['y_test'], predictions_2 + 3)
print("Accuracy = {}".format(accuracy_1))

if name == 'main':
main()
data.zip

Thanks a lot, we'll keep you up to date!

@jfb54 thanks a lot for reporting the error and for the detailed code to reproduce it! It should be fixed now :)


Preprocessed Table does not exist in the database

While predicting, after running the specified instructions, Preprocessed tables have not been created in the database.

Issue was occurring due to the data_collection script not running fully


Implement a full Wechaty interface with HA

The Goal
class HAWechaty implements Wechaty {
  // ...
}

Full-API: HAWechaty will have all the API interface that Wechaty has
Deduplicate: HAWechaty will deduplicate the received message when more than one bot receive one same message
Round Robin Load Balancing: HAWechaty will pick one available bot to send messages

Related issues

#10

Back working on this...

 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.Huan (李卓桓) seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.You have signed the CLA already but the status is still pending? Let us recheck it.


Use ThreadWorkPool instead of thread_process_array in NavMap [3.x]

3.x PR of #60359
Finally, porting PR #60359 to 3.x was easier than anticipated. All because core/templates/thread_work_pool.{h, cpp} was easily ported (only required some copy and paste).
Note. This PR seems to work, but I do not know if I broke some rules, as core/templates didn't already exist.
As a benchmark, I used the minimal reproduction project of issue #56838 made by thoced.
NavigationAgentTest.zip
Godot 3.x [master] (using thread_process_array), first minute, VSYNC disabled (Windows 10)

Godot 3.x [master] (using ThreadWorkPool), first minute, VSYNC disabled (Windows 10)

As the addition of the new template, this pretty much confirms that a simple cherry-pick of #60359 wouldn't work for 3.x
Along with PR #60359, fixes #56838. But this needs testing.

Please add thread_work_pool.h in core/os/ with the other Thread related functionality in 3.x, instead of a templates. The core structure changed in master but for 3.x we should keep the pre-existing structure.

Please add thread_work_pool.h in core/os/ with the other Thread related functionality in 3.x, instead of a templates. The core structure changed in master but for 3.x we should keep the pre-existing structure.

I moved the files as asked! Thanks!


add-amount-to-notification

Lots of users mentioned it would be nice to see the amount in the basic transfer notification when someone sends you bitclout. Im finding this too. So I added this small change which shows the transferred bitclout in the notification.

This does not handle UTXO transactions so cant get actual amount in all circumstances


[GOCA] Migrate from glide to Go Modules

Description
The GOCA library should use the official Go modules functionality to manage dependencies instead of Glide.
Use case
Using Go modules enables better tool and system integration. https://github.com/golang/go/wiki/Modules
Interface Changes
N/A
Additional Context
go mod init supports automatic migration of glide managed dependencies.

Progress Status

[ ] Branch created
[ ] Code committed to development branch
[ ] Testing - QA
[ ] Documentation
[ ] Release notes - resolved issues, compatibility, known issues
[ ] Code committed to upstream release/hotfix branches
[ ] Documentation committed to upstream release/hotfix branches

Note to the reviewer, it needs at least the version 1.11 of Go


Add richer information to pull request messages

It would be very helpful to include richer info in the Slack messages generated for pull request activity, including source/destination projects and branches, reviewers, etc.
I will have a pull request with changes up later today.

Thanks!


Perpendicular: angle instead of reverse

Currently, we have a reverse prop on Perpendicular which rotates the component by 180 degrees. We should rename that prop to angle and accept a number so it'll be consistent with the angle prop on Arrow:
https://github.com/diegohaz/reakit/blob/4523918e64ee73ab5c9b87deb08b29eddd9af95c/src/components/Arrow/Arrow.js#L39-L45
reverse is used by two other components: PopoverArrow and TooltipArrow. These are the lines that should be updated:
https://github.com/diegohaz/reakit/blob/4523918e64ee73ab5c9b87deb08b29eddd9af95c/src/components/Perpendicular/Perpendicular.js#L24-L26
https://github.com/diegohaz/reakit/blob/4523918e64ee73ab5c9b87deb08b29eddd9af95c/src/components/Perpendicular/Perpendicular.js#L54-L66
https://github.com/diegohaz/reakit/blob/4523918e64ee73ab5c9b87deb08b29eddd9af95c/src/components/Popover/PopoverArrow.js#L18-L24
https://github.com/diegohaz/reakit/blob/4523918e64ee73ab5c9b87deb08b29eddd9af95c/src/components/Tooltip/TooltipArrow.js#L17-L23
A PR is very welcome. Since it's a breaking change, the PR should be sent to the next branch.

I'm not sure if this is the right place for it, but the Popover.Arrow docs (https://reakit.io/components/popover/popoverarrow) already refer to the prop angle, but the pos string is actually the prop that modifies the behaviour of the component. Using angle does nothing.

Yes, @Moeface. That's one of the things this solution will fix. Currently, Perpendicular is overriding angle.


allow column options to override defaults

Proposed changes
Allows the user to override column options on the attachment decorator. Related to this issue: https://github.com/adonisjs/attachment-lite/issues/21
Types of changes
What types of changes does your code introduce?
Put an x in the boxes that apply

[ ] Bugfix (non-breaking change which fixes an issue)
[X] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)

Checklist
Put an x in the boxes that apply. You can also fill these out after creating the PR. If you're unsure about any of them, don't hesitate to ask. We're here to help! This is simply a reminder of what we are going to look for before merging your code.

[X] I have read the CONTRIBUTING doc
[X] Lint and unit tests pass locally with my changes
[ ] I have added tests that prove my fix is effective or that my feature works.
[X] I have added necessary documentation (if appropriate)

Further comments
If this is a relatively large or complex change, kick off the discussion by explaining why you chose the solution you did and what alternatives you considered, etc...

@thetutlage can we release a new version with this change?

Released as 1.0.8


search for traces by a service's duration

Would be nice to be able to sort traces by the searched service's duration and not the duration of the entire trace.

Closing due to lack of activity.


F OpenNebula/one-aiops#70: opennebula backend basic skeleton

Developer's Certificate of Origin 1.1
   By making a contribution to this project, I certify that:

   (a) The contribution was created in whole or in part by me and I
       have the right to submit it under the Apache License 2.0; or

   (b) The contribution is based upon previous work that, to the best
       of my knowledge, is covered under an appropriate open source
       license and I have the right under that license to submit that
       work with modifications, whether created in whole or in part
       by me, under the same open source license (unless I am
       permitted to submit under a different license), as indicated
       in the file; or

   (c) The contribution was provided directly to me by some other
       person who certified (a), (b) or (c) and I have not modified
       it.

   (d) I understand and agree that this project and the contribution
       are public and that a record of the contribution (including all
       personal information I submit with it, including my sign-off) is
       maintained indefinitely and may be redistributed consistent with
       this project or the open source license(s) involved.

We closed the PR because it was made in error. We are currently addressing the issue in our fork repository [https://github.com/OpenNebula/lithops]. We apologize for any confusion this may have caused.


import material-ui-interactors as @interactors/material-ui

It can be imported at version 4.

Just leaving this here as a reminder to myself.
I'm currently finishing up the rough draft to introduce mui in the interactors docs in this PR. When we move material-ui-interactors into this repository, we should remember to update the docs too.

We skipped this step.


Comment Code

So one of the most important aspects of writing code in a community is commenting it well. Basic commenting has a top priority if it is necessary so other developers understand what you're doing. In our case, since it is a beginner project - right now we are three people but I hope we'll find some more - I would like us to comment code in-depth so people understand what you're doing. That doesn't mean that you have to explain how syntax and code and languages work. We aren't making a tutorial. However, it means that

On the top of a file we should explain what the file is supposed to do
On the top of a function or class we should explain what the function / class does and what the function arguments mean and what arguments are required
important: the variable and function names should be self-explanatory
Any line or block whose meaning isn't easily discernible should be commented. You don't need to explain in detail how it works, just what it is supposed to do.

Again, you don't need to explain basic syntax or anything.
Do you agree that we should comment this way?
By the way, I didn't understand something myself, namely what the file .styleintrc does. I couldn't find an explanation on google. Is the file name correct? And I was going to ask what that file does (as I said I'm a beginner too :D but maybe you could just answer that in a comment in the file so that everyone can see it right away. :)
If you agree to the commenting suggestion then I will add them to the contributing guidelines. Also, we start to write code in other branches than main and the good commenting will be one of the requirements that is checked by someone else than the author before merging.

I think that coding is like writing. @Aliin, did you read Clean Code book?

I will add this to the CONTRIBUTING.md file.

Good.


Update README.md

Unirest shouldnt be linked if JDA uses OkHttp should it?

Please instead comment on the Pull Request #349


Fix handling of trailing comma in SpaceAfterComma and SpaceAroundBlockParameters

Both Style/SpaceAfterComma and Style/SpaceAroundBlockParameters
failed to properly handle a comma after the last item.
Together the bugs caused an infinite loop when auto-correcting.
Perhaps there should be a new cop for the trailing comma.

Your solution seems good to me. @jonas054 What do you think?

That looks good! :+1:

@lumeet You'll need to rebase.

Rebased.

:+1: Thanks!


Add Webpack 5 compatibility

In webpack 5:

libraryTarget is replaced by library.type
optimizeChunkAssets is deprecated in favour of processAssets

This commit check the version of webpack.
If the version is lower than 5, it uses the old way
and if the version is equal or more than 5, it uses
the new way.

Can you upgrade the webpack dev dependency?

I'm using your plugin in my project called Graceful Server
(aka https://github.com/gquittet/graceful-server)
and it's just super cool ! 🚀
Great job ! 💪

Thanks for the good PR :)

You're welcome !
Thank you too for your great work ! 👍


cdn variables

Hello people,
how to mod variables with cdn best?
Kind regards,
vasihasi

@vasihasi You cant do that, all you can do is to compile your own sass files and overwrite them.

Sorry, but we cannot help with how-to or general troubleshooting issues here; only bug reports and feature requests. You'll want to ask around in the official Slack team or Stack Overflow. See our readme for more details.


nix-optimise doesn't run in a container of any host

Issue description
Since #48098, the nix-optimise service contains a ConditionVirtualization attribute that prevents the service from running inside a containerized installation of NixOS. The rationale for this change, as stated, is that nix-optimise should run on a NixOS host and not its containers. However, the ConditionVirtualization restriction is too broad, as it disables nix-optimize even when running inside a non-NixOS host. Containerization is, after all, an increasingly popular way of sampling less-mainstream Linux distros from inside a more familiar host, and as such NixOS features shouldn't assume that they're being hosted by NixOS whenever they're running in a container.
Is testing the host OS from a module possible? Wrapping the ConditionVirtualization in a mkIf that does that would satisfy me (just as one example solution—so would other hypothetical solutions that let nix-optimise run under non-NixOS hosts).
Steps to reproduce

Install NixOS as a container in a non-NixOS host (see #9884 for tips)
Set nix.optimise.automatic = true; in configuration.nix
See that nix-optimise doesn't run (systemctl status nix-optimise)

Workaround
It's a hack, but: systemd.services.nix-optimise.unitConfig.ConditionVirtualization = pkgs.lib.mkForce null; will do the trick. (This does still leave an awkward ConditionVirtualization= empty entry in the resulting service file, if you bother to check with systemctl cat nix-optimise... not that it really matters, as far as I can tell, but mkUnset from #63553 would be cleaner than mkForce null.)
Technical details
 - system: `"x86_64-linux"`
 - host os: `Linux 5.1.5-arch1-2-ARCH, NixOS, 19.03.172927.30a82bba734 (Koi)`
 - multi-user?: `yes`
 - sandbox: `yes`
 - version: `nix-env (Nix) 2.2.2`
 - channels(root): `"nixos-19.03.172927.30a82bba734, nixos-unstable-19.09pre173349.07b42ccf2de"`
 - nixpkgs: `/nix/var/nix/profiles/per-user/root/channels/nixos`

Isn't the whole idea of containers, that they don't change? Having something change during runtime seems like a terrible idea. If you want to dedup, shouldn't that be done at the time of container creation?

Wow, that claim surprises me a lot! Maybe the whole point of containers as a devops deployment vehicle is that they don't change, but containers have other uses than that! I would say that their ‘whole idea’ is allowing software to run within a custom Linux environment that is isolated from the host, without the overhead of full machine virtualization. That environment doesn't have to be immutable.
I keep a long-running NixOS container on my dev machine, as a platform for running NixOps deployments and developing and testing Nix configurations to be pushed to servers. What would I get out of recreating that container every time I want to update its Nix store? As a container, there's so little overhead to keeping it running and managing itself; I just put my NixOps management timers in the container, enable system.autoUpgrade, and leave it up all the time. So yeah, it's a container that changes at run time, just like my dev machine changes at run time, just like most computers (that aren't ephemeral, single-app VMs) change at run time. What's so terrible about that, as long as everything in the container is still reproducible and transactional?

Fair enough - I suggest introducing a runInContainer option in the nix-optimise module (defaults to false) and setting the ConditionVirtualization based on that. A proper description that outlines the reasons for setting this to true would be great.

No, it shouldn't be an option. What matters here is whether the container has its own Nix store. It should be possible to detect this automatically (e.g. by looking at whether /nix/var/nix/daemon-socket is a read-only bind mount) and make nix-optimise conditional on that.
Or just add systemd.services.nix-optimise.enable = false to modules/virtualisation/container-config.nix (since that's the module for containers that share the host's Nix store).

Great idea. ```ConditionPathIsReadWrite = "/nix/var/nix/daemon-socket" should do the trick.

I like the idea of doing both—disabling nix-optimise in container-config.nix is the cleanest solution for the most common (?) case of NixOS containers in NixOS hosts, but making the service conditional on the writability of /nix/var/nix/daemon-socket also safeguards against less common cases like, say, a NixOS container running on a host that isn't NixOS but that does have a Nix store that it shares with the container.


Chapter 9: Streaming

In the Streaming a Component module, the import for
import { Suspense } from 'react';
import { RevenueChartSkeleton } from '@/app/ui/dashboard/skeletons';
supposed to be
import { Suspense } from 'react';
import { RevenueChartSkeleton } from '@/app/ui/skeletons';

Thank you @jasonaw98, updated. Should be landing soon.


OLS-1168: Ability to print current version to stdout

Description
OLS-1168: Ability to print current version to stdout
Type of change

[ ] Refactor
[x] New feature
[ ] Bug fix
[ ] CVE fix
[ ] Optimization
[x] Documentation Update
[ ] Configuration Update
[ ] Bump-up dependent library
[ ] Bump-up library or tool used for development (does not change the final image)
[ ] CI configuration change
[ ] Konflux configuration change

Related Tickets & Documents

Related Issue #OLS-1168

/test verify

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 96.95%. Comparing base (34b1c90) to head (c89e4df).
Report is 25 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #2016      +/-   ##
==========================================
- Coverage   96.95%   96.95%   -0.01%
==========================================
  Files          69       70       +1
  Lines        2891     2888       -3
==========================================
- Hits         2803     2800       -3
  Misses         88       88

/test unit

/test unit

/lgtm

/approve
/override "Red Hat Konflux / ols-enterprise-contract / lightspeed-service"


Default to native runner.

Closes https://github.com/rust-embedded/cross/issues/314.

I'd like to see this merged and potentially a new version released so I can use the latest version of cross in my CI. Any chance of a review, @jamesmunns?

bors r+


phone number validator

I couldnt find a phone number validator, or am I missing something?
e.g.
+49 175 88 777

For formatting you need to use Cleave or Masked.
For validation, you need to use the regexp validator or a custom one, sorry !
Phone validation is very complex and varies depending on countries.
I don't know if it is missing on purpose or not. @icebob ?

I think also the Cleave is cover this issue.

Well, if you put only half your number for example, will it trigger a validation error ?
I'm not sure require validator is enough.
We already have a creditCard validator, why not add a phone validator ? Or remove the creditCard validator and let people use their custom validator ?

I will add libphonenumber-js and google-libphonenumber in the meantime.
These are robust library built upon the work of Google.
You could do a pretty simple custom validator with this.
My opinion is that since now users have an easy way to add custom validator and that these kind of validation are complex, we should remove creditCard, url and email validators.
We could create dedicated repo for each of those, that rely on other specialized library.

On the other hand, creditCard, url and email validation is quite common, so maybe we should support the common case out-of-the-box?
At least for credit card validation, it's a de-facto global standard, fairly simple to support and requires no extra dependencies. It's very hard to formally, correctly, validate email addresses & urls, so our validators only do simple, common case validation of these.
The bundled validators also make good examples for people wanting to implement their own custom validators.
I'd be open to making things more modular, provided that it doesn't make it harder for people to get started - so no extra setup work for the user, etc...
Also, libphonenumber.js is 418 Kb... ?

I used the hammerzeit libphonenumber. It says it is only 75 Kb.
https://www.npmjs.com/package/libphonenumber-js
IMHO I would include phone as a validator. Quite common.

@obiwarn Maybe you could give us a hand an do a PR for that ?
That would be really nice of you to do that.
Check this file to get started.
Good luck !

I am doing this with regexp, a simple a pattern resolves to me.


Replace Legacy Clickhouse driver or return full support of Legacy version.

After this ticket we need to decide - do we need to replace the Legacy ClickHouse driver or return the previously supported version?
We need to test it on different server versions.

Will be implemented here: https://github.com/dbeaver/pro/issues/2404


Feat/transactions scanning optimization

Description

added check on userStorage is ready for useTransferEvents hook
added check on equality when comparing the last events block

About # (link your issue here)
https://app.zenhub.com/workspaces/gooddollar-5d50833888a83c6880d3e345/issues/gooddollar/gooddapp/3668
How Has This Been Tested?
Please describe the tests that you ran to verify your changes.
Checklist:

[ ] PR title matches follow: (Feature|Bug|Chore) Task Name
[ ] My code follows the style guidelines of this project
[ ] I have followed all the instructions described in the initial task (check Definitions of Done)
[ ] I have performed a self-review of my own code
[ ] My changes generate no new warnings
[ ] I have added tests that prove my fix is effective or that my feature works
[ ] New and existing unit tests pass locally with my changes
[ ] I have added reference to a related issue in the repository
[ ] I have added a detailed description of the changes proposed in the pull request. I am as descriptive as possible, assisting reviewers as much as possible.
[ ] I have added screenshots related to my pull request (for frontend tasks)
[ ] I have pasted a gif showing the feature.
[ ] @mentions of the person or team responsible for reviewing proposed changes

@alt-a1r How about the last point - "perform the rescan only when user app goes to background?"


Centeredlabels initial

#1670

I'm a little bit struggling with locating a correct place to land check if there's enough space for label.


GH bot that automatically posts the integration version Npm package name to PRs that start with integration/

https://github.com/prisma/prisma/pull/12897 is automatically published as<EMAIL_ADDRESS>We could surface this in a comment on the PR. (Useful code: https://github.com/prisma/docs/blob/main/.github/workflows/list-changed-pages.yml)

Hi there,
As part of our effort to clean up our GitHub repo, we’re closing this issue to help focus on features and improvements that align with our focus areas and those of our community.
This issue was originally created for internal tracking purposes, but if you feel this is important to you, feel free to reopen the issue and get like-minded users to upvote as we will prioritize fixing issues based on community interest.
For more insight into our priorities and how we’re thinking about the future of Prisma, please see our blog post: https://www.prisma.io/blog/prisma-orm-manifesto.
Thank you for your understanding and support!


feature: add moisture sensor

Contribution description
this is the implementation of the moisture sensor
Issues/PRs references
this PR fixes the issue #76

Ok man, do a squash and merge it


parallel graph match

Closes #300

What does this implement/fix? Explain your changes.
This PR includes parallelized graph match algorithm.
Any other comments?
The outputs of comparison between not parallelized and parallelized algorithms for running time and match ratio are as follows.
Parameters:
vertices: 99*99
initial times: 30
gmp: True
init_method: "rand"
seed number: [3, 8]
runs: 30 graphs / seed number

Reference Issues/PRs

Reference
[1] J.T. Vogelstein, J.M. Conroy, V. Lyzinski, L.J. Podrazik, S.G. Kratzer,
E.T. Harley, D.E. Fishkind, R.J. Vogelstein, and C.E. Priebe, “Fast
approximate quadratic programming for graph matching,” PLOS one, vol. 10,
no. 4, p. e0121002, 2015.
[2] D. Fishkind, S. Adali, H. Patsolic, L. Meng, D. Singh, V. Lyzinski, C. Priebe,
Seeded graph matching, Pattern Recognit. 87 (2019) 203–215

Codecov Report

Merging #341 into master will increase coverage by 0.02%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##           master     #341      +/-   ##
==========================================
+ Coverage   88.08%   88.11%   +0.02%
==========================================
  Files          41       41
  Lines        2635     2641       +6
==========================================
+ Hits         2321     2327       +6
  Misses        314      314

Impacted Files
Coverage Δ

graspy/match/gmp.py
95.77% <100.00%> (+0.18%)
:arrow_up:

Continue to review full report at Codecov.

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

also need at least one test showing that this works with n_jobs > 1. ideally, take one of the tests that already exists and just make it run in parallel, maybe just 2 inits

Hi Pedigo, for this issue, can I add parameters of "n_jobs=-1" and "par=True" for the init part in gmp.py? And then I can set "par=False" and "n_jobs = 5" for the test?

Thanks Shan, looks done to me! I have some other changes I'm making to GMP so I may wait a bit to merge but you are all good

Thanks for your help along the way!

closing for now because we are going to be refactoring the internals of GraphMatch, right @asaadeldin11? But may be able to use some of this to make that code parallel once we do?


feat(tools): sentry apm and other telemetry

This adds some tracing and other improvements to the sentry dashboard. For example, it was requested by one of the staff to understand things like TPS on a given endpoint, etc. Over all this will be nice to have since we often need better insights about the API.

That's a good question.
You should be able to just sign up for sentry and create a project (it's free), and use those keys to check this locally.
If you do not want to bother, I could do the same and add some screenshots if you prefer.


Better resolution of CDI / Blueprint and plugin transitive dependencies

Thanks for the PR its merged. Do you mind closing this


Reorder of child block

Hi!
We have a small problem here: If you only reorder the child blocks of a neo block and press save, the reorder is not saved and everything is in the same old order. But if you reorder the child blocks and change something within a child block, then the new order is saved. It seems, that the reordering of the child blocks without changing the content is not recognized as "change".
Regards,
Thomas

Reordering true Neo child blocks should always update when saving the entry. The structure for the field gets regenerated every time. When you're talking about child blocks, are you maybe referring to a Matrix or SuperTable field inside a Neo block?
Also, what browser/version are you using?

I'm going to close this issue, given its age and no other reports of the issue, but if you do continue to experience the issue, let us know and we'll reopen.


fix missing Val Season type

The enum no.stelar7.api.r4j.basic.constants.types.val.Season is missing the type "0981a882-4e7d-371a-70c4-c3b4f46c504a"!
Please make sure you have the latest version of the library!
If you do, send this message to the maintainer of the API.

Hey @stelar7, please take a look at the PR.
I wonder if SEASON_7 should be added too, but EPISODE_7_ACT_1 is the newest.

Hey! Thanks for the PR. I went ahead and added all the other acts too 👍


Setup Stephanie from HQ

Give access to NC Open Pass documents and social media accounts

@jhibbets or @zachambrose can you add Stephanie<EMAIL_ADDRESS>to the main NC Open Pass Google Group?

@zachambrose  - can you also give her access to the NC Open Pass Google Calendar

@jhibbets - can you invite Stephanie to the Slack channel

Stephanie should be onboarded (mailing list, invite to GitHub, invite to Slack, and access to Drive). Let me know if I need to share any credentials via LastPass.

@jhibbets  - anything not listed specifically above is all ready taken care of

I just did the calendar and the main Google Group. Stephanie will need the
Hootsuite credentials on Last Pass.
On Thu, Jul 19, 2018 at 12:39 PM, Janel<EMAIL_ADDRESS>wrote:

@jhibbets https://github.com/jhibbets - anything not listed
specifically above is all ready taken care of
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/ncopenpass/NCOpenPass/issues/1082#issuecomment-406340241,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AQ6Ixsbw7Y9kK-OiyD7ckUdFNlh-_pSJks5uILZJgaJpZM4VWmIe
.

--
Zach Ambrose
<EMAIL_ADDRESS>919-438-2752 (office)
919-616-9969 (cell)
www.AmbroseStrategy.com
https://www.linkedin.com/in/zambrose

Thanks @zachambrose  - I gave her access to the social media accounts via Hootsuite

I also gave you management rights to the google calendar. :)
On Thu, Jul 19, 2018 at 2:19 PM, Janel<EMAIL_ADDRESS>wrote:

Thanks @zachambrose https://github.com/zachambrose - I gave her access
to the social media accounts via Hootsuite
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/ncopenpass/NCOpenPass/issues/1082#issuecomment-406369171,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AQ6IxubRsUOgOJ_09S-i5TXV3e5jZvYrks5uIM20gaJpZM4VWmIe
.

--
Zach Ambrose
<EMAIL_ADDRESS>919-438-2752 (office)
919-616-9969 (cell)
www.AmbroseStrategy.com
https://www.linkedin.com/in/zambrose


Initial structure with a Feature Pack and Distribution

@jpkrohling and @stefannegrea could you please review?
I activated Travis CI in settings, but it still does not start.

Great, CI started.

Great, CI is passing

Looks good :) As long as it builds an usable distribution, I'm ok with this.

I could not find where this was done, but I see this in the agent's storage-adapter config:
<storage-adapter tenantId="${hawkular.rest.tenantId}" ...
Note that tenantID is not required, if not specified, we use the default "hawkular". I think you should at least allow for that default value if hawkualr.rest.tenantId is not specified, like this:
<storage-adapter tenantId="${hawkular.rest.tenantId:hawkular}" ...
This would avoid having a person always specify a tenant on the command line.
How are people suppose to set these? On the "standalone.sh" command line via -D? If they forget, the agent will fail to startup and dump errors.

As long as it builds an usable distribution, I'm ok with this.

The agent is not configured with an OOTB username/password. It just has:
<storage-adapter username="${hawkular.rest.user}" password="${hawkular.rest.password}" ...
Does this services build not have a default user anymore? If it does not, we'll need some really good docs to tell people that they can't just unzip and run and see Hawkular be in a usable state immediately. If there is a default user, we should default the agent to use those like this:
<storage-adapter username="${hawkular.rest.user:jdoe}" password="${hawkular.rest.password:thePasswordHere}" ...
I would definitely prefer the latter - make it easy on people to download and go for demo and development purposes - even if it means having a -Pdev profile to build a pre-populated user in the distro (like we had in the hawkular kettle builds).

@jpkrohling Looks good :) As long as it builds an usable distribution, I'm ok with this.

I have not booted it once and as you certainly noticed there is no single itest (that we should add soon for sure).
I also noticed that the Alert's JMX objects are missing in hawkular-services-messaging-activemq.xsl which needs to be fixed now.

I could not find where this was done, but I see this in the agent's storage-adapter config:
<storage-adapter tenantId="${hawkular.rest.tenantId}" ...
Note that tenantID is not required, if not specified, we use the default "hawkular". I think you should at least allow for that default value if hawkualr.rest.tenantId is not specified, like this:
<storage-adapter tenantId="${hawkular.rest.tenantId:hawkular}" ...

+1 I have just sent a fix to Agent: https://github.com/hawkular/hawkular-agent/pull/190

This would avoid having a person always specify a tenant on the command line.
How are people suppose to set these? On the "standalone.sh" command line via -D?

Yes, -D was the intention.

If they forget, the agent will fail to startup and dump errors.

Yes, I think "fail to startup and dump errors" should be expected for a non-dev build.
A related question is if non-empty credentials should be required in the Agent's storage-adapter config, because Hawkular backend components can (in theory) be configured not to require any credentials.

The agent is not configured with an OOTB username/password. It just has:
<storage-adapter username="${hawkular.rest.user}" password="${hawkular.rest.password}" ...
Does this services build not have a default user anymore? If it does not, we'll need some really good docs to tell people that they can't just unzip and run and see Hawkular be in a usable state immediately. If there is a default user, we should default the agent to use those like this:
<storage-adapter username="${hawkular.rest.user:jdoe}" password="${hawkular.rest.password:thePasswordHere}" ...
I would definitely prefer the latter - make it easy on people to download and go for demo and development purposes - even if it means having a -Pdev profile to build a pre-populated user in the distro (like we had in the hawkular kettle builds).

Yes, there is no dev profile here ATM and I am going to add it now. Thanks for bringing this forward. Nevertheless, the zip that will be deployed to Maven Central and offered for download on hawkular.org will not have a hard coded users (same as hawkular zip).

@jpkrohling @jmazzitelli 37102b6 :

Brings fixes I have promised above
Has dev profile
Adds caches and JMS topics and queues required by Alerts
It boots without apparent failures
Still no itests

Is this good to merge?

I'm building this now and will test it with my latest agent. That should be a good test to see if this is ready to merge.


Add Empty Spring Boot Sample

The security team likes to start coding by placing all the code into a sample. We later extract it out into more framework-like code.
We should begin with an empty Spring Boot sample using the latest version of Gradle, which will eventually be the home for the project's minimal authorization server sample code.
For simplicity, Java classes should be placed into a package called sample.
At this point, this sample doesn't need any MVC endpoints or other configurations.

@omvandenberge: Oh just saw to late that you also working on the issue..
@jzheaux: I had a look on the spring-security project structure and linked a working branch to the issue. Is this something you had in mind?


Application templates cannot be deleted

Load a template.
Create an application.
Delete the application.
Try to delete the template.

You can't.

The bug is on the server side.
See roboconf/roboconf-platform#483.


Removing some obvious pep8 violations

Noticed some very obvious pep8 violations while using package, so I thought I would contribute back the fix

wow.. thanks! I'm not really familiar with python. It's my first time to hear about PEP 8. Got it!

Consider putting in some tests as well :+1:


Can't get the same sample image with 1111 webui

This one is from kohya ss gui's sample image. 3 epochs.

This one is from 1111 webui using the ↑Lycoris. Same prompt and seed.

Actually gui's sample image is far more ugly than 1111 webui's. why?

There could be several reasons for this, such as not being able to use TI embeddings, but I feel that the quality may be poor even with these considerations. I will investigate as soon as I have time.

Diffusers and 1111 image quality is very different in general. Not sure if its due to model or library issue.


forcetk.Client.prototype.blob code has broken variable name

The signature for the function is
    forcetk.Client.prototype.blob = function(path, fields, filename, payloadField, payload, callback, error, retry) {

But when the blob is called, the variable name is changed
                    } else if(request.status == 401 && !retry) {
                        that.refreshAccessToken(function(oauthResponse) {
                            that.setSessionToken(oauthResponse.access_token, null,oauthResponse.instance_url);
                            that.blob(path, fields, fileName, file, callback, error, true);
                        },
                        error);
                    } else {

A quick search of the file shows that fileName does not occur anywhere else in the file (and my linter agrees).

Wow - how did that happen? Thanks for filing this, @elijahdorman!

@metadaddy-sfdc I didn't mention in my previous comment (my mistake) that the same line, the variable file is also an undefined variable (that name also doesn't occur anywhere else in the file).

Fixed in e12fc02


Force delete pod stuck in terminating state during hosted cluster cleanup

What this PR does / why we need it:
fixes #1692
Which issue(s) this PR fixes (optional, use fixes #<issue_number>(, fixes #<issue_number>, ...) format, where issue_number might be a GitHub issue, or a Jira story:
Fixes #
Checklist

[x] Subject and description added to both, commit and PR.
[ ] Relevant issues have been referenced.
[ ] This change includes docs.
[ ] This change includes unit tests.

/cc @csrwng @mkumatag

/retest-required

/retest-required

/test e2e-aws

I'm assuming you face this while using CleanupCloudResourcesAnnotation = "hypershift.openshift.io/cleanup-cloud-resources"?

Yes @enxebre using this flag --destroy-cloud-resources to cleanup the cloud resources.

/approve

/retest-required

/lgtm


Can you kill threads?

Someone asked about it on irc and it seems like the answer is no. You can list the running threads with threads. But you can't make Factor shot down a running thread. Seems like you should be able to.

 The closest I got was annotating every word with a flag that says whether it should keep running or not and putting a yield somewhere. Then you could run a thread in the UI and stop it on demand. It's a hack and terrible for performance, but it helped someone find an infinite loop once on irc.
We should concentrate on a new parser, better support for locals/fry/walker and their semantics, a correct compiler/gc, and then a plan for multithreading that allows killing threads.

 The closest I got was annotating every word with a
flag that says whether it should keep running or not and putting a yield
somewhere. Then you could run a thread in the UI and stop it on demand.
It's a hack and terrible for performance, but it helped someone find an
infinite loop once on irc.
We should concentrate on a new parser, better support for
locals/fry/walker and their semantics, a correct compiler/gc, and then a
plan for multithreading that allows killing threads.
—
Reply to this email directly or view it on GitHub
https://github.com/slavapestov/factor/issues/1387#issuecomment-122111343
.

 Closing!

Why not keep feature issues open?

Also, shouldn't we be able to implement kill-thread and wait-for-thread on our cooperative threads?

In general we can, but this one in particular is not something we can do without native threading, and literally the second thing you would implement is the ability to kill threads.
wait-for-thread is in another issue #1407.


null object when using $ selector of node inside dom-if

$['id1'] returns null when inside dom-if template.  Works fine when it's outside the dom-if.
<template is="dom-if" if="{{!isLogin}}">

</template>

That's "as designed". If you wrap your code with asnyc(...) to give Polymer time to stamp the template, it will work.

Tried async(()=>($['md'] as PaperDrawerPanel).togglePanel()); and still getting a null object.

Also when isLogin is false?

It' set on ready() set("isLogin", false);

I am pretty sure this is working as intended. The $ map is only going to contain things that exist on initial render. You could try setting isLogin to false in its initializer but I am not sure if that would work either. You should be able to use $$('md') instead which does an actual query for the element.


polybar main top bar crashes sometimes

Probably need to pipe the logs somehwhere to capture what is happening, it happens so intermittently that it's hard to track. Restart polybar always fixes it.

seeing it recently when clicking on the bar sometimes


Add support for compressed format to ecp_point_read_binary

Since it's supported when writing it should also be supported when reading.
I sent a corporate signed CLA earlier.

resolves #1616
@meh Thank you for your contribution! please fix CI failure:
The following tests FAILED:
	 28 - ecp-suite (Failed)
	 51 - pkparse-suite (Failed)

Support for compressed format has been deprecated by RFC 8422 in the context of TLS, which reflects a more general sentiment in the ECC community to prefer uncompressed format. Also, implementing it correctly for all supported curves would require substantial code, impacting our footprint.
At this point, we're unlikely to want to add that amount of code for a feature that's formally deprecated in TLS and being abandoned more generally, so I'm closing this PR.
Thanks for your contribution and interest in Mbed TLS anyway.


Auto-instrumentation support for http requests

Currently, manual instrumentation of okhttp3 and volleyHttp clients is supported. It requires app developers to call a specific api to get the instrumented http client to avail the instrumentation. Adding this issue to capture the requirement for auto-instrumentation of network requests. Two clients we think auto-instrumentation should be supported for are - OkHttp3 and HttpURLConnection.
Others reading this, do comment what http clients you think are most commonly used today and should be supported.

@surbhiia Can we rename this to be just http specific? Network is much much broader, and I like the idea of starting with http.

Updated issue title! I'm also working on creating a POC for HttpURLConnection auto-instrumentation using byte buddy android plugin.

@surbhiia Take a look at #64 and let's make sure that we're not duplicating efforts. 😃

Yes! Thanks for pointing that out. I had a chat with @LikeTheSalad last week about this. :) HttpURLConnection plugin would be an additional byte buddy plugin like the okhttp3 one in #64 and I will leverage all the base setup done in that PR.

I think it would be great now to close this and to split into new auto-instrumentation enhancement issues, 1 for HttpUrlConnection and 1 for Volley.

That'd be better yes! Closing this and creating two new ones. :)

Created issues #104 and #105!

Great, thanks!


Error when trying to build

python -m venv venv
bash: line 2: python: command not found
make: *** [Makefile:30: bin/pip] Error 127

Which instructions did you follow? You must include its URL for anyone to know what you did. Closing as irrelevant issue.
If you need support, do not use the issue tracker. Instead go to https://community.plone.org/


Add support for geo fix with altitude

From<EMAIL_ADDRESS>on December 29, 2011 14:18:35
Or is it broken? http://stackoverflow.com/questions/3292788/geo-fix-command-does-not-pass-altitude
Original issue: http://code.google.com/p/android-gps-emulator/issues/detail?id=5

Altitude works with this PR
https://github.com/dpdearing/android-gps-emulator/pull/10

I'm not sure I understand the code in the pull request.  How do you specify the altitude and where is it using that information?
I see a bunch of date colleciton.  Is the pull request doing speed and not altitude?

Altitude is hardcoded (you can search for the 20 in PR). My initial idea was to set speed in Location object but I have success with altitude only..  code in this PR is experimental I just want to share it and looking for comments where is the problem for the speed

I don't think that hard-coding to 20 is really any more helpful than not having altitude at all.  Maybe there is an easy way to use the Google Maps Elevation API?

Yes you can easy get the real altitude for the point but this is testing tools and more important is altitude to have some value you can set Random(0,4000) for altitude and I'm sure that nobody will open issue that altitude value is wrong ;) The real problem is how to set some hard-coded value to the speed ? if you know this I will provide PR with the real speed calculated and altitude too :)

Adding speed is part of issue #4, and the idea was to let the user manually enter a speed.  So at a minimum there would need to be a field to manually enter the speed.
Setting a random point doesn't fix this issue (altitude), which is separate from speed.

Manually to set speed why? You can calculate distance and speed from previous point

If you do it that way you still need to know the time it takes to travel between the points to calculate the speed.  And then it's way more complicated to emulate the actual speed you want.

Yes I think that its not problem to attach one timestamp to every point clicked on the map.

Sure you could do that, but I think you would end up with really high speeds (if you click a long distance apart and don't wait, what, an hour between clicks?).  That seems way harder and less useful than just typing in the speed you want to emulate for your next click.


Additional output to make it clear a pre-downloaded rootfs is being used

I ran into issues with a corrupted rootfs file living in my build/downloads when running the install-from-tar script.
I thought some additional debugging information would be useful to point out if a pre-downloaded file is being used.
I would be happy with something similar to lines 35-36 being included, but I have switched to using variables over hardcoding the filename everywhere.

@avade This looks good!  However, we are soon deprecating the git checkout vagrant up flow and will offer standalone "bundles" with versioned build artifacts, so users will likely start to vagrant up from a new location each time they upgrade Lattice, reducing the effectiveness of caching this RootFS download.
After taking a look at this, I did realize we had a bug that users with a cached RootFS won't take any upgrades currently.  [#101932000].
However, the real fix is to get rid of the caching and bake this into our base images: [#101844068] [#101844098].
That said, rebase this up to the latest develop branch and I'll merge it in.

@avade -- With [#101844068], the forthcoming v0.4.0 release will no longer download the RootFS at provision-time  (We invite you to grab our latest nightly bundle at https://lattice.s3.amazonaws.com/nightly/index.html).
I'm closing out this PR, try out the new build and let us know if you have any issues.
Thanks!
David


DO NOT MERGE: node: use Object.assign instead of lodash.merge

For merging protos, let's just pass the list of protos to gaxGrpc.loadProto since it actually supports it.

Nope - we still need something better than Object.assign. To be updated...

@JustinBeckwith one more look at the generated code?


sops-encrypted manfiests built by controller give red herring error

Issue Summary
When deploying a kustomization with sops decryption an error is thrown which makes it appear that a rendered value is invalid, when in fact the kustomization itself has an incorrectly configured service account which lacks permissions to create the object
Details
The error message Secret forbidden, error: data values must be of type string is thrown if you happen to create a kustomization which renders a sops-encrypted manifest and forgot to add the decryption.provider section (ala https://github.com/fluxcd/flux2/discussions/1999)
However, the exact same error message can be thrown even if your kustomization is configured correctly, your manifests are encrypted correctly, and the child manifest is decrypted and rendered correctly.
To Replicate
I've constructed a minimal example at https://github.com/scott-grimes/fluxErrorRepo
You can replicate it (flux version 0.31.1) by running the following
minikube start
flux install
kustomize build https://github.com/scott-grimes/fluxErrorRepo/ | kubectl apply -f -
flux get ks

Or by downloading the repo and following the instructions there
The problem is that the kustomization specifies a serviceAccountName that exists, but lacks permissions to create the resources. The error message is unclear. Rather than displaying something like "permission denied" you see forbidden, error: data values must be of type string, which is the same message that would happen if there was a problem with the decryption.

Yeah we hide all errors because the Kubernetes API includes the secret values in the error message. I know this is frustrating to debug but we did this to avoid leaking secrets.

That is annoying but very sensible, is there anything to be done about this issue or should we close it?

Hmm perhaps an --insecure-show-raw-errors flag to allow for further
debugging?
In this case it would have allowed us to rule out a possible encryption
problem and easily see it was a permission problem. I'm assuming the error
message would have been something like "service account xxx cannot create
resource xxx in namespace xxx" had we been able to see it.
There's bound to be enough problems that would fall into this class of
errors for other people to find this useful?
On Thu, Jun 23, 2022, 1:59 PM Kingdon Barrett @.***>
wrote:

That is annoying but very sensible, is there anything to be done about
this issue or should we close it?
—
Reply to this email directly, view it on GitHub
https://github.com/fluxcd/kustomize-controller/issues/683#issuecomment-1164709525,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABQZUACJMGHKWJNFN4772XTVQSQWXANCNFSM5Y7SEHPQ
.
You are receiving this because you authored the thread.Message ID:
@.***>

I think hiding the error is fine if that's what's needed to keep things safe. Please improve the actual error that is shown though. The error Secret forbidden, error: data values must be of type string suggests there's something wrong with the content of the Secret. Which is annoyingly different from the actual situation I was debugging: The flux user has no role bound that has the create verb for the secret resource.

Fixed in Flux v2.2


engine: normalize the csv job package path name

Signed-off-by: Henry Lonng<EMAIL_ADDRESS>
What problem does this PR solve?

Refer to the Golang best practice: https://go.dev/doc/effective_go#package-names.

By convention, packages are given lower case, single-word names; there should be no need for underscores or mixedCaps.

This PR renames the camel case package name into the snake case.
What is changed and how it works?
Check List
Tests

No code

Questions
Will it cause performance regression or break compatibility?
No
Do you need to update user documentation, design documentation or monitoring documentation?
No
Release note
None

/merge

Codecov Report

Merging #5662 (c97279e) into master (fcea4d5) will increase coverage by 0.6266%.
The diff coverage is 57.7540%.

Flag
Coverage Δ

cdc
62.0746% <62.4318%> (+0.9265%)
:arrow_up:

dm
52.0501% <29.5774%> (+0.0074%)
:arrow_up:

engine
58.7474% <ø> (?)

Flags with carried forward coverage won't be shown. Click here to find out more.
@@               Coverage Diff                @@
##             master      #5662        +/-   ##
================================================
+ Coverage   56.0768%   56.7035%   +0.6266%
================================================
  Files           535        675       +140
  Lines         70143      78988      +8845
================================================
+ Hits          39334      44789      +5455
- Misses        27078      30006      +2928
- Partials       3731       4193       +462


Decreased Docker Image build

First of all, I want to say that this project looks really good: I wanted to make a Rust musicbot myself but when I saw this I thought: ¨this is exactly how I would do it if I had the time (and Rust know-how)". I thus started to look at what I could contribute and began with the Dockerfile, as it seemed to me that it could be smaller. It turns out it can be smaller!
For future reference,I tried:

Alpine -> too much of a hassle to compile Rust to musl instead of glibc
Compiling FFMPEG myself -> Makes a small image, but I am no expert at compilation soo to much of a risk of breaking in the future

In the end I settled on these changes:

Using bitnami/minideb as a base. It turns out installing Python on this image makes it smaller than using the official python:3-slim image.
Removing unnecessary Python build and develop dependencies
Using the static FFMPEG build from yt-dlp. Has the additional benifit of containing some yt-dlp specific fixes. Also offloads the compilation responsibility to them and is assured to work.

Size comparisons (no --squash used):

Current image from ghcr.io: 631.05 MB
New image: 248.48 MB

As a side-note, the version with the custom-compiled FFMPEG, came in at 229.4 MBs. The final image might be smaller or even bigger, because the image did not work yet, but I am not going to all that effort to safe 20-40 MBs.
Notes:
Adding the squash flag made no difference, as the image has very few layers to begin with.
The new image uses a staticly compiled FFMPEG, which makes architecture dependent. yt-dlps ffmpeg is compiled to both arm64 and amd64 though, so I included an if statement to download the correct version. This should make the new image compatible with both versions, which I think are the only architectures people are using realistically anyways.
This does mean that the new docker image on ghcr.io should change to be multi-platform, something in this article

I tried building for arm on my pc but it gave an error on the first cargo build step, but this is likely a cross-compilation problem, not a problem with the new FFMPEG workflow

Apparently I had to merge the readme, all ready now


Minor changes to testing setup

Builds atop great testing work in #11 by @mcuadros and makes a few minor changes.

Use tlsutil.TLSInfo for the server (just read testdata)
Callers goroutine the server, not the Start function itself
Don't hold a listener in the struct, just use a constant address (possibly temporary, try to find races and report upstream)
Allow server and client TLS credentials to be passed in to FixtureServer
Stop is a NOP if Start has not yet been called

There do seem to be races to do with the gRPC package's server.Stop and address release, I see the address already bound error in 1 of every ~200 test runs. Reverting back to choosing random ports would mask the issue as a temporary fix.

There do seem to be races to do with the gRPC package's server.Stop and address:port release, I see the address already bound error in 1 of every ~200 test runs.
Review of Linux Programming Interface shows this is fairly foundational to socket close (search WAIT_TIME and SO_REUSEADDR) and several grpc upstream discussions just mention randomizing ports when setting up and tearing down tests. In that light, let's stick with Maximo's random ports and not worry about this.

Awesome, but if you get back to the random ports... you will need to keep the listener or not?

Yes, keeping the listener in the struct. I think I was just pushing as you commented.


[Android mobile chrome 58] pixi init options.antialias = true // has problem

[Android mobile chrome 58] pixi init options.antialias = true // has problem
chrome 57 ,56, or older version  is normal !
#4015

Can you elaborate please? What issue are you experiencing? Can you share a running example of this issue happening?

It's probably Chrome bug reported here: http://crbug.com/696126

use framework to manager canvas
https://mithril.js.org/index.html
like class PIXI.Application
like this

pixi component

import m from 'mithril';

let canvasStyle = {left: '0%', top: '0%', width: '100%', height: '100%'};
let baseStyle = {
  zIndex: 10,
  position: 'absolute',
  left: '0%',
  top: '0%',
  width: '100%',
  height: '100%'
};
let Component = {
  game: null,

  oninit (vnode) {
    let state = vnode.state;
    let attrs = vnode.attrs;
    let conf = vnode.attrs.config;
    let config = {
      useManager: conf.useManager,
      id: vnode.attrs.id || conf.id,
      width: conf.width || 1024,
      height: conf.height || 768,
      resolution: conf.resolution || 1,
      antialias: conf.antialias,
      transparent: conf.transparent,
    };

    state.config = config;
    state.style = attrs.style || baseStyle;

  },

  oncreate (vnode) {
    let state = vnode.state;
    let config = state.config;
    config.canvas = vnode.instance.children[0].dom;
    config.element = vnode.dom;

    let options = {
        view: config.canvas,
        resolution: screen.resolution,
        antialias: screen.antialias,
        transparent: screen.transparent
    };

    let renderer = PIXI.autoDetectRenderer(screen.width, screen.height, options);

    //--
    let stage = new PIXI.Container();
    render(stage);
  },

  onremove (/*vnode*/) {
    console.log('game onremove');

  },
  view (vnode) {
    let state = vnode.state;

    return m('.', {style: state.style},
      m('canvas', {style: canvasStyle})
    );
  }
};
export default Component;

app

  let style = {zIndex: 10, position: 'absolute', left: '0%', top: '0%', width: '100%', height: '100%'};
  let app = {
    view () {
      return  m('.', {style: style},
        m(components.game.pixi, {
          config: null,
        })
      );
    }
  };
    m.mount(document.body, app);

same issue here
https://github.com/pixijs/pixi.js/issues/4015

Closing since this is a duplicate of #4015.


Make GitHub detect *.ft as Forth

Hello,
Please merge this, if you'd like GitHub to detect your .ft files as Forth.
Thanks!

Awesome, thank you!


Prometheus library does not emit any warnings or errors when alert rules folder does not exist

When adding a non-existent directory via alert_rules_path, there are no indications in the juju debug-logs of any issue.

DONE


Messages with actions in their attachments are not displayed correctly since version 2.23.0

Hi @larkox
I am facing the same issue as @Kvark1205 on #8422: messages from AlertManager component of Prometheus are not displayed correctly on the mobile app of mattermost since release v2.23.0
I tried to debug what's going on: the issue seems related to actions object of attachments in messages. As soon as one action is present, Mattermost mobile does not display the message correctly.
I am opening a separate Github issue because I believe the bug is not directly related to interactive dialogs (please let me know if I'm wrong).
Here is a python script that can reliably trigger the issue:
import requests
response = requests.post(
    f"http://localhost:8065/hooks/3fobp3dduifmtx9cdnbedsi6cy",
    json={
        "username": "NotificationsBot",
        "attachments": [
            {
                "text": "Service AAA went down. Please check",
                "actions": [{"id": "765dguyjij8mbdzc1xwwmuei7c", "type": "button"}],
            }
        ],
    },
)

When executing the code, Mattermost desktop app displays the message correctly:

However, Mattermost mobile does not:

Also, I do confirm that the issue is still present on the current codebase (as of 32453b320c31ec98a8936b9d4192c41d90fd050a ).
I did a test build of the mobile APK, it is still affected by the issue.

@Augustin-FL Can you verify if adding a name to the actions fix the issue? Name is supposed to be a required field for actions.

Indeed,
When adding a name to all actions, everything works correctly.
The issue seems to be on AlertManager side then:
When sending a Mattermost message, AlertManager doesn't add a name field to actions, even when an action name is configured correctly in AlertManager's config (alertmanager.yml)
I am closing this issue, given it is not directly related to the mattermost mobile app. Feel free to re-open it if needed


Feature/stackn 103

STACKN-103
CLI has functionality at the user level, by which I mean that you can:
stackn setup (setup config for deployment of STACKn)
stackn login (login user)
stackn get projects (list the user's projects)
stackn set project (set the active project)
stackn set remote (set the active STACKn deployment)
stackn status (show active remote and active project)
This commit means that we don't need to manually generate and download the project.yaml anymore to manage projects.

Great work achieving this!


Feature request: Add a "Test Config" option to the Nginx HA SSL Proxy addon

One of nginx's incredibly important functions is the ability to verify that you have a valid configuration before actually making that configuration active.
It would be awesome if there was a way to fire off the "nginx configtest" command from within HA so that before you click "Restart" you can confirm that your proxy server won't go down due to a config error.

Hi 👋
This is the issue tracker for addons, for feature requests please raise it on the forum https://community.home-assistant.io/c/feature-requests, thanks 👍

Do you accept pull requests for new features, or does that need to be voted on by the community first?

If you are up to the task, please do 👍


fs/hostfs: add sim hostfs path convert

Summary
Set sim/hostfs to use the path where the executable file is located as the root path
In the sim, hostfs uses $CWD as the root path. When running in different paths, the access path of hostfs is different.
This patch is changed to use the path where the nuttx file is located as the root path, so that the mounted path is fixed when executed in different paths
Impact
sim/hostfs
_NSGetExecutablePath is a system API, it will report an error when nxstyle checks
Testing
sim:nsh

In the sim, hostfs uses $CWD as the root path. When running in different paths, the access path of hostfs is different.

what's wrong with it?

This patch is changed to use the path where the nuttx file is located as the root path, so that the mounted path is fixed when executed in different paths

i feel it's awkward to use the path of the executable for this purpose.

In the sim, hostfs uses $CWD as the root path. When running in different paths, the access path of hostfs is different.

what's wrong with it?

Here is an example, Directory layout:
···
work/apps/
work/nuttx/
work/data/
···
rcS contain:
···
mount -t hostfs ../data /data
···
if user launch nuttx by:
···
cd work/nuttx
./nuttx
···
he can access PC's data directory without error
but if user launch nuttx by:
···
cd work
./nuttx/nuttx
···
ls /data will report the error.
This patch ensures the user get the consistent result regardless he launches the program from anywhere.

This patch is changed to use the path where the nuttx file is located as the root path, so that the mounted path is fixed when executed in different paths

i feel it's awkward to use the path of the executable for this purpose.

Do you have better suggestion?

In the sim, hostfs uses $CWD as the root path. When running in different paths, the access path of hostfs is different.

what's wrong with it?

@yamt Here is an example, Directory layout:
work/apps/
work/nuttx/
work/data/

rcS contain:
mount -t hostfs ../data /data

if user launch nuttx by:
cd work/nuttx
./nuttx

he can access PC's data directory without error, but if user launch nuttx by:
cd work
./nuttx/nuttx

ls /data will report the error. This patch ensures the user get the consistent result regardless he launches the program from anywhere.

probably sometimes it's a good thing.
in the other cases it can be a bad thing.
i don't see much motivation to change the behavior.

This patch is changed to use the path where the nuttx file is located as the root path, so that the mounted path is fixed when executed in different paths

i feel it's awkward to use the path of the executable for this purpose.

Do you have better suggestion?

if you want a consistent result, why don't you use a consistent cwd?

ls /data will report the error. This patch ensures the user get the consistent result regardless he launches the program from anywhere.

probably sometimes it's a good thing. in the other cases it can be a bad thing.

could you explain more when is it good or bad? I can't understand why it's a bad thing to give the user the consistent result.

i don't see much motivation to change the behavior.

So, you don't reject the change, thanks.

Do you have better suggestion?

if you want a consistent result, why don't you use a consistent cwd?

I never complain this since I am very familiar with the code base and understand I need launch from nuttx directory. But many people who use hostfs first time hit this problem frequently. Actually, this is the hottest issue reported by the end user.

ls /data will report the error. This patch ensures the user get the consistent result regardless he launches the program from anywhere.

probably sometimes it's a good thing. in the other cases it can be a bad thing.

could you explain more when is it good or bad? I can't understand why it's a bad thing to give the user the consistent result.

i usually don't use relative path to mount hostfs.
but when i do, i expect it means relative to the host cwd.
this change introduces a surprising behavior to me.
at least on traditional unix, the path of executable usually doesn't affect the behavior of it.

i don't see much motivation to change the behavior.

So, you don't reject the change, thanks.

Do you have better suggestion?

if you want a consistent result, why don't you use a consistent cwd?

I never complain this since I am very familiar with the code base and understand I need launch from nuttx directory. But many people who use hostfs first time hit this problem frequently. Actually, this is the hottest issue reported by the end user and key reason that @Gary-Hobson provide this patch.

ls /data will report the error. This patch ensures the user get the consistent result regardless he launches the program from anywhere.

probably sometimes it's a good thing. in the other cases it can be a bad thing.

could you explain more when is it good or bad? I can't understand why it's a bad thing to give the user the consistent result.

i usually don't use relative path to mount hostfs.

If you want to share the prebuilt nuttx binary or initial script to other people, the related path is better than the absolute path, since the host resource folder mounted by the initial script is normally at the fix location related to nuttx binary.

but when i do, i expect it means relative to the host cwd.

From the previous example, you can see the location related to nuttx binary is better than the current directory.

this change introduces a surprising behavior to me.

As I explain before, it's the top complaint from our daily report. Since you seldom use the relative path in mount, please trust the data we collected, thanks.

at least on traditional unix, the path of executable usually doesn't affect the behavior of it.

Here is a demo that shared-object search path may relate to the path of executable:
https://unix.stackexchange.com/questions/22926/where-do-executables-look-for-shared-objects-at-runtime

ls /data will report the error. This patch ensures the user get the consistent result regardless he launches the program from anywhere.

probably sometimes it's a good thing. in the other cases it can be a bad thing.

could you explain more when is it good or bad? I can't understand why it's a bad thing to give the user the consistent result.

i usually don't use relative path to mount hostfs.

If you want to share the prebuilt nuttx binary or initial script to other people, the related path is better than the absolute path, since the host resource folder mounted by the initial script is normally at the fix location related to nuttx binary.

but when i do, i expect it means relative to the host cwd.

From the previous example, you can see the location related to nuttx binary is better than the current directory.

this change introduces a surprising behavior to me.

As I explain before, it's the top complaint from our daily report. Since you seldom use the relative path in mount, please trust the data we collected, thanks.

what's "our daily report"?
i can understand some people is not happy with the current behavior.
i suspect there can be more people who is happy with the current behavior though.
with the current behavior, if you want to use a path relative to the executable, you can just set cwd.
after this change, it's impossible to use a cwd-relative path. i consider it less flexible.

at least on traditional unix, the path of executable usually doesn't affect the behavior of it.

Here is a demo that shared-object search path may relate to the path of executable: https://unix.stackexchange.com/questions/22926/where-do-executables-look-for-shared-objects-at-runtime

i'm aware of $ORIGIN stuff. that's why i said "traditional". IMO it's a misfeature.

ls /data will report the error. This patch ensures the user get the consistent result regardless he launches the program from anywhere.

probably sometimes it's a good thing. in the other cases it can be a bad thing.

could you explain more when is it good or bad? I can't understand why it's a bad thing to give the user the consistent result.

i usually don't use relative path to mount hostfs.

If you want to share the prebuilt nuttx binary or initial script to other people, the related path is better than the absolute path, since the host resource folder mounted by the initial script is normally at the fix location related to nuttx binary.

but when i do, i expect it means relative to the host cwd.

From the previous example, you can see the location related to nuttx binary is better than the current directory.

this change introduces a surprising behavior to me.

As I explain before, it's the top complaint from our daily report. Since you seldom use the relative path in mount, please trust the data we collected, thanks.

what's "our daily report"?
i can understand some people is not happy with the current behavior. i suspect there can be more people who is happy with the current behavior though.
with the current behavior, if you want to use a path relative to the executable, you can just set cwd. after this change, it's impossible to use a cwd-relative path. i consider it less flexible.

at least on traditional unix, the path of executable usually doesn't affect the behavior of it.

Here is a demo that shared-object search path may relate to the path of executable: https://unix.stackexchange.com/questions/22926/where-do-executables-look-for-shared-objects-at-runtime

i'm aware of $ORIGIN stuff. that's why i said "traditional". IMO it's a misfeature.

Ok, let's stop the discussion which one is better. @Gary-Hobson let's support both.

ls /data will report the error. This patch ensures the user get the consistent result regardless he launches the program from anywhere.

probably sometimes it's a good thing. in the other cases it can be a bad thing.

could you explain more when is it good or bad? I can't understand why it's a bad thing to give the user the consistent result.

i usually don't use relative path to mount hostfs.

If you want to share the prebuilt nuttx binary or initial script to other people, the related path is better than the absolute path, since the host resource folder mounted by the initial script is normally at the fix location related to nuttx binary.

but when i do, i expect it means relative to the host cwd.

From the previous example, you can see the location related to nuttx binary is better than the current directory.

this change introduces a surprising behavior to me.

As I explain before, it's the top complaint from our daily report. Since you seldom use the relative path in mount, please trust the data we collected, thanks.

what's "our daily report"?
i can understand some people is not happy with the current behavior. i suspect there can be more people who is happy with the current behavior though.
with the current behavior, if you want to use a path relative to the executable, you can just set cwd. after this change, it's impossible to use a cwd-relative path. i consider it less flexible.

at least on traditional unix, the path of executable usually doesn't affect the behavior of it.

Here is a demo that shared-object search path may relate to the path of executable: https://unix.stackexchange.com/questions/22926/where-do-executables-look-for-shared-objects-at-runtime

i'm aware of $ORIGIN stuff. that's why i said "traditional". IMO it's a misfeature.

Ok, let's stop the discussion which one is better. @Gary-Hobson let's support both.

i agree that there seems no single "obvious" behavior.
maybe you can support something similar to "$ORIGIN" in the path.

@yamt is the new change good?