On Thu, Oct 27, 2016 at 11:19 AM, Matthew Miller <mattdm@xxxxxxxxxxxxxxxxx> wrote: > On Thu, Oct 27, 2016 at 08:55:33AM -0500, Adam Miller wrote: >> 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. > > *nod* I guess that makes the question mostly whether the generation is > something users need to fundamentally care about, or an insider detail. > > >> 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 I spent some time looking through the OSBS code yesterday and it's written in a such a way that is nice and flexible because we can write plugins that will provide us with whatever tagging strategy we can dream up. We can even have multiple tagging strategies aggregate, so effectively the same image can be tagged by many names based one whatever criteria we hammer out. > > I'd hate to make it top-level simply because modularity forgot to > handle this because we forgot to tell them... > > >> Thoughts? Should we bring this to the modularity group for review? > > Yes. Oh, for @-mentions in email. I'll find someone and bug them. Any update here? -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
