[HOLD for payment 2024-12-07] [$250] Distance - Rate on confirmation page shows 3 decimal value for a 4-digit decimal value rate

If you haven’t already, check out our contributing guidelines for onboarding and email<EMAIL_ADDRESS>to request to join our Slack channel!

Version Number: 9.0.41-2
Reproducible in staging?: Y
Reproducible in production?: Y
If this was caught during regression testing, add the test name, ID and link from TestRail: N/A
Email or phone of affected tester (no customers<EMAIL_ADDRESS>Issue reported by: Applause - Internal Team
Action Performed:

Go to staging.new.expensify.com
Go to workspace settings > Distance rates
Click on any distance rate
Change the distance rate to 4-digit decimal value (non-zero) and save it
Go to workspace chat
Click + > Submit expense > Distance
Enter waypoints and proceed to confirmation page
Click Rate
Select the 4-digit decimal value rate in Step 4
Note that the rate list only shows 3 decimal value instead of 4
Submit the distance expense
Go to transaction thread and open the receipt
Note that the expense preview and distance receipt shows the complete rate which is 4-digit decimal value

Expected Result:
In Step 10, the rate list should show the complete decimal value (eg, 1.2345)
Actual Result:
In Step 10, the rate list only shows 3 decimal value (eg, 1.234)
In Step 13, the expense preview and distance receipt shows 4 decimal value which is the complete rate (eg, 1.2345)
The rate format is not consistent in the rate list and distance receipt
Workaround:
Unknown
Platforms:

Which of our officially supported platforms is this issue occurring on?

[x] Android: Native
[x] Android: mWeb Chrome
[x] iOS: Native
[x] iOS: mWeb Safari
[x] MacOS: Chrome / Safari
[x] MacOS: Desktop

Screenshots/Videos
Add any screenshot/video evidence

https://github.com/user-attachments/assets/5e3c5ab5-93de-46b4-b012-47cb78559ad3
View all open jobs on GitHub
Upwork Automation - Do Not Edit

Upwork Job URL: https://www.upwork.com/jobs/~021841311378926667676
Upwork Job ID:<PHONE_NUMBER>926667676
Last Price Increase: 2024-10-09
Automatic offers:

allgandalf | Contributor | 104470034

Issue OwnerCurrent Issue Owner: @kadiealexander / @kadiealexander
Issue OwnerCurrent Issue Owner: @puneetlath / @kadiealexander

Proposal
Please re-state the problem that we are trying to solve in this issue.
Distance - Rate on confirmation page shows 3 decimal value for a 4-digit decimal value rate
What is the root cause of that problem?
Right here the Rate Decimal for displaying Rate is 3 which is wrong
https://github.com/Expensify/App/blob/0e3b82cc9d5e5425bf7dae5652538fdb494c7799/src/CONST.ts#L2402
And same here
https://github.com/Expensify/App/blob/decf5154ec7b08722d98e4c9124bfe673d30d405/src/libs/PolicyUtils.ts#L148
What changes do you think we should make in order to solve the problem?
We should change it to 4
Result
https://github.com/user-attachments/assets/a4f42c68-c603-4b63-bec2-5a33f1131b13
What alternative solutions did you explore? (Optional)

Proposal
Please re-state the problem that we are trying to solve in this issue.
We have an inconsistency in the number of decimal places for the distance rate.
What is the root cause of that problem?
In this PR https://github.com/Expensify/App/pull/49773, we decided to always display 4 decimals for all currencies. But we haven't updated this function getRateDisplayValue function.
What changes do you think we should make in order to solve the problem?
Update to display 4 decimals
https://github.com/Expensify/App/blob/69483ff0ef36e39fbf40c15f2caa3471dccbef17/src/libs/PolicyUtils.ts#L149
        return Number(numValue).toFixed(CONST.MAX_TAX_RATE_DECIMAL_PLACES).toString().replace('.', toLocaleDigit('.'));

https://github.com/Expensify/App/blob/69483ff0ef36e39fbf40c15f2caa3471dccbef17/src/libs/PolicyUtils.ts#L122
       return numValue.toFixed(CONST.MAX_TAX_RATE_DECIMAL_PLACES);

I see one more edge case when rate is 166.9800 (There are some zeros in the end), should we display zeros? Currently, we also display inconsistency in this case

If yes, (we need to update how we display rates in the money request flow)

https://github.com/Expensify/App/blob/69483ff0ef36e39fbf40c15f2caa3471dccbef17/src/libs/PolicyUtils.ts#L152
Remove .substring(0, value.toString().length);

If no, (we need to update how we display rates distance rate page)

https://github.com/Expensify/App/blob/69483ff0ef36e39fbf40c15f2caa3471dccbef17/src/libs/CurrencyUtils.ts#L167
        minimumFractionDigits: 2,
        maximumFractionDigits: 4,

Another problem in the update rate message, the rate only display 2 decimals. But this data is get from originalMessage. If we want to update it, we need to fix on the BE side or make a workaround on FE (detail later if needed)

What alternative solutions did you explore? (Optional)

Contributor details
Your Expensify account email<EMAIL_ADDRESS>Upwork Profile Link: https://www.upwork.com/freelancers/~011321051436417521

Contributor details
Your Expensify account email<EMAIL_ADDRESS>Upwork Profile Link: https://www.upwork.com/freelancers/~011321051436417521

@parasharrajat Hmm, In https://github.com/Expensify/App/pull/49773, we decided to mirror the Olddot behavior and always use a 4-digit decimal on the rate value.
About this bug, I think this is a new requirement for the update distance rate on the request money flow to use of 4-digit decimals, because this issue also happens on the Olddot
https://github.com/user-attachments/assets/1d144d86-8e44-47fe-92e0-644a94b552cc

I just glanced at proposals and noticed that @thelullabyy mentioned a valuable point

I see one more edge case when rate is 166.9800 (There are some zeros in the end), should we display zeros? Currently, we also display inconsistency in this case

Proposal
Please re-state the problem that we are trying to solve in this issue.
Rate on confirmation page shows 3 decimal value for a 4-digit decimal value rate
What is the root cause of that problem?

On this PR https://github.com/Expensify/App/pull/49773#issue-2549802815 we decided to use 4 decimal digits for distance rate(irrespective of currency)
We need some additional tough up for the change.

What changes do you think we should make in order to solve the problem?

First update RATE_DECIMALS: 4
https://github.com/Expensify/App/blob/99f280b0edae75ff59614a1c5e98c47b39800aa5/src/CONST.ts#L2411
Now update fixedDecimalPoints logic here, based on if we want to hide appending zeroes or not.
https://github.com/Expensify/App/blob/99f280b0edae75ff59614a1c5e98c47b39800aa5/src/libs/PolicyUtils.ts#L149
An additional problem we face after such update is for currency which do not support decimals.(ex. ALL)

check this video
parameter: currency- ALL, rate-0.6799, distance-74.59mil, from New York to New Jersey.
https://github.com/user-attachments/assets/c54cbe01-0385-498a-9baf-1ef5cb53f896

When we display amount on report page we roundoff the amount according to currency. but when we try to edit the amount, edit amount page actually rips off the digits after decimal points for currencies which do not support decimals. which causes inconsistency between amount displayed on report page and amount displayed on edit amount page.

To solve this problem we need to start rounding off amount on IOUStepAmount instead of ripping of the digits after decimal point.
        setNewAmount(Number(currentAmount).toFixed());

https://github.com/Expensify/App/blob/99f280b0edae75ff59614a1c5e98c47b39800aa5/src/components/MoneyRequestAmountInput.tsx#L236
And some cleanup.
What alternative solutions did you explore? (Optional)
Reminder: Please use plain English, be brief and avoid jargon. Feel free to use images, charts or pseudo-code if necessary. Do not post large multi-line diffs or write walls of text. Do not create PRs unless you have been hired for this job.

@parasharrajat bump on the reviews!

@parasharrajat
here in my Proposal I have mentioned an additional problem which will arise afterwards , If you think that issue is out of scope here, then we could raise a new issue for the same. Otherwise I request you to assign this issue to me or at least let me and @thelullabyy work here collaboratively.
cc. @puneetlath

@thelullabyy could you please provide an update here? Thank you!

@thelullabyy I'll open a PR soon.

@kadiealexander I'll open a PR soon.

@parasharrajat This PR is ready for review.

@allgandalf are you ok with splitting the C+ bounty since @parasharrajat already did the proposal review? If so, please go ahead.

@allgandalf I'll open the PR today.

@allgandalf PR is ready for review.

Payments due (50% reduction due to regression):

[ ] Contributor: @thelullabyy paid $125 via Upwork (please apply!)
[ ] Reviewer: @parasharrajat owed $62.50 via manual request (agreed to split here)
[ ] Reviewer: @allgandalf owed $62.50 via Upwork (offer) (agreed to split here)

@allgandalf or @parasharrajat please complete the checklist!

$62.50 approved for @parasharrajat

@parasharrajat @allgandalf please complete the checklist!

@parasharrajat @allgandalf @thelullabyy bump on the above please.

@kadiealexander Is it possible to send the offer to me? https://www.upwork.com/freelancers/~011321051436417521
Upwork requires Connects to apply which I don't have any.
Thank you in advance.

I've sent offers to @thelullabyy and @allgandalf, please let me know when you've accepted.

@kadiealexander I'm done too, thx


MapView onPress triggered on double tap on iOS, not on Android

The onPress event is fired on iOS (3 times, ala #1675) when the map is double tapped.
On Android, the onPress event is not fired on double tap.
I'd expect to have them behave the same way.
Either have an onDoubleTap prop or for it not to fire on double tap so we can rely on the zoom feature without activating our tap functions.

Could you fill your issue according to the new issue template please, so we'll reopen and review


Cards layout and click to copy

TODO:

Add cards layout
Click to copy text

Is this deployed somewhere?

Is this deployed somewhere?

No, we have registered this project as an idea here. If you want to contribute, I'd recommend submitting a PR in one of these projects. Happy coding :)


Provide additional documentation details for the OpenAI demo key

Change
While using the OpenAI demo API key as described in the documentation here, I encountered two unexpected errors. Consequently, I've updated the documentation.

dev.ai4j.openai4j.OpenAiHttpException: Maximum number of tokens per request for demonstration purposes is 5000. If you wish to use more, please use your own OpenAI API key.

dev.ai4j.openai4j.OpenAiHttpException: Only gpt-4o-mini model is available for demonstration purposes. If you wish to use another model, please use your own OpenAI API key.

General checklist

[X] There are no breaking changes
[ ] I have added unit and integration tests for my change
[ ] I have manually run all the unit and integration tests in the module I have added/changed, and they are all green
[ ] I have manually run all the unit and integration tests in the core and main modules, and they are all green

[ X] I have added/updated the documentation
[ ] I have added an example in the examples repo (only for "big" features)
[ ] I have added/updated Spring Boot starter(s) (if applicable)

Checklist for adding new maven module

[ ] I have added my new module in the root pom.xml and langchain4j-bom/pom.xml

Checklist for adding new embedding store integration

[ ] I have added a {NameOfIntegration}EmbeddingStoreIT that extends from either EmbeddingStoreIT or EmbeddingStoreWithFilteringIT
[ ] I have added a {NameOfIntegration}EmbeddingStoreRemovalIT that extends from EmbeddingStoreWithRemovalIT

Checklist for changing existing embedding store integration

[ ] I have manually verified that the {NameOfIntegration}EmbeddingStore works correctly with the data persisted using the latest released version of LangChain4j

@arey thank you!
I did not document quotas on purpose to not "advertise" free tokens.
But perharps we could indeed explicitly mention model name

Ok @langchain4j , I'm understanding. I've just removed quota details.


https://localhost:8080/api  giving error in Hygieia-jenkins plugin configuration

I am trying to set up the Hygieia-Jenkins plugin but
Manage Jenkins > Configure System > Hygieia Publisher Settings
Hygieia Server URL is http://localhost:8080/api/ is giving failure on "Test Connection".
I have set the Proxy settings.
When we hit this https://localhost:8080/api in browser getting the following error.
"Whitelabel Error Page
This application has no explicit mapping for /error, so you are seeing this as a fallback.
Thu Nov 02 09:20:02 EDT 2017
There was an unexpected error (type=Not Found, status=404).
No message available"
Can you please help here.
Thanks in advance.

@ameetsvshah  remove "/" at the end, use http://localhost:8080/api

@ameetsvshah Please reopen if you are still having issues.

I am facing similar issue, api log says connected to mongodb on port 27017, but localhost:8090/api/ping doesn't return true and give me a whitelabel error message page.
UI says red on api connectivity. It was working well earlier suddenly it isnt working, Can someone please help me with this/if any faced same ??

@nireeshT,@tabladrum - I am facing issue in API - UI connectivity. API instance is running and am getting the response (response as true) when I hit http://localhost:8081/api/ping. I have deployed UI via gulp serve command and in the UI page its showing as no API connectivity. When I try to hit http://localhost:8081/api/dashboard, am getting empty json. From the API logs, I saw it has established connection to mongodb successfully. Can you help me to sort out this?
I have built the entire project successfully that I have cloned from GitHub. Mongodb,npm,bower installation  -> successful. No error message in api log.
GET method http://localhost:8081/api/authenticationProviders & http://localhost:8081/api/appinfo returns 404 page not found response


Warning new node with same name

I had the problem that some files were missing after installing ROS. After I installed the missing Packages I get the warning:
[ WARN] [1561983642.247397802]: Shutdown request received.
[ WARN] [1561983642.247547924]: Reason given for shutdown: [new node registered with same name]
Ros seems to be running fine. At least now i can launch the demo file. Do I need to take care of it?
And is there anyway of knowing what is installed twice?

I think i might have opened 2 Rviz windows that might have caused this Problem. After restarting it works


[BUG] Unable to finish install or upgrade when Failed to list *v1beta2.Node: v1beta2.NodeList.Items

Describe the bug
This happens when Backing Image's disk status is empty.
spec:
  disks:
    1e3408a7-3318-4244-ba28-7c4cdc302add: {}
    b16a8aa2-63d8-452f-baf5-eded5a2525e7: {}
    c192b677-fd0d-42e1-9021-78ea70904daf: {}

To Reproduce
There is no specific steps but possible one:

Fresh install v1.1.3

Create backing image

Upgrade to master-head before the first backing image download finishes

See error

Expected behavior
Not sure what would be a better behavior to expect here, but since longhorn-manager pods are still waiting for longhorn-admission-webhook pods, user won't able to do much at this point.
Log or Support bundle
Expand to see the logs.

longhorn-admission-webhook:

longhorn-admission-webhook 2022/02/19 03:44:29 proto: duplicate proto type registered: VersionResponse
longhorn-admission-webhook time="2022-02-19T03:44:29Z" level=info msg="Starting longhorn admission webhook server"
longhorn-admission-webhook W0219 03:44:29.462537       1 client_config.go:552] Neither --kubeconfig nor --master was specified.  Using the inClusterConfig.  This might not work.
longhorn-admission-webhook I0219 03:44:29.465992       1 shared_informer.go:223] Waiting for caches to sync for longhorn datastore
longhorn-admission-webhook E0219 03:44:30.478473       1 reflector.go:178] github.com/longhorn/longhorn-manager/k8s/pkg/client/informers/externalversions/factory.go:117: Failed to list *v1beta2.BackingImage: v1beta2.BackingImageList.Items: []v1beta2.BackingImage: v1beta2.BackingImage.Spec: v1beta2.BackingImageSpec.Disks: ReadString: expects " or n, but found {, error found in #10 byte of ...|c302add":{},"b16a8aa|..., bigger context ...|{"disks":{"1e3408a7-3318-4244-ba28-7c4cdc302add":{},"b16a8aa2-63d8-452f-baf5-eded5a2525e7":{},"c192b|...
longhorn-admission-webhook E0219 03:44:31.734882       1 reflector.go:178] github.com/longhorn/longhorn-manager/k8s/pkg/client/informers/externalversions/factory.go:117: Failed to list *v1beta2.BackingImage: v1beta2.BackingImageList.Items: []v1beta2.BackingImage: v1beta2.BackingImage.Spec: v1beta2.BackingImageSpec.Disks: ReadString: expects " or n, but found {, error found in #10 byte of ...|c302add":{},"b16a8aa|..., bigger context ...|{"disks":{"1e3408a7-3318-4244-ba28-7c4cdc302add":{},"b16a8aa2-63d8-452f-baf5-eded5a2525e7":{},"c192b|...
longhorn-admission-webhook E0219 03:44:34.519957       1 reflector.go:178] github.com/longhorn/longhorn-manager/k8s/pkg/client/informers/externalversions/factory.go:117: Failed to list *v1beta2.BackingImage: v1beta2.BackingImageList.Items: []v1beta2.BackingImage: v1beta2.BackingImage.Spec: v1beta2.BackingImageSpec.Disks: ReadString: expects " or n, but found {, error found in #10 byte of ...|c302add":{},"b16a8aa|..., bigger context ...|{"disks":{"1e3408a7-3318-4244-ba28-7c4cdc302add":{},"b16a8aa2-63d8-452f-baf5-eded5a2525e7":{},"c192b|...
longhorn-admission-webhook E0219 03:44:39.318892       1 reflector.go:178] github.com/longhorn/longhorn-manager/k8s/pkg/client/informers/externalversions/factory.go:117: Failed to list *v1beta2.BackingImage: v1beta2.BackingImageList.Items: []v1beta2.BackingImage: v1beta2.BackingImage.Spec: v1beta2.BackingImageSpec.Disks: ReadString: expects " or n, but found {, error found in #10 byte of ...|c302add":{},"b16a8aa|..., bigger context ...|{"disks":{"1e3408a7-3318-4244-ba28-7c4cdc302add":{},"b16a8aa2-63d8-452f-baf5-eded5a2525e7":{},"c192b|...
longhorn-admission-webhook E0219 03:44:47.517024       1 reflector.go:178] github.com/longhorn/longhorn-manager/k8s/pkg/client/informers/externalversions/factory.go:117: Failed to list *v1beta2.BackingImage: v1beta2.BackingImageList.Items: []v1beta2.BackingImage: v1beta2.BackingImage.Spec: v1beta2.BackingImageSpec.Disks: ReadString: expects " or n, but found {, error found in #10 byte of ...|c302add":{},"b16a8aa|..., bigger context ...|{"disks":{"1e3408a7-3318-4244-ba28-7c4cdc302add":{},"b16a8aa2-63d8-452f-baf5-eded5a2525e7":{},"c192b|...
longhorn-admission-webhook E0219 03:45:00.984511       1 reflector.go:178] github.com/longhorn/longhorn-manager/k8s/pkg/client/informers/externalversions/factory.go:117: Failed to list *v1beta2.BackingImage: v1beta2.BackingImageList.Items: []v1beta2.BackingImage: v1beta2.BackingImage.Spec: v1beta2.BackingImageSpec.Disks: ReadString: expects " or n, but found {, error found in #10 byte of ...|c302add":{},"b16a8aa|..., bigger context ...|{"disks":{"1e3408a7-3318-4244-ba28-7c4cdc302add":{},"b16a8aa2-63d8-452f-baf5-eded5a2525e7":{},"c192b|...
longhorn-admission-webhook E0219 03:45:47.355421       1 reflector.go:178] github.com/longhorn/longhorn-manager/k8s/pkg/client/informers/externalversions/factory.go:117: Failed to list *v1beta2.BackingImage: v1beta2.BackingImageList.Items: []v1beta2.BackingImage: v1beta2.BackingImage.Spec: v1beta2.BackingImageSpec.Disks: ReadString: expects " or n, but found {, error found in #10 byte of ...|c302add":{},"b16a8aa|..., bigger context ...|{"disks":{"1e3408a7-3318-4244-ba28-7c4cdc302add":{},"b16a8aa2-63d8-452f-baf5-eded5a2525e7":{},"c192b|...
longhorn-admission-webhook E0219 03:46:40.122238       1 reflector.go:178] github.com/longhorn/longhorn-manager/k8s/pkg/client/informers/externalversions/factory.go:117: Failed to list *v1beta2.BackingImage: v1beta2.BackingImageList.Items: []v1beta2.BackingImage: v1beta2.BackingImage.Spec: v1beta2.BackingImageSpec.Disks: ReadString: expects " or n, but found {, error found in #10 byte of ...|c302add":{},"b16a8aa|..., bigger context ...|{"disks":{"1e3408a7-3318-4244-ba28-7c4cdc302add":{},"b16a8aa2-63d8-452f-baf5-eded5a2525e7":{},"c192b|...
Stream closed EOF for longhorn-system/longhorn-admission-webhook-57c4747b5d-phh8n (wait-longhorn-conversion-webhook)

longhorn-conversion-webhook:

2022/02/19 03:44:09 proto: duplicate proto type registered: VersionResponse
time="2022-02-19T03:44:09Z" level=info msg="Starting longhorn conversion webhook server"
W0219 03:44:09.498153       1 client_config.go:552] Neither --kubeconfig nor --master was specified.  Using the inClusterConfig.  This might not work.
time="2022-02-19T03:44:09Z" level=warning msg="Failed to init Kubernetes secret: secrets \"longhorn-webhook-tls\" not found"
time="2022-02-19T03:44:09Z" level=info msg="generated self-signed CA certificate CN=dynamiclistener-ca,O=dynamiclistener-org: notBefore=2022-02-19 03:44:09.537432722 +0000 UTC notAfter=2032-02-17 03:44:09.537432722 +0000 UTC"
time="2022-02-19T03:44:09Z" level=info msg="Listening on :9443"
time="2022-02-19T03:44:09Z" level=info msg="certificate CN=dynamic,O=dynamic signed by CN=dynamiclistener-ca,O=dynamiclistener-org: notBefore=2022-02-19 03:44:09 +0000 UTC notAfter=2023-02-19 03:44:09 +0000 UTC"
time="2022-02-19T03:44:09Z" level=info msg="Creating new TLS secret for longhorn-webhook-tls (count: 1): map[listener.cattle.io/cn-longhorn-conversion-webhook.longho-6a0089:longhorn-conversion-webhook.longhorn-system.svc listener.cattle.io/fingerprint:SHA1=AD6C82905AA34BFEF2E984609A95E98FCEAAB468]"
time="2022-02-19T03:44:09Z" level=info msg="Active TLS secret longhorn-webhook-tls (ver=4924) (count 1): map[listener.cattle.io/cn-longhorn-conversion-webhook.longho-6a0089:longhorn-conversion-webhook.longhorn-system.svc listener.cattle.io/fingerprint:SHA1=AD6C82905AA34BFEF2E984609A95E98FCEAAB468]"
time="2022-02-19T03:44:10Z" level=info msg="Starting /v1, Kind=Secret controller"
time="2022-02-19T03:44:10Z" level=info msg="Starting apiextensions.k8s.io/v1, Kind=CustomResourceDefinition controller"
time="2022-02-19T03:44:10Z" level=info msg="Building conversion rules..."
time="2022-02-19T03:44:10Z" level=info msg="Starting apiregistration.k8s.io/v1, Kind=APIService controller"
time="2022-02-19T03:44:10Z" level=info msg="Updating TLS secret for longhorn-webhook-tls (count: 1): map[listener.cattle.io/cn-longhorn-conversion-webhook.longho-6a0089:longhorn-conversion-webhook.longhorn-system.svc listener.cattle.io/fingerprint:SHA1=AD6C82905AA34BFEF2E984609A95E98FCEAAB468]"
time="2022-02-19T03:44:10Z" level=info msg="Update CRD for backingimages.longhorn.io"
time="2022-02-19T03:44:10Z" level=info msg="Update CRD for backuptargets.longhorn.io"
time="2022-02-19T03:44:10Z" level=info msg="Update CRD for engineimages.longhorn.io"
time="2022-02-19T03:44:10Z" level=info msg="Update CRD for nodes.longhorn.io"
time="2022-02-19T03:44:10Z" level=info msg="Update CRD for volumes.longhorn.io"
time="2022-02-19T03:44:11Z" level=error msg="error decoding src object" error="v1beta2.BackingImage.Spec: v1beta2.BackingImageSpec.Disks: ReadString: expects \" or n, but found {, error found in #10 byte of ...|c302add\":{},\"b16a8aa|..., bigger context ...|{\"disks\":{\"1e3408a7-3318-4244-ba28-7c4cdc302add\":{},\"b16a8aa2-63d8-452f-baf5-eded5a2525e7\":{},\"c192b|..."
time="2022-02-19T03:44:12Z" level=error msg="error decoding src object" error="v1beta2.BackingImage.Spec: v1beta2.BackingImageSpec.Disks: ReadString: expects \" or n, but found {, error found in #10 byte of ...|c302add\":{},\"b16a8aa|..., bigger context ...|{\"disks\":{\"1e3408a7-3318-4244-ba28-7c4cdc302add\":{},\"b16a8aa2-63d8-452f-baf5-eded5a2525e7\":{},\"c192b|..."
time="2022-02-19T03:44:13Z" level=error msg="error decoding src object" error="v1beta2.BackingImage.Spec: v1beta2.BackingImageSpec.Disks: ReadString: expects \" or n, but found {, error found in #10 byte of ...|c302add\":{},\"b16a8aa|..., bigger context ...|{\"disks\":{\"1e3408a7-3318-4244-ba28-7c4cdc302add\":{},\"b16a8aa2-63d8-452f-baf5-eded5a2525e7\":{},\"c192b|..."
time="2022-02-19T03:44:14Z" level=error msg="error decoding src object" error="v1beta2.BackingImage.Spec: v1beta2.BackingImageSpec.Disks: ReadString: expects \" or n, but found {, error found in #10 byte of ...|c302add\":{},\"b16a8aa|..., bigger context ...|{\"disks\":{\"1e3408a7-3318-4244-ba28-7c4cdc302add\":{},\"b16a8aa2-63d8-452f-baf5-eded5a2525e7\":{},\"c192b|..."

Environment

Longhorn version: v1.1.3 -> master-head
Installation method (e.g. Rancher Catalog App/Helm/Kubectl): kubectl
Kubernetes distro (e.g. RKE/K3s/EKS/OpenShift) and version: 1.19 k3s

Number of management node in the cluster: 1
Number of worker node in the cluster: 3

Underlying Infrastructure (e.g. on AWS/GCE, EKS/GKE, VMWare/KVM, Baremetal): local vm

Additional context
Can be also reproduced on Kubernetes v1.21

@kaxing Always reproducible?

@derekbit the abnormal resource is the backing image. And yes, if the backing image downloading is not finished before upgrading process, I can reproduce this consistently.

@derekbit the abnormal resource is the backing image. And yes, if the backing image downloading is not finished before upgrading process, I can reproduce this consistently.

Do you mean doing the upgrade during a backing image downloading?

@innobead yes, when the backing-image-manager pods are still downloading the image and there is no ready(downloaded) image in the status the upgrade conversion will become error:

time="2022-02-18T07:20:36Z" level=info msg="Backing Image Manager listening to <IP_ADDRESS>:8000"
time="2022-02-18T07:20:41Z" level=info msg="Backing Image Manager: prepare to start backing image update watch" component=backing-image-manager diskPathOnHost=/var/lib/longhorn/
time="2022-02-18T07:20:41Z" level=info msg="Backing Image Manager: backing image update watch started" component=backing-image-manager diskPathOnHost=/var/lib/longhorn/
time="2022-02-18T07:20:41Z" level=info msg="Backing Image Manager: prepare to pull backing image" URL="https://github.com/rancher/k3os/releases/download/v0.11.0/k3os-amd64.iso" backingImage=bi-v113 component=backing-image-manager diskPathOnHost=/var/lib/longhorn/
time="2022-02-18T07:20:41Z" level=info msg="Backing Image: start to pull backing image" component=backing-image hostDir=/var/lib/longhorn/backing-images/bi-v113-bd0e0c14 name=bi-v113 url="https://github.com/rancher/k3os/releases/download/v0.11.0/k3os-amd64.iso" uuid=bd0e0c14 workDir=/data/backing-images/bi-v113-bd0e0c14
time="2022-02-18T07:20:41Z" level=info msg="Backing Image: failed to try to check or reuse the possible existing backing image file, will start pulling then: stat /data/backing-images/bi-v113-bd0e0c14/backing: no such file or directory" component=backing-image hostDir=/var/lib/longhorn/backing-images/bi-v113-bd0e0c14 name=bi-v113 url="https://github.com/rancher/k3os/releases/download/v0.11.0/k3os-amd64.iso" uuid=bd0e0c14 workDir=/data/backing-images/bi-v113-bd0e0c14
time="2022-02-18T07:20:44Z" level=info msg="Backing Image: pulling backing image" component=backing-image hostDir=/var/lib/longhorn/backing-images/bi-v113-bd0e0c14 name=bi-v113 url="https://github.com/rancher/k3os/releases/download/v0.11.0/k3os-amd64.iso" uuid=bd0e0c14 workDir=/data/backing-images/bi-v113-bd0e0c1
time="2022-02-18T07:20:44Z" level=info msg="Backing Image Manager: pulling backing image" URL="https://github.com/rancher/k3os/releases/download/v0.11.0/k3os-amd64.iso" backingImage=bi-v113 component=backing-image-manager diskPathOnHost=/var/lib/longhorn/

Install Longhorn v1.2.3
Downloading a backingimage

While the download is in progress

Update the 01-prerequisite manifests (master-head)
kubectl -n longhorn-system apply -f 01-prerequisite/

backing_image_manager_controller

c.ds.GetReadyDiskNode(bim.Spec.DiskUUID)
The GetReadyDiskNode lead to the the infinite error in kubelet log
0221 16:45:37.082085   13986 cacher.go:419] cacher (*unstructured.Unstructured): unexpected ListAndWatch error: failed to list [longhorn.io/v1beta1](http://longhorn.io/v1beta1), Kind=Node: conversion webhook for [longhorn.io/v1beta2](http://longhorn.io/v1beta2), Kind=Node failed: Post "https://longhorn-conversion-webhook.longhorn-system.svc:9443/v1/webhook/conversion?timeout=30s": dial tcp <IP_ADDRESS>:9443: connect: connection refused; reinitializing...

After applying 02-components manifests, the error still continues
E0221 16:43:59.517885   13986 cacher.go:419] cacher (*unstructured.Unstructured): unexpected ListAndWatch error: failed to list [longhorn.io/v1beta1](http://longhorn.io/v1beta1), Kind=BackingImage: conversion webhook for [longhorn.io/v1beta2](http://longhorn.io/v1beta2), Kind=BackingImage failed: error decoding src object; reinitializing...

One possible solution:

Apply 01-prerequisite with CRDs (v1beta1's storage: ture and v1beta2's storage: false)
Apply 02-components/longhorn-manager.yaml

old longhorn-managers are terminated
new longhorn-managers are waiting for the webhooks

Apply CRDs update (v1beta1's storage: false and v1beta2's storage: true)

By manual now
Need to move to longhorn-manager daemon

Apply other manifests in 02-components

Do you mean asking users to apply YAML files one by one and step and step during the upgrade? I don't think adding complexity for the upgrade is a good idea.
Besides, asking longhorn manager pods to mutate the YAML deployed by users (the CRD) may cause some other issues as well. Some users will rely on some tools to monitor if the deployed YAML is changed by someone else then throw some errors.

Do you mean asking users to apply YAML files one by one and step and step during the upgrade? I don't think adding complexity for the upgrade is a good idea. Besides, asking longhorn manager pods to mutate the YAML deployed by users (the CRD) may cause some other issues as well. Some users will rely on some tools to monitor if the deployed YAML is changed by someone else then throw some errors.

No, we don't need to ask users to apply YAML files one by one and step and step.
The storage field of v1beta1 and v1beta2 in the CRD manifests will be changed to true and false, respectively. User can upgrade Longhorn as usual. While starting the longhorn-manager, the storage field of v1beta1 and v1beta2CRDs are update false and true in the daemon.
Do you think it makes sense?

Do you mean asking users to apply YAML files one by one and step and step during the upgrade? I don't think adding complexity for the upgrade is a good idea. Besides, asking longhorn manager pods to mutate the YAML deployed by users (the CRD) may cause some other issues as well. Some users will rely on some tools to monitor if the deployed YAML is changed by someone else then throw some errors.

No, we don't need to ask users to apply YAML files one by one and step and step.
The storage field of v1beta1 and v1beta2 in the CRD manifests will be changed to true and false, respectively. User can upgrade Longhorn as usual. While starting the longhorn-manager, the storage field of v1beta1 and v1beta2CRDs are updated to false and true in the daemon.
Do you think it makes sense?

It seems like a promising solution. Have you tried?

Do you mean asking users to apply YAML files one by one and step and step during the upgrade? I don't think adding complexity for the upgrade is a good idea. Besides, asking longhorn manager pods to mutate the YAML deployed by users (the CRD) may cause some other issues as well. Some users will rely on some tools to monitor if the deployed YAML is changed by someone else then throw some errors.

No, we don't need to ask users to apply YAML files one by one and step and step.
The storage field of v1beta1 and v1beta2 in the CRD manifests will be changed to true and false, respectively. User can upgrade Longhorn as usual. While starting the longhorn-manager, the storage field of v1beta1 and v1beta2CRDs are updated to false and true in the daemon.
Do you think it makes sense?

It seems like a promising solution. Have you tried?

Yes, I tried to simulate by the steps.

Some users will rely on some tools to monitor if the deployed YAML is changed by someone else then throw some errors.

Agree with this. The GitOps tool would check whether it deployed is the same as in cluster resource.

Then we still need to rely on Longhorn components to update the CRD YAML deployed by users. As I mentioned above, this may cause some issues. This is similar to the case Longhorn gives up updating tolerations & selectors for some components. For more details, you can check the related PR: https://github.com/longhorn/longhorn-manager/pull/842

longhorn/longhorn-manager#842

Yes. We still need to update the CRD YAML.
Not sure if the update of the storage field will bring some issues. Do you think we can give this solution a go?

longhorn/longhorn-manager#842

Yes. We still need to update the CRD YAML. Not sure if the update of the storage field will bring some issues. Do you think we can give this solution a go?

This also brings another issue that the conversion webhook server would update the CRD spec for the dynamically generate caBundle.

Right now I have no better idea. And I am not sure if we need to break this convention (do not update YAML deployed by users).
For the caBundle update, yeah, this may be a potential issue.

Okay. Let us think more to find a better solution for a while.

I tried to investigate this issue more
Experiment 1
Upload a backingimage bbb, the value of thebbb resource in etcd
 etcdctl --cert /var/lib/rancher/rke2/server/tls/etcd/server-client.crt --key /var/lib/rancher/rke2/server/tls/etcd/server-client.key --endpoints https://<IP_ADDRESS>:2379 --cacert /var/lib/rancher/rke2/server/tls/etcd/server-ca.crt get /registry/longhorn.io/backingimages/longhorn-system/bbb
/registry/longhorn.io/backingimages/longhorn-system/bbb
{"apiVersion":"longhorn.io/v1beta1","kind":"BackingImage","metadata":{"creationTimestamp":"2022-03-01T16:18:36Z","finalizers":["longhorn.io"],"generation":2,"labels":{"longhorn.io/component":"backing-image","longhorn.io/managed-by":"longhorn-manager"},"managedFields":[{"apiVersion":"longhorn.io/v1beta1","fieldsType":"FieldsV1","fieldsV1":{"f:metadata":{"f:finalizers":{".":{},"v:\"longhorn.io\"":{}},"f:labels":{".":{},"f:longhorn.io/component":{},"f:longhorn.io/managed-by":{}}},"f:spec":{},"f:status":{}},"manager":"longhorn-manager","operation":"Update","time":"2022-03-01T16:18:36Z"}],"name":"bbb","namespace":"longhorn-system","uid":"ea37250e-ea72-447b-873c-b9a1410ec97a"},"spec":{"checksum":"","disks":{"93e0d699-9ae4-4ff9-803a-e77ece8a17ef":{}},"imageURL":"","sourceParameters":{"url":"https://github.com/rancher/k3os/releases/download/v0.11.0/k3os-amd64.iso"},"sourceType":"download"},"status":{"checksum":"0a230fccbcf4acdd600933f94250fc6513bbf207d4e584984fca3e36ce6716a9bf3a3ce6fac3a4d0d08c56609ea8c6f02e9944d96c1080fb0abf0020ad7a268f","diskDownloadProgressMap":null,"diskDownloadStateMap":null,"diskFileStatusMap":{"93e0d699-9ae4-4ff9-803a-e77ece8a17ef":{"lastStateTransitionTime":"2022-03-01T16:20:39Z","message":"","progress":100,"state":"ready"}},"diskLastRefAtMap":{"93e0d699-9ae4-4ff9-803a-e77ece8a17ef":"2022-03-01T16:18:36Z"},"ownerID":"rancher60-worker1","size":534431744,"uuid":"2725336b"}}

After finishing upload, update master-head CRD manifests
root@rancher60-master:~/crd_webhook# etcdctl --cert /var/lib/rancher/rke2/server/tls/etcd/server-client.crt --key /var/lib/rancher/rke2/server/tls/etcd/server-client.key --endpoints https://<IP_ADDRESS>:2379 --cacert /var/lib/rancher/rke2/server/tls/etcd/server-ca.crt get /registry/longhorn.io/backingimages/longhorn-system/bbb
/registry/longhorn.io/backingimages/longhorn-system/bbb
{"apiVersion":"longhorn.io/v1beta1","kind":"BackingImage","metadata":{"creationTimestamp":"2022-03-01T16:18:36Z","finalizers":["longhorn.io"],"generation":2,"labels":{"longhorn.io/component":"backing-image","longhorn.io/managed-by":"longhorn-manager"},"managedFields":[{"apiVersion":"longhorn.io/v1beta1","fieldsType":"FieldsV1","fieldsV1":{"f:metadata":{"f:finalizers":{".":{},"v:\"longhorn.io\"":{}},"f:labels":{".":{},"f:longhorn.io/component":{},"f:longhorn.io/managed-by":{}}},"f:spec":{},"f:status":{}},"manager":"longhorn-manager","operation":"Update","time":"2022-03-01T16:18:36Z"}],"name":"bbb","namespace":"longhorn-system","uid":"ea37250e-ea72-447b-873c-b9a1410ec97a"},"spec":{"checksum":"","disks":{"93e0d699-9ae4-4ff9-803a-e77ece8a17ef":{}},"imageURL":"","sourceParameters":{"url":"https://github.com/rancher/k3os/releases/download/v0.11.0/k3os-amd64.iso"},"sourceType":"download"},"status":{"checksum":"0a230fccbcf4acdd600933f94250fc6513bbf207d4e584984fca3e36ce6716a9bf3a3ce6fac3a4d0d08c56609ea8c6f02e9944d96c1080fb0abf0020ad7a268f","diskDownloadProgressMap":null,"diskDownloadStateMap":null,"diskFileStatusMap":{"93e0d699-9ae4-4ff9-803a-e77ece8a17ef":{"lastStateTransitionTime":"2022-03-01T16:20:39Z","message":"","progress":100,"state":"ready"}},"diskLastRefAtMap":{"93e0d699-9ae4-4ff9-803a-e77ece8a17ef":"2022-03-01T16:18:36Z"},"ownerID":"rancher60-worker1","size":534431744,"uuid":"2725336b"}}

Experiment 2
/registry/longhorn.io/backingimages/longhorn-system/bbb
{"apiVersion":"longhorn.io/v1beta1","kind":"BackingImage","metadata":{"creationTimestamp":"2022-03-01T16:40:11Z","finalizers":["longhorn.io"],"generation":2,"labels":{"longhorn.io/component":"backing-image","longhorn.io/managed-by":"longhorn-manager"},"managedFields":[{"apiVersion":"longhorn.io/v1beta1","fieldsType":"FieldsV1","fieldsV1":{"f:metadata":{"f:finalizers":{".":{},"v:\"longhorn.io\"":{}},"f:labels":{".":{},"f:longhorn.io/component":{},"f:longhorn.io/managed-by":{}}},"f:spec":{},"f:status":{}},"manager":"longhorn-manager","operation":"Update","time":"2022-03-01T16:40:11Z"}],"name":"bbb","namespace":"longhorn-system","uid":"f2e52b5a-52e6-4881-890d-f90d377663aa"},"spec":{"checksum":"","disks":{"144171df-1157-412d-acc5-047deb1ff79d":{}},"imageURL":"","sourceParameters":{"url":"https://github.com/rancher/k3os/releases/download/v0.11.0/k3os-amd64.iso"},"sourceType":"download"},"status":{"checksum":"","diskDownloadProgressMap":null,"diskDownloadStateMap":null,"diskFileStatusMap":{"144171df-1157-412d-acc5-047deb1ff79d":{"lastStateTransitionTime":"2022-03-01T16:40:31Z","message":"","progress":1,"state":"in-progress"}},"diskLastRefAtMap":{"144171df-1157-412d-acc5-047deb1ff79d":"2022-03-01T16:40:11Z"},"ownerID":"rancher60-worker1","size":534431744,"uuid":"89f245d3"}}

Update master-head CRD manifests while the upload is in progress
root@rancher60-master:~/crd_webhook/before-issue-3562-install# etcdctl --cert /var/lib/rancher/rke2/server/tls/etcd/server-client.crt --key /var/lib/rancher/rke2/server/tls/etcd/server-client.key --endpoints https://<IP_ADDRESS>:2379 --cacert /var/lib/rancher/rke2/server/tls/etcd/server-ca.crt get /registry/longhorn.io/backingimages/longhorn-system/bbb
/registry/longhorn.io/backingimages/longhorn-system/bbb
{"apiVersion":"longhorn.io/v1beta2","kind":"BackingImage","metadata":{"creationTimestamp":"2022-03-01T16:40:11Z","finalizers":["longhorn.io"],"generation":3,"labels":{"longhorn.io/component":"backing-image","longhorn.io/managed-by":"longhorn-manager"},"managedFields":[{"apiVersion":"longhorn.io/v1beta1","fieldsType":"FieldsV1","fieldsV1":{"f:metadata":{"f:finalizers":{".":{},"v:\"longhorn.io\"":{}},"f:labels":{".":{},"f:longhorn.io/component":{},"f:longhorn.io/managed-by":{}}},"f:spec":{},"f:status":{}},"manager":"longhorn-manager","operation":"Update","time":"2022-03-01T16:40:11Z"}],"name":"bbb","namespace":"longhorn-system","uid":"f2e52b5a-52e6-4881-890d-f90d377663aa"},"spec":{"checksum":"","disks":{"09d9c6de-13ef-4d7a-b8ef-f3622ddfc228":{},"144171df-1157-412d-acc5-047deb1ff79d":{}},"imageURL":"","sourceParameters":{"url":"https://github.com/rancher/k3os/releases/download/v0.11.0/k3os-amd64.iso"},"sourceType":"download"},"status":{"checksum":"","diskDownloadProgressMap":{},"diskDownloadStateMap":{},"diskFileStatusMap":{"09d9c6de-13ef-4d7a-b8ef-f3622ddfc228":{"lastStateTransitionTime":"2022-03-01T16:41:25Z","message":"pod spec node ID rancher60-master doesn't match the desired node ID rancher60-worker1","progress":51,"state":"failed"},"144171df-1157-412d-acc5-047deb1ff79d":{"lastStateTransitionTime":"2022-03-01T16:41:23Z","message":"","progress":0,"state":"unknown"}},"diskLastRefAtMap":{"09d9c6de-13ef-4d7a-b8ef-f3622ddfc228":"2022-03-01T16:41:24Z","144171df-1157-412d-acc5-047deb1ff79d":"2022-03-01T16:40:11Z"},"ownerID":"rancher60-worker1","size":534431744,"uuid":"89f245d3"}}

apiVersion field became longhorn.io/v1beta2.

In Experiment 1, the apiVersion was not changed after updating CRDs.
But, in Experiment 2, apiVersion became longhorn.io/v1beta2 and Spec/Status still followed v1beta1 schema.
The change of apiVersion resulted in the decode failure in "conversion webhook" because of the mismatch of apiVersion and Spec/Status.

Summary of the discussing with @PhanLe1010
The CRD manifest does not include the spec.conversion=Webhook and related fields. Thus, after deploying the CRD manifest, the apiserver thinks the v1beta1 and v1beta2 has same schema and only updates the apiVersion.  This is the root cause of https://github.com/longhorn/longhorn/issues/3631#issuecomment-1055640716.
Ref: https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definition-versioning/#webhook-conversion

If there are no schema changes, the default None conversion strategy may be used and only the apiVersion field will be modified when serving different versions.

Then, the spec.conversion=Webhook and the related fields are updated in the conversion webhook, but  the resources with incorrect apiVersion are not convertible after the update.
https://github.com/longhorn/longhorn-manager/blob/d3df3a36542b36e9b5d73d7ff692fa083bbaeeec/webhook/server/server.go#L218
So, the feasible upgrade steps can be

Apply the manifests in 01-prerequisite except for 01-prerequisite/03-crd.yaml
Start the webhook services by applying 02-components/02-backend.yaml and 02-components/05-webhook.yaml.
If the webhook services are running, apply 01-prerequisite/03-crd.yaml and remaining manifests in 02-components

The hinderance of the solution is how to guarantee the order of applying the manifests.

On the other hand, If we move the spec.conversion=Webhook and the related fields to the CRD manifest, is it helpful for this issue? Can the webhook services start after applying CRD manifest?
cc. @PhanLe1010 @jenting @shuo-wu @innobead

After adding spec.conversion=Webhook for CRDs, why cannot we upgrade the CRD YAML along with other components? Or what will happen?

After adding spec.conversion=Webhook for CRDs

I'm working on it and will report later.

On the other hand, If we move the spec.conversion=Webhook and the related fields to the CRD manifest, is it helpful for this issue? Can the webhook services start after applying CRD manifest?

I set the pec.conversion=Webhook and caBundle in the CRD manifest by manual.
The original upgrade strategy (apply 01-prerequisite and 02-components) works well.
So the prob becomes how to deal with caBundle.
cc. @jenting @shuo-wu @PhanLe1010

I am curious how it can work well. Looks like we are setting conversion strategy as weekhook for the CRDs then deploy the actual webhook. It means that there is a period in which the client (old Longhorn manager) cannot update the CR (I.e., while the week hook has not been deployed?

@PhanLe1010 The apiServer continues to retry to connect the conversion webhook until it succeed.
So we can see the repeated error messages in kubelet log
Mar  3 04:05:23 ubuntu1804 k3s[14117]: E0303 04:05:23.052647   14117 cacher.go:419] cacher (*unstructured.Unstructured): unexpected ListAndWatch error: failed to list longhorn.io/v1beta2, Kind=BackingImage: conversion webhook for longhorn.io/v1beta1, Kind=BackingImage failed: Post "https://longhorn-conversion-webhook.longhorn-system.svc:9443/v1/webhook/conversion?timeout=30s": service "longhorn-conversion-webhook" not found; reinitializing...
Mar  3 04:05:23 ubuntu1804 k3s[14117]: E0303 04:05:23.319682   14117 cacher.go:419] cacher (*unstructured.Unstructured): unexpected ListAndWatch error: failed to list longhorn.io/v1beta2, Kind=EngineImage: conversion webhook for longhorn.io/v1beta1, Kind=EngineImage failed: Post "https://longhorn-conversion-webhook.longhorn-system.svc:9443/v1/webhook/conversion?timeout=30s": service "longhorn-conversion-webhook" not found; reinitializing...

So the prob becomes how to deal with https://github.com/longhorn/longhorn/issues/3631#issuecomment-1050535050.

Adding conversion webhook related fields in the manifest and leaving caBundle  empty in the manifest.
Then, the caBundle` is updated in the conversion webhook.
The strategy looks work well now.

leaving caBundle empty in the manifest.

I think we could leave spec.conversion.webhook to empty in the CRD manifest.

spec.conversion.webhook to

spec.conversion.webhook is either None or Webhook, and None is default value.
Thus, we need to set it to Webhook and set some necessary fields, like
  conversion:
    strategy: Webhook
    webhook:
      conversionReviewVersions: ["v1beta2","v1beta1"]
      clientConfig:
        service:
          namespace: longhorn-system
          name: longhorn-conversion-webhook
          path: /v1/webhook/conversion
          port: 9443

@derekbit there is a different set of errors coming up when upgrading with helm. (testing with today's master-head image *)
With the same testing steps but install using helm3 then upgrade to master-head via local chart(longhorn repo).
$ helm upgrade longhorn ./chart -n longhorn-system                                     127 ↵ master
Error: UPGRADE FAILED: cannot patch "nodes.longhorn.io" with kind CustomResourceDefinition:  "" is invalid: patch: Invalid value: "map[metadata:map[annotations:map[controller-gen.kubebuilder.io/version:v0.7.0] creationTimestamp:<nil> labels:map[app.kubernetes.io/version:v1.3.0-dev helm.sh/chart:longhorn-1.3.0-dev longhorn-manager:]] spec:map[conversion:map[strategy:Webhook webhook:map[clientConfig:map[service:map[name:longhorn-conversion-webhook namespace:longhorn-system path:/v1/webhook/conversion port:9443]] conversionReviewVersions:[v1beta2 v1beta1]]] versions:[map[additionalPrinterColumns:[map[description:Indicate whether the node is ready jsonPath:.status.conditions['Ready']['status'] name:Ready type:string] map[description:Indicate whether the user disabled/enabled replica scheduling for the node jsonPath:.spec.allowScheduling name:AllowScheduling type:boolean] map[description:Indicate whether Longhorn can schedule replicas on the node jsonPath:.status.conditions['Schedulable']['status'] name:Schedulable type:string] map[jsonPath:.metadata.creationTimestamp name:Age type:date]] name:v1beta1 schema:map[openAPIV3Schema:map[description:Node is where Longhorn stores Longhorn node object. properties:map[apiVersion:map[description:APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources type:string] kind:map[description:Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds type:string] metadata:map[type:object] spec:map[x-kubernetes-preserve-unknown-fields:true] status:map[x-kubernetes-preserve-unknown-fields:true]] type:object]] served:true storage:false subresources:map[status:map[]]] map[additionalPrinterColumns:[map[description:Indicate whether the node is ready jsonPath:.status.conditions[?(@.type=='Ready')].status name:Ready type:string] map[description:Indicate whether the user disabled/enabled replica scheduling for the node jsonPath:.spec.allowScheduling name:AllowScheduling type:boolean] map[description:Indicate whether Longhorn can schedule replicas on the node jsonPath:.status.conditions[?(@.type=='Schedulable')].status name:Schedulable type:string] map[jsonPath:.metadata.creationTimestamp name:Age type:date]] name:v1beta2 schema:map[openAPIV3Schema:map[description:Node is where Longhorn stores Longhorn node object. properties:map[apiVersion:map[description:APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources type:string] kind:map[description:Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds type:string] metadata:map[type:object] spec:map[description:NodeSpec defines the desired state of the Longhorn node properties:map[allowScheduling:map[type:boolean] disks:map[additionalProperties:map[properties:map[allowScheduling:map[type:boolean] evictionRequested:map[type:boolean] path:map[type:string] storageReserved:map[format:int64 type:integer] tags:map[items:map[type:string] type:array]] type:object] type:object] engineManagerCPURequest:map[minimum:0 type:integer] evictionRequested:map[type:boolean] name:map[type:string] replicaManagerCPURequest:map[minimum:0 type:integer] tags:map[items:map[type:string] type:array]] type:object] status:map[description:NodeStatus defines the observed state of the Longhorn node properties:map[conditions:map[items:map[properties:map[lastProbeTime:map[description:Last time we probed the condition. type:string] lastTransitionTime:map[description:Last time the condition transitioned from one status to another. type:string] message:map[description:Human-readable message indicating details about last transition. type:string] reason:map[description:Unique, one-word, CamelCase reason for the condition's last transition. type:string] status:map[description:Status is the status of the condition. Can be True, False, Unknown. type:string] type:map[description:Type is the type of the condition. type:string]] type:object] nullable:true type:array] diskStatus:map[additionalProperties:map[properties:map[conditions:map[items:map[properties:map[lastProbeTime:map[description:Last time we probed the condition. type:string] lastTransitionTime:map[description:Last time the condition transitioned from one status to another. type:string] message:map[description:Human-readable message indicating details about last transition. type:string] reason:map[description:Unique, one-word, CamelCase reason for the condition's last transition. type:string] status:map[description:Status is the status of the condition. Can be True, False, Unknown. type:string] type:map[description:Type is the type of the condition. type:string]] type:object] nullable:true type:array] diskUUID:map[type:string] scheduledReplica:map[additionalProperties:map[format:int64 type:integer] nullable:true type:object] storageAvailable:map[format:int64 type:integer] storageMaximum:map[format:int64 type:integer] storageScheduled:map[format:int64 type:integer]] type:object] nullable:true type:object] region:map[type:string] zone:map[type:string]] type:object]] type:object]] served:true storage:true subresources:map[status:map[]]]]] status:map[acceptedNames:map[kind: plural:] conditions:[] storedVersions:[]]]": cannot convert int64 to float64 && cannot patch "volumes.longhorn.io" with kind CustomResourceDefinition:  "" is invalid: patch: Invalid value: "map[metadata:map[annotations:map[controller-gen.kubebuilder.io/version:v0.7.0] creationTimestamp:<nil> labels:map[app.kubernetes.io/version:v1.3.0-dev helm.sh/chart:longhorn-1.3.0-dev longhorn-manager:]] spec:map[conversion:map[strategy:Webhook webhook:map[clientConfig:map[service:map[name:longhorn-conversion-webhook namespace:longhorn-system path:/v1/webhook/conversion port:9443]] conversionReviewVersions:[v1beta2 v1beta1]]] versions:[map[additionalPrinterColumns:[map[description:The state of the volume jsonPath:.status.state name:State type:string] map[description:The robustness of the volume jsonPath:.status.robustness name:Robustness type:string] map[description:The scheduled condition of the volume jsonPath:.status.conditions['scheduled']['status'] name:Scheduled type:string] map[description:The size of the volume jsonPath:.spec.size name:Size type:string] map[description:The node that the volume is currently attaching to jsonPath:.status.currentNodeID name:Node type:string] map[jsonPath:.metadata.creationTimestamp name:Age type:date]] name:v1beta1 schema:map[openAPIV3Schema:map[description:Volume is where Longhorn stores volume object. properties:map[apiVersion:map[description:APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources type:string] kind:map[description:Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds type:string] metadata:map[type:object] spec:map[x-kubernetes-preserve-unknown-fields:true] status:map[x-kubernetes-preserve-unknown-fields:true]] type:object]] served:true storage:false subresources:map[status:map[]]] map[additionalPrinterColumns:[map[description:The state of the volume jsonPath:.status.state name:State type:string] map[description:The robustness of the volume jsonPath:.status.robustness name:Robustness type:string] map[description:The scheduled condition of the volume jsonPath:.status.conditions[?(@.type=='Schedulable')].status name:Scheduled type:string] map[description:The size of the volume jsonPath:.spec.size name:Size type:string] map[description:The node that the volume is currently attaching to jsonPath:.status.currentNodeID name:Node type:string] map[jsonPath:.metadata.creationTimestamp name:Age type:date]] name:v1beta2 schema:map[openAPIV3Schema:map[description:Volume is where Longhorn stores volume object. properties:map[apiVersion:map[description:APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources type:string] kind:map[description:Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds type:string] metadata:map[type:object] spec:map[description:VolumeSpec defines the desired state of the Longhorn volume properties:map[Standby:map[type:boolean] accessMode:map[enum:[rwo rwx] type:string] backingImage:map[type:string] baseImage:map[description:Deprecated. Rename to BackingImage type:string] dataLocality:map[enum:[disabled best-effort] type:string] dataSource:map[type:string] disableFrontend:map[type:boolean] diskSelector:map[items:map[type:string] type:array] encrypted:map[type:boolean] engineImage:map[type:string] fromBackup:map[type:string] frontend:map[enum:[blockdev iscsi ] type:string] lastAttachedBy:map[type:string] migratable:map[type:boolean] migrationNodeID:map[type:string] nodeID:map[type:string] nodeSelector:map[items:map[type:string] type:array] numberOfReplicas:map[minimum:1 type:integer] recurringJobs:map[description:Deprecated. Replaced by a separate resource named \"RecurringJob\" items:map[description:VolumeRecurringJobSpec is a deprecated struct. TODO: Should be removed when recurringJobs gets removed from the volume       spec. properties:map[concurrency:map[type:integer] cron:map[type:string] groups:map[items:map[type:string] type:array] labels:map[additionalProperties:map[type:string] type:object] name:map[type:string] retain:map[type:integer] task:map[enum:[snapshot backup] type:string]] type:object] type:array] replicaAutoBalance:map[enum:[ignored disabled least-effort best-effort] type:string] revisionCounterDisabled:map[type:boolean] size:map[format:int64 type:string] staleReplicaTimeout:map[type:integer]] type:object] status:map[description:VolumeStatus defines the observed state of the Longhorn volume properties:map[actualSize:map[format:int64 type:integer] cloneStatus:map[properties:map[snapshot:map[type:string] sourceVolume:map[type:string] state:map[type:string]] type:object] conditions:map[items:map[properties:map[lastProbeTime:map[description:Last time we probed the condition. type:string] lastTransitionTime:map[description:Last time the condition transitioned from one status to another. type:string] message:map[description:Human-readable message indicating details about last transition. type:string] reason:map[description:Unique, one-word, CamelCase reason for the condition's last transition. type:string] status:map[description:Status is the status of the condition. Can be True, False, Unknown. type:string] type:map[description:Type is the type of the condition. type:string]] type:object] nullable:true type:array] currentImage:map[type:string] currentNodeID:map[type:string] expansionRequired:map[type:boolean] frontendDisabled:map[type:boolean] isStandby:map[type:boolean] kubernetesStatus:map[properties:map[lastPVCRefAt:map[type:string] lastPodRefAt:map[type:string] namespace:map[description:determine if PVC/Namespace is history or not type:string] pvName:map[type:string] pvStatus:map[type:string] pvcName:map[type:string] workloadsStatus:map[description:determine if Pod/Workload is history or not items:map[properties:map[podName:map[type:string] podStatus:map[type:string] workloadName:map[type:string] workloadType:map[type:string]] type:object] nullable:true type:array]] type:object] lastBackup:map[type:string] lastBackupAt:map[type:string] lastDegradedAt:map[type:string] ownerID:map[type:string] pendingNodeID:map[type:string] remountRequestedAt:map[type:string] restoreInitiated:map[type:boolean] restoreRequired:map[type:boolean] robustness:map[type:string] shareEndpoint:map[type:string] shareState:map[type:string] state:map[type:string]] type:object]] type:object]] served:true storage:true subresources:map[status:map[]]]]] status:map[acceptedNames:map[kind: plural:] conditions:[] storedVersions:[]]]": cannot convert int64 to float64

Upgrade can be finished if install from manifest file. But the backing image the under going volume will be failed,

Logs from backing-image-manager-*:
time="2022-03-31T09:18:09Z" level=info msg="Backing Image Manager listening to <IP_ADDRESS>:8000"
time="2022-03-31T09:18:16Z" level=info msg="Backing Image Manager: prepare to start backing image update watch" component=backing-image-manager
time="2022-03-31T09:18:16Z" level=info msg="Backing Image Manager: backing image update watch started" component=backing-image-manager
time="2022-03-31T09:18:16Z" level=info msg="Backing Image Manager: prepare to fetch backing image" backingImage=bi-v113 component=backing-image-manager sourceFileName=
time="2022-03-31T09:18:16Z" level=info msg="Backing Image: start to fetch backing image" component=backing-image expectedChecksum= name=bi-v113 size=534431744 uuid=a3a257a1 workDir=/data/backing-images/bi-v113-a3a257a1
time="2022-03-31T09:18:16Z" level=error msg="Backing Image: failed to process backing image file: failed to reuse file via the fetch call, then reset the work directory and exited: stat /data/backing-images/bi-v113-a3a257a1/backing: no such file or directory" component=backing-image expectedChecksum= name=bi-v113 size=534431744 uuid=a3a257a1 workDir=/data/backing-images/bi-v113-a3a257a1
time="2022-03-31T09:18:16Z" level=error msg="Backing Image Manager: failed to start fetching backing image" backingImage=bi-v113 component=backing-image-manager error="failed to fetch backing image: failed to reuse file via the fetch call, then reset the work directory and exited: stat /data/backing-images/bi-v113-a3a257a1/backing: no such file or directory" sourceFileName=

* longhornio/longhorn-manager@sha256:121ec7cdf95f3f702f1d0a41436aab1b1150255ae36302304ea20687ebf0bf7a

Hmm, need to check the helm's behavior.

Weird... I cannot reproduce the error and the upgrade is successful. Here are my steps:

Install LH v1.2.4 using helm as the steps in https://longhorn.io/docs/1.2.4/deploy/install/install-with-helm/
Create 3 pods with volumes
Create 5 backing image downloads
While the downloads are in progress, upgrade LH by helm upgrade longhorn -n longhorn-system ./chart (latest longhorn/longhorn/chart)

I can reproduce it in v1.18.20+k3s1 now. v1.19 or new is okay.

Th minimum and maximum marks in the CRD manifest introduce the error.
The workaround is that move the checks into the validating webhook.
similar issues

https://github.com/cert-manager/cert-manager/issues/3644
https://github.com/helm/helm/issues/5806

cc @innobead

Yeah, another good finding from @kaxing
As @derekbit mentioned, there is some conversion enhancement after 1.18, so even we use recent versions of helm v2/v3 which adopts newer k8s API lib w/ the fix, we will still hit the issues in the 1.18 cluster.
As per we are still supporting 1.18, so the temporary solution is like @derekbit mentioned, but we need to adjust back when we bump the version support from 1.18.

@derekbit with the latest fix the installtion will no longer stuck.
However, the backing image will fail, as there is no Image URL.
failed to process backing image file: failed to reuse file via the fetch call, then reset the work directory and exited: stat /data/backing-images/bi-v113-e075f796/backing: no such file or

 Expand to see the output of describe backingimage/bi-v113
Name:         bi-v113
Namespace:    longhorn-system
Labels:       longhorn.io/component=backing-image
              longhorn.io/managed-by=longhorn-manager
Annotations:  <none>
API Version:  longhorn.io/v1beta2
Kind:         BackingImage
Metadata:
  Creation Timestamp:  2022-04-06T08:06:00Z
  Finalizers:
    longhorn.io
  Generation:  6
  Managed Fields:
    API Version:  longhorn.io/v1beta1
    Fields Type:  FieldsV1
    fieldsV1:
      f:metadata:
        f:finalizers:
          .:
          v:"longhorn.io":
        f:labels:
          .:
          f:longhorn.io/component:
          f:longhorn.io/managed-by:
    Manager:      longhorn-manager
    Operation:    Update
    Time:         2022-04-06T08:06:00Z
    API Version:  longhorn.io/v1beta2
    Fields Type:  FieldsV1
    fieldsV1:
      f:spec:
        f:imageURL:
        f:sourceParameters:
          f:url:
      f:status:
        f:diskFileStatusMap:
          f:809baab6-0308-4b0b-9dc5-4528090c8185:
            .:
            f:lastStateTransitionTime:
            f:message:
            f:progress:
            f:state:
          f:9517cb60-9d84-4980-8fc6-916797bc1b2a:
            .:
            f:lastStateTransitionTime:
            f:message:
            f:progress:
            f:state:
          f:dcaa228c-53f1-4986-9105-b28bd3b291b1:
            .:
            f:lastStateTransitionTime:
            f:message:
            f:progress:
            f:state:
    Manager:         longhorn-manager
    Operation:       Update
    Time:            2022-04-06T08:09:24Z
  Resource Version:  6981
  Self Link:         /apis/longhorn.io/v1beta2/namespaces/longhorn-system/backingimages/bi-v113
  UID:               66b8bf0d-fbdd-4aa9-b8dd-a723a620423f
Spec:
  Checksum:
  Disks:
    809baab6-0308-4b0b-9dc5-4528090c8185:
    9517cb60-9d84-4980-8fc6-916797bc1b2a:
    dcaa228c-53f1-4986-9105-b28bd3b291b1:
  Image URL:
  Source Parameters:
    URL:
  Source Type:  download
Status:
  Checksum:
  Disk Download Progress Map:
  Disk Download State Map:
  Disk File Status Map:
    809baab6-0308-4b0b-9dc5-4528090c8185:
      Last State Transition Time:  2022-04-06T08:09:21Z
      Message:                     failed to process backing image file: failed to reuse file via the fetch call, then reset the work directory and exited: stat /data/backing-images/bi-v113-e075f796/backing: no such file or directory
      Progress:                    0
      State:                       failed
    9517cb60-9d84-4980-8fc6-916797bc1b2a:
      Last State Transition Time:  2022-04-06T08:09:24Z
      Message:                     failed to process backing image file: failed to reuse file via the fetch call, then reset the work directory and exited: stat /data/backing-images/bi-v113-e075f796/backing: no such file or directory
      Progress:                    0
      State:                       failed
    dcaa228c-53f1-4986-9105-b28bd3b291b1:
      Last State Transition Time:  2022-04-06T08:09:20Z
      Message:                     failed to process backing image file: failed to reuse file via the fetch call, then reset the work directory and exited: stat /data/backing-images/bi-v113-e075f796/backing: no such file or directory
      Progress:                    0
      State:                       failed
  Disk Last Ref At Map:
  Owner ID:  it2-node2
  Size:      534431744
  Uuid:      e075f796
Events:
  Type    Reason  Age    From                               Message
  ----    ------  ----   ----                               -------
  Normal  Update  9m32s  longhorn-backing-image-controller  Initialized UUID to e075f796
  Normal  Create  9m6s   longhorn-backing-image-controller  created default backing image manager backing-image-manager-7298-809b in disk 809baab6-0308-4b0b-9dc5-4528090c8185 on node it2-node1
  Normal  Create  9m6s   longhorn-backing-image-controller  created default backing image manager backing-image-manager-7298-dcaa in disk dcaa228c-53f1-4986-9105-b28bd3b291b1 on node it2-node3
  Normal  Create  9m6s   longhorn-backing-image-controller  created default backing image manager backing-image-manager-7298-9517 in disk 9517cb60-9d84-4980-8fc6-916797bc1b2a on node it2-node2
  Normal  Update  8m40s  longhorn-backing-image-controller  Set size to 534431744
  Normal  Delete  7m8s   longhorn-backing-image-controller  delete old backing image manager backing-image-manager-7298-809b in disk 809baab6-0308-4b0b-9dc5-4528090c8185 on node it2-node1
  Normal  Delete  7m7s   longhorn-backing-image-controller  delete old backing image manager backing-image-manager-7298-9517 in disk 9517cb60-9d84-4980-8fc6-916797bc1b2a on node it2-node2
  Normal  Delete  7m7s   longhorn-backing-image-controller  delete old backing image manager backing-image-manager-7298-dcaa in disk dcaa228c-53f1-4986-9105-b28bd3b291b1 on node it2-node3
  Normal  Create  6m53s  longhorn-backing-image-controller  created default backing image manager backing-image-manager-03a6-809b in disk 809baab6-0308-4b0b-9dc5-4528090c8185 on node it2-node1
  Normal  Create  6m53s  longhorn-backing-image-controller  created default backing image manager backing-image-manager-03a6-9517 in disk 9517cb60-9d84-4980-8fc6-916797bc1b2a on node it2-node2
  Normal  Create  6m53s  longhorn-backing-image-controller  created default backing image manager backing-image-manager-03a6-dcaa in disk dcaa228c-53f1-4986-9105-b28bd3b291b1 on node it2-node3

Also result in volume stuck at attaching.
NAME          STATE       ROBUSTNESS   SCHEDULED   SIZE         NODE        AGE
bi-vol-v113   attaching   unknown<PHONE_NUMBER>   it2-node2   10m

And the BI with empty URL was first reported here: #3510
Maybe we can track this in the previous issue? cc @shuo-wu

Hmm, looks file or director missing. Always failed?
I don't have a concrete idea about the relationship between CRD upgrade and backing image missing.
For a workaround, does deleting the volume with the backingimage and creating a new one work?

@derekbit Yes, creating new Backing Image and Volume with Backing Image will have no problem.

Validation - PASSED
Tested with Kubernetes v1.18 + master-head(v1.3.0-dev, 20220407).
Upgrade-Installation process will no longer be blocked when the backing image is downloading
The empty URL issue for Backing Image will be track in this issue: #3510

Hi @derekbit
Facing similar issue while trying to uninstall and install Longhon on a k8s cluster (1.21).
on fresh install the pod  longhorn-conversion-webhook started running without any error, however the pod longhorn-admission-webhook's container is not in running status showing error
webhook for longhorn.io/v1beta1, Kind=Node failed: Post "https://longhorn-conversion-webhook.longhorn-system.svc:9443/v1/webhook/conversion?timeout=30s": Forbidden
E0308 11:35:46.860886       1 reflector.go:138] github.com/longhorn/longhorn-manager/k8s/pkg/client/informers/externalversions/factory.go:117: Failed to watch *v1beta2.Node: failed to list *v1beta2.Node: conversion webhook for longhorn.io/v1beta1, Kind=Node failed: Post "https://longhorn-conversion-webhook.longhorn-system.svc:9443/v1/webhook/conversion?timeout=30s": Forbidden

The above error repeats for *v1beta2.EngineImage: ,*v1beta2.Volume: all crds.
Installation was performed with helm
helm install longhorn longhorn/longhorn --namespace longhorn-system --create-namespace --version 1.4.0

@Vishnu-Narayanan-Nair
The forbidden issue is mostly related to the certification issue.
Can you check this https://github.com/longhorn/longhorn/issues/4462?


Sharedlivemedias update state

Purpose
Update state API endpoint for shared live media is missing.
Shared live media URLS were not matching those generated by lambda-convert.
Lambda-convert were not using extraParameters while sending update-state request.
Part of #1220
Proposal
Description...

[x] Use extraParameters for shared live media in lambda-convert
[x] Fix converted shared live media URLS
[x] Update update-state API endpoint to manage shared live media

No comment to add. I will review this one once #1267 finished.

As #1267 seems ok, could you please take a look on this @lunika ?


I would like to add my POWER4 token to your exchange

I would like to add my POWER4 token to your exchange.
The token contract address is : 0x38124611aC29A3D54EeAaBb63742D5e62a5da0D4
The token owner address is : 0x0e1e7A8A20e79A87Ed69EA2d99c4663f72B018E2
I am almost done with my DAPP that will use this token.
Token will be used for lottery. 100 tokens = 1 ticket. 100 tokens will cost 0.001 Eth. That means that at current prices.. lets say $50 for one ether it will cost $0.05 cents per play. The lottery will pay out in the POWER4 token. There are some special features to it but essentially you can win as few as 4,300 POWER4 tokens that you can later sell for ether or keep to play more and I intend on buying them back for ether but also if you get all 4 lottery numbers 4 of 4 you will get 730,000 POWER4 tokens. Which again you can sell for 7,300 Ether or you can keep to play some more with them. I am considering using this token as a token for many other DAPPS, poker, lottery, and many other DAPPS in the work. I do not expect to mint any more I am a firm believer that as the creator I need to and will buy them back for ether. Thus creating a true supply and demand structure for my token. I plan on keeping the price fixed at 0.00001 per token although I have set some shares to 0.00002 on a different as well as 0.00001 for supply and demand issues. I do not plan on ever selling for more than 0.00002 and if I do it will be very rare. I plan to keep prices low. I like the idea of a lottery but $5 for a ticket or more at 0.1ether is too high. This is a supposed to be a fun thing that does not break banks. I will host two drawings per week. One on Wednesday and one on Saturday.
Cheers laddies and gentleman! I you enjoy my DAPP and accompanying Token

Sorry but as there is no way to determine if this is a scam it can't be added for now. What you should do is fork our code and deploy your own oasis contract and frontend, and then market it independently. If you manage to attract an organic community around your project then it will be possible for us to add it to the main OasisDEX frontend.

You should probably verify your contract's code on Etherscan.
On Mar 20, 2017 4:06 PM, "hamsterPWR4"<EMAIL_ADDRESS>wrote:

I would like to add my POWER4 token to your exchange.
The token contract address is : 0x38124611aC29A3D54EeAaBb63742D5e62a5da0D4
The token owner address is : 0x0e1e7A8A20e79A87Ed69EA2d99c4663f72B018E2
I am almost done with my DAPP that will use this token.
Token will be used for lottery. 100 tokens = 1 ticket. 100 tokens will
cost 0.001 Eth. That means that at current prices.. lets say $50 for one
ether it will cost $0.05 cents per play. The lottery will pay out in the
POWER4 token. There are some special features to it but essentially you can
win as few as 4,300 POWER4 tokens that you can later sell for ether or keep
to play more and I intend on buying them back for ether but also if you get
all 4 lottery numbers 4 of 4 you will get 730,000 POWER4 tokens. Which
again you can sell for 7,300 Ether or you can keep to play some more with
them. I am considering using this token as a token for many other DAPPS,
poker, lottery, and many other DAPPS in the work. I do not expect to mint
any more I am a firm believer that as the creator I need to and will buy
them back for ether. Thus creating a true supply and demand structure for
my token. I plan on keeping the price fixed at 0.00001 per token although I
have set some shares to 0.00002 on a different as well as 0.00001 for
supply and demand issues. I do not plan on ever selling for more than
0.00002 and if I do it will be very rare. I plan to keep prices low. I like
the idea of a lottery but $5 for a ticket or more at 0.1ether is too high.
This is a supposed to be a fun thing that does not break banks. I will host
two drawings per week. One on Wednesday and one on Saturday.
Cheers laddies and gentleman! I you enjoy my DAPP and accompanying Token
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/OasisDEX/oasis-pro/issues/214, or mute the thread
https://github.com/notifications/unsubscribe-auth/AAqNjcvOzCBIphnVb1s6spN4KchzdZ5yks5rntwwgaJpZM4Mi8g9
.


Adds retirements routes

Description
Adds retirement routes in the API

Get a retirement
Get a retirement provenance records

Related Ticket
Also related to #1936
Notes For QA

Other notes:

Maybe we can chose better route paths

I'm not sure I agree with the very specific routes. A single handler on /retirements would be more flexible and long term sustainable. I can't imagine having to create new handlers & routes and tests every time we use a different provider or retirement type.
Can we please handle this with a single handler and request params or the body of a POST request instead?

Agreed on the fact that the name was very poorly chosen. my purpose was not to have a route by provider. But as an API user I would not like to use request parameters for a route that returns a single retirement. I would like to keep that for a route that filters retirements based on multiple parameters.
So I changed the route to just delete the klima part of the path. The idea is that when an API user wants to get a single retirement he passes the account_id and the retirement_index as part of the path. This would mean that we would consider the couple (account_id, retirement_index) the default key for a retirement.
LMKWYT

I'm not sure I agree with the very specific routes. A single handler on /retirements would be more flexible and long term sustainable. I can't imagine having to create new handlers & routes and tests every time we use a different provider or retirement type.
Can we please handle this with a single handler and request params or the body of a POST request instead?

Agreed on the fact that the name was very poorly chosen. my purpose was not to have a route by provider. But as an API user I would not like to use request parameters for a route that returns a single retirement. I would like to keep that for a route that filters retirements based on multiple parameters. So I changed the route to just delete the klima part of the path. The idea is that when an API user wants to get a single retirement he passes the account_id and the retirement_index as part of the path. This would mean that we would consider the couple (account_id, retirement_index) the default key for a retirement. LMKWYT

Hmm it seems like a lot of extra complexity to avoid the user having to extract the first element from an array. If we were to provide a /retirements endpoint would that require and additional handler?
I would much prefer that we have a single point of access for Retirements (e.g /retirements) and the user has the flexibility to reduce their results how they wish.
Unless theres another reason that a single result without params or a POST body is preferable to developers accessing our API?

I'm not sure I agree with the very specific routes. A single handler on /retirements would be more flexible and long term sustainable. I can't imagine having to create new handlers & routes and tests every time we use a different provider or retirement type.
Can we please handle this with a single handler and request params or the body of a POST request instead?

Agreed on the fact that the name was very poorly chosen. my purpose was not to have a route by provider. But as an API user I would not like to use request parameters for a route that returns a single retirement. I would like to keep that for a route that filters retirements based on multiple parameters. So I changed the route to just delete the klima part of the path. The idea is that when an API user wants to get a single retirement he passes the account_id and the retirement_index as part of the path. This would mean that we would consider the couple (account_id, retirement_index) the default key for a retirement. LMKWYT

Hmm it seems like a lot of extra complexity to avoid the user having to extract the first element from an array. If we were to provide a /retirements endpoint would that require and additional handler?
I would much prefer that we have a single point of access for Retirements (e.g /retirements) and the user has the flexibility to reduce their results how they wish.
Unless theres another reason that a single result without params or a POST body is preferable to developers accessing our API?

It would work with the single retirements handler. But I think it is good have this pattern where as an API user you can filter instances of a model on one side, and you can get an instance of a model by id on the other side.
It enables you to deal with instance of models instead arrays of instance, Instead of checking that you have a single result in your response array. You are ensured to have an instance of a model or a 404 error.

The id could be the transactionHash instead of /:account_id/:retirement_index though

I'm not sure I agree with the very specific routes. A single handler on /retirements would be more flexible and long term sustainable. I can't imagine having to create new handlers & routes and tests every time we use a different provider or retirement type.
Can we please handle this with a single handler and request params or the body of a POST request instead?

Agreed on the fact that the name was very poorly chosen. my purpose was not to have a route by provider. But as an API user I would not like to use request parameters for a route that returns a single retirement. I would like to keep that for a route that filters retirements based on multiple parameters. So I changed the route to just delete the klima part of the path. The idea is that when an API user wants to get a single retirement he passes the account_id and the retirement_index as part of the path. This would mean that we would consider the couple (account_id, retirement_index) the default key for a retirement. LMKWYT

Hmm it seems like a lot of extra complexity to avoid the user having to extract the first element from an array. If we were to provide a /retirements endpoint would that require and additional handler?
I would much prefer that we have a single point of access for Retirements (e.g /retirements) and the user has the flexibility to reduce their results how they wish.
Unless theres another reason that a single result without params or a POST body is preferable to developers accessing our API?

It would work with the single retirements handler. But I think it is good have this pattern where as an API user you can filter instances of a model on one side, and you can get an instance of a model by id on the other side. It enables you to deal with instance of models instead arrays of instance, Instead of checking that you have a single result in your response array. You are ensured to have an instance of a model or a 404 error.  The id could be the transactionHash instead of /:account_id/:retirement_index though

You are ensured to have an instance of a model or a 404 error.

This makes sense though I'm not sure how much extra utility it gives the consumer.
Having /:id routes makes sense because it's a single unique identifier. The /:accoount_id/:another_random_variable is really trying to squash query paramaters (or post body filters) in to a route parameter.
At the end of the day if you can argue the case that this approach will have the same re-usability, DRY benefits and flexibility (for if the user wants to fetch retirements under some other constraints) as if we were to simply allow filtering through a request body then I'm for it. Can the current approach do that?


tiny typo fix

Hi @The-Alchemist
thanks for your fix; the PR is in our CI and should be merged shortly.
Best,
Christian

Has been merged as part of https://github.com/graalvm/graaljs/commit/8baec295d5c004a50e3b62bb45fdf3b92150521b


DAC and PID nerst control is not the best control strategy

usecase: in-range measurment adter out-of-range condition
DAC and PID are not best for return to into range phase of control
suggested soltion: analog control, differential op-amp in diff schematic

@mck1117 says
our digital loop runs at ~2khz
if it ran at 10hz maybe
but we're much faster than the bandwidth of the sensor
shannon/nyquist say digital and analog are "the same" if you're sufficiently faster than the bandwidth of any signal you care about

I have yet to see a problem with it. I've seen full scale swings (in closed loop!) in <0.1 second.


fix test with double error bound

Changes
Please briefly list the changes made:
fix test with double error bound
Merge Request - GuideLine Checklist

Check our git workflow before opening a Pull request/Merge request.
Request a reviewer when your work is ready to review, before this please use the draft feature.

Checks by code author

[x] Every addressed issue is linked (use the "Closes #ISSUE" keyword below)
[x] New code adheres to coding guidelines
[x] No large data files have been added (files should in sum not exceed 100 KB, avoid PDFs, Word docs, etc.)
[x] Tests are added for new functionality and a local test run was successful
[x] Appropriate documentation for new functionality has been added (Doxygen in the code and Markdown files if necessary)
[x] Proper attention to licenses, especially no new third-party software with conflicting license has been added

Checks by code reviewer(s)

[ ] Corresponding issue(s) is/are linked and addressed
[ ] Code is clean of development artifacts (no deactivated or commented code lines, no debugging printouts, etc.)
[ ] Appropriate unit tests have been added, CI passes and code coverage is acceptable (did not decrease)
[ ] No large data files added in the whole history of commits(files should in sum not exceed 100 KB, avoid PDFs, Word docs, etc.)

Additional context
Please list additional information or things a reviewer should look out for.

Codecov Report
Patch and project coverage have no change.

Comparison is base (dfa7bfc) 92.81% compared to head (592d02c) 92.81%.

:exclamation: Your organization is not using the GitHub App Integration. As a result you may experience degraded service beginning May 15th. Please install the Github App Integration for your organization. Read more.
Additional details and impacted files
@@           Coverage Diff           @@
##             main     #686   +/-   ##
=======================================
  Coverage   92.81%   92.81%
=======================================
  Files         107      107
  Lines        8252     8252
=======================================
  Hits         7659     7659
  Misses        593      593

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


fixes remark lint issues

este PR resolve as (issues)[https://app.sourcelevel.io/github/Xerpa/bank_validator_br/reviews/4] de estilo geradas no sourcelevel.

Pull Request Test Coverage Report for Build 5172a9b1-af66-4920-8b13-65fac43f9fa1

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

Totals

Change from base Build 2e3130b5-33d2-4e86-876a-b8a5c37efd34:
0.0%

Covered Lines:
22

Relevant Lines:
31

💛  - Coveralls


Last Week in Pony - August 27, 2017

Gordon Tisher:
"So as a learning exercise I've implemented yet another PEG parsing library: https://github.com/kulibali/kiuatan  No use of actors, but it can handle left recursion.  No doubt has many beginner infelicities."

Andrew Turley:
VERY basic IRC server and client demo in Pony
https://github.com/aturley/pony-irc-demo

Andrew Turley:
"Pony Considerations"
"If you're thinking of checking out the Pony programming language, here's a list of things that I think are important to know. This list is based on a Tweet that I wrote."
https://gist.github.com/aturley/49b60c98306d90ffc2f981515827b005

DragonFly 4.8 support:
https://github.com/ponylang/ponyc/pull/2183

New RFC:
https://github.com/ponylang/rfcs/blob/master/text/0049-improved-itertools-api.md

Dev sync:
https://pony.groups.io/g/dev/files/Pony Sync/2017_08_23

0.18.1 released


List all trusted validator keys under single config section:

Trusted master public keys can be listed under either [validators] or [validator_keys] config sections
This allows rippled operators to list all trusted keys under the [validators] config section

Current coverage is 68.24%

Merging #1602 into develop will increase coverage by +0.09% as of 7fb9687

@@            develop   #1602   diff @@
=======================================
  Files           908     908
  Stmts         67295   67403   +108
  Branches          0       0
  Methods           0       0
=======================================
+ Hit           45862   45997   +135
  Partial           0       0
+ Missed        21433   21406    -27

Review entire Coverage Diff as of 7fb9687

Powered by Codecov. Updated on successful CI builds.

Impressive, and boosts coverage!

The code looks good to me. I think @nbougalis has a valid concern about allowing the same information in two different sections of the config. My gut is to keep them separate, but I need to think about it.

Looks a lot better and more robust with the latest changes. :+1:

:+1: @ximinez @wilsonianb
What do you think about removing the throw in ManifestCache::addTrustedKey? We're adding a key that already has a manifest, I don't see the harm.

@seelabs That works for me. The throw made more sense when addTrustedKey was only being called at startup when loading from [validator_keys]
I think it still makes sense keep the change to ManifestCache::load to have accurate permanent keys and manifest cache when possible.

@seelabs I am very weakly against it, since the check (particularly at startup) will help catch and prevent chained copy and paste errors.

@wilsonianb @ximinez OK, let's keep the throw for now.


[npm] add 'repo' key-value; adjust order

This will add a sidebar link on npmjs.org to this github repo.
Please excuse my re-ordering! ;-)

Thanks @luclu! Looks awesome to me :)


not working with android studio 3.6

build completes without apparent errors
debug install then throws an error and does not run:
Unable to determine application id: com.android.tools.idea.run.ApkProvisionException: No outputs for the main artifact of variant: debug

Yep, I have the same problem using Android Studio 3.6.
But it works good on Android Studio 4.0 Beta 3. Use this version instead if you can, probably I will not investigate that issue on 3.6 since it will be outdated soon.

I'm having the same issue on android studio 4.0 beta 3 as well...

Check that also you have updated version of android gradle plugin
classpath 'com.android.tools.build:gradle:4.0.0-beta03'

Ah, i hadn't done that.
Getting a new error now:
java.io.FileNotFoundException: /Users/meatball/dev/Aurora/build/build-attribution/androidGradlePluginAttributionData (No such file or directory)
0% :app:checkDebu?licateClasses (0:00.313)

/Users/meatball/dev/Aurora/build/build-attribution/androidGradlePluginAttributionData (No such file or directory)

Perform a clean task or do Build -> Rebuild project in AS when you see this error.
This is happening due to new Build Analyzer included into AS 4.0 and it doesnt work good with mirakle so far, will look for a fix.

Yup, that fixed it!
Thanks so much for the help!


Having error with scrcpy

scrcpy
scrcpy 2.4 https://github.com/Genymobile/scrcpy
INFO: ADB device found:
INFO:     --> (tcpip)  <IP_ADDRESS>:5555             device  Pixel_6a
/usr/local/share/scrcpy/scrcpy-server: 1 file pushed, 0 skipped. 0.9 MB/s (69007 bytes in 0.077s)
[server] INFO: Device: [Google] google Pixel 6a (Android 12)
X Error of failed request:  BadValue (integer parameter out of range for operation)
Major opcode of failed request:  148 (GLX)
Minor opcode of failed request:  3 (X_GLXCreateContext)
Value in failed request:  0x0
Serial number of failed request:  139
Current serial number in output stream:  140

#4155 #584


XCode 11: Can't find library libXCTestSwiftSupport.dylib when running tests

This appears to live in
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/usr/lib/

and I can get it to run if I add the following to the command line:
TEST_FRAMEWORK_SEARCH_PATHS=/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/usr/lib/

We get this too, but it's intermittent. Is that what you have @neotron ?

It happens persistently for me on every run.

Does this error happen when running Swift tests?

1.Update; our team used this solve;
Unit tests do not run on iOS 11 devices on Xcode 11 when using dynamically linked libraries · Issue #9165 · CocoaPods/CocoaPods: https://github.com/CocoaPods/CocoaPods/issues/9165#issuecomment-550273696
2.For me it was not actually intermittent
Xctool would always fail
xcodebuild by itself could pass
so it seems like an interaction, maybe xctool adds certain paths for us automagically @ExtremeMan ?
3.we are now still using xctool with fix [1] and all is well.
ty for a great project!

We have mixed ObjC / Swift tests, and the tests depend on a library with mixed objc/swift code.

@neotron  do you think you can give me a test project where it is reproducible? I created several examples myself and couldn't repro the issue.

Alternatively if you can build xctool locally, can you try this change: in XCToolUtil.m in function NSString *IOSTestFrameworkDirectories() add another entry to the array:
NSString *IOSTestFrameworkDirectories()
{
  NSArray *directories = @[
    [XcodeDeveloperDirPath() stringByAppendingPathComponent:@"Library/Frameworks"],
    [XcodeDeveloperDirPath<EMAIL_ADDRESS>    [XcodeDeveloperDirPath<EMAIL_ADDRESS>  ];
  return [directories componentsJoinedByString:@":"];
}

Another question I have - do you run logic or app tests? Because in case of app tests libXCTestSwiftSupport.dylib is part of app bundle.

And is it iOS or OS X target? Thanks!

I can see if I can get a reproducable setup. It's iOS / logic tests - not app bundle.

Thanks! Or if it is easier to try with a suggested fix I can live with that :)

For the test bundle - are tests in Swift, Objective-C or both?

It's a combination of Swift and Objective C - mostly ObjC. Same with the library where the actual code lives in.


javacomplete2 windows

I'm using vim 64bit on windows 7 (https://bintray.com/veegee/generic/vim_x64) and JDK 1.8u45 when i try to compile the server javacomplete#CompileJavavi()
i got an error as the path separator should be ";" but it is not aware of windows os and use unix one ":"
The vimrun call a wrong javac command :-1:
C:\Windows\system32\cmd.exe /c (javac -d C:/Users/XXX/.vim/bundle/vim-javacomplete2/libs/javavi/target/classes -classpath C:/Users/XXX/.vim/bundle/vim-javacomplete2/libs/javavi/target/classes:C:/Users/XXX/.vim/bundle/vim-javacomplete2/libs/javaparser.jar: -sourcepath C:/Users/XXX/.vim/bundle/vim-javacomplete2/libs/javavi/src/main/java: -g -nowarn -target 1.7 -source
1.7 -encoding UTF-8 C:/Users/XXX/.vim/bundle/vim-javacomplete2/libs/javavi/src/main/java/kg/ash/javavi/Javavi.java)
If I manually change the wrong ":" by ";" compilation is OK !

It seems in fact that adding sourcepath to classpath solve the issue !


Add a project named "Virtual Mouse": Oparating Through Hand Only

This is a project made by using Python and OpenCV-Python. This allow a user, control their system by only moving their handwithout any mouse.

Please assign me to add this to this particular repo under hacktoberfest.
And please add the label "hacktoberfest" and "hacktoberfest-accepted" to this issue.


Driving force and positive ions

When the driving force is negative, that's mean that the membrane potential is smaller that equilibrium potential. So, the positive ions tend to influx into the cell. and vice verse.

@Alkahwaji good catch!  Merging...


Disable hand tracking when using gamepad

Currently, with Oculus Mobile SDK v13, if the hand tracking capability is set in AndroidManifest.xml, it seems there isn't a way to disable hand tracking when the controllers are inactive.
If you want to use a gamepad, with ALVR you can disable the controllers input, but if the controllers are inactive, hand tracking is activated and when it glitches and one hand flies away, the guardian boundary pops up, and this can be distracting.

You mean an option like "allow only controller input"? I also noticed that if the quest switches to hand tracking and one or both hands are not tracked, they move to position 0,0 which is right in your face

No, that is another problem. Even if controller/hand tracking input is ignored in the client, the guardian boundary still pops up when hands exit the play area. A workaround is to disable guardian boundary in Oculus Quest settings.
This is a limitation of the SDK so no action can be taken now. I opened this issue just as a reminder for when a future SDK update will allow this to be fixed.

Duplicate of #255.


python310Packages.textual-dev: 1.2.1 -> 1.3.0

Automatic update generated by nixpkgs-update tools. This update was made based on information from passthru.updateScript.
meta.description for python310Packages.textual-dev is: Development tools for Textual
meta.homepage for python310Packages.textual-dev is: https://github.com/Textualize/textual-dev
Updates performed

Ran passthru.UpdateScript

To inspect upstream changes
Impact
Checks done

built on NixOS
The tests defined in passthru.tests, if any, passed
found 1.3.0 with grep in /nix/store/9a2mln83d665a4pqjgaz1yp732pl00a1-python3.10-textual-dev-1.3.0
found 1.3.0 in filename of file in /nix/store/9a2mln83d665a4pqjgaz1yp732pl00a1-python3.10-textual-dev-1.3.0

Rebuild report (if merged into master) (click to expand)

2 total rebuild path(s)

2 package rebuild(s)

First fifty rebuilds by attrpath
python310Packages.textual-dev
python311Packages.textual-dev

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/9a2mln83d665a4pqjgaz1yp732pl00a1-python3.10-textual-dev-1.3.0 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A python310Packages.textual-dev https://github.com/r-ryantm/nixpkgs/archive/89bd86ab27d7fff171f6d3918527aceaf26dcc57.tar.gz

Or:
nix build github:r-ryantm/nixpkgs/89bd86ab27d7fff171f6d3918527aceaf26dcc57#python310Packages.textual-dev

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/9a2mln83d665a4pqjgaz1yp732pl00a1-python3.10-textual-dev-1.3.0
ls -la /nix/store/9a2mln83d665a4pqjgaz1yp732pl00a1-python3.10-textual-dev-1.3.0/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
Result of nixpkgs-review run on x86_64-linux 1

2 packages built:

python310Packages.textual-dev
python311Packages.textual-dev

Maintainer pings
cc @YanniPapandreou for testing.

Looks good, happy to have this merged in