RhodiumGroup / helm-chart

Helm Chart for Rhodiums jupyterhub deployment
https://rhodiumgroup.github.io/helm-chart/
0 stars 0 forks source link

Pangeo updates #7

Closed bolliger32 closed 4 years ago

bolliger32 commented 4 years ago

I think we probably don't actually need our own helm chart (?) I think we can just get away with a config file that we use to configure the pangeo chart. This way, we can leave most of the keeping up with the rapid helm changes to them.

Note I only updated the jupyter_config.yml file and the test2.climate-kube.com creation script. The other creation scripts and the impactlab config file I haven't touched yet (nor the readme or .travis file, which we would probably only need for tests now).

It's a thought?

delgadom commented 4 years ago

Got it. Yeah this seems like a great intermediate step as long as it doesn’t delete data. It seems like the filestore solution is a little farther off so this seems fine. Is this what’s deployed on test2?

From: Ian Bolliger notifications@github.com Reply-To: RhodiumGroup/helm-chart reply@reply.github.com Date: Sunday, December 1, 2019 at 1:06 PM To: RhodiumGroup/helm-chart helm-chart@noreply.github.com Cc: Michael Delgado mdelgado@rhg.com, Comment comment@noreply.github.com Subject: Re: [RhodiumGroup/helm-chart] WIP: Pangeo updates (#7)

@bolliger32 commented on this pull request.


In jupyter-config.ymlhttps://github.com/RhodiumGroup/helm-chart/pull/7#discussion_r352372780:

 storage:
   capacity: 10Gi

I think it won't do anything if there are already standard volumes existing. It will just affect new users and if we were to delete an old users volume. We could also just keep it standard and then at some point try migrating to the filestore instance?

— You are receiving this because you commented. Reply to this email directly, view it on GitHubhttps://github.com/RhodiumGroup/helm-chart/pull/7?email_source=notifications&email_token=AA4G7UA7KIJZ5WZPQMH65NDQWQRNZA5CNFSM4JO2OFNKYY3PNVWWK3TUL52HS4DFWFIHK3DMKJSXC5LFON2FEZLWNFSXPKTDN5WW2ZLOORPWSZGOCNPIVBQ#discussion_r352372780, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AA4G7UC7KFO6J5WVCTIIYBDQWQRNZANCNFSM4JO2OFNA.

bolliger32 commented 4 years ago

Got it. Yeah this seems like a great intermediate step as long as it doesn’t delete data. It seems like the filestore solution is a little farther off so this seems fine. Is this what’s deployed on test2?

Yeah it is. So I think any new user should instantiate a ssd PersistantVolume instance.

brews commented 4 years ago

Heads up, @bolliger32 , ipynb checkpoints have made it into version control under this PR.

Might want to remove them? :-)

bolliger32 commented 4 years ago

@brews bad Ian! bad Ian! sorry, fixed.

delgadom commented 4 years ago

This is weird and slightly disconcerting...

https://travis-ci.org/github/RhodiumGroup/helm-chart/builds/670380553#L519

Our test suite exits without error, but the fiona import test on the worker seems to be printing this debug line:

ERROR 1: PROJ: proj_create_from_database: Open of /opt/conda/share/proj failed

Since fiona does import without error, maybe this is just debug and nothing to worry about?

delgadom commented 4 years ago

Seems like this is relevant to the above issue: https://github.com/conda-forge/geopandas-feedstock/issues/63#issuecomment-526145391 (and below)

bolliger32 commented 4 years ago

We're merging now while ignoring this issue b/c it is unlikely related to this helm chart and rather likely to be related to the notebook and worker images

This is weird and slightly disconcerting...

https://travis-ci.org/github/RhodiumGroup/helm-chart/builds/670380553#L519

Our test suite exits without error, but the fiona import test on the worker seems to be printing this debug line:

ERROR 1: PROJ: proj_create_from_database: Open of /opt/conda/share/proj failed

Since fiona does import without error, maybe this is just debug and nothing to worry about?