-
Notifications
You must be signed in to change notification settings - Fork 529
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
[Docs] Deployment on existing infra #3926
Conversation
Updated with figure and general polishing. |
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.
nit: deploy.sh
may feel a bit janky to some people. Will it be hard to turn it into a CLI or part of sky local up
?
Updated to integrate the script into |
Updated with a polished guide and minor fixes. |
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.
Nice @romilbhardwaj! Took a pass over the docs.
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.
- "dev pods"?
- How about showing one arrow (step)? Can move "User provides" to left, and skypilot logo + text on right. This feels more like it's a tool, rather than a vendor.
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.
- Good point, node conflicts with physical nodes. Changed to pods.
- I think putting a single arrow de-emphasizes the need for having something like SkyPilot and makes it seem like the users are having to deal with low-level infra themselves.
@@ -0,0 +1,143 @@ | |||
.. _existing-clusters: | |||
|
|||
Deploy SkyPilot on existing clusters |
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 discussion: "local clusters" / "local machines" / "on-prem machines" may be better. "Existing clusters" may imply "existing k8s clusters" which has k8s already.
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.
Using "local" or "on-prem" may make a user think this is not applicable to machines in the cloud. We have had several users have this existing cluster use case when their cluster was from a cloud provider.
Also, using "local" or "on-prem" does not solve the "existing k8s" concern - both can be assumed to have k8s.
We can consider changing to "existing clusters" to "existing machines" if that helps.
…o onprem_deploy_script # Conflicts: # docs/source/_static/custom.js
SSH_KEY=path/to/ssh/key | ||
sky local up --ip $IP_FILE --username $SSH_USERNAME --key-path $SSH_KEY | ||
sky local up --ip $IP_FILE --ssh-user SSH_USER --ssh-key-path $SSH_KEY |
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 --ip
or --ips
(L86)? Latter is more intuitive. (Or --ipfile like DeepSpeed's --hostfile.)
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.
ah good catch - it is indeed --ips
, this typo was a remnant from the old deploy.sh.
This PR adds a deployment script to help users easily deploy k8s + SkyPilot given a list of SSH IPs.