Thread: ci: update to freebsd 13.1 / remove minor versions from image names

Hi,

Freebsd 13.0, so far used by CI, is out of support. I've changed the
image to be built against 13.1, so we can switch to that.

I suspect it'd be better to remove the minor version numbers from the
image name, so that switches from 13.0 -> 13.1 don't require CI
changes. Any argument against?

I can also see an argument for not having 13 in the image name, given
that the image is CI specific anyway? But perhaps we might want to have
a 13 and a 14 image for some debugging issue?

Greetings,

Andres Freund

On Thu, 28 Jul 2022 at 11:57, Andres Freund <andres@anarazel.de> wrote:
>
> Hi,
>
> Freebsd 13.0, so far used by CI, is out of support. I've changed the
> image to be built against 13.1, so we can switch to that.
>
> I suspect it'd be better to remove the minor version numbers from the
> image name, so that switches from 13.0 -> 13.1 don't require CI
> changes. Any argument against?
>
> I can also see an argument for not having 13 in the image name, given
> that the image is CI specific anyway? But perhaps we might want to have
> a 13 and a 14 image for some debugging issue?

Has this change in the BSD configuration been applied today? I see
failures in the cfbot builds of 4 different patches [0..3] that all
fail in 033_replay_tsp_drops.pl with the same output:

---

# poll_query_until timed out executing this query:
# SELECT '0/40EAXXX' <= replay_lsn AND state = 'streaming'
# FROM pg_catalog.pg_stat_replication
# WHERE application_name IN ('standby2_WAL_LOG', 'walreceiver')
# expecting this output:
# t
# last actual query output:
#
# with stderr:
# Tests were run but no plan was declared and done_testing() was not seen.
# Looks like your test exited with 29 just after 1.
t/033_replay_tsp_drops.pl ............
Dubious, test returned 29 (wstat 7424, 0x1d00)
All 1 subtests passed

---

Kind regards,

Matthias van de Meent

[0] https://cirrus-ci.com/task/5147001137397760?logs=test_world#L2631-L2662
[1] https://cirrus-ci.com/task/4960990331666432?logs=test_world#L2631-L2662
[2] https://cirrus-ci.com/task/5012678384025600?logs=test_world#L2631-L2662
[3] https://cirrus-ci.com/task/5147001137397760?logs=test_world#L2631-L2662

Hi,

On July 28, 2022 7:29:43 PM GMT+02:00, Matthias van de Meent <boekewurm+postgres@gmail.com> wrote:
>On Thu, 28 Jul 2022 at 11:57, Andres Freund <andres@anarazel.de> wrote:
>>
>> Hi,
>>
>> Freebsd 13.0, so far used by CI, is out of support. I've changed the
>> image to be built against 13.1, so we can switch to that.
>>
>> I suspect it'd be better to remove the minor version numbers from the
>> image name, so that switches from 13.0 -> 13.1 don't require CI
>> changes. Any argument against?
>>
>> I can also see an argument for not having 13 in the image name, given
>> that the image is CI specific anyway? But perhaps we might want to have
>> a 13 and a 14 image for some debugging issue?
>
>Has this change in the BSD configuration been applied today? I see
>failures in the cfbot builds of 4 different patches [0..3] that all
>fail in 033_replay_tsp_drops.pl with the same output:

No, this hasn't yet been applied.


># poll_query_until timed out executing this query:
># SELECT '0/40EAXXX' <= replay_lsn AND state = 'streaming'
># FROM pg_catalog.pg_stat_replication
># WHERE application_name IN ('standby2_WAL_LOG', 'walreceiver')
># expecting this output:
># t
># last actual query output:
>#
># with stderr:
># Tests were run but no plan was declared and done_testing() was not seen.
># Looks like your test exited with 29 just after 1.
>t/033_replay_tsp_drops.pl ............
>Dubious, test returned 29 (wstat 7424, 0x1d00)
>All 1 subtests passed

That seems more likely related to the recent changes in this area.

Andres
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.

On Thu, 28 Jul 2022 at 19:31, Andres Freund <andres@anarazel.de> wrote:
>
> Hi,
>
> On July 28, 2022 7:29:43 PM GMT+02:00, Matthias van de Meent <boekewurm+postgres@gmail.com> wrote:
> >On Thu, 28 Jul 2022 at 11:57, Andres Freund <andres@anarazel.de> wrote:
> >>
> >> Hi,
> >>
> >> Freebsd 13.0, so far used by CI, is out of support. I've changed the
> >> image to be built against 13.1, so we can switch to that.
> >>
> >> I suspect it'd be better to remove the minor version numbers from the
> >> image name, so that switches from 13.0 -> 13.1 don't require CI
> >> changes. Any argument against?
> >>
> >> I can also see an argument for not having 13 in the image name, given
> >> that the image is CI specific anyway? But perhaps we might want to have
> >> a 13 and a 14 image for some debugging issue?
> >
> >Has this change in the BSD configuration been applied today? I see
> >failures in the cfbot builds of 4 different patches [0..3] that all
> >fail in 033_replay_tsp_drops.pl with the same output:
>
> No, this hasn't yet been applied.
>
> ># poll_query_until timed out executing this query:
> ># SELECT '0/40EAXXX' <= replay_lsn AND state = 'streaming'
> ># FROM pg_catalog.pg_stat_replication
> ># WHERE application_name IN ('standby2_WAL_LOG', 'walreceiver')
> ># expecting this output:
> ># t
> ># last actual query output:
> >#
> ># with stderr:
> ># Tests were run but no plan was declared and done_testing() was not seen.
> ># Looks like your test exited with 29 just after 1.
> >t/033_replay_tsp_drops.pl ............
> >Dubious, test returned 29 (wstat 7424, 0x1d00)
> >All 1 subtests passed
>
> That seems more likely related to the recent changes in this area.

Hmm, I should've looked further than just this, so I would've realised
that this was a new test. I guess I'll go bother Alvaro on the
relevant thread instead.

Thanks for the quick response.


Kind regards,

Matthias van de Meent

Hi,

On 2022-07-28 02:57:04 -0700, Andres Freund wrote:
> Freebsd 13.0, so far used by CI, is out of support. I've changed the
> image to be built against 13.1, so we can switch to that.

I pushed that bit.


> I suspect it'd be better to remove the minor version numbers from the
> image name, so that switches from 13.0 -> 13.1 don't require CI
> changes. Any argument against?

> I can also see an argument for not having 13 in the image name, given
> that the image is CI specific anyway? But perhaps we might want to have
> a 13 and a 14 image for some debugging issue?

But not yet this, as there've been no comments so far.

- Andres

On Mon, Aug 1, 2022 at 7:43 AM Andres Freund <andres@anarazel.de> wrote:
> On 2022-07-28 02:57:04 -0700, Andres Freund wrote:
> > Freebsd 13.0, so far used by CI, is out of support. I've changed the
> > image to be built against 13.1, so we can switch to that.
>
> I pushed that bit.

Thanks, belated +1.

> > I suspect it'd be better to remove the minor version numbers from the
> > image name, so that switches from 13.0 -> 13.1 don't require CI
> > changes. Any argument against?

Yeah, that makes sense; it'd remove the need for commits like that.
For comparison, the Debian image is Bullseye AKA 11.x without the x in
the name.

> > I can also see an argument for not having 13 in the image name, given
> > that the image is CI specific anyway? But perhaps we might want to have
> > a 13 and a 14 image for some debugging issue?

I'm not sure about this.  I could imagine a naming scheme that has
sensible options available as pg-ci-{debian,freebsd,...}-default, and
those images are currently the same as
pg-ci-{debian-11,freebsd-13,...} but can be re-pointed as appropriate
without having to modify the .cirrus.yml, and someone investigating a
problem where they really care about the major version could change
their .cirrus.yml to point to the versioned name.  And likewise for
Windows containers; I'm not sure I understand how Cirrus's macOS
images work, but maybe there too.  The problem would be if, for some
reason, you finish up needing to synchronise a change between the
.cirrus.yml file and the image (like, you need to run slightly
different commands for the build or something).  I don't have a
concrete example, but I have a strange feeling in my big toe that it'd
be better to state the major version explicitly, and have a few
available...

Hi,

On 2022-08-01 10:07:32 +1200, Thomas Munro wrote:
> > > I suspect it'd be better to remove the minor version numbers from the
> > > image name, so that switches from 13.0 -> 13.1 don't require CI
> > > changes. Any argument against?
> 
> Yeah, that makes sense; it'd remove the need for commits like that.
> For comparison, the Debian image is Bullseye AKA 11.x without the x in
> the name.

Cool, doing that in https://github.com/anarazel/pg-vm-images/pull/15

There's now "freebsd-13" and "netbsd-9-postgres", "openbsd-7-postgres". The
latter two include the -postgres because we have to generate the "base" image
ourselves, because neither net nor openbsd provide a gcp image themselves. Not
that we use net/openbsd images in PG itself yet (I'm about to merge
open/netbsd support in the meson branch though).


> > > I can also see an argument for not having 13 in the image name, given
> > > that the image is CI specific anyway? But perhaps we might want to have
> > > a 13 and a 14 image for some debugging issue?
> 
> I'm not sure about this.  I could imagine a naming scheme that has
> sensible options available as pg-ci-{debian,freebsd,...}-default, and
> those images are currently the same as
> pg-ci-{debian-11,freebsd-13,...} but can be re-pointed as appropriate
> without having to modify the .cirrus.yml, and someone investigating a
> problem where they really care about the major version could change
> their .cirrus.yml to point to the versioned name.

There's such a concept for gcp, namely "image families". But we already use
that for pg-ci-bullseye etc - each individual image has a name including the
date. There's only one level of families afaiu. We of course could manually
copy images, but that's probably not worth it (and would come with storage
costs).

E.g. pg-ci-bullseye currently points to pg-ci-bullseye-2022-07-31t21-31.


> I don't have a concrete example, but I have a strange feeling in my big toe
> that it'd be better to state the major version explicitly, and have a few
> available...

FWIW, at the moment all images are deleted after two weeks ([1]). We probably
can make that smarter and not delete the newest image for a family, even if
that image is older than two weeks. Not that the gcp API seems to make that
easy.

Greetings,

Andres Freund

[1] https://github.com/anarazel/pg-vm-images/blob/main/.cirrus.yml#L209

Hi,

On 2022-07-31 16:27:37 -0700, Andres Freund wrote:
> On 2022-08-01 10:07:32 +1200, Thomas Munro wrote:
> > > > I suspect it'd be better to remove the minor version numbers from the
> > > > image name, so that switches from 13.0 -> 13.1 don't require CI
> > > > changes. Any argument against?
> > 
> > Yeah, that makes sense; it'd remove the need for commits like that.
> > For comparison, the Debian image is Bullseye AKA 11.x without the x in
> > the name.
> 
> Cool, doing that in https://github.com/anarazel/pg-vm-images/pull/15

That worked, and now I've updated the PG .cirrus.yml to point to that.

Greetings,

Andres Freund