ava-labs / apm Goto Github PK

Currently we have weird headers in plugin definitions, for example:

vm:
   { actual vm here }

These are unnecessary and were only originally added in when I was confused on how to use the yaml library. We should gut these before avalanche-cli's integration w/ apm is released.

Add download script so customers can use the pre-compiled binaries instead of having to build from source.

Add support for commands to:

1. Search for a vm/subnet by keyword apm search "key-value"
2. Lookup info of a vm/subnet by its alias apm info foobarvm

Some networks might have multiple corresponding subnetIds. For example, I might have a network foo that I want to be able to install + join. It might have subnetID 1234 for testnet, but 5678 for mainnet, but both use the same foovm. We might want subnet definitions to look something like this:

alias: foo
networks: 
 testnet:
  subnetID: 1234
 mainnet:
  subnetID: 5678
vms:
 - foovm
...

... and users could join a subnet like so:

apm join-subnet --subnet-alias=foo --network=mainnet

This will only be needed once dynamic-whitelisting is enabled, at which point we can start using those APIs to correctly whitelist the right subnet id.

There are several functions in the CLI's apmintegration package that belong in the APM itself. Mostly on reading the installed repos and listing what's available. This ticket should move that functionality into the APM. I separate ticket can change how the CLI integrates the APM.

APM should be able to support a subnet changing VMs during an upgrade

• It should support listing multiple VMs with the same name but with different versions
• It should also track historical VM versions (i.e. don't delete vm configs on update)

The apm object should accept a logger instance so it can tie insto the CLI's logger rather than printing directly to stdout. We want to suprress some of the tool's prints when used through the CLI.

If you deploy the same subnet on Fuji and Mainnet, we need to decide if we want to track those in the same file or different ones. If we use the same file, we will need to do #27.

The APM should probably support uploading signed binaries and validating them on the import side.

The APM should add the ability to check if an upgrade is available. That function should be callable from the CLI.

We should add a field to support network-level subnetConfigs. The most simple way would probably be to add a map type like so:

subnet-config:
   mainnet: <config>
   testnet: <config>
   ...

Currently the function writes lot of prints to stdout, and the lib users, like CLI, would benefict for giving it a logging instance

We may want to allow users to optionally provide release notes and have them distributed with the APM.

APM should support a subnet adding new upgrade bytes (it can do this multiple times)

• The upgrade bytes should be tracked and downloaded when the subnet is imported

LevelDB isn't a great storage abstraction for this. Would be better to just serialize state in a json/yaml file

We'll need to:

1. Replace database with a statefile
2. Replace the definition registry with file-system lookups

It'd be cool to have some kind of TUI interface for people who aren't as CLI savvy. The bubbletea framework looks promising.

After our discussion with the security team, we'd like to try signing and verifying packages using subnet admin keys. These will use p-chain addresses for signatures and can come from soft keys or from ledgers.

We need to check that each subnet release is signed appropriately. We should also verify that the subnet id does not change across updates.

If this does not work, we can switch to GPG signing with Yubikeys.