-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
machine: Add a new command dvc machine status
#6649
Conversation
fix#6482 1. add a new command `dvc machien status` 2. add a unit test for the cli call. 3. add a unit test for the shown result.
Co-authored-by: Saugat Pachhai <[email protected]>
Co-authored-by: Saugat Pachhai <[email protected]>
@karajan1001 How much extra work would it take to add an asciinema or other video inside of these PRs as an example? It might also make it easier to demo the feature. |
One thing we should consider is sanitizing auth/private data related fields in the CLI commands. In We should probably do the same thing and not display those fields by default (and include them with I'm not sure if there's a straightforward way to get the list of what fields terraform considers sensitive from their CLI, or if it's hard-coded in the provider settings somewhere (@iterative/cml team may know?) |
@pmrowla we hardcode a whitelist in CML https://github.com/iterative/cml/blob/2e9a21ddb4b4eb1261a75ba72f89b98b1972d063/bin/cml/runner.js#L191-L212 and also mark sensitive things in TPI.go (e.g. https://github.com/iterative/terraform-provider-iterative/blob/732d0919577867d40b7ff635dd0667caf19d3cb9/iterative/resource_machine.go#L106) for |
Any way to read this white list? Looks like I need to hardcode it first and sync manually first. |
|
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.
Any way to read this white list? Looks like I need to hardcode it first and sync manually first.
SENSITIVE_FIELDS = {"ssh_private", "startup_script"}
seems enough
Co-authored-by: Casper da Costa-Luis <[email protected]>
Co-authored-by: Casper da Costa-Luis <[email protected]>
for more information, see https://pre-commit.ci
UI comments:
cc @skshetry |
@dberenbaum I think suppressing terraform's CLI output may be an upstream feature request related to https://github.com/iterative/tpi/blob/c7259a8fea023797058deaf487700645df5fe210/tpi/__init__.py#L60 |
@@ -143,6 +143,22 @@ def run(self): | |||
return 0 | |||
|
|||
|
|||
class CmdMachineStatus(CmdBase): | |||
SHOWN_FIELD = ["name", "cloud", "instance_hdd_size", "instance_ip"] |
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.
Can we include instance_launch_time
?
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.
Agreed
|
||
all_status = self.repo.machine.status(self.args.name) | ||
for i, status in enumerate(all_status, start=1): | ||
ui.write(f"instance_num_{i}:") |
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.
Could this be a table, more like dvc stage list, to make it easier to parse? We are trying to have default outputs that are both easy to read and parse if possible.
Thanks, @casperdcl! Should I open an issue? Also, is there a "local" option supported for tpi cloud? @karajan1001 @pmrowla Would that be helpful for integration tests and development generally? |
@dberenbaum were you intending to quote #6649 (comment) instead? |
Yup, thanks. I'll edit it to reference the correct quote. |
@dberenbaum Regarding the terraform CLI output, we originally decided to leave it enabled by default (and not suppress it) since there is no other way for us to reflect status while Since we can't hook into the terraform process itself to setup any kind of status callbacks, the only other option on the DVC UI side would be to just display something like a spinner (we can't provide any progressbar-like estimate of when the terraform command will complete). |
Another way might be to only show the tail of the output limited to |
We don't want to fully suppress the output for commands where progress is important (like On the other hand, I can imagine some people might want the option to see the raw terraform output if they are familiar with that or want more granular info, so it might not be bad as an option (or maybe include in verbose logging?). If we do show it, it would be helpful to somehow tag it or separate it from output controlled by DVC. |
Going to merge this as-is since it's been on hold for a bit. Suppressing the terraform CLI output should be handled upstream in TPI, and tabular formatting for the status output (and decisions on additional fields to display) can be handled in a follow-up PR |
What about making |
fix #6482
dvc machine status
β I have followed the Contributing to DVC checklist.
π If this PR requires documentation updates, I have created a separate PR (or issue, at least) in dvc.org and linked it here.
Thank you for the contribution - we'll try to review it as soon as possible. π