Why is it defined

Bug Description

Reproduction
How to write your own methods to handle data in custom components???????    I want to turn 'YYYY-MM-DD' 'HH:MM:SS' into a timestamp
Expected behavior
How to write your own methods to handle data in custom components???????    I want to turn 'YYYY-MM-DD' 'HH:MM:SS' into a timestamp
Who can help?
No response
Operating System
windows
Langflow Version
1.0.15
Python Version
3.11
Screenshot
No response
Flow File
No response

@alex-ge123 Did you try to build the backend again? With make install_backend.

no

@alex-ge123 Did you try to build the backend again? With make install_backend.

no

@alex-ge123 Did you try to build the backend again? With make install_backend.

no

Does it works now?

from langflow.field_typing import Data
from langflow.custom import Component
from langflow.io import MessageTextInput, Output
from langflow.schema import Data
from datetime import datetime
import pytz
class TimestampComponent(Component):
display_name = "Timestamp Converter"
description = "Converts 'YYYY-MM-DD HH:MM:SS' format to a timestamp."
documentation: str = "http://docs.langflow.org/components/custom"
icon = "custom_components"
name = "CustomComponent"
inputs = [
    MessageTextInput(name="input_value", display_name="Datetime String", value="Hello, World!",info="Datetime in 'YYYY-MM-DD HH:MM:SS' format."),
]

outputs = [
    Output(display_name="Output", name="output", method="build_output"),
]

def build_output(self) -> Data:
    # 转换为datetime对象
    datetime_obj = datetime.strptime(self.input_value, '%Y-%m-%d %H:%M:%S')

    # 设置时区
    tz = pytz.timezone('Asia/Shanghai')
    datetime_obj = tz.localize(datetime_obj)

    # 转换为时间戳，单位为毫秒
    timestamp = int(datetime_obj.timestamp() * 1000)

    data = Data(value=timestamp)
    self.status = data
    return data

    yes    it works now

@alex-ge123 Did you try to build the backend again? With make install_backend.

no

Does it works now?

from langflow.field_typing import Data
from langflow.custom import Component from langflow.io import MessageTextInput, Output from langflow.schema import Data from datetime import datetime import pytz
class TimestampComponent(Component): display_name = "Timestamp Converter" description = "Converts 'YYYY-MM-DD HH:MM:SS' format to a timestamp." documentation: str = "http://docs.langflow.org/components/custom" icon = "custom_components" name = "CustomComponent"
inputs = [
    MessageTextInput(name="input_value", display_name="Datetime String", value="Hello, World!",info="Datetime in 'YYYY-MM-DD HH:MM:SS' format."),
]

outputs = [
    Output(display_name="Output", name="output", method="build_output"),
]

def build_output(self) -> Data:
    # 转换为datetime对象
    datetime_obj = datetime.strptime(self.input_value, '%Y-%m-%d %H:%M:%S')

    # 设置时区
    tz = pytz.timezone('Asia/Shanghai')
    datetime_obj = tz.localize(datetime_obj)

    # 转换为时间戳，单位为毫秒
    timestamp = int(datetime_obj.timestamp() * 1000)

    data = Data(value=timestamp)
    self.status = data
    return data

    yes    it works now

Then please, close your issue.

@alex-ge123 Did you try to build the backend again? With make install_backend.

no

Does it works now?

from langflow.field_typing import Data
from langflow.custom import Component from langflow.io import MessageTextInput, Output from langflow.schema import Data from datetime import datetime import pytz
class TimestampComponent(Component): display_name = "Timestamp Converter" description = "Converts 'YYYY-MM-DD HH:MM:SS' format to a timestamp." documentation: str = "http://docs.langflow.org/components/custom" icon = "custom_components" name = "CustomComponent"
inputs = [
    MessageTextInput(name="input_value", display_name="Datetime String", value="Hello, World!",info="Datetime in 'YYYY-MM-DD HH:MM:SS' format."),
]

outputs = [
    Output(display_name="Output", name="output", method="build_output"),
]

def build_output(self) -> Data:
    # 转换为datetime对象
    datetime_obj = datetime.strptime(self.input_value, '%Y-%m-%d %H:%M:%S')

    # 设置时区
    tz = pytz.timezone('Asia/Shanghai')
    datetime_obj = tz.localize(datetime_obj)

    # 转换为时间戳，单位为毫秒
    timestamp = int(datetime_obj.timestamp() * 1000)

    data = Data(value=timestamp)
    self.status = data
    return data

    yes    it works now

Then please, close your issue.

Of course you can, but I still have a place that I do not understand, custom components, why can not write a method alone, and then call your own method in other methods? Undefined methods always appear

@alex-ge123
Do you need any assistance with this case? If not, please let us know if this issue can be closed.

Thank you for your contribution! This issue will be closed. If you have any questions or encounter another problem, please open a new issue and we will be ready to assist you.


add flag so the landing page can be disabled

Provide ability to disable the landing page.
Following will disable the landing page.
landing:
enable: false
The following will enable the landing page
landing:
or
landing:
enable: true

Fixes #177


Fixed handling unnamed/undeclared returned type from functions

Fixes
This changes almost fix #27 for now (currently I have no idea how to handle specified unnamed returned typed so I've asked for help in TypeScript discord https://discord.com/channels/508357248330760243/640177429775777792/927239241459724298).

The response: https://discord.com/channels/508357248330760243/640177429775777792/933032112909586452

Based on the answer, it seems that to check this we need to compare unnamed object's type with every publicly accessible type, which might and will break the code because it is quite possible that 2 types might be assigned to each other and they will be unrelated.
Probably it worth to leave it as is right now and say that this is expected behaviour that we don't handle it and you need to specify types explicitly everywhere if needed.


The implementation of layerwise learning rate decay

https://github.com/google-research/electra/blob/79111328070e491b287c307906701ebc61091eb2/model/optimization.py#L188-L193
According to the code here, assume that n_layers=24, then key_to_depths["encoder/layer_23/"] = 24 which is the depth for last encoder layer, but the learning rate for last layer is:
learning_rate * (layer_decay ** (24+ 2 - 24)) = learning_rate * (layer_decay ** (2)).
That's what confused me. Why the learning rate for last layer is learning_rate * (layer_decay ** (2)) rather than learning_rate? Do I ignore anything?

For the layerwise learning rate decay we count task-specific layer added on top of the pre-trained transformer as additional layer of the model, so the learning rate for the last layer of ELECTRA should be learning_rate * 0.8. But you've still found a bug, where instead it is learning_rate * 0.8^2.
The bug happened because there used to be a pooler layer in ELECTRA before we removed the next-sentence-prediction task. In that case the learning rates per layer were

task-specific softmax: learning_rate
pooler: learning_rate * 0.8
transformer layer 24: learning_rate * 0.8^2
transformer layer 23: learning_rate * 0.8^3
...
However, when we removed the pooling layer, we didn't fix the learning rates correspondingly. I guess in practice this didn't hurt performance much, so I'm leaving it as-is to keep result reproducible for now.

I got it, thanks for your explanation.


[apimanagement] Update inquirer for @azure/api-management-custom-widgets-scaffolder

Packages impacted by this PR

@azure/api-management-custom-widgets-scaffolder

Issues associated with this PR

https://github.com/Azure/azure-sdk-for-js/issues/22972

Describe the problem that is addressed by this PR
Updates inquirer which uses ESM only, so this moves to ESM, but also allows for CJS.
What are the possible designs available to address the problem? If there are more than one possible design, why was the one in this PR chosen?
Are there test cases added in this PR? (If not, why?)
Provide a list of related PRs (if any)
Command used to generate this PR:**(Applicable only to SDK release request PRs)
Checklists

[x] Added impacted package name to the issue description
[ ] Does this PR needs any fixes in the SDK Generator?** (If so, create an Issue in the Autorest/typescript repository and link it here)
[ ] Added a changelog (if necessary)

API change check
API changes are not detected in this pull request.


configmap of sidecar injector template for istiod is wrongly mounted

Bug description
When revision is set, the configmap mounted to the deployment istiod-<revision> is istio-sidecar-injector, but in fact it should be istio-sidecar-injector-<revision>.
Affected product area (please put an X in all that apply)
[ ] Configuration Infrastructure
[ ] Docs
[X] Installation
[ ] Networking
[ ] Performance and Scalability
[ ] Policies and Telemetry
[ ] Security
[ ] Test and Release
[ ] User Experience
[ ] Developer Infrastructure
Affected features (please put an X in all that apply)
[ ] Multi Cluster
[ ] Virtual Machine
[ ] Multi Control Plane
Expected behavior
The configmap mounted to the deployment istiod-<revision> should be istio-sidecar-injector-<revision>.
Steps to reproduce the bug
Set the revision value and install istio by istioctl, operator or iop script.
Version (include the output of istioctl version --remote and kubectl version and helm version if you used Helm)
istio 1.5.2
helm 2.x
kubectl 2.13
How was Istio installed?
iop script in manifests.
Environment where bug was observed (cloud vendor, OS, etc)
centos
Additionally, please consider attaching a cluster state archive by attaching
the dump file to this issue.

fixed in #23568


feat(Data/Int/WithZero): add WithZeroMultIntToNNReal

We define  the morphism withZeroMultIntToNNReal  from ℤₘ₀ → ℝ≥0 sending 0 ↦ 0 and  x ↦ e^(Multiplicative.toAdd (WithZero.unzero hx) when x ≠ 0, for a nonzero e : ℝ≥0 and prove some of its properties.
Co-authored-by: Filippo A. E. Nuccio<EMAIL_ADDRESS>

bors r-

Can you merge master, fix the build, and then send it back to bors?
bors d+

bors r+


Firefox loses query string after a Router.replace shallow

We have a very strange edge case only happening in Firefox but its def causing some problems.
This is whats happening is I navigate to the root http://localhost:3000, get redirected on the server to /about2
I click I button which Router.replace shallow:true which replaces the url to /about2?key=value
I refresh the browser at the current state, url is /about2, I expect it to be /about2=key=value
Here a video recording of the scenario.
https://drive.google.com/file/d/1c0oN-UZIVuG5lt6oZiJOlwZSzAM98gSX/view?usp=sharing
To be a friendly guest here's the repro repo, examples/hello-world
npm install && npm run dev
https://github.com/ptomasroos/next.js/tree/firefox-loses-querystrings

[x] I have searched the issues of this repository and believe that this is not a duplicate.

Firefox 58 (latest)

To clarify, if you start the test by navigating to /about2, so there's no 302 redirect, this problem doesn't occur. It has to be 302 -> Router.replace -> refresh.
No other browser we tested has been affected. Firefox 56 (pre-quantum) showed the same broken behavior.

I can confirm this is an issue more with Firefox than with Next.js. Basically the issue is this: After a SSR redirect inside getInitialProps with the following code:
res.writeHead(302, { Location: path })
res.end()
res.finished = true

The client behaves as expected but then if you change the query params with Link or Router in Firefox or use the following code and then refresh the page (F5) it will go back to the initial url:
const url = '/about2?key=value'
window.history.replaceState({ url, options: { shallow: true } }, null, url)

I was unable to find why is this happening but here is a quick fix: after using Router.replace or doing a redirect with Link do this:
window.location.href = YOUR_URL

If this is a Firefox issue perhaps we should add this bugreport to mozilla, what do you think @lfades ?

Whoops, I forgot to mention here:
This issue is reported to Mozilla, https://bugzilla.mozilla.org/show_bug.cgi?id=1422334


Updated Microsoft.FeatureManagement to 2.3.0 for release.

Updated Microsoft.FeatureManagement to 2.3.0 for release.

Release adds .net 5 as a target.

Updated build to use separate versions for different projects.

Just to confirm - adding .NET 5 as target will not be a breaking change, correct?

Just to confirm - adding .NET 5 as target will not be a breaking change, correct?

Just to confirm - adding .NET 5 as target will not be a breaking change, correct?

The only behavior that could change as a result of adding a target for .NET 5 would be in apps running on  .NET 5. But, the fact that we aren't targeting it right now means we haven't really established support for it yet.
Another thing, we added 3.1 targeting in the update from 2.1 to 2.2

Just to confirm - adding .NET 5 as target will not be a breaking change, correct?

The only behavior that could change as a result of adding a target for .NET 5 would be in apps running on  .NET 5. But, the fact that we aren't targeting it right now means we haven't really established support for it yet.
Another thing, we added 3.1 targeting in the update from 2.1 to 2.2


Docs on handling secrets with colons

TL;DR
I'm using an GitHub secret with an API key that contains a colon.
This results in an Invalid secret spec '***:latest' error when trying to use the secret via:
          secrets: |
            API_KEY=${{ secrets.API_KEY }}:latest

While this might be a general GitHub Actions issue, it would be helpful to include docs in the README on how to deal with secrets that include a colon.
For instance, should one use single or double quotes around ${{ secrets.API_KEY }} or ${{ secrets.API_KEY }}:latest, or do something else?
Detailed design
No response
Additional information
No response

Never mind. I believe that I misunderstood the syntax of secrets:

@nick-youngblut How'd you misunderstand the syntax? I'm running into a similar issue

@melyux an example of how I set secrets for deploying on Cloud Run:
      - id: "Deploy"
        name: "Deploy to Cloud Run"
        uses: google-github-actions/deploy-cloudrun@v1
        with:
          service: "${{ env.APP }}"
          image: "us-west1-docker.pkg.dev/${{ secrets.GCP_PROJECT_ID }}/${{ env.APP }}/${{ env.APP }}:${{ github.sha }}"
          region: "us-west1"
          secrets: |
            BENCHLING_DEV_DB_PASSWORD=BENCHLING_DEV_DB_PASSWORD:latest
            BENCHLING_PROD_DB_PASSWORD=BENCHLING_PROD_DB_PASSWORD:latest
          flags: >
            --service-account=${{ secrets.GCP_SERVICE_ACCOUNT }}
            --set-env-vars=R_CONFIG_ACTIVE=${{ env.R_CONFIG_ACTIVE }}
            --port=8080
            --cpu=2
            --memory=2Gi
            --min-instances=0
            --max-instances=1
            --concurrency=80

The BENCHLING_DEV_DB_PASSWORD and BENCHLING_PROD_DB_PASSWORD secrets are stored in the GCP Secret Manager.

Thanks @nick-youngblut. I had assumed deploy would let us set the secret values themselves for the run, but this apparently isn't the case. Not clear from the documentation

Yeah, the docs are not very clear. GPT-4o can help, but it does get some stuff wrong.


Textual change for Bought BTC account.

Remove ‘can’ from F&F account.
Title: Exchange Account.
Description: “A separate wallet where your newly bought bitcoin/ sats land”.

Verified this issue on dev app v1.7.9(312)


Integrate with other image plugins

Currently we copy all images to final build, what if there are other plugins which post process image assets?

We need to hook into vite asset pipeline I guess...don't know whats the way


adds a basic comparison step, with logged counts

Fixes

Contributes towards #19

Proposed Changes

Takes the previously parsed datasets (#38 , #37) and compares the content
Comparable variant objects makes this test pretty simple
Nothing substantial being done with the counts yet, just logging the number of variants which match/don't match per sample, and logging all samples which are completely missing from AIP data

Checklist

[x] Related Issue created
[x] Tests covering new change
[x] Linting checks pass

This has been run in Hail Batch, and currently only produces the following (printed) format:
2022-05-26 05:57:47 ERROR comparison:216 - Samples completely missing from AIP results: SAM1, SAM2, SAM3
2022-05-26 05:57:47 ERROR comparison:224 - Sample SAM1: 1 missing variant(s)
2022-05-26 05:57:47 ERROR comparison:224 - Sample SAM2: 1 missing variant(s)
2022-05-26 05:57:47 ERROR comparison:224 - Sample SAM3: 1 missing variant(s)
2022-05-26 05:57:47 INFO comparison:251 - Sample SAM4 - 2 matched variant(s)
2022-05-26 05:57:47 INFO comparison:252 - Sample SAM4 - 0 missing variant(s)

(subset of the real results, with the actual CPG sample IDs anonymised)


actually i will perform the task of spliting the changes into multipl…

…e PRs
but the problem is i started to work on the tasks just today early morning and its now 4AM
which means i gotta push the code and sleep

althought you got some erros/warnings on the github actions pipelines
but the pr can be merged
those errors should be resolved by the next PR


Removed wrong python versions in the contributing.md.

With this phrasing, we won't have to change the file every 6 months.

Coverage remained the same at 85.08% when pulling bc8a09ac9da3cb2cdcb3fb7a180da8a5ca017bb5 on gabrieldemarmiesse:fix_wrong_python_versions_in_contributing into 2e122f463e99b5578043fdb07d33bfd467ed3517 on IDSIA:master.

thanks!


Potentially hold layoutInfo until a later spec revision

Display.layoutInfo: Info about the layout relative to other displays.

So, this currently based on the Chrome App API docs would be roughly how the screen is laid out in relation to the other screens. I think since this can be inferred from the other data provided, we should possibly consider holding off on shipping it in the specification.
My thought process here is that since it can be inferred, it may be better to do a library in JS of what we desire this data structure to look like and get more feedback on it in real-world usage without needing to go through it all with everything else in the v1 specification. This will allow some breathing room to get the core API right, allow libraries to abstract where they can, then consume those API structures internally later as the demand is proven and tested.

I totally agree, I'll remove it from the current proposal. Thanks!


hotfix: initial currency conversion on balance

fiat amount not shown in balance on initial pageload, lets reintroduce the first fetch_balance to fix it.
maybe in the future balance call and wallet itself should give the current fiat value if the wallet uses fiat tracking so you dont need the extra conversion call

Please also remove initial balance assignment from created

done!


Wildcards in tag seems broken.

Describe the bug
When I try to use bufferline.nvim with tag = "v3.*" or tag = "v3.*.*" it can't find the tag. If I use tag = "v3.1.0" it works.
Which version of Neovim are you using?
:version
NVIM v0.8.1
Build type: Release
LuaJIT 2.1.0-beta3
Compiled by<EMAIL_ADDRESS>

You can use the version field for full semver support - see #46
{ 'akinsho/bufferline.nvim', version = "v3.*" }

I'm pretty sure the tag config field must be a real tag on the repo, which is why ranges won't work.

Yep, excatly. Semver is the way to go for this. You don;t need to add the v though, so version="3.* or version=">=3" or ...

Perfect, that works. Sorry about the noise.


feat(composer): Graceful shutdown in Composer

Summary
Brief summary of the changes made, ie "what?"
Background
Brief background on why these changes were made, ie "why?"
Changes

List changes which were made.

Testing
How are these changes tested?
Metrics

List out metrics added by PR, delete section if none.

Breaking Changelist

Bulleted list of breaking changes, any notes on migration. Delete section if none.

Related Issues
Link any issues that are related, prefer full github links.
closes

Closing these PRs to rework shutdown with cancellation tokens.


wildcard major version to latest X.y..z

added check in install function so that if only the major version number is specified, the latest version of that will be installed
fixes 214

Seems this works only for NodeJS < 10 where the major version has only 1 char.

yeah, nvm install 12 installs 12.0.0 :(


Exclude Checkbox not linked with exFilterExternallyTriggered

Here is the live example.
http://jsbin.com/nuduhu/edit?html,js,console,output
Basically, the exclude checkbox will fire search onClick / onKeyUp
However, when using the feature exFilterExternallyTriggered : true
We would like all the filter options to work same way.
Checkbox checked should not trigger independent search.

Fixed in 0.8.9.beta.25


Misleading error message if snippet returns null

Summary
When a snippet returns null, the error message shown in the browser states that the corresponding method could not be found. This is somewhat misleading. I think it would be more informative if it were changed to something like snippet.method returned null. I have uploaded a small project showing this error at https://github.com/aweinert/liftweb-null-snippet.
What I did
$ git clone https://github.com/aweinert/liftweb-null-snippet
<...snip...>
$ cd liftweb-null-snippet
$ ./sbt
> container:start
<...snip...>

Then, open a browser and navigate to <IP_ADDRESS>:8080
What happened
An error is displayed, as shown here:
What I expected to happen
An error should indeed be displayed, but I think the error message is somewhat misleading.
While it is probably technically correct, it should point to a null-pointer-issue rather than to a method resolution one.
Previous discussion
I have also posted this issue to the mailing list.

I think we'll want to add a new error state to LiftRules.SnippetFailures and guard for null in the places where we invoke the result of the function blindly:
https://github.com/lift/framework/blob/79d036703eedf32a27485574ded1bf2805421ead/web/webkit/src/main/scala/net/liftweb/http/LiftSession.scala#L1689
https://github.com/lift/framework/blob/79d036703eedf32a27485574ded1bf2805421ead/web/webkit/src/main/scala/net/liftweb/http/LiftSession.scala#L1678
https://github.com/lift/framework/blob/79d036703eedf32a27485574ded1bf2805421ead/web/webkit/src/main/scala/net/liftweb/http/LiftSession.scala#L1667
https://github.com/lift/framework/blob/79d036703eedf32a27485574ded1bf2805421ead/web/webkit/src/main/scala/net/liftweb/http/LiftSession.scala#L1657
Though the truth is a broader refactoring of snippet dispatch is also long overdue.

I'm going to schedule this for 3.2 with an eye towards refactoring snippet dispatch a bit. We've done some messing with this at work anyway, and I'd like to give it a proper cleanup and expose the important bits for framework user consumption, and fix some of these edge cases while I'm in there.

Also I'd like to accidentally close this issue <_<

Started looking at this a bit, btw. Lot of code to move around, but still hoping to get it done for 3.2.


upgrade Paypal core libraries names

Please upgrade this package, as Paypal has updated their core libraries names here is one example
PPConfigManager -> PayPalConfigManager and so many other libraries name changed
read here Paypal full changes log
https://github.com/paypal/PayPal-PHP-SDK/blob/82971057e15c067e6269591fad44986041e67d15/release_notes.md

@umefarooq  sorry for the delay and thanks for mentioning that . would you like take over that . I really have tons of work. I may need to have some other people help to improve this package.


Use optimal number of VGPRs

LLVM takes a conservative approach during VGPR allocation. It assumes that the work-group size is the largest possible work-group size, hence limits max. number of VGPRs per work-item. To work around this LLVM strategy, this PR sets largest possible work-group size to actual work-group size used.

Is it still WIP? looks good to me

Forgot to change that. Thanks!


⚠ ClamAV has degraded performance

In aedc4c9, ClamAV (https://spamassassin.apache.org/) experienced degraded performance:

HTTP code: 200
Response time: 572 ms

Resolved: ClamAV performance has improved in a8ae385 after 17 minutes.


Norway?

Anecdotally, 'norway' seems to be popular.  Even for example when looking at SA Exploration reports.  Or here:-
This was from a proposal to do predictive analytics on a bunch of geoscience stuff with some dubious analogies - from a Canadian company.
"sti_keywords": [
[
{
"keyword": "education",
"probability": 0.9999927878379822,
"unstemmed": "EDUCATION"
},
{
"keyword": "prediction",
"probability": 0.9999526143074036,
"unstemmed": "PREDICTIONS"
},
{
"keyword": "stability",
"probability": 0.9999324679374695,
"unstemmed": "STABILITY"
},
{
"keyword": "frequency",
"probability": 0.9998124837875366,
"unstemmed": "FREQUENCIES"
},
{
"keyword": "simulation",
"probability": 0.9997246265411377,
"unstemmed": "SIMULATION"
},
{
"keyword": "detection",
"probability": 0.9996479153633118,
"unstemmed": "DETECTION"
},
{
"keyword": "organization",
"probability": 0.999604344367981,
"unstemmed": "ORGANIZATIONS"
},
{
"keyword": "information system",
"probability": 0.9994807243347168,
"unstemmed": "INFORMATION SYSTEMS"
},
{
"keyword": "test",
"probability": 0.9952819347381592,
"unstemmed": "TESTS"
},
{
"keyword": "management method",
"probability": 0.9947834014892578,
"unstemmed": "MANAGEMENT METHODS"
},
{
"keyword": "document",
"probability": 0.9927297234535217,
"unstemmed": "DOCUMENTS"
},
{
"keyword": "sensitivity analysi",
"probability": 0.9906492829322815,
"unstemmed": "SENSITIVITY ANALYSIS"
},
{
"keyword": "survey",
"probability": 0.9885730743408203,
"unstemmed": "SURVEYS"
},
{
"keyword": "measurement",
"probability": 0.9878258109092712,
"unstemmed": "MEASUREMENT"
},
{
"keyword": "on-line system",
"probability": 0.9819966554641724,
"unstemmed": "ON-LINE SYSTEMS"
},
{
"keyword": "probability theory",
"probability": 0.9808198809623718,
"unstemmed": "PROBABILITY THEORY"
},
{
"keyword": "decision making",
"probability": 0.9807706475257874,
"unstemmed": "DECISION MAKING"
},
{
"keyword": "statistical analysi",
"probability": 0.9802524447441101,
"unstemmed": "STATISTICAL ANALYSIS"
},
{
"keyword": "commerce",
"probability": 0.9727779626846313,
"unstemmed": "COMMERCE"
},
{
"keyword": "wind (meteorology)",
"probability": 0.9680668115615845,
"unstemmed": "WIND (METEOROLOGY)"
},
{
"keyword": "ranking",
"probability": 0.966843843460083,
"unstemmed": "RANKING"
},
{
"keyword": "norway",
"probability": 0.9654883742332458,
"unstemmed": "NORWAY"
},
{
"keyword": "turbulence",
"probability": 0.9554965496063232,
"unstemmed": "TURBULENCE"
},
{
"keyword": "environment",
"probability": 0.9523953795433044,
"unstemmed": "ENVIRONMENTS"
},
{
"keyword": "artificial intelligence",
"probability": 0.9461550712585449,
"unstemmed": "ARTIFICIAL INTELLIGENCE"
},
{
"keyword": "spectrum",
"probability": 0.9431440830230713,
"unstemmed": "SPECTRA"
},
{
"keyword": "supplying",
"probability": 0.9292123317718506,
"unstemmed": "SUPPLYING"
},
{
"keyword": "thesis",
"probability": 0.9177210330963135,
"unstemmed": "THESES"
},
{
"keyword": "industry",
"probability": 0.8984866738319397,
"unstemmed": "INDUSTRIES"
},
{
"keyword": "research management",
"probability": 0.8902236223220825,
"unstemmed": "RESEARCH MANAGEMENT"
},
{
"keyword": "logistic",
"probability": 0.8653072118759155,
"unstemmed": "LOGISTICS"
},
{
"keyword": "marketing",
"probability": 0.8555718660354614,
"unstemmed": "MARKETING"
},
{
"keyword": "material",
"probability": 0.8554256558418274,
"unstemmed": "MATERIALS"
},
{
"keyword": "exploration",
"probability": 0.8326903581619263,
"unstemmed": "EXPLORATION"
},
{
"keyword": "finance",
"probability": 0.7999643683433533,
"unstemmed": "FINANCE"
},
{
"keyword": "procedure",
"probability": 0.7985092997550964,
"unstemmed": "PROCEDURES"
},
{
"keyword": "plasmas (physics)",
"probability": 0.7585477828979492,
"unstemmed": "PLASMAS (PHYSICS)"
},
{
"keyword": "management system",
"probability": 0.7525011897087097,
"unstemmed": "MANAGEMENT SYSTEMS"
},
{
"keyword": "personnel",
"probability": 0.7381218075752258,
"unstemmed": "PERSONNEL"
},
{
"keyword": "quality control",
"probability": 0.6919220685958862,
"unstemmed": "QUALITY CONTROL"
},
{
"keyword": "binders (materials)",
"probability": 0.682461678981781,
"unstemmed": "BINDERS (MATERIALS)"
},
{
"keyword": "statistic",
"probability": 0.6598255634307861,
"unstemmed": "STATISTICS"
},
{
"keyword": "technology transfer",
"probability": 0.6495755910873413,
"unstemmed": "TECHNOLOGY TRANSFER"
},
{
"keyword": "economic",
"probability": 0.6489657163619995,
"unstemmed": "ECONOMICS"
},
{
"keyword": "environment management",
"probability": 0.6489007472991943,
"unstemmed": "ENVIRONMENT MANAGEMENT"
},
{
"keyword": "reliability",
"probability": 0.6394709348678589,
"unstemmed": "RELIABILITY"
},
{
"keyword": "methodology",
"probability": 0.5842968225479126,
"unstemmed": "METHODOLOGY"
},
{
"keyword": "life (durability)",
"probability": 0.560967743396759,
"unstemmed": "LIFE (DURABILITY)"
},
{
"keyword": "task",
"probability": 0.5498309135437012,
"unstemmed": "TASKS"
},
{
"keyword": "feedback",
"probability": 0.5493220686912537,
"unstemmed": "FEEDBACK"
},
{
"keyword": "embedding",
"probability": 0.5298750996589661,
"unstemmed": "EMBEDDING"
},
{
"keyword": "model",
"probability": 0.5171043276786804,
"unstemmed": "MODELS"
},
{
"keyword": "image",
"probability": 0.5064711570739746,
"unstemmed": "IMAGES"
},
{
"keyword": "market research",
"probability": 0.5063830018043518,
"unstemmed": "MARKET RESEARCH"
}
]
],
"topic_probabilities": [
[
{
"keyword": "social and information science",
"probability": 0.9999999967051496,
"unstemmed": "social and information sciences"
},
{
"keyword": "life science",
"probability": 0.9997857836273429,
"unstemmed": "life sciences"
},
{
"keyword": "mathematical and computer science",
"probability": 0.9995673040968835,
"unstemmed": "mathematical and computer sciences"
},
{
"keyword": "geoscience",
"probability": 0.6036738988592714,
"unstemmed": "geosciences"
},
{
"keyword": "aeronautic",
"probability": 0.006360614090616023,
"unstemmed": "aeronautics"
},
{
"keyword": "astronautic",
"probability": 0.0010483669327786213,
"unstemmed": "astronautics"
},
{
"keyword": "engineering",
"probability": 0.0006828873398622611,
"unstemmed": "engineering"
},
{
"keyword": "chemistry and material",
"probability": 0.0006251699807542186,
"unstemmed": "chemistry and materials"
},
{
"keyword": "space science",
"probability": 0.0004059099588450474,
"unstemmed": "space sciences"
},
{
"keyword": "physic",
"probability": 0.000008485140273070631,
"unstemmed": "physics"
},
{
"keyword": "general",
"probability": 4.569450859931134e-8,
"unstemmed": "general"
}
]
],
"topic_threshold": 1

That is strange. Not sure why Norway shows up. There is no mention of Norway in the report? Also, how long is the report? One thing to note is these models were trained on abstracts. The performance tends to degrade a bit with very long texts. We actually found that the performance nearly matched that of an abstract when we automatically summarized longer texts down to abstract length (for example, using sumy).

No, and seen it in quite a few others...so relating Norway to something.  So summarise and keyword the summary, as well?

Sumy link says not found btw.

https://github.com/miso-belica/sumy

I think Anthony was suggesting to use 'sumy' to summarize large documents down to abstract length.
It is weird that "Norway" is one of the predicted tags. Are there place names, proper names, or acronyms in the text that could relate to Norway?

Didn't look like it and I am somewhat familiar with Norwegian and place names. Came up some times in some purely South Australian things too, The above had a Canadian address in it. Might have to run it on some chunks to narrow it down.

That library does look handy, thanks.

Checked a few of them... maybe 20% of docs had it come up in this 600 odd sample.  Checked a few just then for the existence of norway - not that, so something related.

Took the example above and kept shrinking it to find the 'Norwayish' bit.  When doing so the Norway probability declined finally down to 0.018 - shrunk it further, then had 0.025 Sweden.  Only proper nouns were two company names and SOW as an acronym.  So interesting.

I'm not sure what the particular reason is for Norway appearing. I think we would have to manually inspect the model for that individual word and see how it is weighting term importances. Could be a case of overfitting. When you say shrink, do you mean you are using automated summarization?

Just saw this tool, might be useful for this type of problem https://github.com/pair-code/lit

Anthony, no, taking sections of the text to try and see which indicated Norway. Justin, saw that one yesterday, will have to investigate. Maybe a higher proportion of abstracts mentioning norway are exploration geosciencey than others, so a longer document like that gets more similarities.

Tomorrow should be able to do a 'Norway' count on a fair set of documents.

7000 odd reports (some from mangled OCR).
Norway keyword percentage: 82.1

Interesting. There must be a really strong correlation between the type of content you're feeding in and Norway in the training data. I'll try to take a closer look at the Norway model at some point and see if it leads to any insights.

Thanks!  Haven't had time yet to try any of the techniques above, or get to the summarisation comparison.  Hopefully this week.

Stability is more common than norway, too, although that at least seems more likely.

Random report summary picked out :
Apart from fair dealing for the purposes of study, research, criticism or review as permitted under the Copyright Act, no part may be reproduced without written permission of the Chief Executive of Primary Industries and Resources South Australia, GPO Box 1671, Adelaide, SA 5001.
A combined seismic reflection and gravity survey was completed across the southeastern portion of Yorke Peninsula for Beach Petroleum Exploration was carried out over a geological province known by drilling to be underlain by )Upper Proterozoic, Cambrian, Permain and Tertiary sediments, the Cambrian and Permian sections of which had been The seismic survey has satisfactorily demonstrated Palaeozoic sedimentary thicknesses to exceed 3500 feet in more southerly areas, and that stratigraphic thickening occurs generally to the south and east.
ments occupy broad glacial valleys, and the sequences tend to be tillitic in the approaches to basal contacts Ludbrook (1961) has recorded thin marine or paralic developments near the base of the section in the Minlaton Comparable developments are believed to have been recorded by A stratigraphic well put down by Beach Petroleum N. L. within the Gulf St. Vincent environs (on Troubridge Island) revealed Permian grey shales and intervening thin sands from 850 feet to the limit of drilling at Undoubted glacial facies appear to be little in evidence.
In the north, submarine topography suggests structural bifurcation with an east segment trending Cambrian limestones outcropping on the coast just south of Ardrossan are similarly monoclinally down-folded to gulfwards (Howchin, 1918).
Primitive estimations place the depth to basement north of Edithburgh approximately 1500 to 2000 feet shallower than in the Yorketown area, The possibility of thrusting of a wedge of base- ment over younger sediments in this coastal zone cannot be ignored entirely.
A complementary south-pitching syn- Local Iclosure'l along the crest of the foregoing anticline is outlined immediately west of Stansbury to the extent of This is herein termed the The 'C' or Deep Horizon map is poorer in reflection quality than the Values are only obtained in one region, representing a limited proportion of the full survey area.
037 - 2 - Appendix II 1 only Mayhew 1000 drilling rig mounted on a 1964 (4 X 4) Bedford truck fitted with 18:00 tyres; short mast, square kelly; Gardner Denver 41" X 6" mud pump; WCQ 427 c.f.m.
The present extension was designed to provide more control for contouring to the north of Stansbury, and also to define the To the east of Currumulka an anomalous NNE-SSW "minimum" trend in both gravity and aeromagnetic corresponds to thickening of Cambrian sediments.
and DARLING, F.W., 1931: "Tables of Theoretical Gravity according to the International Formula" Bulletin SOUTH AUSTRALIAN DEPARTMENT OF MINES, 1955: "Yorke Peninsula - Aeromagnetic Map of Total Intensity" Sheet No.55 - 164, Scale - 13 -
et al, 1966 "Stansbury West No.1 Well Completion Report" by Cundill, Meyers and Associates for Beach Petroleum "The Petrology and Hydrocarbon Potential of some of the Cambrian Carbonates of Yorke Peninsula, South Australia" Unpubl.

"probability_threshold": 0.5,
"request_id": "0",
"sti_keywords": [
[
{
"keyword": "sediment",
"probability": 0.9928513765335083,
"unstemmed": "SEDIMENTS"
},
{
"keyword": "topography",
"probability": 0.9896014928817749,
"unstemmed": "TOPOGRAPHY"
},
{
"keyword": "coast",
"probability": 0.9625886082649231,
"unstemmed": "COASTS"
},
{
"keyword": "drilling",
"probability": 0.9405832886695862,
"unstemmed": "DRILLING"
},
{
"keyword": "australia",
"probability": 0.9212014079093933,
"unstemmed": "AUSTRALIA"
},
{
"keyword": "sedimentary rock",
"probability": 0.8415853381156921,
"unstemmed": "SEDIMENTARY ROCKS"
},
{
"keyword": "ocean bottom",
"probability": 0.8099287152290344,
"unstemmed": "OCEAN BOTTOM"
},
{
"keyword": "survey",
"probability": 0.7431656718254089,
"unstemmed": "SURVEYS"
},
{
"keyword": "limestone",
"probability": 0.731167733669281,
"unstemmed": "LIMESTONE"
},
{
"keyword": "region",
"probability": 0.7080652713775635,
"unstemmed": "REGIONS"
},
{
"keyword": "submarine",
"probability": 0.6398620009422302,
"unstemmed": "SUBMARINES"
},
{
"keyword": "stratigraphy",
"probability": 0.6206201910972595,
"unstemmed": "STRATIGRAPHY"
},
{
"keyword": "thicknes",
"probability": 0.6151227355003357,
"unstemmed": "THICKNESS"
},
{
"keyword": "exploration",
"probability": 0.5438369512557983,
"unstemmed": "EXPLORATION"
},
{
"keyword": "geomorphology",
"probability": 0.5113862156867981,
"unstemmed": "GEOMORPHOLOGY"
}
]
],
"topic_probabilities": [
[
{
"keyword": "geoscience",
"probability": 0.9981602672086761,
"unstemmed": "geosciences"
},
{
"keyword": "life science",
"probability": 0.8026356958046824,
"unstemmed": "life sciences"
},
{
"keyword": "chemistry and material",
"probability": 0.06012665383649461,
"unstemmed": "chemistry and materials"
},
{
"keyword": "engineering",
"probability": 0.054703640877981734,
"unstemmed": "engineering"
},
{
"keyword": "physic",
"probability": 0.0320413217119646,
"unstemmed": "physics"
},
{
"keyword": "mathematical and computer science",
"probability": 0.019253640010804155,
"unstemmed": "mathematical and computer sciences"
},
{
"keyword": "astronautic",
"probability": 0.01115925991857776,
"unstemmed": "astronautics"
},
{
"keyword": "space science",
"probability": 0.010097497008795819,
"unstemmed": "space sciences"
},
{
"keyword": "social and information science",
"probability": 0.0024410125782841226,
"unstemmed": "social and information sciences"
},
{
"keyword": "aeronautic",
"probability": 0.002183980775956557,
"unstemmed": "aeronautics"
},
{
"keyword": "general",
"probability": 0.0007967235959187748,
"unstemmed": "general"
}
]
],
"topic_threshold": 1

and the keywords from the whole report:
,"sti_keywords":[[{"keyword":"detection","probability":1.0,"unstemmed":"DETECTION"},{"keyword":"frequency","probability":1.0,"unstemmed":"FREQUENCIES"},{"keyword":"norway","probability":1.0,"unstemmed":"NORWAY"},{"keyword":"simulation","probability":1.0,"unstemmed":"SIMULATION"},{"keyword":"stability","probability":1.0,"unstemmed":"STABILITY"},{"keyword":"velocity","probability":1.0,"unstemmed":"VELOCITY"},{"keyword":"wind (meteorology)","probability":1.0,"unstemmed":"WIND (METEOROLOGY)"},{"keyword":"drainage","probability":0.9999985098838806,"unstemmed":"DRAINAGE"},{"keyword":"boundary","probability":0.9999971389770508,"unstemmed":"BOUNDARIES"},{"keyword":"binders (materials)","probability":0.9999895691871643,"unstemmed":"BINDERS (MATERIALS)"},{"keyword":"spectrum","probability":0.9999833106994629,"unstemmed":"SPECTRA"},{"keyword":"topography","probability":0.9999693632125854,"unstemmed":"TOPOGRAPHY"},{"keyword":"turbulence","probability":0.9999633431434631,"unstemmed":"TURBULENCE"},{"keyword":"gas","probability":0.9999365210533142,"unstemmed":"GASES"},{"keyword":"gravitation","probability":0.9999074935913086,"unstemmed":"GRAVITATION"},{"keyword":"scattering","probability":0.9998400807380676,"unstemmed":"SCATTERING"},{"keyword":"coast","probability":0.9998008012771606,"unstemmed":"COASTS"},{"keyword":"geology","probability":0.9997913837432861,"unstemmed":"GEOLOGY"},{"keyword":"circulation","probability":0.9997692704200745,"unstemmed":"CIRCULATION"},{"keyword":"horizontal orientation","probability":0.9996856451034546,"unstemmed":"HORIZONTAL ORIENTATION"},{"keyword":"survey","probability":0.9996093511581421,"unstemmed":"SURVEYS"},{"keyword":"deposition","probability":0.9995365738868713,"unstemmed":"DEPOSITION"},{"keyword":"sediment","probability":0.9993331432342529,"unstemmed":"SEDIMENTS"},{"keyword":"crystal","probability":0.9993000030517578,"unstemmed":"CRYSTALS"},{"keyword":"plasmas (physics)","probability":0.9992559552192688,"unstemmed":"PLASMAS (PHYSICS)"},{"keyword":"adult","probability":0.9988338947296143,"unstemmed":"ADULTS"},{"keyword":"rock","probability":0.9987765550613403,"unstemmed":"ROCKS"},{"keyword":"prediction","probability":0.9986652731895447,"unstemmed":"PREDICTIONS"},{"keyword":"error","probability":0.99862140417099,"unstemmed":"ERRORS"},{"keyword":"canada","probability":0.9981276392936707,"unstemmed":"CANADA"},{"keyword":"position (location)","probability":0.9980089068412781,"unstemmed":"POSITION (LOCATION)"},{"keyword":"perturbation","probability":0.9977721571922302,"unstemmed":"PERTURBATION"},{"keyword":"geophysic","probability":0.9969445466995239,"unstemmed":"GEOPHYSICS"},{"keyword":"image","probability":0.9956791996955872,"unstemmed":"IMAGES"},{"keyword":"ion","probability":0.9956188201904297,"unstemmed":"IONS"},{"keyword":"loss","probability":0.9947844743728638,"unstemmed":"LOSSES"},{"keyword":"wake","probability":0.9905879497528076,"unstemmed":"WAKES"},{"keyword":"projectile","probability":0.9886454939842224,"unstemmed":"PROJECTILES"},{"keyword":"resolution","probability":0.987578272819519,"unstemmed":"RESOLUTION"},{"keyword":"x ray","probability":0.9852748513221741,"unstemmed":"X RAYS"},{"keyword":"water","probability":0.9840564727783203,"unstemmed":"WATER"},{"keyword":"longitude","probability":0.9819511771202087,"unstemmed":"LONGITUDE"},{"keyword":"injection","probability":0.9818744659423828,"unstemmed":"INJECTION"},{"keyword":"test","probability":0.9723952412605286,"unstemmed":"TESTS"},{"keyword":"mollusk","probability":0.963683009147644,"unstemmed":"MOLLUSKS"},{"keyword":"attitude (inclination)","probability":0.956942081451416,"unstemmed":"ATTITUDE (INCLINATION)"},{"keyword":"deformation","probability":0.9378564357757568,"unstemmed":"DEFORMATION"},{"keyword":"united kingdom","probability":0.9181330800056458,"unstemmed":"UNITED KINGDOM"},{"keyword":"sensitivity analysi","probability":0.9107515811920166,"unstemmed":"SENSITIVITY ANALYSIS"},{"keyword":"australia","probability":0.9103879928588867,"unstemmed":"AUSTRALIA"},{"keyword":"crystallinity","probability":0.8907729387283325,"unstemmed":"CRYSTALLINITY"},{"keyword":"mathematic","probability":0.870129406452179,"unstemmed":"MATHEMATICS"},{"keyword":"excitation","probability":0.8667937517166138,"unstemmed":"EXCITATION"},{"keyword":"thicknes","probability":0.8121394515037537,"unstemmed":"THICKNESS"},{"keyword":"measurement","probability":0.8025984764099121,"unstemmed":"MEASUREMENT"},{"keyword":"reliability","probability":0.7956236600875854,"unstemmed":"RELIABILITY"},{"keyword":"drying","probability":0.7842564582824707,"unstemmed":"DRYING"},{"keyword":"angular resolution","probability":0.7671957612037659,"unstemmed":"ANGULAR RESOLUTION"},{"keyword":"male","probability":0.6826151609420776,"unstemmed":"MALES"},{"keyword":"wall","probability":0.6692981719970703,"unstemmed":"WALLS"},{"keyword":"oscillation","probability":0.6411301493644714,"unstemmed":"OSCILLATIONS"},{"keyword":"female","probability":0.6219513416290283,"unstemmed":"FEMALES"},{"keyword":"shape","probability":0.49701258540153503,"unstemmed":"SHAPES"},{"keyword":"biodynamic","probability":0.48482751846313477,"unstemmed":"BIODYNAMICS"},{"keyword":"target","probability":0.4754076600074768,"unstemmed":"TARGETS"},{"keyword":"heating","probability":0.46355319023132324,"unstemmed":"HEATING"},{"keyword":"europe","probability":0.4513147473335266,"unstemmed":"EUROPE"},{"keyword":"infrared radiation","probability":0.36240354180336,"unstemmed":"INFRARED RADIATION"},{"keyword":"analysis (mathematics)","probability":0.357046902179718,"unstemmed":"ANALYSIS (MATHEMATICS)"}]],"topic_probabilities":[[{"keyword":"geoscience","probability":0.9999999999995617,"unstemmed":"geosciences"},{"keyword":"life science","probability":0.9999999998044267,"unstemmed":"life sciences"},{"keyword":"space science","probability":5.952435167211817e-05,"unstemmed":"space sciences"},{"keyword":"physic","probability":4.797571174203055e-07,"unstemmed":"physics"},{"keyword":"aeronautic","probability":3.452614189217303e-07,"unstemmed":"aeronautics"},{"keyword":"social and information science","probability":2.775078370610512e-07,"unstemmed":"social and information sciences"},{"keyword":"engineering","probability":2.1643729127246794e-07,"unstemmed":"engineering"},{"keyword":"astronautic","probability":3.961110196099098e-08,"unstemmed":"astronautics"},{"keyword":"chemistry and material","probability":6.182643119277685e-10,"unstemmed":"chemistry and materials"},{"keyword":"mathematical and computer science","probability":4.1405143328909e-10,"unstemmed":"mathematical and computer sciences"},{"keyword":"general","probability":2.2434030242077953e-19,"unstemmed":"general"}]],"topic_threshold":1.0},"service_version":"unspecified","status":"okay"}

I made a graph out of what I have done, here's the edge counts for 'norway'
[('stability', {'weight': 12740}),
('simulation', {'weight': 12502}),
('detection', {'weight': 12152}),
('spectrum', {'weight': 12022}),
('drainage', {'weight': 11570}),
('survey', {'weight': 11534}),
('wind (meteorology)', {'weight': 11514}),
('frequency', {'weight': 11514}),
('boundary', {'weight': 11266}),
('scattering', {'weight': 11106}),
('binders (materials)', {'weight': 10732}),
('turbulence', {'weight': 10722}),
('canada', {'weight': 10514}),
('geology', {'weight': 10392}),
('plasmas (physics)', {'weight': 10370}),
('prediction', {'weight': 10004}),
('deposition', {'weight': 9838}),
('rock', {'weight': 9748}),
('circulation', {'weight': 9592}),
('water', {'weight': 9564}),
('sediment', {'weight': 9484}),
('velocity', {'weight': 8930}),
('geophysic', {'weight': 8788}),
('excitation', {'weight': 8514}),
('position (location)', {'weight': 8494}),
('crystal', {'weight': 8336}),
('injection', {'weight': 8102}),

and coal
[('stability', {'weight': 5478}),
('simulation', {'weight': 5344}),
('norway', {'weight': 5254}),
('detection', {'weight': 5168}),
('spectrum', {'weight': 5116}),
('drainage', {'weight': 5074}),
('wind (meteorology)', {'weight': 4916}),
('frequency', {'weight': 4900}),
('binders (materials)', {'weight': 4766}),
('deposition', {'weight': 4732}),
('geology', {'weight': 4700}),
('scattering', {'weight': 4686}),
('survey', {'weight': 4684}),
('boundary', {'weight': 4648}),
('rock', {'weight': 4558}),
('turbulence', {'weight': 4546}),
('sediment', {'weight': 4512}),
('water', {'weight': 4492}),
('canada', {'weight': 4420}),

One area perhaps where Northern Hemisphere dominated keywords will be a problem - would be differences between petroleum and gas if they call them all gas?


Rebuild with parallel OpenBLAS

Bump build number and rebuild with the parallel OpenBLAS.

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

@grlee77, not sure if this impacts anything you are using downstream, but figured you should be aware of it. We rebuilt OpenBLAS to be multithreaded, which appears to break ABI. So we are rebuilding everything linked to it.


Optimize port communication for scalar types

In reactor-cpp, every value relayed via ports and stored in actions is wrapped in a value ptr. The value ptr itself is a wrapper around the smart pointers of the stdlib and extends it by control for mutability. However, a smartpointer adds a small (but still significant) overhead if simple data types such as scalar values are used. This PR provides to different template specializations that implement the value ptr interface. The old one (based on smart pointers) is only used for non-scalar types. For all scalar types, a new optimized specialization is added that simply stores the value directly instead of using a smartpointer.
On my laptop, this improved performance of the RadixSort benchmark by about 1.7x. Other benchmarks likely also benefit from the change, but maybe not as much.

I ran every test locally everything worked and the code looked fine to me.


non-exhaustive patterns: Language::Javascript not covered

after running:
cargo install atac

to install ATAC, I face this error:
in /postman.rs:278:50
    |
278 |                         let request_body = match language {
    |                                                  ^^^^^^^^ pattern `Language::Javascript` not covered
    |
note: `Language` defined here
/mod.rs:448:1
    |
448 | pub enum Language {
    | ^^^^^^^^^^^^^^^^^
...
462 |     Javascript,
    |     ---------- not covered
    = note: the matched value is of type `Language`
help: ensure that all possible cases are being handled by adding a match arm with a wildcard pattern or an explicit pattern as shown
    |
282 ~                             Language::Xml => ContentType::Xml(body_as_raw),
283 +                             Language::Javascript => todo!()
    |

For more information about this error, try `rustc --explain E0004`.
error: could not compile `atac` (bin "atac") due to 1 previous error
error: failed to compile `atac v0.13.0`, intermediate artifacts can be found at `/tmp/cargo-installL1VJs5`.
To reuse those artifacts with a future compilation, set the environment variable `CARGO_TARGET_DIR` to that path.

but the source code actually has this match value for Language enum covered as can be seen:
in /postman.rs
 return match body_mode {
                Mode::Raw => {
                    let body_as_raw = body.raw?;

                    if let Some(options) = body.options {
                        let language = options.raw?.language?;

                        let request_body = match language {
                            Language::Html => ContentType::Html(body_as_raw),
                            Language::Json => ContentType::Json(body_as_raw),
                            Language::Text => ContentType::Raw(body_as_raw),
                            Language::Xml => ContentType::Xml(body_as_raw),
                            Language::Javascript => ContentType::Javascript(body_as_raw),
                        };

                        Some(request_body)
                    } else {
                        Some(ContentType::Raw(body_as_raw))
                    }
                }

what seems to be the problem, can somebody explain this? Thanks

Hello!
This temporary issue has been resolved in https://github.com/Julien-cpsn/ATAC/issues/35
Have a great day


Using inside magit

This is completely off-topic but I'm not sure where to discuss this.
You seem to be a magit user and I was wondering if you were using difftastic with magit? It seems that magit always deactivate external diffing tools by default. I haven't seen any specific setup in your .emacs.d.

also off-topic but related:
https://github.com/jesseduffield/lazygit/issues/1853

I'm not currently using difftastic with magit. Early versions of difftastic had a nasty habit of trying to use all the memory on the machine (I didn't have DFT_NODE_LIMIT and the code was way less efficient), so I often needed to ctrl-c difftastic.
Difftastic is in a better state today, but I'm still not happy with it. I'm still hoping to make it faster (#232, #156). Display still isn't great either (it needs 24-bit colours with a fallback, inline display crashes #228).
The project alternates between very interesting and very frustrating to hack on :). It's mature enough that I'm comfortable sharing  it, and I'm using difftastic for the majority of my diffing these days.
Difftastic doesn't even work very well in Emacs' eshell/ansi-term yet and I'm not sure why (#177). I know there's magit-delta on MELPA so in principle it should be possible to write a magit package once difftastic is more finished.
I've had requests for integration with a whole range of tools, so I've added a note in the README that I'm open to linking to any relevant plugins people build: https://github.com/wilfred/difftastic#does-difftastic-integrate-with-my-favourite-tool . I'm not even sure what a good external data format is, and the difftastic internals are complicated (arena-allocated syntax trees with pointers to unchanged nodes).

This would be awesome, but I understand it's not high at the priority list at the moment.
Instead I'm currently using magit-delta, which is powered by git-delta, which is also an improvement over the default diff: https://scripter.co/using-git-delta-with-magit/
/ht @kaushalmodi

Oh, I just discovered https://tsdh.org/posts/2022-08-01-difftastic-diffing-with-magit.html. Thanks to @sachac's weekly Emacs News.

I know this has been linked before, but there was an update there recently: https://github.com/jesseduffield/lazygit/issues/1853. Any chance we could make difftastic's output format work with lazygit's hunk parsing algorithm? Thanks for all the hard work!


feat: enforce dependencies for services in docker compose

Adding dependencies and health checks for relevant services
I confirm that this contribution is made under the terms of the license found in the root directory of this repository's source tree and that I have the authority necessary to make this contribution on behalf of its copyright owner.
Resolve #1012

@jrozner Isn't that the case already? All the frontend (nginx) containers depends on the backend to be up already

Ah sorry, I didn't realize we already had that.


Remove AssertGoldenBytes test helper

The test suite is thereby simplified somewhat.
Signed-off-by: Simon Alling<EMAIL_ADDRESS>

@bacongobbler


Failed to get secret for proxy

Hi,
I have an Istio 1.5 installation on AWS EKS (Kubernetes 1.15) Istio was installed with istioctl and Demo profile, and a modified manifest to enable Istio to work with AWS NLB.
Everything worked fine up until last week Friday I tried to manually scale the istio-ingressgateway, which basically did not work. Raising the replicaset did not actually raise the number of pods. However, since then, in k8s dashboard, I can see two ingress-gateways, one, the original replica, up and running since numerous days. The second one constantly recreating.
With some efforts, I was finally able to extract container logs (see below) from the node the terminating pods were assigned to
Bug description
From the container logs it seems the Istio proxy is terminating the connection , but I don't know what the underlying reason may be and how to get it fixed.
[ ] Docs
[ ] Installation
[X ] Networking
[ ] Performance and Scalability
[ ] Extensions and Telemetry
[ ] Security
[ ] Test and Release
[ ] User Experience
[ ] Developer Infrastructure
Expected behavior
Steps to reproduce the bug
Version (include the output of istioctl version --remote and kubectl version and helm version if you used Helm)
How was Istio installed?
Environment where bug was observed (cloud vendor, OS, etc)
{"log":"[Envoy (Epoch 0)] [2020-08-12 07:14:35.656][15][warning][config] [bazel-out/k8-opt/bin/external/envoy/source/common/config/_virtual_includes/grpc_stream_lib/common/config/grpc_stream.h:91] gRPC config stream closed: 14, no healthy upstream\n","stream":"stderr","time":"2020-08-12T07:14:35.656390386Z"}
{"log":"[Envoy (Epoch 0)] [2020-08-12 07:14:35.656][15][warning][config] [bazel-out/k8-opt/bin/external/envoy/source/common/config/_virtual_includes/grpc_stream_lib/common/config/grpc_stream.h:54] Unable to establish new stream\n","stream":"stderr","time":"2020-08-12T07:14:35.656419936Z"}
{"log":"2020-08-12T07:14:35.664305Z\u0009info\u0009sds\u0009node:router~<IP_ADDRESS>~istio-ingressgateway-bcd79ccb-cc8tw.istio-system~istio-system.svc.cluster.local-1 resource:default new connection\n","stream":"stdout","time":"2020-08-12T07:14:35.675832022Z"}
{"log":"2020-08-12T07:14:35.742597Z\u0009error\u0009citadelclient\u0009Failed to create certificate: rpc error: code = Unauthenticated desc= request authenticate failure\n","stream":"stdout","time":"2020-08-12T07:14:35.74271502Z"}
{"log":"2020-08-12T07:14:35.742636Z\u0009error\u0009cache\u0009node:router~<IP_ADDRESS>~istio-ingressgateway-bcd79ccb-cc8tw.istio-system~istio-system.svc.cluster.local-1 resource:default request:b40e778b-2f66-44c6-b8ee-60e52d86e8d9 CSR hit non-retryable error (HTTP code: 0). Error: rpc error: code = Unauthenticated desc = request authenticate failure\n","stream":"stdout","time":"2020-08-12T07:14:35.742772223Z"}
{"log":"2020-08-12T07:14:35.742658Z\u0009error\u0009cache\u0009node:router~<IP_ADDRESS>~istio-ingressgateway-bcd79ccb-cc8tw.istio-system~istio-system.svc.cluster.local-1 resource:default failed to generate secret for proxy: rpc error: code = Unauthenticated desc = request authenticate failure\n","stream":"stdout","time":"2020-08-12T07:14:35.742779142Z"}
{"log":"2020-08-12T07:14:35.742718Z\u0009error\u0009sds\u0009node:router~<IP_ADDRESS>~istio-ingressgateway-bcd79ccb-cc8tw.istio-system~istio-system.svc.cluster.local-1 resource:default Close connection. Failed to get secret for proxy \"router~<IP_ADDRESS>~istio-ingressgateway-bcd79ccb-cc8tw.istio-system~istio-system.svc.cluster.local\" from secret cache: rpc error: code = Unauthenticated desc = request authenticate failure\n","stream":"stdout","time":"2020-08-12T07:14:35.742788059Z"}
{"log":"2020-08-12T07:14:35.742830Z\u0009info\u0009sds\u0009node:router~<IP_ADDRESS>~istio-ingressgateway-bcd79ccb-cc8tw.istio-system~istio-system.svc.cluster.local-1 resource:default connection is terminated: rpc error: code = Canceled desc = context canceled\n","stream":"stdout","time":"2020-08-12T07:14:35.742905078Z"}
{"log":"[Envoy (Epoch 0)] [2020-08-12 07:14:35.742][15][warning][config] [bazel-out/k8-opt/bin/external/envoy/source/common/config/_virtual_includes/grpc_stream_lib/common/config/grpc_stream.h:91] gRPC config stream closed: 16, request authenticate failure\n","stream":"stderr","time":"2020-08-12T07:14:35.743027671Z"}
{"log":"2020-08-12T07:14:35.874955Z\u0009info\u0009sds\u0009node:router~<IP_ADDRESS>~istio-ingressgateway-bcd79ccb-cc8tw.istio-system~istio-system.svc.cluster.local-2 resource:default new connection\n","stream":"stdout","time":"2020-08-12T07:14:35.883571973Z"}
{"log":"2020-08-12T07:14:35.989052Z\u0009error\u0009citadelclient\u0009Failed to create certificate: rpc error: code = Unauthenticated desc= request authenticate failure\n","stream":"stdout","time":"2020-08-12T07:14:35.989188639Z"}
{"log":"2020-08-12T07:14:35.989084Z\u0009error\u0009cache\u0009node:router~<IP_ADDRESS>~istio-ingressgateway-bcd79ccb-cc8tw.istio-system~istio-system.svc.cluster.local-2 resource:default request:a7f2dbb1-2389-4b18-a74a-bff5b8885daa CSR hit non-retryable error (HTTP code: 0). Error: rpc error: code = Unauthenticated desc = request authenticate failure\n","stream":"stdout","time":"2020-08-12T07:14:35.989214107Z"}
{"log":"2020-08-12T07:14:35.989247Z\u0009error\u0009cache\u0009node:router~<IP_ADDRESS>~istio-ingressgateway-bcd79ccb-cc8tw.istio-system~istio-system.svc.cluster.local-2 resource:default failed to generate secret for proxy: rpc error: code = Unauthenticated desc = request authenticate failure\n","stream":"stdout","time":"2020-08-12T07:14:35.989293983Z"}
{"log":"2020-08-12T07:14:35.989323Z\u0009error\u0009sds\u0009node:router~<IP_ADDRESS>~istio-ingressgateway-bcd79ccb-cc8tw.istio-system~istio-system.svc.cluster.local-2 resource:default Close connection. Failed to get secret for proxy \"router~<IP_ADDRESS>~istio-ingressgateway-bcd79ccb-cc8tw.istio-system~istio-system.svc.cluster.local\" from secret cache: rpc error: code = Unauthenticated desc = request authenticate failure\n","stream":"stdout","time":"2020-08-12T07:14:35.989356058Z"}
{"log":"2020-08-12T07:14:35.989396Z\u0009info\u0009sds\u0009node:router~<IP_ADDRESS>~istio-ingressgateway-bcd79ccb-cc8tw.istio-system~istio-system.svc.cluster.local-2 resource:default connection is terminated: rpc error: code = Canceled desc = context canceled\n","stream":"stdout","time":"2020-08-12T07:14:35.989453882Z"}
{"log":"[Envoy (Epoch 0)] [2020-08-12 07:14:35.989][15][warning][config] [bazel-out/k8-opt/bin/external/envoy/source/common/config/_virtual_includes/grpc_stream_lib/common/config/grpc_stream.h:91] gRPC config stream closed: 16, request authenticate failure\n","stream":"stderr","time":"2020-08-12T07:14:35.989593061Z"}
{"log":"[Envoy (Epoch 0)] [2020-08-12 07:14:36.363][15][warning][config] [bazel-out/k8-opt/bin/external/envoy/source/common/config/_virtual_includes/grpc_stream_lib/common/config/grpc_stream.h:91] gRPC config stream closed: 14, no healthy upstream\n","stream":"stderr","time":"2020-08-12T07:14:36.363698818Z"}
{"log":"[Envoy (Epoch 0)] [2020-08-12 07:14:36.363][15][warning][config] [bazel-out/k8-opt/bin/external/envoy/source/common/config/_virtual_includes/grpc_stream_lib/common/config/grpc_stream.h:54] Unable to establish new stream\n","stream":"stderr","time":"2020-08-12T07:14:36.363757681Z"}
{"log":"2020-08-12T07:14:37.020048Z\u0009info\u0009sds\u0009node:router~<IP_ADDRESS>~istio-ingressgateway-bcd79ccb-cc8tw.istio-system~istio-system.svc.cluster.local-3 resource:default new connection\n","stream":"stdout","time":"2020-08-12T07:14:37.020227224Z"}
{"log":"2020-08-12T07:14:37.170853Z\u0009error\u0009citadelclient\u0009Failed to create certificate: rpc error: code = Unauthenticated desc= request authenticate failure\n","stream":"stdout","time":"2020-08-12T07:14:37.170952319Z"}
{"log":"2020-08-12T07:14:37.170877Z\u0009error\u0009cache\u0009node:router~<IP_ADDRESS>~istio-ingressgateway-bcd79ccb-cc8tw.istio-system~istio-system.svc.cluster.local-3 resource:default request:a34ba318-50ca-4567-81cc-c640c24a4ea6 CSR hit non-retryable error (HTTP code: 0). Error: rpc error: code = Unauthenticated desc = request authenticate failure\n","stream":"stdout","time":"2020-08-12T07:14:37.170983465Z"}
{"log":"2020-08-12T07:14:37.170906Z\u0009error\u0009cache\u0009node:router~<IP_ADDRESS>~istio-ingressgateway-bcd79ccb-cc8tw.istio-system~istio-system.svc.cluster.local-3 resource:default failed to generate secret for proxy: rpc error: code = Unauthenticated desc = request authenticate failure\n","stream":"stdout","time":"2020-08-12T07:14:37.171023334Z"}
{"log":"2020-08-12T07:14:37.170916Z\u0009error\u0009sds\u0009node:router~<IP_ADDRESS>~istio-ingressgateway-bcd79ccb-cc8tw.istio-system~istio-system.svc.cluster.local-3 resource:default Close connection. Failed to get secret for proxy \"router~<IP_ADDRESS>~istio-ingressgateway-bcd79ccb-cc8tw.istio-system~istio-system.svc.cluster.local\" from secret cache: rpc error: code = Unauthenticated desc = request authenticate failure\n","stream":"stdout","time":"2020-08-12T07:14:37.171029035Z"}
{"log":"[Envoy (Epoch 0)] [2020-08-12 07:14:37.171][15][warning][config] [bazel-out/k8-opt/bin/external/envoy/source/common/config/_virtual_includes/grpc_stream_lib/common/config/grpc_stream.h:91] gRPC config stream closed: 16, request authenticate failure\n","stream":"stderr","time":"2020-08-12T07:14:37.171127026Z"}
{"log":"2020-08-12T07:14:37.171144Z\u0009info\u0009sds\u0009node:router~<IP_ADDRESS>~istio-ingressgateway-bcd79ccb-cc8tw.istio-system~istio-system.svc.cluster.local-3 resource:default connection is terminated: rpc error: code = Canceled desc = context canceled\n","stream":"stdout","time":"2020-08-12T07:14:37.171189359Z"}
{"log":"2020-08-12T07:14:38.592463Z\u0009info\u0009watchFileEvents has successfully terminated\n","stream":"stdout","time":"2020-08-12T07:14:38.592731506Z"}
{"log":"2020-08-12T07:14:38.592477Z\u0009info\u0009Watcher has successfully terminated\n","stream":"stdout","time":"2020-08-12T07:14:38.592772821Z"}
{"log":"2020-08-12T07:14:38.592464Z\u0009info\u0009Agent draining Proxy\n","stream":"stdout","time":"2020-08-12T07:14:38.592779464Z"}
{"log":"2020-08-12T07:14:38.592488Z\u0009info\u0009Status server has successfully terminated\n","stream":"stdout","time":"2020-08-12T07:14:38.592783903Z"}
{"log":"2020-08-12T07:14:38.592535Z\u0009error\u0009accept tcp [::]:15020: use of closed network connection\n","stream":"stdout","time":"2020-08-12T07:14:38.592787804Z"}
{"log":"2020-08-12T07:14:38.593243Z\u0009info\u0009Graceful termination period is 5s, starting...\n","stream":"stdout","time":"2020-08-12T07:14:38.593341783Z"}
{"log":"[Envoy (Epoch 0)] [2020-08-12 07:14:39.180][15][warning][config] [bazel-out/k8-opt/bin/external/envoy/source/common/config/_virtual_includes/grpc_stream_lib/common/config/grpc_stream.h:91] gRPC config stream closed: 14, no healthy upstream\n","stream":"stderr","time":"2020-08-12T07:14:39.1809113Z"}
{"log":"[Envoy (Epoch 0)] [2020-08-12 07:14:39.180][15][warning][config] [bazel-out/k8-opt/bin/external/envoy/source/common/config/_virtual_includes/grpc_stream_lib/common/config/grpc_stream.h:54] Unable to establish new stream\n","stream":"stderr","time":"2020-08-12T07:14:39.180940339Z"}
{"log":"2020-08-12T07:14:40.520407Z\u0009info\u0009sds\u0009node:router~<IP_ADDRESS>~istio-ingressgateway-bcd79ccb-cc8tw.istio-system~istio-system.svc.cluster.local-4 resource:default new connection\n","stream":"stdout","time":"2020-08-12T07:14:40.520615876Z"}
{"log":"2020-08-12T07:14:40.750383Z\u0009error\u0009citadelclient\u0009Failed to create certificate: rpc error: code = Unauthenticated desc= request authenticate failure\n","stream":"stdout","time":"2020-08-12T07:14:40.750523315Z"}
{"log":"2020-08-12T07:14:40.750412Z\u0009error\u0009cache\u0009node:router~<IP_ADDRESS>~istio-ingressgateway-bcd79ccb-cc8tw.istio-system~istio-system.svc.cluster.local-4 resource:default request:10a279c7-ef5e-4b38-90c0-9f968203d7e0 CSR hit non-retryable error (HTTP code: 0). Error: rpc error: code = Unauthenticated desc = request authenticate failure\n","stream":"stdout","time":"2020-08-12T07:14:40.750567464Z"}
{"log":"2020-08-12T07:14:40.750450Z\u0009error\u0009cache\u0009node:router~<IP_ADDRESS>~istio-ingressgateway-bcd79ccb-cc8tw.istio-system~istio-system.svc.cluster.local-4 resource:default failed to generate secret for proxy: rpc error: code = Unauthenticated desc = request authenticate failure\n","stream":"stdout","time":"2020-08-12T07:14:40.750574796Z"}
{"log":"2020-08-12T07:14:40.750480Z\u0009error\u0009sds\u0009node:router~<IP_ADDRESS>~istio-ingressgateway-bcd79ccb-cc8tw.istio-system~istio-system.svc.cluster.local-4 resource:default Close connection. Failed to get secret for proxy \"router~<IP_ADDRESS>~istio-ingressgateway-bcd79ccb-cc8tw.istio-system~istio-system.svc.cluster.local\" from secret cache: rpc error: code = Unauthenticated desc = request authenticate failure\n","stream":"stdout","time":"2020-08-12T07:14:40.750579737Z"}
{"log":"2020-08-12T07:14:40.750551Z\u0009info\u0009sds\u0009node:router~<IP_ADDRESS>~istio-ingressgateway-bcd79ccb-cc8tw.istio-system~istio-system.svc.cluster.local-4 resource:default connection is terminated: rpc error: code = Canceled desc = context canceled\n","stream":"stdout","time":"2020-08-12T07:14:40.750597752Z"}
{"log":"[Envoy (Epoch 0)] [2020-08-12 07:14:40.750][15][warning][config] [bazel-out/k8-opt/bin/external/envoy/source/common/config/_virtual_includes/grpc_stream_lib/common/config/grpc_stream.h:91] gRPC config stream closed: 16, request authenticate failure\n","stream":"stderr","time":"2020-08-12T07:14:40.750805653Z"}

Interesting, haven't seen that log. Are there logs in Istiod about the authentication failure? usually it will say why the auth failed

Hi John,
thanks for your reply.
I'm actually an Istio newbie, and hunting for a solution quite a while now. I manged to pull the logs from the  container logs folder of the executing node.
If I understood you correctly, the istiod logs may also provide some details about the failure?
I'll try that immediately tomorrow morning.
~Harald

istiod.log
I managed to get the logs from istiod (attached). What I find quite interesting and most promising are several lines of the same kind, saying:
Authentication failed: Authenticator ClientCertAuthenticator at index 0 got error: no verified chain is found. Authenticator KubeJWTAuthenticator at index 1 got error: failed to validate the JWT: the service account authentication returns an error: [invalid bearer token, Token has been invalidated, unknown]. Authenticator ClientCertAuthenticator at index 2 got error: no verified chain is found.
But again, I'm a bloody beginner and can't make any sense out of it.

Basically the pod will get a service account token, and send that to istiod to authenticate. Somehow the token is invalid (see invalid bearer token, Token has been invalidated, unknown). This could likely be an issue with your kubernetes set up? You could look at ./var/run/secrets/tokens/istio-token on the proxy container to get the token then look on jwt.io to see the contents maybe

Hi John,
the issue is that the affected pod is terminating in a matter of seconds. No chance for me to get into the underlying container to pull the token.
Regards,
Harald

I ran into this exact same issue. I'm deploying 2nd istio-ingressgateway on the cluster and it was working before and not sure of what caused to run into this error.
I have deleted istio components and re-installed then tried to run the 2nd-istio-ingressgateway, still the same.
Here are my logs from istiod container.
Authenticator ClientCertAuthenticator at index 0 got error: no verified chain is found. Authenticator KubeJWTAuthenticator at index 1 got error: failed to validate the JWT: the service account authentication returns an error: [invalid bearer token, token audiences ["api" "vault" "factors"] is invalid for the target audiences ["istio-ca"]]. Authenticator ClientCertAuthenticator at index 2 got error: no verified chain is found.
Logs from ingress-gateway pod.
error cache resource:default failed to generate secret for proxy: rpc error: code = Unauthenticated desc = request authenticate failure
error	sds	resource:default Close connection. Failed to get secret for proxy "router~second-istio-ingressgateway-78b7c5c8c9-8b6cp.istio-system~istio-system.svc.cluster.local" from secret cache: rpc error: code = Unauthenticated desc = request authenticate failure
info	sds	resource:default connection is terminated: rpc error: code = Canceled desc = context canceled
warning	envoy config	StreamSecrets gRPC config stream closed: 16, request authenticate failure
warning	envoy config	StreamAggregatedResources gRPC config stream closed: 14, no healthy upstream
warning	envoy config	Unable to establish new stream
info	sds	resource:default new connection
info	sds	Skipping waiting for gateway secret
error	citadelclient	Failed to create certificate: rpc error: code = Unauthenticated desc = request authenticate failure
error	cache	resource:default request:fdc254e9-7df6-41b8-a8ff-475cf5be4318 CSR hit non-retryable error (HTTP code: 0). Error: rpc error: code = Unauthenticated desc = request authenticate failure
Any help will be appreciated. Thanks

@GovardhanDo can you post the pod spec for the gateway? it should have a field like
    - name: istio-token
      projected:
        defaultMode: 420
        sources:
        - serviceAccountToken:
            audience: istio-ca
            expirationSeconds: 43200
            path: istio-token

It sounds like its somehow getting the wrong audience set?
Also can you check if you have 1p or 3p jwt enabled? see https://preliminary.istio.io/latest/docs/ops/best-practices/security/#configure-third-party-service-account-tokens

Any updates on this? seems like the tokens created by k8s are not valid

I am also seeing this exact error. My cluster is deployed kops, Kubernetes 1.18.9.
The API server is configured per istio documentation on kops platform
    apiAudiences:
    - api
    - istio-ca
    serviceAccountIssuer: kubernetes.default.svc
    serviceAccountKeyFile:
    - /srv/kubernetes/server.key
    serviceAccountSigningKeyFile: /srv/kubernetes/server.key

Third party JTW tokens are enabled (output from my cluster):
{
  "name": "serviceaccounts/token",
  "singularName": "",
  "namespaced": true,
  "group": "authentication.k8s.io",
  "version": "v1",
  "kind": "TokenRequest",
  "verbs": [
    "create"
  ]
}

I am seeing the same logs serverca logs mentioned in https://github.com/istio/istio/issues/23879
warn	serverca	Authentication failed for <IP_ADDRESS>:34088: Authenticator ClientCertAuthenticator at index 0 got error: no verified chain is found. Authenticator KubeJWTAuthenticator at index 1 got error: failed to validate the JWT: the service account authentication returns an error: [invalid bearer token, square/go-jose: error in cryptographic primitive]. Authenticator ClientCertAuthenticator at index 2 got error: no verified chain is found

The gateway pod spec has the expected istio-token configuration you mentioned in your previous post.
I am going to do some further research and see if I can narrow it down to a configuration issue with the cluster.

After some investigation I was able to get something to work! I haven't dug into why this is causing the JWT authentication failure, but I can show what is happening on the kubeapi configuration side.
Setting this in the kops cluster config:
    apiAudiences:
    - api
    - istio-ca
    serviceAccountIssuer: kubernetes.default.svc
    serviceAccountKeyFile:
    - /srv/kubernetes/server.key
    serviceAccountSigningKeyFile: /srv/kubernetes/server.key

Generates a kube-apiserver configuration with the following arguments
- --api-audiences=api,istio-ca \
- --service-account-issuer=kubernetes.default.svc \
- --service-account-key-file=/src/kubernetes/server.key \
- --service-account-key-file=/srv/kubernetes/service-account.key \
- --service-account-signing-key-file: /src/kubernetes/server.key

Notice, kops appears to be injecting a second --service-account-key-file argument to the apiserver - Multiple files is fine in terms of allowed configuration, however I believe it is the reason for the token failure.
This modification fixed the JWT authentication error
I found that changing the cluster config to:
    apiAudiences:
    - api
    - istio-ca
    serviceAccountIssuer: kubernetes.default.svc
    serviceAccountKeyFile:
    - /srv/kubernetes/service-account.key
    serviceAccountSigningKeyFile: /srv/kubernetes/service-account.key

results in a kube-apiserver argument list of:
- --api-audiences=api,istio-ca \
- --service-account-issuer=kubernetes.default.svc \
- --service-account-key-file=/srv/kubernetes/service-account.key \
- --service-account-key-file=/srv/kubernetes/service-account.key \
- --service-account-signing-key-file: /srv/kubernetes/service-account.key

Notice kops passes two identical --service-account-key-file args
I am inclined to say this is a configuration output bug on kops' side, although I am not sure what the cryptographic implications of the first versus the second configuration are.

@amoskyler We have the same problem with Kops 1.19.0-alpha.5, but your proposed change leads to master nodes not starting up anymore in our setting ☹

We have the same errors on Kops 1.18 when trying to create a second Ingress for eastwest multi-cluster traffic ^^
Ingress won't get ready and Istiod will report this error repeatedly:
2021-01-20T07:00:20.497489Z	error	ads	Failed to authenticate client from <X.X.X.X>:42522
Authenticator ClientCertAuthenticator: no verified chain is found
; Authenticator KubeJWTAuthenticator: could not get cluster <CLUSTER> kube client

We have the same errors on Kops 1.18 when trying to create a second Ingress for eastwest multi-cluster traffic ^^
Ingress won't get ready and Istiod will report this error repeatedly:
2021-01-20T07:00:20.497489Z	error	ads	Failed to authenticate client from <X.X.X.X>:42522
Authenticator ClientCertAuthenticator: no verified chain is found
; Authenticator KubeJWTAuthenticator: could not get cluster <CLUSTER> kube client

Getting similar issue on EKS 1.16 istio 1.18. The same setup works on our GKE cluster
serverca	Authentication failed for <x.x.x.x> :59334: Authenticator ClientCertAuthenticator at index 0 got error: no verified chain is found. Authenticator KubeJWTAuthenticator at index 1 got error: could not get cluster Kubernetes's kube client.

Update @djablonski-moia @amoskyler @hniehus
We got to make this work on Kops 1.19 by set only the following:
    apiAudiences:
    - api
    - istio-ca
    serviceAccountIssuer: kubernetes.default.svc

Let the rest (serviceAccountKeyFile + serviceAccountSigningKeyFile) for the Kops to handle ^^

/reopen

I am having the same issue on Istio 1.8.3 + Kops 1.19.7. Looks like the last comment here fixed the issue. Would have been nice to have some documentation or warning on it.

For posterity, this seems to have been a kOps issue and recently changed in kOps 1.19:

one should not override either serviceAccountKeyFile or serviceAccountSigningKeyFile in kops 1.19+.

The root cause of that change (and why it was changed) is mentioned in this kOps PR.
@dntosas, who made the last comment, had also made a PR to update the relevant kOps docs on this as well as a PR to the Istio docs to update the kOps config section.
The latter made it into the docs for Istio 1.9, but Istio 1.6-1.8's docs have the old config with serviceAccountKeyFile and serviceAccountSigningKeyFile, so if you're wondering where you even got that config from since it's not in the docs currently, it's because it used to be in both the kOps and Istio docs.

Hi, something curious, with istio 1.5 enabling the debug logs in the istio-pilot container solved the issue :man_shrugging:
containers:
    - name: discovery
      image: docker.io/istio/pilot:1.5.2
      args:
        - '--log_output_level=default:debug'

I run into the same situation, but my configuration is slightly different, I'm using istio-csr+ cert-manager+ vault + istio, and I'm also run it on EKS with  cert-manager-istio-csr v0.4.2  istio 1.14.1
istiod
2022-06-24T20:41:04.790540Z	error	klog	grpc-server "msg"="failed to authenticate request" "error"="could not get cluster aws-eu-central1's kube client" "serving-addr"="<IP_ADDRESS>:6443"
istio-proxy
2022-06-24T20:41:11.075081Z	warning	envoy config	StreamSecrets gRPC config stream closed: 2, failed to generate secret for default: failed to generate workload certificate: create certificate: rpc error: code = Unauthenticated desc = request authenticate failure

@jasonhao518 same here, were you able to fix it?

@remidebette  yes, I fix it by using a different solution, just extended istio samples certs a little bit using helm chart, in certs folder, call make to create intermediate certificate for each cluster make $CLUSTER-certs, then deploy the chart to each cluster by providing helm parameter of the cluster, here I'm using "istiod.global.meshID", and I automated this process using argocd. This is only a temporary solution, will come back to cert-manager-istio-csr when it works.
helm chart

certs (copy from https://github.com/istio/istio/tree/istio-1.3/samples/certs)
templates

ca-cert.yaml

ca-cert.yaml
{{-  $certPath := printf "certs/%s/**" .Values.istiod.global.meshID  -}}
apiVersion: v1
kind: Secret
metadata:
name: cacerts
labels:
app: cacerts
stringData:
{{- (.Files.Glob $certPath ).AsConfig | nindent 2 }}


docs: fix typo in lettable operators doc

Description:
Plain typo fix.

Thank you, @devoto13

Coverage remained the same at ?% when pulling 14d9f3f73af30b70b1b24bf0b78b610f7518de44 on devoto13:patch-1 into d24f5b9f77b97c1b17ab7dd4164d3163dcc0f881 on ReactiveX:master.


Automate Windows Subsystem for Linux Installation

Installing Windows Subsystem for Linux is quite a hassle every time one sets up new system.
This includes the following (referrred from the official documentation  by Microsoft):
i. Enabling "Virtual Machine Platform" and "Windows Subsystem for Linux" itself through Deployment Image Servicing and Management Tool (DISM).
ii. Setting WSL 2 as the default version (as it is redundant to have the previous version too).
iii. Installing a Linux distribution from the Windows Store (only handful of them are available, can be asked in a prompt to the user to install).
Automating the above would be great!

This is coming shortly with wsl --install
https://docs.microsoft.com/en-us/windows/wsl/install-win10#simplified-installation-for-windows-insiders


pull request for e2e test at 12/19/2016 18:15:20

:white_check_mark: Validation status: passed
For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.


Puzzle x14193

URL

[ ] Image
[ ] Type
[ ] Defaults
[ ] Connections
[ ] Description

Verified with https://www.youtube.com/watch?v=8GuxK3FrRCE 3:50


Fix insertAll logic when heap is empty

Fixed logic for insertAll into empty heap, added insertAll test cases, fixed parameter order of assertEquals calls in heap tests

Thanks for the contribution - in order for us to merge it, could you please squash these commits and rebase it on top of our master branch and then git push -f to rewrite your history (rather than merging).


Update terra-text usage guide

Summary
Update terra-text usage guide to include information on decorative, supportive and meaningful text attributes.
Thank you for contributing to Terra.
@cerner/terra

@scottwilmarth @supreethmr

As per point 2.2 in the screenshot above(of Scott's comment in my recently closed spike), some information HAS to be conveyed to the users.
Regardless of it being the text style itself or the meaning behind the style, the ask that something has to be conveyed by the screenreader means that there should be a usage of an aria-* attribute or a dummy span that won't be displayed so that this info is conveyed.
So doesn't this warrant a code change to accommodate this new requirement/enhancement/accessibility update.

Can we add an entry to terra-core-docs/CHANGELOG.md to keep track of this change?

@sdadn  it looks like we need to update actions to prevent deploy action from running. This check is not prevent for forked repo's
: https://github.com/cerner/terra-core/blob/ad8fc28ab57875c16bd20b8e24188a3e1470687c/.github/workflows/ci-cd.yml#L67


Basculer vers Postgress managed OVH pour Metabase

:tada: This issue has been resolved in version 1.42.1-rc.1 :tada:
The release is available on:

v1.42.1-rc.1
GitHub release

Your semantic-release bot :package::rocket:


Implement Cryptocurrency list page

add gradle dependencies
implement pallete and color source
implement item layout
implement list fragment and list adapter
implement cryptocurrency list by a fake list


Network-related or instance-specific error on creating new Container with options -useNewDatabase or -useCleanDatabase

When creating a new Container wie New-BCContainer with the parameters useNewDatabase or useCleanDatabase I get the following error:
A network-related or instance-specific error occurred while establishing a connection to SQL Server. The server was not found or was not accessible. Verify that the instance name is correct and that SQL Server is configured to allow remote connections. (provider: Named Pipes Provider, error: 40 - Could not open a connection to SQL Server)
at , : line 7
A network-related or instance-specific error occurred while establishing a connection to SQL Server. The server was not found or was not accessible. Verify that the instance name is correct and that SQL Server is configured to allow remote connections. (provider: Named Pipes Provider, error: 40 - Could not open a connection to SQL Server)
At Z:\Resources\Repository\navcontainerhelper\ContainerHandling\Invoke-ScriptInNavContainer.ps1:37 char:13

        Invoke-Command -Session $session -ScriptBlock $scriptbloc ...

        ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

CategoryInfo          : InvalidOperation: (:) [Invoke-Sqlcmd], SqlException
FullyQualifiedErrorId : SqlExectionError,Microsoft.SqlServer.Management.PowerShell.GetScriptCommand
PSComputerName        : 10e5fc537d175eb87cde2b83659aa5dcceb93468e16898aedad811b89ebcf0ee

shipped in <IP_ADDRESS>


Find a better way to look up whether a project supports Python 3

Currently the XML-RPC API's browse() function is used, but the XML-RPC library is hard on pypi.python.org and not necessarily the fastest thing. I have opened https://github.com/pypa/warehouse/issues/1393 to see if it's possible to have Warehouse provide a caching replacement. If not, though, it's probably better to just check individual projects rather than the overarching request for all Python 3 projects.

Sounds like using requests + JSON API per project being checked is the best solution.

As part of this work, normalizing all project names using packaging.util.canonicalize_name() would be good.


V4 cacheAsBitmap broken in some scenario

I can't find the exact reason just yet...
I'm opening this issue for the time being. Wondering if anyone else is having issues with cacheAsBitmap?
I definitely had an issue with the following snippet. The graphics simply doesn't display.
    _api.addDarkBkg = function (parent, x, y, width, height, alpha) {
      var bkg = new PIXI.Graphics();
      bkg.beginFill(0x000000, alpha);
      bkg.drawRect(0, 0, width, height);
      bkg.endFill();
      bkg.x = x;
      bkg.y = y;
      bkg.cacheAsBitmap = true;

      parent.addChild(bkg);
      return bkg;
    };

But I also this morning had an issue with a container that had cacheAsBitmap set to true.
Trying to find the reason now.

Okay think I found the issue...

I assume this is related to #2642 i.e. Fix localBounds issues.

It is possible that #2654 will fix this.

On it.

@cvissie can you test it on https://dl.dropboxusercontent.com/u/46636530/pixijs/pixi.js ?

    var bounds = this.getLegacyLocalBounds().clone();

^^^
It is now reporting the right values in each of the scenarios i.e. Graphics and Container.

For some reason the Graphics object is still not displaying right despite getting the right bounds...
Will see if I can pin point it.

Also just want to say - this pixi build of yours has also broken the previous Container issue again :cry:
Actually it seems it has broken renderer.generateTexture or rather renderer.render for some reason or another...

I still need a demo.

@ivanpopelyshev
https://dl.dropboxusercontent.com/u/21144013/pixi/examples.7z
Check the cvissie demo.
I actually tested using the latest version in the dev repo of github and the issue we had is resolved.
As it is, it's the most stable version of PIXI v4 we've had.
The only remaining issue is the drawRect cacheAsBitmap that's not working entirely right - that's also in the demo.

should be fixed in v4 👍


Use of Mixins cause atrocious warning/error messages

Example warning message:
In file included from C:/Projects/ColorToolCore/Colors/ColorSpaces.h:4,
                 from C:/Projects/ColorToolCore/Colors/Stats.h:3,
                 from C:/Projects/ColorToolCore/libColorTool.h:3,
                 from C:/Projects/ColorToolCore/examples/invert_colors.cpp:1:
C:/Projects/ColorToolCore/Math/Vector4Mixin.h: In instantiation of 'constexpr Vector4Mixin<T, X, Y, Z, W> operator-(const Vector4Mixin<T, X, Y, Z, W>&, const Vector4Mixin<P, X2, Y2, Z2, W2>&) [with T = WithAlpha<sRGBu8Base, unsigned char>; auto X = &sRGBu8Base::red; auto Y = &sRGBu8Base::green; auto Z = &sRGBu8Base::blue; auto W = &WithAlpha<sRGBu8Base, unsigned char>::alpha; P = WithAlpha<sRGBu8Base, unsigned char>; auto X2 = &sRGBu8Base::red; auto Y2 = &sRGBu8Base::green; auto Z2 = &sRGBu8Base::blue; auto W2 = &WithAlpha<sRGBu8Base, unsigned char>::alpha]':
C:/Projects/ColorToolCore/Filter/Filter.h:12:72:   required from 'void Filter::invert(const ImageIterator<T>&, const ImageIterator<T>&, const ImageIterator<T>&) [with T = Vector4Mixin<WithAlpha<sRGBu8Base, unsigned char>, &sRGBu8Base::red, &sRGBu8Base::green, &sRGBu8Base::blue, &WithAlpha<sRGBu8Base, unsigned char>::alpha>]'
C:/Projects/ColorToolCore/examples/invert_colors.cpp:7:73:   required from here
C:/Projects/ColorToolCore/Math/Vector4Mixin.h:72:14: warning: narrowing conversion of '(((int)(*(((const uint8_t*)(&(& vec)->Vector4Mixin<WithAlpha<sRGBu8Base, unsigned char>, &sRGBu8Base::red, &sRGBu8Base::green, &sRGBu8Base::blue, &WithAlpha<sRGBu8Base, unsigned char>::alpha>::<anonymous>.WithAlpha<sRGBu8Base, unsigned char>::<anonymous>)) + ((sizetype)&sRGBu8Base::red)))) - ((int)(*(((uint8_t*)(& converted.Vector4Mixin<WithAlpha<sRGBu8Base, unsigned char>, &sRGBu8Base::red, &sRGBu8Base::green, &sRGBu8Base::blue, &WithAlpha<sRGBu8Base, unsigned char>::alpha>::<anonymous>.WithAlpha<sRGBu8Base, unsigned char>::<anonymous>)) + ((sizetype)&sRGBu8Base::red)))))' from 'int' to 'Vector4Mixin<WithAlpha<sRGBu8Base, unsigned char>, &sRGBu8Base::red, &sRGBu8Base::green, &sRGBu8Base::blue, &WithAlpha<sRGBu8Base, unsigned char>::alpha>::X_Type' {aka 'unsigned char'} [-Wnarrowing]
   64 | constexpr Vector4Mixin<T, X, Y, Z, W> operator OPER(const Vector4Mixin<T, X, Y, Z, W>& vec, const Vector4Mixin<P, X2, Y2, Z2, W2>& other){ Vector4Mixin<T, X, Y, Z, W> converted(other); return {vec.*X OPER converted.*X, vec.*Y OPER converted.*Y, vec.*Z OPER converted.*Z, vec.*W OPER converted.*W}; }\
      |
                ~~~~~~~~~~~~~~~~~~~~~~~~

In this case code generation might actually be more appropriate, could be a Macro that expands to the class declaration, but using an external preprocessor could be even better (python script?). Code generation could also lead to better vectorization (needs to be tested).

With Macros the syntax could be
struct Vector3
{
  float x;
  float y;
  float z;

  // Vector 3 constructors, comparison operator, negation operator, length functions, visit and foreach functions
  VECTORIZE3_MEMBER_FUNCTIONS(x, y, z);
}

// Arithmetic operators
VECTORIZE3_OPERATORS(Vector3, x, y, z);

This can then be expanded using gcc -E filename.h
This would also open the doors for having a separate .cpp file for the implementation, but I think having the functions inlined & constexpr is necessary for the compiler to properly optimize the Vectors.


0.10.1 - error when find is called inside onunrender

Description:
When find is called inside the onunrender lifecycle event, produces an error when the instance is not rendered.
This used to work fine in 0.9.13.
To resolve this I have added a guard inside the onunrender lifecycle event to check if the instance is rendered.
I think that this is either a) a breaking change b) a bug in 0.10.1 or c) a bug in 0.9.
Versions affected:
0.10.1
Platforms affected:
All Browsers
Reproduction:
Playground

I think this may be more an issue with lifecycle events and find. Technically, that findAll in 0.9.13 will never find anything because the instance is never rendered in unrender, and it should probably also throw there as it would in any other instance where you try to find DOM nodes in an un-rendered instance. 0.10.1 just added better rendered tracking.
This has actually cropped up for the other lifecycle events as well over the years - when x event fires is it before, during, or after x, and if during, what does that mean? Unrender is probably the most sensitive for this case exactly - the instance is about to be removed from the DOM and you need to do some cleanup before that happens. There should probably be an unmount or unrendering or something along those lines to handle that.
From the find and findAll side, I don't know that throwing is necessarily the best approach there, but them I'm not as big a fan of "fail early, fail hard" on things like that. I think a warning and just returning undefined and [], respectively, would suffice. If the instance is torn down, that would be a reason to throw.

Ok @evs-chris so this is basically more of an issue of the 0.9.x version if I understand correctly.
I don't think another lifecycle event is needed, as long as unrender fires before DOM destruction I think it's ok to put any cleanup logic (unregistering custom events etc) in there.
I always put cleanup logic in onunrender instead of onteardown, I hope that is the correct way to handle it.

After thinking on it a bit, adding an unrendering event as a top-down is non-breaking and doesn't add too much overhead. There are legit usecases for both sides of the unrender event, so I think this is the best solution. If you need to clean up externally managed DOM stuff from a component, unrendering is the event you'll want from 0.10.2. Thanks for the report!

Thank you @evs-chris , so unrender event must not be used for cleanup?

unrender can be used for component cleanup, like dropping listeners and cancelling observers, but if you need to do DOM stuff, like tear down integrations with third party libs that were set up in render, then unrendering is the place for that. Of course, you can also do event/observer cleanup there too.

Ok @evs-chris I think I got it, thank you once again.


Crash with flora disabled

Setting enableFlora to false will crash you when TC looks up aspects (like when you're hovering over a item and press shift, for example).
https://gist.github.com/doushio9967/fe44e76f7e661b472ba6ef40a8b7299a
TB 1.4.1710-2 / DC 2.0.1710.0A

Should be fixed now


Exception while resuming training: assert isinstance(step, list) and len(step) >= 1 AssertionError

Hello,
I need to resume training but getting following exception:
File "experiments/fpn/../../fpn/../lib/utils/lr_scheduler.py", line 29, in init
assert isinstance(step, list) and len(step) >= 1
AssertionError
I have made following changes in .yaml file:
begin_epoch: 76
end_epoch: 100
Any help will be much appreciated.
Thanks

The issue begins in the lr_step field in the config file.
lr: 0.0005
lr_step: '4.83'
warmup: true
warmup_lr: 0.00005
# typically we will use 4000 warmup step for single GPU on VOC
warmup_step: 1000

In the call to get the learning rate scheduler:
    # decide learning rate
    base_lr = lr
    lr_factor = config.TRAIN.lr_factor
    lr_epoch = [float(epoch) for epoch in lr_step.split(',')]
    lr_epoch_diff = [epoch - begin_epoch for epoch in lr_epoch if epoch > begin_epoch]
    lr = base_lr * (lr_factor ** (len(lr_epoch) - len(lr_epoch_diff)))
    lr_iters = [int(epoch * len(roidb) / batch_size) for epoch in lr_epoch_diff]
    print('lr', lr, 'lr_epoch_diff', lr_epoch_diff, 'lr_iters', lr_iters)
    lr_scheduler = WarmupMultiFactorScheduler(lr_iters, lr_factor, config.TRAIN.warmup,
    config.TRAIN.warmup_lr, config.TRAIN.warmup_step)

Note that steps in your error call is lr_iters, if you follow the logic here you will see that lr_epoch=[4.83] and this means the  lr_epoch_diff = [epoch - begin_epoch for epoch in lr_epoch if epoch > begin_epoch] is an empty list because the if will never be satisfied if begin_epoch > lr_step.
I don't have a fix for this. I'd be happy for more action here, its a pretty serious flaw.


start hosting website on IPFS node

This issues was dropped from the list due to lack of team consensus on the importance/need of the described feature


Support for Emoji 13.1

This PR will bring the library up to date with emoji-data 7.0.2, supporting Emoji 13.1

Coverage decreased (-2.9%) to 86.643% when pulling 907911a181564fd07ed16cbf37cc5ecb83a8dbb7 on emoji13.1 into 40916bb7343321e98004de03f2d35bcece9636ce on master.


Applying suggestions for improvement on string repr of special index

Description
Please include a short summary of the change.
Thanks @jonathanberthias for the suggestions!
Issue link (if applicable):
Type of change

[x] New feature (backwards compatible)
[ ] New feature (breaking API changes)
[ ] Bug fix
[ ] Other (Documentation, CI, ...)

Contribution checklist

[x] Add our license to new files.
[x] Check that your code adheres to our coding style.
[x] Write unittests.
[x] Run the unittests and check that they’re passing.
[x] Run the benchmarks to make sure your change doesn’t introduce a regression.

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.William Zijie Zhang seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.You have signed the CLA already but the status is still pending? Let us recheck it.


a misspelling bug in istio/samples/bookinfo

#######there is a misspelling bug in istio/samples/bookinfo
(NOTE: This is used to report product bugs:
To report a security vulnerability, please visit https://istio.io/about/security-vulnerabilities
To ask questions about how to use Istio, please visit https://discuss.istio.io)
Bug description
Affected product area (please put an X in all that apply)
[ ] Docs
[ ] Installation
[ ] Networking
[ ] Performance and Scalability
[ ] Extensions and Telemetry
[ ] Security
[ ] Test and Release
[ ] User Experience
[ ] Developer Infrastructure
[ ] Upgrade
Affected features (please put an X in all that apply)
[ ] Multi Cluster
[ ] Virtual Machine
[ ] Multi Control Plane
Expected behavior
Steps to reproduce the bug
Version (include the output of istioctl version --remote and kubectl version --short and helm version --short if you used Helm)
How was Istio installed?
Environment where the bug was observed (cloud vendor, OS, etc)
Additionally, please consider running istioctl bug-report and attach the generated cluster-state tarball to this issue.
Refer cluster state archive for more details.

Fixed in https://github.com/istio/istio/pull/33279


MA-742 MA-743 Switch between video and full mode.

JIRA: https://openedx.atlassian.net/browse/MA-743
https://openedx.atlassian.net/browse/MA-744

@hanningni please review

:+1:


Are Weave's control and data ports configurable?

Hello,
I have a question. If I am not mistaken, Weave uses port TCP 6783 for control and ports UDP 6783/6784 for data. I am currently running Weave in an environment where these ports are NOT opened. I would like to know if there is a way to configure Weave to use another ports as alternatives.
Thank you in advance!

Set WEAVE_PORT, as described in our docs.

Thank you for your support.