lf-edge / eden Goto Github PK
View Code? Open in Web Editor NEWEden is where EVE and Adam get tried and tested:
Home Page: https://projecteve.dev
License: Apache License 2.0
Eden is where EVE and Adam get tried and tested:
Home Page: https://projecteve.dev
License: Apache License 2.0
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:
-dir
flagThe 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:
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):
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:
Please migrate to them
Currently an EVE instance under Eden's management can be in one of the following states:
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:
Static objects:
config
subcommand)controller
subcommand)certs
subcommand)ociimage
subcommand)eve-update
subcommand)test
subcommand)Dynamic objects:
adam
subcommand)redis
subcommand)eserver
subcommand)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):
server
subcommand and move whatever functionality maybe left there under eserverreconf
subcommand and move whatever functionality maybe left to either `ociimage
to either eci
or eci-image
eve-update
to either baseos
or eve-image
and expand its scope (eventually to be able to manipulate various forms of EVE's baseosinfo
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
flagclean
top level subcommand, if you agree with my definition aboveNote 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:
dist/eve
make build-tools
dist/evebaseos
and dist/evelive
as local git clones git clone eve evelive
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:
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
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:
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:
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
.
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:
eden config add my-new-config
doesn't actually do anything useful AND it doesn't tell me that a mandatory option is --name
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:
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:
.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~/.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)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:
eden eve-update <rootfs.img>
command which will force a config that will update EVE to rootfs.img
eve-config.json
and running eden reconf eve-config.json
so that Adam picks up a new configeden 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)
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.:
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
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.