Show FluentFTP version in log after connect

This might help in case users are secretive
...
Status:   Waiting for response to: SYST
Response: 215 UNIX emulated by FileZilla.
Status:   Listing parser set to: Machine
Status:   Connection established by FluentFTP Version <IP_ADDRESS>
...

Great, but the note seems a bit long, can we shorten it?:

Connection established by FluentFTP Version <IP_ADDRESS>
Connected using FluentFTP <IP_ADDRESS>

It is shorter now. Although they call it "verbose" for a reason, LOL

Any problem that it uses reflection?

Looks great!


After booping, the focus should move to the last empty field, but it doesn't

Summary
The workflow for booping (scanning barcodes) is intended to require minimal switching between scanner and keyboard/mouse. When a user scans a barcode, it should automatically create a fresh blank line item and then move the cursor to it. We do this using the .focus() JS method.
Steps to reproduce

Start a new Donation (or any itemizable)
Go to the line-items area
Boop a barcode or enter a UPC string and press Enter
Note that, while a new line item DOES appear, the cursor remains in the current field.

Closed via #1185

Closed via #1191 now :)


Fix various typos and translate to french

Miscellaneous active reading.

Codecov Report

Merging #16477 (fd612df) into main (ec35783) will decrease coverage by 0.02%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##             main   #16477      +/-   ##
==========================================
- Coverage   45.43%   45.41%   -0.03%
==========================================
  Files         717      717
  Lines       84184    84184
==========================================
- Hits        38252    38235      -17
- Misses      39780    39799      +19
+ Partials     6152     6150       -2

Impacted Files
Coverage Δ

services/mailer/mail_comment.go
77.77% <0.00%> (-7.41%)
:arrow_down:

services/pull/temp_repo.go
25.77% <0.00%> (-4.13%)
:arrow_down:

services/pull/check.go
25.51% <0.00%> (-2.76%)
:arrow_down:

modules/process/manager.go
72.83% <0.00%> (-2.47%)
:arrow_down:

modules/notification/mail/mail.go
36.27% <0.00%> (-1.97%)
:arrow_down:

services/pull/patch.go
54.23% <0.00%> (-1.70%)
:arrow_down:

modules/git/blame.go
65.71% <0.00%> (-1.43%)
:arrow_down:

modules/log/event.go
58.96% <0.00%> (-0.95%)
:arrow_down:

services/pull/pull.go
41.93% <0.00%> (-0.44%)
:arrow_down:

modules/queue/workerpool.go
54.58% <0.00%> (+0.76%)
:arrow_up:

... and 1 more

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 ec35783...fd612df. Read the comment docs.


Remove node-fetch package and use Node.js 18 nativefetch

In another project using Redocly, displays an error on console due to this package. More details: https://github.com/OpenAPI-Qraft/openapi-qraft/issues/117#issuecomment-2271081645
It is an error caused by node-fetch package that hasn't been updated for a year and it uses a deprecated dependency.
But there's no need to have the node-fetch dependency because fetch is natively available since Node.js@18 and it is the same as node-fetch.
Just removing node-fetch and updating the node version to 18 would fix the issue.

I tried to open a PR implementing this, and it is not as straightfowrard as it seems.
In the uploadFileToS3 function a stream is used as body, which is not supported in the native fetch.
A possible solution would be to use another library like undici or axios for this specific function and use native fetch for the rest of functions.

Hi @mauriciabad. Currently, Redocly CLI supports Node versions prior to 18, so I wouldn't remove the node-fetch package just to maintain backward compatibility. However, we might reconsider this in the future. Thanks for the suggestion.


fix(debounceTime): handle synchronous schedulers

Description:
Using debounceTime(0, queueScheduler) was not emitting any values. scheduler.schedule() emits immediately but logic in debounceTime was expecting it to always return before emitting.
Related issue (if exists):
Fixes https://github.com/ReactiveX/rxjs/issues/6764

I see the issue.
I think that a cleaner solution would be to create a Subscription prior to the subscriber.schedule call, and leverage that, something like:
if (!activeTask) {
  subscriber.add(activeTask = new Subscription());
  activeTask.add(scheduler.schedule(emitWhenIdle, dueTime));
}

It's perhaps a little more resource intensive per schedule, but it's certainly less complicated.
Let me know if that works out.

That is a nice solution. Can confirm it works and cleans up the scheduler.schedule subscription even after the fact in the synchronous case. Learned a little more about Subscriptions, thanks.

@dancras Apologies on dropping the ball on landing this one. I think there may be another solution here, and we might still try to get this into the 7.x branch.

I've added a commit and moved it over here. I'll try to make sure you get credit for the commits, @dancras
https://github.com/ReactiveX/rxjs/pull/7161


[CODEOWNERS] - Make primary package owner first

Packages impacted by this PR
None
Issues associated with this PR
Resolves #18210
Describe the problem that is addressed by this PR
Today, vendors create issues and assign them based on a list that I provided
them. The problem is that it can easily get out of sync as nobody would know to
update it. I am working towards making CODEOWNERS the single source of truth for
package ownership. It needs to start with the primary owner listed first, so
that the vendors know who to assign it to.
What are the possible designs available to address the problem? If there are more than one possible design, why was the one in this PR chosen?
I am going to be honest, this effort might not go anywhere. But it's not a
harmful thing to do. Besides, there's a bit of a chicken-and-egg problem right
now. CODEOWNER list ordering is not used by the vendors because it's not
ordered, but nobody will want to order it because the order has no impact.
Between this and the efforts engsys is putting in place to parse this file I am
hopeful we can get to a place where vendors can look at data derived from
CODEOWNERS.

The only changes here are ordering of the GH usernames and removing Richard as owner of Service Bus (sorry Richard)

/check-enforcer override


Have yamllint catch duplicate merge keys.

Duplicate merge keys (<<: foo) are brittle because they're not valid in any YAML standard so far and they rely on implmentation-dependent behaviour. There's also no advantage to them over specifying a single merge key with a list as its value.

Ah I guess we need to wait for yamllint 1.34 and for the runner image to catch up.


[Bug][Jenkins] MavenModuleSet should be treated as a scope

Search before asking

[X] I had searched in the issues and found no similar issues.

What happened
The logic for categorizing Devlake Remote Scopes has changed in version v1.0.0-beta5. Previously, the default category was "scope," but now it is "group." This change has led to issues, such as hudson.maven.MavenModuleSet Jenkins project type being treated as a group instead of a scope. As a result, you cannot add a new Devlake Remote Scope because it's incorrectly categorized as a group.
What do you expect to happen
I expect that hudson.maven.MavenModuleSet Jenkins project is not categorized as group by Devlake
How to reproduce
Create a new Maven Project in Jenkins and try to add it through Devlake:

Anything else
No response
Version
v1.0.0-beta11
Are you willing to submit PR?

[X] Yes I am willing to submit a PR!

Code of Conduct

[X] I agree to follow this project's Code of Conduct

Lovely

I like the report-and-fix vibe here. 👍


sys._home -> sys.base_exec_prefix

Facts:

library_dirs is used to add -L xxx in build commands
sys._home only exists in venv (https://github.com/python/cpython/blob/main/Lib/site.py#L527) It does exist outside of venv, but the value is None
Last time it was changed in https://bugs.python.org/issue15367
This change only applys to os.name == 'nt'

Problems:

When using MS Store version of Python, include sys._home makes no sense. It's like C:\Users\<user>\AppData\Local\Microsoft\WindowsApps\PythonSoftwareFoundation.Python.3.9_qbz5n2kfra8p0 and only contains 0KB files

What's the point to include the folder only when in venv?

Changes:

Always include base_exec_prefix

Other options:

include it still only when in venv
remove it, because right now it's not included outside of venv

Note:

I don't know whether to choose sys.base_exec_prefix or sys.base_prefix, though they are identical in my environment.

I don't have much experience either.
The reason I found this is because there is a VCRUNTIME140.dll under sys.base_exec_prefix, but not under _sys_home when using MS Store Python.
If both my two PRs are merged, there won't be a ld error as I said in #41 and people can successfully use MinGW to compile extensions.
I personally think _sys_home and sys.base_exec_prefix are identical in normal Python. But I didn't test it.
If so, the minimal change is change self.library_dirs.append(_sys_home) to self.library_dirs.append(sys.base_exec_prefix). Keep if _sys_home so that it still only takes effects in venv.
Though I don't know if it's appropriate to use VCRUNTIME140.dll that is bundled with Python.
But that's not very important, because _sys_home is included anyway without this patch.

May I recommend to revisit this issue and file a report that describes the issue. In particular, what do you expect to happen and what happens instead and under what conditions?  And then the next step will be to create two tests as mentioned above:

One test to capture the current behavior (whatever motivated the author to add sys._home to the path). That is, not specifically that sys._home is added, but whatever behavior would break if it's missing.
Another test to capture the expectation that's missed if base_exec_prefix is not added.

These two tests may be the same thing.

I really don't have time for programming now. 😢
In the future I maybe firstly learn how to use linux and how to use python on linux. Then try to understand what sys._home represents.

On further consideration, and after reviewing the patch in bpo-15367 (7e4558cfe24f0fb019e741f5da76cfc6e7cdc40f), it may be asking a lot to capture the expectation that this change introduces. I also agree, that the sys._home was probably a hack and superseded by sys.base_exec_prefix, which was only introduced in Python 3.3. This newer code is cleaner and likely has the intended effect. And since the failure mode is only in MS Store Python, it's probably not easy to test for that environment.
I did read up on the difference between sys.base_exec_prefix and sys.base_prefix. Basically the difference is the same as for sys.exec_prefix and sys.prefix, which is that without exec_, it's for platform independent files. So I'm comfortable that base_exec_prefix is the best choice here.
Let's incorporate this change and see how it goes. Thanks for the contrib.


Ollama server running out of memory when it didn't in previous version

What is the issue?
Hello,
I'm trying to run Llama 3.1 8b in Ollama 0.3.4 on a laptop (it has 8gb ram and 4 cpu cores, running it on CPU as my GPU is integrated and not compatible). Maybe this sounds crazy, but it worked fine on Ollama 0.3.3, and just after updating to 0.3.4 and running it (I also tried updating the model but the same) I get:
Error: Post "http://<IP_ADDRESS>:11434/api/chat": EOF
and when I try again:
Error: llama runner process has terminated: signal: killed
So I think it's running out of memory. I like to try things on my laptop before deploying them to my server, so I would like if you could "fix" that back, or show me a workaround for this. (Mistral 7b works fine with 0.3.4).
Thanks in advanced.
OS
Linux
GPU
Other
CPU
Intel
Ollama version
0.3.4

Server logs will help in debugging.

@MxtAppz Alongside the new version of Ollama, there is an update for the Llama3.1 LLMs. Did you pull this latest version? If you are experiencing memory issues, could you try a lighter version of Llama3.1?
ollama run llama3.1:8b-instruct-q3_K_L

This version is slightly lighter than the default q4_0 and should resolve the issue you're facing.
Yes, the system size grows as Ollama and Llama3.1 grow as well. Another option is to restart your Mac before testing Ollama and ensure no other applications are running besides Ollama and the terminal.

@MxtAppz Alongside the new version of Ollama, there is an update for the Llama3.1 LLMs. Did you pull this latest version? If you are experiencing memory issues, could you try a lighter version of Llama3.1?
ollama run llama3.1:8b-instruct-q3_K_L

This version is slightly lighter than the default q4_0 and should resolve the issue you're facing.
Yes, the system size grows as Ollama and Llama3.1 grow as well. Another option is to restart your Mac before testing Ollama and ensure no other applications are running besides Ollama and the terminal.

Yes, I pulled the latest llama3.1 model, and doesn't work (the older one didn't work either though). I'll try the instruct version as soon as possible and tell you.

Error: llama runner process has terminated: signal: killed

This indicates a problem with the runner, not the model (unless the model is borked somehow).  Server logs will help in debugging.

@MxtAppz would it be possible to check the logs with journalctl -u ollama to see what the error may be? Sorry about this

Hello newly,
Finally, the issue was resolved by rebooting the system (thanks to @igorschlum for telling me). Anyway, I will leave the issue open and attach the log after updating Ollama in case someone wants to check it out. Thanks for your time.
ollama.txt

This should be fixed now – you'll need to re-pull llama3.1 let me know if that doesn't help!


Problems with the spaces option

Hello, I have encountered the following strange behavior when trying to shave an english text while preserving whole words (instead of splitting on any letter) in the following releases:
2.0.4: Defaults to splitting on any letter. Passing {spaces: true} makes it split on spaces. Probably the closest to what I would expect to happen.
2.1.2: spaces option has no effect at all(likely because of https://github.com/dollarshaveclub/shave/pull/98). Changing the source to spaces = false makes it split on spaces (the opposite of 2.0.4? seems odd considering the default was changed in this version and at odds with the use for non-spaced languages)
2.2.0 and 2.2.1: spaces option has no effect at all
The version that is in the codepen demos (says 2.2.0 but I'm not so sure it actually matches that release): Works like 2.1.2, but you can actually pass in {spaces: false} without editing the source.
Additionally, when splitting on spaces the space itself is removed (this differs from the behavior when splitting on any character, where spaces are always preserved). It would be nice if the space that was split on could be kept in the hidden span to make it easier to implement a button to show/hide the rest of the text.

Hello @Dantemss, I'm not clear on this issue as described above. 😁

What's wrong?
What's desired?

Could you provide a CodePen which illustrates the issue that you're seeing? It would be easiest for me if you referenced the code that is in master vs multiple versions.
~Thanks

Hello and thanks for looking into this.
You can see on the codepen example posted in the readme (https://codepen.io/yowainwright/pen/VKVXRa), now that it has been updated, that the newest version of shave seems to always split the sentences on arbitrary letters now. For example, the word hendrerit becomes he…, no matter if you pass in {spaces: true} or {spaces: false}. Shave used to split sentences on whole words if you passed in {spaces: true} in 2.0.4, meaning it would abbreviate the lorem ipsum as something like (…) non posuere justo….
However, it seems that splitting on whole words was not necessary in my project at the moment, so I'm not actually using this option right now.

@Dantemss yes, that's a bug. Thanks for letting me know!


Implement the list command to filter by time

Dependencies: #73
Format: list todo/schedule/completed/"all tasks" at TIME
E.g.

list schedule at 2pm
list all tasks at 5.30pm

*NOTE:

The "all tasks" does not need to have the quotation marks when used.
The TIME has to be in 12-hour format.
A dot is used in the time format instead of colon. E.g. 4.30pm not 4:30pm.

Refer to issue #70

NA anymore. Planned not to do it.


It'll be better if "Check for updates" work within the app and don't open in the web browser.

Currently it takes to https://github.com/microsoft/PowerToys/releases, will be better if PowerToys get built-in updating system.

Hi @sayedarifuddin
the tracker for this issue is https://github.com/microsoft/PowerToys/issues/2535
Closing this as duplicate.
Thank you.


Add Kruskal's Algorithm Implementation in C++

Hey @Kushal997-das , I propose adding an implementation of Kruskal's Algorithm in C++ to find the minimum spanning tree of a connected, undirected graph. The output will contain the edges and the cost of minimum spanning tree built with Krushal's algorithm.
Input:
1
5 7
0 1 10
0 2 6
0 3 5
1 3 15
2 3 4
1 2 8
2 4 3
Output:
Edegs in MST are :-
2 -> 4
0 -> 3
0 -> 1
Total cost of MST is : 18
can you please assign me this issue?
Thank You.

Hi there!
I am the Mentor of this project .
Although this repo is not part of Hacktoberfest 2024, we have some great alternatives for you. Welcome to SkillShow, a repository focused on skill enhancement!
Guidelines:
Please adhere to the existing guidelines.
No additional rules, thanks!
Check it out here: SkillShow.
Note: Start by creating an issue. Once it’s assigned to you, feel free to open a pull request (PR). Directly opening a PR will lead to an invalid label.
Looking forward to your contributions!


Cerebro and S3 snapshots

Does cerbro working with snapshot stored on AWS S3? We are using kopf plugin and we can browse and restore all snapshots. With cerebro it is not working. We can see all our snapshots but when we click on restore - nothing happens (same snapshots work just fine with kopf). We found one snapshot that is actually opening additional properties like rename pattern etc. But other snapshots do not do anything. This is true for all three cluster that we run.
We are using 0.6.8.
Thanks!

Same problem with 0.7.2 !
This happens when snapshot's name contains dots !

Fixed in https://github.com/lmenezes/cerebro/pull/351
Thank you for reporting. In the next release it will be available


wp db create fails

Usually when using Bedrock, I would populate my .env file using https://github.com/roots/trellis-cli.
I have done the same using this Pantheon repo but renamed to .env.local.
I then run wp db create from the bedrock directory to create my local database.
Unfortunately whatever changes that have been made to this repo has resulted in local .env not working at all.
I'd take a guess at something here may be related https://github.com/pantheon-systems/wordpress-composer-managed/commit/bc11ddbd6529f7bb455587af07a1cfea2b9cfd5d
Separetely, because Config::define('WP_HOME', env('WP_HOME') was moved after Config::define('WP_HOME', env('WP_HOME') I was also getting a fatal error.

Thank you for this report @codepuncher! Are you able to share the error message(s) you receive when running wp db create.
We are working on some separate changes for local development that might address this issue. In the case that it doesn't, we'll open a bug ticket and will be sure to look into this.

A ticket has been opened to take care of this, thanks again for the report!

We've run into this as well with our dev sandbox for Decoupled WordPress sites. Specifically using Lando.
Poking at this a bit I've found that based on what @codepuncher pointed out, if i restore the lines here: https://github.com/pantheon-systems/wordpress-composer-managed/commit/bc11ddbd6529f7bb455587af07a1cfea2b9cfd5d#diff-53ea5a45a4b413ca49c7fac3f022e1dcbc2c203dcab4a1e7a34d1a8d65b26977L51-L56
lando wp commands start working again, but the actual WordPress site becomes unstable (I think I starter to see 404s) until those lines are removed again.

Closing as resolved, but feel free to re-open if you're still experiencing this!


HLS manifest generation

See https://github.com/cta-wave/Test-Content/issues/4
HLS manifest can be done for free using our actual packager (GPAC) when generating the DASH manifest. However we need to check the manifest complies with CTA-WAVE recommendations.

2022-06-12 meeting: Closed. This is not relevant for the current test suite.


Implement service class for OpenSearch Dashboards

Signed-off-by: Tianle Huang<EMAIL_ADDRESS>Description
Implement ServiceOpenSearchDashboards. Currently it only has the functional part. Still in progress to add unit test.
Issues Resolved
closes https://github.com/opensearch-project/opensearch-build/issues/1080
Test
Manually switch LocalTestCluster to run this service. Below are the successful service ready checks.
With security
successfully ping 5601 with security

Running ./src/run_integ_test.py . ...
2021-11-23 04:33:43 INFO     Loading ./src/test_workflow/config/test_manifest.yml
2021-11-23 04:33:43 INFO     Loading /usr/share/opensearch/workspace/opensearch-build/dist/manifest.yml
2021-11-23 04:33:43 INFO     Loading /usr/share/opensearch/workspace/opensearch-build/builds/manifest.yml
2021-11-23 04:33:43 INFO     TestRecorder recording logs in /usr/share/opensearch/workspace/opensearch-build/test-results/4c110c451d554faab922c2a1bf085011/integ-test
2021-11-23 04:33:43 INFO     Executing "git init" in /tmp/tmp1df06t5a/functionalTestDashboards
2021-11-23 04:33:43 INFO     Executing "git remote add origin https://github.com/opensearch-project/opensearch-dashboards-functional-test.git" in /tmp/tmp1df06t5a/functionalTestDashboards
2021-11-23 04:33:43 INFO     Executing "git fetch --depth 1 origin e5c2326b3bfe098ca8820d13133703539cbaa790" in /tmp/tmp1df06t5a/functionalTestDashboards
2021-11-23 04:33:45 INFO     Executing "git checkout FETCH_HEAD" in /tmp/tmp1df06t5a/functionalTestDashboards
2021-11-23 04:33:46 INFO     Executing "git rev-parse HEAD" in /tmp/tmp1df06t5a/functionalTestDashboards
2021-11-23 04:33:46 INFO     Checked out https://github.com/opensearch-project/opensearch-dashboards-functional-test.git@e5c2326b3bfe098ca8820d13133703539cbaa790 into /tmp/tmp1df06t5a/functionalTestDashboards at e5c2326b3bfe098ca8820d13133703539cbaa790
2021-11-23 04:33:46 INFO     Creating local test cluster in /tmp/tmp1df06t5a/local-test-cluster
2021-11-23 04:33:46 INFO     Downloading bundle
2021-11-23 04:33:46 INFO     Copying /usr/share/opensearch/workspace/opensearch-build/dist/opensearch-dashboards-1.2.0-linux-x64.tar.gz into /tmp/tmp1df06t5a/local-test-cluster/opensearch-dashboards-1.2.0-linux-x64.tar.gz ...
2021-11-23 04:33:46 INFO     Downloaded bundle to /tmp/tmp1df06t5a/local-test-cluster/opensearch-dashboards-1.2.0-linux-x64.tar.gz
2021-11-23 04:33:46 INFO     Unpacking /tmp/tmp1df06t5a/local-test-cluster/opensearch-dashboards-1.2.0-linux-x64.tar.gz
2021-11-23 04:33:58 INFO     self.install_dir is /tmp/tmp1df06t5a/local-test-cluster/opensearch-dashboards-1.2.0-linux-x64
/tmp/tmp1df06t5a
bin  config  data  LICENSE.txt  manifest.yml  node  node_modules  NOTICE.txt  package.json  plugins  README.txt  src
2021-11-23 04:33:59 INFO     Unpacked /tmp/tmp1df06t5a/local-test-cluster/opensearch-dashboards-1.2.0-linux-x64.tar.gz
opensearch-dashboards  opensearch-dashboards-keystore  opensearch-dashboards-plugin
2021-11-23 04:33:59 INFO     self.stdout /tmp/tmpowv4ocam
2021-11-23 04:33:59 INFO     self.stderr /tmp/tmpz57pioev
2021-11-23 04:33:59 INFO     command ./opensearch-dashboards and cwd is /tmp/tmp1df06t5a/local-test-cluster/opensearch-dashboards-1.2.0-linux-x64/bin
2021-11-23 04:33:59 INFO     Started OpenSearch Dashboards with parent PID 3874342
2021-11-23 04:33:59 INFO     Waiting for service to become available
2021-11-23 04:33:59 INFO     Pinging service attempt 0
2021-11-23 04:33:59 INFO     Pinging http://localhost:5601/api/status
2021-11-23 04:33:59 INFO     Service not available yet
2021-11-23 04:33:59 INFO     - stdout:
2021-11-23 04:33:59 INFO
2021-11-23 04:33:59 INFO     - stderr:
2021-11-23 04:33:59 INFO
2021-11-23 04:34:09 INFO     Pinging service attempt 1
2021-11-23 04:34:09 INFO     Pinging http://localhost:5601/api/status
2021-11-23 04:34:09 INFO     200: {"name":"91b68901f49e","uuid":"3dd1bd17-6f7c-4355-ac63-b7a88bad1068","version":{"number":"1.2.0","build_hash":"caf668e73304bac890f41c37cd6c3a41257cd289","build_number":1,"build_snapshot":false},"status":{"overall":{"since":"2021-11-23T04:34:09.071Z","state":"green","title":"Green","nickname":"Looking good","icon":"success","uiColor":"secondary"},"statuses":[{"id":"core:opensearch@1.2.0","message":"OpenSearch is available","since":"2021-11-23T04:34:09.071Z","state":"green","icon":"success","uiColor":"secondary"},{"id":"core:savedObjects@1.2.0","message":"SavedObjects service has completed migrations and is available","since":"2021-11-23T04:34:09.071Z","state":"green","icon":"success","uiColor":"secondary"},{"id":"plugin:advancedSettings@1.2.0","message":"All dependencies are available","since":"2021-11-23T04:34:09.071Z","state":"green","icon":"success","uiColor":"secondary"},{"id":"plugin:bfetch@1.2.0","message":"All dependencies are available","since":"2021-11-23T04:34:09.071Z","state":"green","icon":"success","uiColor":"secondary"},{"id":"plugin:charts@1.2.0","message":"All dependencies are available","since":"2021-11-23T04:34:09.071Z","state":"green","icon":"success","uiColor":"secondary"},{"id":"plugin:devTools@1.2.0","message":"All dependencies are available","since":"2021-11-23T04:34:09.071Z","state":"green","icon":"success","uiColor":"secondary"},{"id":"plugin:discover@1.2.0","message":"All dependencies are available","since":"2021-11-23T04:34:09.071Z","state":"green","icon":"success","uiColor":"secondary"},{"id":"plugin:embeddable@1.2.0","message":"All dependencies are available","since":"2021-11-23T04:34:09.071Z","state":"green","icon":"success","uiColor":"secondary"},{"id":"plugin:expressions@1.2.0","message":"All dependencies are available","since":"2021-11-23T04:34:09.071Z","state":"green","icon":"success","uiColor":"secondary"},{"id":"plugin:indexPatternManagement@1.2.0","message":"All dependencies are available","since":"2021-11-23T04:34:09.071Z","state":"green","icon":"success","uiColor":"secondary"},{"id":"plugin:inspector@1.2.0","message":"All dependencies are available","since":"2021-11-23T04:34:09.071Z","state":"green","icon":"success","uiColor":"secondary"},{"id":"plugin:legacyExport@1.2.0","message":"All dependencies are available","since":"2021-11-23T04:34:09.071Z","state":"green","icon":"success","uiColor":"secondary"},{"id":"plugin:management@1.2.0","message":"All dependencies are available","since":"2021-11-23T04:34:09.071Z","state":"green","icon":"success","uiColor":"secondary"},{"id":"plugin:navigation@1.2.0","message":"All dependencies are available","since":"2021-11-23T04:34:09.071Z","state":"green","icon":"success","uiColor":"secondary"},{"id":"plugin:opensearchDashboardsOverview@1.2.0","message":"All dependencies are available","since":"2021-11-23T04:34:09.071Z","state":"green","icon":"success","uiColor":"secondary"},{"id":"plugin:opensearchDashboardsReact@1.2.0","message":"All dependencies are available","since":"2021-11-23T04:34:09.071Z","state":"green","icon":"success","uiColor":"secondary"},{"id":"plugin:opensearchDashboardsUsageCollection@1.2.0","message":"All dependencies are available","since":"2021-11-23T04:34:09.071Z","state":"green","icon":"success","uiColor":"secondary"},{"id":"plugin:opensearchDashboardsUtils@1.2.0","message":"All dependencies are available","since":"2021-11-23T04:34:09.071Z","state":"green","icon":"success","uiColor":"secondary"},{"id":"plugin:opensearchUiShared@1.2.0","message":"All dependencies are available","since":"2021-11-23T04:34:09.071Z","state":"green","icon":"success","uiColor":"secondary"},{"id":"plugin:savedObjects@1.2.0","message":"All dependencies are available","since":"2021-11-23T04:34:09.071Z","state":"green","icon":"success","uiColor":"secondary"},{"id":"plugin:savedObjectsManagement@1.2.0","message":"All dependencies are available","since":"2021-11-23T04:34:09.071Z","state":"green","icon":"success","uiColor":"secondary"},{"id":"plugin:share@1.2.0","message":"All dependencies are available","since":"2021-11-23T04:34:09.071Z","state":"green","icon":"success","uiColor":"secondary"},{"id":"plugin:uiActions@1.2.0","message":"All dependencies are available","since":"2021-11-23T04:34:09.071Z","state":"green","icon":"success","uiColor":"secondary"},{"id":"plugin:urlForwarding@1.2.0","message":"All dependencies are available","since":"2021-11-23T04:34:09.071Z","state":"green","icon":"success","uiColor":"secondary"},{"id":"plugin:visDefaultEditor@1.2.0","message":"All dependencies are available","since":"2021-11-23T04:34:09.071Z","state":"green","icon":"success","uiColor":"secondary"},{"id":"plugin:visualizations@1.2.0","message":"All dependencies are available","since":"2021-11-23T04:34:09.071Z","state":"green","icon":"success","uiColor":"secondary"},{"id":"plugin:visualize@1.2.0","message":"All dependencies are available","since":"2021-11-23T04:34:09.071Z","state":"green","icon":"success","uiColor":"secondary"},{"id":"plugin:ganttChartDashboards@1.2.0","message":"All dependencies are available","since":"2021-11-23T04:34:09.071Z","state":"green","icon":"success","uiColor":"secondary"},{"id":"plugin:observabilityDashboards@1.2.0","message":"All dependencies are available","since":"2021-11-23T04:34:09.071Z","state":"green","icon":"success","uiColor":"secondary"},{"id":"plugin:queryWorkbenchDashboards@1.2.0","message":"All dependencies are available","since":"2021-11-23T04:34:09.071Z","state":"green","icon":"success","uiColor":"secondary"},{"id":"plugin:apmOss@1.2.0","message":"All dependencies are available","since":"2021-11-23T04:34:09.071Z","state":"green","icon":"success","uiColor":"secondary"},{"id":"plugin:console@1.2.0","message":"All dependencies are available","since":"2021-11-23T04:34:09.071Z","state":"green","icon":"success","uiColor":"secondary"},{"id":"plugin:dashboard@1.2.0","message":"All dependencies are available","since":"2021-11-23T04:34:09.071Z","state":"green","icon":"success","uiColor":"secondary"},{"id":"plugin:data@1.2.0","message":"All dependencies are available","since":"2021-11-23T04:34:09.071Z","state":"green","icon":"success","uiColor":"secondary"},{"id":"plugin:home@1.2.0","message":"All dependencies are available","since":"2021-11-23T04:34:09.071Z","state":"green","icon":"success","uiColor":"secondary"},{"id":"plugin:inputControlVis@1.2.0","message":"All dependencies are available","since":"2021-11-23T04:34:09.071Z","state":"green","icon":"success","uiColor":"secondary"},{"id":"plugin:mapsLegacy@1.2.0","message":"All dependencies are available","since":"2021-11-23T04:34:09.071Z","state":"green","icon":"success","uiColor":"secondary"},{"id":"plugin:opensearchDashboardsLegacy@1.2.0","message":"All dependencies are available","since":"2021-11-23T04:34:09.071Z","state":"green","icon":"success","uiColor":"secondary"},{"id":"plugin:regionMap@1.2.0","message":"All dependencies are available","since":"2021-11-23T04:34:09.071Z","state":"green","icon":"success","uiColor":"secondary"},{"id":"plugin:tileMap@1.2.0","message":"All dependencies are available","since":"2021-11-23T04:34:09.071Z","state":"green","icon":"success","uiColor":"secondary"},{"id":"plugin:timeline@1.2.0","message":"All dependencies are available","since":"2021-11-23T04:34:09.071Z","state":"green","icon":"success","uiColor":"secondary"},{"id":"plugin:usageCollection@1.2.0","message":"All dependencies are available","since":"2021-11-23T04:34:09.071Z","state":"green","icon":"success","uiColor":"secondary"},{"id":"plugin:visTypeMarkdown@1.2.0","message":"All dependencies are available","since":"2021-11-23T04:34:09.071Z","state":"green","icon":"success","uiColor":"secondary"},{"id":"plugin:visTypeMetric@1.2.0","message":"All dependencies are available","since":"2021-11-23T04:34:09.071Z","state":"green","icon":"success","uiColor":"secondary"},{"id":"plugin:visTypeTable@1.2.0","message":"All dependencies are available","since":"2021-11-23T04:34:09.071Z","state":"green","icon":"success","uiColor":"secondary"},{"id":"plugin:visTypeTagcloud@1.2.0","message":"All dependencies are available","since":"2021-11-23T04:34:09.071Z","state":"green","icon":"success","uiColor":"secondary"},{"id":"plugin:visTypeTimeline@1.2.0","message":"All dependencies are available","since":"2021-11-23T04:34:09.071Z","state":"green","icon":"success","uiColor":"secondary"},{"id":"plugin:visTypeTimeseries@1.2.0","message":"All dependencies are available","since":"2021-11-23T04:34:09.071Z","state":"green","icon":"success","uiColor":"secondary"},{"id":"plugin:visTypeVega@1.2.0","message":"All dependencies are available","since":"2021-11-23T04:34:09.071Z","state":"green","icon":"success","uiColor":"secondary"},{"id":"plugin:visTypeVislib@1.2.0","message":"All dependencies are available","since":"2021-11-23T04:34:09.071Z","state":"green","icon":"success","uiColor":"secondary"},{"id":"plugin:alertingDashboards@1.2.0","message":"All dependencies are available","since":"2021-11-23T04:34:09.071Z","state":"green","icon":"success","uiColor":"secondary"},{"id":"plugin:anomalyDetectionDashboards@1.2.0","message":"All dependencies are available","since":"2021-11-23T04:34:09.071Z","state":"green","icon":"success","uiColor":"secondary"},{"id":"plugin:indexManagementDashboards@1.2.0","message":"All dependencies are available","since":"2021-11-23T04:34:09.071Z","state":"green","icon":"success","uiColor":"secondary"},{"id":"plugin:reportsDashboards@1.2.0","message":"All dependencies are available","since":"2021-11-23T04:34:09.071Z","state":"green","icon":"success","uiColor":"secondary"},{"id":"plugin:securityDashboards@1.2.0","message":"All dependencies are available","since":"2021-11-23T04:34:09.071Z","state":"green","icon":"success","uiColor":"secondary"}]},"metrics":{"last_updated":"2021-11-23T04:34:06.601Z","collection_interval_in_millis":5000,"os":{"platform":"linux","platformRelease":"linux-5.11.0-1020-aws","load":{"1m":0.48193359375,"5m":0.33056640625,"15m":0.3408203125},"memory":{"total_in_bytes":99010002944,"free_in_bytes":24924803072,"used_in_bytes":74085199872},"uptime_in_millis":2163305000,"distro":"CentOS","distroRelease":"CentOS-7.9.2009"},"process":{"memory":{"heap":{"total_in_bytes":152453120,"used_in_bytes":125050216,"size_limit":1526909922},"resident_set_size_in_bytes":187752448},"pid":3874342,"event_loop_delay":0.22176885604858398,"uptime_in_millis":7548},"response_times":{"avg_in_millis":0,"max_in_millis":0},"concurrent_connections":0,"requests":{"disconnects":0,"total":0,"statusCodes":{},"status_codes":{}}}}
2021-11-23 04:34:09 INFO     Service is available
2021-11-23 04:34:09 INFO     ===============================================
2021-11-23 04:34:09 INFO     Running integration tests for functionalTestDashboards
2021-11-23 04:34:09 INFO     ===============================================
2021-11-23 04:34:09 INFO     Executing "/tmp/tmp1df06t5a/functionalTestDashboards/integtest.sh -b localhost -p 9200 -s true -v 1.2.0" in /tmp/tmp1df06t5a/functionalTestDashboards

Without security
successfully ping 5601 without security

Running ./src/run_integ_test.py . ...
2021-11-23 04:15:21 INFO     Loading ./src/test_workflow/config/test_manifest.yml
2021-11-23 04:15:21 INFO     Loading /usr/share/opensearch/workspace/opensearch-build/dist/manifest.yml
2021-11-23 04:15:21 INFO     Loading /usr/share/opensearch/workspace/opensearch-build/builds/manifest.yml
2021-11-23 04:15:21 INFO     TestRecorder recording logs in /usr/share/opensearch/workspace/opensearch-build/test-results/b70374a0993040339f6a3f209a6eacc4/integ-test
2021-11-23 04:15:21 INFO     Executing "git init" in /tmp/tmp3kgepokj/functionalTestDashboards
2021-11-23 04:15:21 INFO     Executing "git remote add origin https://github.com/opensearch-project/opensearch-dashboards-functional-test.git" in /tmp/tmp3kgepokj/functionalTestDashboards
2021-11-23 04:15:21 INFO     Executing "git fetch --depth 1 origin e5c2326b3bfe098ca8820d13133703539cbaa790" in /tmp/tmp3kgepokj/functionalTestDashboards
2021-11-23 04:15:23 INFO     Executing "git checkout FETCH_HEAD" in /tmp/tmp3kgepokj/functionalTestDashboards
2021-11-23 04:15:24 INFO     Executing "git rev-parse HEAD" in /tmp/tmp3kgepokj/functionalTestDashboards
2021-11-23 04:15:24 INFO     Checked out https://github.com/opensearch-project/opensearch-dashboards-functional-test.git@e5c2326b3bfe098ca8820d13133703539cbaa790 into /tmp/tmp3kgepokj/functionalTestDashboards at e5c2326b3bfe098ca8820d13133703539cbaa790
2021-11-23 04:15:24 INFO     Creating local test cluster in /tmp/tmp3kgepokj/local-test-cluster
2021-11-23 04:15:24 INFO     Downloading bundle
2021-11-23 04:15:24 INFO     Copying /usr/share/opensearch/workspace/opensearch-build/dist/opensearch-dashboards-1.2.0-linux-x64.tar.gz into /tmp/tmp3kgepokj/local-test-cluster/opensearch-dashboards-1.2.0-linux-x64.tar.gz ...
2021-11-23 04:15:24 INFO     Downloaded bundle to /tmp/tmp3kgepokj/local-test-cluster/opensearch-dashboards-1.2.0-linux-x64.tar.gz
2021-11-23 04:15:24 INFO     Unpacking /tmp/tmp3kgepokj/local-test-cluster/opensearch-dashboards-1.2.0-linux-x64.tar.gz
2021-11-23 04:15:37 INFO     self.install_dir is /tmp/tmp3kgepokj/local-test-cluster/opensearch-dashboards-1.2.0-linux-x64
/tmp/tmp3kgepokj
bin  config  data  LICENSE.txt  manifest.yml  node  node_modules  NOTICE.txt  package.json  plugins  README.txt  src
2021-11-23 04:15:37 INFO     Unpacked /tmp/tmp3kgepokj/local-test-cluster/opensearch-dashboards-1.2.0-linux-x64.tar.gz
Removing securityDashboards...
Plugin removal complete
opensearch-dashboards  opensearch-dashboards-keystore  opensearch-dashboards-plugin
2021-11-23 04:15:37 INFO     self.stdout /tmp/tmpa89_hm67
2021-11-23 04:15:37 INFO     self.stderr /tmp/tmpruyt1x23
2021-11-23 04:15:37 INFO     command ./opensearch-dashboards and cwd is /tmp/tmp3kgepokj/local-test-cluster/opensearch-dashboards-1.2.0-linux-x64/bin
2021-11-23 04:15:37 INFO     Started OpenSearch Dashboards with parent PID 3862762
2021-11-23 04:15:37 INFO     Waiting for service to become available
2021-11-23 04:15:37 INFO     Pinging service attempt 0
2021-11-23 04:15:37 INFO     Pinging http://localhost:5601/api/status
2021-11-23 04:15:37 INFO     Service not available yet
2021-11-23 04:15:37 INFO     - stdout:
2021-11-23 04:15:37 INFO
2021-11-23 04:15:37 INFO     - stderr:
2021-11-23 04:15:37 INFO
2021-11-23 04:15:47 INFO     Pinging service attempt 1
2021-11-23 04:15:47 INFO     Pinging http://localhost:5601/api/status
2021-11-23 04:15:47 INFO     200: {"name":"91b68901f49e","uuid":"fa75ca02-62ea-4404-bbbd-b5dca066ae83","version":{"number":"1.2.0","build_hash":"caf668e73304bac890f41c37cd6c3a41257cd289","build_number":1,"build_snapshot":false},"status":{"overall":{"since":"2021-11-23T04:15:47.580Z","state":"green","title":"Green","nickname":"Looking good","icon":"success","uiColor":"secondary"},"statuses":[{"id":"core:opensearch@1.2.0","message":"OpenSearch is available","since":"2021-11-23T04:15:47.580Z","state":"green","icon":"success","uiColor":"secondary"},{"id":"core:savedObjects@1.2.0","message":"SavedObjects service has completed migrations and is available","since":"2021-11-23T04:15:47.580Z","state":"green","icon":"success","uiColor":"secondary"},{"id":"plugin:ganttChartDashboards@1.2.0","message":"All dependencies are available","since":"2021-11-23T04:15:47.580Z","state":"green","icon":"success","uiColor":"secondary"},{"id":"plugin:observabilityDashboards@1.2.0","message":"All dependencies are available","since":"2021-11-23T04:15:47.580Z","state":"green","icon":"success","uiColor":"secondary"},{"id":"plugin:queryWorkbenchDashboards@1.2.0","message":"All dependencies are available","since":"2021-11-23T04:15:47.580Z","state":"green","icon":"success","uiColor":"secondary"},{"id":"plugin:advancedSettings@1.2.0","message":"All dependencies are available","since":"2021-11-23T04:15:47.580Z","state":"green","icon":"success","uiColor":"secondary"},{"id":"plugin:bfetch@1.2.0","message":"All dependencies are available","since":"2021-11-23T04:15:47.580Z","state":"green","icon":"success","uiColor":"secondary"},{"id":"plugin:charts@1.2.0","message":"All dependencies are available","since":"2021-11-23T04:15:47.580Z","state":"green","icon":"success","uiColor":"secondary"},{"id":"plugin:devTools@1.2.0","message":"All dependencies are available","since":"2021-11-23T04:15:47.580Z","state":"green","icon":"success","uiColor":"secondary"},{"id":"plugin:discover@1.2.0","message":"All dependencies are available","since":"2021-11-23T04:15:47.580Z","state":"green","icon":"success","uiColor":"secondary"},{"id":"plugin:embeddable@1.2.0","message":"All dependencies are available","since":"2021-11-23T04:15:47.580Z","state":"green","icon":"success","uiColor":"secondary"},{"id":"plugin:expressions@1.2.0","message":"All dependencies are available","since":"2021-11-23T04:15:47.580Z","state":"green","icon":"success","uiColor":"secondary"},{"id":"plugin:indexPatternManagement@1.2.0","message":"All dependencies are available","since":"2021-11-23T04:15:47.580Z","state":"green","icon":"success","uiColor":"secondary"},{"id":"plugin:inspector@1.2.0","message":"All dependencies are available","since":"2021-11-23T04:15:47.580Z","state":"green","icon":"success","uiColor":"secondary"},{"id":"plugin:legacyExport@1.2.0","message":"All dependencies are available","since":"2021-11-23T04:15:47.580Z","state":"green","icon":"success","uiColor":"secondary"},{"id":"plugin:management@1.2.0","message":"All dependencies are available","since":"2021-11-23T04:15:47.580Z","state":"green","icon":"success","uiColor":"secondary"},{"id":"plugin:navigation@1.2.0","message":"All dependencies are available","since":"2021-11-23T04:15:47.580Z","state":"green","icon":"success","uiColor":"secondary"},{"id":"plugin:opensearchDashboardsOverview@1.2.0","message":"All dependencies are available","since":"2021-11-23T04:15:47.580Z","state":"green","icon":"success","uiColor":"secondary"},{"id":"plugin:opensearchDashboardsReact@1.2.0","message":"All dependencies are available","since":"2021-11-23T04:15:47.580Z","state":"green","icon":"success","uiColor":"secondary"},{"id":"plugin:opensearchDashboardsUsageCollection@1.2.0","message":"All dependencies are available","since":"2021-11-23T04:15:47.580Z","state":"green","icon":"success","uiColor":"secondary"},{"id":"plugin:opensearchDashboardsUtils@1.2.0","message":"All dependencies are available","since":"2021-11-23T04:15:47.580Z","state":"green","icon":"success","uiColor":"secondary"},{"id":"plugin:opensearchUiShared@1.2.0","message":"All dependencies are available","since":"2021-11-23T04:15:47.580Z","state":"green","icon":"success","uiColor":"secondary"},{"id":"plugin:savedObjects@1.2.0","message":"All dependencies are available","since":"2021-11-23T04:15:47.580Z","state":"green","icon":"success","uiColor":"secondary"},{"id":"plugin:savedObjectsManagement@1.2.0","message":"All dependencies are available","since":"2021-11-23T04:15:47.580Z","state":"green","icon":"success","uiColor":"secondary"},{"id":"plugin:share@1.2.0","message":"All dependencies are available","since":"2021-11-23T04:15:47.580Z","state":"green","icon":"success","uiColor":"secondary"},{"id":"plugin:uiActions@1.2.0","message":"All dependencies are available","since":"2021-11-23T04:15:47.580Z","state":"green","icon":"success","uiColor":"secondary"},{"id":"plugin:urlForwarding@1.2.0","message":"All dependencies are available","since":"2021-11-23T04:15:47.580Z","state":"green","icon":"success","uiColor":"secondary"},{"id":"plugin:visDefaultEditor@1.2.0","message":"All dependencies are available","since":"2021-11-23T04:15:47.580Z","state":"green","icon":"success","uiColor":"secondary"},{"id":"plugin:visualizations@1.2.0","message":"All dependencies are available","since":"2021-11-23T04:15:47.580Z","state":"green","icon":"success","uiColor":"secondary"},{"id":"plugin:visualize@1.2.0","message":"All dependencies are available","since":"2021-11-23T04:15:47.580Z","state":"green","icon":"success","uiColor":"secondary"},{"id":"plugin:alertingDashboards@1.2.0","message":"All dependencies are available","since":"2021-11-23T04:15:47.580Z","state":"green","icon":"success","uiColor":"secondary"},{"id":"plugin:anomalyDetectionDashboards@1.2.0","message":"All dependencies are available","since":"2021-11-23T04:15:47.580Z","state":"green","icon":"success","uiColor":"secondary"},{"id":"plugin:indexManagementDashboards@1.2.0","message":"All dependencies are available","since":"2021-11-23T04:15:47.580Z","state":"green","icon":"success","uiColor":"secondary"},{"id":"plugin:reportsDashboards@1.2.0","message":"All dependencies are available","since":"2021-11-23T04:15:47.580Z","state":"green","icon":"success","uiColor":"secondary"},{"id":"plugin:apmOss@1.2.0","message":"All dependencies are available","since":"2021-11-23T04:15:47.580Z","state":"green","icon":"success","uiColor":"secondary"},{"id":"plugin:console@1.2.0","message":"All dependencies are available","since":"2021-11-23T04:15:47.580Z","state":"green","icon":"success","uiColor":"secondary"},{"id":"plugin:dashboard@1.2.0","message":"All dependencies are available","since":"2021-11-23T04:15:47.580Z","state":"green","icon":"success","uiColor":"secondary"},{"id":"plugin:data@1.2.0","message":"All dependencies are available","since":"2021-11-23T04:15:47.580Z","state":"green","icon":"success","uiColor":"secondary"},{"id":"plugin:home@1.2.0","message":"All dependencies are available","since":"2021-11-23T04:15:47.580Z","state":"green","icon":"success","uiColor":"secondary"},{"id":"plugin:inputControlVis@1.2.0","message":"All dependencies are available","since":"2021-11-23T04:15:47.580Z","state":"green","icon":"success","uiColor":"secondary"},{"id":"plugin:mapsLegacy@1.2.0","message":"All dependencies are available","since":"2021-11-23T04:15:47.580Z","state":"green","icon":"success","uiColor":"secondary"},{"id":"plugin:opensearchDashboardsLegacy@1.2.0","message":"All dependencies are available","since":"2021-11-23T04:15:47.580Z","state":"green","icon":"success","uiColor":"secondary"},{"id":"plugin:regionMap@1.2.0","message":"All dependencies are available","since":"2021-11-23T04:15:47.580Z","state":"green","icon":"success","uiColor":"secondary"},{"id":"plugin:tileMap@1.2.0","message":"All dependencies are available","since":"2021-11-23T04:15:47.580Z","state":"green","icon":"success","uiColor":"secondary"},{"id":"plugin:timeline@1.2.0","message":"All dependencies are available","since":"2021-11-23T04:15:47.580Z","state":"green","icon":"success","uiColor":"secondary"},{"id":"plugin:usageCollection@1.2.0","message":"All dependencies are available","since":"2021-11-23T04:15:47.580Z","state":"green","icon":"success","uiColor":"secondary"},{"id":"plugin:visTypeMarkdown@1.2.0","message":"All dependencies are available","since":"2021-11-23T04:15:47.580Z","state":"green","icon":"success","uiColor":"secondary"},{"id":"plugin:visTypeMetric@1.2.0","message":"All dependencies are available","since":"2021-11-23T04:15:47.580Z","state":"green","icon":"success","uiColor":"secondary"},{"id":"plugin:visTypeTable@1.2.0","message":"All dependencies are available","since":"2021-11-23T04:15:47.580Z","state":"green","icon":"success","uiColor":"secondary"},{"id":"plugin:visTypeTagcloud@1.2.0","message":"All dependencies are available","since":"2021-11-23T04:15:47.580Z","state":"green","icon":"success","uiColor":"secondary"},{"id":"plugin:visTypeTimeline@1.2.0","message":"All dependencies are available","since":"2021-11-23T04:15:47.580Z","state":"green","icon":"success","uiColor":"secondary"},{"id":"plugin:visTypeTimeseries@1.2.0","message":"All dependencies are available","since":"2021-11-23T04:15:47.580Z","state":"green","icon":"success","uiColor":"secondary"},{"id":"plugin:visTypeVega@1.2.0","message":"All dependencies are available","since":"2021-11-23T04:15:47.580Z","state":"green","icon":"success","uiColor":"secondary"},{"id":"plugin:visTypeVislib@1.2.0","message":"All dependencies are available","since":"2021-11-23T04:15:47.580Z","state":"green","icon":"success","uiColor":"secondary"}]},"metrics":{"last_updated":"2021-11-23T04:15:45.004Z","collection_interval_in_millis":5000,"os":{"platform":"linux","platformRelease":"linux-5.11.0-1020-aws","load":{"1m":0.7177734375,"5m":0.36767578125,"15m":0.2822265625},"memory":{"total_in_bytes":99010002944,"free_in_bytes":24997011456,"used_in_bytes":74012991488},"uptime_in_millis":2162204000,"distro":"CentOS","distroRelease":"CentOS-7.9.2009"},"process":{"memory":{"heap":{"total_in_bytes":145113088,"used_in_bytes":117416624,"size_limit":1526909922},"resident_set_size_in_bytes":180658176},"pid":3862762,"event_loop_delay":0.21001386642456055,"uptime_in_millis":7442},"response_times":{"avg_in_millis":0,"max_in_millis":0},"concurrent_connections":0,"requests":{"disconnects":0,"total":0,"statusCodes":{},"status_codes":{}}}}
2021-11-23 04:15:47 INFO     Service is available

Check List

[x] Commits are signed per the DCO using --signoff

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

Codecov Report

Merging #1128 (979c424) into main (2cfdd09) will decrease coverage by 20.90%.
The diff coverage is n/a.

@@              Coverage Diff              @@
##               main    #1128       +/-   ##
=============================================
- Coverage     93.48%   72.58%   -20.91%
- Complexity        9       10        +1
=============================================
  Files            99        8       -91
  Lines          2488       62     -2426
  Branches          3        7        +4
=============================================
- Hits           2326       45     -2281
+ Misses          158        9      -149
- Partials          4        8        +4

Impacted Files
Coverage Δ

src/jenkins/InputManifest.groovy
62.50% <0.00%> (-12.50%)
:arrow_down:

src/manifests/build/build_manifest_1_1.py

src/test_workflow/integ_test/local_test_cluster.py

...est_workflow/test_result/test_component_results.py

src/build_workflow/builder_from_dist.py

..._workflow/input_manifests_opensearch_dashboards.py

src/build_workflow/build_artifact_checks.py

src/test_workflow/test_recorder/test_recorder.py

...rc/test_workflow/test_result/test_suite_results.py

src/run_manifests.py

... and 82 more

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 2cfdd09...979c424. Read the comment docs.

In progress to add unit test. Send incremental progress for early feedback.
Foreseeing more work for next step:

The build and assemble workflow uses the same file name for manifest files of OpenSearch and Dashboards. This may cause download issues when Dashboards Cluster needs to download both.
The functional test repo only exists in the build manifest instead of the bundle manifest. We may either need to add it to bundle manifest so that the logic for both services is same OR we may use build manifest instead for Dashboards.
We may need to have a separate test manifest file for Dashboards.


customized naming for user interaction spans

Is your feature request related to a problem? Please describe
The user interaction instrumentation attaches the element xpath to the span. When the element doesn't have an id, this results in something like "//html/body/div/div/div/div/div/div/div/div/button".
This can be hard to understand.
Describe the solution you'd like to see
Allow some other attribute than id to be used in the span. For example, opencensus-web supported
<button data-ocweb-id="myid">
Describe alternatives you've considered
You can attach an id to an element, but this is not always practical. Or the id may already be used in a way that is not helpful for humans reading the traces. (Say, randomly generated to ensure uniqueness).

maybe having the interceptor (hook) in config and then allowing simply add whatever you need by passing a span and element should fulfil all different cases and user needs. Similar we have for many other instrumentations. I would rather avoid adding some predefined attributes as this will always be not enough for certain user.

That sounds like a good solution.


Rails (<IP_ADDRESS>.alpha): Devise(4.4.3) Error: undefined local variable or method `mimes_for_respond_to' for DeviseController:Class

Environment

Ruby [2.4.1]
Rails [6.0.0.alpha]
Devise [4.4.3]

Current behavior
When I Upgraded application from rails 5.2 to 6.0.0.alpha, application starts getting crash showing error on sign_in page.
   Started GET "/admins/sign_in" for <IP_ADDRESS> at 2018-06-05 08:23:21 +0530
   (1.9ms)  SELECT "schema_migrations"."version" FROM "schema_migrations" ORDER BY "schema_migrations"."version" ASC
  ↳ /home/rotlu_crush/.rvm/gems/ruby-2.4.1/gems/activerecord-5.2.0/lib/active_record/log_subscriber.rb:98

ActionController::RoutingError (undefined local variable or method `mimes_for_respond_to' for DeviseController:Class):

devise (4.4.3) app/controllers/devise_controller.rb:18:in `<class:DeviseController>'
devise (4.4.3) app/controllers/devise_controller.rb:4:in `<main>'
bootsnap (1.3.0) lib/bootsnap/load_path_cache/core_ext/kernel_require.rb:100:in `load'
bootsnap (1.3.0) lib/bootsnap/load_path_cache/core_ext/kernel_require.rb:100:in `load'
activesupport (5.2.0) lib/active_support/dependencies.rb:468:in `block in load_file'
activesupport (5.2.0) lib/active_support/dependencies.rb:653:in `new_constants_in'
activesupport (5.2.0) lib/active_support/dependencies.rb:467:in `load_file'

Expected behavior
Devise wouldn't crash, It should work with rails 6.0.0.alpha

Rails 6 is really early in development and devise or responders have no plan to support a version of rails that early. We will fix those issue before the 6.0.0.beta release.


Ad-blocking does not work

I'm using blockify on arch linux and I've installed it through the AUR package (not the -git version.) blockify-ui shows the current track and I can change the track through it but when an ad plays it doesn't mute it and shows "No song playing?" in the window.
~$ blockify --version
3.0.2

2015-11-11 16:18:16 DEBUG    util     Added logging file handler: /home/julian/blockify.log.
2015-11-11 16:18:16 INFO     util     Loading configuration.
2015-11-11 16:18:16 INFO     util     Configuration file loaded from /home/julian/.config/blockify/blockify.ini.
2015-11-11 16:18:16 INFO     list     Blocklist loaded from /home/julian/.config/blockify/blocklist.txt.
2015-11-11 16:18:16 INFO     player   InterludePlayer initialized.
2015-11-11 16:18:16 DEBUG    player   Loading playlist.
2015-11-11 16:18:16 DEBUG    player   Stop: State is (<enum GST_STATE_CHANGE_SUCCESS of type GstStateChangeReturn>, <enum GST_STATE_NULL of type GstState>, <enum GST_STATE_VOID_PENDING of type GstState>).
2015-11-11 16:18:16 INFO     player   Playlist loaded (Length: 0).
2015-11-11 16:18:16 INFO     player   Playlist: []
2015-11-11 16:18:17 DEBUG    cli      Mute method is alsa or pulse without sinks.
2015-11-11 16:18:17 INFO     cli      No pulse sinks found, falling back to system mute via alsa/pulse.
2015-11-11 16:18:17 INFO     cli      Blockify initialized.
2015-11-11 16:18:17 INFO     cli      Blockify started.
2015-11-11 16:25:34 WARNING  cli      Spotify was closed!
2015-11-11 16:25:44 DEBUG    cli      2 received. Exiting safely.
2015-11-11 16:25:44 INFO     cli      Exiting safely. Bye.

When I start it in a terminal, something constantly prints
Cannot get client list properties.
(_NET_CLIENT_LIST or _WIN_CLIENT_LIST)

The log also says that it can't find pulse sinks but I'm using pulseaudio and I can mute spotify individually via pavucontrol. However, when I use the command pacmd list-sink-inputs it prints Daemon not responding..
"Show desktop notifications when the track changes" is enabled but I don't have any programs installed that would show the notification.
I'm using a fork of dwm as my window manager.

I was able to fix the pulseaudio issue by restarting pulseaudio but the rest remains the same.

It sounds like your window manager isn't EWHM compliant (https://en.wikipedia.org/wiki/Extended_Window_Manager_Hints).
wmctrl and by extension blockify relies on certain standards regarding window management being implemented by the window manager. If they are not, blockify simply won't work.
You could test this by trying out one of the window managers listed in the wikipedia article.

Thanks for the tip. After adding _NET_CLIENT_LIST support to the wm it works as advertised. However, after looking at the source code a bit, I have some questions/suggestions:

blockify seems to be manually polling the spotify state every 200ms. I'm not sure why the desktop notifications have to be enabled at all.

I think you could rewrite blockify to not use wmctrl (and not to require _NET_CLIENT_LIST) and to passively listen to spotify track changes. You can use

~$ xwininfo -root -children | grep -i spotify
     0x1600001 "spotify": ("spotify" "Spotify")  10x10+10+10  +10+10
     0x1800001 "Maroon 5 - Lucky Strike": ("spotify" "Spotify")  603x369+-1218+15  +-1218+15

to find the spotify window. And then you can use
~$ xprop -spy -id 0x1800001 | grep WM_NAME
_NET_WM_NAME(UTF8_STRING) = "Maroon 5 - Lucky Strike"
_NET_WM_NAME(UTF8_STRING) = "Wer beim Autofahren telefoniert, nimmt weniger wahr"

to wait for the _NET_WM_NAME property to change.

Thanks for the suggestion!
That method would rely heavily on the window manager setting the proper wm_name. The wm I'm using (Awesome) doesn't, for instance.
So while that would be a great method, I believe it wouldn't work universally.
P.S.: I'm sorry to hear you had to go through the code. I've taught myself programming writing Blockify and it shows ;)

In case you do feel like improving the ad detection method, you could take a look at #67 and #68 ;)
I'd love to do it but my linux machine is currently almost unusable due to hardware issues.


The io.js Built Team WG Proposal

We are putting together a governance model for the io.js build team, and are proposing that the docker-iojs team be a sub-working group of that team. To be part of this conversation, check out: https://github.com/iojs/build/pull/49

I'd like to limit my involvement to just docker-iojs for now, so a separate sub-group sounds good :+1:

Is there a list of members of the docker-iojs sub-working group some where?

@Starefossen not at the moment. We are still trying to iron out what it means to be a sub-working group.
We could do a pull request to our own README.md with those actively involved in dev.

Cool, thanks. I guess I'll hang around and see where it goes :smile:

@wblankenship btw what is the rationale for the docker-team being a sub-WG of Build? I don't think they are really related.

FYI, we don't have a provision for "sub-WG" in the governance model. Informally the term has been used for working groups that are basically being bootstrapped out of another WG (this happened with evangelism spinning out of the website WG."
While this behavior isn't documented the working group doc does set the expectation that working groups are basically already running and getting things done prior to being chartered so it's all fine :)

Thanks @mikeal
I think we should at least have a separate GitHub team (@iojs/docker). Not sure if this requires a separate WG as well.

Good idea, either @rvagg or I can set that up whenever you like :)

Closing as #39 was implemented instead


[WIP] drivers device interface improvements

This can wait until after v1.7.0.
Next step is to split CDev out of Device. Device is the base class for a physical device (eg i2c or spi sensor) with a bus, address, and unique id. There are many CDevs in the system (like all uORB topics) that aren't physical devices.
Additionally there are many device interfaces throughout common drivers like mpu6000, mpu9250, etc that don't need to be CDevs.

@dagar what du needed to get the WIP flag removed?


testport.sh: Fix make.conf not being respected

Currently, testport -c does not honour make.confs such as can be set
in poudriere.d/{*-}make.conf files, because the __MAKE_CONF variable [1]
is set to /dev/null, introduced in a43fe7cb to fix #545.
Accordingly, when using testport -c, when dialog4ports is run, it presents
information that does not match what is actually used/built because the
expected make environment(s) configurations are not used.
For example, this issue was identified while testing the www/py-autobahn
port, and make config (dialog4ports) was incorrectly displaying
py36-autobahn and py36 specific OPTIONS, when testport was in fact
building py27-autobahn and py27 specific OPTIONS (correctly) via -zpy27,
which contained a DEFAULT_VERSIONS=python=2.7 override.
The issue is not limited to package names and OPTIONS, but anything that
needs to take effect or be modified in the config target.
Conversely, the options command introduced a fix to "Fix make.conf not
being respected in 2d9b712b, introducing a setup_makeconf() function in
common.sh that constructs a make.conf based on global, tree, and set
specific make.conf's, if they are set.
This change utilises the setup_makeconf() function in common.sh, and
applies it to testport.sh to correctly respect make.confs when -c is used.
I have tested this locally with a patch against ports-mgmt/poudriere-devel
and confirmed that it correctly finds and appends all relevant make.confs,
and presents information in dialog4ports that is correct, and matches what
is used and built during the testport.
I wasn't sure whether the following CLEANUP_HOOK from options.sh also
needed to be replicated in testport.sh:
CLEANUP_HOOK=options_cleanup
options_cleanup() {
    rm -f ${__MAKE_CONF}
}

If it does, let me know and I'll that that to the PR
[1] man make.conf

If you want me to scope the directives inside the if [ $CONFIGSTR -eq 1 ]; then block let me know.
I'm not familiar with the impact or need either way, but I just tested it within the block and it seems to continue to resolve the problem, but only scoped to the make config call

A minor (visual) and harmless artifact, I just noticed after this is that 'Appending to make.conf' entries are printed twice, presumably once when creating jail or build environment, and once (with this PR) during make config:
[00:00:00] Creating the reference jail... done
[00:00:05] Mounting system devices for 12amd64-koobs-py27
[00:00:05] Mounting ports/packages/distfiles
[00:00:05] Using packages from previously failed build: /storage/poudriere/data/packages/12amd64-koobs-py27/.building
[00:00:05] Mounting packages from: /storage/poudriere/data/packages/12amd64-koobs-py27
[00:00:05] Copying /var/db/ports from: /usr/local/etc/poudriere.d/12amd64-koobs-py27-options
[00:00:05] Appending to make.conf: /usr/local/etc/poudriere.d/make.conf
[00:00:05] Appending to make.conf: /usr/local/etc/poudriere.d/py27-make.conf
/etc/resolv.conf -> /storage/poudriere/data/.m/12amd64-koobs-py27/ref/etc/resolv.conf
[00:00:05] Starting jail 12amd64-koobs-py27
[00:00:06] Ports supports: FLAVORS SELECTED_OPTIONS
[00:00:07] Appending to make.conf: /usr/local/etc/poudriere.d/make.conf
[00:00:07] Appending to make.conf: /usr/local/etc/poudriere.d/py27-make.conf

This may indicate a need for a minor refactor to do it (and print it) once during a testport (or underlying bulk), then applied for all later stages

I think you missed my comment to also rm the file afterwards.

Ah, I interpreted the original comment as 'if its moved into the if [ $CONFIGSTR -eq 1 ]; block then it 'will' clean it up.
Should we copy the form that exists in options.sh? That is ..
CLEANUP_HOOK=options_cleanup
options_cleanup() {
    rm -f ${__MAKE_CONF}
}

Nah just rm directly. The CLEANUP_HOOK is a good idea but it may interact poorly with the embedded bulk handling.

Thanks!


Go version bump

bump golang version for new dependencies

should we also update the go-version in .github/workflows/unit-tests.yml ?

yes, on staging this was already updated- we need to update main and then rebase staging

should we also update the go-version in .github/workflows/unit-tests.yml ?

yes, on staging this was already updated- we need to update main and then rebase staging

oh ok! sorry I didn't check that!

lgtm. I still question why we aren't bumping to 1.22

we can do 1.22 i'll update it


Need to make TLS versions in HAProxy configurable

We just caused a production downtime after updating to a new version of CF because we have some clients that aren't able to use TLS 1.2 (in our case it was https://stackoverflow.com/questions/29663974/wcf-client-in-net-4-51-how-to-enable-tls-1-2-when-webrequest-is-used) and this commit forced HAProxy to only accept that:
https://github.com/cloudfoundry/cf-release/commit/db20539ffcc15aff69862b77c2493d93e9a7c3d6
This option needs to be configurable and the default can be to disable SSLv3, TLS 1.0, and TLS 1.1 if desired. We just need to be able to turn back on 1.0 and 1.1.  Even worse, the change was not mentioned in the release notes so we missed it, again resulting in the production downtime for customers.  :-(
Aaron

Hi @amhuber. Thanks for bringing this to our attention.
First, apologies for failing to include this in release notes. My hope has always been that, if we have to make these kinds of changes, that we at least give proper context in the release notes.
As far as the actual request here to allow older versions of TLS for the HAProxy configuration, we'll need to follow the Gorouter's lead: If HAProxy starts accepting older versions of TLS but the Gorouter does not, then connections will fail between the proxy and the router. I see that you've opened a similar issue on the Gorouter. If @shalako and the Routing team sign off allowing older versions of TLS, we can make the parallel change to HAProxy.

This repository is no longer supported. Closing issue.


[WIP] [5.2] Cache: add increment and decrement to \Illuminate\Contracts\Cache\Repository

increment (and thus decrement) are missing in \Illuminate\Contracts\Cache\Repository
See https://github.com/laravel/framework/blob/5.2/src/Illuminate/Cache/RateLimiter.php#L61

Please send to 5.3.


fish support

Simple fish adapter. It takes the calculated PATH from bash.

Hey, I'm out of town. Will come back and check this out on Monday. Thanks :)

No clue about fish myself. Anyways, merging it.


Add SSL support

Is your feature request related to a problem? Please describe.
If you want to access a MikroTik device on an unreliable network it is unsafe without SSL/TLS.
Describe the solution you'd like
Use api-ssl instead of api even if with self signed or custom CA signed certificates.
Describe alternatives you've considered
There are not any alternatives of encrypted connections on unreliable networks.
Additional context

Hi @soosp
thanks for your feature request.
The underlying library already supports ssl-api.
tls: {
    rejectUnauthorized: false,
    ciphers: 'ADH-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384',
},
port: config.sslPort

I will try to add and test this in the next few days.

Hi @soosp
thanks for your feature request.
The underlying library already supports ssl-api.
tls: {
    rejectUnauthorized: false,
    ciphers: 'ADH-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384',
},
port: config.sslPort

I will try to add and test this in the next few days.

@soosp I added the functionality in the new 0.6.0 release.
Please can you test this and give me feedback

@soosp I added the functionality in the new 0.6.0 release.
Please can you test this and give me feedback

Thank you for this awesome quick solution! It was tested with self signed certificate and certificate signed with my custom CA. The mikrotik node has worked well in both case.

Thank you for this awesome quick solution! It was tested with self signed certificate and certificate signed with my custom CA. The mikrotik node has worked well in both case.


Implement Inline editing and inline add

I want to have add and edit the data in the table itself without having to go to separate a page for editing. Is there a way to implement this?

Dup of #3021.


x/pkgsite: add a way to opt in to https://beta.pkg.go.dev/

What is the URL of the page with the issue?
https://pkg.go.dev/
What is your user agent?

Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/85.0.4183.59 Safari/537.36

Screenshot
n/a
What did you do?
Visited https://pkg.go.dev/
What did you expect to see?
I would like to be able to set a cookie/other that allows https://pkg.go.dev/ to in effect be https://beta.pkg.go.dev/, in much the same way that users can opt-in to being redirected to https://pkg.go.dev/ from godoc.
What did you see instead?
No option to "opt in" to https://beta.pkg.go.dev/

If anyone is interested in working on this feature, here's the code for how users can opt-in to always being redirected from godoc.org to pkg.go.dev: https://github.com/golang/gddo/blob/721e228c7686d830b5decc691a4dc7e6a6e94888/gddo-server/main.go#L1161


Docs might be in the main repo

IMHO, it is a best practice to put source and docs in the same repo; so that every code change and related docs change go into the same commit.
I see that in order to maintain a connection between source and docs you are using git tags in both repos. Even so, you might consider moving docs to the main repo for better peace of mind.
Moving only en and zh folders (as they are the source for docs) would be enough and this repo (incubator-echarts-doc) would contain the build code for building docs.
Thanks for the great documentation.

Thanks for your suggestion. We usually update and merge the code ASAP while it usually takes more time to write the document, as long as if it's ready before the next release. We think this makes sure the code is merged ASAP to avoid conflict.


[NEW] Group chats by favorites

The app only allows grouping the chats room by type. Grouping by favorites should be possible to the user too.

The feature to star/unstar a chat room will be implemented soon. You can track its status here.
Regarding the "Group by Favorite" and changed your issue description so as soon as we implement it we'll close this issue.
Thanks for opening!

waiting patiently for this feature.


Kepubify runs out of memory on gigantic ebooks

I received a PM on MobileRead about a book (William Shakespeare Complete Works published by Modern Library) which was way bigger than anything I've seen before and causes kepubify to run out of memory during conversion.

This is only reproducible for me on devices with less than 4GB of available memory. Based on pprof, the memory issue seems to be due to regexps and something to do with the span adding.

The refactor I'm working on right now should fix this issue and greatly improve performance. One of the biggest changes in this area is optimizing the span adding by decreasing the number of memory allocations, streamlining the logic, and using a stack-based algorithm rather than recursion.


feat: Added File::OpenFor::ReadWrite

Description
This fixes a problem with FileHandle::memory_map where it was impossible to successfully memory map a file if it was opened using File::open with any value other than OpenFor::Reading.
Type of change

[x] New feature (non-breaking change which adds functionality)

How Has This Been Tested?
By creating a file (with File::open), and then calling memory_map on it.
Checklist

[x] I have added the necessary description of this PR to the changelog, and I have followed the same format as other entries.

This PR now also fixes the size of the std::span returned by memory_map being wrong.


Update GitHub Secrets Information in README

🗣 Description
This PR updates the section about GitHub Secrets in the README to mention the terraform-to-secrets tool in cisagov/development-guide. It also appropriately mentions needing appropriate permissions to view/add Secrets to the repository.

💭 Motivation and Context
The lack of clear language was brought up in #29 and @felddy created a tool to automagically add desired Secrets from Terraform states to a repository.

🧪 Testing
Just automated stuff.

📷 Screenshots (if appropriate)
🚥 Types of Changes

[ ] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (causes existing functionality to change)

✅ Checklist

[x] My code follows the code style of this project.
[ ] My change requires a change to the documentation.
[x] I have updated the documentation accordingly.
[x] I have read the CONTRIBUTING document.
[ ] I have added tests to cover my changes.
[x] All new and existing tests passed.

Changes look good @mcdonnnj - still approved by me. 👍


MBL-1822: Compose UI tests for ChangePasswordScreen

📲 What
Create ui tests for ChangePasswordScreen composable
🤔 Why
Compose makes testing ui much easier, and we should be taking advantage of this to make sure ui is working as expected.
🛠 How
New test suite with composable functions
👀 See
no user facing changes
📋 QA
Not much to QA, you can run the tests locally if youd like
Story 📖
MBL-1822: Compose UI tests for ChangePasswordScreen

:warning: Please install the  to ensure uploads and comments are reliably processed by Codecov.
Codecov Report
Attention: Patch coverage is 89.47368% with 2 lines in your changes missing coverage. Please review.

Project coverage is 68.42%. Comparing base (9f7b813) to head (754517f).

Files with missing lines
Patch %
Lines

...rter/ui/activities/compose/ChangePasswordScreen.kt
89.47%
2 Missing :warning:

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
Additional details and impacted files
@@             Coverage Diff              @@
##             master    #2157      +/-   ##
============================================
+ Coverage     67.99%   68.42%   +0.42%
  Complexity     2224     2224
============================================
  Files           365      365
  Lines         22756    22769      +13
  Branches       3262     3262
============================================
+ Hits          15474    15579     +105
+ Misses         5531     5430     -101
- Partials       1751     1760       +9

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


Adding proxy API's for etherscan

Hi I am extending the API's for proxy and will help for any other things in my free time. I will also write the remaining API's onceI find time.

@corpetty recommended that we stick to python3.6 What is your opinion ?

I agree that sticking with at least >= 3.5 is the way to go.

Thanks for asking, my app is running on Python 3.6, but indeed normally libraries should have quite wide support to different python versions. And this is currently enforced with tox checking for 2 and 3 https://github.com/corpetty/py-etherscan-api/blob/f3cd702/tox.ini
But well Python2 should be dropped at some point so I'm fine if we drop it https://pythonclock.org

@corpetty Nope, I am fine if we drop it too.

Please also drop Python2.7 from tox.ini otherwise Travis will fail https://travis-ci.org/corpetty/py-etherscan-api/jobs/390758838

@agatsoh please remove 2.7 from tox.ini and travis.yaml and re-PR

@agatsoh The naming of 'check_keys_api' is somewhat ambiguous. I feel like adding comments would be valuable here (and eventually required w/ linting integration).

@corpetty Why did that check fail?

Great! Still don't know why Travis didn't complain about it. It should be
turned on when another pull request fixes the errors :)
El lun., 25 jun. 2018 0:32, Taylor Dawson<EMAIL_ADDRESS>escribió:

@taylorjdawson commented on this pull request.
In tests/test_proxies.py
https://github.com/corpetty/py-etherscan-api/pull/35#discussion_r197655017
:

@@ -13,8 +13,8 @@ def test_get_most_recent_block(self):
api = Proxies(api_key=API_KEY)
# currently raises an exception even though it should not, see:
# https://github.com/corpetty/py-etherscan-api/issues/32

Okay just ran that. Got the same results. When should we switch flake8 to
the whole directory?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/corpetty/py-etherscan-api/pull/35#discussion_r197655017,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AABhjU9ROarsQLRYSQp6BuSd-DVDdyvgks5uABOSgaJpZM4Uifo9
.

We should have a slack/discord. Which would you guys prefer?

I was imagining the project to have his own gitter room. From what I remember, all it needs is the maintainer @corpetty to authenticate to https://gitter.im/ and pick a room. Then gitter bot will come with a pull request to add the gitter badge to the project README.
It's better if it's an "official room" created by the maintainer, because a bunch of hooks get added so we see pull requests and ticket updates directly in the room.

done: https://gitter.im/py-etherscan/Lobby#


Client Allocation Request for: Wenkeer

Client Allocation Questions
Core Information

Name: Wenkeer
Website / Social Media: https://www.mart.global/
Region: Greater China
DataCap Requested: 20TiB
Addresses to be Notarized: f13npbrhv4jryhgirvgcx2fvdiyvqvzsryeenfvna
Notary Requested: swatchliu

@notpj25 Please subscribe to notifications for this Issue to be aware of updates. Notaries may request additional information on the Issue.

Thanks for your request. Can you kindly add more information here?
Is your company located in Greater China？
Please give the following information and provide links to social media/news mentions.
Duration of establishment,
Number of employees,
Business scope and products or services,
Social media link (Weibo, WeChat, Douyin, Zhihu, Facebook, Twitter, Linkedin, e.g.)
Data size to be stored,
Have you already applied for DataCap to another notary, and whether it is accepted or rejected? Is there any reliable DataCap left?
Would you like to submit more company information on www.bytebase.cn?
Would you like to accept our face-to-face visit?

Thanks for your request.
Duration of establishment:
Wenkeer platform was established in Shanghai Free Trade Zone on Apri l8th 2021.
Number of employees:
We build a technical team 7 members.
Business scope and products or services:
Our company's main business is digital trading platform based on blockchain underlying technology+Web3.0 community .It involves art, meta-universe, media, entertainment. Our cooperative clients include: International Youth Art Research Center, Meta-Universe of Solomon Islands, Himalaya Art Museum, etc.
Social media link (Weibo, WeChat, Douyin, Zhihu, Facebook, Twitter, Linkedin, e.g.):
You can downloaded Wenkeer app on PC and mobile,
WeChat ID:gh_eed18270a8ea
Data size to be stored:
We have more than 50TiB of storage on our platform which can support the application.
Have you already applied for DataCap to another notary, and whether it is accepted or rejected? Is there any reliable DataCap left?
We haven't contacted any other notary yet, and  no reliable DataCap left.
Would you like to submit more company information on www.bytebase.cn?
I’m very glad to share more information on the web side.
Would you like to accept our face-to-face visit?
I’m looking forward to meeting you.

Request Approved
Your Datacap Allocation Request has been approved by the Notary
Message sent to Filecoin Network

bafy2bzacedyplukbe4sqejsqr3id7iidofkq7gbcvxa3ypdanr3jtnltv7oa4

Address

f13npbrhv4jryhgirvgcx2fvdiyvqvzsryeenfvna

Datacap Allocated

20.00TiB

Signer Address

f1yh6q3nmsg7i2sys7f7dexcuajgoweudcqj2chfi

You can check the status of the message here: https://filfox.info/en/message/bafy2bzacedyplukbe4sqejsqr3id7iidofkq7gbcvxa3ypdanr3jtnltv7oa4


Error while running R package

Thanks for giving me the pointer everything seems to be in order but I am still getting this error while trying to deploy the R model,
Traceback (most recent call last):
File "/Library/Frameworks/R.framework/Versions/3.5/Resources/library/Rclipper/build_container.py", line 9, in
version.registry, version.version)
AttributeError: 'module' object has no attribute 'registry'
To deploy this model, execute the following command from a connected ClipperConnection object conn:
conn.deploy_model("test-model", "1", "ints", "test-model:1", num_replicas=<num_container_replicas>)
Any Idea why I am getting this?

Hi @aliraza0337 , this might be clipper version issue.
Can you run pip install git+https://github.com/ucbrise/clipper.git#subdirectory=clipper_admin to make sure the installed clipper version matches the version Rclipper is calling from.
Basically what happened was:

RClipper will try to call a python script. This script is up to date.
The script will try to call clipper_admin package installed.
The package is not up to date with script.

I am getting a similar error with clipper-develop.
I tried pip install git+https://github.com/ucbrise/clipper.git#subdirectory=clipper_admin and it did NOT work.
Traceback (most recent call last):
File "/usr/local/lib/R/site-library/Rclipper/build_container.py", line 5, in
from clipper_admin import DockerContainerManager, ClipperConnection, ClipperException
File "/home/ubuntu/clipper-develop/clipper_admin/clipper_admin/clipper_admin.py", line 27, in
from .container_manager import CONTAINERLESS_MODEL_IMAGE, ClusterAdapter
ValueError: Attempted relative import in non-package
To deploy this model, execute the following command from a connected ClipperConnection object conn:
conn.deploy_model("r-csus-tc", "6", "strings", "r-csus-tc:6", num_replicas=<num_container_replicas>)

@simon-mo The above error is gone after I ran the update but now I am getting the following while running the admin
Traceback (most recent call last):
File "admin.py", line 7, in
conn.connect()
File "/Library/Python/2.7/site-packages/clipper_admin/clipper_admin.py", line 147, in connect
self.cm.connect()
File "/Library/Python/2.7/site-packages/clipper_admin/docker/docker_container_manager.py", line 261, in connect
self.redis_port = all_labels[CLIPPER_DOCKER_PORT_LABELS['redis']]
KeyError: 'ai.clipper.redis.port'
Thanks for your help

@aliraza0337 You might need to kill the existing clipper docker containers before starting a new connection. From my experience, this error occurs when there's dangling containers. You can do so by running docker kill $(docker ps -q) in your terminal.

@csmithnm where are you running the the script? From the traceback, the clipper package that the R/python runtime found was located at /home/ubuntu/clipper-develop/clipper_admin/.... however it should be located at either a conda environement of python runtime (typically they are located under a directory called site-pakages within python folder.
I have seen this error occurs when i start my R or python REPL within clipper folder. Most of the time, switching to some other place to run the REPL will help.

I tried the above command and after that ran docker container ls it showed no container, but I am still get the above error.

It now works. I was forcing Python to look in the /home/ubuntu/clipper-develop/clipper_admin/clipper_admin/clipper_admin.py via the PYTHONPATH environment variable. I removed the PYTHONPATH environment variable and now the build works!!!  Thank You!  I have been working getting Clipper to with with R for MONTHS without any luck. I am hoping this version will do the trick.

But be careful with the clipper-develop version when you try to deploy. The Clipper developers added default-cluster onto the name of the Docker image:
clipper_conn.deploy_model("r-csus-tc", "6", "strings", "default-cluster-r-csus-tc:6", num_replicas=1)

One more thing even if when I run the R code given here:
http://clipper.ai/tutorials/r-deployment/#build-a-model
It gives the expected output, but when I run docker container ls I don't see any container.

In case you missed it, just bumping it up.
This is the output if starting R model.
Alis-MacBook-Pro:RCode aliraza$ Rscript model.R
Loading required package: CodeDepends
Loading required package: histry
[1] "Serialized list of dependent libraries: Rclipper: knitr: histry: CodeDepends: stats: graphics: grDevices: utils: datasets: methods: base"
[1] "Serialized model function!"
[1] "Done!"
18-07-07:16:40:10 INFO     [clipper_admin.py:467] [default-cluster] Building model Docker image with model data from /tmp/clipper//2018-07-07-16-40-08.583
18-07-07:16:40:12 INFO     [clipper_admin.py:472] [default-cluster] Step 1/2 : FROM clipper/r-container-base:develop
18-07-07:16:40:12 INFO     [clipper_admin.py:472] [default-cluster]  ---> b81704bec464
18-07-07:16:40:12 INFO     [clipper_admin.py:472] [default-cluster] Step 2/2 : COPY /tmp/clipper//2018-07-07-16-40-08.583 /model/
18-07-07:16:40:12 INFO     [clipper_admin.py:472] [default-cluster]  ---> c51d1cce5daf
18-07-07:16:40:12 INFO     [clipper_admin.py:472] [default-cluster] Successfully built c51d1cce5daf
18-07-07:16:40:12 INFO     [clipper_admin.py:472] [default-cluster] Successfully tagged default-cluster-test-model:1
18-07-07:16:40:12 INFO     [clipper_admin.py:474] [default-cluster] Pushing model Docker image to default-cluster-test-model:1
To deploy this model, execute the following command from a connected ClipperConnection object `conn`:
conn.deploy_model("test-model", "1", "ints", "test-model:1", num_replicas=<num_container_replicas>)

This is when I start admin:
Traceback (most recent call last):
  File "check.py", line 4, in <module>
    conn.connect()
  File "/Library/Python/2.7/site-packages/clipper_admin/clipper_admin.py", line 147, in connect
    self.cm.connect()
  File "/Library/Python/2.7/site-packages/clipper_admin/docker/docker_container_manager.py", line 261, in connect
    self.redis_port = all_labels[CLIPPER_DOCKER_PORT_LABELS['redis']]
KeyError: 'ai.clipper.redis.port'

what do you think causing it crash, second after running the R model, I don't see any container. when I do docker container ls.

@aliraza0337 :
http://clipper.ai/tutorials/r-deployment/#deploy-and-link-the-model assumes that a Clipper cluster is running on localhost with a registered application that has the name app1. So you must execute other commands before it.
from clipper_admin import ClipperConnection, DockerContainerManager
conn = ClipperConnection(DockerContainerManager())
# Start Clipper cluster
conn.start_clipper()
# Register 'app1' application to Clipper
conn.register_application(name="app1", input_type="ints", default_output="-1.0", slo_micros=100000)

and then,
conn.connect()

# Deploy a single replica of the model
conn.deploy_model(name="test-model", version="1", input_type="ints", image="test-model:1", replicas=1)

conn.link_model_to_app(app_name="app1", model_name="test-model")

Hi @withsmilo
I have tried what you suggested up there, I get the following error.
18-07-09:19:54:53 INFO     [docker_container_manager.py:151] [default-cluster] Starting managed Redis instance in Docker 18-07-09:19:54:55 INFO     [docker_container_manager.py:229] [default-cluster] Metric Configuration Saved at /private/var/folders/9l/nb5rkvcx70xgfcttqmzqc7dm0000gn/T/tmptIBmbl.yml 18-07-09:19:54:56 INFO     [clipper_admin.py:138] [default-cluster] Clipper is running 18-07-09:19:54:56 INFO     [clipper_admin.py:215] [default-cluster] Application app1 was successfully registered 18-07-09:19:54:56 INFO     [clipper_admin.py:151] [default-cluster] Successfully connected to Clipper cluster at localhost:1337 18-07-09:19:54:56 INFO     [docker_container_manager.py:353] [default-cluster] Found 0 replicas for test-model:1. Adding 1 Traceback (most recent call last):   File "/Users/aliraza/Desktop/SummerEco/RCode/check.py", line 11, in <module>     conn.deploy_model("test-model", "1", "ints", "test-model:1", num_replicas=1)   File "/Library/Python/2.7/site-packages/clipper_admin/clipper_admin.py", line 560, in deploy_model     num_replicas=num_replicas)   File "/Library/Python/2.7/site-packages/clipper_admin/docker/docker_container_manager.py", line 279, in deploy_model     self.set_num_replicas(name, version, input_type, image, num_replicas)   File "/Library/Python/2.7/site-packages/clipper_admin/docker/docker_container_manager.py", line 358, in set_num_replicas     image)   File "/Library/Python/2.7/site-packages/clipper_admin/docker/docker_container_manager.py", line 333, in _add_replica     **self.extra_container_kwargs)   File "/Library/Python/2.7/site-packages/docker/models/containers.py", line 768, in run     self.client.images.pull(image, platform=platform)   File "/Library/Python/2.7/site-packages/docker/models/images.py", line 412, in pull     self.client.api.pull(repository, tag=tag, **kwargs)   File "/Library/Python/2.7/site-packages/docker/api/image.py", line 399, in pull     self._raise_for_status(response)   File "/Library/Python/2.7/site-packages/docker/api/client.py", line 231, in _raise_for_status     raise create_api_error_from_http_exception(e)   File "/Library/Python/2.7/site-packages/docker/errors.py", line 31, in create_api_error_from_http_exception     raise cls(e, response=response, explanation=explanation) docker.errors.ImageNotFound: 404 Client Error: Not Found ("pull access denied for test-model, repository does not exist or may require 'docker login'") [Finished in 4.1s with exit code 1] [shell_cmd: python -u "/Users/aliraza/Desktop/SummerEco/RCode/check.py"] [dir: /Users/aliraza/Desktop/SummerEco/RCode] [path: /Library/Frameworks/Python.framework/Versions/3.6/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/Applications/Wireshark.app/Contents/MacOS]

@aliraza0337 :
You got this error,
docker.errors.ImageNotFound: 404 Client Error: Not Found ("pull access denied for test-model, repository does not exist or may require 'docker login'")

Did you execute Rclipper::build_model("test-model", ...)? If you had the success to build your R model, you can find your own Docker image(test-model) through docker images.

yes, I do execute that, as I you can see in my R code above at the bottom of my comment, this is how my Rcode looks and it runs with out error:
""
library(Rclipper)
pred_fn = function(inputs) {
return(lapply(inputs, function(input) {
return(as.character(length(input)))
}))
}
Rclipper::build_model("test-model", "1", pred_fn, sample_input = as.integer(c(1,2,3)))
""

check.py
from clipper_admin import ClipperConnection, DockerContainerManager
conn = ClipperConnection(DockerContainerManager())
# Start Clipper cluster
conn.start_clipper()
# Register 'app1' application to Clipper
conn.register_application(name="app1", input_type="ints", default_output="-1.0", slo_micros=100000)
conn.connect()

# Deploy a single replica of the model
#conn.deploy_model(name="test-model", version="1", input_type="ints", image="test-model:1", replicas=1)
conn.deploy_model("test-model", "1", "ints", "test-model:1", num_replicas=1)

conn.link_model_to_app(app_name="app1", model_name="test-model")

docker images
REPOSITORY                         TAG                            IMAGE ID            CREATED             SIZE
default-cluster-test-model         1                              9c35423eda51        29 seconds ago      895MB
<none>                             <none>                         a9c74a7b65ac        7 minutes ago       895MB
<none>                             <none>                         ebe176dec507        32 minutes ago      895MB
invoker                            latest                         3d20b3124b85        About an hour ago   392MB
whisk/invoker                      latest                         3d20b3124b85        About an hour ago   392MB
whisk/controller                   latest                         671ebdeba61c        About an hour ago   312MB
controller                         latest                         671ebdeba61c        About an hour ago   312MB
scala                              latest<PHONE_NUMBER>d9        About an hour ago   199MB
whisk/scala                        latest<PHONE_NUMBER>d9        About an hour ago   199MB
<none>                             <none>                         086803fedf77        5 hours ago         895MB
<none>                             <none>                         5ad6ef43085b        5 hours ago         895MB
<none>                             <none>                         2542ee614c64        5 hours ago         895MB
<none>                             <none>                         cf48375592ef        5 hours ago         895MB
<none>                             <none>                         9fdaa6b79592        5 hours ago         895MB
<none>                             <none>                         55ab263006bf        5 hours ago         895MB
<none>                             <none>                         3d604fd6fe8a        5 hours ago         895MB
<none>                             <none>                         1cc0c2719348        5 hours ago         895MB
<none>                             <none>                         3210a27d6855        5 hours ago         895MB
<none>                             <none>                         9ef18972ed0d        5 hours ago         895MB
<none>                             <none>                         0d1922e38d68        5 hours ago         895MB
openwhisk/apigateway               latest                         7bcaf99cc58d        8 hours ago         555MB
openwhisk/invoker                  latest                         34da23791748        10 hours ago        392MB
openwhisk/controller               latest                         4ea6bda7a2b8        10 hours ago        312MB
adoptopenjdk/openjdk8              jdk8u172-b11-alpine            1cd02d9d8566        30 hours ago        193MB
<none>                             <none>                         41a930450952        2 days ago          895MB
<none>                             <none>                         a47255ab3cc1        2 days ago          895MB
<none>                             <none>                         ffce634f4c04        2 days ago          895MB
<none>                             <none>                         27b0933d5ecd        2 days ago          895MB
<none>                             <none>                         d73b5663977d        2 days ago          895MB
<none>                             <none>                         bcc16b928915        2 days ago          895MB
<none>                             <none>                         c51d1cce5daf        2 days ago          895MB
<none>                             <none>                         72348ee9e11d        3 days ago          895MB
<none>                             <none>                         c73e9f2cc6f6        3 days ago          895MB
<none>                             <none>                         19a4e18370cf        3 days ago          895MB
<none>                             <none>                         8655a77571c2        3 days ago          895MB
default-cluster-sum-model1         2                              7c9abfcc8417        3 days ago          460MB
default-cluster-sum-model          1                              e58781ea5bb6        3 days ago          460MB
<none>                             <none>                         ee1e23344228        3 days ago          895MB
zookeeper                          3.4                            ef4e95d0f320        3 days ago          147MB
redis                              alpine                         4a1adec0b3ab        3 days ago          28.4MB
clipper/python-closure-container   develop                        76a098e0f6ee        3 weeks ago         460MB
clipper/query_frontend             develop                        e9f3003fe4c8        3 weeks ago         1.85GB
clipper/management_frontend        develop                        52b6407ef38a        3 weeks ago         1.85GB
clipper/frontend-exporter          develop                        c29b40eb6336        4 weeks ago         148MB
clipper/r-container-base           develop                        b81704bec464        4 weeks ago         895MB
minio/minio                        RELEASE.2018-05-04T23-13-12Z   7c079871e874        2 months ago        29.4MB
openwhisk/nodejs6action            latest                         18e881851d8e        2 months ago        538MB
prom/prometheus                    v2.1.0                         c8ecf7c719c1        5 months ago        112MB
couchdb                            1.6                            827c620e2004        8 months ago        226MB
confluentinc/cp-kafka-rest         3.3.1                          12a1d317a72a        8 months ago        440MB
landoop/kafka-topics-ui            0.9.3                          78d75abcbd70        8 months ago        26MB
actionproxy                        latest                         25d1878c2f31        9 months ago        109MB
openwhisk/dockerskeleton           latest                         25d1878c2f31        9 months ago        109MB
whisk/actionproxy                  latest                         25d1878c2f31        9 months ago        109MB
wurstmeister/kafka                 <IP_ADDRESS>                       b994f889ee53        9 months ago        265MB
ddragosd/ansible                   <IP_ADDRESS>-debian8                83abf1a2bf1c        9 months ago        243MB
redis                              2.8                            481995377a04        2 years ago         186MB

@simon-mo added 'default-cluster' to Docker image's name on the latest 'develop' branch by this commit. So I think that you must execute like this,
conn.deploy_model("test-model", "1", "ints", "default-cluster-test-model:1", num_replicas=1)

Okay this time, it didnt give error, but not correct out put. I guess CURL command has issue:
curl -X POST --header "Content-Type:application/json" -d '{"input": [1,2,3,4]}' <IP_ADDRESS>:1337/app1/predict
As we don't have predict here?

never mind, it seem to be working. Thanks alot :)

@aliraza0337 👍

@withsmilo it works sometime and sometime its not giving the correct output :/
It gives,
{"query_id":18,"output":-1.0,"default":true,"default_explanation":"No connected models found for query"}

Check Clipper_query_frontend's logs when querying your inputs.
$ docker container ls
$ docker logs --tail 100 -f <query_frontend_container_ID>


Ability to make resumes in other languages

It's possible to do it by just allowing to change more headings like "Address" and "Website"

just saw apparently there are translations available. not sure how to use them yet but will figure it out