Clayton are you the right person to talk to to get a v1.2 tag pushed for whatever the latest 1.2 containers are? (and for 1.3 once it's released / going forward)
On Thu, Jun 16, 2016 at 5:03 PM, Clayton Coleman <[email protected]> wrote: > What you describe sounds very reasonable - I don't think building > clusters off latest should ever be a default. > > On Thu, Jun 16, 2016 at 3:37 PM, Devan Goodwin <[email protected]> wrote: >> On Thu, Jun 16, 2016 at 4:07 PM, Clayton Coleman <[email protected]> wrote: >>>> 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? >> >> If you specify them explicitly in inventory yes and I think I can keep >> that working, the issue here popped up when you don't specify one. >> >> In this case openshift-ansible grabs "latest" origin, which gets you >> 1.3 alpha. After this openshift-ansible code starts getting very >> confused in trying to maintain that environment because there's no >> clean way to map from what's reported in "openshift version" (i.e. >> v1.3.0-alpha.1-321-gb095e3a) to a tag we can use to pull on all >> current, and future hosts in the cluster. (as we don't want to >> configure them to pull 'latest', over time they would drift) >> >> However a simple solution to this would be to block attempts to >> install without specifying either openshift_image_tag or the new >> openshift_release (assuming we can implement (1) for origin). >> >> I'm part way through a sizable refactor trying to make sense of >> openshift_image_tag / openshift_pkg_version / new openshift_release / >> inventories with none of those set, across cluster install / >> maintenance / upgrade. I set out hoping to just focus on getting a >> version number for first master like "1.2.0", and then using that to >> assume image tag / rpm version and keying all other hosts off the >> version from first master. However I'm not 100% sure it will stay that >> simple at this point as it would have an impact on the use of tags >> like this in inventory. Need to think on this a bit more. >> >> However still could use (1) so we can support openshift_release for origin. _______________________________________________ dev mailing list [email protected] http://lists.openshift.redhat.com/openshiftmm/listinfo/dev
