[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



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 <dgoodwin redhat com> wrote:
> 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]