Self-hosted covalent UX

[venkatBala]

As the self-hosted Covalent on AWS is nearing completion, the desired UX around it needs some discussion. As pointed out in earlier discussions, the process for deploying covalent on AWS EC2 is fairly straightforward. Covalent AMIs are (to be) built with each stable release automatically via the release pipelines. The corresponding terraform script to deploy a EC2 virtual machine using the stable AMI can be found in AgnostiqHQ/terraform repository under covalent-ec2-server. For completeness, the command to deploy Covalent on AWS is

terraform apply -var="covalent_version=<covalent_version>" -var="aws_key_name=<ec2 key name>" -var="owner_acct_id=<agnostiq owner id>"

The output of this command will be the public ip address (FQDN) that was dynamically assigned to the instance by AWS. This in principle is all a user should need to start dispatching workloads to Covalent.

This discussion is intended to address the following issues

• Having obtained the address of the remote dispatcher, how must the user specify it in their local environment?
  • Is the user expected to manually create a covalent.conf file in ``/.config/covalent/covalent.conf` and add the dispatcher address therein
  • Is the desired UX that user's in their jupyter notebooks import covalent, and perform ct.set_config("dispatcher.address", <dispatcher_address>) to set the address there
  • Should the covalent config CLI be modified to allow configuring covalent.conf from the command line?
  • Should the covalent UI open automatically once a dispatch is done?

covalent config add "dispatcher.address=<address>"
covalent config add "dispatcher.port=<port>"

Secondly, as can be noted the terraform command required to self-host covalent is entirely independent to Covalent and can be carried out as such. Would having a UX that is part of covalent CLI itself help here i.e. (for example)

covalent deploy --version=0.177.0 --ncpus=2 --mem=4G --credentials=~/.aws/credentials --requirements <path/to/requirements.txt>

Is there a benefit to having such a UX? The addition of requirements.txt here is to allow users to install any additional python packages needed for their workflows/tasks.

Another thing to consider is the what the UX surrounding CLI would be like. With Covalent self-hosted, in principle there is no need for a user to run covalent start on their local machines as all the dispatches are forwarded to the remote server. This entails that any other CLI command would not work at present i.e.

• Running covalent logs locally will not return anything since the logs are being generated and stored on the remote machine
• covalent cluster and all of its sub-commands also will not work for the same aforementioned reasons
• covalent status will report that server is not running since for the time being it checks whether covalent is running locally on the user's machine

What the UX around this ought to be needs to be discussed and prioritized accordingly.

@wjcunningham7 @santoshkumarradha @AlejandroEsquivel

[FyzHsn]

@venkatBala I think one of the concerns was how would the user be informed of the address where the UI is running. Currently, covalent status prints out the address the user needs to navigate to for the UI. For the sake of consistency, there needs to be a similar UX for the self-hosted Covalent.

Note that opening the UI automatically once the dispatch is done is not enough to minimize the accessibility barrier to the UX. For example, if the user closes the browser and hasn't saved the server address, they still would need a similar way to covalent status to check where the UX is running.