[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



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 <ccoleman redhat com> 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 <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]