From the meeting discussion today statements from @mikeb and @lsedlar

13:09:39         mbonnet | I don't think we have any dependency on update labels though
13:10:05         lsedlar | PDC could import composes without label fine, it already has nighlies without a label

We might need input from @ralph and @ausil on this one. @ralph, @ausil, can you please comment on this ticket?

:+1: As I understand it, labels are meant to signify special composes like "this one is the Beta" or "this one is RC 9000". The updates composes individually aren't special - they're all updates composes. So, I vote for --no-label.

from today's releng meeting:

13:27:25          mboddu | #info We are waiting on dgilmore input, so we are going to punt this for next week

as the atomic composes are not really updates but new releases we probably should use --label RC-<date stamp>.X as we did previously

The version that people want for Atomic trees is implemented in https://pagure.io/pungi/pull-request/791#.
As soon as a new Pungi release is made, we can switch to using that generator, and that will ignore the label.

This doesn't help us if we ever add Atomic qcow image creation to the actual updates compose (which would be nice). The image names will have some form of Update-20171025.1312 in the name where the ostree will have the 27.2017025.0 version.

Can you explain what the label is used for for updates composes? No one that I have talked to included the last 3 releng meetings knows why they are needed.

Well, for images there are the image_name_format and image_volid_formats parameters where we can tweak that.

Something like this should do the trick: image_name_format = '%(release_short)s-%(variant)s-%(disc_type)s-%(arch)s-%(version)s-%(date)s.%(respin)s.iso'

@puiterwijk - can you 100% confirm that (maybe with a test updates run in stage that also creates a ostree and a qcow)?

If so we can put this to rest.

@dustymabe - I will do so as soon as I get home (in about 4 hours or so). Will comment back when I have the answer.

@dustymabe - I will do so as soon as I get home (in about 4 hours or so). Will comment back when I have the answer.

thanks!

so now that we are producing f28 updates-testing content using bodhi with "version": "!OSTREE_VERSION_FROM_LABEL_DATE_TYPE_RESPIN",. We can see that the version that gets generated is not what we want:

ostree show fedora/28/x86_64/testing/atomic-host 
commit 14f21d3e994370d5b8bb5e938f343cb20ff930fb76489ec29d572249463d8a8c
Date:  2018-03-13 14:46:57 +0000
Version: 28_Update.20180313.1420
(no subject)

Found 1 signature:

  Signature made Tue 13 Mar 2018 02:47:04 PM UTC using RSA key ID E08E7E629DB62FB1
  Can't check signature: public key not found

I think we want 28_Update.20180313.1420 to be more like 28.20180313.n.0 for testing and 28.20180313.0 for updates. We can do something other than .n. for testing, but that's just one example.

We should probably switch to use the '!RELEASE_FROM_VERSION_COMPOSE_ID' so we can test what ostree versions get output with that code.

Note that Bodhi is still using OSTREE_VERSION_FROM_LABEL_DATE_TYPE_RESPIN, while I explicitly added VERSION_FROM_VERSION_DATE_RESPIN to do what you wanted.
So the Pungi code is there, but Bodhi config needs updating.

(We had tested this once before with f27 and then found out the OSTREE_VERSION_FROM_LABEL_DATE_TYPE_RESPIN behavior, remember?)

I can predict what the RELEASE_FROM_VERSION_COMPOSE_ID version would be: Fedora-28-updates-testing-20180314.0.

ok. I know there were a few iterations on adding an appropriate version macro to pungi so I wasn't sure which one we wanted to use. Is the proposal to use !VERSION_FROM_VERSION_DATE_RESPIN for ostree version and image_name_format = '%(release_short)s-%(variant)s-%(disc_type)s-%(arch)s-%(version)s-%(date)s.%(respin)s.iso' for the imagebuilds?

Can we add an AtomicHost image_build and ISO creation to the f28-u-t run so we can test out to see if we get expected results?

thanks. yes this was done in f28 cycle. Thanks everyone