You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Description
At the moment we have a function pull_if_newer that to avoid overwriting (well, technically retagging, I believe) an "older" (upstream) image. See issue where I think this came from.
IMHO, I don't think the added complexity to solely deal with this today, when multiple registries are typically used for algorithms, is worth the continued effort.
These are some of the reasons, as a I see it:
As Frank pointed out, using a different tag locally is what is recommended by the moby community.
pull_if_newer system was (?) implemented at a time when harbor seemed to be only registry in use by vantage6. These days I think users (myself included) are using other registries for algorirhtms like Azure Container Registry or GitHub Container Registry.
IMHO, vantage6 shouldn't be tied to a specific registry implementation like harbor – especially to parts of it that are outside of the OCI distribution spec.
FWIW, to deal with the issue for algorithms I might be developing on locally, on the same machine where my node is running (testing), I think naming the image with a local tag seems very acceptable. Although most people I believe use the MockClient. Perhaps using 'localhost/name-of-image' could be an idea, or local.vantage6.ai .. or anything the user can rest assure will not actually exist out there.
For server/node/support images, this is where my bias shows :). I never have to deal with this, as if I ever make changes to the node/server code, I always just test it locally with --mount-src. And if I push it somewhere, it's not to the official registry.
Perhaps related to this issue, I'd argue that running something like make base-image should limit itself to building the image. Pushing to a production registry seems unexpected from just running that command. Perhaps we can find a series of make incantations that work for everybody – local tags, make push, .. or whatever we might come up with :)
I think it's a good idea because the code is now too complex (and not so nice) for working with different registry types to check the versions
Perhaps related to this issue, I'd argue that running something like make base-image should limit itself to building the image. Pushing to a production registry seems unexpected from just running that command. Perhaps we can find a series of make incantations that work for everybody – local tags, make push, .. or whatever we might come up with :)
I'm fine with changing this but to me it's not really high-prio. Maybe easiest is to rename to build-and-push or so - of course splitting is also an option if you want to do it yourself ;-)
Description
At the moment we have a function
pull_if_newer
that to avoid overwriting (well, technically retagging, I believe) an "older" (upstream) image. See issue where I think this came from.IMHO, I don't think the added complexity to solely deal with this today, when multiple registries are typically used for algorithms, is worth the continued effort.
These are some of the reasons, as a I see it:
pull_if_newer
system was (?) implemented at a time when harbor seemed to be only registry in use by vantage6. These days I think users (myself included) are using other registries for algorirhtms like Azure Container Registry or GitHub Container Registry.FWIW, to deal with the issue for algorithms I might be developing on locally, on the same machine where my node is running (testing), I think naming the image with a local tag seems very acceptable. Although most people I believe use the MockClient. Perhaps using 'localhost/name-of-image' could be an idea, or local.vantage6.ai .. or anything the user can rest assure will not actually exist out there.
For server/node/support images, this is where my bias shows :). I never have to deal with this, as if I ever make changes to the node/server code, I always just test it locally with
--mount-src
. And if I push it somewhere, it's not to the official registry.Perhaps related to this issue, I'd argue that running something like
make base-image
should limit itself to building the image. Pushing to a production registry seems unexpected from just running that command. Perhaps we can find a series ofmake
incantations that work for everybody – local tags,make push
, .. or whatever we might come up with :)Source code:
vantage6/vantage6-common/vantage6/common/docker/addons.py
Lines 66 to 311 in 2d7312d
The text was updated successfully, but these errors were encountered: