-
Notifications
You must be signed in to change notification settings - Fork 28
HOLD FOR RELEASE: Add CMX VMs beta docs #3407
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
base: main
Are you sure you want to change the base?
Conversation
✅ Deploy Preview for replicated-docs ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
✅ Deploy Preview for replicated-docs-upgrade ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
docs/vendor/testing-vm-networking.md
Outdated
replicated vm port rm VMID_OR_VMNAME | ||
``` | ||
|
||
## Connect a CMX VM with a CMX Cluster |
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.
Oo fancy.
Makes me wonder if we might want to consider how this content fits with or overlaps with https://docs.replicated.com/vendor/testing-ingress.
As in, do we want separate VMs and cluster networking pages?, where would this info live that touches on both?, do we want the headlines framed around "networking", "accessing your app in the cluster/VM", or maybe something else? etc
I don't really think this needs to be addressed as part of this PR, but something we can talk through
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, let's discuss this! Very good questions.
docs/vendor/testing-vm-create.md
Outdated
ssh -T [email protected] | ||
``` | ||
|
||
1. For the prompt `Are you sure you want to continue connecting (yes/no/[fingerprint])?`, type `yes` and press Enter. |
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.
- For the prompt
Are you sure you want to continue connecting (yes/no/[fingerprint])?
, typeyes
and press Enter.
I got this output when I was testing. I assume you are just supposed to say Yes?
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.
Note from 8/4: we should clarify that you may or may not see this prompt.
|
||
```bash | ||
replicated vm create --distribution ubuntu --version 20.04 --ssh-public-key ~/.ssh/id_rsa.pub --ssh-public-key ~/.ssh/id_ed25519.pub | ||
``` |
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.
To automate the creation of VMs in your CI/CD workflows, you can use the flag
--ssh-public-key
to provide the SSH public key for a GitHub service account.
This section doesn't have any info about how to set up the service account/use it in your CI/CD workflows. I think that's fine for the first iteration of these docs, but one thing that might be important is how would the Vendor Portal be made aware of this service account?
Would we like to recommend that someone on the team needs to add the name of the service account in their Vendor Portal account? Or would be prefer the username override method?
replicated vm create --distribution ubuntu --version 22.04 --disk 50 --instance-type r1.medium | ||
``` | ||
|
||
## Connect to a VM |
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.
Note: I did some reorg here so that you have three methods listed for how to connect to a VM (previously, the steps on connecting manually were elsewhere).
I also moved the steps on how to transfer files to their own h2 section. My assumption was that it would be worthwhile to include steps just for how to connect, without also telling people how to transfer. If that's not a valid use case though, we can combine the "connect" and "copy files" sections into one. LMK.
docs/vendor/testing-vm-create.md
Outdated
|
||
* [**Direct SSH**](#direct-ssh): When you connect to a VM using direct SSH, you can use your SSH tool of choice and pass any client supported flags, without any added connection lag of being routed through the Compatibility Matrix Forwarder. Example use cases for direct SSH include transferring large assets such as air gap bundles to the VM using SCP, or passing specific SHH flags during testing workflows. | ||
|
||
* [**Connect to a VM Manually**](#connect-to-a-vm-manually): If the above options are not supported with your preferred SSH client, you can connect to a VM manually. |
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.
^ this "connect manually" doesn't need to be a totally different option. instead, just add it as an alternative to the vm ssh-endpoint command
|
||
:::note | ||
You can also get the SSH endpoint and port in JSON format by running `replicated vm ls --output 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.
^ new note that replaces the "connect manually" steps
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.
@hyu updated based on our convo today and approved! marking as "hold for release", and I'll leave it to you to merge when you all are ready :)
Co-authored-by: Kyle Squizzato <[email protected]> Co-authored-by: Josh De Winne <[email protected]>
No description provided.