[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Request for a new generic release image tag on Docker hub

On Thu, Jun 16, 2016 at 4:07 PM, Clayton Coleman <ccoleman redhat com> wrote:
>> On Jun 16, 2016, at 3:01 PM, Devan Goodwin <dgoodwin redhat com> wrote:
>>> On Thu, Jun 16, 2016 at 3:48 PM, Clayton Coleman <ccoleman redhat com> 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.

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]