Automatically deleting old indexes using curator

Hi,
In order to sync my deleted row, I configured a timewindowed index on my elasticsearch-jdbc.
Here is the configuration:
curl -XPUT 'localhost:9200/_river/tags/_meta' -d
'{
"type": "jdbc",
"jdbc": {
"driver": "com.mysql.jdbc.Driver",
"url": "jdbc:mysql://localhost:3306/socialcrm_development",
"user": "root",
"password": "root",
"sql": " select books.id as "_id",  books.subject as "ticket", tags.text as "tags[text]" from books left join book_tags on books.id = book_tags.book_id left join tags on book_tags.tag_id = tags.id and tags.library_id = books.library_id;",
"poll": "30s",
"schedule": "0/30 * * ? * *"
},
"index_timewindow": true,
"index": {
"index": "'''tags-'''YYYY-MM-dd-HH",
"type": "tags"
}
}'
I expected curator will delete old timebased indexes, e.g tags-2015-08-17-00
But when I type curator show indices --all-indices, curator show this list instead:
2015-09-07 15:20:38,040 INFO      Job starting: show indices
2015-09-07 15:20:38,060 INFO      Matching all indices. Ignoring flags other than --exclude.
2015-09-07 15:20:38,060 INFO      Matching indices:
_river
jdbc
No timewindowed indices shown. Did I miss something?
Thanks before :)

Hi,
Found the bug on my script. Thanks!


Introduce activity logger configuration for the server

API looks the same way it looks for clients. :log-activity param includes LoggingHandler as a top-level handler.
To track operations on each child channels we still need to use pipeline-transform, I'm still not sure how to distinguish the two: maybe :child-log-activity? "Child" might be confusing as this term from Netty was never exposed before. :handler-log-activity?... even more confusing. As a simple workaround, we can set the same logger both for server and handlers. Less flexibility but that's probably what you need when debugging. @ztellman WDYT?
user=> (def s (http/start-server (fn [_] {:status 200}) {:port 2020 :log-activity :warn}))
#'user/s
[aleph-netty-server-event-pool-1] WARN aleph-server - [id: 0xe168e395] REGISTERED
[aleph-netty-server-event-pool-1] WARN aleph-server - [id: 0xe168e395] BIND: <IP_ADDRESS>/<IP_ADDRESS>:2020
[aleph-netty-server-event-pool-1] WARN aleph-server - [id: 0xe168e395, L:/0:0:0:0:0:0:0:0:2020] ACTIVE
[aleph-netty-server-event-pool-1] WARN aleph-server - [id: 0xe168e395, L:/0:0:0:0:0:0:0:0:2020] READ: [id: 0x0c71398b, L:/0:0:0:0:0:0:0:1:2020 - R:/0:0:0:0:0:0:0:1:54059]
[aleph-netty-server-event-pool-1] WARN aleph-server - [id: 0xe168e395, L:/0:0:0:0:0:0:0:0:2020] READ COMPLETE

P.S. This PR obviously conflicts with a few previous changes, e.g. Kqueue. Publishing this earlier not to lose once again :)

Approved, pending conflicts being resolved.

@ztellman Merged.

As of now, merging into 1.0.0 branch to accumulate pre-release changes there.


Filtered badge view

This fixes #685 by turning badge_details view into filtered view.
Filtered views have not only the obvious ability to filter, but they can also change ordering.

Nice!


added support for 'job_slice_count' on JTs

Closes #728

Coverage increased (+0.008%) to 64.401% when pulling d3f53e1094b0d568026bdf872841fea165b60606 on kfattig:job_slice_count into f2bcc3a3c545b2f4bf5b5e5771fea258ce136550 on ansible:master.


Remove git-diff detection logic.

CircleCI runs all its bash commands with -eo pipefail, so any command
that returns a non-zero exit code will cause the job to fail. In this
case, git-diff will return 1 if there are diffs. The solution is to
ignore git-diff and just create a commit, swallowing the exit code
(which is 1 if there are no diffs). If there is no diff, there will be
no commit, but git push will still return 0.

Submitted so I can merge this in the Sphinx changes.


[Searchable Snapshots] Correctly clone IndexInputs to avoid race

In PR #6345 I did remove a duplicate clone, however this resulted in cloning the IndexInput in the wrong place. When requesting a file that needs to be downloaded, we have a mechanism to ensure that concurrent calls do not end up duplicating the download, which results in multiple threads being given the same instance. The clone must happen after this point to ensure that each thread gets its own clone.
I've added a unit test that will reliably fail without the fix.
Check List

[x] New functionality includes testing.

[x] All tests pass

[x] New functionality has been documented.

[x] New functionality has javadoc added

[x] Commits are signed per the DCO using --signoff
[x] Commit changes are listed out in CHANGELOG.md file (See: Changelog)

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

Fixed up the spotless errors. Also, I ran the integration test in a loop over the weekend (which is how I found this bug) and it passed a total 11,440 of iterations with no failures, so I'm confident this is the fix the race I observed.

REPRODUCE WITH: ./gradlew ':server:test' --tests "org.opensearch.index.store.remote.utils.TransferManagerTests.testConcurrentAccess" -Dtests.seed=8617C6A8B33B1557 -Dtests.security.manager=true -Dtests.jvm.argline="-XX:TieredStopAtLevel=1 -XX:ReservedCodeCacheSize=64m" -Dtests.locale=ar-SA -Dtests.timezone=America/St_Lucia -Druntime.java=19

org.opensearch.index.store.remote.utils.TransferManagerTests > testConcurrentAccess FAILED
    java.lang.IllegalStateException: FileSystem Cache per segment capacity is less than single IndexInput default block size
        at __randomizedtesting.SeedInfo.seed([8617C6A8B33B1557:490AF9A9D2BEE804]:0)
        at org.opensearch.index.store.remote.filecache.FileCacheFactory.createFileCache(FileCacheFactory.java:56)
        at org.opensearch.index.store.remote.filecache.FileCacheFactory.createConcurrentLRUFileCache(FileCacheFactory.java:41)
        at org.opensearch.index.store.remote.utils.TransferManagerTests.<init>(TransferManagerTests.java:40)

The number of cache segments is based off of Runtime.getAvailableProcessors and wow we have some large machines running the CI workflows :). I'll change this to remove the non-determinism here.

org.opensearch.search.SearchWeightedRoutingIT.testSearchAggregationWithNetworkDisruption_FailOpenEnabled

#5957


Add init subcommand

Duplicate of #2 with a new fork. Now also includes the reworked spec command and formatting changes.

bors try

bors try

Bors is not working. I have to check the configuration.
It isn't necessary to create a new PR. You have only to update your branch JTS22:main

bors retry

bors cancel

bors try

bors try-

bors try

Ok, bors is now working. @JTS22 Please take a look on its results.
Currently, you start an init process within a cgroup and not in the namespace. What is the init process doing? The same staff, what the spawned process is doing in start?

bors try


Module resolution error when using components on npm packages

Summary
We have a project that was working before the changes on the module resolution. After the changes were merged and deployed, our project stopped working. We figured out that we need a new file called lwc.config.js on the root folder of the project where we need to define which components will be exported and the local modules folder. We figured out that we need to follow the RFC located at https://rfcs.lwc.dev/rfcs/lwc/0020-module-resolution.
After all this changes, we still can't reference our npm package project into our "client" project as it throws errors regarding missing components. Our folder structure looks like this:
NPM package structure (we called this package @test/lightning):
src
  |--> modules
             |--> lightning
                           |--> button
                                     |--> button.js
                                     |--> button.html
                           |--> primitiveButton
                                    |--> primitiveButton.js
                                    |--> primitiveButton.html
                           |--> primitiveIcon
                                    |--> primitiveIcon.js
                                    |--> primitiveIcon.html
                           |--> utils
                                    |--> utils.js
                           |--> utilsPrivate
                                    |--> utilsPrivate.js

NPM package lwc.config.js looks like this:
{
    "expose": [
        "lightning/button",
        "lightning/primitiveButton",
        "lightning/primitiveIcon",
        "lightning/utils",
        "lightning/utilsPrivate"
    ],
    "modules": [
        {
            "dir": "src/modules"
        }
    ]
}

Running this npm package project by itself works without any issue and we can use the tag <lightning-button />.
On our "client" project, we have installed the @test/lightning npm package and our folder structure looks like the boilerplate used by the create-lwc-app:
src
  |--> modules
             |--> my
                           |--> app
                                     |--> app.js
                                     |--> app.html

The lwc.config.js file looks like this:
{
    "modules": [
        {
            "npm": "@test/lightning"
        }
    ]
}

The app.html file looks like:
<template>
    <div class="center greeting">
        <lightning-button variant="base" label="Base" title="Looks like a link" class="slds-m-left_x-small">
        </lightning-button>
    </div>
</template>

After running using npm run watch, an error is thrown and the app won't run:
ERROR in<EMAIL_ADDRESS>Module not found: Error: Can't resolve 'lightning/primitiveButton' in '/Users/armandoruiz/Projects/new-lwc/resources/node_modules/@test/lightning/src/modules/lightning/button'
<EMAIL_ADDRESS>34:0-57 37:22-38
 @ ./src/modules/my/app/app.html
 @ ./src/modules/my/app/app.js
 @ ./src/index.js
 @ multi ./node_modules/error-overlay-webpack-plugin/lib/entry-basic.js ./node_modules/error-overlay-webpack-plugin/lib/entry-devserver.js? ./src/index.js

After looking into the module-resolver, we have found that indeed it locates the lightning/button, but not the components that this component references (lightning/primitiveButton and lightning/utils):
Module-resolver output when trying to locate the lightning/button:
{
  entry<EMAIL_ADDRESS>  specifier: 'lightning/button',
  scope: '/Users/armandoruiz/Projects/new-lwc/resources/node_modules/@test/lightning'
}

We also tried to add this to the lwc-services.config.js file:
    localModulesDirs: [
        './node_modules/@test/lightning/src/modules'
    ]

Steps To Reproduce:

Create a new lwc project using npm create-lwc-app.
Add 2 components. One component should reference the other component (parent/child)
Configure the lwc.config.js file and expose both parent and child component.
Create a second new lwc project.
Install the first project into this new project as an npm module.
Configure the lwc.config.js of the second project to use the exposed components from the first project
Use the parent component from the first project in the second project.

Expected result
The app should work and we should be able to use the components that are located in the npm package and it should also resolve child components.
Actual result
Resolver throws errors notifying that it can't locate other components referenced in the npm package.
Additional information
NPM package running on standalone mode:

Errors on client project

Also, it would be nice if all this changes and configurations can be documented, we spent some days trying to figure out what changed and where this lwc.config.js file came from.

Thanks for opening an issue.
First, try the beta channel on npmjs.com, the last version of lwc-services from two weeks ago should unblock you.
The implementation of the module resolution is documented for v2.0.7 in the changelog. That consuming 3rd party npm packages worked before was never supported by lwc-services, at it used an internal mechanism of the LWC module-resolver.
For documentation of LWC core features, like lwc.config.json, I'm referring to the LWC team and lwc.dev, as all functionality related to LWC in the tooling here depends on what is supported there.

I verified that using the 2.0.8-beta.1 works.

Had the same issue. Can confirm as well that 2.0.8-beta.1 works.

Thanks @muenzpraeger , the beta works perfect. Do you have an estimate on when it is going to be promoted?

@armandoisaac I plan/hope by end of this week latest.

I can confirm the issue has been fixed with release 2.1.0.
Thanks for your help René


build_deploy.sh and pr_check.sh for AppSRE CI/CD

build_deploy.sh will be executed in merge to master. It currently
builds and pushes to quay.
pr_check.sh currently doesn't do anything as the CI is done via
openshift-ci.

@dgoodwin we can put both scripts elsewhere if you want. We usually put them in the root, but it can go anywhere.
Also, adding a smoke test to pr_check.sh would be useful, even if real CI is done separately.

/lgtm

[test]

/retest


Public Access: Add a new setting for global activation

Current behavior
The new public access feature misses an additional setting for the superadmin to activate/deactivate the public access globally.
Wanted behavior
A new setting should be placed on organization level in settings > Superadmin settings > under 'enable chat globally'. Name of the setting should be 'Enable public access globally'. By activating it, the option to set a meeting as public access should be avaible in any meeting. If deactivated, the setting in the meetings should not be visible.

The new setting in the organization is also called enable anonymous.
The field should be used to hide the guest button in the login mask if it is not true.
@bastianjoel @m-schieder I cannot evaluate what changes would be needed in the auth service, if any, but I can imagine that we may want all anonymous users to be thrown out if the setting is turned off.
By the way, wouldn't it be better to leave the meeting setting visible and allow the user to manually turn it off if it was turned on before the the organization setting was turned off?


Update keys.ts

Add Language Spanish
Checklist
Please put "X" in the below checkboxes that apply::

[ ] If committing a bugfix, I have tested it in different browsers (Chrome, Firefox, Safari).
[ ] If committing a new feature, I have first submitted an issue (Please note: you are free to open PRs for non-issued features, but opening an issue increases your chance of a successful PR).
[ ] If committing a new feature, I have also written an appropriate test suite for it.

I have tested the following:

[x] Qalendar component in month mode.
[x] Qalendar component in week mode.
[x] Qalendar component in day mode.
[ ] All of the above modes on emulated mobile view.
[ ] Dragging and dropping events.
[ ] Resizing events in day/week modes.
[ ] Clicking events to open event dialog.

This PR solves the following problem**.
insert your description.
How to test this PR**.
For example:

Feed X and Y in the events-Prop.
Click Z or A.
Confirm that B is displayed.

Thanks for opening this pull request. This will only work for users with locale es-ES, however. In order for it to also work for  people with locales such as es-AR and es-MX, which are probably pretty widely used locales, you would also have to edit src/language/index.ts. Or does the language you added not work for Spanish in the American countries?

Ok, I can Add settings the Country


Opening Android app fresh from Branch.io link runs branch.subscribe callback function twice.

I'm having an issue on Android only where when I launch our app fresh (not resuming from background) from a Branch.io link the callback I provide to the branch.subscribe function get's called with the same bundle payload twice.
This only happens on Android, not on iOS, and I have verified that on the Android side the onNewIntent method is only called once when opening a Branch.io link while our app is backgrounded and onNewIntent isn't called at all when launching the app fresh from the same Branch.io link.
This leads me to believe that the problem is probably on the JS side. Any help or guidance on this would be very much appreciated.
Thanks!
react-native: 0.36.0
react-native-branch: 0.9.0

@jasonmerino Thanks for the info. This sounds like it might be related to another issue I was just working on: #73. The short answer is there is definitely something wrong in the JS layer, but it requires a little research to address it.
If you can use<EMAIL_ADDRESS>you can try a branch in this repo: resubscription-fix. That is a partial fix, at least, for the issue mentioned above. Trying it might at least produce some information, even if it doesn't completely fix your problem.

@jdee Thanks for the speedy response. :)
Upgrading to RN 0.40.0 is not on our roadmap right now as it will take a while since our app is quite large. Is there any hope of applying this patch to a 0.9.1 version of this repo?

@jasonmerino There's always hope.
I'm more immediately concerned about understanding your problem. I suspect you're running afoul of the same caching issue, but I don't know that, or why it doesn't happen on iOS. If you can't use 0.40.0 and are feeling adventurous, you can copy this file (src/index.js from the resubscription-fix branch) to node_modules/react-native-branch/src, restart the React packager and try it out. There were no source changes there in 1.0.0, so you should be able to drop it in.
Also, can I ask what version of Android you're using? It may have an impact, but mainly I'm trying to get an Android test environment going and want to make sure I'm looking at what you're looking at.
Thanks.

@jdee I have applied the src/index.js file to our project and restarted the packager and rebuilt the application. The same problem seems to be still present.
Emulator Android Version: 6.0
Device Android Version: 6.0.1

@jasonmerino Thanks for the info. How urgent is this problem for you? Would it be sufficient if we did a release 0.9.1 next week?
Thanks.

@jdee next week would definitely be acceptable. I'm not happy about my setTimeout workaround, but it will get the job done for now. :)

@jasonmerino I now have a working Android setup. I'm able to deploy a test app to a device or an emulator, both running Marshmallow, open App Links and be called back in JS. I've tried working with the development react-native server and also bundling the JS into the app. If I kill the app on the device or emulator and open an App Link to launch the app, the JS callback is never invoked more than once. I'm working with react-native-branch 1.0, but there were no changes to the JS or native Android code between 0.9 and 1.0. The only bug I'm aware of is that if you unsubscribe and resubscribe, you will receive the last link again after you resubscribe. That is fixed in 0.9.1. So in short, I'm not able to reproduce your problem.
Can you share any of your code to show how you're using the SDK? I wonder if anything other SDK calls could be interfering in some way.
Also, there are more intent receivers involved than just the activity that receives the link. In particular, there is a call here, around line 82 of node_modules/react-native-branch/android/src/main/java/io/branch/rnbranch/RNBranchModule.java. Can you confirm whether that is being called more than once? If that's not firing more than once, it has to be in the JS. But it's strange that this doesn't occur for you on iOS. That suggests it could be a matter of timing between the two native layers. But it's also strange that I can't produce the problem on Android, so I'm obviously not looking at what you're looking at.
Finally, there is a branch here called release-0.9.1, which is a preview of what will be released as 0.9.1. I don't think that will have any impact on your problem, but you can always try it out.

Hi @jdee I'm seeing this issue as well and could really use some help. Here is the information I can provide:
react-native: 0.42.0
react-native-branch: 1.1.1
My deep linking integration works fine on iOS but on android it opens the route twice.
I did some debugging and found that _onInitSessionResult is called twice. The first time it's called from the INIT_SESSION_SUCCESS listener nativeEventEmitter.addListener(INIT_SESSION_SUCCESS, this._onInitSessionResult) and the second time it's called when redeemInitSessionResult returns. Seems like the code wants this to happen so I'm not really understanding what's going wrong. Both times the result variable has the same value.
Let me know if I can provide any more information.

@timursadykhov Interesting. Thanks for investigating. I couldn't reproduce it when I last looked. I'll check again and see if I can reproduce it.
Incidentally, there is now a webview_example in the examples folder in master. That uses 2.0.0, but there are not many SDK differences between 1.1 and 2.0 yet, mainly just changes to the way things are built. The main difference on Android is that 2.0 includes a jar for the Branch SDK. This illustrates link routing, among other things. It would be interesting to know if you can reproduce the same problem with that app. You could test by setting up a new app in the Branch Dashboard with that package identifier (com.webview_example) and then set up intent-filters in the AndroidManifest.xml and modify the Branch key. Then just yarn or npm install and run. You can share links from the app, open and see if the callback fires twice.

@jdee okay, i'll try that out. in the meantime I can tell you that commenting out the line if (result) this._onInitSessionResult(result) fixes my issue and results in everything working as expected. For what scenario is that line necessary?

@timursadykhov I think you've done a better job of analyzing this code than I did. It looks to me like that call is unnecessary. The underlying issue is a race between initializing the Branch session in the native layer and loading the JS. The link that launched the app may already have been received by the native layer before the JS loads. That's the idea behind that call. However, there's also a cache used by the subscribe method.
I don't reproduce this problem with the webview_example, but that may be because it's small. If your app is large, and the JS doesn't finish loading until after the initial link has been received by the native layer, it looks like it will fire twice as is. And maybe it just loads faster on iOS, so the JS wins the race, and the callback only fires once.
I'll get this fixed and released. Thanks for the help. Branch would be happy to reward you with swag for your assistance. You can contact<EMAIL_ADDRESS>for details.

@jdee glad to help! :)
Your diagnosis sounds right to me. I was only seeing the issue about 90% of the time.

@timursadykhov There is now a branch called maintenance-1.1 that contains version 1.1.2 with this fix. Would you mind trying it out to see if it fixes your problem? It worked in the webview_example after adding delays here and there to simulate loading a large RN app.

@jdee sure thing, I'll do that tonight and get back to you

@timursadykhov If you're only calling subscribe once in your app, that branch will probably work. I think there's more work to do to support multiple subscribers properly. In short, the issue is fairly thorny, and there will probably be further iterations. I'd be interested to know how that branch works for you, but expect further changes before this is released.

@jdee Using the branch now and it's passed all my tests. We are indeed subscribing only once.
Since we need this fix I'm planning to continue using the maintenance-1.1 branch ... unless you have a different suggestion?

@jdee Actually I spoke too soon :)
The new RNBranch.redeemInitSessionResult() in subscribe is still causing a second call to my callback. Maybe the native cache isn't being cleared like expected?

@jdee okay i did some investigating, here's a breakdown of what's happening.
The order of events is as follows:

Native - sendRNEvent with RN_INIT_SESSION_EVENT is called from forwardInitSessionFinishedEventToReactNative

the event is immediately successfully emitted (i see Catalyst instance active in the console)

Javascript - RNBranch.redeemInitSessionResult is called in the subscribe method (time since launch here is on average 580ms)
Native - redeemInitSessionResult finishes and clears the cache
Javascript - _onInitSessionResult is called from our INIT_SESSION_SUCCESS listener in response to the event from 1

it still has a result since the event actually happened before we clear the cache in the redeemInitSessionResult call in 3

Javascript - the promise from 2 RNBranch.redeemInitSessionResult returns and calls our callback a second time

I don't really understand the code well enough to suggest any solutions though :)
My only thought is that maybe sendRNEvent should clear the cache itself in the RN_INIT_SESSION_EVENT since we know it's successful before redeemInitSessionResult is even called.

@timursadykhov Thanks for the testing and analysis. It's very helpful.
There are some other requirements that complicate matters:

Multiple subscription is supported. You can call branch.subscribe from multiple places in the JS and get back the same link events everywhere it's called. This includes any initial link cached by the native or JS layer.
Unsubscription/resubscription is supported. You can call the result of branch.subscribe to cancel your subscription, then call branch.subscribe again. You won't get the same link twice. In particular, after unsubscribing, when you resubscribe, you won't get the initial link again. This is the reason for the INIT_SESSION_TTL in index.js.
The only way I'm aware of to call the native layer from JS is asynchronously, via promises. There doesn't seem to be any support for synchronous calls, so things like getFirstReferringParams and createBranchUniversalObject, which are fundamentally synchronous, always have to be asynchronous. This is a big part of the problem. The way the JS layer is designed is fine, except that redeemInitSessionResult should be synchronous. Instead there's a race between the promise to that method and the call to the same method in subscribe. If these were both synchronous, I don't think there would be a problem.

The idea behind the current implementation, I believe, is that calls into the native layer are minimized. The native layer caches each response but only until it is retrieved by RNBranch.redeemInitSessionResult. Once this is called, it's up to the JS layer to cache. The JS layer handles the fanout to multiple listeners. Hence it maintains a cache at launch, in case of races and multiple subscriptions. After a few seconds, it voids the cache and stops caching.
Obviously this is a little complicated. I'd like to simplify it to make it simpler to understand and maintain. This will make greater use of the native layer and make the calls through a little more transparent. We can evaluate performance implications once it's working properly. If there is extra overhead to call the native layer, it will be at least partly offset by improved performance of operations performed by the native layer instead of JS.
The native layer already fans out notifications to multiple listeners by emitting an event. and the emitted result is never modified by the JS layer. The callback to subscribe can just be passed to addEventListener directly, and when unsubscribing, removeEventListener can be called. The _listeners can be removed from the Branch class in index.js.
The native cache can be changed so that rather than being cleared immediately on retrieval, it has the TTL currently used by the JS layer. Then the cache can be completely removed from the JS layer. When a cached value is needed, it can be retrieved asynchronously from the native layer and returned to the subscribe listener when that promise is resolved. There should then be no risk of getting the cached value twice.
 If you can confirm the fix, I can release quickly. Apologies for the trouble, and thanks for your patience and assistance.

@timursadykhov When you have a chance, can you please try the maintenance-1.1 branch again? I tested this on iOS and Android, with multiple subscriptions, unsubscribe/resubscribe. Everything worked well at app launch. Each subscribe callback was invoked once. It would be nice to know if this works with your app.

@jdee thanks for the great explanation. I had to switch focus for a bit to deal with a bug so I haven't had a chance to try this out. Will follow up once I do.

@timursadykhov Have you had a chance to look at these recent changes? Since I couldn't reproduce the issue directly, I'm curious to know how/if it addresses your problem. I'll release this as 1.1.2 if you can confirm.

@jdee So I finally had a chance to try out the new code and unfortunately it's not good news, I'm seeing the same issue. Do you need me to dig in and see what's happening?

@timursadykhov That's a shame. Can I just ask: Is it still happening 90% of the time? Is it sporadic?
There will always be a weakness because the call to retrieve the cache at initialization is asynchronous. If the API response from Branch happens to be returned at about the same time as the cache retrieval, there's a race between the promise and the live event. But that should not happen frequently or consistently.
I have some ideas to work around it, but since I can't consistently produce the problem that happens all the time for you, it's hard to know what will work.
Let me dig a little bit. I can simulate a large app loading by adding some setTimeouts here and there. If I can find a way produce your problem consistently, I should be able to fix it.
Sorry for the further delay. I'll have something else for you soon.

@jdee in my testing today it's been happening 95% of the time. Once out of about 20 or 30 tries it did not get called twice.

@timursadykhov I'm still not able to reproduce this problem at all, but I think you're not the only one experiencing it. I have a few things to try, but I don't want to keep wasting your time. It would be good to have a better idea of what's going on. Would you be interested in doing a screen-sharing session? Maybe I can see things more clearly if I can actually see what's happening in your app. Please contact me at<EMAIL_ADDRESS>to set this up if you'd like to do this.

Hey @jdee,
I'm also facing this issue on Android. Callback of subscribe is called twice every time I open the app for the first time. Also tried maintenance-1.1 branch but it's still happening :/

Hi @iDams. I'm sorry this is affecting you too. I spent some time with @timursadykhov the other day and found a solution that eliminated the problem. He wasn't able to produce it in at least ten tries. I want to review that solution thoroughly, which is why it hasn't been released yet. But since this is clearly not an isolated case, I'll get something into the master branch by the end of the day and release 2.0.0-beta.2 with the fix by the end of the week. If the fix proves to be solid, I can also release a patch to 1.1 and maybe 0.9. I appreciate your patience.

@jdee No worries ;)
Thanks for your work on it.

@iDams @timursadykhov 2.0.0-beta.2 is out with these changes. I'm skeptical because it's been so hard for me to produce and so persistent for you. I'm eager to know how this works for you.

@jdee It fixed it for me. Nice work! Thanks

Hi @iDams. It's good news that this fixed the problem for you. I want to review this fix a little more and then I'll probably release it as 1.1.2.
You can easily fix your mock issue, at least temporarily, by adding:
React.NativeModules.RNBranchEventEmitter = {};

But I think the right idea would be instead to mock the call to branch.subscribe instead of mocking the NativeModules. I really need to find a good mock framework for JS. It looks like jack had the right idea, but it hasn't been updated in five years and requires node < 0.7.
In order to simulate certain things in unit tests for these recent additions, I did some ad hoc mocking. See things like https://github.com/BranchMetrics/react-native-branch-deep-linking/blob/master/test/index.js#L45 and https://github.com/BranchMetrics/react-native-branch-deep-linking/blob/master/test/index.js#L81. The tests temporarily modify the NativeModules with mock methods and then restore the original methods and the end of the test. There are still some problems with those tests as they stand, but this basically works.
You could take a similar approach with branch, but you're not the only one who needs this. Maybe I can at least provide a branch mock you can plug into your unit tests so that it doesn't try to load NativeModules and just lets you call subscribe and other methods without actually doing anything.

Thanks @jdee
I did this in the end:
React.NativeModules.RNBranch = {
  redeemInitSessionResult: jest.fn().mockImplementation(() => Promise.resolve())
};

React.NativeModules.RNBranchEventEmitter = {};

But yeah you're right, the proper way should be to mock to subscribe.
Thanks for your exemple, it helped a lot.

@jdee sorry to be so slow in getting back to you. I finally did some testing with 2.0.0-beta.3 and I didn't see the issue in my android build a single time. It looks good to me!

Thanks @timursadykhov, and apparently I'm also slow.
I think backporting this fix to 1.1 or 0.9 will be tricky, and 2.0 is nearing a production release. If anyone desperately needs it, please comment/reopen or open a new issue. For now, I'm considering this issue closed.

I am getting the same issue, may I get the correct solution?


keypoint

Hi, I have a question about how to print the human keypoints information.

Hi! You can get them by accessing keypoints field of the Pose class.

Hope, it is helped.

Hope, it is helped.

Thank you very much.


The PROCESSORS property should be set for MPI tests

All tests that run in parallel with MPI should set the PROCESSOR property.
This would ensure they only run in parallel if enough slots are available.

In GitLab by @ksiero on Feb 5, 2021, 11:52
mentioned in commit 4dd4f66c8c87ccb2a3a6019f0d434fa6bd4efc00

In GitLab by @ksiero on Feb 5, 2021, 11:25
mentioned in commit ef5e1ec95c9acec8355612b0f4af8cffabe59035


fix(docs): typo

Describe this PR

Changes

What issue does this fix?

Any other relevant information

Thank you fixing this 🙏🏽


rancher container automatically restart

Environment information

Rancher version (rancher/rancher/rancher/server image tag or shown bottom left in the UI): v2.1.7
Installation option (single install/HA): Single
Rancher master: 4 Core and 32 GB RAM
OS: Cent OS v7.2

We have setup rancher behind nginx load balancer.
Cluster information

Kubernetes version (use kubectl version): v1.13.4
Docker version: v17.03

Two Clusters:
Cluster 1 : 3 (control plan + etcd) and 9 worker node {bare metal cluster}
Cluster 2 : 1 (control plan + etcd) and 4 worker node {AWS custom cluster}
Describe your issue here
Rancher docker container automatically restarts sometimes and working again after 2-5 minute. When I go through rancher container logs I found that it tries to connect with previously discarded clusters and when I do kubectl get cluster inside the rancher container it shows me actual clusters which are running right now.

2019/03/25 09:14:14 [ERROR] ClusterRoleTemplateBindingController c-65mlq/u-gjewqkidsl-admin [mgmt-auth-crtb-controller] failed with : cluster.management.cattle.io "c-65mlq" not found
2019/03/25 09:14:14 [ERROR] ClusterRoleTemplateBindingController c-f6ff8/u-27fgmzj2gc-admin [mgmt-auth-crtb-controller] failed with : cluster.management.cattle.io "c-f6ff8" not found
2019/03/25 09:14:14 [ERROR] ClusterRoleTemplateBindingController c-f6ff8/creator-cluster-owner [mgmt-auth-crtb-controller] failed with : cluster.management.cattle.io "c-f6ff8" not found
2019/03/25 09:14:14 [ERROR] ClusterRoleTemplateBindingController c-65mlq/creator-cluster-owner [mgmt-auth-crtb-controller] failed with : cluster.management.cattle.io "c-65mlq" not found
2019/03/25 09:14:14 [ERROR] ProjectRoleTemplateBindingController p-vbl4q/creator-project-owner [mgmt-auth-prtb-controller] failed with : cluster.management.cattle.io "c-f6ff8" not found
2019/03/25 09:14:14 [ERROR] ProjectRoleTemplateBindingController p-zxcm6/creator-project-owner [mgmt-auth-prtb-controller] failed with : cluster.management.cattle.io "c-f6ff8" not found
2019/03/25 09:14:14 [ERROR] ProjectRoleTemplateBindingController p-txhx4/creator-project-owner [mgmt-auth-prtb-controller] failed with : cluster.management.cattle.io "c-65mlq" not found
2019/03/25 09:14:14 [ERROR] ProjectRoleTemplateBindingController p-cwwj5/creator-project-owner [mgmt-auth-prtb-controller] failed with : cluster.management.cattle.io "c-65mlq" not found

More logs:

2019-03-26 12:06:10.788376 W | etcdserver: apply entries took too long [424.49928ms for 2 entries]
2019-03-26 12:06:10.788390 W | etcdserver: avoid queries with large range/delete range!
2019/03/26 12:06:11 [INFO] Handling backend connection request [c-dff54:m-bfdc4158a30e]
2019-03-26 12:06:12.573297 W | etcdserver: apply entries took too long [339.310121ms for 1 entries]
2019-03-26 12:06:12.573313 W | etcdserver: avoid queries with large range/delete range!
2019-03-26 12:06:13.505315 W | etcdserver: apply entries took too long [369.37636ms for 3 entries]
2019-03-26 12:06:13.505331 W | etcdserver: avoid queries with large range/delete range!
2019/03/26 12:06:14 [INFO] Handling backend connection request [c-dff54:m-1315e07dc5ec]
2019/03/26 12:06:14 [INFO] Handling backend connection request [c-dff54:m-ccc93da12a36]
2019-03-26 12:06:16.170085 W | etcdserver: apply entries took too long [267.092101ms for 1 entries]
2019-03-26 12:06:16.170106 W | etcdserver: avoid queries with large range/delete range!
2019-03-26 12:06:16.558331 W | etcdserver: apply entries took too long [205.133371ms for 1 entries]
2019-03-26 12:06:16.558347 W | etcdserver: avoid queries with large range/delete range!
2019/03/26 12:06:17 [INFO] Handling backend connection request [c-dff54:m-9e22b2ee2831]
2019-03-26 12:06:18.019339 W | etcdserver: apply entries took too long [361.148498ms for 2 entries]
2019-03-26 12:06:18.019356 W | etcdserver: avoid queries with large range/delete range!
2019-03-26 12:06:18.623408 W | etcdserver: apply entries took too long [484.676445ms for 2 entries]
2019-03-26 12:06:18.623425 W | etcdserver: avoid queries with large range/delete range!
2019/03/26 12:06:19 [INFO] Handling backend connection request [c-dff54:m-c7d796696cf1]
2019-03-26 12:06:19.041068 W | etcdserver: apply entries took too long [200.522982ms for 1 entries]
2019-03-26 12:06:19.041080 W | etcdserver: avoid queries with large range/delete range!
2019-03-26 12:06:19.637902 W | etcdserver: apply entries took too long [460.103476ms for 1 entries]
2019-03-26 12:06:19.637921 W | etcdserver: avoid queries with large range/delete range!
2019/03/26 12:06:19 [INFO] Handling backend connection request [c-mfhcs:m-2cea63ab2a6a]
2019/03/26 12:06:21 [INFO] error in remotedialer server [400]: read tcp <IP_ADDRESS>:80-><IP_ADDRESS>:58127: i/o timeout
2019-03-26 12:06:22.241450 W | etcdserver: apply entries took too long [342.221558ms for 1 entries]
2019-03-26 12:06:22.241466 W | etcdserver: avoid queries with large range/delete range!
2019-03-26 12:06:22.602398 W | etcdserver: apply entries took too long [239.658625ms for 1 entries]
2019-03-26 12:06:22.602412 W | etcdserver: avoid queries with large range/delete range!
2019-03-26 12:06:22.980555 W | etcdserver: apply entries took too long [149.843966ms for 1 entries]
2019-03-26 12:06:22.980573 W | etcdserver: avoid queries with large range/delete range!
2019/03/26 12:06:24 [INFO] error in remotedialer server [400]: read tcp <IP_ADDRESS>:80-><IP_ADDRESS>:58139: i/o timeout
2019/03/26 12:06:24 [INFO] Handling backend connection request [c-dff54:m-38c372163f76]
2019/03/26 12:06:24 [INFO] error in remotedialer server [400]: read tcp <IP_ADDRESS>:80-><IP_ADDRESS>:58149: i/o timeout
2019-03-26 12:06:27.459105 W | etcdserver: apply entries took too long [268.628818ms for 1 entries]
2019-03-26 12:06:27.459121 W | etcdserver: avoid queries with large range/delete range!
2019/03/26 12:06:27 [INFO] error in remotedialer server [400]: read tcp <IP_ADDRESS>:80-><IP_ADDRESS>:58168: i/o timeout
2019/03/26 12:06:28 [INFO] Handling backend connection request [c-dff54:m-7bca7509f24e]
2019-03-26 12:06:28.739896 W | etcdserver: apply entries took too long [168.948427ms for 1 entries]
2019-03-26 12:06:28.739908 W | etcdserver: avoid queries with large range/delete range!
2019/03/26 12:06:29 [INFO] error in remotedialer server [400]: read tcp <IP_ADDRESS>:80-><IP_ADDRESS>:58209: i/o timeout
2019-03-26 12:06:43.725945 W | etcdserver: apply entries took too long [261.598225ms for 2 entries]
2019-03-26 12:06:43.725959 W | etcdserver: avoid queries with large range/delete range!
2019-03-26 12:06:44.143208 W | etcdserver: apply entries took too long [256.128203ms for 1 entries]
2019-03-26 12:06:44.143224 W | etcdserver: avoid queries with large range/delete range!
2019/03/26 12:06:46 [INFO] Handling backend connection request [c-dff54:m-9e22b2ee2831]
2019/03/26 12:06:46 [INFO] Handling backend connection request [c-mfhcs:m-2cea63ab2a6a]
2019/03/26 12:06:48 [INFO] Handling backend connection request [c-dff54:m-bfdc4158a30e]
2019-03-26 12:06:48.943174 W | etcdserver: apply entries took too long [213.920486ms for 2 entries]
2019-03-26 12:06:48.943195 W | etcdserver: avoid queries with large range/delete range!
2019/03/26 12:06:50 [INFO] error in remotedialer server [400]: read tcp <IP_ADDRESS>:80-><IP_ADDRESS>:58402: i/o timeout
2019-03-26 12:06:51.518659 W | etcdserver: apply entries took too long [382.461301ms for 2 entries]
2019-03-26 12:06:51.518677 W | etcdserver: avoid queries with large range/delete range!
2019/03/26 12:06:52 [INFO] Handling backend connection request [c-dff54:m-38c372163f76]
2019/03/26 12:06:52 [INFO] Handling backend connection request [c-dff54:m-c7d796696cf1]
2019/03/26 12:06:52 [INFO] Handling backend connection request [c-dff54:m-ccc93da12a36]
2019-03-26 12:06:52.807235 W | etcdserver: apply entries took too long [228.375544ms for 1 entries]
2019-03-26 12:06:52.807247 W | etcdserver: avoid queries with large range/delete range!
2019-03-26 12:06:53.077726 I | mvcc: store.index: compact 82469770
2019-03-26 12:06:53.092246 W | etcdserver: apply entries took too long [283.021656ms for 1 entries]
2019-03-26 12:06:53.092261 W | etcdserver: avoid queries with large range/delete range!
2019-03-26 12:06:53.523657 W | etcdserver: apply entries took too long [246.604142ms for 1 entries]
2019-03-26 12:06:53.523674 W | etcdserver: avoid queries with large range/delete range!
2019-03-26 12:06:54.026949 W | etcdserver: apply entries took too long [241.677515ms for 1 entries]
2019-03-26 12:06:54.026963 W | etcdserver: avoid queries with large range/delete range!
2019/03/26 12:06:54 [INFO] Handling backend connection request [c-dff54:m-7bca7509f24e]
2019-03-26 12:06:54.587944 W | etcdserver: apply entries took too long [243.402263ms for 1 entries]
2019-03-26 12:06:54.587962 W | etcdserver: avoid queries with large range/delete range!
2019/03/26 12:06:56 [INFO] error in remotedialer server [400]: read tcp <IP_ADDRESS>:80-><IP_ADDRESS>:58475: i/o timeout
2019/03/26 12:06:56 [INFO] error in remotedialer server [400]: read tcp <IP_ADDRESS>:80-><IP_ADDRESS>:58479: i/o timeout
2019/03/26 12:06:58 [INFO] error in remotedialer server [400]: read tcp <IP_ADDRESS>:80-><IP_ADDRESS>:58495: i/o timeout
2019/03/26 12:07:02 [INFO] error in remotedialer server [400]: read tcp <IP_ADDRESS>:80-><IP_ADDRESS>:58541: i/o timeout
2019/03/26 12:07:02 [INFO] error in remotedialer server [400]: read tcp <IP_ADDRESS>:80-><IP_ADDRESS>:58543: i/o timeout
2019/03/26 12:07:02 [INFO] error in remotedialer server [400]: read tcp <IP_ADDRESS>:80-><IP_ADDRESS>:58545: i/o timeout
2019/03/26 12:07:04 [INFO] error in remotedialer server [400]: read tcp <IP_ADDRESS>:80-><IP_ADDRESS>:58578: i/o timeout
F0326 12:07:05.529144       7 controllermanager.go:247] leaderelection lost
2019/03/26 12:07:06 [INFO] Handling backend connection request [c-dff54:m-1315e07dc5ec]
2019-03-26 12:07:06.713199 W | wal: sync duration of 1.166671436s, expected less than 1s
goroutine 5086 [running]:
github.com/rancher/rancher/vendor/github.com/golang/glog.stacks(0xc047dd7200, 0xc03d12ec30, 0x4c, 0xf0)
        /go/src/github.com/rancher/rancher/vendor/github.com/golang/glog/glog.go:766 +0xd4
github.com/rancher/rancher/vendor/github.com/golang/glog.(*loggingT).output(0xb6fed40, 0xc000000003, 0xc075b46bb0, 0xb34d131, 0x14, 0xf7, 0x0)
        /go/src/github.com/rancher/rancher/vendor/github.com/golang/glog/glog.go:717 +0x306
github.com/rancher/rancher/vendor/github.com/golang/glog.(*loggingT).printf(0xb6fed40, 0x3, 0x57f1cce, 0x13, 0x0, 0x0, 0x0)
        /go/src/github.com/rancher/rancher/vendor/github.com/golang/glog/glog.go:655 +0x14b
github.com/rancher/rancher/vendor/github.com/golang/glog.Fatalf(0x57f1cce, 0x13, 0x0, 0x0, 0x0)
        /go/src/github.com/rancher/rancher/vendor/github.com/golang/glog/glog.go:1145 +0x67
github.com/rancher/rancher/vendor/k8s.io/kubernetes/cmd/kube-controller-manager/app.Run.func2()
        /go/src/github.com/rancher/rancher/vendor/k8s.io/kubernetes/cmd/kube-controller-manager/app/controllermanager.go:247 +0x47
github.com/rancher/rancher/vendor/k8s.io/client-go/tools/leaderelection.(*LeaderElector).Run.func1(0xc037440a50)
        /go/src/github.com/rancher/rancher/vendor/k8s.io/client-go/tools/leaderelection/leaderelection.go:163 +0x40
github.com/rancher/rancher/vendor/k8s.io/client-go/tools/leaderelection.(*LeaderElector).Run(0xc037440a50, 0x783b3a0, 0xc07169a940)
        /go/src/github.com/rancher/rancher/vendor/k8s.io/client-go/tools/leaderelection/leaderelection.go:172 +0x112
github.com/rancher/rancher/vendor/k8s.io/client-go/tools/leaderelection.RunOrDie(0x783b3e0, 0xc000074068, 0x7853e60, 0xc031a12900, 0x37e11d600, 0x2540be400, 0x77359400, 0xc030c51c40, 0x59f19f8, 0x0, ...)
        /go/src/github.com/rancher/rancher/vendor/k8s.io/client-go/tools/leaderelection/leaderelection.go:184 +0x99
github.com/rancher/rancher/vendor/k8s.io/kubernetes/cmd/kube-controller-manager/app.Run(0xc043ea2cb0, 0xc00018c0c0, 0xc03f98df60, 0xc03f98df00)
        /go/src/github.com/rancher/rancher/vendor/k8s.io/kubernetes/cmd/kube-controller-manager/app/controllermanager.go:239 +0x8c3
github.com/rancher/rancher/vendor/k8s.io/kubernetes/cmd/kube-controller-manager/app.NewControllerManagerCommand.func1(0xc03f754000, 0xb722d48, 0x0, 0x0)
        /go/src/github.com/rancher/rancher/vendor/k8s.io/kubernetes/cmd/kube-controller-manager/app/controllermanager.go:104 +0x1e5
github.com/rancher/rancher/vendor/github.com/spf13/cobra.(*Command).execute(0xc03f754000, 0xc0556a64e0, 0x0, 0x19, 0xc03f754000, 0xc0556a64e0)
        /go/src/github.com/rancher/rancher/vendor/github.com/spf13/cobra/command.go:760 +0x2cc
github.com/rancher/rancher/vendor/github.com/spf13/cobra.(*Command).ExecuteC(0xc03f754000, 0xc000090570, 0xc000090500, 0x0)
        /go/src/github.com/rancher/rancher/vendor/github.com/spf13/cobra/command.go:846 +0x2fd
github.com/rancher/rancher/vendor/github.com/spf13/cobra.(*Command).Execute(0xc03f754000, 0x42bf91, 0x59f70d0)
        /go/src/github.com/rancher/rancher/vendor/github.com/spf13/cobra/command.go:794 +0x2b
github.com/rancher/rancher/pkg/hyperkube.NewKubeControllerManager.func1(0xc0409850e0, 0xc0556a64e0, 0x0, 0x19, 0xc00018c0c0, 0xb60205, 0xc046d37210)
        /go/src/github.com/rancher/rancher/pkg/hyperkube/kube-controller-manager.go:44 +0x57
github.com/rancher/rancher/pkg/hyperkube.(*HyperKube).Run.func1(0xc03f951f80, 0xc0409850e0)
        /go/src/github.com/rancher/rancher/pkg/hyperkube/hyperkube.go:184 +0x76
created by github.com/rancher/rancher/pkg/hyperkube.(*HyperKube).Run
        /go/src/github.com/rancher/rancher/pkg/hyperkube/hyperkube.go:183 +0x4e6
E0326 12:07:05.529258       7 leaderelection.go:270] error retrieving resource lock kube-system/kube-controller-manager: Get https://<IP_ADDRESS>:6443/api/v1/namespaces/kube-system/endpoints/kube-controller-manager?timeout=10s: net/http: request canceled (Client.Timeout exceeded while awaiting headers)
E0326 12:07:05.529388       7 status.go:64] apiserver received an error that is not an metav1.Status: &errors.errorString{s:"context canceled"}
2019/03/26 12:07:22 [INFO] Rancher version v2.1.7 is starting
2019/03/26 12:07:22 [INFO] Rancher arguments {ACMEDomains:[] AddLocal:auto Embedded:false KubeConfig: HTTPListenPort:80 HTTPSListenPort:443 K8sMode:auto Debug:false NoCACerts:true ListenConfig: AuditLogPath:/var/log/auditlog/rancher-api-audit.log AuditLogMaxage:10 AuditLogMaxsize:100 AuditLogMaxbackup:10 AuditLevel:0}
2019/03/26 12:07:23 [INFO] Listening on /tmp/log.sock
2019/03/26 12:07:23 [INFO] Running etcd --peer-client-cert-auth --client-cert-auth --advertise-client-urls=https://<IP_ADDRESS>:2379,https://<IP_ADDRESS>:4001 --listen-peer-urls=https://<IP_ADDRESS>:2380 --trusted-ca-file=/etc/kubernetes/ssl/kube-ca.pem --peer-trusted-ca-file=/etc/kubernetes/ssl/kube-ca.pem --cert-file=/etc/kubernetes/ssl/kube-etcd-127-0-0-1.pem --peer-cert-file=/etc/kubernetes/ssl/kube-etcd-127-0-0-1.pem --heartbeat-interval=500 --peer-key-file=/etc/kubernetes/ssl/kube-etcd-127-0-0-1-key.pem --data-dir=/var/lib/rancher/etcd/ --initial-cluster-token=etcd-cluster-1 --listen-client-urls=https://<IP_ADDRESS>:2379 --initial-advertise-peer-urls=https://<IP_ADDRESS>:2380 --initial-cluster=etcd-master=https://<IP_ADDRESS>:2380 --key-file=/etc/kubernetes/ssl/kube-etcd-127-0-0-1-key.pem --name=etcd-master --initial-cluster-state=new --election-timeout=5000
2019-03-26 12:07:23.640638 I | etcdmain: etcd Version: 3.2.13
2019-03-26 12:07:23.640651 I | etcdmain: Git SHA: Not provided (use ./build instead of go build)
2019-03-26 12:07:23.640656 I | etcdmain: Go Version: go1.11
2019-03-26 12:07:23.640659 I | etcdmain: Go OS/Arch: linux/amd64
2019-03-26 12:07:23.640662 I | etcdmain: setting maximum number of CPUs to 8, total number of available CPUs is 8
2019-03-26 12:07:23.833362 N | etcdmain: the server is already initialized as member before, starting as etcd member...
2019-03-26 12:07:23.833406 I | embed: peerTLS: cert = /etc/kubernetes/ssl/kube-etcd-127-0-0-1.pem, key = /etc/kubernetes/ssl/kube-etcd-127-0-0-1-key.pem, ca = , trusted-ca = /etc/kubernetes/ssl/kube-ca.pem, client-cert-auth = true
2019-03-26 12:07:23.833839 I | embed: listening for peers on https://<IP_ADDRESS>:2380
2019-03-26 12:07:23.833878 I | embed: listening for client requests on <IP_ADDRESS>:2379
2019-03-26 12:07:24.834124 W | etcdserver: another etcd process is using "/var/lib/rancher/etcd/member/snap/db" and holds the file lock.
2019-03-26 12:07:24.834141 W | etcdserver: waiting for it to exit before starting...
2019-03-26 12:07:36.255402 I | etcdserver: recovered store from snapshot at index 84300847
2019-03-26 12:07:36.479878 I | mvcc: restore compact to 82467432
2019-03-26 12:07:37.054730 I | mvcc: store.index: compact 82469770
2019-03-26 12:07:37.071654 I | mvcc: resume scheduled compaction at 82469770
2019-03-26 12:07:37.167415 I | etcdserver: name = etcd-master
2019-03-26 12:07:37.167433 I | etcdserver: data dir = /var/lib/rancher/etcd/
2019-03-26 12:07:37.167439 I | etcdserver: member dir = /var/lib/rancher/etcd/member
2019-03-26 12:07:37.167443 I | etcdserver: heartbeat = 500ms
2019-03-26 12:07:37.167456 I | etcdserver: election = 5000ms
2019-03-26 12:07:37.167459 I | etcdserver: snapshot count = 100000
2019-03-26 12:07:37.167484 I | etcdserver: advertise client URLs = https://<IP_ADDRESS>:2379,https://<IP_ADDRESS>:4001
2019-03-26 12:07:37.167550 W | wal: ignored file<PHONE_NUMBER>004220-0000000004f3f765.wal.broken in wal
2019-03-26 12:07:46.689376 I | etcdserver: restarting member e92d66acd89ecf29 in cluster 7581d6eb2d25405b at commit index 84328389
2019-03-26 12:07:46.690325 I | raft: e92d66acd89ecf29 became follower at term 204
2019-03-26 12:07:46.690344 I | raft: newRaft e92d66acd89ecf29 [peers: [e92d66acd89ecf29], term: 204, commit: 84328389, applied: 84300847, lastindex: 84328389, lastterm: 204]
2019-03-26 12:07:46.690462 I | etcdserver/api: enabled capabilities for version 3.2
2019-03-26 12:07:46.690474 I | etcdserver/membership: added member e92d66acd89ecf29 [https://<IP_ADDRESS>:2380] to cluster 7581d6eb2d25405b from store
2019-03-26 12:07:46.690482 I | etcdserver/membership: set the cluster version to 3.2 from store
2019-03-26 12:07:47.169383 I | mvcc: restore compact to 82467432
2019-03-26 12:07:47.544831 I | mvcc: store.index: compact 82469770
2019-03-26 12:07:47.561772 I | mvcc: resume scheduled compaction at 82469770
2019-03-26 12:07:47.561805 W | auth: simple token is not cryptographically signed
2019-03-26 12:07:48.435450 I | etcdserver: starting server... [version: 3.2.13, cluster version: 3.2]
2019-03-26 12:07:48.435853 I | embed: ClientTLS: cert = /etc/kubernetes/ssl/kube-etcd-127-0-0-1.pem, key = /etc/kubernetes/ssl/kube-etcd-127-0-0-1-key.pem, ca = , trusted-ca = /etc/kubernetes/ssl/kube-ca.pem, client-cert-auth = true
2019-03-26 12:07:49.414895 I | mvcc: finished scheduled compaction at 82469770 (took 1.853045255s)
2019-03-26 12:07:50.690709 I | raft: e92d66acd89ecf29 is starting a new election at term 204
2019-03-26 12:07:50.769677 I | raft: e92d66acd89ecf29 became candidate at term 205
2019-03-26 12:07:50.769692 I | raft: e92d66acd89ecf29 received MsgVoteResp from e92d66acd89ecf29 at term 205
2019-03-26 12:07:50.769707 I | raft: e92d66acd89ecf29 became leader at term 205
2019-03-26 12:07:50.769714 I | raft: raft.node: e92d66acd89ecf29 elected leader e92d66acd89ecf29 at term 205
2019-03-26 12:07:50.769997 I | embed: ready to serve client requests
2019-03-26 12:07:50.770058 I | etcdserver: published {Name:etcd-master ClientURLs:[https://<IP_ADDRESS>:2379 https://<IP_ADDRESS>:4001]} to cluster 7581d6eb2d25405b
2019-03-26 12:07:50.770164 I | embed: serving client requests on [::]:2379
2019/03/26 12:07:51 [INFO] Running kube-apiserver --service-node-port-range=30000-32767 --requestheader-group-headers= --requestheader-username-headers= --kubelet-preferred-address-types=InternalIP,ExternalIP,Hostname --requestheader-allowed-names= --client-ca-file=/etc/kubernetes/ssl/kube-ca.pem --tls-cert-file=/etc/kubernetes/ssl/kube-apiserver.pem --etcd-certfile=/etc/kubernetes/ssl/kube-node.pem --enable-admission-plugins=NamespaceLifecycle,LimitRanger,ServiceAccount,DefaultStorageClass,DefaultTolerationSeconds,MutatingAdmissionWebhook,ValidatingAdmissionWebhook,ResourceQuota --secure-port=6443 --allow-privileged=true --authorization-mode=Node,RBAC --advertise-address=<IP_ADDRESS> --service-account-key-file=/etc/kubernetes/ssl/kube-apiserver-key.pem --etcd-servers=https://<IP_ADDRESS>:2379 --service-cluster-ip-range=<IP_ADDRESS>/16 --etcd-prefix=/registry --tls-cipher-suites=TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305 --insecure-bind-address=<IP_ADDRESS> --insecure-port=0 --endpoint-reconciler-type=lease --bind-address=<IP_ADDRESS> --requestheader-extra-headers-prefix= --proxy-client-cert-file= --cloud-provider= --kubelet-client-certificate=/etc/kubernetes/ssl/kube-apiserver.pem --kubelet-client-key=/etc/kubernetes/ssl/kube-apiserver-key.pem --etcd-cafile=/etc/kubernetes/ssl/kube-ca.pem --etcd-keyfile=/etc/kubernetes/ssl/kube-node-key.pem --requestheader-client-ca-file= --proxy-client-key-file= --storage-backend=etcd3 --tls-private-key-file=/etc/kubernetes/ssl/kube-apiserver-key.pem -v=1 --logtostderr=false --alsologtostderr=false
2019/03/26 12:07:51 [INFO] Activating driver eks
2019/03/26 12:07:51 [INFO] Activating driver eks done
2019/03/26 12:07:51 [INFO] Activating driver import
2019/03/26 12:07:51 [INFO] Activating driver import done
2019/03/26 12:07:51 [INFO] Activating driver rke
2019/03/26 12:07:51 [INFO] Activating driver rke done
2019/03/26 12:07:51 [INFO] Activating driver gke
2019/03/26 12:07:51 [INFO] Activating driver gke done
2019/03/26 12:07:51 [INFO] Activating driver aks
2019/03/26 12:07:51 [INFO] Activating driver aks done
[restful] 2019/03/26 12:07:58 log.go:33: [restful/swagger] listing is available at https://<IP_ADDRESS>:6443/swaggerapi
[restful] 2019/03/26 12:07:58 log.go:33: [restful/swagger] https://<IP_ADDRESS>:6443/swaggerui/ is mapped to folder /swagger-ui/
[restful] 2019/03/26 12:07:59 log.go:33: [restful/swagger] listing is available at https://<IP_ADDRESS>:6443/swaggerapi
[restful] 2019/03/26 12:07:59 log.go:33: [restful/swagger] https://<IP_ADDRESS>:6443/swaggerui/ is mapped to folder /swagger-ui/
2019/03/26 12:08:02 [INFO] Waiting for server to become available: Get https://<IP_ADDRESS>:6443/version?timeout=32s: net/http: TLS handshake timeout
2019/03/26 12:08:02 [INFO] Waiting for server to become available: Get https://<IP_ADDRESS>:6443/version?timeout=30s: net/http: TLS handshake timeout
2019-03-26 12:08:03.975867 W | etcdserver: apply entries took too long [195.61086ms for 1 entries]
2019-03-26 12:08:03.975881 W | etcdserver: avoid queries with large range/delete range!
2019/03/26 12:08:05 [INFO] Running kube-controller-manager --enable-hostpath-provisioner=false --pod-eviction-timeout=5m0s --cloud-provider= --service-account-private-key-file=/etc/kubernetes/ssl/kube-apiserver-key.pem --leader-elect=true --node-monitor-grace-period=40s --kubeconfig=/etc/kubernetes/ssl/kubecfg-kube-controller-manager.yaml --configure-cloud-routes=false --v=2 --allocate-node-cidrs=true --service-cluster-ip-range=<IP_ADDRESS>/16 --root-ca-file=/etc/kubernetes/ssl/kube-ca.pem --address=<IP_ADDRESS> --allow-untagged-cloud=true --cluster-cidr=<IP_ADDRESS>/16 --use-service-account-credentials=true -v=1 --logtostderr=false --alsologtostderr=false --controllers * --controllers -resourcequota --controllers -service
2019-03-26 12:08:05.345700 W | etcdserver: apply entries took too long [1.213300374s for 1 entries]
2019-03-26 12:08:05.345716 W | etcdserver: avoid queries with large range/delete range!
2019/03/26 12:08:05 [INFO] Running in single server mode, will not peer connections
2019/03/26 12:08:06 [INFO] Starting API controllers
2019/03/26 12:08:06 [INFO] Listening on :443
2019/03/26 12:08:06 [INFO] Listening on :80
2019/03/26 12:08:06 [INFO] Starting catalog controller
2019-03-26 12:08:07.092093 W | etcdserver: apply entries took too long [339.594194ms for 1 entries]
2019-03-26 12:08:07.092108 W | etcdserver: avoid queries with large range/delete range!
2019/03/26 12:08:07 [INFO] Starting management controllers
2019/03/26 12:08:07 [INFO] Stopping cluster agent for c-dff54
2019-03-26 12:08:08.148875 W | etcdserver: apply entries took too long [261.807919ms for 1 entries]
2019-03-26 12:08:08.148892 W | etcdserver: avoid queries with large range/delete range!
2019/03/26 12:08:08 [INFO] Stopping cluster agent for c-mfhcs
2019/03/26 12:08:08 [INFO] Stopping cluster agent for c-dff54
2019/03/26 12:08:08 [INFO] Stopping cluster agent for c-mfhcs
2019/03/26 12:08:08 [INFO] Stopping cluster agent for c-mfhcs
2019/03/26 12:08:08 [INFO] Stopping cluster agent for c-dff54
2019/03/26 12:08:08 [INFO] Stopping cluster agent for c-dff54
2019/03/26 12:08:08 [INFO] Stopping cluster agent for c-mfhcs
2019/03/26 12:08:08 [INFO] Stopping cluster agent for c-dff54
2019/03/26 12:08:08 [INFO] Stopping cluster agent for c-mfhcs
2019/03/26 12:08:09 [INFO] Stopping cluster agent for c-dff54
2019/03/26 12:08:09 [INFO] Stopping cluster agent for c-mfhcs
2019/03/26 12:08:10 [INFO] Handling backend connection request [c-mfhcs:m-2cea63ab2a6a]
2019/03/26 12:08:11 [INFO] Handling backend connection request [c-dff54:m-5b9de42bf3fa]
2019/03/26 12:08:11 [INFO] Handling backend connection request [c-dff54:m-78882aaeb08e]
2019/03/26 12:08:11 [INFO] Handling backend connection request [c-dff54:m-d5802d05bbf0]
2019/03/26 12:08:11 [INFO] Handling backend connection request [c-dff54]
2019/03/26 12:08:13 [INFO] Handling backend connection request [c-dff54:m-2925bf35562c]
2019/03/26 12:08:13 [INFO] Handling backend connection request [c-dff54:m-c7d796696cf1]
2019/03/26 12:08:13 [INFO] Handling backend connection request [c-dff54:m-bfdc4158a30e]
2019/03/26 12:08:13 [INFO] Handling backend connection request [c-dff54:m-7bca7509f24e]
2019/03/26 12:08:14 [INFO] Handling backend connection request [c-dff54:m-38c372163f76]
2019/03/26 12:08:14 [INFO] Handling backend connection request [c-dff54:m-ccc93da12a36]
2019/03/26 12:08:14 [INFO] Handling backend connection request [c-dff54:m-8b8ecfb94d1e]
2019/03/26 12:08:15 [INFO] Handling backend connection request [c-dff54:m-9e22b2ee2831]
2019-03-26 12:08:16.185268 W | etcdserver: apply entries took too long [266.972774ms for 1 entries]
2019-03-26 12:08:16.185284 W | etcdserver: avoid queries with large range/delete range!
2019/03/26 12:08:16 [INFO] Handling backend connection request [c-mfhcs:m-781bbf170c8b]
2019/03/26 12:08:16 [INFO] Handling backend connection request [c-mfhcs:m-f7dc54811da4]
2019/03/26 12:08:16 [INFO] Handling backend connection request [c-mfhcs:m-48773c97db93]
2019/03/26 12:08:16 [INFO] Handling backend connection request [c-mfhcs:m-d18bcbb274ca]
2019/03/26 12:08:17 [INFO] Handling backend connection request [c-mfhcs]
2019/03/26 12:08:17 [INFO] Reconciling GlobalRoles
2019/03/26 12:08:17 [INFO] Reconciling RoleTemplates
2019/03/26 12:08:17 [ERROR] ProjectRoleTemplateBindingController p-vbl4q/creator-project-owner [mgmt-auth-prtb-controller] failed with : cluster.management.cattle.io "c-f6ff8" not found
2019/03/26 12:08:17 [ERROR] ProjectRoleTemplateBindingController p-cwwj5/creator-project-owner [mgmt-auth-prtb-controller] failed with : cluster.management.cattle.io "c-65mlq" not found
2019/03/26 12:08:17 [ERROR] ProjectRoleTemplateBindingController p-zxcm6/creator-project-owner [mgmt-auth-prtb-controller] failed with : cluster.management.cattle.io "c-f6ff8" not found
2019/03/26 12:08:17 [ERROR] ClusterRoleTemplateBindingController c-f6ff8/creator-cluster-owner [mgmt-auth-crtb-controller] failed with : cluster.management.cattle.io "c-f6ff8" not found
2019/03/26 12:08:17 [ERROR] ClusterRoleTemplateBindingController c-f6ff8/u-27fgmzj2gc-admin [mgmt-auth-crtb-controller] failed with : cluster.management.cattle.io "c-f6ff8" not found
2019/03/26 12:08:17 [ERROR] ClusterRoleTemplateBindingController c-65mlq/creator-cluster-owner [mgmt-auth-crtb-controller] failed with : cluster.management.cattle.io "c-65mlq" not found
2019/03/26 12:08:17 [ERROR] ClusterRoleTemplateBindingController c-65mlq/u-gjewqkidsl-admin [mgmt-auth-crtb-controller] failed with : cluster.management.cattle.io "c-65mlq" not found
2019/03/26 12:08:17 [ERROR] ProjectRoleTemplateBindingController p-txhx4/creator-project-owner [mgmt-auth-prtb-controller] failed with : cluster.management.cattle.io "c-65mlq" not found
2019/03/26 12:08:18 [ERROR] ProjectRoleTemplateBindingController p-vbl4q/creator-project-owner [mgmt-auth-prtb-controller] failed with : cluster.management.cattle.io "c-f6ff8" not found
2019/03/26 12:08:18 [ERROR] ProjectRoleTemplateBindingController p-cwwj5/creator-project-owner [mgmt-auth-prtb-controller] failed with : cluster.management.cattle.io "c-65mlq" not found
2019/03/26 12:08:18 [ERROR] ProjectRoleTemplateBindingController p-zxcm6/creator-project-owner [mgmt-auth-prtb-controller] failed with : cluster.management.cattle.io "c-f6ff8" not found
2019/03/26 12:08:18 [ERROR] ClusterRoleTemplateBindingController c-f6ff8/creator-cluster-owner [mgmt-auth-crtb-controller] failed with : cluster.management.cattle.io "c-f6ff8" not found
2019/03/26 12:08:18 [ERROR] ClusterRoleTemplateBindingController c-f6ff8/u-27fgmzj2gc-admin [mgmt-auth-crtb-controller] failed with : cluster.management.cattle.io "c-f6ff8" not found
2019/03/26 12:08:18 [ERROR] ClusterRoleTemplateBindingController c-65mlq/creator-cluster-owner [mgmt-auth-crtb-controller] failed with : cluster.management.cattle.io "c-65mlq" not found
2019/03/26 12:08:18 [ERROR] ClusterRoleTemplateBindingController c-65mlq/u-gjewqkidsl-admin [mgmt-auth-crtb-controller] failed with : cluster.management.cattle.io "c-65mlq" not found
2019/03/26 12:08:18 [ERROR] ProjectRoleTemplateBindingController p-txhx4/creator-project-owner [mgmt-auth-prtb-controller] failed with : cluster.management.cattle.io "c-65mlq" not found
2019-03-26 12:08:18.697886 W | etcdserver: apply entries took too long [353.422841ms for 1 entries]
2019-03-26 12:08:18.697902 W | etcdserver: avoid queries with large range/delete range!
2019/03/26 12:08:19 [ERROR] ProjectRoleTemplateBindingController p-vbl4q/creator-project-owner [mgmt-auth-prtb-controller] failed with : cluster.management.cattle.io "c-f6ff8" not found
2019/03/26 12:08:19 [ERROR] ProjectRoleTemplateBindingController p-cwwj5/creator-project-owner [mgmt-auth-prtb-controller] failed with : cluster.management.cattle.io "c-65mlq" not found
2019/03/26 12:08:19 [ERROR] ProjectRoleTemplateBindingController p-zxcm6/creator-project-owner [mgmt-auth-prtb-controller] failed with : cluster.management.cattle.io "c-f6ff8" not found
2019/03/26 12:08:19 [ERROR] ClusterRoleTemplateBindingController c-f6ff8/u-27fgmzj2gc-admin [mgmt-auth-crtb-controller] failed with : cluster.management.cattle.io "c-f6ff8" not found
2019/03/26 12:08:19 [ERROR] ClusterRoleTemplateBindingController c-f6ff8/creator-cluster-owner [mgmt-auth-crtb-controller] failed with : cluster.management.cattle.io "c-f6ff8" not found
2019/03/26 12:08:19 [ERROR] ClusterRoleTemplateBindingController c-65mlq/creator-cluster-owner [mgmt-auth-crtb-controller] failed with : cluster.management.cattle.io "c-65mlq" not found
2019/03/26 12:08:19 [ERROR] ClusterRoleTemplateBindingController c-65mlq/u-gjewqkidsl-admin [mgmt-auth-crtb-controller] failed with : cluster.management.cattle.io "c-65mlq" not found
2019/03/26 12:08:19 [ERROR] ProjectRoleTemplateBindingController p-txhx4/creator-project-owner [mgmt-auth-prtb-controller] failed with : cluster.management.cattle.io "c-65mlq" not found
2019/03/26 12:08:20 [INFO] error in remotedialer server [400]: read tcp <IP_ADDRESS>:80-><IP_ADDRESS>:46327: i/o timeout
2019-03-26 12:08:20.150611 W | etcdserver: apply entries took too long [307.933778ms for 1 entries]
2019-03-26 12:08:20.150626 W | etcdserver: avoid queries with large range/delete range!
2019/03/26 12:08:21 [ERROR] ProjectRoleTemplateBindingController p-vbl4q/creator-project-owner [mgmt-auth-prtb-controller] failed with : cluster.management.cattle.io "c-f6ff8" not found
2019/03/26 12:08:21 [ERROR] ProjectRoleTemplateBindingController p-cwwj5/creator-project-owner [mgmt-auth-prtb-controller] failed with : cluster.management.cattle.io "c-65mlq" not found
2019/03/26 12:08:21 [ERROR] ProjectRoleTemplateBindingController p-zxcm6/creator-project-owner [mgmt-auth-prtb-controller] failed with : cluster.management.cattle.io "c-f6ff8" not found
2019/03/26 12:08:21 [ERROR] ClusterRoleTemplateBindingController c-f6ff8/u-27fgmzj2gc-admin [mgmt-auth-crtb-controller] failed with : cluster.management.cattle.io "c-f6ff8" not found
2019/03/26 12:08:21 [ERROR] ClusterRoleTemplateBindingController c-f6ff8/creator-cluster-owner [mgmt-auth-crtb-controller] failed with : cluster.management.cattle.io "c-f6ff8" not found
2019/03/26 12:08:21 [ERROR] ClusterRoleTemplateBindingController c-65mlq/creator-cluster-owner [mgmt-auth-crtb-controller] failed with : cluster.management.cattle.io "c-65mlq" not found
2019/03/26 12:08:21 [ERROR] ClusterRoleTemplateBindingController c-65mlq/u-gjewqkidsl-admin [mgmt-auth-crtb-controller] failed with : cluster.management.cattle.io "c-65mlq" not found
2019/03/26 12:08:21 [ERROR] ProjectRoleTemplateBindingController p-txhx4/creator-project-owner [mgmt-auth-prtb-controller] failed with : cluster.management.cattle.io "c-65mlq" not found
2019/03/26 12:08:22 [INFO] Registering project network policy
2019/03/26 12:08:22 [INFO] Registering namespaceHandler for adding labels
2019/03/26 12:08:22 [INFO] registering podsecuritypolicy cluster handler for cluster c-mfhcs
2019/03/26 12:08:22 [INFO] registering podsecuritypolicy project handler for cluster c-mfhcs
2019/03/26 12:08:22 [INFO] registering podsecuritypolicy namespace handler for cluster c-mfhcs
2019/03/26 12:08:22 [INFO] registering podsecuritypolicy serviceaccount handler for cluster c-mfhcs
2019/03/26 12:08:22 [INFO] registering podsecuritypolicy template handler for cluster c-mfhcs
2019/03/26 12:08:22 [INFO] Handling backend connection request [c-dff54:m-1315e07dc5ec]
2019/03/26 12:08:23 [INFO] Starting cluster controllers for c-mfhcs
2019/03/26 12:08:23 [INFO] Rancher startup complete
2019/03/26 12:08:23 [INFO] error in remotedialer server [400]: read tcp <IP_ADDRESS>:80-><IP_ADDRESS>:46774: i/o timeout
2019/03/26 12:08:23 [INFO] error in remotedialer server [400]: read tcp <IP_ADDRESS>:80-><IP_ADDRESS>:46776: i/o timeout
2019/03/26 12:08:23 [INFO] error in remotedialer server [400]: read tcp <IP_ADDRESS>:80-><IP_ADDRESS>:46778: i/o timeout
2019/03/26 12:08:24 [INFO] error in remotedialer server [400]: read tcp <IP_ADDRESS>:80-><IP_ADDRESS>:46780: i/o timeout
2019/03/26 12:08:24 [INFO] error in remotedialer server [400]: read tcp <IP_ADDRESS>:80-><IP_ADDRESS>:46782: i/o timeout
2019/03/26 12:08:24 [INFO] error in remotedialer server [400]: read tcp <IP_ADDRESS>:80-><IP_ADDRESS>:46784: i/o timeout
2019/03/26 12:08:25 [ERROR] ProjectRoleTemplateBindingController p-vbl4q/creator-project-owner [mgmt-auth-prtb-controller] failed with : cluster.management.cattle.io "c-f6ff8" not found
2019/03/26 12:08:25 [ERROR] ProjectRoleTemplateBindingController p-cwwj5/creator-project-owner [mgmt-auth-prtb-controller] failed with : cluster.management.cattle.io "c-65mlq" not found
2019/03/26 12:08:25 [ERROR] ProjectRoleTemplateBindingController p-zxcm6/creator-project-owner [mgmt-auth-prtb-controller] failed with : cluster.management.cattle.io "c-f6ff8" not found
2019/03/26 12:08:25 [ERROR] ClusterRoleTemplateBindingController c-f6ff8/u-27fgmzj2gc-admin [mgmt-auth-crtb-controller] failed with : cluster.management.cattle.io "c-f6ff8" not found
2019/03/26 12:08:25 [ERROR] ClusterRoleTemplateBindingController c-f6ff8/creator-cluster-owner [mgmt-auth-crtb-controller] failed with : cluster.management.cattle.io "c-f6ff8" not found
2019/03/26 12:08:25 [ERROR] ClusterRoleTemplateBindingController c-65mlq/creator-cluster-owner [mgmt-auth-crtb-controller] failed with : cluster.management.cattle.io "c-65mlq" not found
2019/03/26 12:08:25 [ERROR] ClusterRoleTemplateBindingController c-65mlq/u-gjewqkidsl-admin [mgmt-auth-crtb-controller] failed with : cluster.management.cattle.io "c-65mlq" not found
2019/03/26 12:08:25 [ERROR] ProjectRoleTemplateBindingController p-txhx4/creator-project-owner [mgmt-auth-prtb-controller] failed with : cluster.management.cattle.io "c-65mlq" not found
2019/03/26 12:08:25 [INFO] error in remotedialer server [400]: read tcp <IP_ADDRESS>:80-><IP_ADDRESS>:46879: i/o timeout
2019-03-26 12:08:25.984474 W | etcdserver: apply entries took too long [326.025909ms for 1 entries]
2019-03-26 12:08:25.984490 W | etcdserver: avoid queries with large range/delete range!
2019/03/26 12:08:26 [INFO] error in remotedialer server [400]: read tcp <IP_ADDRESS>:80-><IP_ADDRESS>:47018: i/o timeout
2019/03/26 12:08:28 [INFO] Starting cluster agent for c-mfhcs [owner=true]
2019-03-26 12:08:28.875069 W | etcdserver: apply entries took too long [1.973863674s for 1 entries]
2019-03-26 12:08:28.875087 W | etcdserver: avoid queries with large range/delete range!
2019-03-26 12:08:30.002600 W | etcdserver: apply entries took too long [508.954844ms for 1 entries]
2019-03-26 12:08:30.002614 W | etcdserver: avoid queries with large range/delete range!
2019/03/26 12:08:30 [INFO] Registering project network policy
2019/03/26 12:08:30 [INFO] Registering namespaceHandler for adding labels
2019/03/26 12:08:30 [INFO] registering podsecuritypolicy cluster handler for cluster c-dff54
2019/03/26 12:08:30 [INFO] registering podsecuritypolicy project handler for cluster c-dff54
2019/03/26 12:08:30 [INFO] registering podsecuritypolicy namespace handler for cluster c-dff54
2019/03/26 12:08:30 [INFO] registering podsecuritypolicy serviceaccount handler for cluster c-dff54
2019/03/26 12:08:30 [INFO] registering podsecuritypolicy template handler for cluster c-dff54
2019/03/26 12:08:30 [INFO] Starting cluster controllers for c-dff54
2019/03/26 12:08:30 [INFO] Starting cluster agent for c-dff54 [owner=true]
2019-03-26 12:08:31.213445 W | etcdserver: apply entries took too long [154.844267ms for 1 entries]
2019-03-26 12:08:31.213461 W | etcdserver: avoid queries with large range/delete range!
2019/03/26 12:08:32 [INFO] error in remotedialer server [400]: read tcp <IP_ADDRESS>:80-><IP_ADDRESS>:47496: i/o timeout
2019/03/26 12:08:33 [ERROR] ProjectRoleTemplateBindingController p-zxcm6/creator-project-owner [mgmt-auth-prtb-controller] failed with : cluster.management.cattle.io "c-f6ff8" not found
2019/03/26 12:08:33 [ERROR] ProjectRoleTemplateBindingController p-cwwj5/creator-project-owner [mgmt-auth-prtb-controller] failed with : cluster.management.cattle.io "c-65mlq" not found
2019/03/26 12:08:33 [ERROR] ProjectRoleTemplateBindingController p-vbl4q/creator-project-owner [mgmt-auth-prtb-controller] failed with : cluster.management.cattle.io "c-f6ff8" not found
2019/03/26 12:08:33 [ERROR] ClusterRoleTemplateBindingController c-f6ff8/u-27fgmzj2gc-admin [mgmt-auth-crtb-controller] failed with : cluster.management.cattle.io "c-f6ff8" not found
2019/03/26 12:08:33 [ERROR] ClusterRoleTemplateBindingController c-f6ff8/creator-cluster-owner [mgmt-auth-crtb-controller] failed with : cluster.management.cattle.io "c-f6ff8" not found
2019/03/26 12:08:33 [ERROR] ClusterRoleTemplateBindingController c-65mlq/creator-cluster-owner [mgmt-auth-crtb-controller] failed with : cluster.management.cattle.io "c-65mlq" not found
2019/03/26 12:08:33 [ERROR] ClusterRoleTemplateBindingController c-65mlq/u-gjewqkidsl-admin [mgmt-auth-crtb-controller] failed with : cluster.management.cattle.io "c-65mlq" not found
2019/03/26 12:08:33 [ERROR] ProjectRoleTemplateBindingController p-txhx4/creator-project-owner [mgmt-auth-prtb-controller] failed with : cluster.management.cattle.io "c-65mlq" not found
2019/03/26 12:08:35 [ERROR] CatalogController [catalog] failed with : Unexpected HTTP status code 404 from<EMAIL_ADDRESS>expected 200
2019/03/26 12:08:35 [INFO] Updating catalog helm-incubator
2019/03/26 12:08:35 [INFO] Updating catalog helm
2019/03/26 12:08:35 [ERROR] CatalogController [catalog] failed with : Unexpected HTTP status code 404 from<EMAIL_ADDRESS>expected 200
2019-03-26 12:08:36.926814 W | etcdserver: apply entries took too long [469.041433ms for 1 entries]
2019-03-26 12:08:36.926827 W | etcdserver: avoid queries with large range/delete range!
2019/03/26 12:08:37 [ERROR] CatalogController [catalog] failed with : Unexpected HTTP status code 404 from<EMAIL_ADDRESS>expected 200
2019-03-26 12:08:37.940087 W | etcdserver: apply entries took too long [259.362989ms for 1 entries]
2019-03-26 12:08:37.940141 W | etcdserver: avoid queries with large range/delete range!
2019/03/26 12:08:38 [INFO] Handling backend connection request [c-dff54:m-c7d796696cf1]
2019/03/26 12:08:38 [INFO] Handling backend connection request [c-dff54:m-7bca7509f24e]
2019-03-26 12:08:39.441219 W | etcdserver: apply entries took too long [259.704049ms for 2 entries]
2019-03-26 12:08:39.441236 W | etcdserver: avoid queries with large range/delete range!
2019-03-26 12:08:39.728953 W | etcdserver: apply entries took too long [105.58418ms for 1 entries]
2019-03-26 12:08:39.728969 W | etcdserver: avoid queries with large range/delete range!
2019/03/26 12:08:40 [ERROR] CatalogController [catalog] failed with : Unexpected HTTP status code 404 from<EMAIL_ADDRESS>expected 200
2019/03/26 12:08:40 [INFO] Handling backend connection request [c-dff54:m-38c372163f76]
2019-03-26 12:08:40.611648 W | etcdserver: apply entries took too long [417.232735ms for 2 entries]
2019-03-26 12:08:40.611668 W | etcdserver: avoid queries with large range/delete range!
2019/03/26 12:08:41 [INFO] Handling backend connection request [c-dff54:m-9e22b2ee2831]
2019/03/26 12:08:41 [INFO] Handling backend connection request [c-dff54:m-bfdc4158a30e]
2019-03-26 12:08:41.405906 W | etcdserver: apply entries took too long [691.188456ms for 2 entries]
2019-03-26 12:08:41.405921 W | etcdserver: avoid queries with large range/delete range!
2019/03/26 12:08:41 [INFO] Catalog sync done. 0 templates created, 4 templates updated, 0 templates deleted
2019-03-26 12:08:41.878582 W | etcdserver: apply entries took too long [261.83018ms for 2 entries]
2019-03-26 12:08:41.878597 W | etcdserver: avoid queries with large range/delete range!
2019-03-26 12:08:42.567970 W | etcdserver: apply entries took too long [535.223555ms for 2 entries]
2019-03-26 12:08:42.567989 W | etcdserver: avoid queries with large range/delete range!
2019/03/26 12:08:42 [INFO] Handling backend connection request [c-dff54:m-8b8ecfb94d1e]
2019/03/26 12:08:43 [INFO] Handling backend connection request [c-dff54:m-ccc93da12a36]
2019-03-26 12:08:43.727419 W | etcdserver: apply entries took too long [273.240721ms for 1 entries]
2019-03-26 12:08:43.727437 W | etcdserver: avoid queries with large range/delete range!
2019/03/26 12:08:44 [ERROR] CatalogController [catalog] failed with : Unexpected HTTP status code 404 from<EMAIL_ADDRESS>expected 200
2019-03-26 12:08:44.927229 W | etcdserver: apply entries took too long [213.821604ms for 1 entries]
2019-03-26 12:08:44.927246 W | etcdserver: avoid queries with large range/delete range!
2019-03-26 12:08:45.666225 W | etcdserver: apply entries took too long [250.376862ms for 1 entries]
2019-03-26 12:08:45.666244 W | etcdserver: avoid queries with large range/delete range!
2019-03-26 12:08:46.139839 W | etcdserver: apply entries took too long [304.76777ms for 2 entries]
2019-03-26 12:08:46.139859 W | etcdserver: avoid queries with large range/delete range!
2019-03-26 12:08:46.610352 W | etcdserver: apply entries took too long [301.105132ms for 1 entries]
2019-03-26 12:08:46.610368 W | etcdserver: avoid queries with large range/delete range!
2019/03/26 12:08:46 [INFO] Handling backend connection request [c-dff54:m-1315e07dc5ec]
2019/03/26 12:08:47 [INFO] Handling backend connection request [c-mfhcs:m-2cea63ab2a6a]
2019-03-26 12:08:47.854396 W | etcdserver: apply entries took too long [335.240568ms for 1 entries]
2019-03-26 12:08:47.854414 W | etcdserver: avoid queries with large range/delete range!
2019/03/26 12:08:48 [INFO] error in remotedialer server [400]: read tcp <IP_ADDRESS>:80-><IP_ADDRESS>:48859: i/o timeout
2019-03-26 12:08:48.287315 W | etcdserver: apply entries took too long [144.543963ms for 1 entries]
2019-03-26 12:08:48.287334 W | etcdserver: avoid queries with large range/delete range!
2019/03/26 12:08:48 [INFO] error in remotedialer server [400]: read tcp <IP_ADDRESS>:80-><IP_ADDRESS>:48882: i/o timeout
2019-03-26 12:08:48.728546 W | etcdserver: apply entries took too long [265.8057ms for 1 entries]
2019-03-26 12:08:48.728563 W | etcdserver: avoid queries with large range/delete range!
2019/03/26 12:08:49 [ERROR] ProjectRoleTemplateBindingController p-zxcm6/creator-project-owner [mgmt-auth-prtb-controller] failed with : cluster.management.cattle.io "c-f6ff8" not found
2019/03/26 12:08:49 [ERROR] ProjectRoleTemplateBindingController p-cwwj5/creator-project-owner [mgmt-auth-prtb-controller] failed with : cluster.management.cattle.io "c-65mlq" not found
2019/03/26 12:08:49 [ERROR] ProjectRoleTemplateBindingController p-vbl4q/creator-project-owner [mgmt-auth-prtb-controller] failed with : cluster.management.cattle.io "c-f6ff8" not found
2019/03/26 12:08:49 [ERROR] ClusterRoleTemplateBindingController c-f6ff8/u-27fgmzj2gc-admin [mgmt-auth-crtb-controller] failed with : cluster.management.cattle.io "c-f6ff8" not found
2019/03/26 12:08:49 [ERROR] ClusterRoleTemplateBindingController c-f6ff8/creator-cluster-owner [mgmt-auth-crtb-controller] failed with : cluster.management.cattle.io "c-f6ff8" not found
2019/03/26 12:08:49 [ERROR] ClusterRoleTemplateBindingController c-65mlq/creator-cluster-owner [mgmt-auth-crtb-controller] failed with : cluster.management.cattle.io "c-65mlq" not found
2019/03/26 12:08:49 [ERROR] ClusterRoleTemplateBindingController c-65mlq/u-gjewqkidsl-admin [mgmt-auth-crtb-controller] failed with : cluster.management.cattle.io "c-65mlq" not found
2019/03/26 12:08:49 [ERROR] ProjectRoleTemplateBindingController p-txhx4/creator-project-owner [mgmt-auth-prtb-controller] failed with : cluster.management.cattle.io "c-65mlq" not found
2019/03/26 12:08:49 [INFO] Handling backend connection request [c-mfhcs:m-d18bcbb274ca]
2019-03-26 12:08:49.373968 W | etcdserver: apply entries took too long [458.144829ms for 1 entries]
2019-03-26 12:08:49.374048 W | etcdserver: avoid queries with large range/delete range!
2019/03/26 12:08:50 [INFO] error in remotedialer server [400]: read tcp <IP_ADDRESS>:80-><IP_ADDRESS>:48983: i/o timeout
2019-03-26 12:08:50.927570 W | etcdserver: apply entries took too long [261.692777ms for 2 entries]
2019-03-26 12:08:50.927590 W | etcdserver: avoid queries with large range/delete range!
2019/03/26 12:08:50 [INFO] Catalog sync done. 0 templates created, 8 templates updated, 0 templates deleted
2019/03/26 12:08:51 [INFO] error in remotedialer server [400]: read tcp <IP_ADDRESS>:80-><IP_ADDRESS>:49055: i/o timeout
2019/03/26 12:08:51 [INFO] error in remotedialer server [400]: read tcp <IP_ADDRESS>:80-><IP_ADDRESS>:49060: i/o timeout
2019-03-26 12:08:51.386006 W | etcdserver: apply entries took too long [256.880445ms for 1 entries]
2019-03-26 12:08:51.386020 W | etcdserver: avoid queries with large range/delete range!
2019-03-26 12:08:52.402715 W | etcdserver: apply entries took too long [364.766378ms for 1 entries]
2019-03-26 12:08:52.402735 W | etcdserver: avoid queries with large range/delete range!
2019/03/26 12:08:52 [INFO] error in remotedialer server [400]: read tcp <IP_ADDRESS>:80-><IP_ADDRESS>:49091: i/o timeout
2019/03/26 12:08:52 [ERROR] CatalogController [catalog] failed with : Unexpected HTTP status code 404 from<EMAIL_ADDRESS>expected 200
2019/03/26 12:08:53 [INFO] error in remotedialer server [400]: read tcp <IP_ADDRESS>:80-><IP_ADDRESS>:49178: i/o timeout
2019-03-26 12:08:53.272658 W | etcdserver: apply entries took too long [221.520183ms for 2 entries]
2019-03-26 12:08:53.272678 W | etcdserver: avoid queries with large range/delete range!
2019-03-26 12:08:54.184065 W | etcdserver: apply entries took too long [274.158869ms for 1 entries]
2019-03-26 12:08:54.184080 W | etcdserver: avoid queries with large range/delete range!
2019-03-26 12:08:54.647690 W | etcdserver: apply entries took too long [209.648983ms for 2 entries]
2019-03-26 12:08:54.647774 W | etcdserver: avoid queries with large range/delete range!
2019-03-26 12:08:55.743014 W | etcdserver: apply entries took too long [207.717355ms for 1 entries]
2019-03-26 12:08:55.743028 W | etcdserver: avoid queries with large range/delete range!
2019/03/26 12:08:56 [INFO] error in remotedialer server [400]: read tcp <IP_ADDRESS>:80-><IP_ADDRESS>:49470: i/o timeout
2019/03/26 12:08:57 [INFO] error in remotedialer server [400]: read tcp <IP_ADDRESS>:80-><IP_ADDRESS>:49573: i/o timeout
2019-03-26 12:08:58.518273 W | etcdserver: apply entries took too long [184.719707ms for 1 entries]
2019-03-26 12:08:58.518287 W | etcdserver: avoid queries with large range/delete range!
2019/03/26 12:08:59 [INFO] error in remotedialer server [400]: read tcp <IP_ADDRESS>:80-><IP_ADDRESS>:49605: i/o timeout
2019-03-26 12:08:59.346228 W | etcdserver: apply entries took too long [266.776404ms for 1 entries]
2019-03-26 12:08:59.346240 W | etcdserver: avoid queries with large range/delete range!
2019-03-26 12:08:59.743656 W | etcdserver: apply entries took too long [284.028398ms for 2 entries]
2019-03-26 12:08:59.743675 W | etcdserver: avoid queries with large range/delete range!
2019-03-26 12:09:00.592016 W | etcdserver: apply entries took too long [290.819007ms for 2 entries]
2019-03-26 12:09:00.592031 W | etcdserver: avoid queries with large range/delete range!
2019/03/26 12:09:02 [INFO] Handling backend connection request [c-dff54:m-c7d796696cf1]
2019/03/26 12:09:02 [INFO] Handling backend connection request [c-dff54:m-9e22b2ee2831]
2019/03/26 12:09:03 [INFO] Handling backend connection request [c-dff54:m-7bca7509f24e]
2019-03-26 12:09:04.690930 W | etcdserver: apply entries took too long [240.028084ms for 1 entries]
2019-03-26 12:09:04.690948 W | etcdserver: avoid queries with large range/delete range!
2019-03-26 12:09:05.132438 W | etcdserver: apply entries took too long [240.731842ms for 1 entries]
2019-03-26 12:09:05.132454 W | etcdserver: avoid queries with large range/delete range!
2019-03-26 12:09:05.464606 W | etcdserver: apply entries took too long [218.394033ms for 1 entries]
2019-03-26 12:09:05.464627 W | etcdserver: avoid queries with large range/delete range!
2019-03-26 12:09:05.909287 W | etcdserver: apply entries took too long [302.065243ms for 2 entries]
2019-03-26 12:09:05.909305 W | etcdserver: avoid queries with large range/delete range!
2019/03/26 12:09:06 [INFO] Handling backend connection request [c-dff54:m-38c372163f76]
2019-03-26 12:09:06.710148 W | etcdserver: apply entries took too long [312.756997ms for 1 entries]
2019-03-26 12:09:06.710169 W | etcdserver: avoid queries with large range/delete range!
2019-03-26 12:09:07.198827 W | etcdserver: apply entries took too long [352.947893ms for 2 entries]
2019-03-26 12:09:07.198846 W | etcdserver: avoid queries with large range/delete range!
2019/03/26 12:09:09 [ERROR] CatalogController [catalog] failed with : Unexpected HTTP status code 404 from<EMAIL_ADDRESS>expected 200
2019-03-26 12:09:09.971843 W | etcdserver: apply entries took too long [253.67534ms for 1 entries]
2019-03-26 12:09:09.971863 W | etcdserver: avoid queries with large range/delete range!
2019/03/26 12:09:12 [INFO] error in remotedialer server [400]: read tcp <IP_ADDRESS>:80-><IP_ADDRESS>:50007: i/o timeout
2019-03-26 12:09:12.268637 W | etcdserver: apply entries took too long [242.223039ms for 1 entries]
2019-03-26 12:09:12.268652 W | etcdserver: avoid queries with large range/delete range!
2019/03/26 12:09:12 [INFO] error in remotedialer server [400]: read tcp <IP_ADDRESS>:80-><IP_ADDRESS>:50051: i/o timeout
2019-03-26 12:09:12.662517 W | etcdserver: apply entries took too long [277.35228ms for 1 entries]
2019-03-26 12:09:12.662531 W | etcdserver: avoid queries with large range/delete range!
2019/03/26 12:09:12 [INFO] Handling backend connection request [c-dff54:m-1315e07dc5ec]
2019/03/26 12:09:13 [INFO] error in remotedialer server [400]: read tcp <IP_ADDRESS>:80-><IP_ADDRESS>:50091: i/o timeout
2019/03/26 12:09:15 [INFO] Handling backend connection request [c-dff54:m-bfdc4158a30e]
2019/03/26 12:09:16 [INFO] error in remotedialer server [400]: read tcp <IP_ADDRESS>:80-><IP_ADDRESS>:50125: i/o timeout
2019-03-26 12:09:17.872198 W | etcdserver: apply entries took too long [204.329883ms for 2 entries]
2019-03-26 12:09:17.872217 W | etcdserver: avoid queries with large range/delete range!
2019-03-26 12:09:19.173877 W | etcdserver: apply entries took too long [222.757338ms for 1 entries]
2019-03-26 12:09:19.173892 W | etcdserver: avoid queries with large range/delete range!
2019-03-26 12:09:19.438703 W | etcdserver: apply entries took too long [134.359486ms for 1 entries]
2019-03-26 12:09:19.438719 W | etcdserver: avoid queries with large range/delete range!
2019/03/26 12:09:20 [INFO] Handling backend connection request [c-dff54:m-8b8ecfb94d1e]
2019-03-26 12:09:20.819539 W | etcdserver: apply entries took too long [289.615001ms for 1 entries]
2019-03-26 12:09:20.819556 W | etcdserver: avoid queries with large range/delete range!
2019/03/26 12:09:21 [ERROR] ProjectRoleTemplateBindingController p-zxcm6/creator-project-owner [mgmt-auth-prtb-controller] failed with : cluster.management.cattle.io "c-f6ff8" not found
2019/03/26 12:09:21 [ERROR] ProjectRoleTemplateBindingController p-cwwj5/creator-project-owner [mgmt-auth-prtb-controller] failed with : cluster.management.cattle.io "c-65mlq" not found
2019/03/26 12:09:21 [ERROR] ProjectRoleTemplateBindingController p-vbl4q/creator-project-owner [mgmt-auth-prtb-controller] failed with : cluster.management.cattle.io "c-f6ff8" not found
2019/03/26 12:09:21 [ERROR] ClusterRoleTemplateBindingController c-f6ff8/creator-cluster-owner [mgmt-auth-crtb-controller] failed with : cluster.management.cattle.io "c-f6ff8" not found
2019/03/26 12:09:21 [ERROR] ClusterRoleTemplateBindingController c-65mlq/creator-cluster-owner [mgmt-auth-crtb-controller] failed with : cluster.management.cattle.io "c-65mlq" not found
2019/03/26 12:09:21 [ERROR] ClusterRoleTemplateBindingController c-65mlq/u-gjewqkidsl-admin [mgmt-auth-crtb-controller] failed with : cluster.management.cattle.io "c-65mlq" not found
2019/03/26 12:09:21 [ERROR] ClusterRoleTemplateBindingController c-f6ff8/u-27fgmzj2gc-admin [mgmt-auth-crtb-controller] failed with : cluster.management.cattle.io "c-f6ff8" not found
2019/03/26 12:09:21 [ERROR] ProjectRoleTemplateBindingController p-txhx4/creator-project-owner [mgmt-auth-prtb-controller] failed with : cluster.management.cattle.io "c-65mlq" not found

cluster which are running right now in Rancher:

NAME
c-dff54
c-mfhcs

Useful
Info

Versions
Rancher v2.1.7 UI: v2.1.21

Route
authenticated.cluster.index

We were running cronjobs on that server it causes me this issue.


Support position independent code in higher half

When a PIC kernel is located in higher half, we currently try to allocate 33554177 entries in the level 4 page table, which of course fails. This is the reason that we currently use the static relocation model for our higher half test:
https://github.com/rust-osdev/bootloader/blob/4e2b8d7e4b4fad3c7aefd7f8174f86ec2119ecc7/Cargo.toml#L87
I think the issue is in these lines:
https://github.com/rust-osdev/bootloader/blob/4e2b8d7e4b4fad3c7aefd7f8174f86ec2119ecc7/common/src/load_kernel.rs#L64-L75
Looks like we only consider the end address for the size calculation, without taking the start address into account. I think we should be able to fix this by using the difference between the max and min address as size instead.

cc @Freax13

I started to look into this in https://github.com/rust-osdev/bootloader/tree/higher-half-pic. Not sure if my approach is right, though. The current error is "the relocation table must end in the elf file".

Unless I'm missing something, specifying a image base address for a PIC kernel is meaningless because they're supposed to be able to be relocated anywhere. Instead the dynamic_start config value should be used (and already is for our higher half kernel test).
Removing those two lines should do the trick:
https://github.com/rust-osdev/bootloader/blob/17ba81613b2feb55ca9d7be67a8923cb703d4511/Cargo.toml#L96-L97

I'll take a look at your approach of changing how we calculate the size later today.

Thanks a lot! This issue is not that urgent, so no hurry.

Unless I'm missing something, specifying a image base address for a PIC kernel is meaningless because they're supposed to be able to be relocated anywhere.

I guess there are different possible ways to handle this. For example, we could try to default to the image base address if it's still free when ASLR is disabled. Or we could treat it as a fallback for the dynamic_start if it isn't specified. Or we just ignore it.
Either way, we should not panic on PIC kernels with a higher half base address. It should be possible to change the relocation mode without adjusting all addresses in a linker script.

I guess there are different possible ways to handle this. For example, we could try to default to the image base address if it's still free when ASLR is disabled. Or we could treat it as a fallback for the dynamic_start if it isn't specified. Or we just ignore it.

There is some precedence for treating the base address as the default: glibc used to treat the base address as the preferred address for PIEs when the LD_USE_LOAD_BIAS environment variable was set to 1. This was used in conjunction with prelinking which is a process that assigns static load addresses to shared libraries and PIEs at build time. Prelinking isn't used anymore which is my LD_USE_LOAD_BIAS was removed from glibc earlier this year.

Either way, we should not panic on PIC kernels with a higher half base address. It should be possible to change the relocation mode without adjusting all addresses in a linker script.

Agreed.

The current error is "the relocation table must end in the elf file".

We currently assume that the address given by the RELA entry is an offset into the file. This is incorrect, it's actually a virtual address pointing to mapped memory. The fix for this isn't entirely trivial because we need to translate the virtual address to a physical address (or in other words we need to translate from the kernel's address space to the bootloader's address space). I'm working on a fix.


Node14

Platforms affected
All
Motivation and Context

Progresses https://github.com/apache/cordova/issues/223
Description

Depends on: https://github.com/apache/cordova-plugin-file/pull/458
Testing

Ran npm test
Checklist

[x] I've run the tests to see all new and existing tests pass
[x] I added automated test coverage as appropriate for this change
[x] Commit is prefixed with (platform) if this change only applies to one platform (e.g. (android))
[x] If this Pull Request resolves an issue, I linked to the issue in the text above (and used the correct keyword to close issues using keywords)
[x] I've updated the documentation if necessary

The failed check is due to an unrelated problem, which I'm going to solve in the WIP PR https://github.com/apache/cordova-plugin-file/pull/460
Merging.


Need Custom payment methode to mark the invoice paid.

Hello All
I have used custom payment method to add a gateway.There i added the gateway details which makes all the payment.Now what return Url should be used to make the invoice paid?

The return url can be determined by the following example

your domain name is mydomain.com
boxbilling is installed in billing
your gateway ID is 4 (you'll be able to determine that by going to Payment Gateways and click on the Pencil icon)

Your return URL will be
https://mydomain.com/billing/bb-ipn.php?bb_gateway_id=4


feat: loading screen spinner

Shows a spinning loading screen in the output while the plugin is working so that a user knows that their call was executed but a response has not come back. We could perhaps put a spinner on the Run Plugin button as well, or alternatively only put it there.

Great idea - maybe it can be a little smaller? Putting in in the Run Plugin button is a good idea too. Swap out the text for the spinner until the plug-in call resolves?


Fix reversed follow/unfollow states in InterestsItem-ToggleButton

During the UI test review, I found that the follow and unfollow states in the contentDescription of the InterestsItem-ToggleButton were reversed, so I corrected them.

I misunderstood the section written based on accessibility.
I will close this.


Container disappeared after NAS reboot (after having cleared it for update purpose) - Synology

Hello,
I'm looking for help before doing worse.
I tried to update the container on my Synology NAS following the instructions here - it's not the first time I'm doing it since I've been using the docker image for a few years now. While trying to clear the container, I got an "Operation failed" error so I've decided to give a NAS reboot a try.
After rebooting, the container were not listed anymore - I guess I shouldn't have rebooted the NAS, and now I'm afraid to have my whole backup to upload again (3TB) ...
Before doing worse, could you help to get the container back and updated ?
Thanks

@septeven in my experience, if you login to the crashplan instance with your account, it will will verify the files on your disk with the files in your cloud and if they are the same, it won't back them up again.
the key is making sure your crashplan instance is referencing the files in the back up from the same path as they were before.
This sounds somewhat similar to the issue I opened just before you (#223 )
It takes my 3.7 TB backup several days to verify all the files in the cloud and in my local backup.

If you re-create the container with the same parameters as before, you should not have any problem.  The folder your mapped to /config contains everything needed.

Thanks for your response @nckwltn @jlesage
It's hard for me to remember the parameters I create the container with as I was following a tutorial and that was a few years ago.
And actually, if I backup the whole crashplan-pro folder (the one located at volume1/docker/appdata) just in case, I should be fine if I'd do something wrong (by replacing it in place if I'm screwing up anything), right ?

@septeven in my experience it's less about exactly how the docker is setup, and more about the volumes you map that are visible to CrashPlan. You want those volumes to basically be the same as they were before.  Once you login to crashplan, the software will look for the folders it was backing up, see them, and start a very long comparison process between the files and the archive.
For me, it takes a couple of days to verify against my cloud backup and my local backup of 3.7 TB
you might be able to get some information on how the volumes were setup by logging into crashplan.com and looking at the cloud archive data structure.

@nckwltn Thanks :)
@jlesage I tried following the commands previously mentioned and I got this error : docker: invalid reference format: repository name must be lowercase.
Any idea?

I think it's because of -- restart: you should not put space, like this: --restart.

That seems to work now, crashplan is syncing....
Thanks again for your great work!


Single-color decompression for TreeSetColoringResult?

I didn't implement it because I'm not even sure it is possible. @amontoison what do you think?

According to Alexis, the best we can do is decompress tree by tree. This requires more than one column of B, and up to every column in the worst case. So it's not worth adding to the API: if memory is an issue, use :direct decompression.


Added modal

Changes/Additions:

Modal to its own branch

Closes #79

Asking @DenFlyvendeGed have you decided that implementing close/open functionality as a svelte store is too complex? I would prefer it that way, but I can accept this as well.

Asking @DenFlyvendeGed have you decided that implementing close/open functionality as a svelte store is too complex? I would prefer it that way, but I can accept this as well.

I'll do it

It is okay to delete the three tests because they specifically test the custom open/close functionality that we have removed by moving the settings view to the modal. We should however implement tests that check the same functionality in the modal.


Test tokenomics implementation

We should write more comprehensive tests for the Sui framework, especially the functions in sui_system around staking, delegation and rewards distribution.

@emmazzz is this still relevant? If not, let's close it. Thanks