bilayer-containers
Replies: 4 comments 2 replies
-
|
Major issue: How do we handle this on the interface-builds? The worst-worst solution to me seems to be "one folder with config.yml for cuda, and one for non-cuda" (duplicates could get out of sync), the less-worse solution to me would be that we extend the config.yml spec to allow for "alternate containers to parallelize across for this same interface". But it will definitely require CI/CD to handle that. Are there other options to consider? |
Beta Was this translation helpful? Give feedback.
-
|
Minor issue: we hope/assume we're generally not building all the Dockers from Dockerfiles, but in this case, we are. How do we tell whatever CI/CD we build out for that what to name each of the tagged Dockers we have dockerfiles for? Right now, we have |
Beta Was this translation helpful? Give feedback.
-
|
Not the same but related (possibly should be a new discussion, possibly this one ) - matrixing across amd/arm . Thematically the same, in the sense of "we want to indicate that X containers should all follow the same interface patterns and need only a single config file, but be built separately according to their needs/drivers" |
Beta Was this translation helpful? Give feedback.
-
|
Aren't we already handling this by having a platform tag in the config. That way the spec makes the architecture explicit - users know which base image/platform they’re pulling, and we don’t need duplicate configs |
Beta Was this translation helpful? Give feedback.
-
|
Yes, it's currently explicit, but if I want the amd version of the container and you want an arm of the container version, right now, AFAICT (and please do let me know if I'm wrong), one of us is out of luck, OR we need two versions of the config (one that points at the amd container and one at the arm). If we want to matrix on arches, and/or if we want to matrix on source containers (maybe Cellpose5 makes a CUDA9 and a CUDA11 version), I don't think we currently have elegant ways to handle that (but am delighted if I'm wrong). |
Beta Was this translation helpful? Give feedback.
-
|
Yes, I see the point |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
In #49, we now have two Dockers and two Dockerfiles - one with and one without CUDA. We had presumably figured it would be fine to maintain SEQUENTIAL versions, because that is what tags are for, but never contemplated PARALLEL versions. The spec assumes there's a one true container name.
I'm generally convinced that even if we didn't do this for Instanseg, someone would ask us for this eventually, but we need to have a way to handle at least a couple of aspects:
Beta Was this translation helpful? Give feedback.
All reactions