Where do I put the license in my app? C#

I don't know where to put the license for Scintilla in my app. It's a commercial app, which I will be selling, but I'm not sure where to put the license.
Should I put it in a text file embedded in the app, or display it to the user if they click a certain button?
Thanks :)

Licensing is a legal matter and it's best you consult a lawyer when it comes to these things, especially that you are intending to sell your software.
What I can suggest is add a copy of ScintillaNET's LICENSE file to your software's distribution folder and acknowledge ScintillaNET's copyright in your executable's "About" dialog.

Licensing is a legal matter and it's best you consult a lawyer when it comes to these things, especially that you are intending to sell your software.
What I can suggest is add a copy of ScintillaNET's LICENSE file to your software's distribution folder and acknowledge ScintillaNET's copyright in your executable's "About" dialog. You can acknowledge it by adding a line such as ScintillaNET (C) Jacob Slusser, MIT with a hyperlink to this repository.

Oh, thanks! Just what I needed :)


Fix some localization issues

Fixes some test failures which occur when changing my regional settings to french (which uses a comma as the decimal separator).

Resolves https://github.com/IronLanguages/ironpython3/issues/751


Fix recent scikit-learn version

Compatibility with recent scikit-learn.

Codecov Report

Merging #27 into master will decrease coverage by 0.07%.
The diff coverage is 100%.

@@            Coverage Diff             @@
##           master      #27      +/-   ##
==========================================
- Coverage   92.85%   92.78%   -0.08%
==========================================
  Files           4        4
  Lines         308      305       -3
==========================================
- Hits          286      283       -3
  Misses         22       22

Impacted Files
Coverage Δ

compiledtrees/compiled.py
95.71% <100%> (-0.18%)
:arrow_down:

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 423b3a6...c254d74. Read the comment docs.


[BUG] openshift-tools-installer fails to find chart-verifier releases

Version
All versions
Describe the bug
openshift-tools-installer fails to find chart-verifier 1.13.6 release binary tarballs in the list of release assets.
Steps to reproduce, workflow links, screenshots

No steps to reproduce because we've worked around this issue for the Chart Verifier 1.13.6 release to unblock users.

See https://github.com/redhat-certification/chart-verifier/issues/463 for a detailed synopsis of what was going wrong.

Context
I maintain https://github.com/redhat-certification/chart-verifier.
The problem here is the filtering that's applied within openshift-tools-installer. Chart Verifier undergoes the default release asset filtering (filterByOs, filterByArch, filterByZipped).
In the past, we only had a single release asset that was published. When openshift-tools-installer encounters only a single release asset, it skips remaining filtering (i.e. all filters). Now that we have 2 assets, the first filter (filterByOs) is filtering out everything, and returning 0 assets.
Chart Verifier either needs to rename their release asset, or needs custom filters here. I'm leaning the filtering route for now because there may be other locations that use our release asset names as they exist.
I've got some filters that work. I'll submit them as a PR here shortly.

cc @jessesimpson36 - thanks for reporting this


Chakra UI + Formik example is broken

Description
https://chakra-ui.com/getting-started/with-formik

turns out after refreshing it worked?
can you reproduce?

Works for me as well, I will close it, if it happens again, please create another issue.


Expose child on default logger

This allows use to add child loggers to the default logger.
This makes it easy to establish a pattern for sub-components to scope their logs without needing to call createLogger or be passed the application logger.
Example:
app.js
const winston = require('winston');
winston.configure({
  level: 'info',
  format: winston.format.combine(
    winston.format.colorize(),
    winston.format.json()
  ),
  defaultMeta: { service: 'abc-service' },
  transports: [
    new winston.transports.Console()
  ]
})

component-xyz.js
const logger = require('winston').child({ component: 'xyz-middleware' });

@DABH any ETA on when this will appear in a release? Even a patch would be nice 😬

We’ll probably cut a release in a week or two (sorry for vague estimate).  In the meantime feel free to reference the master branch directly in your package.json :) Thanks!

@DABH Any update on this release?

@DABH Same as above. Any news on cutting a release with this in?

@DABH Ping! Last release was on 29 Jan. This is non-breaking could we just get a patch with the latest fixes in master?

You will have to ping @indexzero as I can’t push a new tag to npm unfortunately

@indexzero could we please get a new version of Winston tagged and released?

@indexzero ?

Any update on this? @indexzero ? Issue #1767 is still open as well with no response even though this commit looks to resolve it.


Extension issue

Issue Type: Bug
Extension Name: git
Extension Version: 1.0.0
OS Version: Windows_NT x64 10.0.19043
VS Code version: 1.57.1

:warning: We have written the needed data into your clipboard. Please paste! :warning:

/needsMoreInfo


Additional Kext Tests

Added Tests for

TryGetFileIsFlaggedAsInRoot
ShouldHandleVnodeOpEvent
VirtualizationRoot_VnodeIsOnAllowedFilesystem
VirtualizationRoot_IsValidRootHandle

@pmj thanks for the quick turnaround and pointers here.  My C is rusty for sure, so I definitely appreciate the tips :-).  I addressed your comments in a separate commit for easy review.  I'll squash before merging.


Prioritize maskable icons for apple-touch-icon

If an icon has "purpose": "maskable", that indicates it should not be transparent and is suited to be masked to shapes like iOS' rounded squares.
Some potential behaviour options:

Include the maskable icons with no priority (current behaviour)
If a maskable icon is present, discard the non-maskable icons and only use maskable icons for apple-touch-icon
Rank maskable icons higher somehow (does Safari use the first icon it encounters?)

We could probably prefer the maskable icons for generating the apple-touch-icon or splash screen. WDYT?
I don't see a huge disadvantage in continuing to check for and add a solid background. The spec says that maskable icons should not be transparent but can't enforce that in any way.

I agree that its probably fine to keep adding a solid background. It should be simple to process the maskable icons in the exact same way as a standard icon that's a square with no transparent background. I'm happy to send a PR if you like!

Sure, if you like! 👍
On Mon., 19 Aug. 2019, 19:26 Tiger Oakes<EMAIL_ADDRESS>wrote:

I agree that its probably fine to keep adding a solid background. It
should be simple to process the maskable icons in the exact same way as a
standard icon that's a square with no transparent background. I'm happy to
send a PR if you like!
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/GoogleChromeLabs/pwacompat/issues/33?email_source=notifications&email_token=AAA5DEG737NBJNQ2R2KKAX3QFNI6TA5CNFSM4IMN7XF2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD4U3D2Q#issuecomment-522826218,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAA5DEDUO3FNBJM7UG3LO5DQFNI6TANCNFSM4IMN7XFQ
.


[Bug] Stationctl "start" reprovisions

Describe the bug
When running stationctl and Startup, it reprovisions the boxes.
To Reproduce
Steps to reproduce the behavior:

stationctl
4
2

Expected behavior
Just restart the boxes without reprovisioning them.
This can be fixed by changing stationctl to start (and restart boxes) with `vagrant {up,reload} --no-provision

This is already added to file. May in fact be causing #47

This is already added to file. May in fact be causing #47

Closing, as this issue is being addressed in #49

Closing, as this issue is being addressed in #49


Debian Jessie Clear

After making ./mvnw clean package
[INFO] --- frontend-maven-plugin:0.0.25:npm (npm install) @ commafeed ---
[INFO] Running 'npm install --loglevel info --color=false' in /opt/commafeed
[ERROR] npm info it worked if it ends with ok
[ERROR] npm info using<EMAIL_ADDRESS>[ERROR] npm info using<EMAIL_ADDRESS>[ERROR] npm info attempt registry request try #1 at 18:44:15
[ERROR] npm http request GET https://registry.npmjs.org/bower
[ERROR] npm info attempt registry request try #1 at 18:44:15
[ERROR] npm http request GET https://registry.npmjs.org/gulp
[ERROR] npm info attempt registry request try #1 at 18:44:15
[ERROR] npm http request GET https://registry.npmjs.org/gulp-rev
[ERROR] npm info attempt registry request try #1 at 18:44:15
[ERROR] npm http request GET https://registry.npmjs.org/gulp-minify-css
[ERROR] npm info attempt registry request try #1 at 18:44:15
[ERROR] npm http request GET https://registry.npmjs.org/gulp-rev-replace
[ERROR] npm info attempt registry request try #1 at 18:44:15
[ERROR] npm http request GET https://registry.npmjs.org/gulp-filter
[ERROR] npm info attempt registry request try #1 at 18:44:15
[ERROR] npm http request GET https://registry.npmjs.org/gulp-uglify
[ERROR] npm info attempt registry request try #1 at 18:44:15
[ERROR] npm http request GET https://registry.npmjs.org/gulp-connect
[ERROR] npm info attempt registry request try #1 at 18:44:15
[ERROR] npm http request GET https://registry.npmjs.org/connect-modrewrite
[ERROR] npm info attempt registry request try #1 at 18:44:15
[ERROR] npm http request GET https://registry.npmjs.org/gulp-useref
[ERROR] npm info attempt registry request try #1 at 18:44:15
[ERROR] npm http request GET https://registry.npmjs.org/gulp-sass
[ERROR] npm info attempt registry request try #1 at 18:44:15
[ERROR] npm http request GET https://registry.npmjs.org/gulp-angular-templatecache
[ERROR] npm http 304 https://registry.npmjs.org/bower
[ERROR] npm http 304 https://registry.npmjs.org/gulp-minify-css
[ERROR] npm http 304 https://registry.npmjs.org/gulp-rev
[ERROR] npm http 304 https://registry.npmjs.org/gulp-rev-replace
[ERROR] npm http 304 https://registry.npmjs.org/gulp-filter
[ERROR] npm http 304 https://registry.npmjs.org/gulp-uglify
[ERROR] npm http 304 https://registry.npmjs.org/connect-modrewrite
[ERROR] npm WARN deprecated<EMAIL_ADDRESS>Please use gulp-clean-css

How i can fix it? Errors drops unlimited times. I tried run and from /home/commafeed, and from /opt, with root and without.. its always drop me with this errors

Seems like it's not really an error, npm is just too verbose. Is the build finishing successfully if you leave it running ?


How to get access point IP address?

Is it possible to get the IP address that ESP chose to give itself while in AP mode? Or will it always be the subnet's gateway IP address as given in embedded_svc::ipv4::RouterConfiguration.subnet?
Sorry if this is a dumb question. I'm learning the ropes and haven't even fired up my ESP32C3 as an access point yet. I'm just trying to make sense of the APIs.

Is it possible to get the IP address that ESP chose to give itself while in AP mode? Or will it always be the subnet's gateway IP address as given in embedded_svc::ipv4::RouterConfiguration.subnet?

It will of course always be the subnet's gateway IP address. In AP mode, the ESP is the gateway.
Just have in mind that if you do simultaneous AP+STA (as the demo does) then the ESP will have two IP addresses:

The AP gateway address
A DHCP address from your wifi network

... and will route traffic between the two. The AP traffic will be NAT-ed behind the AP gateway IP however (which is of course inconvenient a bit).


Fixed how we handle unions of records with the same fields.

When deserializing an Avro object, we need to select records based on their names, not just their fields. This lets us have unions with two records that have different names but the same set of fields (which is totally valid in Avro).
In principle, we can select named types based only on names, not looking at the fields at all. Avro requires full names in schemas to be unique. However, I did not make this change here to avoid changing the existing behavior of the library too much.

@AlexeyRaga As part of writing some tests for the JSON parsing/serializing logic, I found out that unions aren't handled correctly when the branches are different records with the same fields.
I added a general test cases for unions that includes an example like this and fixed the issue by changing the Eq instance for Schema.

In general, Avro requires "full names" of types (ie namespace + name) to be unique in the schema. I think it would make sense to change how we handle equality for all named types to only look at the name, but wanted to keep this PR scoped to just this fix.

Thanks!

Probably worth noting that this change is technically backwards-incompatible, but the incompatibility should only manifest on schemas that were handled incorrectly previously.


Consider deduplication of message on overlapping subscriptions

There are two types of brokers: those that deduplicate, and those that don't.
Given the following example:

Subscribe to a/b
Subscribe to a/+

A message published on a/b MAY cause a single message to arrive over the socket (e.g. Mosquitto) or MAY cause two messages to arrive over the socket (e.g. NATS and FlashMQ). Both messages are identical.
Now to make sure both callbacks are called, currently a single message on a/b causes the callback of a/b and a/+ to be triggered. But if the broker is of the latter type, this is done twice, which is sub-optimal.
We should explore if there is a solution to prevent the latter situations with such brokers, without using a lot of memory. For example, a not acceptable solution is to keep all topics is memory for a few ms after they are processed, to check if duplicates follow. But maybe we can figure out a way to do this without spending a lot of memory.

Currently in the regression CI it only checks with Mosquitto because of this. NATS / FlashMQ fail.


Totally failed to install react package on atom, it throws the following npm errors, Please help

Installing<EMAIL_ADDRESS>failed.
npm ERR! git clone C:\Users\myusername.atom.apm_git-remotes\https-github-com-millermedeiros-rocambole-git-fa28ae6f C:\Users\myusername\AppData\Local\Temp\npm-1036-ae33b59a\git-cache-30f7a7b8d919\1bd5044df1d6c888a1bd1b511158fb34b011e9aa: Cloning into 'C:\Users\myusername\AppData\Local\Temp\npm-1036-ae33b59a\git-cache-30f7a7b8d919\1bd5044df1d6c888a1bd1b511158fb34b011e9aa'...
npm ERR! git clone C:\Users\myusername.atom.apm_git-remotes\https-github-com-millermedeiros-rocambole-git-fa28ae6f C:\Users\myusername\AppData\Local\Temp\npm-1036-ae33b59a\git-cache-30f7a7b8d919\1bd5044df1d6c888a1bd1b511158fb34b011e9aa: fatal: '/cygdrive/c/Users/myusername/.atom/.apm/_git-remotes/https-github-com-millermedeiros-rocambole-git-fa28ae6f/C:\Users\myusername.atom.apm_git-remotes\https-github-com-millermedeiros-rocambole-git-fa28ae6f' does not appear to be a git repository
npm ERR! git clone C:\Users\myusername.atom.apm_git-remotes\https-github-com-millermedeiros-rocambole-git-fa28ae6f C:\Users\myusername\AppData\Local\Temp\npm-1036-ae33b59a\git-cache-30f7a7b8d919\1bd5044df1d6c888a1bd1b511158fb34b011e9aa: fatal: Could not read from remote repository.
PS:: I am completely sure it's not about my internet connection, I can ping github perfectly
npm ERR! git clone C:\Users\myusername.atom.apm_git-remotes\https-github-com-millermedeiros-rocambole-git-fa28ae6f C:\Users\myusername\AppData\Local\Temp\npm-1036-ae33b59a\git-cache-30f7a7b8d919\1bd5044df1d6c888a1bd1b511158fb34b011e9aa:
npm ERR! git clone C:\Users\myusername.atom.apm_git-remotes\https-github-com-millermedeiros-rocambole-git-fa28ae6f C:\Users\myusername\AppData\Local\Temp\npm-1036-ae33b59a\git-cache-30f7a7b8d919\1bd5044df1d6c888a1bd1b511158fb34b011e9aa: Please make sure you have the correct access rights
PS:: I went ahead to change permissions and access rights to the .apm  folder and gave everyone "Full Control', same error
npm ERR! git clone C:\Users\myusername.atom.apm_git-remotes\https-github-com-millermedeiros-rocambole-git-fa28ae6f C:\Users\myusername\AppData\Local\Temp\npm-1036-ae33b59a\git-cache-30f7a7b8d919\1bd5044df1d6c888a1bd1b511158fb34b011e9aa: and the repository exists.
PS:: Well if it exists...?
npm ERR! git clone C:\Users\myusername.atom.apm_git-remotes\https-github-com-millermedeiros-rocambole-git-fa28ae6f C:\Users\myusername\AppData\Local\Temp\npm-1036-ae33b59a\git-cache-30f7a7b8d919\1bd5044df1d6c888a1bd1b511158fb34b011e9aa:
npm ERR! Windows_NT 6.2.9200
npm ERR! argv "C:\Users\myusername\AppData\Local\atom\app-1.2.4\resources\app\apm\bin\node.exe" "C:\Users\myusername\AppData\Local\atom\app-1.2.4\resources\app\apm\node_modules\npm\bin\npm-cli.js" "--globalconfig" "C:\Users\myusername\.atom\.apm\.apmrc" "--userconfig" "C:\Users\myusername\.atom\.apmrc" "install" "C:\Users\myusername\AppData\Local\Temp\d-1151110-9832-1aghraj\package.tgz" "--target=0.34.0" "--arch=ia32" "--msvs_version=2013"
npm ERR! node v0.10.40
npm ERR! npm  v2.13.3
npm ERR! code 128
npm ERR! Command failed: Cloning into 'C:\Users\myusername\AppData\Local\Temp\npm-1036-ae33b59a\git-cache-30f7a7b8d919\1bd5044df1d6c888a1bd1b511158fb34b011e9aa'...
npm ERR! fatal: '/cygdrive/c/Users/myusername/.atom/.apm/_git-remotes/https-github-com-millermedeiros-rocambole-git-fa28ae6f/C:\Users\myusername.atom.apm_git-remotes\https-github-com-millermedeiros-rocambole-git-fa28ae6f' does not appear to be a git repository
npm ERR! fatal: Could not read from remote repository.
npm ERR!
npm ERR! Please make sure you have the correct access rights
npm ERR! and the repository exists.
npm ERR!
npm ERR!
npm ERR! If you need help, you may report this error at:
npm ERR!     https://github.com/npm/npm/issues
PS::Am confused about the fact that inside my .apm folder, I have the react folder having versions up to the latest 0.12.11. Iam still wondering why in my settings, the react package is still marked as install instead of update.
Am I missing anything here? Please help, am new to the atom editor, just switched from brackets.

I am having the same issue :(

I haven't gone trough reading all these errors and checking if they are the same as mine but I am having the same final result.
are there any news?

I had this occur when running the command from cygwin. If you look closely at the error output you can see that a cygwin path (/cygdrive/c) is combined with a windows path (C:\Users...) to form a bad path.
npm ERR! fatal: '/cygdrive/c/Users/myusername/.atom/.apm/_git-remotes/https-github-com-millermedeiros-rocambole-git-fa28ae6f/C:\Users\myusername.atom.apm_git-remotes\https-github-com-millermedeiros-rocambole-git-fa28ae6f' does not appear to be a git repository
The easiest thing is to run from a Windows command shell (with something like Git for Windows in your path).


There are strings haven't been translated in Application page on Settings panel

Storage Explorer Version: 1.10.1
Build: 20191012.1
Branch: master
Platform/OS: Windows 10/ Linux Ubuntu 19.04/macOS High Sierra
Language: Chinese(zh-TW)
Architecture: ia32/x64
Regression From: Not a regression
Steps to reproduce:

Launch Storage Explorer.
Open Settings panel -> Regional Settings -> Select Chinese(Traditional) as application language -> Restart Storage Explorer.
Open Settings panel -> Application.
Check the strings on this page.

Expect Experience:
The strings that need to be translated have been localized.
Actual Experience:

The 'Proxy' and its description are not localized.

The 'Regional Settings' and its description are not localized.

The string 'Use device code flow sign-in' is not localized.

More Info:

This issue also reproduces in Chinese(zh-CN).
Only verified this issue in Chinese(zh-CN) and Chinese(zh-TW).

New string from 10/11/2019. On translation.
File: loc\en\src\Standalone\resources\Shell.json
ID: 0; "TitleSignInDeviceCodeFlow"
SRC: Use device code flow sign-in

Localized by this commit.
https://devdiv.visualstudio.com/DevDiv/_git/StorageExplorer/commit/36491ccfebba8b26249bafdeaff80d21b341a45b?_a=compare&path=%2Floc%2Floc%2Fzh-Hans%2Fsrc%2FStandalone%2Fresources%2FShell.json.lcl

Verified as fixed.


Explore creating a signal to containers that an external data source has changed

EDIT: This is a throw away PR and is not intended to be merged into main. We are simply using this branch as a playground for hacking around in for now.
This PR explores creating a signal that will be emitted from the server to the container in the client that the source of truth for the data that the client has changed and that the container in the client should do something with that information.
In order to try it out yourself, please do the following:

Start a codespace of branch (or pull it down to you linux box)
Navigate to protocol-definitions, install packages and build them:
$ cd common/lib
$ npm i
$ npm run build
Go back to root, and link to the protocol-definitions:
$ cd ../..
$ npm link common/lib/protocol-definitions
Install the rest of the node packages and build them at root:
$ npm i
$ npm run build
Navigate to routerlicious, link to protocol-definition, then install and build the libraries there:
$ cd server/routerlicious
$ npm link ../../common/lib/protocol-definitions
$ npm i
$ npm run build
Navigate to server/routerlicious/packages/lambdas and link from there because the package name and the directory name are different:
$ cd packages/lambdas
$ npm run build
$ npm link
Navigate to the tinylicious directory from routerlicious, install and link all pacakges and then build:
$ cd .../../tinylicious
$ npm i
$ npm link ../../common/lib/protocol-definitions/
$ npm link @fluidframework/server-lambdas (this completes the link started in the last part of step 6.)
$ npm run build
Run tinylicious: $ npm run start
Navigate to the example directory and run it:
$ cd ../../examples/hosts/app-integration/external-data
$ npm run start

Now you should be able to go to a browser at localhost:8080 and turn on the developer tools, and click on the Network tab and Websockets filter to see the WS. If it is empty, just refresh. You should see the following signals exchange taking place in the Networks tab then, (note the greyed externalDataChange signal):

Might be worth updating the description to note that this is being merged into a temp dev branch


Make timing event payloads customizable, and apply to sample video mixin

Refs:
https://openscience.atlassian.net/browse/LEI-391
https://openscience.atlassian.net/browse/LEI-392
Purpose
Make it possible for some frames to always customize the event payload with custom parameters used for every timing event captured.
Demonstrate use of this feature with the video recorder mixins
Summary of changes

Add makeTimeEvent hook to customizable base frame
Use in mixins

TODO

[ ] Refactor videorecorder mixin responsibilities so it can capture stream time

Testing notes
TBD

Per original request, would this sample proposal meet the needs?

VideoRecorder mixin should overwrite the standard setTimeEvent action with one that includes the videoId and streamTime
Rather than: each frame using this mixin includes its own sendTimeEvent function instead.

Question for @kimberscott on second half of the request: clarifying which "general video timing events" we want to put in the generic mixin.

Record events about video recording directly in the VideoRecordMixin, rather than handling those from any frames using it.

Each frame has some latitude in what it records or how; currently there is no 100% generic "video recording events" use case. I propose to add the very most common things to the VideoRecordMixin, which will add timing events boilerplate too.
Proposed "video recorder" helpers (let me know if we want other boilerplate)

setRecorder (just make sure recorder can be found in a consistent place)
startRecording(recorder)
pauseRecording(recorder)
stopRecording(recorder)

Other recorder events (like hasCamAccess) get set as part of creating the recorder, and not every frame does that the same way.

Looks good! That set of events for video recorder events makes sense to me.
I see the issue about the onCamAccess, onConnectionStatus, etc. events currently getting set up only upon creating the recorder, but although the recorder may be created differently, the actual events to record are pretty standard. Is it possible for event-recording to be part of the standard handlers for those events? It looks like in exp-player/addon/services/video-recorder.js, for instance, recording an appropriate event could happen in _onConnectionStatus, _onCamAccess, etc.

Thanks for the feedback. Not every frame was consistent previously, but I can make these part of the standard package.
There's a fairly good chance that the required refactorings will collide with your latest PR, and it will require some careful vetting to check for subtle recording bugs.
Though I plan to finish this today or tomorrow, how would you like to plan the merging timeline? I'll tentatively plan to hold this PR until you give the all clear, so that we are sure that we have time to start experiments without untested refactorings at the 11th hour.

Yep, this will definitely require some changes to existing frames (at least to avoid redundant event records) but it's worth it going forward. Shall we plan to merge these changes next week? Once you've set up for these events to be recorded as part of the videoRecorder mixin, I can go back through to all of the affected frames (off the top of my head, video-preview, video-physics, geometry-alternation, and the three new frames for the round 2 studies) to make the necessary changes, and double-check that we don't break anything on the currently-running studies (physics & geometry).

Changes updated to give a sense of the new mixin methods and will hold this until there are no conflicts for @kimberscott 's work. I avoided preemptively altering the list of events for compatibility with Kim's existing analysis workflow, but am happy to make changes as needed.
If you're using experimenter, you can compare the "before" picture (bb0sT, 3/21/2017)  to the "after" payload (profile eOiv3, 3/23/2017), from this link.
https://staging-experimenter.osf.io/experiments/58d015243de08a00400316e0/results?sort=-modified_on

I've set a note to revisit this PR on Thursday: do you think this is something that could be merged and vetted this week?
I know schedule will be tight, but if we can keep PRs from going stale (without breaking things for collaborators), that's always helpful.

Also, I'll work on resolving the merge conflicts.

Yes! Sorry we had to prioritize merging in the other changes, but I do have scheduled to look through and adjust the existing frames this affects on Wednesday.

Yes! Sorry we had to prioritize merging in the other changes, but I do have scheduled to look through and adjust the existing frames this affects on Wednesday.

You made the right call by waiting; no worries.
If you'd like, I've got some time free before 2pm, and could work on converting the new frames along similar lines as what's already in this PR. Just let me know.

If you're up for it, that'd be great - thanks so much! (I think they should mostly have TODO comments already where they're recording events that got moved.)

If you're up for it, that'd be great - thanks so much! (I think they should mostly have TODO comments already where they're recording events that got moved.)

@saradbowman could answer better than I, but I believe the plan is increased availability this week due to the sensitive timeline.
Until I get any set list of specific tasks from her, I'll proceed on the assumption that priority is to help you with your general queue to get collaborators on board by Friday. :)

Updated to work with newest frames. Passing to Kim for any review she'd like to do- in particular, to make sure this preserves the intended behavior of the frames. Will hold until she's had time to look at this.
(I did a light pass but am running light on context for requirements)
Sorry for the documentation change spam in this diff. Since filenames are just alphabetical, just scroll down until you get to something that doesn't have docs/ in the path and start reading from there. :)

Finally working on review now! :)

I've tried this out and made some minor changes to the individual frames. I tried making a PR to your abought:feature/lei391-392-event-recording branch so you could add in my changes, but let me know if there's a better way to do that!
The only outstanding issue for us is that the recorderReady events that each frame sends like this
const installPromise = this.setupRecorder(this.$('#videoRecorder'), true, {
    hidden: true
});
installPromise.then(() => {
    this.send('setTimeEvent', 'recorderReady');
});

are never recorded in any frames, which makes me suspect I don't understand how the installPromise works. Any ideas about what might be going on there? From our current data, it looks like this event hasn't been recorded before, so it's not a new thing, but it might be good to address while we're here.

Good catch on the recorderReady event.
It looks what is happening is that the resolve method specific to the installPromise is never actually getting resolved, if you choose to record:
https://github.com/abought/exp-addons/blob/0dece495326bc05fbc36ad5041d123717a718a44/exp-player/addon/services/video-recorder.js#L164-L164
Instead if returns a different promise. Normally this all works by magic, because under the hood some other code has done the work of calling resolve for us. But in this case not so much. Theoretically the fix will be pretty simple but developing a testing plan would be another matter; I've not been able to find any tests or spec for this code.
I suggest merging what we have here and then evaluating that as a separate PR, per Sara decision? (I'd be more sanguine about changing that piece if our schedule weren't so tight, but trying to play it safe for collaborators)

Thanks for looking into that, and cool that there's a simple explanation!
Sounds fine to me to merge this and deal with the installPromise separately - all we do with the promise is record the event anyway, and this code hasn't changed anything about that not working :) It'd probably be cleaner, going forward, to actually get back a promise, and be able to use that (rather than videoStreamConnection + hasCamAccess) to decide when to start trials.
Up to Sara on timeline!

Merged changes, and they should now be on staging. I'll be switching back to other tasks now, but if there are remaining items to be addressed as part of this ticket, please let Sara or myself know.

Sounds good - thanks so much!


fix release for nginx not package config files, eg: zookeeper.properties

Tips

Thanks very much for contributing to Apache DolphinScheduler.
Please review https://dolphinscheduler.apache.org/en-us/community/index.html before opening a pull request.

What is the purpose of the pull request
(For example: This pull request adds checkstyle plugin.)
Brief change log
(for example:)

Add maven-checkstyle-plugin to root pom.xml

Verify this pull request
(Please pick either of the following options)
This pull request is code cleanup without any test coverage.
(or)
This pull request is already covered by existing tests, such as (please describe tests).
(or)
This change added tests and can be verified as follows:
(example:)

Added dolphinscheduler-dao tests for end-to-end.
Added CronUtilsTest to verify the change.
Manually verified the change by testing locally.

good job
I'm a little confused about missing common.properties in dolphinscheduler-common module ?

thanks for your first contribution, if you need help, please contact<EMAIL_ADDRESS>or wechat(510570367), when added, please tell your github id

Here include common.properties, and I compiled again, common.properties is in the package. See the following picture


Include errors & traceback report.

See the script at ishere.lua

Here's an example of the usage:
C:\Users\Shawn\GitHub\ishere\src>lua ishere.lua .\.gitignore
Could not find the file ".\.gitignore"
.\.gitignore: No such file or directory
stack traceback:
        ishere.lua:11: in main chunk
        [C]: in ?
C:\Users\Shawn\GitHub\ishere\src>lua ishere.lua ..\.gitignore
The file "..\.gitignore" is available


Crash when deleting an item with no selection

Steps to reproduce:

Go to the BetterF3 mod settings.
Go to Left Modules.
Select the first module.
Delete it. There will be no selection, but the delete button is still clickable.
Click the delete button again.

I think the expected behavior would be to either disable the delete button, or select the next item in the list.
Crash log, using "Not Enough Crashes": https://gist.githubusercontent.com/natanfudge/e2921fbe4bd4cdd2085e838388bfd2de/raw/5fe8b1f55b79a83dd4a10c65f195ef0b4e17a1da/crash.txt

Thanks for the report! I'll look into it


Capitalize command

Hi @golergka - is this functionality not the same as the built in editor.action.transformToUppercase in VS Code?
See https://stackoverflow.com/questions/35184509/make-selected-block-of-text-uppercase


Packet Loss Monitoring?

Should we be monitoring packet loss between our Ingest / Edge servers? Should we be tracking NACK stats in prometheus as well?

Interesting idea of whether use of the blackbox_exporter on every node ICMP pinging (and/or FTL or HTTP check?) every other node. The issue is really how would be helpfully use this data. We would have end to end/both ways tracking of everything (great!). But how to helpfully visualise..!
If a node or region had an issue, we would see all/most pings to it see latency/loss, and potentially pings out would never be recorded/captured. Maybe some sort of aggregation based on a target label and tracking deviations from averages?

https://github.com/benjojo/sping might be another interesting tool to further investigate. Handily exposes /metrics as well.

I had seen https://grafana.com/grafana/plugins/grafana-synthetic-monitoring-app/ before, but had assumed it was Grafana Cloud only.
In fact, it's all open source (plugin is AGPLv3, client is Apache 2), though I the reality is that it's just blackbox_exporter + logs, and pretty graphs. We could just use blackbox_exporter and the graphs as inspiration:

And it's the graphs that give at least some idea how we could use the data. We would have a dashboard like that ^^ with var selectors for each instance.
Nice world map would highlight issues between regions.
Would we opt for every edge tracking every ingress + every ingress tracking every edge? That's the internal flow of data, so most relevant.
I expect it'd be cheap to add more locations on diff hosting providers if we wanted an external perspective.
==
Thoughts @clone1018

Would we opt for every edge tracking every ingress + every ingress tracking every edge? That's the internal flow of data, so most relevant.

I think this sounds like a good approach!


NTVS 1.2 Beta: IntelliSense For Locally Required Files needs VS 2015 Update 3 RTM+

In NTVS 1.2 Beta on VS 2015 Update 2, IntelliSense does not work for locally required files:
var my_file = require('./my_local_file');

my_file.
// No IntelliSense for `my_file` :(

This issue  was originally identified and tracked by #817. It is a Visual Studio / TypeScript bug, that is fixed by (the currently unreleased) VS 2015 Update 3 RTM.
Workaround
As a workaround, try adding a tsconfig.json to the root of your NTVS project with these options:
{
 "compilerOptions": {
   "allowJs": true,
   "moduleResolution": "node",
   "noEmit": true
 },
 "exclude": ["node_modules"]
}

And right click Save As this file into C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\CommonExtensions\Microsoft\TypeScript to replace the existing typescriptServices.js in that directory.

This issue has been resolved with Visual Studio 2015 Update 3 RTM https://www.visualstudio.com/news/releasenotes/vs2015-update3-vs


Setonetime boot calls  handler for reboot that fails

Setonetimeboot role sends message to "Reboot system to apply new BIOS settings" but then has a handler that makes does a reboot using redfish_command powerReboot that fails with ILO 5.  Why is this handler being called if the role is suggesting in return message to reboot.  And why do we need to reboot?  That is not necessary to set the onetime boot.

We have updated our collection to fix this


[MM-41999] Add additional logging for debugging, allow users to change log level

Summary
This PR adds a substantial amount of log statements to various functions in the main process. This should help facilitate debugging some of the stranger issues we've seen in the past from users, especially those that cannot be reproduced by developers.
I've switched to using 6 different log levels instead of the 3 we've been using. This loosely corresponds to this guide:
error - Something went wrong, and it's probably a big deal
warn - Something went wrong, but it's likely not a big deal
info - Just want to make sure you know something happened
verbose - Same as info if you care about a bit extra information
debug - Tells you basically everything the app is doing
silly - Same as debug, except it's basically every single function in the app

(and yes, the top one is called silly. Thanks electron-log :P)
The user will be able to switch between those log levels using a dropdown in the Settings window. This way developers can instruct users to turn on more verbose logging to help debug some issues. See screenshots below.
Ticket Link
https://mattermost.atlassian.net/browse/MM-41999
Screenshots

Release Note
Added a dropdown to select the logging level of the app for developers to help users debug complicated issues.

@esethna Added you for wording review.


RPi Pico LED

It would be useful for diagnostic purposes if the LED on the pico could be used as an indicator light.
A few ideas:

Fast Blink if power only and no USB data connection
Solid if power+data
Flicker on button press
Slow Blink if in web-config mode

Hi @FreddoUK ,
This is a great idea and we will look into implementation.

I am going to add this to the official bounty board and sponsor it.
Bounty number 7:  Enable onboard LED for visual status indicator
Web-UI element that has the following options:
1 - Off
2 - Mode indicator
3 - Input test mode
Off - LED is off
Mode indicator - LED is solid if unit is powered with connected data, LED blinks rapidly if powered with no data, LED blinks slowly when in web-config mode
Input test mode - LED is off but turns on when any input is pressed (LED turns off when button is released)

This is implemented and merged into main.


Support / fix dark mode

Doubts:

should slide miniatures also be rendered in dark mode?
should the exported pdf also be rendered in dark mode? (Excalidraw offers an option to export either in light or dark mode, should Excalideck also offer that option?)

Note: the possibility to toggle Dark Mode / change background colour has been removed in #36 (hiding the control with CSS), figuring it's better to have it off than on and broken. It will be re-added when this issue is solved.

Discussing the doubts posed:

It makes contextual sense for all widgets to adhere to dark mode once the canvas has switched. This is standard behavior for dark-mode-enabled interfaces, and is going to be expected by most if not all users.
Similarly as in (1), the users who eventually use both the dark mode and PDF export features will expect a consistent layout between both. I for one have encountered a similar problem in VSCode's Markdown rendering extension in the past.


nginx-ingress version

Hello Esigo, very nice example here.
Which version of nginx-ingress do you install to have the enable-opentelemetry annotation?
I saw a PR on the nginx-ingress project, but it still needs to be merged.
Regards!

Hi @csepulveda,
Thanks for your interest. The annotation will come when https://github.com/kubernetes/ingress-nginx/pull/9062 is merged.

@csepulveda FYI https://github.com/kubernetes/ingress-nginx/pull/9062 is just merged. This will be available with ingress-nginx 1.7.0.


KAFKA-3770: KStream job should be able to specify linger.ms

Hi @gfodor , could you check if #1465 handles this issue or not?

Hi @gfodor , #1465 has been merged into trunk. Could you check if already covers this PR?

Yes apologies for the delay here, will verify ASAP. Thanks for the ping.
On Wed, Jun 15, 2016 at 11:48 AM, Guozhang Wang<EMAIL_ADDRESS>wrote:

Hi @gfodor https://github.com/gfodor , #1465
https://github.com/apache/kafka/pull/1465 has been merged into trunk.
Could you check if already covers this PR?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/apache/kafka/pull/1463#issuecomment-226283157, or mute
the thread
https://github.com/notifications/unsubscribe/AANbdIzEqUeW_B0qverOYjxA4UF64lPOks5qMEkVgaJpZM4ItH1y
.

@gfodor If you agree that this issue has been resolved, please feel free to close this PR and the corresponding JIRA ticket as well.

Fixed via KAFKA-3786


1.10.2 Oxygen O2 system logical error

in a sealed room 3x3x3 the system still use O2 in vent
?? where do the oxygen go to ???
In my opinion, it would make sense to use ogygen to fill the room , 1 unit per block
and then, once filled, stop to use O2.
of course, if unsealed, all O2 "blocks" are gone/lost

When a person breathes air it is exhaled as CO2. Not exactly breathable. It has to be constantly filtered and replenished with oxygen. You can suffocate if the only air around you is CO2.

The idea behind the system is that the scrubbers remove the carbon from exhaled CO2, but without the scrubbers it is theorectically just venting CO2 into space but the lost CO2 needs to be replaced with fresh oxygen.

At some point would definatly like to continue to investigate this for future implementation though

you know the player coordinates
you know the coordinates of the scrubber
so, if player is in range x , he will produce co2,
therefore the vent is supplied by the scrubber , otherwise not

The vent does not supply a range, otherwise it would always be a regular shape like a cube or sphere, the range can also be large enough that the vent is no longer chunkloaded depending on whether or not volume based O2 is used, in that case I'd either have to keep the chunk loaded or constantly load it upon checking.


Avoidanceattributestorage

Attempt pull request of external stored avoidance attributes

This was supposed to be to engaric branch.

Ok. Still if you think that there are valueable pieces at some point feel free to post them as individual PRs!


Support different registries

As the WebContainer installs fresh node_modules in each usage, it would be great to support different npm registry for fast installation in everywhere 😄

It's on our roadmap to support pointing at different registries for sure!

show we use different registries now?

Really need this feature.

Hey 👋 Thanks for the report. This is definitely on our roadmap and once there's some progress we'll share it here.

Really need this feature, looking forwards to some updates of it!

Hey 👋 We have shipped StackBlitz Teams which allows you to use custom / private registries while at the same time being more secure that just using a .npmrc which is what we don't recommend because that file gets uploaded. With StackBlitz Teams you can configure tokens per registry via the dashboard and they will be stored securely.
I am going to close this one. If you have questions, feel free to respond to this issue anyways.


[Feat.Req] messages segregate by chains

Problem statement
At the moment all messages sent by the operators are sent to pubsub topic graphcast-v0. We should segregate the messages meant for different chains as different gossip networks.
Expectation proposal
Code changes on the radio operator to utilize block provider for the CAIP2 Chain Id, and then append to application name as the pubsub topic.
Alternative considerations
Radio channels are already filtered by on-chain identifiers, so we could potentially allow all messages to just routing within the graphcast-v0 protocol, but then we will have to assume that entities on different chains will not have ID collision.
Additional context
Also add handling to block provider failures.

great stuff! Awesome explanation of the issue. Btw don't we need to do the same for other chains as well (the ones coming in from MIPS - gnosis, polygon, etc)? Of course that can be done later on, for now supporting the different ETH flavours is enough


Get the values using index of slider thumbs.

Hi,
I just started using your control for one of my project and seriously loved it so much.
Only thing I would love to have on this control is getting the values using the thumb index.
For example:
Right now the code could look as under for ranges:
if (thumbIndex == 0) {                 doSmthForZero(String.valueOf(value));             } else if (thumbIndex == 1) {                 doSmthforOne(String.valueOf(value));             }  else {                 doSmthElse(String.valueOf(value));             }
I would like to see something on the lines of getThumb(1).getValue() inside the change event, like
getValueOf(thumbIndex);. OR on change  provide a method which return string as --  getRangeValues()
May be I am asking too much, however the concern is it is really difficult for anyone to display range such as 18-25 in a single label while it changes.
I have a label which has a string bound as 'Age Range: {0}-{1}' while I want to change the values of {0} and {1} with the values of thumbs.
-- N Baua

Okey,
Just went through the code once again, and wish I would have looked deeply earlier.
I could use the oSlider.getThumb(1).getValue() method.
Thanks for making this awesome library.
--  N Baua


cluster agent is not ready error seen when cluster does not have a node with worker role

What kind of request is this (question/bug/enhancement/feature request):
bug
Steps to reproduce (least amount of steps as possible):
Create Cluster

Add Cluster - Existing Nodes
Name it and hit next accepting the defaults
Node options/roles: select etcd and control plane (no worker)
Done

Add First Node
Result:

State: ERROR
Msg: Cluster health check failed: cluster agent is not ready

Other details that may be helpful:
I have tried this a number of times using different rancher docker tags and it continues to fail.
The last version that seems to work for me was v2.4.8
I thought this was related to issue 29652 but I tried master-head later and it still failed.  Also tried supplying a certificate (from the issue) and it still failed.
I can easily reproduce this so if someone wants me to try a different docker tag or gather logs, I can do so.
Environment information

Rancher version (rancher/rancher/rancher/server image tag or shown bottom left in the UI): latest, v2.5.1, v2.5-rc3, master-head(as of 10/21)
Installation option (single install/HA): Docker Rancher, attempting to create HA cluster
Ubuntu 18.04
ufw inactive

Cluster information

Cluster type (Hosted/Infrastructure Provider/Custom/Imported): Custom/Existing Nodes
Machine type (cloud/VM/metal) and specifications (CPU/memory): VM
Kubernetes version (use kubectl version): Whatever is bundled w/ the Rancher version (v1.19.3)
Docker version (use docker version):19.03.6

This is probably due to the new logic that now waits for the cluster agent to be healthy which it can't (also not in v2.4.x) but now waits for that condition. Can you explain the use-case that you have for just provisioning etcd + controlplane? Are you not running workers at all? Can you confirm it works when you add a worker?

My existing k8s cluster that I am looking at replacing w/ Rancher/rke has 3 masters and 10-15 worker nodes.  The masters do not take on worker loads.  In the past, I would get the 3 masters up and healthy.  Then just added worker nodes.
I re-tested w/ rancher:latest and if I leave the worker selected, I am able to successfully add the first master node.

So the cluster wasn't healthy either in v2.4.x, it just never checked if the cattle-cluster-agent was actually running and now it won't mark the cluster Ready/Active until its running. I actually think thats better as its a better indication what the state is of the cluster. There shouldn't be a problem provisioning all nodes at once, as the workers will wait for the cluster to form (etcd+controlplane) and then start provisioning after.
The only thing I can think off that we might change something in the error status so we still allow the user to query the cluster to troubleshoot/debug instead of blocking it off with error.
Can you let me know if, now that we know the root cause, this is no longer blocking you or is this blocking a certain use case?

Not sure what you are requesting.  If my intention is having 3 master's w/ out worker node roles, I can't do that in any Rancher version post 2.4.8 right?  So you are asking me to change my requirements, because post 2.4.8 has new restrictions?
I a guess I am no longer blocked in the fact that I can continue to get Rancher to move forward but it doesn't meet my needs that were met back in 2.4.8.  Per Rancher best practices, it says I shouldn't allow the masters to perform 'worker' loads?

@superseb I've just bumped into the same issue and it is a huge blocker for me to use rancher in a production environment
The checks for the cattle-cluster-agent sound like an excellent addition to make sure the cluster is stable. However it seems to me that the checks happen way to early when the cluster is initiated without worker nodes.
Granted that a cluster without worker nodes is a bit pointless, but that doesn't mean it should be tainted as unhealthy
I've been using rancher in test mode for a couple of weeks and everything has run extremely well when it comes to launching new clusters. However, this issue has made me realised that creating clusters with custom nodes only works when the cluster is initiated with a node which has ALL the three roles of etcd, control plane and worker.
For as long as I've been using kubernetes, separating workers from control plane/etcd nodes has been a 101 of kubernetes security best practices. Indeed, that's what's recommended in the rancher docs too:

Nodes should have one of the following role configurations:

etcd
controlplane
etcd and controlplane
worker (the worker role should not be used or added on nodes with the etcd or controlplane role)

A node with the three roles in production is a major security threat.
With this in mind, launching a cluster with custom nodes is impossible in the latest version of rancher (tried on 2.5.2rc3)
As a a workaround, I tried to first register the worker, and then one control plane node. But still no success.
I've even tried rebooting the control plane node to see if recreating containers solves the issue.
This is what I see in the console

These are the containers running in the control plane/etcd node:
CONTAINER ID        IMAGE                                  COMMAND                  CREATED             STATUS              PORTS               NAMES
20558bd7c273        03feeb39a75a                           "/usr/bin/kube-contr…"         41 minutes ago      Up 28 minutes                           kube-proxy
581ddc0d360b        rancher/hyperkube:v1.19.3-rancher1     "/opt/rke-tools/entr…"   41 minutes ago      Up 28 minutes                           kubelet
4b087290248a        rancher/hyperkube:v1.19.3-rancher1     "/opt/rke-tools/entr…"   42 minutes ago      Up 28 minutes                           kube-scheduler
b23640617888        rancher/hyperkube:v1.19.3-rancher1     "/opt/rke-tools/entr…"   42 minutes ago      Up 28 minutes                           kube-controller-manager
dee1bb16233c        rancher/hyperkube:v1.19.3-rancher1     "/opt/rke-tools/entr…"   42 minutes ago      Up 28 minutes                           kube-apiserver
1bb347d52be4        rancher/coreos-etcd:v3.4.13-rancher1   "/usr/local/bin/etcd…"   42 minutes ago      Up 28 minutes                           etcd

These are the containers running in the worker:
CONTAINER ID        IMAGE                                     COMMAND                  CREATED             STATUS              PORTS               NAMES
c64e01913119        rancher/metrics-server                    "/metrics-server --k…"   25 minutes ago      Up 25 minutes                           k8s_metrics-server_metrics-server-8449844bf-8vcjm_kube-system_2c4d7e44-cf5c-4d7a-82e0-1f8d6dcec478_1
db59b6ec97ec        rancher/pause:3.2                         "/pause"                 26 minutes ago      Up 26 minutes                           k8s_POD_metrics-server-8449844bf-8vcjm_kube-system_2c4d7e44-cf5c-4d7a-82e0-1f8d6dcec478_60
0c617b82f4a9        rancher/coredns-coredns                   "/coredns -conf /etc…"   36 minutes ago      Up 36 minutes                           k8s_coredns_coredns-6f85d5fb88-f9jqt_kube-system_d6102c4c-76e6-4d70-9484-78b7ffbc6d02_0
48d20782bf4c        rancher/pause:3.2                         "/pause"                 36 minutes ago      Up 36 minutes                           k8s_POD_coredns-6f85d5fb88-f9jqt_kube-system_d6102c4c-76e6-4d70-9484-78b7ffbc6d02_61
a5ec3e30e5ae        0bfefe9f649b                              "/opt/bin/flanneld -…"   37 minutes ago      Up 37 minutes                           k8s_kube-flannel_canal-fthpb_kube-system_c552a359-f970-4cc5-a1b1-202ba286ccd4_2
88e85bc9068b        rancher/cluster-proportional-autoscaler   "/cluster-proportion…"      38 minutes ago      Up 38 minutes                           nginx-proxy
d37343db2421        rancher/hyperkube:v1.19.3-rancher1        "/opt/rke-tools/entr…"   38 minutes ago      Up 38 minutes                           kubelet
3875095c27a2        rancher/hyperkube:v1.19.3-rancher1        "/opt/rke-tools/entr…"   38 minutes ago      Up 38 minutes                           kube-proxy

The behavior of the cluster recovering because there is no DNS in the cluster is the same for 2.4.x and 2.5.x, the only difference is that 2.4.x will show the cluster as "healthy" and 2.5.x will display the error regarding the cluster-agent. Both clusters recover after I add a worker, the only issue is that based on the crashloopbackoff state it can take up to ~10 minutes for the pod to get restarted.
I'm not saying this cannot be improved, I'm looking for the use cases where this is blocking from v2.4.x as both clusters behavior is the same. If your cluster never recovers (even after waiting), there is a bug somewhere or we are looking at a different cause. Can you share the output of the following command to confirm we are looking at the same problem?
docker ps -a -q --filter "label=io.kubernetes.container.name=cluster-register" | while read container; do echo "=> $container"; docker logs $container; done

Also, this issue is not about not splitting up roles, this is still recommended and still works the same way in v2.4.x and v2.5.x (besides the red bar showing in the UI).

thank you @superseb for taking the time to answer on a Sunday!
I deleted the cluster I was referring to yesterday and I've created a new one.
Reproduction of the same potential bug
This time I tested something different. Yesterday I created a worker, and then a control plane/etcd node. Today I created a control plane/etcd node first, and then added the worker. The result is the same as the cluster never became healthy (after more than one hour). However, there is one difference in that the worker is not even able to join the cluster doing things these way. It stays in "registering" state in the UI (all the general kubernetes containers are running though)
Diagnostics
For the command docker ps -a -q --filter "label=io.kubernetes.container.name=cluster-register" | while read container; do echo "=> $container"; docker logs $container; done I get this:
INFO: Environment: CATTLE_ADDRESS=<IP_ADDRESS> CATTLE_CA_CHECKSUM=ab088d9696eaf8bf505f9b4ddddb49a7eb05c699679987a1308799a2a896bfba CATTLE_CLUSTER=true CATTLE_FEATURES= CATTLE_INTERNAL_ADDRESS= CATTLE_IS_RKE=true CATTLE_K8S_MANAGED=true CATTLE_NODE_NAME=cattle-cluster-agent-78f8fc847-7c4tv CATTLE_SERVER=https://xxxxxxx.com
INFO: Using resolv.conf: nameserver <IP_ADDRESS> search cattle-system.svc.cluster.local svc.cluster.local cluster.local options ndots:5
ERROR: https://xxxxx.com/ping is not accessible (Could not resolve host: xxxxx.com)

The domain xxxx.com is just me redacting the identity of my real domain.
For reference, this is what I get in the worker for one of the containers running rancher/rancher-agent:v2.5.2-rc3 image (similar logs in the control plane too):
INFO: Arguments: --server https://xxxx.com --token REDACTED --ca-checksum ab088d9696eaf8bf505f9b4ddddb49a7eb05c699679987a1308799a2a896bfba --no-register --only-write-certs --node-name worker1
INFO: Environment: CATTLE_ADDRESS=x.x.x.x CATTLE_AGENT_CONNECT=true CATTLE_INTERNAL_ADDRESS= CATTLE_NODE_NAME=worker1 CATTLE_SERVER=https://xxxx.com CATTLE_TOKEN=REDACTED CATTLE_WRITE_CERT_ONLY=true
INFO: Using resolv.conf: nameserver <IP_ADDRESS> nameserver <IP_ADDRESS> nameserver <IP_ADDRESS> nameserver 2a01:4f8:0:1::add:1010 nameserver 2a01:4f8:0:1::add:9999 nameserver 2a01:4f8:0:1::add:9898
INFO: https://xxxx.com/ping is accessible
INFO: xxxx.com resolves to x.x.x.x x.x.x.x x.x.x.x
INFO: Value from https://xxxx.com/v3/settings/cacerts is an x509 certificate
time="2020-10-25T17:39:08Z" level=info msg="Listening on /tmp/log.sock"
time="2020-10-25T17:39:08Z" level=info msg="Rancher agent version v2.5.2-rc3 is starting"
time="2020-10-25T17:39:08Z" level=info msg="Option etcd=false"
time="2020-10-25T17:39:08Z" level=info msg="Option controlPlane=false"
time="2020-10-25T17:39:08Z" level=info msg="Option worker=false"
time="2020-10-25T17:39:08Z" level=info msg="Option requestedHostname=worker1"
time="2020-10-25T17:39:08Z" level=info msg="Option customConfig=map[address:x.x.x.x internalAddress: label:map[] roles:[] taints:[]]"
time="2020-10-25T17:39:08Z" level=info msg="Connecting to wss://xxxx.com/v3/connect with token m89hx886sfbbslnkffxdw7685qbh9q86tq8wv7mqgdzbh25kgxxcns"
time="2020-10-25T17:39:08Z" level=info msg="Connecting to proxy" url="wss://xxxx.com/v3/connect"
time="2020-10-25T17:39:08Z" level=info msg="Starting plan monitor, checking every 120 seconds"
time="2020-10-25T18:34:44Z" level=error msg="Remotedialer proxy error" error="websocket: close 1006 (abnormal closure): unexpected EOF"
time="2020-10-25T18:34:54Z" level=info msg="Connecting to wss://xxxx.com/v3/connect with token m89hx886sfbbslnkffxdw7685qbh9q86tq8wv7mqgdzbh25kgxxcns"
time="2020-10-25T18:34:54Z" level=info msg="Connecting to proxy" url="wss://xxxx.com/v3/connect"
time="2020-10-25T18:34:54Z" level=info msg="Starting plan monitor, checking every 120 seconds"

Some findings that may point to DNS resolution issues
I don't know the internals of what's going on here, but if DNS resolution is the issue then I've noticed something that looks odd to me. Whereas the cluster-register container resolves the env variable CATTLE_ADDRESS to an IP within cluster's pod CIDR, all the other containers using the rancher agent image resolve it to the IP of the host in the public interface
The nameservers used to resolve the cattle host also indicate that the pod that failed used internal DNS resolution, while the others use the host's DNS resolution

As an after thought, I just tried docker run busybox ping -c 1 xxxx.com in the control plane node (xxx.com being my rancher domain) and docker resolves the domain correctly

The kubelet registers itself to the cluster using the nginx in the nginx-proxy container, please share logs from nginx-proxy and kubelet to determine why it can't register to the cluster.

But I thought nginx was optional? How would it work if I disable the nginx proxy (which is indeed what I'll want to do as I'll only use Istio ingress)?
In the meantime, I've just checked the logs, and for the nginx-proxy I get:
2020/10/25 22:10:29 [error] 13#13: *57043 upstream timed out (110: Operation timed out) while connecting to upstream, client: <IP_ADDRESS>, server: <IP_ADDRESS>:6443, upstream: "x.x.x.x:6443", bytes from/to client:0/0, bytes from/to upstream:0/0

where the upstream IP is the worker node's itself.
and probably more revealing, the kubelet logs:
E1026 01:51:26.623159 1199390 kubelet.go:2103] Container runtime network not ready: NetworkReady=false reason:NetworkPluginNotReady message:docker: network plugin is not ready: cni config uninitialized
E1026 01:51:26.689631 1199390 kubelet.go:2183] node "worker1" not found
I1026 01:51:26.774204 1199390 kubelet_node_status.go:334] Setting node annotation to enable volume controller attach/detach
E1026 01:51:26.789741 1199390 kubelet.go:2183] node "worker1" not found
I1026 01:51:26.799173 1199390 kubelet_node_status.go:526] Recording NodeHasSufficientMemory event message for node worker1
I1026 01:51:26.799191 1199390 kubelet_node_status.go:526] Recording NodeHasNoDiskPressure event message for node worker1
I1026 01:51:26.799196 1199390 kubelet_node_status.go:526] Recording NodeHasSufficientPID event message for node worker1
I1026 01:51:26.799224 1199390 kubelet_node_status.go:70] Attempting to register node worker1
E1026 01:51:26.889934 1199390 kubelet.go:2183] node "worker1" not found
E1026 01:51:26.990132 1199390 kubelet.go:2183] node "worker1" not found
E1026 01:51:27.090328 1199390 kubelet.go:2183] node "worker1" not found
E1026 01:51:28.800468 1199390 kubelet_node_status.go:92] Unable to register node "worker1" with API server: Post "https://<IP_ADDRESS>:6443/api/v1/nodes": read tcp <IP_ADDRESS>:42288-><IP_ADDRESS>:6443: read: connection reset by peer
E1026 01:51:28.894420 1199390 kubelet.go:2183] node "worker1" not found
E1026 01:51:28.994701 1199390 kubelet.go:2183] node "worker1" not found
W1026 01:51:29.458902 1199390 cni.go:239] Unable to update cni config: no networks found in /etc/cni/net.d
E1026 01:51:29.495995 1199390 kubelet.go:2183] node "worker1" not found

There is no /etc/cni/net.dfile
This is a bit confusing for me as I come from a kubeadm world where the worker nodes do not listen on port 6443 (as the api is a concerned of the control plane)

Any non-controlplane node uses nginx-proxy locally to load balance between all the available controlplane nodes. It runs on <IP_ADDRESS>:6443 and generates the nginx.conf based on the controlplane nodes in the cluster. The configuration can be viewed using:
docker exec nginx-proxy cat /etc/nginx/nginx.conf

The kubelet is configured to connect to this local nginx-proxy which then passes the connection to a controlplane node. If you are adding a worker and the nginx.conf is generated with its own IP, there is something wrong here. What IP addresses are used/discovered when registering?
@kable-wilmoth Can you confirm that adding a separate node with only the worker role will make the cluster go into Active state? If not, can you confirm that you are running into the same logging/error as described above? This to separate multiple issues.

the more I learn about rancher the more I like it! Thanks for the explanation on the nginx load balancer. I used to have to do that myself outside the cluster and that's neat
I looked at the nginx config and the IP of the control plane was indeed correct. This was my fault as I created this cluster without specifying that nodes should be using the private network for internal purposes and the firewall rules didn't match. Apologies for not having seen this earlier
After applying a fix on the firewall the worker has joined, which brings this cluster to the same bad state as the one I reported initially. There is one worker, and one control plane/etcd node. Both have registered correctly. But the cluster does not go healthy because of the cluster agent is not ready error as per my screenshot
So to summarise:

If I register a node with all roles, cluster becomes healthy
If I register a control_plane node and then a worker, both join OK but I get cluster agent is not ready error. Cluster is not healthy and so I can't inspect with kubectl, etc.
If I register a worker node and then the control plane, I get the same behaviour as in (2)

The behavior should be that the worker node joins and eventually the needed pods (coredns) are scheduled and running and the cattle-cluster-agent gets restarted (which can take up to ~10 minutes) because of CrashLoopBackOff state. If it doesn't become healthy, there is still an issue. To find the issue, we need logging from kubelet from the worker node, logging from kubelet from the the etcd/controlplane node.

It's been more than 2 hours since the worker joined and cluster is still not healthy.
These are the logs since the moment the worker joined
kubelet-worker.log
kubelet-control-plane.log

We probably need the same info as before we found that the kubelet wasn't able to join the cluster:

docker ps -a from controlplane and worker
Output of docker ps -a -q --filter "label=io.kubernetes.container.name=cluster-register" | while read container; do echo "=> $container"; docker logs $container; done
If the error is the same (Could not resolve host), please try manual DNS resolution:

Run dig rancher.yourdomain.com @<IP_ADDRESS> on controlplane
Run dig rancher.yourdomain.com @<IP_ADDRESS> on worker

@superseb so I have an active cluster if when creating it I allow the control plane nodes to also be master.  You would like me to start over, create my control plan (3 etcd/control plane) and then try to add a 4th node w/ just worker role.  For some reason, I didn't think i could do that because the cluster was in a fail state BUT I probably just assumed that and didn't want to keep adding problems at that point.  Will give this a test.

It took a while and after the first node, you loose a lot of the feedback so people would probably give up.  After I added the 4th node w/ worker role, after a bit, everything turned ACTIVE and it looks healthy.

Thanks for verifying. For node driver clusters, we already require a worker to be added. For custom cluster, you are a bit more free but I think we should be able to let the user know that we require a worker for this to work. Another path is to explore the explicit reason to launch coredns on workers only and not on the controlplane as that would also fix this issue. I'll report back but at least this verifies that it can work like I tested it and that we run into a different issue for @cortopy

I have the same issue, but for me, the cluster does not get healthy even when using node with all three roles.
I did leave the cluster running overnight, no change other than several hundreds recreations of container k8s_cluster-register_cattle-cluster-agent-5849799686-cn7j6_cattle-system_4644ce37-d98a-44d6-b8ff-d581713540ea_xxx
It fails every time with wrong dns hostname lookup for Rancher. I have public dns A record for my domain, but rancher is not meant to be public, so there is no port forwarding.
I have found the description of this issue way back in january here.
Ouput of command docker ps -a -q --filter "label=io.kubernetes.container.name=cluster-register" | while read container; do echo "=> $container"; docker logs $container; done
=> deb27488740c
INFO: Environment: CATTLE_ADDRESS=<IP_ADDRESS> CATTLE_CA_CHECKSUM=5bd5632b37de5f40b5ef0233aa01fe86ae081c22e2f6633dcb8fbde586a6e80a CATTLE_CLUSTER=true CATTLE_FEATURES= CATTLE_INTERNAL_ADDRESS= CATTLE_IS_RKE=true CATTLE_K8S_MANAGED=true CATTLE_NODE_NAME=cattle-cluster-agent-545797bb9c-wslc4 CATTLE_SERVER=https://rancher.redacted.cz
INFO: Using resolv.conf: nameserver <IP_ADDRESS> search cattle-system.svc.cluster.local svc.cluster.local cluster.local redacted.cz options ndots:5
ERROR: https://rancher.redacted.cz/ping is not accessible (Could not resolve host: rancher.redacted.cz)
=> 0822de2af85b
INFO: Environment: CATTLE_ADDRESS=<IP_ADDRESS> CATTLE_CA_CHECKSUM=5bd5632b37de5f40b5ef0233aa01fe86ae081c22e2f6633dcb8fbde586a6e80a CATTLE_CLUSTER=true CATTLE_FEATURES= CATTLE_INTERNAL_ADDRESS= CATTLE_IS_RKE=true CATTLE_K8S_MANAGED=true CATTLE_NODE_NAME=cattle-cluster-agent-545797bb9c-wslc4 CATTLE_SERVER=https://rancher.redacted.cz
INFO: Using resolv.conf: nameserver <IP_ADDRESS> search cattle-system.svc.cluster.local svc.cluster.local cluster.local redacted.cz options ndots:5
ERROR: https://rancher.redacted.cz/ping is not accessible (Could not resolve host: rancher.redacted.cz)

Hostname should be resolved via local DNS. If I docker commit cattle-register cattle-cluster-agent container and run it in interactive, I can successfully ping Rancher server.
This is related to several issues: https://github.com/rancher/rancher/issues/16454 https://github.com/rancher/rancher/issues/28836 https://github.com/rancher/rancher/issues/28605 https://github.com/rancher/rancher/issues/29633 https://github.com/rancher/rancher/issues/29652 https://github.com/rancher/rancher/issues/25949 - might be way more.

When Rancher is installed and you visit the UI for the first time, it asks you to configure a server-url where Rancher can be accessed. This needs to be a FQDN which is resolvable through DNS (proper DNS because pods resolve through cluster dns which means it actually needs to query DNS). That is 75% of the time the issue when it cannot be resolved. Other possible causes are broken overlay networking and thus DNS not working, or running a local DNS cache nameserver that cannot be used. We are investigating possibilities of the latter for cortopy setup as we already confirmed the logic works (by me and kable-wilmoth.
In this case, I cannot resolve the host, while you say it fails every time with wrong dns hostname lookup for Rancher. What wrong response do you get versus it saying it cannot resolve? Any info that you can provide on the setup helps in diagnosing the issue.
I also removed all the issue references as not every cattle-cluster-agent issue is the same root cause.

In my case, all the logs are the same as I reported earlier, including the inability for cluster-register to resolve the DNS of the rancher installation
The command dig rancher.yourdomain.com @<IP_ADDRESS> turned out to be the key to understand a little bit more what was going on. The command worked in the worker but not in the control plane. In order to test if it's something to do with ports and the firewall (external hardware) I disabled it and the command worked! At that moment, cluster-register succeeded next time it was created
However, this raises another issue since I'm not sure if the firewall rules in the docs cover this issue (dns resolution). The command dig rancher.yourdomain.com @<IP_ADDRESS> uses port 53 UDP, and so this became extremely hard for me to debug since I don't know how dns resolution is supposed to happen differently in the dig command and in the cluster
This made me think that maybe it's all an issue with the firewall, and so I went with creating a cluster with the configuration that I need and leave the firewall disabled. In particular I need canal/flannel to use the interface for the private network in my nodes. As soon as I create a cluster using canal_iface I go back to square one. This is what I observed when setting iface:

flannel logs seem fine and it picks the right interface and IP
dig rancher.yourdomain.com @<IP_ADDRESS> works in worker and not in control plane
the logs from the cluster-register are all the same, no DNS resolution
docker exec into the rancher agent pod in the worker allows me to ping and resolve external domains. I don't know how to pin a service in the control plane as I can't use kubectl to inspect. This experiment also works in the control plane's pod of rancher agent

@superseb All those linked issues were not picked by blindless searching for cattle-cluster-agent problems. They were exactly the same, i.e. rancher server DNS not resolving.
What is the meaning of "proper DNS"? I have a homelab + home network behind pfSense. There is a local DNS resolver (not visible from public network) for all my internal services like Rancher server, Portainer, vCenter, etc... DHCP clients gets registered in DNS automatically. Rancher is resolved and accessible from every VM I tried, even from the Windows machine, where I explicitly flushed DNS cache.
I also have a publicly visible DNS hosted on my domain registrator. There is few subdomain A records and a wildcard A record pointing to my pfSense server for internal services I want to access publicly (Nextcloud for example). In pfSense I am port forwarding subdomains to Traefik proxy with SSL termination. This is not the case for Rancher tho as I mentioned above.
I wanted to get you output from dig command, but I don't understand, where I should use it. I have only one node with all three roles (etd, Control Plane and worker). If I dig the rancher server from there, it works as expected. If I dig with @<IP_ADDRESS>, it fails as this IP does not exist. If you tell me, which docker container I should dig in with @<IP_ADDRESS>, I'll be happy to.
CONTAINER ID        IMAGE                                             COMMAND                  CREATED             STATUS                     PORTS               NAMES
5bec02f73cba        141c7125f5a2                                      "run.sh"                 2 minutes ago       Exited (1) 2 minutes ago                       k8s_cluster-register_cattle-cluster-agent-545797bb9c-wslc4_cattle-system_7c7d87b5-42a0-414c-935f-d3c1f5731ed2_132
ca17d71d5352        rancher/metrics-server                            "/metrics-server --k…"   11 hours ago        Up 11 hours                                    k8s_metrics-server_metrics-server-8449844bf-lrs6l_kube-system_92a542e3-3252-44d2-b907-2d9d834ae1d4_0
a9023275c636        rancher/calico-kube-controllers                   "/usr/bin/kube-contr…"   11 hours ago        Up 11 hours                                    k8s_calico-kube-controllers_calico-kube-controllers-649b7b795b-cd46l_kube-system_914ae0ee-49ec-442d-91d6-29d5c2cb8c82_0
ae11b667f810        rancher/coredns-coredns                           "/coredns -conf /etc…"   11 hours ago        Up 11 hours                                    k8s_coredns_coredns-6f85d5fb88-dhmqp_kube-system_3a076418-ffbf-4980-a703-b4db0fa78422_0
02ecf28f39b3        rancher/cluster-proportional-autoscaler           "/cluster-proportion…"   11 hours ago        Up 11 hours                                    k8s_autoscaler_coredns-autoscaler-79599b9dc6-lrp4k_kube-system_e169ff19-74d4-4662-b76f-5e381922b235_0
4fc931f3acdd        rancher/nginx-ingress-controller-defaultbackend   "/server"                11 hours ago        Up 11 hours                                    k8s_default-http-backend_default-http-backend-65dd5949d9-hx62b_ingress-nginx_3352eacb-f667-497c-8a7c-536563c95498_0
363b689c60b5        rancher/coreos-flannel                            "/opt/bin/flanneld -…"   11 hours ago        Up 11 hours                                    k8s_kube-flannel_canal-592hb_kube-system_c1209a45-1728-495d-b12d-738ea8ffd0f9_0
0b1cd6632f95        rancher/pause:3.2                                 "/pause"                 11 hours ago        Up 11 hours                                    k8s_POD_cattle-cluster-agent-545797bb9c-wslc4_cattle-system_7c7d87b5-42a0-414c-935f-d3c1f5731ed2_2
07c7fcf3def8        rancher/kube-api-auth                             "/bin/sh -c 'kube-ap…"   11 hours ago        Up 11 hours                                    k8s_kube-api-auth_kube-api-auth-zlf9p_cattle-system_c3331bc9-846f-4bdf-9192-f595d9c3ed53_0
d6cbd9a0c283        rancher/pause:3.2                                 "/pause"                 11 hours ago        Up 11 hours                                    k8s_POD_coredns-6f85d5fb88-dhmqp_kube-system_3a076418-ffbf-4980-a703-b4db0fa78422_5
7cadc2b28d56        rancher/pause:3.2                                 "/pause"                 11 hours ago        Up 11 hours                                    k8s_POD_calico-kube-controllers-649b7b795b-cd46l_kube-system_914ae0ee-49ec-442d-91d6-29d5c2cb8c82_5
a0ba00129e5e        rancher/pause:3.2                                 "/pause"                 11 hours ago        Up 11 hours                                    k8s_POD_metrics-server-8449844bf-lrs6l_kube-system_92a542e3-3252-44d2-b907-2d9d834ae1d4_5
0d887e7de3d8        rancher/pause:3.2                                 "/pause"                 11 hours ago        Up 11 hours                                    k8s_POD_coredns-autoscaler-79599b9dc6-lrp4k_kube-system_e169ff19-74d4-4662-b76f-5e381922b235_5
1366999f3e24        rancher/calico-node                               "start_runit"            11 hours ago        Up 11 hours                                    k8s_calico-node_canal-592hb_kube-system_c1209a45-1728-495d-b12d-738ea8ffd0f9_0
7d100033f13a        rancher/pause:3.2                                 "/pause"                 11 hours ago        Up 11 hours                                    k8s_POD_default-http-backend-65dd5949d9-hx62b_ingress-nginx_3352eacb-f667-497c-8a7c-536563c95498_4
7f3019f211d3        141c7125f5a2                                      "run.sh"                 11 hours ago        Up 11 hours                                    k8s_agent_cattle-node-agent-gpfp5_cattle-system_bc310ce2-ade0-4602-b161-b3234a79e459_0
e6f63b828b4b        rancher/pause:3.2                                 "/pause"                 11 hours ago        Up 11 hours                                    k8s_POD_kube-api-auth-zlf9p_cattle-system_c3331bc9-846f-4bdf-9192-f595d9c3ed53_0
773f99d15fc5        rancher/pause:3.2                                 "/pause"                 11 hours ago        Up 11 hours                                    k8s_POD_cattle-node-agent-gpfp5_cattle-system_bc310ce2-ade0-4602-b161-b3234a79e459_0
aff2a6558907        rancher/rancher-agent:v2.5.1                      "run.sh -- share-roo…"   11 hours ago        Exited (0) 11 hours ago                        share-mnt
4f9d62d636c6        rancher/nginx-ingress-controller                  "/usr/bin/dumb-init …"   11 hours ago        Up 11 hours                                    k8s_nginx-ingress-controller_nginx-ingress-controller-blbfz_ingress-nginx_1e3e5662-2d23-4510-b194-6169f161b71c_0
cdab1dce2834        rancher/calico-pod2daemon-flexvol                 "/usr/local/bin/flex…"   11 hours ago        Exited (0) 11 hours ago                        k8s_flexvol-driver_canal-592hb_kube-system_c1209a45-1728-495d-b12d-738ea8ffd0f9_0
cd5ad463889f        rancher/pause:3.2                                 "/pause"                 11 hours ago        Up 11 hours                                    k8s_POD_nginx-ingress-controller-blbfz_ingress-nginx_1e3e5662-2d23-4510-b194-6169f161b71c_0
dc838d9cfcfc        4beef00ca5da                                      "kubectl apply -f /e…"   11 hours ago        Exited (0) 11 hours ago                        k8s_rke-ingress-controller-pod_rke-ingress-controller-deploy-job-8ff7b_kube-system_97e17d9f-47ef-4d2a-97d7-2e6eabee4f83_0
5dcf118ae663        rancher/pause:3.2                                 "/pause"                 11 hours ago        Exited (0) 11 hours ago                        k8s_POD_rke-ingress-controller-deploy-job-8ff7b_kube-system_97e17d9f-47ef-4d2a-97d7-2e6eabee4f83_0
06d3836f2c5e        rancher/calico-cni                                "/opt/cni/bin/install"   11 hours ago        Exited (0) 11 hours ago                        k8s_install-cni_canal-592hb_kube-system_c1209a45-1728-495d-b12d-738ea8ffd0f9_0
822376430ac9        4beef00ca5da                                      "kubectl apply -f /e…"   11 hours ago        Exited (0) 11 hours ago                        k8s_rke-metrics-addon-pod_rke-metrics-addon-deploy-job-9jmpl_kube-system_415d8bb5-a231-4f13-996d-0e2d3571ef64_0
f55b7726b6f2        rancher/pause:3.2                                 "/pause"                 11 hours ago        Exited (0) 11 hours ago                        k8s_POD_rke-metrics-addon-deploy-job-9jmpl_kube-system_415d8bb5-a231-4f13-996d-0e2d3571ef64_0
4edb3d541e6d        4beef00ca5da                                      "kubectl apply -f /e…"   11 hours ago        Exited (0) 11 hours ago                        k8s_rke-coredns-addon-pod_rke-coredns-addon-deploy-job-cfstm_kube-system_902e3738-b81f-4d5c-8baf-e9b513ec16e3_0
f60d61b53ac3        rancher/pause:3.2                                 "/pause"                 11 hours ago        Exited (0) 11 hours ago                        k8s_POD_rke-coredns-addon-deploy-job-cfstm_kube-system_902e3738-b81f-4d5c-8baf-e9b513ec16e3_0
51875d790171        rancher/pause:3.2                                 "/pause"                 11 hours ago        Up 11 hours                                    k8s_POD_canal-592hb_kube-system_c1209a45-1728-495d-b12d-738ea8ffd0f9_0
a75d4339801c        4beef00ca5da                                      "kubectl apply -f /e…"   11 hours ago        Exited (0) 11 hours ago                        k8s_rke-network-plugin-pod_rke-network-plugin-deploy-job-t78dg_kube-system_456a1746-0ad7-4a85-911b-e64a7dd55780_0
8f779a55e09a        rancher/pause:3.2                                 "/pause"                 11 hours ago        Exited (0) 11 hours ago                        k8s_POD_rke-network-plugin-deploy-job-t78dg_kube-system_456a1746-0ad7-4a85-911b-e64a7dd55780_0
0e74512ec831        rancher/hyperkube:v1.19.3-rancher1                "/opt/rke-tools/entr…"   11 hours ago        Up 11 hours                                    kube-proxy
da4a21450e8e        rancher/hyperkube:v1.19.3-rancher1                "/opt/rke-tools/entr…"   11 hours ago        Up 11 hours                                    kubelet
e4d7792c7f00        rancher/hyperkube:v1.19.3-rancher1                "/opt/rke-tools/entr…"   11 hours ago        Up 11 hours                                    kube-scheduler
cba0a7b66e7c        rancher/hyperkube:v1.19.3-rancher1                "/opt/rke-tools/entr…"   11 hours ago        Up 11 hours                                    kube-controller-manager
eca919a5fd46        rancher/hyperkube:v1.19.3-rancher1                "/opt/rke-tools/entr…"   11 hours ago        Up 11 hours                                    kube-apiserver
eeb95a7c525f        rancher/rke-tools:v0.1.65                         "/bin/bash"              11 hours ago        Created                                        service-sidekick
1ebb9e0e9ca8        rancher/coreos-etcd:v3.4.13-rancher1              "/usr/local/bin/etcd…"   11 hours ago        Up 11 hours                                    etcd
ee5e3bab0157        rancher/rke-tools:v0.1.65                         "/docker-entrypoint.…"   11 hours ago        Exited (0) 11 hours ago                        cluster-state-deployer

The logs from CoreDNS (which only tells us if its properly running without debug) can be shown using:
docker logs $(docker ps -q -f label="io.kubernetes.container.name"=coredns)

The IP of the cluster DNS is <IP_ADDRESS>, so you can try using dig rancher.yourdomain.com @<IP_ADDRESS> as stated above to see what it resolves to (this is on the node added to the cluster). Only other things I can think of are possible configuration of /etc/resolv.conf or a local caching DNS nameserver on the host. I've seen issues with wildcard DNS but this usually results in a wildcard record being hit and directing to a different service than the intended one, this usually does not result in Could not resolve host.

Indeed, wildcard certificate does not result in Could not resolve host, but 404. In principle it's the same issue tho. This was already covered in the article above https://adamo.wordpress.com/2020/01/14/ranchers-cattle-cluster-agent-and-error-404/
Anyway... I created another cluster with a node per single role. Here's the output:
Control Pane
ubuntu@srv01-ctrl-1:~$ sudo docker logs $(sudo docker ps -q -f label="io.kubernetes.container.name"=coredns)
"docker logs" requires exactly 1 argument.
See 'docker logs --help'.

	IN	A

;; ANSWER SECTION:
rancher.domain.cz. 8	IN	A	<IP_ADDRESS>

;; Query time: 0 msec
;; SERVER: <IP_ADDRESS>#53(<IP_ADDRESS>)
;; WHEN: Tue Oct 27 11:07:25 UTC 2020
;; MSG SIZE  rcvd: 109

ETCD
ubuntu@srv01-etcd-1:~$ sudo docker logs $(sudo docker ps -q -f label="io.kubernetes.container.name"=coredns)
"docker logs" requires exactly 1 argument.
See 'docker logs --help'.

	IN	A

;; ANSWER SECTION:
rancher.domain.cz. 15	IN	A	<IP_ADDRESS>

;; Query time: 0 msec
;; SERVER: <IP_ADDRESS>#53(<IP_ADDRESS>)
;; WHEN: Tue Oct 27 11:07:18 UTC 2020
;; MSG SIZE  rcvd: 109

Worker
ubuntu@srv01-worker-1:~$ sudo docker logs $(sudo docker ps -q -f label="io.kubernetes.container.name"=coredns)
.:53
[	IN	A

;; ANSWER SECTION:
rancher.domain.cz. 30	IN	A	<IP_ADDRESS>

;; Query time: 0 msec
;; SERVER: <IP_ADDRESS>#53(<IP_ADDRESS>)
;; WHEN: Tue Oct 27 11:07:02 UTC 2020
;; MSG SIZE  rcvd: 97

So to summarize. CoreDNS runs only in worker node. Rancher server is resolved from all three nodes (IP <IP_ADDRESS> is correct).

Yes please create a new issue, dont split the roles as it only complicates things and its much easier to debug with a single machine. Please include the logs from cattle-cluster-agent and kubelet, and the information about the OS (mostly what kernel and if present, host firewall configuration)

@superseb I'm not sure if you saw my message earlier, but after that I carried on trying different things. I'm happy to say that all issues are gone if I use calico
So another summary of what I've tried to so far:

One node with all roles always works
Canal using default network interface also works
Canal using private network interface never works
Calico works (provided I add some crazy firewall rules to allow DNS resolution from control plane to worker)

Having now spent many days on this issue I'm even more convinced that control plane nodes should be able to be healthy without depending on others. My expectation would be that the cluster is healthy once the first node is up, and then the state of the cluster is in "waiting" state until all roles are present. Using kubectl during this early stage would be so helpful!!
Introducing DNS resolution that depends on the existence and stable connection with at least one worker feels like it's at the bottom of all the problems I've been experiencing. Not least because a control plane that waits for the first worker stays with the "cluster agent is not ready" error, even while the worker is in a registering state. Debugging is just nearly impossible (e.g.: I still don't know what the issue with flannel is). My favourite CNI is Cilium but given this experience I wouldn't even dare to start a cluster without any CNI deployed.
Also related to the use case of hardened clusters like mine, external firewall configurations can be extremely difficult with overlays. Delegating DNS resolution to one is calling for even more trouble.

On 2.5.0-rc8 (10/5/2020)

Faced an issue similar to the original one.
Deploy a windows cluster - 1 node etcd/control plane and 3 windows worker node and NO Linux worker node
This cluster does not recover from this error Cluster health check failed: cluster agent is not ready
The cluster recovered when 1 linux worker node was added to the cluster

My VM templates (Centos 7.8) were using firewalld. When I removed it, the cluster installation finished successfully. I were adding more and more port openings to my template, and did not get it to work. I think Ranchers documentation need an update about what requirements Rancher have on VM templates. Or Rancher produced kickstart files and similar for other OS:es.

Same issue with v2.5.2 and Bare Metal + terraform.
node-> control+etcd
work-> worker
If the hosts register in this order the error appears:
module.k8s_cluster.null_resource.cluster_nodes["node-3"]: Creation complete after 27s [id=7987953507597298733]
module.k8s_cluster.null_resource.cluster_nodes["node-1"]: Creation complete after 27s [id=390062523069814721]
module.k8s_cluster.null_resource.cluster_nodes["node-2"]: Creation complete after 27s [id=5069222939592754326]
module.k8s_cluster.null_resource.cluster_nodes["work-1"]: Creation complete after 27s [id=4399590074894980930]
module.k8s_cluster.null_resource.cluster_nodes["work-3"]: Creation complete after 27s [id=2633117467603870906]
module.k8s_cluster.null_resource.cluster_nodes["work-2"]: Creation complete after 27s [id=1139161877529620383]

If they register this this order it works:
module.k8s_cluster.null_resource.cluster_nodes["node-2"]: Creation complete after 25s [id=1136617860855636338]
module.k8s_cluster.null_resource.cluster_nodes["work-3"]: Creation complete after 26s [id=2235442029882892698]
module.k8s_cluster.null_resource.cluster_nodes["work-1"]: Creation complete after 27s [id=8650905267792694987]
module.k8s_cluster.null_resource.cluster_nodes["work-2"]: Creation complete after 27s [id=5939226371038830070]
module.k8s_cluster.null_resource.cluster_nodes["node-1"]: Creation complete after 27s [id=799686223658873238]
module.k8s_cluster.null_resource.cluster_nodes["node-3"]: Creation complete after 27s [id=1081439579899701676]

Agree with Jost, doc updates to reflect expected /etc/hosts and other environment details would be helpful. This is consistently failing to roll out on bare metal and when using the latest rancher quick start solultion. Happy to provide further logs as required.

Agree with Jost, doc updates to reflect expected /etc/hosts and other environment details would be helpful. This is consistently failing to roll out on bare metal and when using the latest rancher quick start solultion. Happy to provide further logs as required.

Can we also confirm that the issue has been resolved before closing ? I'm certainly still seeing this issue.

Can we also confirm that the issue has been resolved before closing ? I'm certainly still seeing this issue.

Hi, I am also seeing a very similar issue Rancher 2.5.x  installing RKE cluster onto baremetal (HyperV)
default settings. One node with all 3 roles.
If I look at the logs of the cluster-agent container I have:
INFO: Using resolv.conf: nameserver <IP_ADDRESS> search cattle-system.svc.cluster.local svc.cluster.local cluster.local bluecrest.local options ndots:5
ERROR: https://rancher-dev/ping is not accessible (Failed to connect to rancher-dev port 443: Connection timed out)
Our rancher URL is rancher-dev  because the FQDN  ends in .local   which Rancher does not allow.
I have tested using the IP address for the rancher server and I get the same error.
I have tested v2.50,1,2,3 and all have the same issue.
The only way I can provision an RKE cluster without this error is to go back to v2.4.11

Hi, I am also seeing a very similar issue Rancher 2.5.x  installing RKE cluster onto baremetal (HyperV)
default settings. One node with all 3 roles.
If I look at the logs of the cluster-agent container I have:
INFO: Using resolv.conf: nameserver <IP_ADDRESS> search cattle-system.svc.cluster.local svc.cluster.local cluster.local bluecrest.local options ndots:5
ERROR: https://rancher-dev/ping is not accessible (Failed to connect to rancher-dev port 443: Connection timed out)
Our rancher URL is rancher-dev  because the FQDN  ends in .local   which Rancher does not allow.
I have tested using the IP address for the rancher server and I get the same error.
I have tested v2.50,1,2,3 and all have the same issue.
The only way I can provision an RKE cluster without this error is to go back to v2.4.11

This issue is for when cattle-cluster-agent does not become ready because the cluster does not have a node with the worker role which means cluster DNS pods can't be scheduled and cattle-cluster-agent fails to start successfully because of the error Could not resolve host. This would also be the case in v2.4 but because there was a cluster check added that waits for cattle-cluster-agent to be ready, it is now preventing the cluster to become ready.
Connection timed out is a different issue. In general, the server-url needs to be an FQDN that is resolvable using DNS. The other change in v2.5 is that k8s 1.19 was added with new CNI plugins which could have caused a regression. The easiest way to test this is to provision a 1.18 cluster in v2.5 and see if that resolves the issue. If not, it is usually firewalld or custom iptables rules conflicting. If you tried with an IP address than DNS is already excluded, and you should take a look at the CNI pod logs to see why it can't be setup correctly.

This issue is for when cattle-cluster-agent does not become ready because the cluster does not have a node with the worker role which means cluster DNS pods can't be scheduled and cattle-cluster-agent fails to start successfully because of the error Could not resolve host. This would also be the case in v2.4 but because there was a cluster check added that waits for cattle-cluster-agent to be ready, it is now preventing the cluster to become ready.
Connection timed out is a different issue. In general, the server-url needs to be an FQDN that is resolvable using DNS. The other change in v2.5 is that k8s 1.19 was added with new CNI plugins which could have caused a regression. The easiest way to test this is to provision a 1.18 cluster in v2.5 and see if that resolves the issue. If not, it is usually firewalld or custom iptables rules conflicting. If you tried with an IP address than DNS is already excluded, and you should take a look at the CNI pod logs to see why it can't be setup correctly.

Thanks Seb, to be clear I am seeing the same cluster not ready response as per the OP. I have tried rolling an older k8 cluster with the same response. The issue persists without any iptable rules (flushed with iptables -F) and on a clean Ubuntu system with a clear base and only Rancher createrd rules.
Perhaps there is more than one cuase for the initial as raised ?

Thanks Seb, to be clear I am seeing the same cluster not ready response as per the OP. I have tried rolling an older k8 cluster with the same response. The issue persists without any iptable rules (flushed with iptables -F) and on a clean Ubuntu system with a clear base and only Rancher createrd rules.
Perhaps there is more than one cuase for the initial as raised ?

Yes this issue is for when a cluster does not contain a node with a worker role, if you do have a worker in your cluster, please use the steps in this and other issues that describe the "cluster agent not ready" error and use that info to track down the issue. If it is Rancher related or you are unable to determine the root cause based on the outputs, please create a new issue with all the info requested and the outputs from the commands in this and other issues to help track down the root cause.

Yes this issue is for when a cluster does not contain a node with a worker role, if you do have a worker in your cluster, please use the steps in this and other issues that describe the "cluster agent not ready" error and use that info to track down the issue. If it is Rancher related or you are unable to determine the root cause based on the outputs, please create a new issue with all the info requested and the outputs from the commands in this and other issues to help track down the root cause.

Seeing this exact same issue as of today.   I have been fighting this for days.  Just found this thread.   I created 3 etcd control plan nodes first and then 4 worker nodes.   seeing this error.   This is how we have always created in past.  I will try creating worker nodes first.

Seeing this exact same issue as of today.   I have been fighting this for days.  Just found this thread.   I created 3 etcd control plan nodes first and then 4 worker nodes.   seeing this error.   This is how we have always created in past.  I will try creating worker nodes first.

If you have a node with the worker role, this is not your issue. Please search the other issues describing the error cluster agent is not ready to find troubleshooting steps.

If you have a node with the worker role, this is not your issue. Please search the other issues describing the error cluster agent is not ready to find troubleshooting steps.