2i2c-aws-us: ncar-cisl added

[consideRatio]

• for [Request deployment] New Hub: NCAR-CISL for UCAR #2523

[github-actions]

Merging this PR will trigger the following deployment actions.

Support and Staging deployments

Cloud Provider	Cluster Name	Upgrade Support?	Reason for Support Redeploy	Upgrade Staging?	Reason for Staging Redeploy
aws	2i2c-aws-us	No		Yes	Following helm chart values files were modified: common.values.yaml

Production deployments

Cloud Provider	Cluster Name	Hub Name	Reason for Redeploy
aws	2i2c-aws-us	researchdelight	Following helm chart values files were modified: common.values.yaml, researchdelight.values.yaml
aws	2i2c-aws-us	ncar-cisl	Following helm chart values files were modified: common.values.yaml, ncar-cisl.values.yaml, enc-ncar-cisl.secret.values.yaml

[yuvipanda]

This is actually not required, as we do not use proxy anymore for HTTPS. The proxy stanza can be removed

[consideRatio]

Hmmmm, I recall it was required for some reason still, but I recall thinking the same thing.

If it isn't, it should be addressed for all our hubs, because its consistently setup for all hubs after #2349.

[consideRatio]

Ah, I figure it may be because of this, which is something we probably can relax:

infrastructure/helm-charts/basehub/values.schema.yaml

Lines 258 to 268 in 3a6b47f

	proxy:
	type: object
	additionalProperties: true
	required:
	- https
	properties:
	hosts:
	type: array
	minItems: 1
	items:
	type: string

[yuvipanda]

Aaah yes we should! Not sure why that's listed as required. Am ok if you wanna do that as a separate PR, or open an issue and deal with it later as well. Not required to block this PR

[yuvipanda]

One extreneous config stanza but otherwise lgtm

[consideRatio]

@yuvipanda I updated the PR title and PR description to reflect the PR better as it was a bit more than just add the hub for ncar-cisl.

Do you think the decision to remove the image choice for researchdelight in the GPU section was acceptable as well? I didn't think it was important enough to put the profileList config in individual hubs, but at the same time didn't want image choices to be shared among hubs in a shared cluster for the gpu option.

[yuvipanda]

@consideRatio I do think whenever we offer GPUs, we should offer those two choices. The default image doesn't have any GPU stuff, and these two images are different enough that I think we should do this each time.

[yuvipanda]

It probably makes sense to put these in the hub specific config though.

[consideRatio]

It probably makes sense to put these in the hub specific config though.

Done in 710bc23!

I do think whenever we offer GPUs, we should offer those two choices.

Okay lets do it (4aed868, e35dcd1), but I feel uneasy about this because I see how we provide blurry lines about image management responsibility by doing this. I'll open an issue about discussing this in a meeting, which is my preference on how to discuss this topic.

To quickly clarity why without entering a discussion about it here, consider the note I wrote in the config for singleuser.image below.

      image:
        # image choice preliminary and is expected to be setup via
        # https://ncar-cisl.2i2c.cloud/services/configurator/ by the community
        #
        # pangeo/pangeo-notebook is maintained at: https://github.com/pangeo-data/pangeo-docker-images
        name: pangeo/pangeo-notebook
        tag: "2023.05.18"

The gist is that I don't think we have a clear and simple enough policy for this image management if we specify a kubespawner_override for the GPU profile's image. By specifying it, we discard the community's ability to self-manage the GPU profile's image via the default image in the configurator, and perhaps also make the community adopt expectations that it needs to be a dedicated image.

[yuvipanda]

@consideRatio yes i agree with your concerns re: management, hence opened 2i2c-org/features#26. However, if we don't provide them the option to use the GPU image, they can not use any of the GPU features. I appreciate you sticking to the status quo here so users can benefit despite your uneasiness.

[github-actions]

🎉🎉🎉🎉

Monitor the deployment of the hubs here 👉 https://github.com/2i2c-org/infrastructure/actions/runs/5110517276

[consideRatio]

I read your excellent writeup in 2i2c-org/features#26 and I figure we'll skip a discussion about handling this interim situation where this is a problem to save our time and focus on the long term things instead.