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
