On Wed, Oct 26, 2016 at 10:13 AM, Matthew Miller <mattdm@xxxxxxxxxxxxxxxxx> wrote: > On Tue, Oct 25, 2016 at 04:43:55PM -0500, Adam Miller wrote: >> > I'm not sure we should put base distro and distro version as the >> > primary distinguisher. As a user, it's the application (and possibly >> > major version of that application) that I care about. How about just: >> > registry.fedoraproject.org/httpd/24/http:latest >> > registry.fedoraproject.org/httpd/24/http:2.4.23 >> > with Fedora version indicated by labels? > > Or even just > > registry.fedoraproject.org/httpd/http:latest > > and *really* have the Fedora version as an implementation detail (just > the label, nothing in the path at all). Does that present any practical > problems that I'm not seeing? The main thing that concern I have is that with modularity there is going to be a concept of "base runtime" which will have a "generation" associated with it (most likely, the "generation" will share a name with the Fedora release number it was built from). Containers will be built on top of the base runtime and depending on the modules requirements, a module may select different generations of the base runtime and since there's plans to distribute modules (at least optionally) as containers, we'll likely need a way to distinguish between "generations" of the base runtime upon which a container was built. Of course, that might not be something we need to worry about in the event that the modularity metadata handles all the book keeping and just maps the appropriate information to a specific docker image tag. If that ends up being the case, I'd almost just say drop the first httpd and make it registry.fedoraproject.org/httpd:latest Thoughts? Should we bring this to the modularity group for review? -AdamM > > -- > Matthew Miller > <mattdm@xxxxxxxxxxxxxxxxx> > Fedora Project Leader > _______________________________________________ > cloud mailing list -- cloud@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to cloud-leave@xxxxxxxxxxxxxxxxxxxxxxx _______________________________________________ cloud mailing list -- cloud@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to cloud-leave@xxxxxxxxxxxxxxxxxxxxxxx
