-
Notifications
You must be signed in to change notification settings - Fork 66
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
Add callysto cluster and hub #1649
Conversation
Terraform plan output
|
According to our docs, I believe I first need an approval for the config, before running terraform apply and add the cluster to the various workflows |
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 LGTM!
For setting up new infra, I think there's no need to wait on first review to start iterating. I think it's covered in https://infrastructure.2i2c.org/en/latest/contributing/code-review.html?highlight=terraform#changes-to-set-up-new-infrastructure.
I'm not sure we need to redeploy either!
Sorry about it! Thank you @yuvipanda! |
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.
I actually have a suggestion here - let's use Google Filestore and not manually manage an NFS server. I think we should move off manually managed NFS servers everywhere possible, and just rely on Filestore. The only disadvantage of filestore is the minimum base cost, but I think at Callysto's scale that isn't a big deal.
Thanks for the suggestion @yuvipanda! I've deleted the manually deployed vm and switched the cluster to use GFS. But just to make sure I understand, the reason behind this is to avoid performing those manual steps to create the vm, right? Are there any other technicalities that make GFS the better choice? thanks! Update on the state of the cluster and hub
HOWEVER
IMPASSEI am in an impasse however on how to deal with the There is also the issue of tracing back support requests to the users, which in theory would be possible with the current hub version if Context Where I need helpThe only solution I can think of right now is to override the But maybe there's something better that can be done? I would really appreciate a set of fresh eyes looking at thins, since I feel I am in a bit of a loop maybe (cc @yuvipanda) |
Sorry for the extra ping @yuvipanda and @2i2c-org/tech-team, but can please help unblock me with on the above matter ⬆️ ? thank you! |
Yes - GFS is fully automated, while manual NFS isn't. Plus, it is much easier to resize a GFS than a manually deployed NFS VM. |
@GeorgianaElena re: authentication, were we planning on allowing anyone with a Microsoft or Google account (based on #1439 (comment))? If that's the case, I think for admins we should ask the admins to log in, and ask for their opaque ID. It can be found if they go to the JupyterHub Control Panel. For example, if I go to https://jupyter.utoronto.ca/hub/home I can see my user id on the top right: We can add those to the admin list once admins log in and report their opaque UID to us. This is also how support can be provided - users can self-report their Opaque UID when asking for support. Hope this helps! |
Hmm, not sure if they want to allow anyone but I will ask. I assumed they would like to keep a list of allowed users at least. Esp since we don't have extraordinary experiences with the hubs where we enabled this kind of loose access.
I believe not knowing each users opaque UID disables the ability to have an allowed list because the people will need to login to find their id. But CILogon provides a service which I believe checks which attributes returns an identity provider, and it's running at https://cilogon.org/testidp/. You can then login with the IDP and account you'd like to access the hub, go to the We could use this to find out the admin's Opaque IDs and the admins could ask the users get their oids to providem access to the hub. WDYT @yuvipanda ? |
Support and Staging deployments
Production deployments
|
Support and Staging deployments
Production deployments
|
@2i2c-org/tech-team, can you please login into https://2i2c.callysto.ca then retrieve the hub username from there so I can add it as a hub admin? |
I am |
Support and Staging deployments
Production deployments
|
Kind of 😅 I believe the community rep wants to keep theirs private, so I'll probably have staff ones mapped and add the others through the hub Admin Panel. |
Yeah, I meant, but didn't articulate, staff IDs! |
for more information, see https://pre-commit.ci
c47b9f2
to
24e63d9
Compare
Support and Staging deployments
Production deployments
|
Hmmm, I'm going to have to pause that workflow that posts the plans and figure out why it's posting multiple times instead of updating an existing comment... Edit: I opened #1675 to track |
Thanks a lot @sgibson91 ✨ FeedbackI believe this is ready for review again. I will check with the callysto folks if they are able to login, but my plan is to get this merged, then iterate on further request from them in other PRs |
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.
With the understanding that this would probably have trouble with cryptocurrency miners in some form as is (but I think @ianabc already knows that :D), I'm happy to merge this.
@ianabc @GeorgianaElena let's open a separate issue to talk about locking this down to protect from that some more? We already run cryptnono, but need more I'd imagine.
Thanks @yuvipanda! I opened #1678 and will merge this now as it is, but I plan to open a follow-up PR to use an allowed list of users until we find other abuse protection mechanisms for it, or until the hub will need to be used. |
🎉🎉🎉🎉 Monitor the deployment of the hubs here 👉 https://github.com/2i2c-org/infrastructure/actions/runs/2991831003 |
Reference #1439
Creates a regional cluster in
northamerica-northeast1-b
(Montreal, gpu machines are available in this zone also, just in case we need them).Other assumptions made would be that the storage buckets will be disabled since they won't probably be needed, as this hub is an educational one. Also, although right now it would be a single tenant cluster, maybe this would change in the future, so I left
enable_network_policy
set to true since I don't think we are so strict on the costs.Config inspiration was from the cloudbank cluster, since that holds edu hubs