> On Jun 16, 2016, at 3:01 PM, Devan Goodwin <[email protected]> wrote: > >> On Thu, Jun 16, 2016 at 3:48 PM, Clayton Coleman <[email protected]> wrote: >> Generally we always pin tags to the previous version (so that we know >> exactly what we'd get). If we tagged them as v1.3.0, when we pushed >> new .alpha.X tags there's no guarantee everyone's deployments would >> get a new image deployed, which would make debugging very, very hard >> and prevent us from being able to guarantee the right update is >> delivered. > > Ok I'm content to drop this goal and assume you can't really setup an > env with ansible and alpha tags for time being.
Why can't we pass alpha tags to ansible? Shouldn't the tag be opaque? > > Does (1) sound ok? > >> >>> On Thu, Jun 16, 2016 at 2:09 PM, Devan Goodwin <[email protected]> wrote: >>>> On Thu, Jun 16, 2016 at 3:01 PM, Clayton Coleman <[email protected]> >>>> wrote: >>>> Can you explain #2 in more detail (why you want to be using 1.3.0 >>>> image tags, which you shouldn't be doing) >>> >>> Goal was to let people install the latest 1.3 alpha containers with >>> openshift-ansible, if that is not desirable though then I am happy to >>> scrap it as it's a bit problematic for a number of assumptions I've >>> tried to make to simplify things. You could probably still work around >>> and do it anyhow even if we don't do (2). >>> >>>> >>>>> On Thu, Jun 16, 2016 at 1:42 PM, Devan Goodwin <[email protected]> >>>>> wrote: >>>>> If I may add another request and summarize: >>>>> >>>>> (1) Add an additional v1.2 tag pointing to the latest released 1.2.x >>>>> image. Doing the same for 1.3 even in alpha stage would help make it a >>>>> supported option to install with openshift-ansible. This will allow >>>>> users to specify a version to install with less precision, and a >>>>> version/release they might actually know beforehand. >>>>> >>>>> (2) Add a v1.3.0 tag pointing to the latest alpha build. More >>>>> generally the rule here is to standardize on whatever is before the >>>>> first "-" in the output from "openshift version" as something we can >>>>> use to locate image tags, and rpm versions for use throughout the >>>>> cluster. I.e. v1.3.0-alpha.1-321-gb095e3a = safe to assume a tag of >>>>> v1.3.0 exists. >>>>> >>>>> >>>>>> On Wed, Jun 15, 2016 at 5:04 PM, Scott Dodson <[email protected]> wrote: >>>>>>> On Wed, Jun 15, 2016 at 1:45 PM, Devan Goodwin <[email protected]> >>>>>>> wrote: >>>>>>> Would it be possible to have a new tag included when we push official >>>>>>> release images out to docker hub: i.e. "v1.2" for the latest image in >>>>>>> the 1.2 stream. >>>>>>> >>>>>>> This would allow support for a new way to specify a generic release to >>>>>>> install in ansible inventories, rather than having to specify with >>>>>>> complete precision as you do today. (i.e. 3.1.1.6 in the OSE case) >>>>>>> >>>>>>> We've done this for OSE but I'd like to see it work for origin as well. >>>>>> >>>>>> +1 to this and it doesn't suffer from having to decide which versions >>>>>> are "stable" which seems to have been Clayton's objection when I asked >>>>>> for a "stable" tag to achieve the same end goal you're trying to >>>>>> achieve. >>>>>> >>>>>> Ultimately I'd settle for anything that got me a non ephemeral build, >>>>>> but v1.2 and v1.3 would be awesome. >>>>>> -- >>>>>> Scott >>>>> >>>>> _______________________________________________ >>>>> dev mailing list >>>>> [email protected] >>>>> http://lists.openshift.redhat.com/openshiftmm/listinfo/dev _______________________________________________ dev mailing list [email protected] http://lists.openshift.redhat.com/openshiftmm/listinfo/dev
