Closed bolliger32 closed 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
dynamic:
storageClass: pd-ssd
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.
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.
Heads up, @bolliger32 , ipynb checkpoints have made it into version control under this PR.
Might want to remove them? :-)
@brews bad Ian! bad Ian! sorry, fixed.
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?
Seems like this is relevant to the above issue: https://github.com/conda-forge/geopandas-feedstock/issues/63#issuecomment-526145391 (and below)
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?
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?