[09:33:33] what would it take to create a separate registry namespace in order to avoid accidental overlaps with production images? [09:59:46] dpogorzelski: o/ what I meant in the task could be resolved, in theory, having another dir like the "istio" one in the production-images repository (it also needs a related config-something.yaml file as well). If you check the README in the repo it is explained (a little), that should probably be enough and it will avoid a new repo [10:00:25] will check thx [10:00:49] so on ml-build you'll be able to just to docker-pkg -c config-machinelearning.yaml etc.. [10:01:06] still not 100% bullet-proof [10:01:36] but it should be less easy to accidentally build/push other images that are handled by the build2xxx hosts [10:02:20] if you check https://docker-registry.wikimedia.org/ there is also another namespace, the `releng` one, but that is handled via blubbler I believe [10:02:26] *blubber [10:02:48] it depends what others think it is best [10:03:10] cc: jayme claime akosiaris [10:05:22] I think I'm missing backscroll maybe... [10:09:25] we don't have a concept of 'namespace' in the registry in a way that it is bound to some authentication (apart from a snowflake for mw images). But we do have separate 'prefixes'...some of them on purpose, some of them forced on us by gitlab for example (repos/*) [10:15:14] jayme: yes prefixes, this is the idea [10:15:42] context in https://phabricator.wikimedia.org/T412524 and parent task [10:16:16] ml-build1001 will be used to build complex base ML images that require a ton of CPU/Memory/GPUs to be built basically [10:16:34] so ML is asking to be able to push the final result to the registry via docker-pkg [10:32:05] under some /ml/ prefix or something ? [10:42:02] yeah, TBD the name [10:42:19] the question is - do we want to keep in production-images, or a new repo? [10:42:32] this is the first non build2xxx host pushing images to the registry [10:54:19] In the task I suggested to try, as much as possible, to avoid building/pushing by accident the same images that are managed by build2xxx [10:54:44] so ideally a production-ml-images repo, brand new etc.., would be the super safe option [10:54:55] but having a new prefix in production-images would work too [10:55:09] (together with separate credentials etc.. of course) [10:55:16] thoughts? Preferences? [10:58:27] My preference, not that it counts for much, would be for a separate prefix (i.e. `/ml`)in the production-images repo. I don't think it should be too hard to avoid clobbering images that are managed by build2xxx [10:59:47] no please that counts a lot, I am trying to get consensus on what we all prefer/agree :) [11:00:08] so we are all on the same page an nobody is caught off guard [12:13:45] I also prefer a new prefix. It makes things easier on a number of ways [12:14:20] now as to whether the image definitions would be kept in the production-images repo or not. I think we can filter the images docker-pkg builds? [12:14:43] although I do see how that could break and we could end up not doing what we expected. [12:14:54] 🤔 [12:15:19] let's keep this easy to reason about. Different prefix, different repo. It should help avoid confusion and having to reason about it [12:27:21] +1 [12:27:50] wonderful: The nelm people proposed an alternative to go templates for writing charts! [12:28:04] not so wonderful: They chose typescript 🤦 [12:40:13] ok so both, a prefix + a new repo [15:04:42] jayme LOL. I was playing around with LXC this weekend and noticed they use https://schlachter.tech/solutions/pongo2-template-engine/ . Hopefully more go projects realize there is an alternative out there ;P [15:13:42] jayme: typescript isn't bad, and, the editor support is amazing [15:14:56] I would still have preferred python :) [15:21:51] we could use Pulumi ;)