Closed antho1404 closed 4 years ago
We should also refacto the init of the CoreClient
in the utils
package. It's currently init in daemon
and service
package
service deployment will be done by https://github.com/mesg-foundation/core/issues/366
Done
I see that validate command directly accesses to core where it can use a new gRPC api for validation. And there might be more commands like this. Reopening this one.
We're using importer.validate here and it should stay to make it faster, but we should also have ServiceValidate.
I would like to have this validation really separated, I wonder what would be the best. I have few solutions:
test
or validationOnly
or noPersistancy
... like that we fully use the process from the deploy and we ensure that the validation is 100% validI'm open for any other proposal, the goal is to be able to have this validation even from outside the cli we develop. An UI could be able to verify the source, another CLI in python should do etc...
For a full validation, I suggest to send all service context to Core not just particular files like Dockerfile, mesg.yml, ignore files etc. Because the way we validate and the files we require may change or we can introduce more validations in future like limiting service's size on disk.
Deploying with only validation option seems nice to me. But since the action's name is deploy
, it's also a bit confusing too. Maybe having a separate API like validateService
is the better to avoid any confusion.
@mesg-foundation/core todo: close or move to cli issues
Right now the CLI does some actions by connecting directly to the database, this should not be possible and the CLI should only start/stop the daemon and then connect to the api of the daemon
Here a the following functions that need to be implemented in the API and replaced in the CLI
When these functions are implemented in the API it means we can have different clients CLI or any website or application to have the exact same features