Hi, My issues are

First: I may create a subnet, deploy it, stop it, start it again in the same session. But when I restart my machine, the subnet can not start because the backend controller has not started. As I understand, the backend controller starts only with the command "avalanche subnet deploy". But in this case, the subnet is re-deployed and the private key and rpc urls are different now. So, I cannot continue with my current hardhat config and metamask subnet config. I think this is not much useful because, my local environment must be updated on a daily basis. Am I missing something?

Second: normally I'd like to deploy multiple subnets on my local machine in different Linux VMs. But I can not configure the backend controller endpoint port. When I start one subnet, I cannot deploy another one because of the same port confliction. Is there any way to set the backend controller port?

The control key flow should have list and delete functions, same as precompile configuration.

Our current implementation of validator join asks the user to enter their node id manually. We need to either provide them more detailed instructions about how to find that or get it for them automatically. Maybe request the nodes RPC URL instead and query for it.

Make sure we are very explicit saying that keys in our key module should not be used with real funds in production.

The avalanche subnet deploy command should accept a --fuji flag to skip the select network prompt. This is a mutually exclusive flag with --local.

The table generated in key list should have the balances of the addresses.

If the user already has created a key, and a command requires a key name, then the key name could be set as default.

But this makes only sense if there is a single key, otherwise no default should be given and rather have the user be prompted for the key to use.

This ticket is to first decide if this is worthwhile, and if yes, implement it.

I can successfully launch a local subnet on an Ubuntu 18.04 VM instance using the cli subnet command. However, when I try to containerize my local subnet setup for my development pipeline, the avalanche subnet deploy mysubnet command fails inside the container environment:

./bin/avalanche subnet create mysubnet
✔ SubnetEVM
creating subnet mysubnet
Enter your subnet's ChainId. It can be any positive integer.
✔ ChainId: 42069█
Select a symbol for your subnet's native token
✔ Token symbol: tkn█
✔ Low disk use    / Low Throughput    1.5 mil gas/s (C-Chain's setting)
✔ Airdrop 1 million tokens to the default address (do not use in production)
✔ No
Successfully created genesis
root@bd56dc4e98fd:/go/avalanche-cli# ./bin/avalanche subnet deploy mysubnet
✔ Local Network
Deploying [mysubnet] to Local Network
Backend controller started, pid: 4778, output at: /root/.avalanche-cli/runs/deploy2022-06-24T22:58:54Z/avalanche-cli-backend
Installing avalanchego...
Avalanchego installation successful
VM binary does not exist locally, starting download...
.
VM ready. Trying to boot network...                                                                                                                                                         24-Jun-22
Network has been booted. Wait until healthy. Please be patient, this will take some time...
..................................
..........................................................................................................................................................Error: failed to query network health: the health check failed to complete. The server might be down or have crashed, check the logs! rpc error: code = DeadlineExceeded desc = context deadline exceeded
Usage:
  avalanche subnet deploy [subnetName] [flags]

Flags:
  -h, --help    help for deploy
  -l, --local   deploy to a local network

Global Flags:
      --log-level string   log level for the application (default "ERROR")

My dockerfile is very simple to reproduce:

FROM ubuntu:18.04

RUN apt update -y \
  && apt install -y vim \
                    tmux \
                    curl

WORKDIR /root

# install the subnet cli
RUN curl -sSfL https://raw.githubusercontent.com/ava-labs/avalanche-cli/main/scripts/install.sh | sh -s

ENV PATH="${PATH}:/root/bin"

I build and run an interactive session like this:

docker build -t subnets .
docker run -it --rm --entrypoint bash --name subnets subnets
./bin/avalanche subnet create mysubnet
./bin/avalanche subnet deploy mysubnet

We'd like to ensure VMIDs are random, so let's add some entropy and store them in the sidecar so we can retrieve them.

Users will need to be able to recover a deployed Fuji subnet on a new CLI instance. If we do a Fuji deploy and then delete our subnet config, how can we get it back?

In the Fuji deploy process, we should be able to use our generated keys as control keys.

Should be version 18.4

editCongigFile in cmd/subnet/join.go needs some unit tests.

In order to fund a P-Chain address, we should be able to automate the process of exporting from C to P.

Use the wallet and coreth (for the C-Chain part) to do this.

We should add a --hard flag to our clean operation that deletes our ~/.avalanche-cli/bin directory to facilitate upgrades to later avalanchego and subnet-evm versions.

First, merge main into fujiDeploy, then merge everything back into main.

All PRs must be merged first. Currently blocked on the next avalanchego release.

Edit the CLI prompts to include a link to a tutorial showing users how they can determine their NodeID. They will need this for addValidator and join.

Go over all the command text added in the new epic and make sure it is ready to release.

We might want to wait until after our APM integration.

When the CLI creates a subnet config, we should be able to specify what happens to gas fees. This may have rollover effects into the deploy process.

Request:

if I’m running an instance of the Subnet EVM via avalanche-cli and I want to give the fees to validators via allowFeeRecipients —where is the validator(s) EVM chain config located so that I can set the corresponding feeRecipient ?
I would expect the Subnet EVM’s config to be in $HOME/.avalanchego/configs/chains/SUBNETID/config.json but my local machine doesn’t have a $HOME/.avalanchego/chains/ directory. How can I figure out the --chain-config-dir when running avalanche-cli so that I can set feeRecipient in the config? Thanks!

minor nit: you should be expecting the Subnet EVM's config to be in $HOME/.avalanchego/configs/chains/CHAINID/config.json

we have to edit two places. First we add allowFeeRecipients to ~/.avalanche-cli/chainName_genesis.json . Second we add feeRecipient to the EVM chain config for each validator.

In network start and network stop, we accept the snapshotName as an argument. We don't use this pattern anywhere else in the codebase. We should convert this to a flag.

The key list test seems flaky. Maybe print ordering isn't consistent?

https://github.com/ava-labs/avalanche-cli/runs/7542652944?check_suite_focus=true

Goal

• Support multiple, configurable Avalanchego versions
• Support the latest avalanchego version without requiring a CLI update

Command Changes

Deploy Subnet

avalanche subnet deploy <subnetName>

Edits

• In the deploy flow, ask Github for the latest avago version, download it if not already available. If github is unavailable, use the latest installed version.
• Add a flag --avalanchego-version to manually override the avago version.

Technical Details

• We should query github to see what the latest release is (if github isn’t available, we can fall back to the latest installed version)
• We should remove our hardcoded avago version constants

Implementation Details

All installed binaries will live in the ~/.avalanche-cli/bin/avalanchego directory. There will further subdirectories for each installed version.

When we do a validator join, we should copy the VM to the plugin dir or print instructions to do so.

When setting the number of control keys in deploy, we should add range parameters in the prompt.

We should be able to run these commands in manual and automatic mode without any prompts. We need to add the flags to do so. We definitely need a --fuji and --mainnet. Then if the user provides either print or (--plugin-dir AND avalanchego-config) we skip the confirmations.

We should edit fuji deploy, addValidator, and join to use the same pattern as subnet create. You should be able to hit enter every time and end up with something that works with sensible defaults wherever possible.

We need to bump the version of our subnet-evm support to v0.2.5 (or later). This will enable us to add support for fee config precompiles. We need to add the new menu option in the create process.

H/T to @felipemadero for finding the issue.

When we list keys, we should hide the custom VM p-chain address unless a --all-networks flag is passed.

Write up a work plan for implementing package management and custom VMs.

Our new flow is:

• avalanche network clean resets the environment
• You cannot deploy a subnet multiple times (locally) without resetting the environment
• You can deploy multiple different subnets simultaneously and run them in parallel

We need to update our readme, our docs website, and our long command descriptions to reflect this.

We should provide a default suggestion for stake weight when whitelisting a validator.

Some of the join prompts are missing text. I think prompts can't handle newline characters.

I'm following this tutorial: https://docs.avax.network/subnets/create-a-fuji-subnet/#private-key

It directs me to run avalanche-cli create key, but avalanche-cli complains:

$ avalanche-cli create key
Error: unknown command "create" for "avalanche"
Run 'avalanche --help' for usage.

What am I missing?
Thanks for your time

Make sure that key names contain no spaces.

We need a doc explaining how each command interacts with the snapshot. The process is pretty confusing and we should document it.

We should probably create a local network version of our Fuji deploy path and use it to test our fuji/mainnet deploy functionality.

We should return an error if you attempt a fuji deploy and no keys are available.