[Feat]: netdata-claim.sh is too cryptic, documentation missing #12186
Comments
ktsaou
added
feature request
|
Possible partial fix here: #12179 95% of the issues around this are because it’s a shell script that was cobbled together in a hurry early on in the life of the cloud and then never got reimplemented in the agent code like it should have been in the first place. |
|
@Ferroin the initial issue is we don't call Perhaps we just need to add netdata/packaging/installer/kickstart.sh Lines 585 to 586 in 32cd848 |
|
The particular case mentioned in the OP is indeed that, but the general information is that this is a problem regardless of why the claiming fails. |
|
I think that is the main problem here. If you need to claim your node the Cloud suggests using
And the issue is - we don't call I may be wrong, but I am under impression that |
|
There are several issues mentioned here:
So, because of all these, as a user of a cc: @cpipilas |
|
We need to decide if we still want to expose Currently, to reconnect a node we suggest the use of If we choose to go with claiming using |
|
OK, so IOW we do want to support random unknown installation types such as users building by hand on their own system or installing through their system package manager? Because I’ve been under the impression given pretty much everything discussed around any type of support that we do not care about such installs at all, which is why the kickstart script explicitly refuses to attempt to claim them. In more detail as far as the specific list though:
As far as the final point, the documentation is correct, for a vast majority of real users, a |
If we can yes. If we can't no.
Wait! "we do not care" ? No, we do care about every single netdata install. I don't mind about automatically managing these installs, as long as there is clear help and documentation on what users should do. So, points 1 and 4 may stay as they are if we believe that we can't do them right, or the amount of work required to do them is tremendous vs the number of users who need it.
ok
No. This is not a problem of claiming. The problem here is that as a user I want to have a valid, supported install, but we don't provide any information on how to achieve that when you have a
No. Same as above. I want a supported install. Claiming an existing install is a fallback. I will still run an unsupported install.
ok, but it may or may not work. It depends on the agent version I have installed. If it is old, the user is still doomed.
So, you are suggesting that for those users that for whatever reason they need a custom install, the only way for them to claim their agents to the cloud is via the kickstart script, that they have already decided not to use for the installation.
This used to be the default way. We have users out there using it. We should say something about it. Pretending this does not exist, does not help. Adding some documentation about it, is not that hard... |
The stance you have effectively projected regarding any third-party install method since I started at the company is that we do not care, because they cannot be up to date enough for us to shove new features down users throats.
Apologies about both of these then, my understanding was that they were specifically about the claiming issue and not general complaints.
Yes, and because we cannot safely update such an install, we cannot resolve this for them.
Our own policies have functionally made it such that third party installs cannot be supported for Cloud usage. See for example the hard cutover to the new architecture that we are only giving about six weeks worth of advance notice about, which will mean that pretty much anybody who is currently installed through a third-party mechanism cannot use the Cloud at all. If we want to support such users, then the first step needs to be acknowledging that we are handling such things completely wrong and change our policies around such breaking changes, and only then can we consider worrying about other aspects of support. And yes, there are also people who built Netdata by hand to consider, but they constitute a tiny percentage of our user base compared to other installation methods at this point, and the smaller the group of users the less tenable it is to provide support for them.
It has not been the officially recommended install method for five years (assuming the original commit of the kickstart script in 2017 was when we decided that that was the preferred install method), and AFAIK we have no evidence of continued usage by actual users other than you (please correct me if I am wrong about this, but be prepared to provide demonstrable proof), and given the fact that we have no indication that any significant percentage of users is actually still using such installs, support for such installs has been categorized as the lowest possible priority. Yes, adding documentation is not hard, but it takes time which could be spent more effectively by working on things that actually benefit a significant percentage of our users. |
|
I am just suggesting that adding some documentation for corner-case of users is respectful for them, and easy for us... |
|
btw, And if the node is old we have this: # /opt/netdata/usr/bin/netdata-claim.sh -token=qmwHshM-34i6RZrblN1YXaaZJVfuIjkKN5iKohBAhR7wBgs4D5Epd3LTKi_4FoS1_tjEVyqJlEWGYFjySntO7nolTAqgpDvUZpAtE6b4GCkoggo073ILTPptVXihuJvLfM2hIu0 -rooms=02179f1f-9030-486a-a873-9b57f6420a53 -url=https://app.netdata.cloud
Token: ****************
Base URL: https://app.netdata.cloud
Id: e6e4dcc4-969f-11ec-82f2-0401d1165f01
Rooms: 02179f1f-9030-486a-a873-9b57f6420a53
Hostname: d1.firehol.org
Proxy:
Netdata user: netdata
Generating private/public key for the first time.
Generating RSA private key, 2048 bit long modulus
.............................+++
..................................................+++
e is 65537 (0x10001)
Extracting public key from private key.
writing RSA key
Failed to connect to https://app.netdata.cloud, return code 60
Connection attempt 1 failed. Retry in 1s.
Failed to connect to https://app.netdata.cloud, return code 60
Connection attempt 2 failed. Retry in 2s.
Failed to connect to https://app.netdata.cloud, return code 60
Connection attempt 3 failed. Retry in 3s.
grep: /opt/netdata/var/lib/netdata/cloud.d/tmpout.txt: No such file or directory
grep: /opt/netdata/var/lib/netdata/cloud.d/tmpout.txt: No such file or directory
Failed to claim node with the following error message:"Unknown HTTP error message"To work, you have to do this: # export PATH="/opt/netdata/bin:${PATH}"
# /opt/netdata/usr/bin/netdata-claim.sh -token=qmwHshM-34i6RZrblN1YXaaZJVfuIjkKN5iKohBAhR7wBgs4D5Epd3LTKi_4FoS1_tjEVyqJlEWGYFjySntO7nolTAqgpDvUZpAtE6b4GCkoggo073ILTPptVXihuJvLfM2hIu0 -rooms=02179f1f-9030-486a-a873-9b57f6420a53 -url=https://app.netdata.cloud
Token: ****************
Base URL: https://app.netdata.cloud
Id: e6e4dcc4-969f-11ec-82f2-0401d1165f01
Rooms: 02179f1f-9030-486a-a873-9b57f6420a53
Hostname: d1.firehol.org
Proxy:
Netdata user: netdata
Connection attempt 1 successful
Node was successfully claimed. |
|
This issue has been mentioned on the Netdata Community Forums. There might be relevant details there: https://community.netdata.cloud/t/issues-installing-netdata-on-servers/2476/5 |
|
I think this issue is no longer needed. Using |
Problem
Now what? No URL on the above error message to find help. No link to discord either.
Let's try to claim it by hand:
netdata-claim.shdoes not have any command line help:The "Add Nodes to War Room" modal on the cloud, does not provide any hints on how to call
netdata-claim.sh.Let's hope
netdata-claim.shsupports the same parameters askickstart.shdoes:# netdata-claim.sh --claim-token HIDDEN --claim-rooms HIDDEN --claim-url https://app.netdata.cloud Unknown argument --claim-tokenNo. It does not.
Hm... probably it should work by eliminating
--claimfrom the above command.# netdata-claim.sh -token HIDDEN -rooms HIDDEN -url https://app.netdata.cloud Unknown argument -tokenNo it does not.
Let's check the documentation. The "Add node to war room" modal, has a link to documentation: https://learn.netdata.cloud/docs/agent/claim#connect-an-agent-running-in-linux
Great! Let's read that!
Hm... where is
netdata-claim.shmentioned?Nowhere!
Wait! There is a example of
netdata-claim.sh, as part of a netdata running under docker.This is the solution. It also needs
=:But
-key=valueis quite unusual for Linux.The usual is
--key=value(2x dashes).Description
netdata-claim.shshould:kickstart.shkickstart.shwhen it fails, should:Importance
blocker
Value proposition
kickstart.shshould claim the existing installationProposed implementation
I suggested above
The text was updated successfully, but these errors were encountered: