- Setting up Eden for the first time
$ git clone ... ; cd eden ; make bin
$ PATH=`pwd`:$PATH - Create a few permanent configs corresponding to my different developer workflows
$ eden config add eve-on-qemu
$ eden config edit eve-on-qemu
$ eden config add eve-on-gcp
$ eden config edit eve-on-gcp - Steady state of my developer workflow
$ cd .../local-workspace-1
$ git clone/pull
$ edit some stuff in EVE
$ make HV=adam-kvm live
$ eden config set eve-on-qemu
$ eden stop # making sure that nothing in this context is "up and running"
$ eden setup # making sure that whatever I need in this context gets built/pulled
$ eden start # at this point I'd expect my local build of EVE and whatever else is configured in eve-on-qemu to get started
$ eden status # expect it to show me that everything is running and also that EVE is in the "onboarding" state
$ eden eve onboard # this will register a given EVE's onboarding UUID Adam and effectively allow EVE to register with it
$ eden status # expect it to show me that everything is running and also that EVE is now in the "registered" state
$ eden controller -m adam:// edge-node get-config
$ eden controller -m adam:// edge-node eveimage-update dist/amd64/installer/rootfs.img
Notes on the above workflow:
- I'm not particularly happy about picking eden eve onboard as the command to run in order to force onboarding of EVE into Adam controller. This may move to some other subcommand but hanging it off of eden eve for now seems like the least of all evils. I'm all ears for better/more orthogonal ideas.
- When I run eden start my expectation is that some fixed, pre-determined version of EVE that I specified in my eve-on-qemu config will get started: I don't really care about it that much, since I'm going to immediately upgrade it into the version that I've built locally, but Eden config doesn't need to know anything about it since I'll be using eden controller -m adam:// edge-node eveimage-update command.