search

coiled / feedback

A place to provide Coiled feedback
16 stars 4 forks source link

Maintained software environment for nightlies #197

Closed fjetter closed 2 years ago

fjetter commented 2 years ago

Coiled is offering a range of predefined software environments based on the coiled-runtime meta package, see https://cloud.coiled.io/coiled/software image

We should expand this list of software environments with a coiled/coiled-runtime-nightly-pyXY. This nightly would be published once a day and would include the most recent builds of dask and distributed (as is already built by the coiled-runtime CI)

crusaderky commented 2 years ago

From my understanding the nightly builds of coiled-runtime are whatever is in https://github.com/coiled/coiled-runtime/blob/main/recipe/meta.yaml git tip, e.g. they still pin the version of dask and distributed. So I think what is actually desirable is 3 separate sets of builds:

ntabris commented 2 years ago

The current approach seems fine to me. We build images and push the to Docker Hub. It’s trivial to use these with Coiled if you know how, but that’s also not typical/recommended use, so I don’t especially want to make that easier.

Are you thinking you want more customers using nightly?

ntabris commented 2 years ago

It’s trivial to use these with Coiled

in case anyone doesn't know how: https://docs.coiled.io/user_guide/software_environment_creation.html#docker

or via command line: https://docs.coiled.io/user_guide/software_environment_cli.html#coiled-env-create

It's pretty much instant to create software env from an existing image.

dchudz commented 2 years ago

FWIW I agree w/ Nat here.

His advice seems fine for anyone internal, or the occasional outside user who wants nightlies.

I don't expect wanting nightlies to be common for most users.

(Happy to discuss if any of that seems wrong, but please tell us why.)

ncclementi commented 2 years ago

@fjetter I remember that at some point it was discussed that we didn't want users to have nightlies accessible in prod as we don't want to maintain them. That is why they are not there. That being said, we do push a docker image with the dask and distributed nightlies every day. You can find the soft-env from container which will be very fast. Here are the nightlies https://hub.docker.com/r/coiled/coiled-runtime/tags

dchudz commented 2 years ago

Hey @fjetter, feel free to reopen if you think there's more we should do, but I think you should be all set with Naty's link to the images, and Nat's link to the docs on what to do with them.

fjetter commented 2 years ago

@fjetter I remember that at some point it was discussed that we didn't want users to have nightlies accessible in prod as we don't want to maintain them.

Does maintain refer to dask support? I don't think that's an issue. Nightlies are very obviously not stable releases. What's the additional maintenance burden?

I don't expect wanting nightlies to be common for most users.

We often ask users to provide early feedback. Right now, that's not easily possible. coiled default environments use stable coiled-runtime versions which is great from a support perspective but we're making it harder than it should be to try newer versions of dask.

I still believe we should offer nightly software environments similar to what guido proposed in https://github.com/coiled/feedback/issues/197#issuecomment-1234100864

FWIW I agree w/ Nat here.

His advice seems fine for anyone internal, or the occasional outside user who wants nightlies.

I don't have docker images that fit my needs, see https://github.com/coiled/feedback/issues/197#issuecomment-1234100864

ntabris commented 2 years ago

I don't have docker images that fit my needs

Ah, okay. I think the request then is for coiled-runtime CI to build and push these (and not for them to be added as Coiled software environments). Disagree?

fjetter commented 2 years ago

Ah, okay. I think the request then is for coiled-runtime CI to build and push these (and not for them to be added as Coiled software environments). Disagree?

I still think there is value in offering this easily to users.

ntabris commented 2 years ago

I still think there is value in offering this easily to users.

Maybe a sync chat is better since we keep going back and forth, but my perspective is that we've explained that it is easy if there are docker images.

If you disagree, it would be helpful if you explained the use-case that you think this doesn't cover, since I (and I think others) still aren't seeing what you're trying to accomplish that wouldn't be well covered by this.

fjetter commented 2 years ago

Maybe a sync chat is better since we keep going back and forth, but my perspective is that we've explained that it is easy if there are docker images.

IMO this is not a question about technology but about usability. If we decide there is value in nightlies I don't see why we'd treat them any different than the default environments listed https://cloud.coiled.io/coiled/software

providing them as a default coiled environment offers more visibility and removes an unnecessary step for the user.

ntabris commented 2 years ago

IMO this is not a question about technology but about usability

Totally agree. Here are the user-related product reasons driving my "I don't want these listed as pre-baked software environments":

  1. My impression is that if you don't know what you're doing, you probably shouldn't be using a nightly dask. My impression is that a big part of why we created coiled runtime was to give people something stable, because running unpinned dask/distributed was not a good experience.
  2. Having nightlies here is going to make it that much easier to have out-of-sync cluster and local dev. Again, if you know what you're doing, you can avoid this, but that's why I think it makes sense for easy nightlies if you're a power user who knows where to find them, but not for most users.
  3. If we have 3 separate nights, as described in https://github.com/coiled/feedback/issues/197#issuecomment-1234100864, then it's going to be even easier to pick the wrong one or to get cluster and local out of sync.
  4. I think all of this is addressed by package sync assuming package sync can be fast which @shughes-uk is currently working on.
dchudz commented 2 years ago

If we decide there is value in nightlies I don't see why we'd treat them any different than the default environments listed https://cloud.coiled.io/coiled/software

It's different b/c nightlies should only be used by power users who already know a lot about how things work and how to use dask/coiled (or are working closely with some such person).

That is to say, I think the same thing as Nat said.

dchudz commented 2 years ago

Closing as "won't do". Feel free to reopen and schedule a live chat with us if you like.

ntabris commented 2 years ago

The current approach seems fine to me. We build images and push the to Docker Hub. It’s trivial to use these with Coiled if you know how, but that’s also not typical/recommended use, so I don’t especially want to make that easier.

Are you thinking you want more customers using nightly?

On Thu, Sep 1, 2022 at 4:40 AM Florian Jetter @.***> wrote:

Coiled is offering a range of predefined software environments based on the coiled-runtime meta package, see https://cloud.coiled.io/coiled/software [image: image] https://user-images.githubusercontent.com/8629629/187894503-0208c003-187e-4fe6-a56d-6f324542b7e3.png

We should expand this list of software environments with a coiled/coiled-runtime-nightly-pyXY. This nightly would be published once a day and would include the most recent builds of dask and distributed (as is already built by the coiled-runtime CI)

  • Early adopters would have a much easier time trying new dask features
  • Developers would even benefit from a much higher update frequency but many of our tests could already be performed using a nightly build

— Reply to this email directly, view it on GitHub https://github.com/coiled/feedback/issues/197, or unsubscribe https://github.com/notifications/unsubscribe-auth/ALBFDHVVP3FQITLU26TP64LV4CB2PANCNFSM6AAAAAAQCHBQYQ . You are receiving this because you are subscribed to this thread.Message ID: @.***>