Add unit tests for RespondActivityTaskFailedByID in frontend API handler

What changed?
Add unit tests for RespondActivityTaskFailedByID in frontend api handler

Why?
Improve test coverage and stability

How did you test it?
Unit tests

Potential risks

Release notes

Documentation Changes

Pull Request Test Coverage Report for Build 018fe099-4d86-443c-bab5-7ae16970a85d
Details

0 of 0   changed or added relevant lines in 0 files are covered.
182 unchanged lines in 15 files lost coverage.
Overall coverage decreased (-0.04%) to 69.738%

Files with Coverage Reduction
New Missed Lines
%

common/task/weighted_round_robin_task_scheduler.go
1
89.05%

common/persistence/sql/sqlplugin/mysql/task.go
2
73.68%

service/history/task/transfer_active_task_executor.go
2
72.79%

common/util.go
2
91.78%

service/history/task/fetcher.go
2
85.57%

common/persistence/sql/sqlplugin/mysql/db.go
2
79.49%

service/history/handler/handler.go
3
96.2%

common/task/fifo_task_scheduler.go
3
84.54%

common/archiver/filestore/historyArchiver.go
4
80.95%

service/history/task/transfer_standby_task_executor.go
6
86.33%

Totals

Change from base Build 018fe051-df14-4702-b515-0388c6db07f3:
-0.04%

Covered Lines:
103168

Relevant Lines:
147936

💛  - Coveralls


Deployment on jelastic wants to connect on precompile

Hi there,
When trying to deploy an Play! 1.2.4 based Web App using latest Morphia plugin 1.2.4d on jelastic (with jelastic 0.1 module), I get the following exception:
http://support.jelastic.com/discussions/problems/1549-howto-deploy-play-app-which-is-using-morphia
Seems like the Morphia plugin wants to connect (from my local build machine, which cannot reach into the jelastic net) already to the MongoDB on the precompiling step. Any ideas on how this can be avoided?
Thanks,
Niko

From your console log information, the precompiling step is already done.
And the error happened when application start, and play server starts
another precompiling process, which is wierd. I don't think this is a
morphia issue, because the connecting process happened in
onApplicationStart hook, which is a correct behavior
On Wed, Feb 29, 2012 at 5:14 AM, Niko Schmuck <
<EMAIL_ADDRESS>
wrote:

Hi there,
When trying to deploy an Play! 1.2.4 based Web App using latest Morphia
plugin 1.2.4d on jelastic (with jelastic 0.1 module), I get the following
exception:
http://support.jelastic.com/discussions/problems/1549-howto-deploy-play-app-which-is-using-morphia
Seems like the Morphia plugin wants to connect (from my local build
machine, which cannot reach into the jelastic net) already to the MongoDB
on the precompiling step. Any ideas on how this can be avoided?
Thanks,
Niko

Reply to this email directly or view it on GitHub:
https://github.com/greenlaw110/play-morphia/issues/69

In the
https://github.com/Fameing/play-jelastic/blob/master/src/play/modules/jelastic/Jelastic.java
,
go to line 167, it calls Play.init(), which in turn will call Play.start()
and trigger Morphia module to connect database. I think the problem is
here. If you are just deploy, you should not try to start the application.
Not only morphia will call startup hooks, but also all other modules will
do the same thing, and if there are resources cannot be reached, the whole
process will crash.
On Wed, Feb 29, 2012 at 7:27 AM, green<EMAIL_ADDRESS>wrote:

From your console log information, the precompiling step is already done.
And the error happened when application start, and play server starts
another precompiling process, which is wierd. I don't think this is a
morphia issue, because the connecting process happened in
onApplicationStart hook, which is a correct behavior
On Wed, Feb 29, 2012 at 5:14 AM, Niko Schmuck <
<EMAIL_ADDRESS>
wrote:

Hi there,
When trying to deploy an Play! 1.2.4 based Web App using latest Morphia
plugin 1.2.4d on jelastic (with jelastic 0.1 module), I get the following
exception:
http://support.jelastic.com/discussions/problems/1549-howto-deploy-play-app-which-is-using-morphia
Seems like the Morphia plugin wants to connect (from my local build
machine, which cannot reach into the jelastic net) already to the MongoDB
on the precompiling step. Any ideas on how this can be avoided?
Thanks,
Niko

Reply to this email directly or view it on GitHub:
https://github.com/greenlaw110/play-morphia/issues/69

Thanks so much for analyzing, I will forward your conclusion over to the folks at jelastic.


Outdated Azure SWA CLI

If someone tries to run rule editor locally with the most recent version of Azure SWA CLI, they will get a 404 on the emulator<EMAIL_ADDRESS>is the version running on engine but the CLI is on version 1.1.10 which is incompatible..

We need to update the document to specify that version 1.1.6 is required and newer version will not work in the short term
we need to update rule editor to work with the newer versions in the long term to run rule editor

The documentation has been updated, this is not a versioning issue


Added testcase for yum update

There are issues reported during "yum update".
This test case is for capturing them.

@LiliDeng LGTM


blank? returns false when passed nil value

Is this the expected behavior? If so, it seems counterintuitive. Also, it differs from the clojure.string/blank? which returns true when nil is passed.
I was using cuerdas as a "mostly" compatible enhancement to clojure.string namespace. Perhaps I was wrong.

This library from its origins, strictly works with strings, this means it does not understand nil as empty seq or empty string.
In fact, nil is nil, or in other words it is not a empty or blank string.
Probably all functions in cuerdas that receive nil will return nil (probably with few exceptions).
Being strict and does not treat nil as string in some predicates has its tradeoffs, but from my perspective I needed a library that works with strings. I don't want to have blank? validation return true when no string is provided per example. If I want to accept nil, I should probably do something like: (or (nil? x) (str/blank? x)) (explicitly specifying that nil are allowed)

I totally agree with the decision of this library only focusing on string types. But, "nil punning" is a commonly used idiom in Clojure. There is a chance people will get confused, like me. After discovering this behavior (because of a test case not behaving as expected), I had to hunt down all use of blank? in a large code base and replace it with something like you suggested.
Anyway, I think it would have been better if this was documented somewhere.

Anyway, I think it would have been better if this was documented somewhere.

Sure, I will put a large warning on top of the documentation page. Thanks for the suggestion.

An additional option can be adding a set of new predicates like blank-or-nil? (only the companions to predicates that makes sense). PR welcome for this.


Please support Mono, at least support it for one MVC client in samples

Is there any configuration to make Single-Sign On on mono using IdentityServer3. I don't have Windows computer to use Microsoft itself. Make one sample mvc server/client which can be run on Mono with right settings.
Now I am stuck on:
"Could not load type 'Microsoft.IdentityModel.Tokens.Saml2SecurityTokenHandler' from assembly 'Microsoft.IdentityModel.Protocol.Extensions, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=31bf3856ad364e35'."
when I run "MVC Owin Client Implicit" sample

I would also be very interested in a mono sample.

You can try porting this to Mono:
https://github.com/IdentityServer/IdentityServer3.Samples/tree/master/source/Clients/MvcFormPostClient


adapt exception message to the actual command executed

if ansible fails to copy a file, the error message moving it failed, which is confusing while debugging permissions.. :)

Hey, sorry I let this fall by the wayside for so long. I actually just merged a different change with more fixes which fixes this message as well, so I'm going to close this without merging.
I do appreciate the PR though!


[FLINK-13058][Table SQL / Runtime] Avoid memory copy for the trimming operations of BinaryString

What is the purpose of the change
For trimming operations of BinaryString (trim, trimLeft, trimRight), if the trimmed string is identical to the original string (which is likely to happen in practice). The memory copy can be avoided by directly returning the original string.
Brief change log

Change the implementations for trim, trimLeft & trimRight methods

Verifying this change
This change is already covered by existing tests, such as (BinaryStringTest).
Does this pull request potentially affect one of the following parts:

Dependencies (does it add or upgrade a dependency): (no)
The public API, i.e., is any changed class annotated with @Public(Evolving): (no)
The serializers: (no)
The runtime per-record code paths (performance sensitive): (yes)
Anything that affects deployment or recovery: JobManager (and its components), Checkpointing, Yarn/Mesos, ZooKeeper: (no)
The S3 file system connector: (no)

Documentation

Does this pull request introduce a new feature? (no)
If yes, how is the feature documented? (not applicable)

CI report for commit 7cbfc8c4a202fb6102a8e14f353a29207b4cd2da: SUCCESS Travis


Maven repo

It would be great if you upload the library to maven, thus making it easier to install via gradle.

yes I'll do this. thank you

+1

Is this on Gradle/Maven?

+1

+1

Is it available in Maven yet?

any updates?


[perf]: performance tuning

Objective:

current goal: analyze basic execution flow and fix known issues
Next stage: run the rooch process independently and simulate performance data by means of external calls. Rich parameter support will be provided

The following steps address the current goal:
Analyze bottlenecks in the basic execution flow:

optimize bench related code to help narrow the problem domain for pprof to locate the problem #1395
use pprof-rs to get bottleneck (enough to get rough bottleneck information）

Known issues:

DA and executor share tx buffer, resulting in blocking when DA submits batch executor append tx: DA server by DA control concurrency, tx buffer use read/write cache to reduce blocking
bitcoin block as a parameter causes the transaction output json is too large: when converting RoochTransaction to MoveTransaction, fetcher is used to get the content of the block, and pass it to the VM. Move provides a native method to get the block of bitcoin through hash.

too old data, move to #3031


runtime: Swiss Table maps can double size multiple times when deleting/adding elements

Go version
go version go1.24rc1 (Edit: I had incorrect version here)
Output of go env in your module/workspace:
N/A

What did you do?
When repeatedly deleting and adding elements from a Swiss Table map but without increasing the count of elements, the map can grow multiple times (e.g., from 128 slots to 1024 slots in a ~30s test).
I think there is currently a simplification in the current implementation (compared to Abseil and the CockroachDB implementations) such that it is expected that some growth occurs in lieu of a same-sized grow or rehashing in place, but it seemed worth a tracking bug that tables can end up growing substantially larger.
Here's a sample test demonstrating this:
https://go.dev/play/p/RITVDebV5op?v=gotip
It's runnable on the playground, where it sometimes fails or passes, though the main intent is to run locally.
Using that test, here's a sample run that starts with a ~10% load (14 elements in a map with an underlying table size of 128), then loops 1M times deleting and adding a different element (while never going above 14 elements in the map). The map's underlying table grows from 128 slots to 512 slots while doing that delete/add cycle 1M times:
$ go1.24rc1 test -count=3 -v -loop=1000000 -run=TestTombstoneGrow/tableSize=128/elems=14
=== RUN   TestTombstoneGrow
=== RUN   TestTombstoneGrow/tableSize=128/elems=14/load=0.109
    main_test.go:33: before delete/add loop: len(m)=14, underlying table size=128, map=0xc00002b140
    table: growing: old size=128, new size=256, map=0xc00002b140
    table: growing: old size=256, new size=512, map=0xc00002b140
    main_test.go:53: [after delete/add loop]  len(m)=14, underlying table size=512, map=0xc00002b140
    main_test.go:56: got 2 allocations per run
--- FAIL: TestTombstoneGrow (0.34s)
    --- FAIL: TestTombstoneGrow/tableSize=128/elems=14/load=0.109 (0.34s)

Those results above include using a minor hack into the runtime to report the underlying table size and print when tables grow.
If we instead loop 100M times on that same test, the map grows from 128 table slots to 1024 table slots:
$ go1.24rc1 test -count=3 -v -loop=100000000 -run=TestTombstoneGrow/tableSize=128/elems=14
=== RUN   TestTombstoneGrow
=== RUN   TestTombstoneGrow/tableSize=128/elems=14/load=0.109
    main_test.go:33: before delete/add loop: len(m)=14, underlying table size=128, map=0xc00002b140
    table: growing: old size=128, new size=256, map=0xc00002b140
    table: growing: old size=256, new size=512, map=0xc00002b140
    table: growing: old size=512, new size=1024, map=0xc00002b140
    main_test.go:53: [after delete/add loop]  len(m)=14, underlying table size=1024, map=0xc00002b140
    main_test.go:56: got 2 allocations per run
--- FAIL: TestTombstoneGrow (33.86s)
    --- FAIL: TestTombstoneGrow/tableSize=128/elems=14/load=0.109 (33.86s)

If we just loop, say, 100 times, the table does not grow, as expected:
$ go1.24rc1 test -count=3 -v -loop=100 -run=TestTombstoneGrow/tableSize=128/elems=14
=== RUN   TestTombstoneGrow
=== RUN   TestTombstoneGrow/tableSize=128/elems=14/load=0.109
    main_test.go:33: before delete/add loop: len(m)=14, underlying table size=128, map=0xc00002b140
    main_test.go:53: [after delete/add loop]  len(m)=14, underlying table size=128, map=0xc00002b140
--- PASS: TestTombstoneGrow (0.00s)
    --- PASS: TestTombstoneGrow/tableSize=128/elems=14/load=0.109 (0.00s)

One note of caution regarding the accuracy of this as a bug report -- test pass/failure here is being reported using testing.AllocsPerRun to see if an alloc occurs, but either I'm holding it wrong or seems to be flakey or both. (I was purposefully not using a more conventional runs number like 100, but maybe that's a mistake).
CC @prattmic
What did you see happen?
8x memory used.
What did you expect to see?
Less than 8x. Using an extra ~2x memory might be OK as a near-term simplification, but 8x seems high, and the memory can grow further.

Related Issues

runtime: map memory usage grows as it changes even though number of entries does not grow #16070 (closed)
runtime: consider growing map on iteration #51410 (closed)

Related Code Changes

runtime: use SwissTable
runtime: limit the number of map overflow buckets

(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)

(Ah, after stepping away, I realized my mistake with testing.AllocsPerRun. I was trying to set things up so that a "good" result was zero allocs, but that was a mistake, or at least, I did it incorrectly such that the t.Fatalf was not catching everything. Probably not super important to the main report here, but correcting that shows similar results, but now it reports a pass/fail more reliably I think: https://go.dev/play/p/xiWudCQADt5?v=gotip)

The rationale for leaving this as a TODO and not immediately adding a same size grow is that growth should be logarithmic. Each time the map grows from tombstones it gets harder and harder to create enough tombstones to grow again.
Luckily your test seems to agree with this. While I think we'll want same size grow eventually, IMO 100M iterations to grow from 128 to 1024 is not that bad. Or rather, it seems unlikely to cause significant problems in a real production application. But its definitely good to keep this open for reports if folks do run into issues.

Hi @prattmic, it does indeed get harder and harder, and it makes sense to have the focus be on real-world apps (including my understanding is that you've already seen the new code running very successfully against real-world apps).
Regarding the 100M loop example growing from 128 slots to 1024 slots, I'll just briefly note that for that one, I happened to pick a very low load of around 10% as the starting point.
If I do the same experiment starting at a table size of 128 but start instead at a ~43% load (which could hypothetically be just after a "natural" grow) or at ~87% load (just before a grow), then it takes around 100K loops and 10K loops respectively to have the tombstones push it from a 128 table size to 1024:
$ go1.24rc1 test -count=3 -v -loop=100000 -run=TestTombstoneGrow/tableSize=128/elems=56
=== RUN   TestTombstoneGrow/tableSize=128/elems=56/load=0.438
    table: growing: old size=128, new size=256, map=0xc00002b180
    table: growing: old size=256, new size=512, map=0xc00002b180
    table: growing: old size=512, new size=1024, map=0xc00002b180
    table: growing: old size=128, new size=256, map=0xc00002b1c0
    table: growing: old size=256, new size=512, map=0xc00002b1c0
    table: growing: old size=512, new size=1024, map=0xc00002b1c0
    main_test.go:59: after delete/add loop: len(m)=56, underlying table size=1024, map=0xc00002b1c0
    main_test.go:65: got 10 allocations per run
--- FAIL: TestTombstoneGrow (0.03s)

$ go1.24rc1 test -count=3 -v -loop=10000 -run=TestTombstoneGrow/tableSize=128/elems=112
=== RUN   TestTombstoneGrow/tableSize=128/elems=112/load=0.875
    table: growing: old size=128, new size=256, map=0xc0000ba200
    table: growing: old size=256, new size=512, map=0xc0000ba200
    table: growing: old size=512, new size=1024, map=0xc0000ba200
    table: growing: old size=128, new size=256, map=0xc0000ba240
    table: growing: old size=256, new size=512, map=0xc0000ba240
    table: growing: old size=512, new size=1024, map=0xc0000ba240
    main_test.go:59: after delete/add loop: len(m)=112, underlying table size=1024, map=0xc0000ba240
    main_test.go:65: got 10 allocations per run
--- FAIL: TestTombstoneGrow (0.01s)

(I don't think that's a surprise result either -- higher starting load means the tombstones need to do less at the start to get their first grow).
In any event, makes sense to see how this compares against other possible future refinements. Thanks for taking a look!


[AKS] Fix typo on VirtualMachineScaleSets and update references to Kubernetes versions

Description
Updated the help text to fix one typo that was missing an 's' on VirtualMachineScaleSets. Fixes #13945
Snapped all references to Kubernetes versions to one that is currently supported. Fixes #13922

This checklist is used to make sure that common guidelines for a pull request are followed.

[X] The PR title and description has followed the guideline in Submitting Pull Requests.

[X] I adhere to the Command Guidelines.

AKS


TypeError: Cannot read properties of undefined (reading 'code_snippet')

TypeError: Cannot read properties of undefined (reading 'code_snippet')    at zE (http://<IP_ADDRESS>:8000/:72:257091)    at mi (http://<IP_ADDRESS>:8000/:72:70706)    at Ql (http://<IP_ADDRESS>:8000/:72:122308)    at xc (http://<IP_ADDRESS>:8000/:72:109797)    at _c (http://<IP_ADDRESS>:8000/:72:109725)    at Cc (http://<IP_ADDRESS>:8000/:72:109588)    at Nc (http://<IP_ADDRESS>:8000/:72:106582)    at hc (http://<IP_ADDRESS>:8000/:72:103958)    at nu (http://<IP_ADDRESS>:8000/:72:119816)    at http://<IP_ADDRESS>:8000/:72:121187

Hi, thanks for letting is know. This looks like a duplicate of #59. We'll continue the issue there!


Add ability to remove history or start new conversations with the same agent

⚠ Please check that this feature request hasn't been suggested before.

[X] I searched previous Ideas in Discussions didn't find any similar feature requests.
[X] I searched previous Issues didn't find any similar feature requests.

🔖 Feature description
I think it would be a good feature to add the ability to reset chat history or make new conversations with the same agent
📝 Additional Context
No response
Acknowledgements

[X] My issue title is concise and descriptive.
[X] I have searched the existing issues to make sure this feature has not been requested yet.
[X] I have provided enough information for the maintainers to understand and evaluate this request.

@ahnedeee We have released something called sessions which allows you to do this without explicitly deleting memory. You can pass in a session key when you do a predict request to an agent to start a fresh memory!


support change instance of $fetch for using in useFetch and ...

Describe the feature
Suppose we need add automatically some headers for all requests ( for example Bearer token ) how can doing it without pass in all requests ?
i think we must have api to change default $fetch instance to using it on all useFetch requests
Additional information

[ ] Would you be willing to help implement this feature?
[ ] Could this feature be implemented as a module?

Final checks

[X] Read the contribution guide.
[X] Check existing discussions and issues.

You can wrap useFetch in another composable.
async function fetchApi(...) { return await useFetch(...);}

Indeed, creating your own composable based on useFetch (or useAsyncData) is the way to go here ☺


[BIG ONE] New features and minor bugfixes

Add the ability to create punishments through the WebUI in admin session (behavior for when there is a currently active punishment can be chosen in settings.php)
Add the ability to edit soft/silent attributes in editban/mute modals
Prevent setting an empty reason in punishment modals (empty reasons get replaced with '(WebUI)'
Allow only vertical resizing of the reason textarea in modals, preventing it from surpassing the width of the modal
Change some class names for mute modals (were using the ban classes before)

Adds the ability to change punish mode through admin panel
Fixes a bug with player_kicks setting, where it would get the value from player_warnings


Non-optional psycopg2

The poetry file has psycopg2 set as an optional dependency, but django will fail setup when it's unable to load it:
  File "/bot/rosetta/scripts.py", line 53, in start     django.setup()
django.core.exceptions.ImproperlyConfigured: Error loading psycopg2 module: No module named 'psycopg2'
I made the dependency mandatory and removed the extra install section of the poetry install file.

Further investigation suggests a pg_config is needed to build from source.
Rosetta is the component that needs the module:
Traceback (most recent call last):   File "/home/<redacted>/.cache/pypoetry/virtualenvs/rosetta-5Czp34tN-py3.8/lib/python3.8/site-packages/django/db/backends/postgresql/base.py", line 25, in <module>     import psycopg2 as Database ModuleNotFoundError: No module named 'psycopg2'
Appears the options are:

Add the pg_config required for building from source
Convert to psycopg2-binary as the dependency

The poetry file has psycopg2 set as an optional dependency, but django will fail setup when it's unable to load it:
 File "/bot/rosetta/scripts.py", line 53, in start django.setup()
django.core.exceptions.ImproperlyConfigured: Error loading psycopg2 module: No module named 'psycopg2'
I made the dependency mandatory and removed the extra install section of the poetry install file.

Django does not necessarily use PostgreSQL, it's what I'm using in production but a user on their own deployment could easily configure the django app to instead use SQLite or MySQL etc. Therefore it's not a mandatory dependency for rosetta and it's a conditional dependency depending on the configuration of the user, that was the reasoning for not having it mandatory.

Further investigation suggests a pg_config is needed to build from source.
Rosetta is the component that needs the module:
Traceback (most recent call last): File "/home/<redacted>/.cache/pypoetry/virtualenvs/rosetta-5Czp34tN-py3.8/lib/python3.8/site-packages/django/db/backends/postgresql/base.py", line 25, in <module> import psycopg2 as Database ModuleNotFoundError: No module named 'psycopg2'
Appears the options are:
* Add the pg_config required for building from source

* Convert to psycopg2-binary as the dependency

The latter option has been tested and resolves the issue.

This heavily depends on the system and Python version used.

Further investigation suggests a pg_config is needed to build from source.
Rosetta is the component that needs the module:
Traceback (most recent call last): File "/home/<redacted>/.cache/pypoetry/virtualenvs/rosetta-5Czp34tN-py3.8/lib/python3.8/site-packages/django/db/backends/postgresql/base.py", line 25, in <module> import psycopg2 as Database ModuleNotFoundError: No module named 'psycopg2'
Appears the options are:
* Add the pg_config required for building from source

* Convert to psycopg2-binary as the dependency

The latter option has been tested and resolves the issue.

This heavily depends on the system and Python version used.


Git resolver should consider oauthtoken for private catalog

Feature request
Currently, github resolver does not consider oauthtoken when they lookup the file in resolver param.
So basically, it's not possible to use private catalog via github now.
I think github is one of the major scm so it's good to support it first.
Use case
Use private github repo as resolver.

@vdemeester i'd like to contribute here. i'm a new contributor. i have basic understanding of tekton pipelines and explored the codebase to some extent. can you help me in figuring out where to add the oauth token, with some high level steps?

@vdemeester i'd like to contribute here. i'm a new contributor. i have basic understanding of tekton pipelines and explored the codebase to some extent. can you help me in figuring out where to add the oauth token, with some high level steps?

Thank you @santhoshivan23!
@tektoncd/core-maintainers anyone with expertise on remote resolution who can provide some guidance here?

/lifecycle frozen


Refine soma_joinid/soma_rowid handling

Affects both R & Python
Related to #324 and #325
Current thinking is that we want the handling of soma_joinid/soma_rowid to be explicit, eg,

soma_joinid/int64 - (materialized column) explicit in read, get schema, writes, etc.  create op will enforce existence and type. No magic population of the column, user must explicitly specify values.
soma_rowid/int64 - (pseudo-column only in SOMADataFrame), explicit in schema (create, get schema ops), explicit in read (always present unless user overrides with subset of column names), explicit in writes (it is the coordinate into the dense array)

[x] Python implementation
[ ] R implementation

@aaronwolen - any chance this is fixed?  It is done in Python, and I suspect it is done in R at this point.

@aaronwolen @eddelbuettel  -  I believe the R work for this is complete.  Can you close it if you agree?  Python side has been complete for a long while.  Note that with the removal of the "dense" DataFrame, much of this issue is obsolete.

This isn't done but I'll be sure to get it added to our next sprint.

With #642 in the books I think we can close. @bkmartinjr?

With #642 in the books I think we can close. @bkmartinjr?

OK w/ me!  Thanks for doing the lift on this...


[DELETE] feat(backend): add postgres support for dataproc migration

This PR includes functionality to migrate Postgres tables with no schema changes via Dataproc
Branched from PR: https://github.com/cloudspannerecosystem/harbourbridge/pull/520

Closing as PR raised on dataproc branch #594


chore: pin cosmo keycloak version in default values

Motivation and Context

TODO

[ ] Tests or benchmark included
[ ] Documentation is changed or added on https://app.gitbook.com/
[ ] PR title must follow conventional-commit-standard

Helm diff is dirty @StarpTech


Feed URL
https://mangeshm.xyz/index.xml
More Info
No response

closed by https://github.com/murtuzaalisurti/rssed/commit/22f63efbb89df3853949b53727ff45624836fa86


Remove tests for ERC4624

Remove:

https://github.com/ubiquity/ubiquity-dollar/blob/development/packages/contracts/test/dollar/ERC4626.t.sol
https://github.com/ubiquity/ubiquity-dollar/blob/development/packages/contracts/src/dollar/mocks/MockERC4626.sol

Will take on this for my first task as I understand the code base

Will take on this for my first task as I understand the code base

@rndquu Are you ok that @Hendobox will be assigned to this bounty?

Wait, if its just deleting two files we shouldn't be paying $100 for that.

Will take on this for my first task as I understand the code base

@rndquu Are you ok that @Hendobox will be assigned to this bounty?

sure

Wait, if its just deleting two files we shouldn't be paying $100 for that.
I guess its too late because we already have an open PR. I should have checked the new issues created (which I implicitly approved) more carefully. To fix this part of the process, @rndquu next time you create bounties, please continue to set time estimates, and priorities. However let me assign to @ubiquity-bounties in order to officially approve and release the bounties to the DevPool.

the smallest time estimate we have is "<1 Day"
we have a "time precision" feature in the bot's issues https://github.com/ubiquity/bounty-bot/issues/77 but it is not yet implemented

Hi can u assign me this issue. I was not able to do diamond optimization but i want to contribute to ubiquity pay.

@Eren-Yeaager hi, this issue is already solved, so @pavlovcik we can close it


Claiming i915 resources in a single container has 2 cards accessible for Intel GPU Flex 140

Summary
With default allocation policy "none", shared-dev-num=10 and Intel® Data Center GPU Flex 140 - if a container is allocated  3 or more gpu.intel.com/i915 resources, 2 gpu cards are accessible in the pod.
Detail
On Openshift 4.12 cluster, created gpu device plugin CR with allocation-policy none and shared-dev-num 10- on a node with Intel GPU Flex 140 card. So the node has 2 cards  and 20 gpu.intel.com/i915 resources. For clinfo pod, if 1 or 2 gpu.intel.com/i915 resources are allocated, one card is accessible from the pod.
sh-4.4$ cd /dev/dri
sh-4.4$ ls
card0  renderD128

If more than three resources are allocated both the cards are accessible inside the pod
sh-4.4$ cd /dev/dri
sh-4.4$ ls
card0  card1  renderD128  renderD129

Is this expected by design?
Possible solutions

Card sharing: Card sharing from the drivers/hardware perspective is limited/not supported. Though 2 containers can share card, there's no card isolation for containers and can have security concerns.  As we cannot use GAS yet, can we assume there is no way to support card sharing among containers? Is it possible to disable the sharing of card- i.e change the resource-allocation-policy options.  That means user can only input shared dev num and one container can use the card exclusively.

Inconsistency of claiming resources and access to gpu devices: Do containers need multiple i915 resources? In the case of packed policy, shared-dev-num:3, each container requesting 2 resources- one container has access to 1 card, another container has access to 2 cards. 1 container should claim i915 resource, but they can claim more than 1 i915 resource
To resolve it, can containers be limited to request only 1 i915 resource each?

Thanks!

Thanks for reaching out!
In short, the scenario is by design. The best option for you is to modify the deployment to use balanced mode. For 140 vs. 170, GPU-plugin threats them as same. For now we are not planning on changing the default allocation policy.
Longer story:
With shared-dev-num GPU-plugin creates artificial devices for the node card0-0, card0-1, card0-2 etc. Each of them represent the same card on the node. With multiple cards, plugin generates card0-0, card0-1, card1-0, card1-1, card2-0, card2-1 etc. When GPU-plugin is requested to allocate i915 resources to a container, it gets a list of possibilities from kubelet. With none allocation policy, plugin just selects the first n devices (order is not guaranteed) and returns them. So in the worst case, by requesting 10x i915s, you might only get one card in the container.
Our GPU Aware Scheduler provides better granularity to reserve GPUs, but it's a bigger effort to set up:
https://github.com/intel/platform-aware-scheduling/tree/master/gpu-aware-scheduling

This tells more about the features supported by the GPU Aware Scheduler (GAS): https://github.com/intel/platform-aware-scheduling/blob/master/gpu-aware-scheduling/docs/usage.md
Note that there are few gotchas in installing GAS, see: https://github.com/intel/platform-aware-scheduling/issues/126

Thanks for your quick response, we will have a look at how GAS handles it.
However, for the current design, It might cause some inconsistent issue.
For example:
on Flex 140 with 2 GPU Cards, we set Shared-dev-num as 3, and mode as packaked. And we have a set of containers that claim i915 resouces as 2 for each container.  and on the cluster, only one Flex 140 there.
For the first container scheduled to access the i915 resource. it only access the single card(card0).
But the second container can access 2 cards(card0, card 1).
And the third container can only see and access singel card(card1)
So with the same configurations, the different container might have different access permission to the two cards. That makes system results and behavior not consistent anymore.
I think maybe the possible solution is to limit the i915 resource to 1 for each container. That can resolve all the potential issue.
Thanks!

Thanks for reaching out!
In short, the scenario is by design. The best option for you is to modify the deployment to use balanced mode. For 140 vs. 170, GPU-plugin threats them as same. For now we are not planning on changing the default allocation policy.
Longer story: With shared-dev-num GPU-plugin creates artificial devices for the node card0-0, card0-1, card0-2 etc. Each of them represent the same card on the node. With multiple cards, plugin generates card0-0, card0-1, card1-0, card1-1, card2-0, card2-1 etc. When GPU-plugin is requested to allocate i915 resources to a container, it gets a list of possibilities from kubelet. With none allocation policy, plugin just selects the first n devices (order is not guaranteed) and returns them. So in the worst case, by requesting 10x i915s, you might only get one card in the container.
Our GPU Aware Scheduler provides better granularity to reserve GPUs, but it's a bigger effort to set up: https://github.com/intel/platform-aware-scheduling/tree/master/gpu-aware-scheduling

Thank you! So the none policy allocates number of cards(in this case 1 or 2) for each pod randomly, irrespective of how many resources requested? Is my understanding right? In this example case of balanced mode, for containers requesting <= 2 resources, it shows one card. For resources > 2, it shows 2 cards. Is this expected as well?

Yes, "i915" resource is for number of GPU devices that should be visible [1] within given container.
GPU plugin share count (CLI option) is just an upper limit on to how many containers the given GPU device may be assigned at the same time.
When using just the GPU plugin, you can limit each container to its own GPU device only by using share count of 1.
Whereas with GAS, you specify the sharing using GPU memory and millicore resource requests (and having large enough share count for GPU plugin to support that sharing), like you would do with k8s CPU resources.
If e.g. at max 2 containers should be given the same GPU, containers should request half a core i.e. 500 millicores (see linked GAS docs for pod spec examples).
Note that these GPU resource requests are just used for pod scheduling and device assignment decisions, there's no (cgroup based) enforcement for them, like there's for CPU resources  [2].
To avoid GPU being underutilized (when it has not enough work to do), or container perf suffering (when GPU has too much work), those requests should roughly correspond to how much GPU your workload actually uses.  You can check that  e.g. with the intel_gpu_top CLI tool from the intel-gpu-tools package.  Or if you have Prometheus / Grafana running in your cluster, you can use XPU manager [3] to export GPU resource usage info to Prometheus: https://github.com/intel/xpumanager

[1] Whether those devices can actually be used when container uses some other user ID than root, depends on the user ID, device file access rights on the node hosts, and container runtime settings. For more info, see: https://kubernetes.io/blog/2021/11/09/non-root-containers-and-devices/
[2] Upstream kernel DRM infrastructure does not support cgroup for GPUs yet.  Currently, enforcing things for GPU sharing would require e.g. GPU that supports SR-IOV (as Flex does) and configuring the SR-IOV partitions beforehand.  Each SR-IOV partition will then show up as separate GPU.
[3] Most of GPU metrics are available for the SR-IOV PF device, not for the VFs.  GPU plugin handles that by providing only VFs for "i915" resource requests, and "i915_monitoring" resource (requested by GPU exporters) including also PF device in addition to all VFs.  Note: monitoring resource needs to be explicitly enabled with GPU plugin option, it's not enabled by default.

Thank you! So the none policy allocates number of cards(in this case 1 or 2) for each pod randomly, irrespective of how many resources requested- Its different each time, is my understanding right? In this example case of balanced mode, for containers requesting <= 2 resources, it shows one card. For resources > 2, it shows 2 cards. Is this expected as well?

None policy can result in 1 or 2 actual GPUs to the container if i915 == 2. Balanced policy should result in 2 actual GPUs to the container if i915 == 2. If this is not the case, can you supply logs for me to check? You'll have to add "-v=5" to gpu-plugin arguments as the default doesn't print much of anything.
https://github.com/intel/intel-device-plugins-for-kubernetes/blob/main/deployments/gpu_plugin/overlays/monitoring_shared-dev_nfd/add-args.yaml#L13

For the first container scheduled to access the i915 resource. it only access the single card(card0).
But the second container can access 2 cards(card0, card 1).
And the third container can only see and access singel card(card1)

Yes, that's correct. Packed mode "packs" each GPU before moving to the next one.

I think maybe the possible solution is to limit the i915 resource to 1 for each container. That can resolve all the potential issue.

That's a way to workaround the limitations yes.

Thank you! So the none policy allocates number of cards(in this case 1 or 2) for each pod randomly, irrespective of how many resources requested- Its different each time, is my understanding right? In this example case of balanced mode, for containers requesting <= 2 resources, it shows one card. For resources > 2, it shows 2 cards. Is this expected as well?

None policy can result in 1 or 2 actual GPUs to the container if i915 == 2. Balanced policy should result in 2 actual GPUs to the container if i915 == 2. If this is not the case, can you supply GPU-plugin logs for me to check? You'll have to add "-v=5" to gpu-plugin arguments as the default doesn't print much of anything. https://github.com/intel/intel-device-plugins-for-kubernetes/blob/main/deployments/gpu_plugin/overlays/monitoring_shared-dev_nfd/add-args.yaml#L13

For the first container scheduled to access the i915 resource. it only access the single card(card0).
But the second container can access 2 cards(card0, card 1).
And the third container can only see and access singel card(card1)

Yes, that's correct. Packed mode "packs" each GPU before moving to the next one.

I think maybe the possible solution is to limit the i915 resource to 1 for each container. That can resolve all the potential issue.

That's a way to workaround the limitations yes.

Do we have a way to limit the i915 resource claim to 1 from gpu device plugin side? :-)

Do you have a workload that would require both GPUs from a single Flex 140 physical card?
I am not sure about that.
We don't currently have such allocation policy, though I believe it could be implemented.
That is the inconsistency issue, for some option combinations, some container can actually access 2 cards while some only access 1 card.

I think since we have several different combinations for the options, we also need to let users know what is the behavior or potential issues of these combinations, And what combination is preferred by us.

That is the inconsistency issue, for some option combinations, some container can actually access 2 cards while some only access 1 card.

IMO shared dev num is not really intended to give more than one GPU to a container. You could ask 10 x i915 resources from a node with only two physical GPUs and the container would receive those 10 resources. But the container would get only one or two actual GPU devices.
Shared dev num is intended for cases where workloads need GPUs intermittently or just required a (constant) portion of the GPU's overall power.
If the workloads require more than one GPU, then it's best to set shared-dev-num=1, or use GAS.

I think since we have several different combinations for the options, we also need to let users know what is the behavior or potential issues of these combinations, And what combination is preferred by us.

Yes, I agree. I created a ticket for improving the documentation: https://github.com/intel/intel-device-plugins-for-kubernetes/issues/1381

In general sharing is for things that are batched, rather than things that have specific latency requirements.
If you do have latency requirements, in addition to either using small enough share count that more cannot be schedule to same GPU, or by using GAS + suitable Pod GPU resource requests to take care of that, you need to vet the workloads to make sure they fit into same GPU without causing latency issues for the workloads running in parallel on the same GPU.
(Reminder: kernel does not provide enforcement for how much GPU each client can use, except for the "reset the offending GPU context" hang-check, which you may want to disable when running "random" HPC use-cases as their compute kernels may run long enough to trigger hand check.)

Thanks @vbedida79  for updating the "Possible solutions"
I'd like to summarize our suggestions here:

Since card sharing is not supported for our coming Intel technology enabling for OpenShift project release, could we only enable shared-dev-num == 1 and disable the other modes in GPU plugin which is mentioned in
https://github.com/intel/intel-device-plugins-for-kubernetes/blob/main/cmd/gpu_plugin/README.md#operation-modes-for-different-workload-types

Could GPU device plugin only allows a container can only claim the single i915 resource? So it can resolve the inconsistent issue we mentioned above.
BTW, I have gone through the updated readme as well as the GAS readme. I still can't find any clue why i915 resource can be set as > 1. Please educate me.

So as to fractional use, card sharing and GAS support, Could we continue to discuss for the future release?

Since card sharing and fractional use will not be supported for our coming Intel technology enabling for OpenShift project release, in order to avoid the confusing from our users, could we only enable shared-dev-num == 1 and disable the other modes in GPU plugin which is mentioned in
https://github.com/intel/intel-device-plugins-for-kubernetes/blob/main/cmd/gpu_plugin/README.md#operation-modes-for-different-workload-types

Using shared-dev-num = 1 (=no sharing) is the simplest case. I'd say that's the best basic setup. You can then have as many containers using a GPU as you have GPUs (as long as each container requests one GPU).

Could GPU device plugin only allows a container can only claim the single i915 resource? So it can resolve the inconsistent issue we mentioned above.

Currently with only GPU-plugin, the only way to achieve that is to use shared-dev-num == 1. Though, I guess we could change the default functionality so that it tries to pick different GPUs, if possible. But even that would start returning duplicate GPUs when the available GPUs are scarce.

BTW, I have gone through the updated GPU device plugin readme as well as the GAS readme. I still can't find any clue why i915 resource can be set as > 1. Please educate me.

What would be the use cases for having shared-dev-num > 1?

So as to fractional use, card sharing and GAS support, Could we continue to discuss for the future release?

Sure.

BTW, I have gone through the updated GPU device plugin readme as well as the GAS readme. I still can't find any clue why i915 resource can be set as > 1. Please educate me.

It's required to support GPU sharing with GAS resource management, as it's the upper limit on the sharing.
It can also be used when you have only single GPU per node, know all the workloads, and manually make sure that everything you schedule fits to GPUs (heavier jobs have affinity rules to avoid them being scheduled to same node, and if you have multiple heavy deployments, you either use labels to put them to different sets of nodes, or do not schedule them at same time).
It can also be useful for testing / development if you do not have that many GPUs in your cluster.

Please allowed me to describe "the i915 resource set >1"  more clearly.
Normally each container only claimes gpu.intel.com/i915 as 1 as the below example
        resources:
          limits:
            gpu.intel.com/i915: 1
            gpu.intel.com/tiles: 2

But we found that users actually can set gpu.intel.com/i915 as any number they want, like
        resources:
          limits:
            gpu.intel.com/i915: 3
            gpu.intel.com/tiles: 2

That will cause the inconsistent issue we mentioned.
Is it by design or an issue?
We hope that users can only set gpu.intel/i915 as 1, all the other numbers should not be allowed.

But we found that users actually can set gpu.intel.com/i915 as any number they want, like
        resources:
          limits:
            gpu.intel.com/i915: 3
            gpu.intel.com/tiles: 2

That will cause the inconsistent issue we mentioned. Is it by design or an issue?

It's by design.  While same workload using multiple physical GPUs is uncommon, it's a valid "scale-up" use-case.  For example AI training back propagation with GPU-to-GPU communication (e.g. using PVC XeLink).
PR linked by Tuomas makes best-effort to provide workload separate GPU devices when it requests multiple ones, even when using "none" policy and no GAS is in use.

We hope that users can only set gpu.intel/i915 as 1, all the other numbers should not be allowed.

Share count = 1 with nodes having only single GPU at max, would result in pods which have container(s) that request more, remaining in Pending state.
If you'd like those kept in Pending state also on other situations, or to be rejected outright... That's probably better done on k8s control plane side, as generic resources management functionality, rather than something GPU specific.
There's already LimitRange, but currently that would seem to apply only to normal k8s resources (memory/CPU), not extended resources (such as devices):
https://kubernetes.io/docs/concepts/policy/limit-range/

PS. If you want want one-liner for finding out how many GPUs containers currently running in your cluster have requested, you can use this:
kubectl get pods --all-namespaces -o go-template --template='
{{range .items}}
  {{"pod: "}}{{.metadata.name}}{{range .spec.containers}}{{if .resources.requests}}
      {{"container name: "}}{{.name}}
      {{"image: "}}{{.image}}
      {{if .resources.requests}}
        {{"requests: "}}{{.resources.requests}}
      {{else if .resources.limits}}
        {{"limits: "}}{{.resources.limits}}
      {{end}}{{end}}{{end}}{{end}}' |\
grep -F gpu.intel.com

which provides output like this:
        requests: map[gpu.intel.com/i915_monitoring:1]
        requests: map[gpu.intel.com/i915_monitoring:1]
        requests: map[gpu.intel.com/i915_monitoring:1]

To see to which pods these resources belong to, just add -B4 option for grep:
  pod: xpu-manager-268s4
      container name: xpumd
      image: intel/xpu-manager:V1.2.8

        requests: map[gpu.intel.com/i915_monitoring:1]
--
  pod: xpu-manager-js2fg
      container name: xpumd
      image: intel/xpu-manager:V1.2.8

        requests: map[gpu.intel.com/i915_monitoring:1]
--
...

@eero-t
I am l little lost here. :-)
Can you let me know what is the definition of resource "gpu.intel.com/i915"?
Maybe from the beginning, we have some misunderstandings. :-)

From https://github.com/intel/platform-aware-scheduling/tree/master/gpu-aware-scheduling
I can see below definition
The only resource treated differently is the GPU-plugin "i915"-resource, which is considered to describe "from how many GPUs the GPU-resources for the POD should be evenly consumed". That is, if each GPU has e.g. capacity of 1000 "gpu.intel.com/millicores", and POD spec has a limit for two (2) "gpu.intel.com/i915" and 2000 "gpu.intel.com/millicores", that POD will consume 1000 millicores from two GPUs, totaling 2000 millicores.
However from Intel device plugin according to our testing,  i915 resources is: how many containers can share the same GPU card.

With shared-dev-num == 1 => no sharing
i915 resource (of gpu.intel.com/i915) represents a GPU device on a node. It is similar to k8s' traditional resources like cpu or memory with the exception that i915 only supports full values (not 0.5 or 500m). In practice, when a Pod requests an i915 resource in its pod spec, the resulting container will see /dev/dri/cardX and /dev/dri/renderDY devices.
If the pod spec indicates 2 i915 resources, the resulting container will see /dev/dri/cardX and /dev/dri/cardX+1 (and the render devices).
No other containers will have access to the GPUs that were allocated to the Pod.
With shared-dev-num > 1 => sharing
The difference here is that a GPU device on a node is not dedicated to any particular Pod. There can be multiple Pods using a GPU on a node (up to the shared-dev-num count). Lets say the shared-dev-num is set to 2. A Pod with i915: 1 will get "half" of one GPU on a node. If another Pod is scheduled (with i915: 1), it will get the other half of the same GPU. The two Pods would end up sharing one GPU - sharing its execution time, memory etc. The i915 count in the Pod spec, in most cases, should be 1.
Shared-dev-num selection
Shared-dev-num should be selected depending on the use case of the cluster. If you are doing heavy computing, shared-dev-num should be probably set to 1. You are using the whole GPU and there's no room for other users.
If the cluster is more of a generic use, moderate workloads, then maybe shared-dev-num should be set to 2, 5 or 10. The expectation is that a Pod shouldn't consume the GPU's resources completely: short heavy loads, or long light loads.
Note: as you are not using GAS, you shouldn't mix millicores or memory.max resources in the equation. They don't apply when you are only using GPU plugin.

FYI: When Tuomas says "Pod" in above, he really means "container in a Pod".  Resources are container attributes...

Can you let me know what is the definition of resource "gpu.intel.com/i915"?

(Tuomas/Ukri, please correct in case I've misunderstood / remember something wrong.)
Technically, it's a per-node list of resource IDs [1] and matching device file paths (/dev/dri/{card,renderD}*) on given node, provided to kubelet (k8s node agent) by the per-node GPU plugin instances.  When Intel GPU plugin sharing option is used, that list includes given number of aliases for each device.
K8s scheduler knows just the size of that list, and how many of them are already allocated on each node.  When scheduling a pod that requests i915 GPU resource, k8s scheduler picks list of candidate nodes where unallocated i915 resource count (integer) is large enough to satisfy the request, and that list is filtered further by scheduler extensions (like GAS), to get target node for the pod.
When pod is deployed on that node, kubelet (k8s node agent) asks device plugin for device paths matching the specified resource IDs.  At that point Intel GPU plugin can still affect them, based e.g. on pod annotations added by GAS.
(When GAS is in use, it tells GPU plugin what device should be mapped to which container using pod annotations.  Only when GAS is not used, GPU plugin does (some) independent decisions about that.)
Kubelet adds provided device paths to pod container's OCI spec before giving it to container runtime, which uses devices cgroup or BPF to provide access [2] only to specified devices files for the created container (in addition to few devices provided for all containers).
[1] Different GPU plugins (Intel, AMD, Nvidia) use different resource IDs: BNF (PCI bus address), device UUID, or in case of Intel GPU plugin, GPU device control file name (as that makes some things simpler with GAS).
[2] For non-root containers, see: https://kubernetes.io/blog/2021/11/09/non-root-containers-and-devices/

Btw. There's also a use-case where different containers want the same GPU device.  For example cloud game pod where one of its containers is for the actual game, and another one for the media streaming functionality.
GAS has functionality to handle these different kind of use-cases, for example:
https://github.com/intel/platform-aware-scheduling/blob/master/gpu-aware-scheduling/docs/usage.md#enforcing-same-gpu-to-multiple-containers-within-pod
(IMHO using share count > 1 without GAS is a bit of a corner-case.)

PS. In future, GPU workloads could use also DRA (dynamic resource allocation): https://github.com/kubernetes/enhancements/tree/master/keps/sig-node/3063-dynamic-resource-allocation#summary
With DRA, GPU device requests would work more like current k8s volume handling.  You have separate device allocation objects (similar to PVs, Persistent Volumes) which pods can then claim (similar to PVCs, Persistent Volume Claims).

(IMHO using share count > 1 without GAS is a bit of a corner-case.)

Discussed with Ukri, and there's a clear use-case for this. A dedicated cluster with specific GPU workload pod, where it has been validated how many instances of that pod can work in parallel on the same GPU (without interfering each other too much).  That does not need GAS, just a GPU plugin with suitable share count.

What @eero-t mentioned i915 resources definition makes sense to me. But It is not aligned with what we observed in the current GPU device plugin. according to our testing: i915 == share-dev-num * cards number on the node. -shared-dev-num specifies how many containers is allowed to access that one card Thanks!

Your equation is correct: i915 == share-dev-num * cards on the node

@uniemimu Could you please reopen this issue? I think we haven't finished the discussing yet. :-)

I've created two issues for the continuation: #1407 for the i915 documentation improvements and #1408 for the i915 resource limitation per Pod. I'd like the discussion to continue in those tickets. I hope our understanding of the i915 and shared-dev-num is now aligned.


have an issue in logout from facebook

i am trying to logoff from facebook using the logout() function. but it's not allow me to logout from facebook. after closing my ionic app, when i again click on the facebook login button, it retain the previous facebook session and redirect me with the same logged in information to inside my app. please help me to logged off from api.

I used a workaround, by adding "&auth_type=reauthenticate" to the login url, this worked as I wanted. I hope it helps.
Although, I don't know if it's a bug, because even in the native sdk I couldn't perform this with the logout function. When I tried to login again the token was kept by facebook.


The ExtentSize property will be invalid when DisableScroll=true

I found that CoerceVerticalOffset and CoerceHorizontalOffset won't be called if DisableScroll=true, but I think Panning should still be limited by the ExtentSize property.

Hi!
You're right, Panning should be limited by ExtentSize. Will fix this later as I am working on some other features at the moment. It will be packed in the next release for sure.
Thanks!


cargo xtest doesn't work under WSL1 with native QEMU

Install QEMU natively on Windows
Under WSL setup cargo
In ~/bin/qemu-system-x86_64 put exec /mnt/c/Program\ Files/qemu/qemu-system-x86_64.exe "$@" and make the file executable
run cargo xrun
run cargo xtest

The xrun command works because it provides a relative path to the target to run to qemu. However xtest fails because it provides an absolute path which native QEMU doesn't understand. Passing a relative path just like xrun does should fix the issue.
Running: `qemu-system-x86_64 -drive format=raw,file=/mnt/c/projects/blog_os/target/x86_64-blog_os/debug/deps/bootimage-blog_os-f9b6181f9decdfac.bin -device isa-debug-exit,iobase=0xf4,iosize=0x04 -serial stdio -display none`
C:\Program Files\qemu\qemu-system-x86_64.exe: -drive format=raw,file=/mnt/c/projects/blog_os/target/x86_64-blog_os/debug/deps/bootimage-blog_os-f9b6181f9decdfac.bin: Could not open '/mnt/c/open/blog_os/target/x86_64-blog_os/debug/deps/bootimage-blog_os-f9b6181f9decdfac.bin': The system cannot find the path specified.

This seems to be an issue of the bootimage tool and not of cargo-xbuild. Let me try to transfer the issue to the bootimage repository.


Modflow6: Well package does not support time dimension

In GitLab by @Huite on Nov 17, 2021, 12:13
The mf6 well package currently sets everything on an "index", but not a "time" dimension.
(In general, the Well package warrants another look with sparse datasets, dataframe versus dataset, etc.)

In GitLab by @Huite on Dec 22, 2021, 10:54
mentioned in commit e93f18d787ca4d6f3c7f05395189706a909befcc


V5.0.0 setEventHandler reported NoSuchMethodError: The getter 'iterator' was called on null

while setting rtc engine setEventHandler function, this error occurred
when set a breakpoint, i found that inside setEventHandler function,  it used a process function(line 236), this process func occurred en error while process the method name 'AudioVolumeIndication', and because of the data with this method have an attribute which value is null, so inside AudioVolumeIndication case , create a list form this null value failed, and error occurred
i tested in real phone, emulator, same error
see this picture

i don't know why my speakers are null
maybe you should return [] but not null, so that list conversion should complete

This issue had been fixed, you can try the pre-release version agora_rtc_engine: ^5.0.1-rc.1, or wait for the next release.

@littleGnAl ok, thanks i will try that version

good work! waiting for the next release version.


Recovered shows - none

Getting this issue while calling the function. Everything seems fine except active and recovered. Both of them show none.
Can it be fixed by any means?
Thanks for such an awesome package!
{'id': '80', 'country': 'India', 'confirmed': 32156493, 'active': None, 'deaths': 430732, 'recovered': None, 'latitude': 20.593684, 'longitude': 78.96288, 'last_update':<PHONE_NUMBER>000}
{'id': '186', 'country': 'United Kingdom', 'confirmed': 6241447, 'active': None, 'deaths': 131116, 'recovered': None, 'latitude': 55.0, 'longitude': -3.0, 'last_update':<PHONE_NUMBER>000}

I am happy you find it useful,
Which source did you use?

it was john hopkins, they are no longer providing recovered data

for now you can switch to Worldometers, it will have recovered data


Ansible fix

This enhancement allows a developer to specify an "organization" in addition to the branch variable.  Previously the ansible role would only pull from the rackhd organization.
It is written so that a developer can fork only the repos they want to work on into their "organization" (i.e. http://www.githhub.com/michaelsteven - where michaelsteven is the organization).
The role now does a check to see if the repo exists in the specified organization, and if not it will fall back pull from the "rackhd".  It also does a check to see if the branch exists, and if not it will fall back to use "master".
Also changed is the dependence on "submodules" is removed.  It no longer needs them.

add BRI experts for review @panpan0000 @PengTian0 @changev

Ok I discovered a problem when deploying with these changes to Ubuntu 14.04.  The ansible version for trusty is 1.5.4, and the git "recursive" option isn't available to until ansible 1.6.   This means while it works fine when using it with Ubuntu 16.04 but not 14.04 (without backports).   I haven't been able to find out how to tell git to NOT pull the submodules in the old ansible.    Looking at options, don't approve yet.

Do not commit this PR yet.  Still working out the problems with using on 14.04 that carries a really old version of Ansible.  I feel it is worth having once this is fixed for build system flexibility.

BUILD RackHD #460 : FAILURE

BUILD RackHD #460  Error Logs  ▼Test Name: setup_ipmi_obm
Error Details: (404)
Reason: Not Found
HTTP response headers: HTTPHeaderDict({'Content-Length': '110', 'X-Powered-By': 'Express', 'Connection': 'keep-alive', 'ETag': 'W/"6e-UNQOnoYfyToTqhCwZDYSweL3NzY"', 'Date': 'Fri, 16 Jun 2017 14:59:52 GMT', 'Access-Control-Allow-Origin': '*', 'Content-Type': 'application/json; charset=utf-8'})
HTTP response body: {"message":"No Catalogs Found for Source (bmc).","status":"404","UUID":"ea549c91-a28d-48cf-a89a-8e9b7efcaa57"}
-------------------- >> begin captured logging << --------------------
tests.api.v2_0.obm_settings: WARNING: No OBM settings for node type compute (id=5943f2351e71f6f909e1676a)
tests.api.v2_0.obm_settings: WARNING: No OBM settings for node type compute (id=5943f2381e71f6f909e1676b)
tests.api.v2_0.obm_settings: WARNING: No OBM settings for node type compute (id=5943f23a1e71f6f909e1676c)
--------------------- >> end captured logging << ---------------------
Stack Trace:   File "/usr/lib/python2.7/unittest/case.py", line 331, in run
testMethod()
File "/usr/lib/python2.7/unittest/case.py", line 1043, in runTest
self._testFunc()
File "/home/jenkins/workspace/RackHD/RackHD/test/.venv/on-build-config/local/lib/python2.7/site-packages/proboscis/case.py", line 296, in testng_method_mistake_capture_func
compatability.capture_type_error(s_func)
File "/home/jenkins/workspace/RackHD/RackHD/test/.venv/on-build-config/local/lib/python2.7/site-packages/proboscis/compatability/exceptions_2_6.py", line 27, in capture_type_error
func()
File "/home/jenkins/workspace/RackHD/RackHD/test/.venv/on-build-config/local/lib/python2.7/site-packages/proboscis/case.py", line 350, in func
func(test_case.state.get_state())
File "/home/jenkins/workspace/RackHD/RackHD/test/tests/api/v2_0/obm_tests.py", line 27, in setup_ipmi_obm
assert_equal(len(obmSettings().setup_nodes(service_type='ipmi-obm-service')), 0)
File "/home/jenkins/workspace/RackHD/RackHD/test/tests/api/v2_0/obm_settings.py", line 65, in setup_nodes
if self._set_ipmi(uid) == False:
File "/home/jenkins/workspace/RackHD/RackHD/test/tests/api/v2_0/obm_settings.py", line 23, in _set_ipmi
Api().nodes_get_catalog_source_by_id(uid,'bmc')
File "/home/jenkins/workspace/RackHD/RackHD/test/.venv/on-build-config/local/lib/python2.7/site-packages/on_http_api2_0/apis/api_api.py", line 1862, in nodes_get_catalog_source_by_id
callback=params.get('callback'))
File "/home/jenkins/workspace/RackHD/RackHD/test/.venv/on-build-config/local/lib/python2.7/site-packages/on_http_api2_0/api_client.py", line 322, in call_api
response_type, auth_settings, callback)
File "/home/jenkins/workspace/RackHD/RackHD/test/.venv/on-build-config/local/lib/python2.7/site-packages/on_http_api2_0/api_client.py", line 149, in __call_api
post_params=post_params, body=body)
File "/home/jenkins/workspace/RackHD/RackHD/test/.venv/on-build-config/local/lib/python2.7/site-packages/on_http_api2_0/api_client.py", line 342, in request
headers=headers)
File "/home/jenkins/workspace/RackHD/RackHD/test/.venv/on-build-config/local/lib/python2.7/site-packages/on_http_api2_0/rest.py", line 184, in GET
query_params=query_params)
File "/home/jenkins/workspace/RackHD/RackHD/test/.venv/on-build-config/local/lib/python2.7/site-packages/on_http_api2_0/rest.py", line 177, in request
raise ApiException(http_resp=r)
'(404)\nReason: Not Found\nHTTP response headers: HTTPHeaderDict({'Content-Length': '110', 'X-Powered-By': 'Express', 'Connection': 'keep-alive', 'ETag': 'W/"6e-UNQOnoYfyToTqhCwZDYSweL3NzY"', 'Date': 'Fri, 16 Jun 2017 14:59:52 GMT', 'Access-Control-Allow-Origin': '*', 'Content-Type': 'application/json; charset=utf-8'})\nHTTP response body: {"message":"No Catalogs Found for Source (bmc).","status":"404","UUID":"ea549c91-a28d-48cf-a89a-8e9b7efcaa57"}\n\n-------------------- >> begin captured logging << --------------------\ntests.api.v2_0.obm_settings: WARNING: No OBM settings for node type compute (id=5943f2351e71f6f909e1676a)\ntests.api.v2_0.obm_settings: WARNING: No OBM settings for node type compute (id=5943f2381e71f6f909e1676b)\ntests.api.v2_0.obm_settings: WARNING: No OBM settings for node type compute (id=5943f23a1e71f6f909e1676c)\n--------------------- >> end captured logging << ---------------------'

BUILD RackHD #466 : FAILURE

BUILD RackHD #466  Error Logs  ▼Test Name: test_node_catalogs
Error Details: Node catalog is empty!
Stack Trace: Traceback (most recent call last):
  File "/usr/lib/python2.7/unittest/case.py", line 331, in run
    testMethod()
  File "/usr/lib/python2.7/unittest/case.py", line 1043, in runTest
    self._testFunc()
  File "/home/jenkins/workspace/RackHD/RackHD/test/.venv/on-build-config/local/lib/python2.7/site-packages/proboscis/case.py", line 296, in testng_method_mistake_capture_func
    compatability.capture_type_error(s_func)
  File "/home/jenkins/workspace/RackHD/RackHD/test/.venv/on-build-config/local/lib/python2.7/site-packages/proboscis/compatability/exceptions_2_6.py", line 27, in capture_type_error
    func()
  File "/home/jenkins/workspace/RackHD/RackHD/test/.venv/on-build-config/local/lib/python2.7/site-packages/proboscis/case.py", line 350, in func
    func(test_case.state.get_state())
  File "/home/jenkins/workspace/RackHD/RackHD/test/tests/api/v2_0/nodes_tests.py", line 255, in test_node_catalogs
    assert_not_equal(0, len(resp), message='Node catalog is empty!')
  File "/home/jenkins/workspace/RackHD/RackHD/test/.venv/on-build-config/local/lib/python2.7/site-packages/proboscis/asserts.py", line 151, in assert_not_equal
    raise ASSERTION_ERROR(message)
AssertionError: Node catalog is empty!
Test Name: setup_ipmi_obm
Error Details: (404)
Reason: Not Found
HTTP response headers: HTTPHeaderDict({'Content-Length': '110', 'X-Powered-By': 'Express', 'Connection': 'keep-alive', 'ETag': 'W/"6e-QAZRXRpTozw19JLKV9jhZAbYDVk"', 'Date': 'Fri, 16 Jun 2017 20:47:17 GMT', 'Access-Control-Allow-Origin': '*', 'Content-Type': 'application/json; charset=utf-8'})
HTTP response body: {"message":"No Catalogs Found for Source (bmc).","status":"404","UUID":"ef51532a-9662-46ba-9bd5-2f200e6e2681"}
-------------------- >> begin captured logging << --------------------
tests.api.v2_0.obm_settings: WARNING: No OBM settings for node type compute (id=5944438a49af6b870a232ecd)
tests.api.v2_0.obm_settings: WARNING: No OBM settings for node type compute (id=5944438d49af6b870a232ece)
tests.api.v2_0.obm_settings: WARNING: No OBM settings for node type compute (id=5944438f49af6b870a232ecf)
--------------------- >> end captured logging << ---------------------
Stack Trace:   File "/usr/lib/python2.7/unittest/case.py", line 331, in run
testMethod()
File "/usr/lib/python2.7/unittest/case.py", line 1043, in runTest
self._testFunc()
File "/home/jenkins/workspace/RackHD/RackHD/test/.venv/on-build-config/local/lib/python2.7/site-packages/proboscis/case.py", line 296, in testng_method_mistake_capture_func
compatability.capture_type_error(s_func)
File "/home/jenkins/workspace/RackHD/RackHD/test/.venv/on-build-config/local/lib/python2.7/site-packages/proboscis/compatability/exceptions_2_6.py", line 27, in capture_type_error
func()
File "/home/jenkins/workspace/RackHD/RackHD/test/.venv/on-build-config/local/lib/python2.7/site-packages/proboscis/case.py", line 350, in func
func(test_case.state.get_state())
File "/home/jenkins/workspace/RackHD/RackHD/test/tests/api/v2_0/obm_tests.py", line 27, in setup_ipmi_obm
assert_equal(len(obmSettings().setup_nodes(service_type='ipmi-obm-service')), 0)
File "/home/jenkins/workspace/RackHD/RackHD/test/tests/api/v2_0/obm_settings.py", line 65, in setup_nodes
if self._set_ipmi(uid) == False:
File "/home/jenkins/workspace/RackHD/RackHD/test/tests/api/v2_0/obm_settings.py", line 23, in _set_ipmi
Api().nodes_get_catalog_source_by_id(uid,'bmc')
File "/home/jenkins/workspace/RackHD/RackHD/test/.venv/on-build-config/local/lib/python2.7/site-packages/on_http_api2_0/apis/api_api.py", line 1862, in nodes_get_catalog_source_by_id
callback=params.get('callback'))
File "/home/jenkins/workspace/RackHD/RackHD/test/.venv/on-build-config/local/lib/python2.7/site-packages/on_http_api2_0/api_client.py", line 322, in call_api
response_type, auth_settings, callback)
File "/home/jenkins/workspace/RackHD/RackHD/test/.venv/on-build-config/local/lib/python2.7/site-packages/on_http_api2_0/api_client.py", line 149, in __call_api
post_params=post_params, body=body)
File "/home/jenkins/workspace/RackHD/RackHD/test/.venv/on-build-config/local/lib/python2.7/site-packages/on_http_api2_0/api_client.py", line 342, in request
headers=headers)
File "/home/jenkins/workspace/RackHD/RackHD/test/.venv/on-build-config/local/lib/python2.7/site-packages/on_http_api2_0/rest.py", line 184, in GET
query_params=query_params)
File "/home/jenkins/workspace/RackHD/RackHD/test/.venv/on-build-config/local/lib/python2.7/site-packages/on_http_api2_0/rest.py", line 177, in request
raise ApiException(http_resp=r)
'(404)\nReason: Not Found\nHTTP response headers: HTTPHeaderDict({'Content-Length': '110', 'X-Powered-By': 'Express', 'Connection': 'keep-alive', 'ETag': 'W/"6e-QAZRXRpTozw19JLKV9jhZAbYDVk"', 'Date': 'Fri, 16 Jun 2017 20:47:17 GMT', 'Access-Control-Allow-Origin': '*', 'Content-Type': 'application/json; charset=utf-8'})\nHTTP response body: {"message":"No Catalogs Found for Source (bmc).","status":"404","UUID":"ef51532a-9662-46ba-9bd5-2f200e6e2681"}\n\n-------------------- >> begin captured logging << --------------------\ntests.api.v2_0.obm_settings: WARNING: No OBM settings for node type compute (id=5944438a49af6b870a232ecd)\ntests.api.v2_0.obm_settings: WARNING: No OBM settings for node type compute (id=5944438d49af6b870a232ece)\ntests.api.v2_0.obm_settings: WARNING: No OBM settings for node type compute (id=5944438f49af6b870a232ecf)\n--------------------- >> end captured logging << ---------------------'
Test Name: test_catalogs
Error Details: Catalog dmi not found in node 5944438a49af6b870a232ecd!
Stack Trace: Traceback (most recent call last):
File "/usr/lib/python2.7/unittest/case.py", line 331, in run
testMethod()
File "/usr/lib/python2.7/unittest/case.py", line 1043, in runTest
self._testFunc()
File "/home/jenkins/workspace/RackHD/RackHD/test/.venv/on-build-config/local/lib/python2.7/site-packages/proboscis/case.py", line 296, in testng_method_mistake_capture_func
compatability.capture_type_error(s_func)
File "/home/jenkins/workspace/RackHD/RackHD/test/.venv/on-build-config/local/lib/python2.7/site-packages/proboscis/compatability/exceptions_2_6.py", line 27, in capture_type_error
func()
File "/home/jenkins/workspace/RackHD/RackHD/test/.venv/on-build-config/local/lib/python2.7/site-packages/proboscis/case.py", line 350, in func
func(test_case.state.get_state())
File "/home/jenkins/workspace/RackHD/RackHD/test/tests/api/v2_0/catalogs_tests.py", line 48, in test_catalogs
fail('Catalog {0} not found in node {1}!'.format(source,node.get('id')))
File "/home/jenkins/workspace/RackHD/RackHD/test/.venv/on-build-config/local/lib/python2.7/site-packages/proboscis/asserts.py", line 220, in fail
raise ASSERTION_ERROR(message)
AssertionError: Catalog dmi not found in node 5944438a49af6b870a232ecd!
Test Name: test_tag_create
Error Details: (404)
Reason: Not Found
HTTP response headers: HTTPHeaderDict({'Content-Length': '110', 'X-Powered-By': 'Express', 'Connection': 'keep-alive', 'ETag': 'W/"6e-g9j+4LMmqcj156OYA/TLTT2eEB0"', 'Date': 'Fri, 16 Jun 2017 20:49:17 GMT', 'Access-Control-Allow-Origin': '*', 'Content-Type': 'application/json; charset=utf-8'})
HTTP response body: {"message":"No Catalogs Found for Source (dmi).","status":"404","UUID":"d637a874-1372-471c-8bfa-cd5c69743b9d"}
Stack Trace: Traceback (most recent call last):
File "/usr/lib/python2.7/unittest/case.py", line 331, in run
testMethod()
File "/usr/lib/python2.7/unittest/case.py", line 1043, in runTest
self._testFunc()
File "/home/jenkins/workspace/RackHD/RackHD/test/.venv/on-build-config/local/lib/python2.7/site-packages/proboscis/case.py", line 296, in testng_method_mistake_capture_func
compatability.capture_type_error(s_func)
File "/home/jenkins/workspace/RackHD/RackHD/test/.venv/on-build-config/local/lib/python2.7/site-packages/proboscis/compatability/exceptions_2_6.py", line 27, in capture_type_error
func()
File "/home/jenkins/workspace/RackHD/RackHD/test/.venv/on-build-config/local/lib/python2.7/site-packages/proboscis/case.py", line 350, in func
func(test_case.state.get_state())
File "/home/jenkins/workspace/RackHD/RackHD/test/tests/api/v2_0/tags_tests.py", line 45, in test_tag_create
tagsWithRules = self.__create_tag_rule(n.get('id'))
File "/home/jenkins/workspace/RackHD/RackHD/test/tests/api/v2_0/tags_tests.py", line 26, in __create_tag_rule
Api().nodes_get_catalog_source_by_id(identifier=id,source='dmi')
File "/home/jenkins/workspace/RackHD/RackHD/test/.venv/on-build-config/local/lib/python2.7/site-packages/on_http_api2_0/apis/api_api.py", line 1862, in nodes_get_catalog_source_by_id
callback=params.get('callback'))
File "/home/jenkins/workspace/RackHD/RackHD/test/.venv/on-build-config/local/lib/python2.7/site-packages/on_http_api2_0/api_client.py", line 322, in call_api
response_type, auth_settings, callback)
File "/home/jenkins/workspace/RackHD/RackHD/test/.venv/on-build-config/local/lib/python2.7/site-packages/on_http_api2_0/api_client.py", line 149, in __call_api
post_params=post_params, body=body)
File "/home/jenkins/workspace/RackHD/RackHD/test/.venv/on-build-config/local/lib/python2.7/site-packages/on_http_api2_0/api_client.py", line 342, in request
headers=headers)
File "/home/jenkins/workspace/RackHD/RackHD/test/.venv/on-build-config/local/lib/python2.7/site-packages/on_http_api2_0/rest.py", line 184, in GET
query_params=query_params)
File "/home/jenkins/workspace/RackHD/RackHD/test/.venv/on-build-config/local/lib/python2.7/site-packages/on_http_api2_0/rest.py", line 177, in request
raise ApiException(http_resp=r)
ApiException: (404)
Reason: Not Found
HTTP response headers: HTTPHeaderDict({'Content-Length': '110', 'X-Powered-By': 'Express', 'Connection': 'keep-alive', 'ETag': 'W/"6e-g9j+4LMmqcj156OYA/TLTT2eEB0"', 'Date': 'Fri, 16 Jun 2017 20:49:17 GMT', 'Access-Control-Allow-Origin': '*', 'Content-Type': 'application/json; charset=utf-8'})
HTTP response body: {"message":"No Catalogs Found for Source (dmi).","status":"404","UUID":"d637a874-1372-471c-8bfa-cd5c69743b9d"}
Test Name: get_sku_nodes
Error Details: (404)
Reason: Not Found
HTTP response headers: HTTPHeaderDict({'Content-Length': '110', 'X-Powered-By': 'Express', 'Connection': 'keep-alive', 'ETag': 'W/"6e-DHf4d9mbBQahP7Pk5BIIuW5NrCc"', 'Date': 'Fri, 16 Jun 2017 20:49:37 GMT', 'Access-Control-Allow-Origin': '*', 'Content-Type': 'application/json; charset=utf-8'})
HTTP response body: {"message":"No Catalogs Found for Source (dmi).","status":"404","UUID":"b58a6f5b-a9db-4009-917d-bb0deaa4bff2"}
Stack Trace: Traceback (most recent call last):
File "/usr/lib/python2.7/unittest/case.py", line 331, in run
testMethod()
File "/usr/lib/python2.7/unittest/case.py", line 1043, in runTest
self._testFunc()
File "/home/jenkins/workspace/RackHD/RackHD/test/.venv/on-build-config/local/lib/python2.7/site-packages/proboscis/case.py", line 296, in testng_method_mistake_capture_func
compatability.capture_type_error(s_func)
File "/home/jenkins/workspace/RackHD/RackHD/test/.venv/on-build-config/local/lib/python2.7/site-packages/proboscis/compatability/exceptions_2_6.py", line 27, in capture_type_error
func()
File "/home/jenkins/workspace/RackHD/RackHD/test/.venv/on-build-config/local/lib/python2.7/site-packages/proboscis/case.py", line 350, in func
func(test_case.state.get_state())
File "/home/jenkins/workspace/RackHD/RackHD/test/tests/api/v2_0/skupack_tests.py", line 148, in get_sku_nodes
Api().nodes_get_catalog_source_by_id(identifier=node_id,source='dmi')
File "/home/jenkins/workspace/RackHD/RackHD/test/.venv/on-build-config/local/lib/python2.7/site-packages/on_http_api2_0/apis/api_api.py", line 1862, in nodes_get_catalog_source_by_id
callback=params.get('callback'))
File "/home/jenkins/workspace/RackHD/RackHD/test/.venv/on-build-config/local/lib/python2.7/site-packages/on_http_api2_0/api_client.py", line 322, in call_api
response_type, auth_settings, callback)
File "/home/jenkins/workspace/RackHD/RackHD/test/.venv/on-build-config/local/lib/python2.7/site-packages/on_http_api2_0/api_client.py", line 149, in __call_api
post_params=post_params, body=body)
File "/home/jenkins/workspace/RackHD/RackHD/test/.venv/on-build-config/local/lib/python2.7/site-packages/on_http_api2_0/api_client.py", line 342, in request
headers=headers)
File "/home/jenkins/workspace/RackHD/RackHD/test/.venv/on-build-config/local/lib/python2.7/site-packages/on_http_api2_0/rest.py", line 184, in GET
query_params=query_params)
File "/home/jenkins/workspace/RackHD/RackHD/test/.venv/on-build-config/local/lib/python2.7/site-packages/on_http_api2_0/rest.py", line 177, in request
raise ApiException(http_resp=r)
ApiException: (404)
Reason: Not Found
HTTP response headers: HTTPHeaderDict({'Content-Length': '110', 'X-Powered-By': 'Express', 'Connection': 'keep-alive', 'ETag': 'W/"6e-DHf4d9mbBQahP7Pk5BIIuW5NrCc"', 'Date': 'Fri, 16 Jun 2017 20:49:37 GMT', 'Access-Control-Allow-Origin': '*', 'Content-Type': 'application/json; charset=utf-8'})
HTTP response body: {"message":"No Catalogs Found for Source (dmi).","status":"404","UUID":"b58a6f5b-a9db-4009-917d-bb0deaa4bff2"}
Test Name: post_skupacks
Error Details: (404)
Reason: Not Found
HTTP response headers: HTTPHeaderDict({'Content-Length': '110', 'X-Powered-By': 'Express', 'Connection': 'keep-alive', 'ETag': 'W/"6e-CFDAqynPyD0t1dw8AUn9gBFPYBw"', 'Date': 'Fri, 16 Jun 2017 20:50:05 GMT', 'Access-Control-Allow-Origin': '*', 'Content-Type': 'application/json; charset=utf-8'})
HTTP response body: {"message":"No Catalogs Found for Source (dmi).","status":"404","UUID":"4421d5bd-9c3a-4afa-b7e7-755fea2b1e55"}
Stack Trace: Traceback (most recent call last):
File "/usr/lib/python2.7/unittest/case.py", line 331, in run
testMethod()
File "/usr/lib/python2.7/unittest/case.py", line 1043, in runTest
self._testFunc()
File "/home/jenkins/workspace/RackHD/RackHD/test/.venv/on-build-config/local/lib/python2.7/site-packages/proboscis/case.py", line 296, in testng_method_mistake_capture_func
compatability.capture_type_error(s_func)
File "/home/jenkins/workspace/RackHD/RackHD/test/.venv/on-build-config/local/lib/python2.7/site-packages/proboscis/compatability/exceptions_2_6.py", line 27, in capture_type_error
func()
File "/home/jenkins/workspace/RackHD/RackHD/test/.venv/on-build-config/local/lib/python2.7/site-packages/proboscis/case.py", line 350, in func
func(test_case.state.get_state())
File "/home/jenkins/workspace/RackHD/RackHD/test/tests/api/v2_0/sel_alert_poller_tests.py", line 54, in post_skupacks
Api().nodes_get_catalog_source_by_id(identifier=node_id, source='dmi')
File "/home/jenkins/workspace/RackHD/RackHD/test/.venv/on-build-config/local/lib/python2.7/site-packages/on_http_api2_0/apis/api_api.py", line 1862, in nodes_get_catalog_source_by_id
callback=params.get('callback'))
File "/home/jenkins/workspace/RackHD/RackHD/test/.venv/on-build-config/local/lib/python2.7/site-packages/on_http_api2_0/api_client.py", line 322, in call_api
response_type, auth_settings, callback)
File "/home/jenkins/workspace/RackHD/RackHD/test/.venv/on-build-config/local/lib/python2.7/site-packages/on_http_api2_0/api_client.py", line 149, in __call_api
post_params=post_params, body=body)
File "/home/jenkins/workspace/RackHD/RackHD/test/.venv/on-build-config/local/lib/python2.7/site-packages/on_http_api2_0/api_client.py", line 342, in request
headers=headers)
File "/home/jenkins/workspace/RackHD/RackHD/test/.venv/on-build-config/local/lib/python2.7/site-packages/on_http_api2_0/rest.py", line 184, in GET
query_params=query_params)
File "/home/jenkins/workspace/RackHD/RackHD/test/.venv/on-build-config/local/lib/python2.7/site-packages/on_http_api2_0/rest.py", line 177, in request
raise ApiException(http_resp=r)
ApiException: (404)
Reason: Not Found
HTTP response headers: HTTPHeaderDict({'Content-Length': '110', 'X-Powered-By': 'Express', 'Connection': 'keep-alive', 'ETag': 'W/"6e-CFDAqynPyD0t1dw8AUn9gBFPYBw"', 'Date': 'Fri, 16 Jun 2017 20:50:05 GMT', 'Access-Control-Allow-Origin': '*', 'Content-Type': 'application/json; charset=utf-8'})
HTTP response body: {"message":"No Catalogs Found for Source (dmi).","status":"404","UUID":"4421d5bd-9c3a-4afa-b7e7-755fea2b1e55"}

BUILD RackHD #705 : FAILURE

BUILD RackHD #747 : FAILURE

@michaelsteven  is this PR still valid, if not, we could close it


Add id vector

I need to catch and recycle deleted segments to use this for something other than fresh-ids

Still looking good.  :-)

This needs lazy allocation for the permutation vector, but I'll do that in a follow up PR.


Cannot install version middleware_automation.amq:1.3.11 with ansible Galaxy.

SUMMARY
Cannot install version middleware_automation.amq:1.3.11 with ansible Galaxy.
ISSUE TYPE

Bug Report

STEPS TO REPRODUCE
ansible-galaxy collection install -r requirements/requirements.yml

❯ cat requirements/requirements.yml
---
collections:
  - name: middleware_automation.common
  - name: ansible.posix
  - name: middleware_automation.amq
    version: 1.3.11

EXPECTED RESULTS
I expected version 1.3.11 to be installed
ACTUAL RESULTS
ansible-galaxy collection install -r requirements/requirements.yml
Starting galaxy collection install process
Process install dependency map
ERROR! Failed to resolve the requested dependencies map. Could not satisfy the following requirements:
* middleware_automation.amq:1.3.11 (direct request)

Hello Robert, 1.3.11 is still unreleased (it's the current -devel version)


how to set different color for different zone?

HI,
This library is great because i can select one part by mouse when hover.
If I want to select multi zone by mouse, How should I do?
I also just want to know how to set different colors for different zone in three circles?
Can you help me about it.
Thanks.
br
wt

          {
            ...data.datasets[0],
            backgroundColor: [
            'rgba(255, 99, 132, 0.2)',
            'rgba(54, 162, 235, 0.2)',
            'rgba(255, 206, 86, 0.2)',
            'rgba(75, 192, 192, 0.2)',
            'rgba(153, 102, 255, 0.2)',
            'rgba(255, 159, 64, 0.2)'
        ],
        borderColor: [
            'rgba(255, 99, 132, 1)',
            'rgba(54, 162, 235, 1)',
            'rgba(255, 206, 86, 1)',
            'rgba(75, 192, 192, 1)',
            'rgba(153, 102, 255, 1)',
            'rgba(255, 159, 64, 1)'
        ],
        borderWidth: 1
          },

we can use this to set color.
Thanks


Debugging callback

@runarberg had a good idea in https://github.com/tc39/proposal-pipeline-operator/issues/225#issuecomment-933705405.

Just to throw it out there. If debugging is this big of an issue, why hasn’t there been a proposal for say Function.aside:
.map(Function.aside(() => { debugger; }))

or in the above examples:
await Promise.resolve('intro.txt')
  .then(Deno.open)
  .then(Deno.readAll)
  .then(Function.aside((x) => { console.log(x); debugger; }))
  .then(data => new TextDecoder('utf-8').decode(data))
  .then(console.log)

Which is rougly:
Function.aside = (fn) => (x) => {
  fn(x)
  return x;
};

Prior arts include Rust’s inspect, RxJS’s tap. If this is common enough pattern, perhaps it should be included in the Function helpers proposal.

Debugging in callback-heavy code is a pain. This convenience function would be generally useful. Maybe this should be called Function.debug or something.
My off-work time is currently limited, but I plan to add a section for this sometime in the next few weeks.
Please feel free to comment with more precedents from other languages and libraries here.

Great idea. tap looks like an already widespread name for a function that  performs a side effect with the input value and then returns said input value. (that's the name on RxJs, Ramda and fp-ts, among others).
// general definition
Function.prototype.tap = a => { g(a); return this(a); }

/// Example use in a pipe (assume minimal)
```typescript
a
|> f
|> g.tap(console.log)
|> h

This would be valuable and, being a function, it composes well.
I suspect the overwhelming majority of uses of this function will be for console.log calls and debugger, in which case we might consider also shipping helpers for those? At which point we'd offer similar functional debugging to Haskell's Debug.Trace.
Status quo:
.map(x => { debugger; return x })

Function.aside alone:
.map(Function.aside(() => { debugger }))

Specialised helpers (hopefully with better names!) built atop Function.aside:
.map(Function.asideDebug)

Added this need, along with mentioned precedents, to the table in #6.

I figure that I’ll add both a Function.tap(f) (x => (f(x), x)) and a Function.debug (x => { debugger; return x; }) to the explainer later.


devnet: clarinet: need to specify version to install

I was running through the new DR v0.2 devnet docs (thanks @friedger!!) and noticed an issue running the deploy_contracts.sh.
We link to: https://github.com/hirosystems/clarinet for installation steps, however if you happen to try to install the prebuilt binaries:
You are directed to: https://github.com/hirosystems/clarinet/blob/develop/README.md?plain=1#L49
Which downloads v0.27.0 of clarinet, which does not have the deployment subcommands, and thus deploy_contracts.sh fails to execute.
I just want to flag this for discussion, as this is a stumbling point for a new user. We probably want to at a minimum, prescribe the minimum clarinet version that we have tested with.

Has been fixed in #109


Export many to many (N:N) entities to data lake ?

It is possible to export a many to many (N:N) entity using "Export to data lake" ?
Thank you

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 19489d66-04a5-73a7-ed5e-6a7f83290687
Version Independent ID: f1ad4134-09ed-7683-2715-b6dda1ff8682
Content: Export to data lake - Power Apps
Content Source: powerapps-docs/maker/data-platform/export-to-data-lake.md
Service: powerapps
GitHub Login: @sabinn-msft
Microsoft Alias: matp

It is possible by using the feature flag. To use the feature flag, please append ?athena.showRelationships=true to the end of your link, after selecting your preferred environment. Please note that this feature is still in preview.

I have tested the flag and it works as expected.
Thank you


Remove own 'definition' annotation property and instead use IAO's

Replace use of a custom OEO 'definition' annotation property with use of IAO's 'definition' annotation property in all edits modules.
Closes #529

Could you also update the CHANGELOG.md?


[FLINK-32913][tests] Updates base version for japicmp check

Updating the japicmp base version. Verification of API changes happened in FLINK-32927

thanks for taking a look


Could you please add unit tests?

Having some unit tests would be good. What do you think?

The tests I did was running the manual example in the readme, I am using this utility in various projects and because it's working and so little logic, I did not want to deploy any further tests. I also looked at the assembly generated in various cases to verify that I did not make the compiler do any extra than it should have. @yesudeep

The rationale is pretty simple I think. It allows users of the library to ensure their code
continues to work if the library changes.
For example, I import the library using Bazel and would prefer to include its unit tests
within my test suites as well. Therefore, if the library receives an update that changes functionality,
the tests would catch it. It makes the library more dependable.
I'm certain the code is pretty small but even a small piece of code can have unintended consequences
beyond its original purpose. Would you agree? Still it's entirely up to you to decide whether
it makes sense to include tests. Please feel free to close the bug. :)

Yes I agree, I wish I had time to write tests though

I turned your examples into tests locally. But they use googletest and bazel. Would you be willing to accept PRs?

@yesudeep I got a notification in the email that you're willing to have a PR about some tests, I don't see the comment here, but I can accept it - please put all the tests in a subdirectory named tests. @yesudeep


Get mint address for a given address

Hey I need a way of identifying what type of tokens the address is for so I need a way of querying a given public address to get it's mint address.
If I create a new client what method do I use to get the tokens mint address ?
c := client.NewClient(rpc.MainnetRPCEndpoint)
Thanks 👍

Actually I need to know how to do this to.
I need to know how to identify what type of cryptocurrency the given public address belongs to and I need a way of identifying what token the given token address belongs to.
How can we do this?

you can take a look at https://github.com/portto/solana-go-sdk/blob/main/docs/_examples/client/get-token-account/main.go
the mint is included in the token account data.


Did you check whether you get the identical seed as provided by SEC?

just as the title says, may i ask whether you get the identical seeds as provided by the original repo, as I find the localization cue important for training the segmentation network

Hi,
The cue is indeed important, but it is difficult to get the identical one due to randomness and difference between frameworks.

On Jun 26, 2018, at 9:06 PM, yaoqi_isee<EMAIL_ADDRESS>wrote:
just as the title says, may i ask whether you get the identical seeds as provided by the original repo, as I find the localization cue important for training the segmentation network
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.


Add icon for non-expanded folders/groups

This includes https://github.com/microsoft/perfview/pull/1530, so will be merged after it has been merged. Just review https://github.com/microsoft/perfview/commit/5f979d2df9941c109c9e571ec40d8a93f094dac6.
This adds a icon for non-expanded folders/groups.

I think I'm missing something obvious here, but I don't see a difference between the behavior of #1530 and #1531 with respect to folders and groups.  I'm watching the animation in this PR and then looking at a baseline version of PerfView, and I don't see a difference.  What did I miss?

@brianrob There is no "folder closed" icon. They are always expanded in the baseline.


upgrade SDK and use SDK to handle subscription restore

Coverage increased (+0.05%) to 40.307% when pulling 915bb62a3d7b63d9ff9b982d3db664f1779d750c on embbnux:feature/upgrade-sdk into fa0fe9525334dc253427499c882352db6e73317c on ringcentral:master.


Garbage being created in BaseShader

Issue details
The BaseShader is creating garbage int[] arrays each frame in BaseShader.getAttributeLocations  when using meshes with a different number of vertex attributes. https://github.com/libgdx/libgdx/blob/master/gdx/src/com/badlogic/gdx/graphics/g3d/shaders/BaseShader.java#L215
Having a different number of vertex attributes oftens means a different shader would be used for the renderanble, so IntArray add/shrink would never create new internal int[] arrays and everything would be fine. However, when rendering shadows, the same shader (DepthShader) is handling all the non-skinned meshes (good) causing the tempArray to constantly recreate its underlying int[] array (bad).
After discussing with Xoppa, the best solution is to add a 'size' argument to the bind/unbind methods in  Mesh, VertexData, and all implementing classes in the backends.
Reproduction steps/code
This can be reproduced by creating ModelInstances with two different vertex attributes and rendering shadows (or any shader that renders different vertex attributes).
Version of LibGDX and/or relevant dependencies
1.9.6
Please select the affected platforms
All Platforms.

I tested it again and it's no longer the case, array is shrink the first time the model is added but not for other frames after that.


make example.zip in tools same as exampleTest.zip

The two example zip files should probably be the same or the one in tools should be removed

Done it

We should remove aem-content-importer/tools-files/example.zip.
And, this file, aem-content-importer/aem-content-importer-bundle/src/test/resources/exampleTest.zip, should not be checked-in as a zip. The zip should be built during the maven install from a directory of the example files. This allows us to control the contents of the zip within the git system.

I'm thinking about giving up a maven task to create a zip file from a folder. Instead of this, integration test could manage it directly using a example folder in src/test/resources. What do you think?

This is file for testing the import functionality. Later when we have Jenkins continuous integration we might want to test the upload and unzipping of a zip file, but that would be a different issue.

I enclosed in the integration test the task to prepare a zip file from a folder for testing different things. So, right now we have a folder with all necessary files for zipping and doing the import functionality.


[Wip] experiment with model for metadata

This is an experiment to allow the user to enforce better types for a metadatables metadata and snapshot. In the first instance this is applied to parameter.
There are a quite a few things left to do but mainly validation on addition of data is missing.

#6119 continues the work started in this PR


Fix typo

What kind of change does this PR introduce? (Bug fix, feature, docs update, ...)

Why was this change needed? (You can also link to an open issue here)

Other information:

Thank you
@holopin-bot @FarukhS52


[5.0] align routes and ingress

From https://github.com/grafana-operator/grafana-operator/blob/master/documentation/roadmap/roadmap-v5.md
As part of 5.0 we would like to see the same configuration options available in both route and ingress, e.g. no TLS options exposed for Routes.
At the same time we would like to use the power of openshift when it's phaseable.
Today we assume routes should be behind TLS by default. This is very simple to do in OCP.
Since we don't know enough about none OCP environments we can't do the same assumptions. Instead the default value for ingress should be http.
We have already implemented was of making differences between OCP and none OCP and we should use them to solve the same issue here.

We now expose the Kube objects themselves and users can configure all properties.


Removing named connections graphql API

Describe the bug
Removing named connections of models throws Cannot perform more than one GSI creation or deletion in a single update. Someone who hasn't experienced this would think that he/she needs to remove those one by one, but doing so will throw Found one half of connection "<ModelName>" at <ModelName>.<field> but no related field on type <ModelName>.
To Reproduce
Steps to reproduce the behavior:

Create a two models, that look like so:

type ModelOne
  @model
  @searchable
  @auth(rules: [{ allow: public, provider: apiKey }, { allow: private }]) { {
  id: ID!
  testField: String
  modelTwo: ModelTwo @connection(name: "ModelOneTwoConnection", keyField: "modelOneId")
  createdAt: AWSDateTime
  updatedAt: AWSDateTime
}

type ModelTwo
  @model
  @searchable
  @auth(rules: [{ allow: public, provider: apiKey }, { allow: private }]) { {
  id: ID!
  modelOneId: String
  testFieldAgain: String
  modelOne: ModelOne @connection(name: "ModelOneTwoConnection", keyField: "modelOneId")
  createdAt: AWSDateTime
  updatedAt: AWSDateTime
}

I tried to push this and the connection didn't work, modelTwo field will always be null when I query ModelOne, I suppose this could only be done in a "belongsTo" fashion where I have to do this instead:
type ModelOne
  @model
  @searchable
  @auth(rules: [{ allow: public, provider: apiKey }, { allow: private }]) { {
  id: ID!
  testField: String
  modelTwo: [ModelTwo] @connection(name: "ModelOneTwoConnection", keyField: "modelOneId")
  createdAt: AWSDateTime
  updatedAt: AWSDateTime
}

type ModelTwo
  @model
  @searchable
  @auth(rules: [{ allow: public, provider: apiKey }, { allow: private }]) { {
  id: ID!
  modelOneId: String
  testFieldAgain: String
  modelOne: ModelOne @connection(name: "ModelOneTwoConnection", keyField: "modelOneId")
  createdAt: AWSDateTime
  updatedAt: AWSDateTime
}

But I decided to remove the connection all together to try a different approach.

Remove the fields with connections.

Expected behavior
I'm unsure.
Screenshots
N/A
Smartphone (please complete the following information):

Device: N/A
OS: MacOS
Browser N/A
Version 4.13.1

Additional context
Add any other context about the problem here.
Sample code
See above.

Hi @aprilmintacpineda this was addressed as a part of sanity checks the CLI implementing when it comes to adding and removing GSI's in one push.
Comment: https://github.com/aws-amplify/amplify-cli/issues/922#issuecomment-509418653

Yeah, I read that one. I was actually able to solve this and this was plainly my fault. However, could you tell me why 1 to 1 relationship with named connection always respond with null?


Provide basic metadata and versioning scheme for modules

Define basic properties of a module to make it future-proof:

sandbox version that it supports
WASM VM capabilities
signature from the producer
anything else?

Provide a mechanism to attach this manifest to a module.
/cc @douglas-reid (who might be interested in WASM distribution infrastructure)

I'm very interested in this topic.
I think your original list missed a few basics that may be base assumptions:

unique name
tag(s)
date of publish

And probably some way of adding metadata generically (allow publishers to describe inclided lib versions or other attributes important at audit time, etc.).