-
Notifications
You must be signed in to change notification settings - Fork 13
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
System service instance #1087
System service instance #1087
Conversation
c381cb6
to
fcf6f8e
Compare
9c2dbc0
to
085b8b7
Compare
085b8b7
to
ff3eb5d
Compare
@NicolasMahe can you take care of ethwallet service |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's looking good!
I would suggest to simplify the override of the env of the system services. Instead of having to define one variable per env, we could pass ALL envs in one variable as a JSON encoded array. The Engine would have to decode it to start the instances.
Maybe we could go further and create a generic system based on JSON encoded string or a file that is transform to an asset during the compilation, that contains all info about the SystemService. Like this we will not have to update the config package to add or update system services. @krhubert suggested something like this on Discord.
This is definitely for another PR and it's not blocking for the next release.
dev
Outdated
pushd $s > /dev/null | ||
name=$(basename "$s") | ||
varname="${name}" | ||
LDFLAGS+=" -X 'github.com/mesg-foundation/core/config.${varname}Compiled=$(cat compiled.json)'" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
also, why not compiling the service also in this script? like scripts/build-engine.sh is doing? because of optimization?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes because of optimization but not only, we should only have the compiled version of the service and if we have the compiled version there is no need of having the sources of the system service in the engine and in that case, the compiled version is a snapshot of the exact version we want from this system service that we can manually update with something like
mesg-cli service:compile https://github.com/mesg-foundation/service-marketplace > systemservices/marketplace.json
Url: s.URL, | ||
Sid: s.Definition.Sid, | ||
Hash: s.Instance.Hash.String(), | ||
Url: s.Definition.Source, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is it useful to return the Source?
I think it will be nice to also have ServiceHash along side InstanceHash.
But anyway Hash = InstanceHash
is the most important one 👍
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
just didn't want to break the api and return what was initially returned. Let's remove it if needed in another PR
# Conflicts: # config/services.go # core/main.go # dev # scripts/build-core.sh
eb9a5dc
to
6ebc490
Compare
# Conflicts: # config/services.go # core/main.go # dev # scripts/build-engine.sh
Co-Authored-By: Nicolas Mahé <nicolas@mesg.com>
Co-Authored-By: Nicolas Mahé <nicolas@mesg.com>
Dependency: #1085
service.Create
andinstance.Create
functionsdev
scriptgo-assets
or something like thatfix #1115