HDFS-14839: Use Java Concurrent BlockingQueue instead of Internal Blo…

…ckQueue

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Comment

0
reexec
42
Docker mode activated.

_ Prechecks _

+1
dupname
0
No case conflicting files found.

+1
@author
0
The patch does not contain any @author tags.

-1
test4tests
0
The patch doesn't appear to include any new or modified tests.  Please justify why no new tests are needed for this patch. Also please list what manual steps were performed to verify this patch.

_ trunk Compile Tests _

+1
mvninstall
1032
trunk passed

+1
compile
65
trunk passed

+1
checkstyle
46
trunk passed

+1
mvnsite
71
trunk passed

+1
shadedclient
792
branch has no errors when building and testing our client artifacts.

+1
javadoc
58
trunk passed

0
spotbugs
162
Used deprecated FindBugs config; considering switching to SpotBugs.

+1
findbugs
161
trunk passed

_ Patch Compile Tests _

+1
mvninstall
62
the patch passed

+1
compile
59
the patch passed

+1
javac
59
the patch passed

+1
checkstyle
40
hadoop-hdfs-project/hadoop-hdfs: The patch generated 0 new + 25 unchanged - 6 fixed = 25 total (was 31)

+1
mvnsite
63
the patch passed

+1
whitespace
0
The patch has no whitespace issues.

+1
shadedclient
729
patch has no errors when building and testing our client artifacts.

+1
javadoc
53
the patch passed

-1
findbugs
164
hadoop-hdfs-project/hadoop-hdfs generated 3 new + 0 unchanged - 0 fixed = 3 total (was 0)

_ Other Tests _

-1
unit
5289
hadoop-hdfs in the patch failed.

+1
asflicense
41
The patch does not generate ASF License warnings.

8837

Reason
Tests

FindBugs
module:hadoop-hdfs-project/hadoop-hdfs

Exceptional return value of java.util.concurrent.BlockingQueue.offer(Object) ignored in org.apache.hadoop.hdfs.server.blockmanagement.DatanodeDescriptor.addBlockToBeErasureCoded(ExtendedBlock, DatanodeDescriptor[], DatanodeStorageInfo[], byte[], ErasureCodingPolicy)  At DatanodeDescriptor.java:ignored in org.apache.hadoop.hdfs.server.blockmanagement.DatanodeDescriptor.addBlockToBeErasureCoded(ExtendedBlock, DatanodeDescriptor[], DatanodeStorageInfo[], byte[], ErasureCodingPolicy)  At DatanodeDescriptor.java:[line 624]

Exceptional return value of java.util.concurrent.BlockingQueue.offer(Object) ignored in org.apache.hadoop.hdfs.server.blockmanagement.DatanodeDescriptor.addBlockToBeRecovered(BlockInfo)  At DatanodeDescriptor.java:ignored in org.apache.hadoop.hdfs.server.blockmanagement.DatanodeDescriptor.addBlockToBeRecovered(BlockInfo)  At DatanodeDescriptor.java:[line 638]

Exceptional return value of java.util.concurrent.BlockingQueue.offer(Object) ignored in org.apache.hadoop.hdfs.server.blockmanagement.DatanodeDescriptor.addBlockToBeReplicated(Block, DatanodeStorageInfo[])  At DatanodeDescriptor.java:ignored in org.apache.hadoop.hdfs.server.blockmanagement.DatanodeDescriptor.addBlockToBeReplicated(Block, DatanodeStorageInfo[])  At DatanodeDescriptor.java:[line 612]

Failed junit tests
hadoop.hdfs.tools.TestDFSZKFailoverController

hadoop.hdfs.TestSafeMode

hadoop.hdfs.server.namenode.ha.TestBootstrapAliasmap

hadoop.hdfs.server.namenode.ha.TestDFSUpgradeWithHA

Subsystem
Report/Notes

Docker
Client=19.03.1 Server=19.03.1 base: https://builds.apache.org/job/hadoop-multibranch/job/PR-1422/1/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hadoop/pull/1422

JIRA Issue
HDFS-14839

Optional Tests
dupname asflicense compile javac javadoc mvninstall mvnsite unit shadedclient findbugs checkstyle

uname
Linux 846f1177826e 4.15.0-58-generic #64-Ubuntu SMP Tue Aug 6 11:12:41 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
personality/hadoop.sh

git revision
trunk / dacc448

Default Java
1.8.0_222

findbugs
https://builds.apache.org/job/hadoop-multibranch/job/PR-1422/1/artifact/out/new-findbugs-hadoop-hdfs-project_hadoop-hdfs.html

unit
https://builds.apache.org/job/hadoop-multibranch/job/PR-1422/1/artifact/out/patch-unit-hadoop-hdfs-project_hadoop-hdfs.txt

Test Results
https://builds.apache.org/job/hadoop-multibranch/job/PR-1422/1/testReport/

Max. process+thread count
4400 (vs. ulimit of 5500)

modules
C: hadoop-hdfs-project/hadoop-hdfs U: hadoop-hdfs-project/hadoop-hdfs

Console output
https://builds.apache.org/job/hadoop-multibranch/job/PR-1422/1/console

versions
git=2.7.4 maven=3.3.9 findbugs=3.1.0-RC1

Powered by
Apache Yetus 0.10.0 http://yetus.apache.org

This message was automatically generated.

There are findbugs warnings. Are they related?

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Comment

+0 :ok:
reexec
0m 30s
Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s
No case conflicting files found.

+1 :green_heart:
@author
0m  0s
The patch does not contain any @author tags.

-1 :x:
test4tests
0m  0s
The patch doesn't appear to include any new or modified tests. Please justify why no new tests are needed for this patch. Also please list what manual steps were performed to verify this patch.

_ trunk Compile Tests _

+1 :green_heart:
mvninstall
21m 50s
trunk passed

+1 :green_heart:
compile
1m 33s
trunk passed with JDK Ubuntu-11.0.8+10-post-Ubuntu-0ubuntu118.04.1

+1 :green_heart:
compile
1m 21s
trunk passed with JDK Private Build-1.8.0_252-8u252-b09-1~18.04-b09

+1 :green_heart:
checkstyle
0m 54s
trunk passed

+1 :green_heart:
mvnsite
1m 28s
trunk passed

+1 :green_heart:
shadedclient
19m 42s
branch has no errors when building and testing our client artifacts.

-1 :x:
javadoc
0m 39s
hadoop-hdfs in trunk failed with JDK Ubuntu-11.0.8+10-post-Ubuntu-0ubuntu118.04.1.

+1 :green_heart:
javadoc
0m 45s
trunk passed with JDK Private Build-1.8.0_252-8u252-b09-1~18.04-b09

+0 :ok:
spotbugs
3m 26s
Used deprecated FindBugs config; considering switching to SpotBugs.

+1 :green_heart:
findbugs
3m 23s
trunk passed

_ Patch Compile Tests _

+1 :green_heart:
mvninstall
1m 18s
the patch passed

+1 :green_heart:
compile
1m 27s
the patch passed with JDK Ubuntu-11.0.8+10-post-Ubuntu-0ubuntu118.04.1

+1 :green_heart:
javac
1m 27s
the patch passed

+1 :green_heart:
compile
1m 20s
the patch passed with JDK Private Build-1.8.0_252-8u252-b09-1~18.04-b09

+1 :green_heart:
javac
1m 20s
the patch passed

+1 :green_heart:
checkstyle
0m 49s
hadoop-hdfs-project/hadoop-hdfs: The patch generated 0 new + 24 unchanged - 6 fixed = 24 total (was 30)

+1 :green_heart:
mvnsite
1m 18s
the patch passed

+1 :green_heart:
whitespace
0m  0s
The patch has no whitespace issues.

+1 :green_heart:
shadedclient
17m  0s
patch has no errors when building and testing our client artifacts.

-1 :x:
javadoc
0m 35s
hadoop-hdfs in the patch failed with JDK Ubuntu-11.0.8+10-post-Ubuntu-0ubuntu118.04.1.

+1 :green_heart:
javadoc
0m 42s
the patch passed with JDK Private Build-1.8.0_252-8u252-b09-1~18.04-b09

-1 :x:
findbugs
3m 46s
hadoop-hdfs-project/hadoop-hdfs generated 3 new + 0 unchanged - 0 fixed = 3 total (was 0)

_ Other Tests _

-1 :x:
unit
99m 18s
hadoop-hdfs in the patch passed.

+1 :green_heart:
asflicense
0m 40s
The patch does not generate ASF License warnings.

181m 59s

Reason
Tests

FindBugs
module:hadoop-hdfs-project/hadoop-hdfs

Exceptional return value of java.util.concurrent.BlockingQueue.offer(Object) ignored in org.apache.hadoop.hdfs.server.blockmanagement.DatanodeDescriptor.addBlockToBeErasureCoded(ExtendedBlock, DatanodeDescriptor[], DatanodeStorageInfo[], byte[], ErasureCodingPolicy)  At DatanodeDescriptor.java:ignored in org.apache.hadoop.hdfs.server.blockmanagement.DatanodeDescriptor.addBlockToBeErasureCoded(ExtendedBlock, DatanodeDescriptor[], DatanodeStorageInfo[], byte[], ErasureCodingPolicy)  At DatanodeDescriptor.java:[line 630]

Exceptional return value of java.util.concurrent.BlockingQueue.offer(Object) ignored in org.apache.hadoop.hdfs.server.blockmanagement.DatanodeDescriptor.addBlockToBeRecovered(BlockInfo)  At DatanodeDescriptor.java:ignored in org.apache.hadoop.hdfs.server.blockmanagement.DatanodeDescriptor.addBlockToBeRecovered(BlockInfo)  At DatanodeDescriptor.java:[line 644]

Exceptional return value of java.util.concurrent.BlockingQueue.offer(Object) ignored in org.apache.hadoop.hdfs.server.blockmanagement.DatanodeDescriptor.addBlockToBeReplicated(Block, DatanodeStorageInfo[])  At DatanodeDescriptor.java:ignored in org.apache.hadoop.hdfs.server.blockmanagement.DatanodeDescriptor.addBlockToBeReplicated(Block, DatanodeStorageInfo[])  At DatanodeDescriptor.java:[line 618]

Failed junit tests
hadoop.hdfs.TestFileChecksum

hadoop.hdfs.server.namenode.TestNameNodeRetryCacheMetrics

hadoop.hdfs.TestDecommissionWithStriped

hadoop.hdfs.tools.TestDFSZKFailoverController

hadoop.hdfs.TestDecommissionWithStripedBackoffMonitor

hadoop.hdfs.server.balancer.TestBalancer

hadoop.hdfs.tools.TestECAdmin

hadoop.hdfs.TestReconstructStripedFile

hadoop.hdfs.server.blockmanagement.TestBlockManagerSafeMode

hadoop.hdfs.TestDecommissionWithBackoffMonitor

hadoop.hdfs.TestStripedFileAppend

hadoop.fs.contract.hdfs.TestHDFSContractMultipartUploader

hadoop.hdfs.TestReconstructStripedFileWithRandomECPolicy

hadoop.hdfs.TestDFSStripedOutputStreamWithRandomECPolicy

hadoop.hdfs.TestDecommission

hadoop.hdfs.TestWriteReadStripedFile

hadoop.hdfs.server.datanode.TestDataXceiverBackwardsCompat

Subsystem
Report/Notes

Docker
ClientAPI=1.40 ServerAPI=1.40 base: https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-1422/3/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hadoop/pull/1422

JIRA Issue
HDFS-14839

Optional Tests
dupname asflicense compile javac javadoc mvninstall mvnsite unit shadedclient findbugs checkstyle

uname
Linux adc1a60d64ab 4.15.0-60-generic #67-Ubuntu SMP Thu Aug 22 16:55:30 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
personality/hadoop.sh

git revision
trunk / e756fe35909

Default Java
Private Build-1.8.0_252-8u252-b09-1~18.04-b09

Multi-JDK versions
/usr/lib/jvm/java-11-openjdk-amd64:Ubuntu-11.0.8+10-post-Ubuntu-0ubuntu118.04.1 /usr/lib/jvm/java-8-openjdk-amd64:Private Build-1.8.0_252-8u252-b09-1~18.04-b09

javadoc
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-1422/3/artifact/out/branch-javadoc-hadoop-hdfs-project_hadoop-hdfs-jdkUbuntu-11.0.8+10-post-Ubuntu-0ubuntu118.04.1.txt

javadoc
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-1422/3/artifact/out/patch-javadoc-hadoop-hdfs-project_hadoop-hdfs-jdkUbuntu-11.0.8+10-post-Ubuntu-0ubuntu118.04.1.txt

findbugs
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-1422/3/artifact/out/new-findbugs-hadoop-hdfs-project_hadoop-hdfs.html

unit
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-1422/3/artifact/out/patch-unit-hadoop-hdfs-project_hadoop-hdfs.txt

Test Results
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-1422/3/testReport/

Max. process+thread count
4308 (vs. ulimit of 5500)

modules
C: hadoop-hdfs-project/hadoop-hdfs U: hadoop-hdfs-project/hadoop-hdfs

Console output
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-1422/3/console

versions
git=2.17.1 maven=3.6.0 findbugs=4.0.6

Powered by
Apache Yetus 0.12.0 https://yetus.apache.org

This message was automatically generated.


On Egg Import Egg does not get validated.

If i import an Egg with a variable that is required but doesnt have a standard value its ignoring it.
A docker image check would be also good.
Panel: 1fcad8d
Server's OS: Ubuntu 16.04
Your Computer's OS & Browser: Firefox 58.0b5 (64-Bit) Developer Edition, Windows 10 latest

Can you upload the file so we can test, thanks

@lancepioch well i cooked some egg to give you a better taste, have a great lunch:
https://hastebin.com/ititukumot.json
import the given egg

then press import aaand:

even if i save the complete egg

it will not check for the docker image
well i will create a seperate issue for this https://github.com/Pterodactyl/Panel/issues/782
but its also passing it without checking for the input value.

As you can see it saved my invalid standard values:

But atleast on this Site Lavarel Validation does work correctly:

with regards

I do not see a bug here, and your docker issue is not a bug, as I mentioned in the linked issue.
Can you please clarify exactly what you think the problem here is.

The problem is that it will not check the egg on import;
but thats more a P:low thread so

I'm sorry, I do not understand what you're trying to say is broken here. "will not check on egg-import" does not make sense to me.
What is not checked, what is not erring that you believe should be, because all of your screenshots appear completely normal.

Okay well the topic is about->
on Egg import the given variables in the json file have standard values.
and these standard variables must not match with the validation. i think this is kinda invalid.

The same thing as I said in the other issue about docker applies here. Setting a default value that doesn't meet the requirements of that field is an administrative user issue, not the fault of the Panel.


Asking token amount when sending ERC20

Fixes https://github.com/sunodo/sunodo/issues/386.
Send ERC20 should always ask for amount. Default value is still 1

You need to write a changeset and commit together.
Information on how to do it is above in this PR.

Can you squash the commits to a single one with a message that has the format:
fix(cli): fix sunodo send erc20 not asking for token amount

Can you squash the commits to a single one with a message that has the format: fix(cli): fix sunodo send erc20 not asking for token amount

Done


Considerations for multi geo environment

Per Kevin Lam (MS)
To fully enumerate all (non-root) sites on all geos, you will need to do this initial request to discover all geos; then use the returned root site URLs to compose further requests against each geo to enumerate all sites on that geo. Unfortunately this latter step cannot be done using Microsoft Graph - it needs to be a request directly against the sharepoint tenant, using a separate oauth token valid for that tenant/geo combination. These follow up requests would look something like:
GET https://{tenant}.sharepoint.com/_api/v2.0/sites
GET [https://{tenant}-EUR.sharepoint.com/_api/v2.0/sites]
GET [https://{tenant}-APC.sharepoint.com/_api/v2.0/sites]
etc.

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

ID: b05ccb12-48fb-7f65-a695-0846564d2bc2
Version Independent ID: 769c63c0-4981-7506-8320-56beafaa8770
Content: List sites - Microsoft Graph v1.0
Content Source: api-reference/v1.0/api/site-list.md
Product: sharepoint
Technology: microsoft-graph
GitHub Login: @JeremyKelley
Microsoft Alias: MSGraphDocsVteam

As part of a repository clean up effort we are closing older issues. If this issue remains, please: open a new issue, reference this issue, and provide any additional details that may help in resolution. Thank you for your understanding as we work to improve our responsiveness.


Search is Case Sensitive - Document It!

Summary
Just document that the search box is case-sensitive
Please describe the problem you are trying to solve.
I expect that search is not case sensitive. When it is I'm surprised.
Proposed Solution
Add a little bit of text to tell me that I should capitalize things.

Surfaced by @richardbobo1


Docker Image

Is the Docker Image already available?

there is this - https://hub.docker.com/r/athlon1600/notepad
I will update instructions to make it pull that instead of having it to build everytime


Migrate tests for footer from cypress to selenium

@sheralim012 @edmoss345 I've made an attempt at introducing 'Page objects' (1, 2) in the Selenium tests. Let me know if you think this would be useful, and any other comments you may have.

@istride looks good to me, use of the 'Page objects' seems like a good idea as should make everything more readable and repeatable. Understand how you've used them, but think I should be taking more advantage in the tests I am writing. Maybe once I've got a decent size PR of tests together (currently working on #1377 ), we can discuss some best practice for using the pages and modify my code as required


Server side rendering window object not rendered

hi i have this code in my index method and when i check the page source it doesnt have the window object that i assigned in the globals...but when i switch on using the tag helper its perfectly fine i can see the window object
 public async Task<IActionResult> Index()
    {
        var nodeServices = Request.HttpContext.RequestServices.GetRequiredService<INodeServices>();
        var hostEnv = Request.HttpContext.RequestServices.GetRequiredService<IHostingEnvironment>();

        var applicationBasePath = hostEnv.ContentRootPath;
        var requestFeature = Request.HttpContext.Features.Get<IHttpRequestFeature>();
        var unencodedPathAndQuery = requestFeature.RawTarget;
        var unencodedAbsoluteUrl = $"{Request.Scheme}://{Request.Host}{unencodedPathAndQuery}";

        TransferData transferData = new TransferData();
        transferData.Request = AbstractHttpContextRequestInfo(Request); // You can automatically grab things from the REQUEST object in Angular because of this

        // Prerender / Serialize application (with Universal)

        var prerenderResult = await Prerenderer.RenderToString(
            "/", // baseURL
            nodeServices,
            new JavaScriptModuleExport(applicationBasePath + "/ClientApp/dist/boot-server"),
            unencodedAbsoluteUrl,
            unencodedPathAndQuery,
            // Our Transfer data here will be passed down to Angular (within the main.server file)
            // Available there via `params.data.yourData`
            transferData,
            30000,
            Request.PathBase
        );

        // This is where everything is now spliced out, and given to .NET in pieces
        ViewData["SpaHtml"] = prerenderResult.Html;
        if (prerenderResult.RedirectUrl != null)
        {
            return LocalRedirect(prerenderResult.RedirectUrl);
        }

        return View();
    }

and in my view

@Html.Raw(ViewData["SpaHtml"])

but no luck i cant see the window object

The data you assign to globals will be returned to your .NET code as prerenderResult.Globals. It's up to you to then pass that from your MVC action to your view and render it into the page however you want. That doesn't happen automatically - it's not part of prerenderResult.Html, because it's up to you how you want to serialize it and where you want to inject it into the page.
As an example, you can see the code that the built-in asp-prerender-module tag helper uses to extract and format the data here: https://github.com/aspnet/JavaScriptServices/blob/dev/src/Microsoft.AspNetCore.SpaServices/Prerendering/PrerenderTagHelper.cs#L137


multilicensing for LLVM

as discussed @oconnor663

Added some more changes on top and merged. Nightly CI failures are unrelated new warnings, will fill those in a followup.


[Checkout UI] Extension selling plan doesn't work with express checkout

Please list the package(s) involved in the issue, and include the version you are using
"@shopify/app": "^3.50.0",
"@shopify/cli": "^3.50.0",
"@shopify/ui-extensions": "^2023.10.0",
"@shopify/ui-extensions-react": "^2023.10.0",
"@shopify/shopify-api": "^7.3.1",
"@shopify/shopify-app-express": "^2.1.3",
"@shopify/shopify-app-session-storage-mysql": "^1.1.13",

Describe the bug
When applying a selling plan on the checkout page, if the store has express checkouts installed (shop pay, google pay, paypal etc), they all crash. The selling plan is still applied but the user isn't able to use the express checkouts. Also, if the user decides to use an express checkout like shop pay, and they are already signed in, if the selling plan is applied afterwards, it still crashes and reroutes with an error to a new checkout page without the express checkouts. The type of selling plan applied does one payment now and another in the future.
Our testing suggests that this isn't a bug limited to selling plans being applied to a checkout at the point of checkout. If you generate a checkout with a selling plan applied, there are no express checkouts available to the user. All express checkouts don't work with selling plans.
Steps to reproduce the behavior:

Install express checkouts on your shop
Apply a selling plan to a product and checkout.
Notice that the selling the express checkouts aren't visible.

Expected behavior
We expect the express checkouts to be visible and useable when the cart has a selling plan applied to it.
Screenshots
When a selling plan is applied at the point of checkout, using a checkout extension app, the page crashes (as seen in the screenshot) and then automatically redirected to the checkout page with the selling plan applied but the express checkouts not there:

Additional context
The below code snippet is causing the crash. Specifically, applyCartLinesChange. We have checked that type, id and sellingPlanId are all correct.
Here's the link to the docs: https://shopify.dev/docs/api/checkout-ui-extensions/unstable/apis/cart-lines#checkoutapi-propertydetail-applycartlineschange
const sellingPlan: CartLineChange = {
type: "updateCartLine",
id: cartLineId,
sellingPlanId: sellingPlanId,
};
const api = useApi();
await api.applyCartLinesChange(sellingPlan);

Hi @algoad I am not able to reproduce this issue on my end. I created an extension that adds/removes a selling plan to a line item, and am able to successfully do this with no errors or disappearing accelerated checkouts. I'm also able to add and remove the selling plan in the Shop Pay checkout without any issues.
If you are still experiencing the issue could you please supply the full code of an extension that reproduces the error? With any additional setup/information to reproduce.

Hi @Steve-D-Powell ,
Perhaps your selling group is specified slightly differently to ours. Currently we have the selling plan group that is created with the following mutation. You can tweak it slightly, however the idea is that the customer pays X% now and the remaining balance due in 14 days.
This allows us to achieve the following goals. The customer enters into an agreement where they pay a discount up front and they will be charged at a later date. However, if the customer performs action XYZ via our external system, we will mark their order as paid so they can keep their discount. If not, they will be charged the remaining balance.
We apply the selling plan to the cart by looping through the cart line item and attaching each selling plan to the item. Then then applying the selling plan to that item. The code to apply the selling plan looks like this:
const sellingPlan: CartLineChange = {
  type: "updateCartLine",
  id: cartLineId,
  sellingPlanId: sellingPlanId,
};
const api = useApi();
await api.applyCartLinesChange(sellingPlan);

Side note: We use script tags to hide the selling plan on the product page.
Please visit the following document that has videos and explanations. Feel free to email me at<EMAIL_ADDRESS>and I would be happy to explain further. We have spoken to shopify support and do believe their is an active issue that needs resolving.
https://docs.google.com/document/d/1krWviOGJsPLEmX19AV26auLcgO6zPhZPwbBojKJz320/edit
const mutation = `
  mutation {
    sellingPlanGroupCreate(
      input: {
        name: "test-selling-plan-group"
        merchantCode: "test-selling-plan"
        options: [
          "Pre-order"
        ]
        sellingPlansToCreate: [
          {
            name: "Placeholder Group Name (50%)"
            category: PRE_ORDER
            options: [
              "50% deposit"
            ]
            billingPolicy: {
              fixed: {
                checkoutCharge: {type: PERCENTAGE, value: {percentage: 50}}
                remainingBalanceChargeTrigger: TIME_AFTER_CHECKOUT
                remainingBalanceChargeTimeAfterCheckout: "P14D"
              }
            }
            pricingPolicies: [
              {
                fixed: {
                  adjustmentType: PERCENTAGE
                  adjustmentValue: { percentage: 0 }
                }
              }
            ]
            deliveryPolicy: {fixed: {fulfillmentTrigger: UNKNOWN}}
            inventoryPolicy: {reserve: ON_FULFILLMENT}
          },
          // ... Additional selling plans with different percentages and deposit values
        ]
      }
    ) {
      sellingPlanGroup {
        id
      }
      userErrors {
        field
        message
      }
    }
  }
  `;

@Steve-D-Powell - Please let me know if I can provide you with further details.


Fix cloudflare cache problem

cloudflare also caches the content of the authentication page in some cases, this should prevent the case

@Charca

I can confirm the fix from @ReneWerner87 worked for me.
After applying the fix the Cloudflare page behind the login screen became 100% functional. It was not the case before the fix.

Thanks for the PR! (and sorry for the delay)


Elasticsearch 8.x support

Requirement - what kind of business use case are you trying to solve?
Elastic recently released Elasticsearch 8.0, by now they've released 8.1.
Problem - what in Jaeger blocks you from solving the requirement?
The ES index can't be created anymore, I think the legacy template api part is now completely deprecated:

jaeger-collector    | {"level":"info","ts":1646824639.4679213,"caller":"config/config.go:205","msg":"Elasticsearch detected","version":8}
jaeger-collector    | {"level":"info","ts":1646824639.4697242,"caller":"zapgrpc/zapgrpc.go:129","msg":"Deprecation warning: 299 Elasticsearch-8.1.0-3700f7679f7d95e36da0b43762189bab189bc53a \"Legacy index templates are deprecated in favor of composable templates.\""}
jaeger-collector    | {"level":"fatal","ts":1646824639.4699457,"caller":"./main.go:84","msg":"Failed to create span writer","error":"elastic: Error 400 (Bad Request): unknown key [template] in the template  [type=parse_exception]","stacktrace":"main.main.func1\n\t./main.go:84\ngithub.com/spf13/cobra.(*Command).execute\n\tgithub.com/spf13/cobra@v1.3.0/command.go:856\ngithub.com/spf13/cobra.(*Command).ExecuteC\n\tgithub.com/spf13/cobra@v1.3.0/command.go:974\ngithub.com/spf13/cobra.(*Command).Execute\n\tgithub.com/spf13/cobra@v1.3.0/command.go:902\nmain.main\n\t./main.go:147\nruntime.main\n\truntime/proc.go:255"}

The https://www.elastic.co/guide/en/elasticsearch/reference/8.1/migrating-8.0.html lists now (somewhere in the middle)
The [create or update index template API](https://www.elastic.co/guide/en/elasticsearch/reference/8.1/indices-templates-v1.html)’s template parameter has been removed.

Details
In 6.0, we deprecated the template parameter in create or update index template requests in favor of using index_patterns. Support for the template parameter is now removed in 8.0.

Impact
Use the create or update index template API's index_patterns parameter. Requests that include the template parameter will return an error.

I think the code falls back to the unversioned mappings if it does not find a specific mapping
So, in my opinion the code should not fall back to the jaeger-span.json mapping but instead use the
jaeger-span-7.json for newer versions, e.g. use the -7 jsons for 8 etc.
e.g. change line 42 from == 7 to >=7
https://github.com/jaegertracing/jaeger/blob/7872d1b07439c3f2d316065b1fd53e885b26a66f/plugin/storage/es/mappings/mapping.go#L40-L46
Workaround
Force the ES Version to 7 via --es.version=7

Would you like to submit a PR? Besides the logic fix it would need to add v8 to the CI steps.

Sure, I'll give it a try.

I spent time investigating the effort in achieving it. I think this is going to be difficult now that we use same elasticsearch client olivere/elastic to support both of our elasticsearch and opensearch implementations.
Major challenge:
Right now we are using v6 of olivere/elastic which doesn't have support for new index template. To support it we need to update to v7  of olivere/elastic specifically for https://github.com/olivere/elastic/pull/1458 and https://github.com/olivere/elastic/pull/1415  which intern breaks the opensearch support.
Not sure how we should proceed.

Workaround
Force the ES Version to 7 via --es.version=7

I have tried latest helm operator installation and setting this parameter didn't result in anything better.

Would it be possible for Jaeger to add a separate docker image/branch which maintains opensearch support and the main branch getting support for Elasticsearch 8.x ?

hope to support elasticsearch 8.1.x

We are working on bootstrapping Jaeger v2 which will be based on OTEL collector. This will allow us to have ES exporter per ES version.

Is there any workaround currently available, e.g., creating the index manually?
I tried the OP's suggested workaround (with elastic 8.1.3) and I get the following error:
legacy template [jaeger-span] has index patterns [*jaeger-span-*] matching patterns from existing composable templates [.deprecation-indexing-template,.ml-anomalies-,.ml-state,.ml-stats,.monitoring-beats-mb,.monitoring-ent-search-mb,.monitoring-es-mb,.monitoring-kibana-mb,.monitoring-logstash-mb,.slm-history,.watch-history-16,ilm-history,logs,metrics,synthetics] with patterns (.deprecation-indexing-template => [.logs-deprecation.*],.ml-anomalies- => [.ml-anomalies-*],.ml-state => [.ml-state*],.ml-stats => [.ml-stats-*],.monitoring-beats-mb => [.monitoring-beats-8-*],.monitoring-ent-search-mb => [.monitoring-ent-search-8-*],.monitoring-es-mb => [.monitoring-es-8-*],.monitoring-kibana-mb => [.monitoring-kibana-8-*],.monitoring-logstash-mb => [.monitoring-logstash-8-*],.slm-history => [.slm-history-5*],.watch-history-16 => [.watcher-history-16*],ilm-history => [ilm-history-5*],logs => [logs-*-*],metrics => [metrics-*-*],synthetics => [synthetics-*-*]), use composable templates (/_index_template) instead

I would be thankful for any workaround too.
We need to upgrade our elasticsearch cluster but we are stuck because of this problem

we also need this asap!!!!!!1

we also need this asap! +1

Hi,
Workaround
Force the ES Version to 7 via --es.version=7
Add add this two indexes
PUT _index_template/jaeger-service
{
  "priority": 1,
  "template": {
    "settings": {
      "index": {
        "mapping": {
          "nested_fields": {
            "limit": "50"
          }
        },
        "requests": {
          "cache": {
            "enable": "true"
          }
        },
        "number_of_shards": "6",
        "number_of_replicas": "1"
      }
    },
    "mappings": {
      "_routing": {
        "required": false
      },
      "_size": {
        "enabled": false
      },
      "numeric_detection": false,
      "dynamic_date_formats": [
        "strict_date_optional_time",
        "yyyy/MM/dd HH:mm:ss Z||yyyy/MM/dd Z"
      ],
      "_source": {
        "excludes": [],
        "includes": [],
        "enabled": true
      },
      "dynamic": true,
      "dynamic_templates": [
        {
          "span_tags_map": {
            "path_match": "tag.*",
            "mapping": {
              "ignore_above": 256,
              "type": "keyword"
            }
          }
        },
        {
          "process_tags_map": {
            "path_match": "process.tag.*",
            "mapping": {
              "ignore_above": 256,
              "type": "keyword"
            }
          }
        }
      ],
      "date_detection": true,
      "properties": {
        "operationName": {
          "type": "keyword"
        },
        "serviceName": {
          "type": "keyword"
        }
      }
    }
  },
  "index_patterns": [
    "*jaeger-service-*"
  ],
  "composed_of": []
}

PUT _index_template/jaeger-span
{
  "priority": 2,
  "template": {
    "settings": {
      "index": {
        "mapping": {
          "nested_fields": {
            "limit": "50"
          }
        },
        "requests": {
          "cache": {
            "enable": "true"
          }
        },
        "number_of_shards": "6",
        "number_of_replicas": "1"
      }
    },
    "mappings": {
      "_routing": {
        "required": false
      },
      "_size": {
        "enabled": false
      },
      "numeric_detection": false,
      "dynamic_date_formats": [
        "strict_date_optional_time",
        "yyyy/MM/dd HH:mm:ss Z||yyyy/MM/dd Z"
      ],
      "dynamic": true,
      "_source": {
        "excludes": [],
        "includes": [],
        "enabled": true
      },
      "dynamic_templates": [
        {
          "span_tags_map": {
            "path_match": "tag.*",
            "mapping": {
              "ignore_above": 256,
              "type": "keyword"
            }
          }
        },
        {
          "process_tags_map": {
            "path_match": "process.tag.*",
            "mapping": {
              "ignore_above": 256,
              "type": "keyword"
            }
          }
        }
      ],
      "date_detection": true,
      "properties": {
        "traceID": {
          "type": "keyword"
        },
        "process": {
          "type": "object",
          "properties": {
            "tag": {
              "type": "object"
            },
            "serviceName": {
              "type": "keyword"
            },
            "tags": {
              "type": "nested",
              "properties": {
                "tagType": {
                  "type": "keyword"
                },
                "value": {
                  "type": "keyword"
                },
                "key": {
                  "type": "keyword"
                }
              }
            }
          }
        },
        "references": {
          "type": "nested",
          "properties": {
            "spanID": {
              "type": "keyword"
            },
            "traceID": {
              "type": "keyword"
            },
            "refType": {
              "type": "keyword"
            }
          }
        },
        "startTimeMillis": {
          "type": "date"
        },
        "flags": {
          "type": "integer"
        },
        "operationName": {
          "type": "keyword"
        },
        "parentSpanID": {
          "type": "keyword"
        },
        "tags": {
          "type": "nested",
          "properties": {
            "tagType": {
              "type": "keyword"
            },
            "value": {
              "type": "keyword"
            },
            "key": {
              "type": "keyword"
            }
          }
        },
        "duration": {
          "type": "long"
        },
        "spanID": {
          "type": "keyword"
        },
        "startTime": {
          "type": "long"
        },
        "tag": {
          "type": "object",
          "properties": {}
        },
        "logs": {
          "type": "nested",
          "properties": {
            "fields": {
              "type": "nested",
              "properties": {
                "tagType": {
                  "type": "keyword"
                },
                "value": {
                  "type": "keyword"
                },
                "key": {
                  "type": "keyword"
                }
              }
            },
            "timestamp": {
              "type": "long"
            }
          }
        }
      }
    }
  },
  "index_patterns": [
    "*jaeger-span-*"
  ],
  "composed_of": []
}

Hi,
Workaround
Force the ES Version to 7 via --es.version=7 and es.create-index-templates: false
Add add this two indexes. If some of them fails related to "index priority" just change it
PUT _index_template/jaeger-service
{
  "priority": 1,
  "template": {
    "settings": {
      "index": {
        "mapping": {
          "nested_fields": {
            "limit": "50"
          }
        },
        "requests": {
          "cache": {
            "enable": "true"
          }
        },
        "number_of_shards": "6",
        "number_of_replicas": "1"
      }
    },
    "mappings": {
      "_routing": {
        "required": false
      },
      "_size": {
        "enabled": false
      },
      "numeric_detection": false,
      "dynamic_date_formats": [
        "strict_date_optional_time",
        "yyyy/MM/dd HH:mm:ss Z||yyyy/MM/dd Z"
      ],
      "_source": {
        "excludes": [],
        "includes": [],
        "enabled": true
      },
      "dynamic": true,
      "dynamic_templates": [
        {
          "span_tags_map": {
            "path_match": "tag.*",
            "mapping": {
              "ignore_above": 256,
              "type": "keyword"
            }
          }
        },
        {
          "process_tags_map": {
            "path_match": "process.tag.*",
            "mapping": {
              "ignore_above": 256,
              "type": "keyword"
            }
          }
        }
      ],
      "date_detection": true,
      "properties": {
        "operationName": {
          "type": "keyword"
        },
        "serviceName": {
          "type": "keyword"
        }
      }
    }
  },
  "index_patterns": [
    "*jaeger-service-*"
  ],
  "composed_of": []
}

PUT _index_template/jaeger-span
{
  "priority": 2,
  "template": {
    "settings": {
      "index": {
        "mapping": {
          "nested_fields": {
            "limit": "50"
          }
        },
        "requests": {
          "cache": {
            "enable": "true"
          }
        },
        "number_of_shards": "6",
        "number_of_replicas": "1"
      }
    },
    "mappings": {
      "_routing": {
        "required": false
      },
      "_size": {
        "enabled": false
      },
      "numeric_detection": false,
      "dynamic_date_formats": [
        "strict_date_optional_time",
        "yyyy/MM/dd HH:mm:ss Z||yyyy/MM/dd Z"
      ],
      "dynamic": true,
      "_source": {
        "excludes": [],
        "includes": [],
        "enabled": true
      },
      "dynamic_templates": [
        {
          "span_tags_map": {
            "path_match": "tag.*",
            "mapping": {
              "ignore_above": 256,
              "type": "keyword"
            }
          }
        },
        {
          "process_tags_map": {
            "path_match": "process.tag.*",
            "mapping": {
              "ignore_above": 256,
              "type": "keyword"
            }
          }
        }
      ],
      "date_detection": true,
      "properties": {
        "traceID": {
          "type": "keyword"
        },
        "process": {
          "type": "object",
          "properties": {
            "tag": {
              "type": "object"
            },
            "serviceName": {
              "type": "keyword"
            },
            "tags": {
              "type": "nested",
              "properties": {
                "tagType": {
                  "type": "keyword"
                },
                "value": {
                  "type": "keyword"
                },
                "key": {
                  "type": "keyword"
                }
              }
            }
          }
        },
        "references": {
          "type": "nested",
          "properties": {
            "spanID": {
              "type": "keyword"
            },
            "traceID": {
              "type": "keyword"
            },
            "refType": {
              "type": "keyword"
            }
          }
        },
        "startTimeMillis": {
          "type": "date"
        },
        "flags": {
          "type": "integer"
        },
        "operationName": {
          "type": "keyword"
        },
        "parentSpanID": {
          "type": "keyword"
        },
        "tags": {
          "type": "nested",
          "properties": {
            "tagType": {
              "type": "keyword"
            },
            "value": {
              "type": "keyword"
            },
            "key": {
              "type": "keyword"
            }
          }
        },
        "duration": {
          "type": "long"
        },
        "spanID": {
          "type": "keyword"
        },
        "startTime": {
          "type": "long"
        },
        "tag": {
          "type": "object",
          "properties": {}
        },
        "logs": {
          "type": "nested",
          "properties": {
            "fields": {
              "type": "nested",
              "properties": {
                "tagType": {
                  "type": "keyword"
                },
                "value": {
                  "type": "keyword"
                },
                "key": {
                  "type": "keyword"
                }
              }
            },
            "timestamp": {
              "type": "long"
            }
          }
        }
      }
    }
  },
  "index_patterns": [
    "*jaeger-span-*"
  ],
  "composed_of": []
}

It Works ! thanks 👍

As part of adding support for the newer index template API, it might be nice to have the option for Jaeger to create component templates instead of index templates.
With the current API we have a couple of other index templates targetting jaeger indices that all get merged together to perform the following modifications:

Set custom default settings that apply to all our indices (Tier routing, refresh interval, translog settings etc.)
Modify some field mappings (e.g. we set eager_global_ordinals on traceID for better search performance)

With the new index template API this won't be possible as only one index template wll be chosen (highest priority) and even if Jaeger supporting passing composed_of values to the template, which would allow us to pull in our default index settings, anything still explicitly set by Jaeger template (e.g. the traceID field mapping) would take precedence over our modifications.
I'm not sure if this is a common use case or not, otherwise we may choose to disable Jaeger index template creation and just managed them entirely ourselves, however pulling in any new field mappings etc. automatically when upgrading Jaeger is handy

Thanks @sergiomcalzada that worked:
storage:
    type: elasticsearch
    options:
      es:
        server-urls: http://elasticsearch.elastic-db:9200
        index-prefix: jaeger_
        version: 7                                  # Necessary as it doesn't work with 8 yet
        create-index-templates: false               # Necessary as it doesn't work with 8 yet

Fyi, https://github.com/jaegertracing/spark-dependencies is not working with es8.x also.
That means it cannot really be used in production IMHO

We are experiencing problems connecting Jaeger to our existing ES setup due to this issue.
I've gone ahead and followed the work around instructions above, currently using the Helm chart for setup.
Ex:
   cmdlineParams:
      es.version: 7
      es.create-index-templates: false

But no matter I still see this error relating to the template index patterns:
"caller":"./main.go:69","msg":"Failed to create span writer","error":"elastic: Error 400 (Bad Request): legacy template [jaeger-span] has index patterns [*jaeger-span-*] matching patterns from existing composable templates
I have also tried removing the leading * from the templates, but the error message stayed the same which leads me to believe this is still on the Jaeger end of things.
Anyone have further workaround info/updates on ES8 support?

Looks like this was some yaml mangling - No matter what was specified, checking the config state on the ingester showed
spec:
  containers:
  - args:
    - --es.create-index-templates
    - --es.version=7

Solution: quote the false
   cmdlineParams:
      es.version: 7
      es.create-index-templates: "false"

Which becomes:
spec:
  containers:
  - args:
    - --es.create-index-templates=false
    - --es.version=7

@Ashmita152 I came across https://github.com/olivere/elastic/issues/1533, where the author of the library unequivocally states:

Elastic v8 won't happen. I will polish v7 if I have the time and energy, but v8 won't happen. I'm sorry.

So there seems to be little point in upgrading to v7 of the library as it won't support v8 of ES.
Unlike our Cassandra implementation that uses an internal abstraction over gocql driver, the ES implementation has a large exposure to many different types from olivere/elastic driver. This complicates things a lot if we want to support both ESv8 and OpenSearch using different drivers.
ESv7 will be EOL-ed by 2023-08-01.

@yurishkuro Could you please clarify whether Jaeger is going to support ElasticSearch v8.+?

@yurishkuro Any thoughts about my previous comment?

Thank you @sergiomcalzada. It works. We're also using ILM/aliases, which changes the configuration a little bit.
Script to apply all manifests
Make sure you named the files correctly
#! /bin/bash

function apply_ilm() {
	policy_name=$1
	file_name=$2
	curl -Ss -XPUT -H 'Content-Type: application/json' \
	    -d @"${file_name}" \
	    "http://localhost:9200/_ilm/policy/${policy_name}"
}

function apply_template() {
	template_name=$1
	file_name=$2
	curl -Ss -XPUT -H 'Content-Type: application/json' \
		-d @"${file_name}" \
		"http://localhost:9200/_index_template/${template_name}"
}

function apply_index() {
	index_name=$1
	file_name=$2
	curl -Ss -XPUT -H 'Content-Type: application/json' \
		-d @"${file_name}" \
		"http://localhost:9200/${index_name}"
}

apply_ilm "jaeger" jaeger.ilm.json
apply_template "jaeger-service" jaeger-service.tpl.json
apply_template "jaeger-span" jaeger-span.tpl.json
apply_index "jaeger-service-000001" jaeger-service-000001.idx.json
apply_index "jaeger-span-000001" jaeger-span-000001.idx.json

ILM manfest (jaeger.ilm.json)
{
  "policy": {
    "phases": {
      "hot": {
        "min_age": "0ms",
        "actions": {
          "rollover": {
            "max_age": "4h"
          },
          "set_priority": {
            "priority": 100
          }
        }
      },
      "delete": {
        "min_age": "2d",
        "actions": {
          "delete": {}
        }
      }
    }
  }
}

Spans Composable Template (jaeger-span.tpl.json)
{
  "version": 3,
  "index_patterns": [
    "*jaeger-span-*"
  ],
  "priority": 101,
  "template": {
    "settings": {
      "index": {
        "lifecycle": {
          "name": "jaeger",
          "rollover_alias": "jaeger-span-write"
        },
        "mapping": {
          "nested_fields": {
            "limit": "50"
          }
        },
        "requests": {
          "cache": {
            "enable": "true"
          }
        },
        "number_of_shards": 5
      }
    },
    "aliases": {
      "jaeger-span-read": {}
    },
    "mappings": {
      "_routing": {
        "required": false
      },
      "numeric_detection": false,
      "dynamic_date_formats": [
        "strict_date_optional_time",
        "yyyy/MM/dd HH:mm:ss Z||yyyy/MM/dd Z"
      ],
      "dynamic": true,
      "_source": {
        "excludes": [],
        "includes": [],
        "enabled": true
      },
      "dynamic_templates": [
        {
          "span_tags_map": {
            "path_match": "tag.*",
            "mapping": {
              "ignore_above": 256,
              "type": "keyword"
            }
          }
        },
        {
          "process_tags_map": {
            "path_match": "process.tag.*",
            "mapping": {
              "ignore_above": 256,
              "type": "keyword"
            }
          }
        }
      ],
      "date_detection": true,
      "properties": {
        "traceID": {
          "type": "keyword"
        },
        "process": {
          "type": "object",
          "properties": {
            "tag": {
              "type": "object"
            },
            "serviceName": {
              "type": "keyword"
            },
            "tags": {
              "type": "nested",
              "properties": {
                "tagType": {
                  "type": "keyword"
                },
                "value": {
                  "type": "keyword"
                },
                "key": {
                  "type": "keyword"
                }
              }
            }
          }
        },
        "references": {
          "type": "nested",
          "properties": {
            "spanID": {
              "type": "keyword"
            },
            "traceID": {
              "type": "keyword"
            },
            "refType": {
              "type": "keyword"
            }
          }
        },
        "startTimeMillis": {
          "type": "date"
        },
        "flags": {
          "type": "integer"
        },
        "operationName": {
          "type": "keyword"
        },
        "parentSpanID": {
          "type": "keyword"
        },
        "tags": {
          "type": "nested",
          "properties": {
            "tagType": {
              "type": "keyword"
            },
            "value": {
              "type": "keyword"
            },
            "key": {
              "type": "keyword"
            }
          }
        },
        "duration": {
          "type": "long"
        },
        "spanID": {
          "type": "keyword"
        },
        "startTime": {
          "type": "long"
        },
        "tag": {
          "type": "object",
          "properties": {}
        },
        "logs": {
          "type": "nested",
          "properties": {
            "fields": {
              "type": "nested",
              "properties": {
                "tagType": {
                  "type": "keyword"
                },
                "value": {
                  "type": "keyword"
                },
                "key": {
                  "type": "keyword"
                }
              }
            },
            "timestamp": {
              "type": "long"
            }
          }
        }
      }
    }
  },
  "composed_of": []
}

Services Composable Template (jaeger-service.tpl.json)
{
  "version": 3,
  "index_patterns": [
    "*jaeger-service-*"
  ],
  "priority": 102,
  "template": {
    "settings": {
      "index": {
        "lifecycle": {
          "name": "jaeger",
          "rollover_alias": "jaeger-service-write"
        },
        "mapping": {
          "nested_fields": {
            "limit": "50"
          }
        },
        "requests": {
          "cache": {
            "enable": "true"
          }
        },
        "number_of_shards": 5
      }
    },
    "aliases": {
      "jaeger-service-read": {}
    },
    "mappings": {
      "_routing": {
        "required": false
      },
      "numeric_detection": false,
      "dynamic_date_formats": [
        "strict_date_optional_time",
        "yyyy/MM/dd HH:mm:ss Z||yyyy/MM/dd Z"
      ],
      "dynamic": true,
      "_source": {
        "excludes": [],
        "includes": [],
        "enabled": true
      },
      "dynamic_templates": [
        {
          "span_tags_map": {
            "path_match": "tag.*",
            "mapping": {
              "ignore_above": 256,
              "type": "keyword"
            }
          }
        },
        {
          "process_tags_map": {
            "path_match": "process.tag.*",
            "mapping": {
              "ignore_above": 256,
              "type": "keyword"
            }
          }
        }
      ],
      "date_detection": true,
      "properties": {
        "operationName": {
          "type": "keyword"
        },
        "serviceName": {
          "type": "keyword"
        }
      }
    }
  },
  "composed_of": []
}

Spans rollover origin index (jaeger-span-000001.idx.json)
Since it's not possible to add rollover writable aliases using templates, you'll have to deploy the origin index manually.
{
    "aliases": {
        "jaeger-span-write": {
            "is_write_index": true
        }
    }
}

Services rollover origin index (jaeger-service-000001.idx.json)
{
    "aliases": {
        "jaeger-service-write": {
            "is_write_index": true
        }
    }
}

K8s Jaeger Operator
If you're using the k8s operator to deploy your Jaeger stack, the all-in-one distribution won't work since it'll try to create the rollover job because of the necessary flag use-aliases: true. You'll have to use the version of the separate components. This is a basic setup using Jaeger CRD manifest:
apiVersion: jaegertracing.io/v1
kind: Jaeger
metadata:
  name: jaeger
spec:
  collector:
    options:
      es:
        use-aliases: true
        use-ilm: true
  query:
    options:
      es:
        use-aliases: true
        use-ilm: true
  storage:
    type: elasticsearch
    options:
      es:
        version: 7
        create-index-templates: false
        server-urls: http://elasticsearch:9200

  # Necessary for elasticsearch integration to work properly
  # read more: https://github.com/jaegertracing/jaeger-operator/issues/1187
  strategy: production

Elasticsearch is up to 8.5.0 and still waiting on an update? Using out of date infrastructure in production is becoming a burden.

Opensearch is a good alternative. Not sure there is interest in building support for 9.x. There are also other backends which are efficient as options.

We are experiencing problems connecting Jaeger to our existing ES setup due to this issue. I've gone ahead and followed the work around instructions above, currently using the Helm chart for setup.
Ex:
   cmdlineParams:
      es.version: 7
      es.create-index-templates: false

But no matter I still see this error relating to the template index patterns:
"caller":"./main.go:69","msg":"Failed to create span writer","error":"elastic: Error 400 (Bad Request): legacy template [jaeger-span] has index patterns [*jaeger-span-*] matching patterns from existing composable templates
I have also tried removing the leading * from the templates, but the error message stayed the same which leads me to believe this is still on the Jaeger end of things.
Anyone have further workaround info/updates on ES8 support?

try to use env as workaroud:
    extraEnv:
      - name: ES_VERSION
        value: "7"
      - name: ES_CREATE_INDEX_TEMPLATES
        value: "false"

mangli

This is a bug in the helm char: False property are treat as true.
https://github.com/jaegertracing/helm-charts/blob/main/charts/jaeger/templates/collector-deploy.yaml#L53

which value we need to modify to work properly

which value we need to modify to work properly

As workaround? Just use "false" instead of false.
To fix the chart, check if values are empty or null instead of false:
The bugged code:
          {{- if $value }}
          - --{{ $key }}={{ $value }}
          {{- else }}
          - --{{ $key }}

Any progress?

anybody can tell me, now it support to 8.x??

Hi,
Workaround
Force the ES Version to 7 via --es.version=7 and es.create-index-templates: false
Add add this two indexes. If some of them fails related to "index priority" just change it
PUT _index_template/jaeger-service
{
  "priority": 1,
  "template": {
    "settings": {
      "index": {
        "mapping": {
          "nested_fields": {
            "limit": "50"
          }
        },
        "requests": {
          "cache": {
            "enable": "true"
          }
        },
        "number_of_shards": "6",
        "number_of_replicas": "1"
      }
    },
    "mappings": {
      "_routing": {
        "required": false
      },
      "_size": {
        "enabled": false
      },
      "numeric_detection": false,
      "dynamic_date_formats": [
        "strict_date_optional_time",
        "yyyy/MM/dd HH:mm:ss Z||yyyy/MM/dd Z"
      ],
      "_source": {
        "excludes": [],
        "includes": [],
        "enabled": true
      },
      "dynamic": true,
      "dynamic_templates": [
        {
          "span_tags_map": {
            "path_match": "tag.*",
            "mapping": {
              "ignore_above": 256,
              "type": "keyword"
            }
          }
        },
        {
          "process_tags_map": {
            "path_match": "process.tag.*",
            "mapping": {
              "ignore_above": 256,
              "type": "keyword"
            }
          }
        }
      ],
      "date_detection": true,
      "properties": {
        "operationName": {
          "type": "keyword"
        },
        "serviceName": {
          "type": "keyword"
        }
      }
    }
  },
  "index_patterns": [
    "*jaeger-service-*"
  ],
  "composed_of": []
}

PUT _index_template/jaeger-span
{
  "priority": 2,
  "template": {
    "settings": {
      "index": {
        "mapping": {
          "nested_fields": {
            "limit": "50"
          }
        },
        "requests": {
          "cache": {
            "enable": "true"
          }
        },
        "number_of_shards": "6",
        "number_of_replicas": "1"
      }
    },
    "mappings": {
      "_routing": {
        "required": false
      },
      "_size": {
        "enabled": false
      },
      "numeric_detection": false,
      "dynamic_date_formats": [
        "strict_date_optional_time",
        "yyyy/MM/dd HH:mm:ss Z||yyyy/MM/dd Z"
      ],
      "dynamic": true,
      "_source": {
        "excludes": [],
        "includes": [],
        "enabled": true
      },
      "dynamic_templates": [
        {
          "span_tags_map": {
            "path_match": "tag.*",
            "mapping": {
              "ignore_above": 256,
              "type": "keyword"
            }
          }
        },
        {
          "process_tags_map": {
            "path_match": "process.tag.*",
            "mapping": {
              "ignore_above": 256,
              "type": "keyword"
            }
          }
        }
      ],
      "date_detection": true,
      "properties": {
        "traceID": {
          "type": "keyword"
        },
        "process": {
          "type": "object",
          "properties": {
            "tag": {
              "type": "object"
            },
            "serviceName": {
              "type": "keyword"
            },
            "tags": {
              "type": "nested",
              "properties": {
                "tagType": {
                  "type": "keyword"
                },
                "value": {
                  "type": "keyword"
                },
                "key": {
                  "type": "keyword"
                }
              }
            }
          }
        },
        "references": {
          "type": "nested",
          "properties": {
            "spanID": {
              "type": "keyword"
            },
            "traceID": {
              "type": "keyword"
            },
            "refType": {
              "type": "keyword"
            }
          }
        },
        "startTimeMillis": {
          "type": "date"
        },
        "flags": {
          "type": "integer"
        },
        "operationName": {
          "type": "keyword"
        },
        "parentSpanID": {
          "type": "keyword"
        },
        "tags": {
          "type": "nested",
          "properties": {
            "tagType": {
              "type": "keyword"
            },
            "value": {
              "type": "keyword"
            },
            "key": {
              "type": "keyword"
            }
          }
        },
        "duration": {
          "type": "long"
        },
        "spanID": {
          "type": "keyword"
        },
        "startTime": {
          "type": "long"
        },
        "tag": {
          "type": "object",
          "properties": {}
        },
        "logs": {
          "type": "nested",
          "properties": {
            "fields": {
              "type": "nested",
              "properties": {
                "tagType": {
                  "type": "keyword"
                },
                "value": {
                  "type": "keyword"
                },
                "key": {
                  "type": "keyword"
                }
              }
            },
            "timestamp": {
              "type": "long"
            }
          }
        }
      }
    }
  },
  "index_patterns": [
    "*jaeger-span-*"
  ],
  "composed_of": []
}

Executing an error on elasticsearch 8.6.0, can you give a correct elasticsearch 8.6.0 PUT command, thank you
The error message is as follows:
{
  "error": {
    "root_cause": [
      {
        "type": "illegal_argument_exception",
        "reason": "composable template [jaeger-service] template after composition is invalid"
      }
    ],
    "type": "illegal_argument_exception",
    "reason": "composable template [jaeger-service] template after composition is invalid",
    "caused_by": {
      "type": "illegal_argument_exception",
      "reason": "invalid composite mappings for [jaeger-service]",
      "caused_by": {
        "type": "mapper_parsing_exception",
        "reason": "Failed to parse mapping: Root mapping definition has unsupported parameters:  [_size : {enabled=false}]",
        "caused_by": {
          "type": "mapper_parsing_exception",
          "reason": "Root mapping definition has unsupported parameters:  [_size : {enabled=false}]"
        }
      }
    }
  },
  "status": 400
}

@sergiomcalzada
Executing an error on elasticsearch 8.6.0, can you give a correct elasticsearch 8.6.0 PUT command, thank you
The error message is as follows:
{
  "error": {
    "root_cause": [
      {
        "type": "illegal_argument_exception",
        "reason": "composable template [jaeger-service] template after composition is invalid"
      }
    ],
    "type": "illegal_argument_exception",
    "reason": "composable template [jaeger-service] template after composition is invalid",
    "caused_by": {
      "type": "illegal_argument_exception",
      "reason": "invalid composite mappings for [jaeger-service]",
      "caused_by": {
        "type": "mapper_parsing_exception",
        "reason": "Failed to parse mapping: Root mapping definition has unsupported parameters:  [_size : {enabled=false}]",
        "caused_by": {
          "type": "mapper_parsing_exception",
          "reason": "Root mapping definition has unsupported parameters:  [_size : {enabled=false}]"
        }
      }
    }
  },
  "status": 400
}

Facing issues after upgrading to ES8. Jaeger Collector startup errors can be fixed with workaround by adding --es.version=7 and --es.create-index-templates=false command parameters. But then Jaeger Query is erroring with Error 400 (Bad Request): all shards failed [type=search_phase_execution_exception]. Thanks to sergiomcalzada, the suggested manual index template creation is helping to restore Jaeger Query functionality. I am applying suggested templates using Kibana->Dev Tools->Console.

Is there any workaround currently available, e.g., creating the index manually?
I tried the OP's suggested workaround (with elastic 8.1.3) and I get the following error:
legacy template [jaeger-span] has index patterns [*jaeger-span-*] matching patterns from existing composable templates [.deprecation-indexing-template,.ml-anomalies-,.ml-state,.ml-stats,.monitoring-beats-mb,.monitoring-ent-search-mb,.monitoring-es-mb,.monitoring-kibana-mb,.monitoring-logstash-mb,.slm-history,.watch-history-16,ilm-history,logs,metrics,synthetics] with patterns (.deprecation-indexing-template => [.logs-deprecation.*],.ml-anomalies- => [.ml-anomalies-*],.ml-state => [.ml-state*],.ml-stats => [.ml-stats-*],.monitoring-beats-mb => [.monitoring-beats-8-*],.monitoring-ent-search-mb => [.monitoring-ent-search-8-*],.monitoring-es-mb => [.monitoring-es-8-*],.monitoring-kibana-mb => [.monitoring-kibana-8-*],.monitoring-logstash-mb => [.monitoring-logstash-8-*],.slm-history => [.slm-history-5*],.watch-history-16 => [.watcher-history-16*],ilm-history => [ilm-history-5*],logs => [logs-*-*],metrics => [metrics-*-*],synthetics => [synthetics-*-*]), use composable templates (/_index_template) instead

Have you solved it? How did you solve it?

Is there any workaround currently available, e.g., creating the index manually?
I tried the OP's suggested workaround (with elastic 8.1.3) and I get the following error:
legacy template [jaeger-span] has index patterns [*jaeger-span-*] matching patterns from existing composable templates [.deprecation-indexing-template,.ml-anomalies-,.ml-state,.ml-stats,.monitoring-beats-mb,.monitoring-ent-search-mb,.monitoring-es-mb,.monitoring-kibana-mb,.monitoring-logstash-mb,.slm-history,.watch-history-16,ilm-history,logs,metrics,synthetics] with patterns (.deprecation-indexing-template => [.logs-deprecation.*],.ml-anomalies- => [.ml-anomalies-*],.ml-state => [.ml-state*],.ml-stats => [.ml-stats-*],.monitoring-beats-mb => [.monitoring-beats-8-*],.monitoring-ent-search-mb => [.monitoring-ent-search-8-*],.monitoring-es-mb => [.monitoring-es-8-*],.monitoring-kibana-mb => [.monitoring-kibana-8-*],.monitoring-logstash-mb => [.monitoring-logstash-8-*],.slm-history => [.slm-history-5*],.watch-history-16 => [.watcher-history-16*],ilm-history => [ilm-history-5*],logs => [logs-*-*],metrics => [metrics-*-*],synthetics => [synthetics-*-*]), use composable templates (/_index_template) instead

I have the same problem with you

I think this index-template creation could be implemented in the initContainers of the collector deployment. I've created the MR https://github.com/jaegertracing/helm-charts/issues/452.  If you are using the jaeger operator helm chart, you may get adavantage from this.

the OP's suggested workaround (with elastic 8.1.3) and I get the following error:

how you resolve this problem

for the most part our system is working, however the init phase of rollover still returns:
Error: failed to create template: jaeger-span, request failed, status code: 400, body: {"error":{"root_cause":[{"type":"parse_exception","reason":"unknown key [template] in the template "}],"type":"parse_exception","reason":"unknown key [template] in the template "},"status":400}
the actual rollover returns:
Error: failed to create rollover target: jaeger-span-write, request failed, status code: 404, body: {"error":{"root_cause":[{"type":"index_not_found_exception","reason":"no such index [jaeger-span-write]","resource.type":"index_or_alias","resource.id":"jaeger-span-write","index_uuid":"_na_","index":"jaeger-span-write"}],"type":"index_not_found_exception","reason":"no such index [jaeger-span-write]","resource.type":"index_or_alias","resource.id":"jaeger-span-write","index_uuid":"_na_","index":"jaeger-span-write"},"status":404}
is there a known workaround for this?
Also, is there a timeline on when actual support will be ready for elasticsearch 8?
thank you.

@sergiomcalzada, on 8.7 I had to delete from both templates, should I replace it with something else?
"_size": {
"enabled": false
},

Opensearch is a good alternative. Not sure there is interest in building support for 8.x+. There are also other backends which are efficient as options.

Unfortunately, none of the others have operators as robust as ECK.
E.g. Sure OpenSearch has a helm chart, but it's missing a ton of functionality.

@jpuskar what are your requirements in terms of features/dataset size?

Hi. This topic is still relevant. Is there any plan to support Elasticsearch 8?

@henrygas2018 or you can just don't set prefix and everything will be work (if you created ILM policy before jaeger start)
storage:
  type: elasticsearch
  elasticsearch:
    scheme: http
    host: elastic-logs
    port: 9200
    user: elastic
    usePassword: false
    password: changeme
    # indexPrefix: jaeger
    ## Use existing secret (ignores previous password)
    # existingSecret:
    # existingSecretKey:
    nodesWanOnly: false
    extraEnv: []
    cmdlineParams:
      es.version: 7
      es.create-index-templates: "false"
      # es.index-prefix: jaeger

Elastic v7 has ben EOL as of 1st of August. If someone wants to use jaeger properly, they would have to install an EOL version.
Is there at least a timeline on when can we expect support for Elasticsearch 8?

@fatihdogmus This has been proposed as a project for LFX mentorship: https://github.com/jaegertracing/jaeger/issues/4600 So someone's going to start working on it in Sep.

Is there a plan to support elasticsearch data stream?

Just in case someone bumps into this:
With just ES_VERSION=7 (or --es.version=7 one might get the following cryptic error message:
"Failed to init storage factory","error":"failed to create primary Elasticsearch client: health check timeout: no Elasticsearch node available"

Adding a ES_CREATE_INDEX_TEMPLATES="false" (or es.create-index-templates="false") as suggested above seems to fix the problem and seems to make jaeger accept the ES 8 backend.

Is there a way to create all the configurations in a fresh installation on
Elasticsearch 8 or the only option is to install with ES7 and then upgrade to 8 using the workarounds mentioned above?

You can apply all the workarounds in a fresh v8 (tested). You will need to create the index by your self, you can find the code for the indexes in a previous comment from me

I did this, but there are missing aliases and ILM related configurations.


eastus2 region required for AMS deployment

As part of the ASM deployment, I had some issue to deploy it into eastus. I was getting following error

After some troubleshooting, I realized that the error is related to our policy which (intentionally) denies any deployment into eastus2 region, because when I allowed eastus2 for deployment the error was gone. It seems the deployment template has some hardcoded parameter with value eastus2! See my following suspicious findings:

The deployment template contains the eastus2 in parameter "Location"

Deployed AMS resource contains in properties parameter "Service Location" values with "East US 2"

The ASM was deployed correctly to eastus alongside with all related resources

Kindly fix dependency on eastus2 to ensure all AMS resources are deployed into selected region as part of the ASM deployment.

@MightySuz  and @sameeksha91

i hava the same problem. I only want to deploy in EastUS, but some resources ends up being located in EastUS2.

Hi @mkerni  and @ezequielmqg , thanks for reporting this behavior. AMS is currently using Geo based deployment method, where AMS service is hosted in one region in a geography (EastUS2) but AMS resource can be setup in another region within that geography. We are planning to have AMS service available in all the supported regions by GA.
For now, you will need to update your azure policy to allow few resources to be created in a different region than your SAP system. Please note that these resources are only for tracking purposes and not have any bearing on performance of AMS.

Please let me know if it's ok to close this issue. Thanks

Yes, this limitation make sense for the preview phase but should be addressed when going for GA.
With temporary enabled region EastUS2 in the policy template I can deploy the AMS into the EastUS region.
I'm ok to close this issue.


make kindle-line-height into a variable

Based on the discussion here: https://github.com/FriendsOfEpub/Blitz/issues/54

After giving it some thought, I’d prefer the variable to be more global as it’s used for sup and sub for instance, and not tie it to Kindle. So probably something like min-line-height.
On a related note, it would be far better to use min-line-height in Kindle if the computed line-height is less than the variable’s value. I came across mixins as functions in the LESS docs the other day, and think I will give it a try as soon as time allows this week.
Checked package.json and the LESS dependency was updated at the same time the build was automated so I don’t consider it a breaking change. Mixins as functions indeed require v.3.5.0 – but we’re using v.3.9.0.

Status: pending as I’ll have to check some assumption before merging.

Updated to min-line-height and protected Kindle’s line-height directly in rhythm.less.
Many thanks for all the PRs!


Exported variable 'x' has or is using name 'y' from external module 'z' but cannot be named.

If you import Foo somewhere, and Foo is internally using Bar, you have to import Bar as well, which basically negates all benefits of type inference, you have to write all types everywhere (https://github.com/Microsoft/TypeScript/issues/9944).. from what I understood from that issue, you can get around this by disabling declaration in compilerOptions (which is what angular-cli does by default I think).. could this be made configurable in ng-packagr? It's currently set to true.
@dherges

Hi @fxck,
short answer: no.
--declaration-d | boolean | false | Generates corresponding .d.ts file.

https://www.typescriptlang.org/docs/handbook/compiler-options.html

@dherges I don't think it's a duplicate, also I'm not entirely sure what you do you mean
--declaration-d | boolean | false | Generates corresponding .d.ts file.

is it something you can pass down to ng-packagr?
Let me try to explain the problem once more, in my lib I import
import { createFeatureSelector } from '@ngrx/store';

as createFeatureSelector is the only thing I need, but internally, createFeatureSelector uses MemoizedSelector, so I get an error

packages/dialog/src/dialog.selector.ts(6,14): error TS4023: Exported variable 'getDialogSlice' has or is using name 'MemoizedSelector' from external module "/Users/fxck/www/vshlibs/node_modules/@ngrx/store/src/selector" but cannot be named.

which can be fixed by
import { createFeatureSelector, MemoizedSelector } from '@ngrx/store';

but I DO NOT actually use MemoizedSelector..

@fxck ... but it is not specific for ng-packagr. The same effects happens just in pure Angular app ... when compiling to AOT mode. Form exapmple with Observable from rxjs, .... and others.

Could be, that's why I linked to that typescript issue https://github.com/Microsoft/TypeScript/issues/9944
But it doesn't doesn't happen when you try to use createSelector in a standard app, aot or not.

This one is related https://github.com/dherges/ng-packagr/issues/542


Fix resolving yanked crates when using a local registry.

Fixes #6741.

r? @alexcrichton
(rust_highfive has picked a reviewer for you, use r? to override)

Test failure in nightly reported on #6258.

Restarted the Travis job that failed.

@bors: r+

:pushpin: Commit 915b49d9690f4a4fc28524103983b38464e5bcc7 has been approved by alexcrichton

:hourglass: Testing commit 915b49d9690f4a4fc28524103983b38464e5bcc7 with merge 8ebf915a54134d02c8bc0ace8609545b450f54eb...

:sunny: Test successful - checks-travis, status-appveyor
Approved by: alexcrichton
Pushing 8ebf915a54134d02c8bc0ace8609545b450f54eb to master...

Can we backport this into beta? Getting a 1.33.1 is probably a long shot.
We'll need to skip 1.33.0 internally, as having commits that cannot be successfully build anymore due to an update to the local registry is unacceptable.

The thing it is fixing got a backport #6655 so I am +1 on a backport.


Upgrade required API version (>=0.12.0,<0.13.0)

Codecov Report

:exclamation: No coverage uploaded for pull request base (main@de30ae6). Click here to learn what that means.
Patch has no changes to coverable lines.

Additional details and impacted files
@@           Coverage Diff           @@
##             main      #42   +/-   ##
=======================================
  Coverage        ?   99.62%
=======================================
  Files           ?       22
  Lines           ?      527
  Branches        ?       40
=======================================
  Hits            ?      525
  Misses          ?        0
  Partials        ?        2

Impacted Files
Coverage Δ

bemserver_api_client/client.py
100.00% <ø> (ø)

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

:umbrella: View full report at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.


Add stale bot

What kind of change does this PR introduce?

Add stale bot to mark issues and PRs as Stale after a long period of inactivity.
Currently, it does NOT close issues automatically, but it can do so if wanted.
Same yaml as https://github.com/supabase-community/supabase-py/pull/774

Additional context

https://github.com/actions/stale

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

Project coverage is 85.21%. Comparing base (a809e98) to head (ce4c7cf).
Report is 24 commits behind head on main.

Additional details and impacted files
@@           Coverage Diff           @@
##             main      #92   +/-   ##
=======================================
  Coverage   85.21%   85.21%
=======================================
  Files           7        7
  Lines         115      115
=======================================
  Hits           98       98
  Misses         17       17

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


add empty ResourceSupport object to SubmissionDefinitionResource.

to address issue DS-3916.  This is sort of a hack, but it seems to work.  A better solution if this approach is feasible would be to add a method in HALResource.java with a signature like so:
public void embedResource(String relationship, ResourceSupport resource) {
embedded.put(relationship, resource);
}
in addition to what is there.

Thanks Andrea, I will take a look!
-- Bill
On Thu, Aug 16, 2018 at 8:57 AM, Andrea Bollini<EMAIL_ADDRESS>wrote:

@abollini requested changes on this pull request.
I will prefer a solution that modify the org.dspace.app.rest.
RestResourceController.findRelInternal(HttpServletRequest,
HttpServletResponse, String, String, ID, String, Pageable,
PagedResourcesAssembler, String)
to solve the issue for all the searchMethods
This should be similar to what is done here
in the case that the list is an explicit attribute of the REST model class
https://github.com/DSpace/DSpace/blob/master/dspace-
spring-rest/src/main/java/org/dspace/app/rest/RestResourceController.java#
L738
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/DSpace/DSpace/pull/2127#pullrequestreview-146854666,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AJqhOVuThdiDtZJ9FecP06rfn74LT7Z5ks5uRXo4gaJpZM4VYcH2
.

--
Human wheels spin round and round
While the clock keeps the pace... -- John Mellencamp

Bill Tantzen    University of Minnesota Libraries
612-626-9949 (U of M)<PHONE_NUMBER> (cell)

Andrea,
I will start a new branch with a new PR.
But I'm sorry -- I am not sure where to go with this.  Are you suggesting
that in findRelInternal() that I should return an empty list along with
STATUS_OK instead of null?  Or just in the case of this particular endpoint?
Your suggestions will be appreciated!
-- Bill
On Thu, Aug 16, 2018 at 9:27 AM, Bill Tantzen<EMAIL_ADDRESS>wrote:

Thanks Andrea, I will take a look!
-- Bill
On Thu, Aug 16, 2018 at 8:57 AM, Andrea Bollini<EMAIL_ADDRESS>wrote:

@abollini requested changes on this pull request.
I will prefer a solution that modify the org.dspace.app.rest.RestResour
ceController.findRelInternal(HttpServletRequest, HttpServletResponse,
String, String, ID, String, Pageable, PagedResourcesAssembler, String)
to solve the issue for all the searchMethods
This should be similar to what is done here
in the case that the list is an explicit attribute of the REST model class
https://github.com/DSpace/DSpace/blob/master/dspace-spring-
rest/src/main/java/org/dspace/app/rest/RestResourceController.java#L738
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/DSpace/DSpace/pull/2127#pullrequestreview-146854666,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AJqhOVuThdiDtZJ9FecP06rfn74LT7Z5ks5uRXo4gaJpZM4VYcH2
.

--
Human wheels spin round and round
While the clock keeps the pace... -- John Mellencamp

Bill Tantzen    University of Minnesota Libraries
612-626-9949 (U of M)<PHONE_NUMBER> (cell)

--
Human wheels spin round and round
While the clock keeps the pace... -- John Mellencamp

Bill Tantzen    University of Minnesota Libraries
612-626-9949 (U of M)<PHONE_NUMBER> (cell)


Update Unit 6 for Gymnasium

In this new version:

We removed Pybullet (obsolete) and focus instead of panda gym

The docs for this PR live here. All of your documentation changes will be reflected on that endpoint.


Where is the “sydr.zip”

Hello,
I am very excited to sydr project, but i don`t find the sydr.zip from /projects/project/README.

@apach301

Hi! Sydr is a commercial product with no source code available. This repository only contains data to build fuzzing targets for various open source projects.

thanks your reply, how can i purchase it?

Sales and trial versions are only possible for companies and institutes. To request a product or for additional info use mail<EMAIL_ADDRESS>

Thanks！


Increase emoji size in the comment reaction selection box

Description
It's pretty difficult to tell the difference between the two face emojis when selecting an emoji response because they're so small.
This changes the g-emoji class font-size from 1em to 1.6em. Perhaps the spacing could be increased too if click-ability was diminished. The whole popup could be a bit bigger
Screenshot

Example URL
https://github.com/refined-github/refined-github/issues/5085#issue-1057916229

Not a terrible idea honestly: they are kinda small, the change is CSS only, the hit area is already that big, the container doesn't change.
.js-pick-reaction .emoji {
	font-size: 1.6em;
}

They do need to be better aligned vertically though.

It's pretty difficult to tell the difference between the two face emojis when selecting an emoji response because they're so small.

They are not close to each other, so it's easy to remember their location. Also the similarity between them depends on your emoji font.

This changes the g-emoji class font-size from 1em to 1.6em. Perhaps the spacing could be increased too if click-ability was diminished. The whole popup could be a bit bigger

Isn't GitHub already enlarging the emoji when hovering?

Also the emoji size in your screenshot is smaller than it should be, see @fregante's screenshot for reference.

I'm on MacOS, maybe @fegante isn't and the macos emoji font is smaller? I could file that as a github UI bug if so

No, me and @fregante are both on macOS and have normal emoji size. You can try clearing the browser cache and see if it is fixed.

Yeah, ok that solved it. It appears I had github zoomed out without noticing. Apologies for the noise


promoter opening

promoter opening during RNA Polymerase II
transcription - mediated by XPB (TFIIH subunit) helicase
Reported by: geetatope
Original Ticket: "geneontology/ontology-requests/1497":https://sourceforge.net/p/geneontology/ontology-requests/1497

thanks www.movied.org


fixed h5 atribute RuntimeError (names, types, paths)

added module image_sample.py

added module img_tools into utils
pending:

comments new module img_tools.
pytest functions
documentation (specs, tutorial)


feat: task list page framework (FPLA-1223)

Before creating a pull request make sure that:

[x] commit messages are meaningful and follow good commit message guidelines
[x] README and other documentation has been updated / added (if needed)
[x] tests have been updated / new tests has been added (if needed)

JIRA link
https://tools.hmcts.net/jira/browse/FPLA-1223
Change description
Removes gulp in favour of Webpack
Adds task list page and dependancies
Added new route '/task-list'
Does this PR introduce a breaking change? (check one with "x")
[ ] Yes
[x] No

@Jamesnelson117 is it general practice that barrel files are named index.? because if you see modules - 18n index or nunjucks index or any module also has index. for different purpose.

Not sure why your PR is not showing that it is out of date with master. @tomaszpowroznik released appInsights code last night.


circle CI: switch fedora latest to fedora 28

Some change in F29 breaks the CI runs, so lets switch back to what we had
before so we can merge patches.
Signed-off-by: Peter Hutterer<EMAIL_ADDRESS>

used my superpowers to merge this, so we can have test runs succeed in the other PRs


AVRO-3408: Schema evolution with logical types

Hello! Please take a look a PR for the issue https://issues.apache.org/jira/browse/AVRO-3408
I hope I fulfilled all PR requirements but feel free to point me out if I missed something.
Thank you in advance. I would love the read what does the community think about it.

@opwvhk what is the rule for PR updates? Shall I amend my original commit and force push to a branch to keep the number of commits in the PR = 1 or can I create another commit with a fix and we will squash all together during a merge?

To update your PR, simply push a new commit to the branch. This will update the PR.

hi! Are there any other concerns for this PR?

hi! Are there any other concerns for this PR?

Only one: convertible from a CharSequence doesn't yet take the scale into account. It should, because otherwise reading data can result in a BigDecimal with an unexpected scale. Simply setting the scale with RoundingMode.UNNECESSARY is sufficient; evolution to a larger  will then still work,  but evolution to a smaller scale will only succeed if the value allows it (as it should).

We are two different people :D
Again, thanks for your attention on this, there's some discussion on the JIRA about "the right thing to do".  I definitely think you have a valid use case and that it should be simple for users of the Java SDK to migrate away from the pre-LogicalType java-class and @Stringable annotations!
I'm not entirely sure: maybe interpreting an underlying STRING as character digits for a decimal LogicalType is the right thing to do!  It feels like something we should discourage, but if it would fix this migration issue it's hard to argue against it!

Cool, I'm glad to see this PR is not stalled and more people are involved. :+1:
Could anyone answer my previous question about ResolvingDecoder#resolve?
I think we face here 2 problems:

the first is BigDecimal by default is decoded as a string, but the decimal logical type does not support string conversion, thus we have inconsistency.
the second is some kind of new way how to make schema migration if you just need to change the encoding type. With my changes, you can introduce a new logical type for a field that would support an old format and a new format. At the method ResolvingDecoder#resolve I told above, we can check if the type conversion is valid or not, or we can do the same during the ResolvingAction. I think it's a sort of debate like runtime vs compile-time resolution. That's why I'd like to hear community comments on this.

Close/re-open to trigger the GHA checks.

hi! does anyone knows why did the build fail? It used to be green...
And good news everyone, I tested this patch on our production, it works and we successfully migrated from one version to another one with it. And it works for several month on our prod (even at this moment)
So, from bug point of view, it's kinda safe to merge.

Close/reopen to check!  :roll_eyes: I'm not sure why the "rerun jobs" button disappeared!
Note that the 1.11.1 RC is out, after that release, we should be WAY more reactive to attack all of these contributions!

Any news? Is this PR still alive?

Hi @mrk-andreev  !
Thank you for poking this PR, yes the pr is okay, and per my understanding it's waiting for a small spec change.
It's still unclear to me though how this process look like. Where is the spec source text and who is the person(s) who can push the button.
if someone can explain, I'm ready to make a change and communicate with the folks.

Hey, @RyanSkraba ! I hope you're having wonderful holidays

I'm marking this as Request changes to make sure it doesn't get merged before consensus on the mailing list. Spec changes affect all the SDKs.

could you elaborate how to make changes to the spec? Shall I write a letter or communicate to someone?
Thank you.
Marry Christmas and happy New Year!

Hello?
Don't want to whine out but it feels like you turn a blind eye to this issue....
if someone could help me with my questions above it would be marvelous!

The specification sources can be found at https://github.com/apache/avro/blob/master/doc/content/en/docs/%2B%2Bversion%2B%2B/Specification/_index.md


DBInstance does not retry Create for invalid spec values

Describe the bug
If a password is not specified when first creating an RDS DBInstance CR, the Create* call fails and sets the CR into a terminal condition. If you update the password field after this, the call is not re-attempted and the instance is forever stuck in a terminal state.
Steps to reproduce

Create a DBInstance with an invalid masterUserPassword value
Watch for the DBInstance to become terminal
Update the masterUserPassword value to be valid
See that the DBInstance never changes

Expected outcome
The DBInstance should be created with the new masterUserPassword if the initial Create failed.
Environment

Kubernetes version
Using EKS (yes/no), if so version?
AWS service targeted (S3, RDS, etc.) RDS

From our Slack conversation regarding this issue:

When we generate the RDS controller, we set which error responses should be classified as terminal. I can see that InvalidParameterValue is one of those. It might be worth it for us to remove that one from the list, since that blocks your use case.

/lifecycle frozen

@Samze I see that in our logic for retrieving fields from Secret, we will throw an error if the Secret is not found - https://github.com/aws-controllers-k8s/runtime/blob/main/pkg/runtime/reconciler.go#L121 . This should cause the reconciler to requeue (without any backoff) until it succeeds. Is this the scenario you've been facing? Or have you been supplying an empty or invalid value inside the Secret, which is what's being used to create the instance?

@RedbackThomson thanks for your response. Interesting, I'm not seeing any requeue and I see DBInstance get a " terminal condition" condition, which I assume means it won't retry. I'm using 0.0.24 of the RDS Operator.
This is what I'm doing:

Create DBInstance with reference to non-existing secret.
Check status, it shows.

  conditions:
  - message: kubernetes secret not found
    status: "True"
    type: ACK.Terminal
  - lastTransitionTime: "2022-06-03T18:25:10Z"
    message: Resource synced successfully
    reason: resource is in terminal condition
    status: "True"
    type: ACK.ResourceSynced

Apply secret
Wait for changes. Nothing changes

Also didn't mean to hijack this thread, happy to make another issue if needed.

Oh yeah this should not be a terminal condition. We definitely want to retry when we see that. If you could please put this into a separate issue, this is no longer just an RDS bug - it's a bug with the general way we handle secrets (and errors). I see the problem in the code, though!

Thanks, created https://github.com/aws-controllers-k8s/community/issues/1318

issue-1318 is closed, we can close this one too.
https://github.com/aws-controllers-k8s/community/issues/1318

/close

/close


GitHub Actions run of pytest has problems

Errors are reported, but the Action still succeeds
The --log-cli-level=INFO is not being output to the log
Add in bioformats2raw library

It appears that the pytest debug output is now being displayed.
Need to add install of bioformats2raw to the build.

Added the bioformats2raw install in main.yml which also requires java to run.
Still need to mark the build as failed when the tests fail, but will wait for Prefect2 as that should make failure detection much easier.


Add conversions for tosa.maximum and tosa.minimum

LGTM +1 Out of curiosity: do we have/does TOSA have non-binary max/min ops?

There is tosa.argmax, which returns the index of the maximum value.


VSCode 1.12.1 standard c# snippets quit working after update

VSCode Version: Code 1.12.1 (f6868fce3eeb16663840eb82123369dec6077a9b, 2017-05-04T21:18:32.269Z)
OS Version: Darwin x64 16.5.0
Extensions:

Extension
Author
Version

vscode-clock
Compulim
0.0.1

EditorConfig
EditorConfig
0.9.3

beautify
HookyQR
1.0.2

markdown-checkbox
PKief
1.0.2

vscode-docker
PeterJausovec
0.0.14

html-snippets
abusaidm
0.1.0

git-easy
bibhasdn
1.9.1

githistory
donjayamanne
0.2.0

python
donjayamanne
0.6.4

tslint
eg2
0.15.0

vscode-npm-script
eg2
0.1.9

rest-client
humao
0.14.3

csharpextensions
jchannon
1.3.0

Angular2
johnpapa
2.2.3

Go
lukehoban
0.6.61

markdown-shortcuts
mdickin
0.8.1

vscode-todo-parser
minhthai
1.8.10

mssql
ms-mssql
1.0.0

csharp
ms-vscode
1.9.0

debugger-for-chrome
msjsdiag
3.1.1

vscode-icons
robertohuertasm
7.7.0

yo
samverschueren
0.9.3

JavaScriptSnippets
xabikos
1.4.0

Steps to Reproduce:

Open .cs file containing a C# class
Notice other features of the extension are functioning: Syntax Highlighting, IntelliSense, Go to Definition, Find All References, .NET Core Attach debugging, etc.
The extension is installed (see list above) in ~/.vscode/extensions/ms-vscode.csharp-1.9.0/
The snippets file exists in the snippets sub-dir as csharp.json
Common snippets like "prop", "namespace", etc. simply do not appear.
Note the "class" snippet does show up in the intellisense list but produces bad output:

    class Name
    {

    ,
    }|<== the cursor is left here after specifying the class name and hitting return

"foreach" snippet does the same thing:

            foreach (var item in collection)
            {

            ,
            }|<== the cursor is left here after specifying var, item and collection and hitting return

Command-Shift-p and "Insert Snippet" shows the snippets that will show up in context; all of the ones I tried from the list had the same formatting issues.
Here is what I see from csharp.json for the "class" snippet.

        "Class": {

                "prefix": "class",
                "body": [
                        "class ${Name}",
                        "{",
                        "       $0",
                        "}"
                ],
                "description": "Class"
        },

Given this I suspect there are some syntax errors in this file. But see below - it appears that is not the whole story.
Note I did try to re-compile the extension in hopes that the json file would be regenerated somehow. But after npm i and doing npm run compile I got an error about missing tsconfig.json file and then also noticed there was no source delivered with the extension. So I stopped there.
Note the csharp.json file had not changed since Oct 2016 - there were 2 commits recently:
csharp.json commmits
There are several issues opened in the OmniSharp repo - #1459 is just one. So treat this as an FYI.
However they do reference MS VSCode #26101 as part of the problem.
The OmniSharp VSCode #1464 issue was closed on May 8 by Dustin Campbell with a reference to MS #26101.
I am hoping you and the OmniSharp folks can fix this soon. It is impactful to snippets across all extensions.

I have the same issue and also all snippets after "iterindex" are missing from the snippet list. For instance the "prop" snippet for auto properties is missing in the list and vscode also doesn't recognise it when I'm typing it.
If I copy the snippets from https://github.com/OmniSharp/omnisharp-vscode/blob/master/snippets/csharp.json into my own C# snippet file, they are back in the list and also working properly.
Maybe this is a problem with the C# Extension?

Duplicate of #25938, fix will be in the recovery build we do this week.


Azure artifacts with Universal package

is there anyway to download the latest artifacts by using universal packages?

Hi @Kaali09  , I'm going to close this issue as we haven't heard from you, but we would like to! If you could help give us some insight as to what "latest" would mean to you, it will help us implement the right feature for our users :)

Hi,
we would like to see similar feature as well.
I think using wildcards would be fine, so using @mitchdenny example:
--version "1.0.*" would give me 1.0.3
--version "*" would give me 2.0.0
--version "1.*.0" would probably give me 1.0.0 then.
Latest meaning latest version (following semver)
I think behaviour similar to NuGet package rererences wildcards would be nice.
I created another ask (that should probably go into some VSTS issue tracker), that is somewhat similar here #4098.


Generate grass on the fly

The current branch 'grass' brings the new feature to generate grass for areas of the terrain where a grass texture is sprayed on.
However, this generating process is done during initialization. Furthermore, it is done for the whole scene. This takes a noticeable amount of time and memory. Especially, for bigger scenes this might not be a good idea.
To solve this problem we could implement the grass generation on the fly. While the player is walking through the game world existing grass batches are removed and new grass batches will be created.
What do you think @8Keep and @jvpichowski ?

This won't be implemented any more.


SIEVE filters: Support regex extension

Currently the SIEVE filters frontend does not support the creation of regex filters.
Both the very old Avelsieve plugin for Squirrelmail and Roundcube already support regex filters.
The current specification for the filters themselves is at https://tools.ietf.org/html/draft-ietf-sieve-regex-01
There are several Sieve implementations that support this extensions, including Cyrus Sieve and Piegeonhole for Dovecot.
Rationale:

In some cases, it is desirable to have a string matching mechanism
which is more powerful than a simple exact match, a substring match
or a glob-style wildcard match.  The regular expression matching
mechanism defined in this draft should allow users to isolate just
about any string or address in a message header or envelope.

Available in the last version.

It may be good to have some help for the user here,
for instance when "regex" is selected, some common expressions could be shown in a dropdown.
eg: "match all", "match excluding"


Curator name must be added for Single-cell multi-omics analysis of the immune response in COVID-19

See curator experience for background.
"Batuhan Cakir" must be added as the curator name for Single-cell multi-omics analysis.

Addressed in Curator names must be added to data_submission_policy_version 1.0 collections.


Increase width of side score overlayi

This fixes the issue where the scores overrun the boxes on the "side overlay"

I guess I was hoping for something which made us a bit more agnostic of the name length, though perhaps that needs too big a change for now?
This seems good as a quick fix though.

I guess I was hoping for something which made us a bit more agnostic of the name length, though perhaps that needs too big a change for now?

I agree. However, if we are replacing this codebase, I see little point in sinking lots of time into it. Probably going to be using SFCs for the replacement, so fixing up the slightly messy SCSS we have here doesn't hold a lot of value.


Updated README license chapter

Adding chapter License to README.md in a consistent format with other hyperledger-labs projects.

@defidbpub Thanks for adding this! Looks good, except the commit needs sign-off to make the DCO bot happy. Details on how to do that are here: https://github.com/hyperledger-labs/firefly-fabconnect/pull/8/checks?check_run_id=3078469259