shipchain / hydra Goto Github PK

hydra client update works by replacing the running process with pip install git+... to upgrade itself, always installing into the users home folder.

However, since replacing the running process eliminates the side effects of prefixing hydra client update with sudo, if the package is installed under sudo, there's no way for it to update itself.

Anyone with hydra installed under sudo currently (who followed our getting started guide prior to v0.0.3b3) will therefore be unable to use the upgrade helper and must either:

1. always use sudo pip3 install git+https://github.com/shipchain/hydra.git@master, which is longer and inconvenient but pretty much fine, but it needs to be documented somewhere...
   or
2. run this one time right now to remove all the installed versions and just reinstall under your ~/.local directory, which will fix this problem for you forever:
   pip3 uninstall -y hydra ; sudo pip3 uninstall -y hydra ; pip3 install git+https://github.com/shipchain/hydra.git@master
   (and then log out and log in, and hydra -v should show at least version 0.0.3b3 on the first line)

Hydra could try to engineer around this by changing off of the os.execpv method, but (1) and (2) above would still be relevant (because if we introduced the fix in v0.0.3b4, you'd still have to manually sudo your upgrade to download it) and frankly I'm not sure how else we can safely make this package update itself while it's still running. I think since we've updated the Getting Started Guide to no longer default to sudo installs, this issue can dangle, we ask users to run (2) above.

Loom.yaml file should be included in the S3 bucket to be pulled by the nodes during join.

A node is unlikely to properly peer with all the available hosts unless it specifies it's own external_addr in config.toml -- We've added support in hydra for setting this, but incase anyone is running old software, here is the proper fix:

sed -i -e "/external_address =/ s/= .*/= \"tcp:\/\/$(curl -4 https:\/\/ifconfig.co\/):46656\"/" chaindata/config/config.toml

Right now, we don't help backup node keys and expect our users to manage it themselves.

This is especially problematic when using leave-network, which blasts the sidechain directory.

I propose one of the following:

• Bare minimum, leave-network should drop keys into ~/.hydra/backups/{name}, possibly also including other relevant backup stuff (like config.toml or loom.yml)

• Alternatively/additionally, maybe it would be appropriate to consider adding something like hydra client save-identities --profile=my_node to backup the keys, and then a corresponding restore-identities option

Leaving as a reminder, plan to implement this weekend

Cement is currently being imported in setup.py, which means we have to pip install cement before we can pip install hydra. We should remove this dependency so that pip can automatically resolve all of hydra's dependencies via install_requires.

External calls from Hydra do not have any validation that the commands ran successfully. Hydra needs to capture the result from executing commands and check the exit codes and/or process output.

Options for handling this might include a new fail_on_error parameter which checks the exit code, or a successful_message that needs to be found in the process output.

Expected to be handled in raw_exec

EC2 instances should be tagged with NAME=<network>-<node_number> to help keep the EC2 Instance dashboard more organized.

As part of our ShipChain sidechain test network evaluation, we are trying to gather feedback from node operators. We will be providing a Gitcoin bounty for any parties who will assist in testing the hydra project, and set up a non-validating node synchronized to our shipchain-testnet-alpha network.

Please complete the survey below:

1. What are the hardware specifications (CPU/RAM/Disk space/SSD or HDD/Network link speed) of your server?
2. Where is your server located, geographically?
3. What operating system and version are you using?
4. What version of Python are you using?
5. Did you encounter any issues when installing the hydra package?
6. Did you encounter any issues with the hydra client join-network command?
7. Did you encounter any issues with the hydra client configure command?
8. Approximately how long did it take for your node to sync with the network?
   (Your node is sync'd when curl localhost:46657/status returns catching_up: false)
9. Are you interested in running a validator on the network?
10. Do you have any other feedback for us?

Not always, but sometimes, when doing either hydra client update or pip install git+.../hydra.git, at the end of the install process on Ubuntu 18.04, there's a segmentation fault.

It seems to be a non-issue, except for the scary warning message, because the package installs correctly and pip has completely cleaned up.

My best guess is that this is problem upstream in maybe the Cement library, because our pip install process is fairly vanilla from their template, but I can't find any other references to the issue on their bug tracker.

The node should come back up on server reboot.

I believe all that is needed to support this is a call to systemctl enable during the hydra configure step.

CLI Help output needs more content to better assist users in selecting the correct options.

Controllers should be specifying title, description, and help content in the Meta class. Each exposed sub-command should be specifying help and potentially alias components in the @ex decorator.

I can't figure out why, either, because UFW and IPtables are disabled by default, and only security groups are configured -- they don't allow ICMP either, and they should be modified to do so, but if i go into AWS add the rules by hand, I still can't ping the nodes by public IP.