lf-edge / eden Goto Github PK

after running the following sequence of eden commands I can't seem to be able to start eve:

Romans-MBP:eden roman$ eden eve stop
ERRO[0000] cannot stop EVE: cannot kill process with pid: 57489
Romans-MBP:eden roman$ eden eve stop
ERRO[0000] cannot stop EVE: cannot open pid file /Users/roman/src/lfe/eden/dist/eve.pid: open /Users/roman/src/lfe/eden/dist/eve.pid: no such file or directory
Romans-MBP:eden roman$ eden eve start
EVE is running

on further investigation this appears to be an issue with qemu launch but no diagnostic information is given and it is unclear how to proceed:

$ eden -v debug eve start
ERRO[0000] cannot start eve: exit status 1

it appears that ssh is disabled by default in a running instance of EVE -- we need to enable it via sending an appropriate part of the config via adam (e.g. https://github.com/lf-edge/eve/blob/master/docs/FAQ.md#1-how-to-ssh-into-a-running-instance-of-eve)

Both of these commands currently require me to pass two arguments a query and a location of the directory in the filesystem. The directory part should:

• have a default (that gets figured out from a running Adam instance)
• be tweakable by the -dir flag

The query part should also have a default

IOW, I should be able to run: eden log or eden info and get the expected result.

I need to be able to use eden to issue adam commands as per: https://github.com/lf-edge/adam

Here's what I need to be able to do:

eden adam onboard -> adam admin onboard
eden adam device -> adam admin device

NOTE1: that these need to be proxied in such a way that they work out of the box (IOW, I don't have to manually specify --server, etc. etc.)

NOTE2: onboad command needs to have reasonable defaults so I don't have to specify --path ../certs/onboard.cert.pem --serial 31415926)

If there's an agreement on #72 then eden config delete my-awesome-config and eden config set my-awesome-config also needs to work as expected.

This will effectively make name of the config an mandatory argument

After some playing with Eden it has become clear to me that we need an eden controller subcommand that should be modeleted after zcli CLI API but capable of operating on the following controllers:

• plain text files containing JSON EVE config
• binary files containing protobuf serialization of the EVE config
• Adam controller
• Zedcloud

The way I envision this command is the following:

   eden controller -m [file|proto|adam|zedcloud]://<URL> [subset of zcli commands]

The semantics here is going to be that for plain text files, binary files and Adam controller the above command will simply take the source file from the -m option, parse it, apply the changes requested by zcli commands and store the result back (obviously in Adam's case that config needs to be retrieved via Adam's admin endpoint first and then submitted to that same endpoint -- but otherwise Adam use case is exactly like operating on a local JSON config).

To get us going, I suggest we only focus on plain text files with JSON config and Adam for now (but obviously the implementaion need to be designed in such a way that we can plug the other two easily later on).

And here's the first zcli command we need to implement edge-node. Hence the request here is for:

 edge-node reboot [-f] <name>
 edge-node update <name> [--title=<title>] [--lisp-mode=experimental|default] [--project=<project>] [--clear-onboarding-certs] [--config=<key:value>...] [--network=<network>...]
 edge-node eveimage-update <name> --image=<image> [--activate]
 edge-node eveimage-remove <name> --image=<image>

There's no reason to have separate infowatch and logwatch commands. Those should be made into -f flag of info and log respectively.

Now eden status reflects only whether something is running or not.

Suggested:
If something is running display (except name & status):

1. IP/Port (how to connect) 2) log file location
   If something is not running display (except name & status):
2. Likely cause (if possible) 2) log file location 3) last error from log (something like tail -f)

Instead of log file to pipe the output of serial console from qemu, I suggest we implement a full fledged socket and eden eve attach to attach to the running EVE console

Currently, fixIPs.sh script edits EVE's Makefile on the fly. This is not particularly flexible and I have introduced the following variables in EVE Makefile to make it go away:

• QEMU_OPTS_NET1
• QEMU_OPTS_NET1_FIRST_IP
• QEMU_OPTS_NET2
• QEMU_OPTS_NET2_FIRST_IP

Please migrate to them

Currently an EVE instance under Eden's management can be in one of the following states:

• unknown
• onboarding
• managed

These would correspond to the status of the adam admin device/onboard commands and need to be displayed by eden status

We need to make sure the difference between these two is clearly articulated

Currently it seems that when there are no changes to be applied (e.g. when simply running eden controller -m file://foo.json edge-node update with no sub-options) the command still sends a new config. I feel this should be a no-op instead.

We need to properly deal with how EVE passes metadata to the VM, upstream it into linuxkit and remove the local workarounds.

Arguably, EVE is doing the right thing here following cloud-config/cloudinit standard so perhaps on the linuxkit side we can frame it more along the lines of following cloudinit

At this point Eden has grown quite a bit into, effectively, a system that manages various runtime and static objects to make different scenarios of working with EVE possible. These objects are:

1. Static objects:

   • Eden's own configs/contexts (current config subcommand)
   • EVE's controllers (current controller subcommand)
   • x509 certificates (current certs subcommand)
   • Edge Containers (current ociimage subcommand)
   • EVE live images (current eve-update subcommand)
   • Test suites/Test scripts (current test subcommand)

2. Dynamic objects:

   • Adam instances (current adam subcommand)
   • Redis instances (current redis subcommand)
   • Eserver instances (current eserver subcommand)
   • EVE instances (current eve subcommand)

On top of that we have what I would describe as top-level actions (those act on a collection of objects described in a current context):

• setup (makes sure that all of the local objects defined in my current context are up-to-date)
• clean (it actually isn't clear to me anymore what it does -- but logically it should probably an opposite of setup in a sense that it would clean any transient resources -- like disk space or docker cache that setup may have created)
• start (makes sure that all the dynamic objects get started)
• status (gives me a view of the objects currently known to Eden)
• stop (makes sure that all the dynamic objects get stopped)

Here's what I'd like to propose for the immediate (7-10 days future):

1. Research whether it would be possible to clearly format 3 different sections when eden prints its help (currently we're simply relying on Cobra to list commands in the alphabetical order).
2. kill server subcommand and move whatever functionality maybe left there under eserver
3. kill reconf subcommand and move whatever functionality maybe left to either `
4. rename ociimage to either eci or eci-image
5. rename eve-update to either baseos or eve-image and expand its scope (eventually to be able to manipulate various forms of EVE's baseos
6. move info and log top level subcommands under controller and model them after zcli by having a single eden controller events command and being able to filter the kind of event you're interested in by the --filter-type flag
7. Figure out what to do about clean top level subcommand, if you agree with my definition above

Note that #3 and #4 should probably go together (e.g. if it is eci-image it should probably be eve-image).

Currently, Eden tries to leverage EVE's makefile target run to run a live image of EVE. Instead we should invest into Eden's own qemu management.

When doing so, I highly suggest we use configuration files instead of command line options and feed it to qemu via -readconfig option.

Right now Makefile logic does two parallel clones of EVE into dist/evebaseos and dist/eve.

I understand why are you doing it -- since you want to use these two repositories for two different purposes -- one is running live image of EVE under test and the other one for building a baseos image when you need it for baseos-level testing.

In order to save time and bandwidth, lets:

1. just clone repository once into dist/eve
2. run make build-tools
3. create dist/evebaseos and dist/evelive as local git clones git clone eve evelive
4. copy (or symlink) dist/eve/build-tools/bin into both of the repositories above (to save time building linuxkit and manifest-tool)

Currently, running eden status prints a pretty brief summary covering only "running entities" (Adam, EServer and EVE itself):

Adam status: adam container not exists
EServer status: no pid file
EVE status: no pid file

We need to extend its functionality to cover all the artifacts that can be mentioned in the config and their state.

Currently, there's a lot of attempts of configuring individual tests via ad-hoc mechanisms like looking up environment variables, etc. A good example is baseOS upgrade test where what baseOS to upgrade to and from can largely be any combination and anything that we would put into the test statically would be a random choice.

We need to come up with a generic framework to feed tests that type of configuration information. Off the top of my head, I could imagine a folder called conf that would be full of json files named according to the testname itself. On a startup each test looks up for the json there and slurps its content to use it as a configuration information. On top of that we can introduce similar schema for the ENV variables to be able to tweak those setting in-place without editing the json file (but that can come in later).

Now, I've just come up with this scheme right now -- so I don't know if there's anything that already exists in the open source that would help us do this.

@deitch your feedback here would be invaluable

There's a few operations in eden that can be potentially long running like downloading from Docker HUB, etc. It would be great to provide some kind of a progress bar for those or at least indicate that the operation is still 'in progress'. Right now I' have:

eden eve download ...

sitting there 7 min in -- and I have no idea whether I should wait some more, interrupt it, etc. All I see is:

DEBU[0006] DownloadEveFormDocker run: /Users/roman/src/lfe/eden/dist/bin/eden-darwin-amd64 eve download --eve-tag=5.1.11 --eve-arch=amd64 -d /Users/roman/src/lfe/eden/dist/eve/dist/amd64 --baseos=false

It seems that controller edge-node update --config= does a check for what keys are accepted. This is not bad in and of itself, but we need to agree on how to synchronize on that between EVE and Eden.

I suggest two things: short term you simply bulk-whitelist all the options mentioned here: https://github.com/lf-edge/eve/blob/master/docs/CONFIG-PROPERTIES.md

Long term I'd like you guys to come up with some kind of an API-driven way of having that list of properties synchronized (e.g we should be able to declare them somehow in EVE's API and then Eden would simply get a list of those from one of the go API structs).

Currently Eden tries to follow logs and info messages that Adam collects through the filesystem. We need to migrate to something other than that and make sure that we can query Adam itself for that information. I'm sure @deitch will have an opinion here, but I'm thinking something like an embedded https://github.com/unit-io/tracedb into Adam.

What do you think @giggsoff @sadov -- can you guys articulate your requirements on this issue?

Right now cleaning is non-intuitive and there is no "clean everything"
eden clean cleans itself and leaves the config

Suggested:
make clean - cleans all  (asks yes /no for config files) 
eden clean - cleans all except eden binary
eden config clean - cleans all configs (asks yes /no) 

Here's what I'm getting running eden run on Mac OS:

make run EVE_REF=master ADAM_REF=master EVE_BASE_REF=master
CGO_ENABLED=0 GOOS=darwin GOARCH=amd64 go build -o /Users/roman/src/lfe/eden/dist/bin/eden-darwin-amd64 .
# github.com/lf-edge/eden/pkg/utils
pkg/utils/commandWrapper.go:59:3: unknown field 'Pdeathsig' in struct literal of type syscall.SysProcAttr
make: *** [/Users/roman/src/lfe/eden/dist/bin/eden-darwin-amd64] Error 2

It seems that Pdeathsig is missing on Mac OS. Can you please take a look?

Just to make it easier to get going with configs I suggest we introduce eden config edit which effectively executes whatever my $EDITOR env variable is point at (and complains if that is an empty variable) on the file that corresponds to the current config.

While looking at a few Eden tests it became clear to me that a we need to implement asynchronous asserts and in general encourage the test writers to write their tests with EVE's eventual consistency in mind.

Let me explain. Fundamentally, testing EVE is about the following 3 things:

1. crafting a certain config based on the desired state that the test wants to validate
2. monitoring EVE's state transition for valid (and invalid transitions)
3. monitoring other state (outside of EVE) for desired properties

We are now starting to look good when it comes to automation of №1, and with log and info messages from Adam now moving to a continuous streaming architecture it is time we tackle №2.

The way I suggest we do it is -- we rely on two worker threads that always start when we initialize any controller/cloud object. Those worker threads are in business of continuously receiving log and info messages from the controller. What I'm suggesting is that we should make it possible to register listeners on these worker threads and make it convenient for test writers to create asserts that are attached to those listeners. Think of the asserts as validating (or invalidating!) the stream of info messages (and later logs).

E.g. instead of blocking like we currently do https://github.com/lf-edge/eden/blob/master/tests/integration/baseImage_test.go#L63 we will write a code similar to:

    deviceCtx.InfoAssertOnce("wait for version", filter.ZInfoDevSW, func(i InfoType) bool {i.version == desiredVersion})

This type of assert InfoAssertOnce is expected to fire once and when it does it is expected to go way (obviously it does have a chance to either pass or fail). At the end of the test run all these kinds of asserts that haven't passed are considered failed.

In addition we can also have a continuous type of assert -- the kind that simply listens and validates the events as they flow -- those types of asserts will persist until the end of the test run and then will have a chance to run one last time signaling the end of a testrun.

Obviously, we should also implement assert management that would allow us to block (if needed) on certain sets of asserts firing, etc.

I'd love to hear @deitch if he's seen any test frameworks like that -- if not -- it shouldn't be to difficult to implement from scratch.

Implementation-wise, I'm not sure whether all these asserts need their own goroutines and be fed events via channels or something else may be simpler/faster.

Running eden controller edge-node update --help doesn't really tell me which sub-options are supported (my current understanding is that at least --config=<key:value> sub-option is supposed to be supported -- but nothing tells me that.

Currently, we fetch EVE source repo and build artifacts out of it.

However, unless we're actively patching EVE source code (which we shouldn't anyway), all the same artifacts are available in Docker hub under https://hub.docker.com/r/lfedge/eve

All the containers there are basically glorified tarballs full of rootfs.img and live.img -- all you need to do is to pull it, unpack it and use instead of building a local one.

We need to provide an option of doing that in Eden

Hey @sadov @giggsoff to make sure tests run faster -- lets add the above to the initial config

It seems that the default configuration given to qemu lists the synthetic /config partition as the first drive. This prevents UEFI BIOS to boot EVE from the 2nd drive

NB: This probably should go in lf-edge/eve, but let's leave it here in the "testing world" for now.

As discussed in #22, developers working on a cycle will want to have as rapid iteration as possible. Specifically:

1. Build a pkg locally and run it on their dev env, without needing an EVE device at all, to iterate super-rapidly. When this is done...
2. Deploy it to a live EVE device, and re-deploy and re-deploy. When this is done...
3. Build rootfs and deploy, and re-deploy and re-deploy. When this is done...
4. It is ready!

We are working on the stage 1 above. Stage 3 is how we do it today. We need a stage 2: have the ability to deploy a pkg without upgrading EVE.

To be clear, this must be for testing only, and we need ways to ensure that this cannot go past it. It is an inviolable EVE design that the baseOS is immutable. But the middle stage is important to making development cycles quick and light.

I've been playing with eden controller edge-node eveimage-update and it is clear to me that this is a pretty tricky one. The biggest problem is how to generate datastores and drives.image.name portions so that they make most sense. Here's a couple observations I have:

1. first of all, I think we need to make --image sub-option accept an actual URL. That would take care of a use case where I have an EVE image some place publicly available. You will still have to download it locally, calculate a SHA, etc. etc. but at least we will know that you can simply stick the first part of the URL into the datastore and the file portion of the URL into the drives.image.name.

2. when the file given truly is a file in a local filesystem I starting to think that maybe the best option is to actually rely on somebody else establishing a local tunnel between EVE and a local host (where the file resides). In that sense EVE will get a datastore portion that is basically "fqdn": "http://localhost:8888" and a drives.image.name portion that is a full pathname on the locahost.

The reason I'm leaning towards what I'm describing in #2 is that we probably can't rely on anything but ssh port forwarding when dealing with files on a local filesystem. While it is true that EVE running inside qemu can hit 192.168.1.2 even that is not guaranteed.

Another option would be to come up with some unique domain name (like eden.local) and then agree that any local file will always be considered to reside on eden.local host (IOW "fqdn": "http://eden.local:XXXX" setting in a data store) and it will be a responsibility of however is managing the DHCP/DNS on the outside of EVE to make sure that the name resolves to an appropriate IP address.

Like I said -- #2 here is a tricky one -- need your collective brain power to solve it.

I'm trying to use our new eden config functionality and I'm discovering that add subcommand is still a bit cryptic/surprising. Here's why -- when I run eden config add --help it prints a subset of config knobs (that I presume I can tweak on the command line for a newly created config). However, this is surprising on two levels:

• it doesn't tell me what are the mandatory options -- so for example running eden config add my-new-config doesn't actually do anything useful AND it doesn't tell me that a mandatory option is --name
• the list of the knobs it displays seems to be a weird subset of all the options that I can put into a config and as such it isn't clear how this subset was selected

To fix this, I would much rather prefer that non-optional parts of the command, are, well non-optional. So that what I need to run is eden config add my-new-config and that would generate a config for me.

On the 2nd point -- I'd like a bit of an explanation of what's the logic behind selecting those particular knobs.

It's better to have all properties and magic numbers that are used/reused in the modules to be in the single file

Hey @sadov @giggsoff @deitch @kalyan-nidumolu @eriknordmark I've started playing with Eden quite a bit this week and here's what emerged as my ideal developer workflow. Note that portions of it don't quite work with Eden yet, but if we all agree this is where we need to go -- we can then file individual issues to make it so.

For now, lets just use this issue to make sure we're all on the same page as to what that workflow should be.

The rest here is predicated on the following observations:

1. EVE developers are focusing on hacking functionality that gets packaged via pkg/XXX
2. ideally in my edit/compile/debug cycle I'd be able to simply update that one package in a running image of EVE someplace and continue with my testing -- I'm slowly working on making it a reality, but for now lets assume that EVE developers will always have to update a full image if they want to test their latest code in one of the packages
3. regardless of how quickly we solve #2 in EVE, an average EVE developer doesn't really want to think about anything but rootfs they've just built -- all that business about installers, live images, etc -- that's deployment time. Most of my workflow is:
   3.1. edit packages
   3.2. compile rootfs
   3.3. debug it in a live version of EVE

If we all agree with the above, then it follows that the ideal workflow is having a semi-permanent running instance of EVE that we will keep "upgrading" (until it breaks or gets wedged -- and then we restart it to state 0 and keep "upgrading" again).

Interestingly enough, this is exactly the kind of a workflow most of us who have access to commercial ZEDEDA's controller have been using for quite some time now. What is different now is that:
1. we are trying to make the same workflow available to all the EVE developers
2. we want to have a much, much finer grained control over the structure and the content of the config that EVE receives (speaking of which -- I would really love to see something like http://jsoneditoronline.org/ integrated directly into Adam, but it is fine for now)

So putting it all together, here's what my favorite workflow.

Before I begin my edit/compile debug cycle:

• have a default .eden.yml checked into the EVE workspace - that would be a configuration file describing default way of deploying EVE and adam. You can either edit it or may be we can have an option of having ~/.eden/config.yml that would always serve as an override. This file, but will allow me to tweak all the same value that today are in that make's Config.mk
• have a ~/.eden/state.yml that keeps track of pairs of EVE and Adam running on this machine (I think it will be fair to assume for now that most of the time it'll be a single pair)
• run eden run which spawns a default version of EVE+Adam (lets say we always pick latest releases -- it doesn't matter even for EVE since it'll be updated almost immediately)

Now I have a pair of EVE+Adam running on my machine, I have all there whereabouts recorded in ~/.eden.state.yml and I do my daily routine. Which will consist of:

1. running eden eve-update <rootfs.img> command which will force a config that will update EVE to rootfs.img
2. editing eve-config.json and running eden reconf eve-config.json so that Adam picks up a new config
3. running eden test XXXXX where XXXX is a test specification similar to go test -run XXX

Once I'm dong I anticipate to run eden shutdown (and yes I was tempted to suggest eden expel ;-)) so that the whole thing shuts down.

Does it make sense to the rest of you guys?

I wanna have something like -

eden config add raspberry_conf
eden config set raspberry_conf --key eve.devmodel--value raspberry
eden config set raspberry_conf --key eve.ssid--value NPC_network
eden config set raspberry_conf
eden setup 

and get an image that I need to transfer to SDcard

Then I power raspberry on, it connects to wifi (is able to connect to WPA wifi) , I run eden start and use eden pod deploy commands to deploy something on raspberry

When I run eden info it tells me to Error: requires at least 2 arg(s), only received 0 and then prints:

Usage:
  eden info [flags]

Flags:
  -h, --help   help for info

Global Flags:
  -v, --verbosity string   Log level (debug, info, warn, error, fatal, panic (default "warning")

It is not clear from this what 2 args it expects me to pass to it

At least on MacOS I get into a situation where the entry for Adam in /etc/hosts is 192.168.0.153. I don't understand how this could resolve. The correct IP is 192.168.0.2 (and once I manually change it -- EVE seems to be able to talk to Adam just right)

Looking at #71
x509 certificates (current certs subcommand)
Edge Containers (current ociimage subcommand)
EVE live images (current eve-update subcommand)

server command
eserver comand
redis command

Also remove everything redundant and rename according to #71

I don't think the following is needed anymore:

[drive]
  file = "fat:rw:/Users/roman/src/lfe/eden/dist/adam/run/config"
  format = "raw"

Now the setup checks against existing artifacts and doesn't update components if they exist. I suggest to do cleaning of all local components before setup to ensure the correct versions are loaded.

When I run eden certs it seems to hang. Running eden certs --help doesn't actually say what arguments are expected of me. This may be related to the fact that PreRunE in cert implementation tries to load the config file and is suffering from an issue described in #30

Check the code for unimportant logs like "will use remote Adam" and make them valuable and/or move to debug. Also please rename logs to make them more comprehensive

Looking at the current structure of the Eden config file it becomes clear that we need to do a bit of refactoring to make it understandable by "mere mortals" in the EVE development community. I suggest we do at least the following:

Focus on Eden workflows that assume that Eden doesn't ever "rebuild" anything by itself. If Eden needs some kind of an artifact it needs to be already present as a file or a docker container on the developer's desktop (that is not to say that we will be killing this functionality in Eden -- just that we're not going to focus on it for now). If we assume that -- we can them restructure the sequence of various settings in the config file so that the ones that have to do with building (or any other complicated workflow get to be listed AFTER the ones that developers may actually be interested in tweaking.

With this in mind, here's what I propose Eden default config should look like. NOTE that lines with XXX comments are my questions about something -- please answer those. Lines with MOVED-FROM show what options I propose we move from some other part of Eden config:

#config is generated by eden
adam:
    #tag on adam container to pull
    tag: 0.0.44

    #port of adam
    port: 3333

    #domain of adam
    domain: mydomain.adam

    #ip of adam for EVE access
    eve-ip: 192.168.0.2

    #ip of adam for EDEN access
    ip: 10.0.0.247

    #URL of RedisDB for Adam to talk to (MOVED-FROM adam.redis.adam)
    redis-url: redis://10.0.0.247:6379

    #certificate for communication with adam
    ca: adam/run/config/root-certificate.pem

# From this point on, all the rest of the settings are "internal" for Adam -- tweak at your own risk

    #location of adam XXX - do we need this if we are NOT building Adam?
    dist: adam

     #force adam rebuild XXX note that the new setting is false -- will this break anything?
     force: false

    #use remote adam
    remote:
        enabled: true

        #load logs and info from redis instead of http stream
        redis: true

    #use v1 api
    v1: true

eve:
    #live image of EVE: this is a baseOS version for the initial image
    #XXX: note that this is the only thing that Eden needs to know about how to launch
    #EVE instance -- we don't even need to know the version of it
    image-file: eve/dist/amd64/live.qcow2

    #devmodel
    devmodel: Qemu

    #file to save qemu config
    qemu-config: /Users/roman/.eden/qemu.conf

    #EVE arch (amd64/arm64)
    arch: amd64

    #EVE acceleration (set to false if you have problems with qemu)
    accel: true

    #uuid of EVE to use in cert
    uuid: 2b72e180-7e85-4cd9-b4b5-13af35de1be7

    #serial number in SMBIOS
    serial: 31415926

    #onboarding certificate of EVE to put into adam
    cert: certs/onboard.cert.pem

    #EVE firmware
    firmware: eve/dist/amd64/OVMF.fd

    #forward of ports in qemu [(HOST:EVE)]
    hostfwd:
        2222: 22
        5912: 5901
        5911: 5900
        8027: 8027
        8028: 8028

# From this point on, all the rest of the settings are "internal" for Eve -- tweak at your own risk

    #location of eve directory
    dist: eve

    #location of EVE base os directory
    base-dist: evebaseos

    #dtb directory of EVE
    dtb-part:

    #EVE pid file
    pid: eve.pid

    #EVE log file
    log: eve.log

    #eve repo used in clone mode (eden.download = false)
    repo: https://github.com/lf-edge/eve.git

    #eve tag -- XXX we only need this for tests, correct?
    tag: 5ee6043906449f7fa3447c96fd38dc9a536c5693

    #eve tag for base os -- XXX we only need this for tests, correct?
    base-tag: 571d94a11fa19d79805a0465030175b7257d343b

    #eve version (without hv and os) -- XXX we only need this for tests, correct?
    base-version: 0.0.0-snapshot-master-93c2dbb2-2020-05-08.13.15

    #config part of EVE -- XXX this can be killed now, correct?
    config-part: adam/run/config

    #variant of hypervisor of EVE (kvm/xen) -- XXX why do we need this option if we don't rebuild
    hv: kvm

    #EVE os (linux/darwin) -- XXX why do we need this option?
    os: darwin

eden:
    #root directory of eden
    root: /Users/roman/src/lfe/eden/dist

    #URL of RedisDB for Eden to talk to (MOVED-FROM adam.redis.eden)
    redis-url: redis://10.0.0.247:6379

    #caching logs and info to redis instead of local (MOVED-FROM adam.caching.*)
    events-caching:
        enabled: false

        #cache from redis
        redis: false

        #prefix for directory/redis stream
        prefix: cache

    images:
        #directory to save images
        dist: images

        #yml to build docker image
        docker: /Users/roman/src/lfe/eden/images/docker/alpine/alpine.yml

        #yml to build vm image
        vm: /Users/roman/src/lfe/eden/images/vm/alpine/alpine.yml

    #download eve instead of build
    download: true

    #directory to save certs
    certs-dist: certs

    #directory to save binaries
    bin-dist: bin

    #ssh-key to put into EVE
    ssh-key: certs/id_rsa.pub

    #observe logs in tests
    logs: false

    #eden binary
    eden-bin: eden

    #test binary
    test-bin: eden.integration.test

    #test script
    test-script: eden.integration.tests.txt

redis:
    #port for access redis
    port: 6379

    #tag for redis image
    tag: 6

    #directory to use for redis persistence
    dist: redis

#eserver is tool for serve images (MOVED-FROM: eden.eserver)
eserver:
        #ip (domain name) of eserver for EVE access
        ip: mydomain.adam

        #port for eserver
        port: 8888

        #pid for eserver
        pid: eserver.pid

        #log of eserver
        log: eserver.log

Seems to be related to the Adam run path not existing:

eden adam start
INFO[0000] Executable path: /Users/roman/src/lfe/eden/eden
INFO[0001] {"status":"Pulling from lfedge/adam","id":"0.0.26"}
INFO[0001] {"status":"Digest: sha256:b506a8e4cad7f97b74425bcddbc00ae966b03232fedfe9d76dd1fd90931b6899"}
INFO[0001] {"status":"Status: Downloaded newer image for lfedge/adam:0.0.26"}
ERRO[0001] cannot start adam: error in create adam container: Error response from daemon: invalid mount config for type "bind": bind source path does not exist: /Users/roman/eden/adam/run

If I make it manually mkdir -p /Users/roman/eden/adam/run it seems to work

One use case for EVE is to ru applications. Now I need to write a config or issue a set of commands. Would like to have a one line command to deploy an app.

while running ssh manually with existing ssh key is not that big of a deal, it would be very nice if I can simply do eden eve ssh and immediately ssh into the running instance of EVE

Hi, I've noticed that the version field of the config itself (the following JSON object at the very top:

$ cat config.json
{
  "id": {
    "uuid": "93d13bae-87b6-4277-9cc5-752c4ba957bc",
    "version": "4"
  },
...

doesn't get incremented after updates to the config.

This needs to happen for EVE to pick up the new config effectively. That said, I think we should follow @deitch strategy of how this needs to be done. E.g.:

• if config contains UUID and it does not match the existing one: error
• if config does not contain UUID: insert automatically
• if config contains version: override the existing one
• if config does not contain version and the existing one is an integer: increment and insert
• if config does not contain version and the existing one is not an integer: error

You can even lift his code for doing it from Adam: lf-edge/adam#19

My eden workspace is checked out at /Users/roman/src/lfe/eden however when I run eden config I see that the value of eden.root is pointing to /Users/roman/eden

eden config should remain as a command that allows me to manipulate config files for various pieces of the harness (global eden config, configs for adam, eve and eserver) and thus never block at trying to download/unpack anything.

All the functionality that has to do with "setting things up" (like downloading images from docker hub, building images, etc.) should be moved into a standalone command called setup.

Once we split it this way eden config will stop at making sure that various config files in the filesystem are the way I like them but NOT INTERPRET those configs. IOW, if an image I pointed at in my config is missing and needs to be downloaded -- eden config will not attempt to do that).

On the other hand, the new eden setup command will treat all the various configs produced by eden config as R/O and will be in business of making sure that my system is setup according to the values in those configs (images are downloaded, or built, etc., etc.). It will be important to make sure that eden setup has a dry run option. So that running eden setup --dry-run will produce an output of what eden setup would do