fedora-ci / messages

Clone
Source Code
GIT

#76 Add fedora-update artifact and schemas
Merged 4 years ago by mvadkert. Opened 4 years ago by adamwill.
fedora-ci/ adamwill/messages fedora-update-artifact  into  master

file added
+55 
@@ -0,0 +1,55 @@ 
 

+ {
 

+     "pipeline": {
 

+         "id": "openqa.Update-FEDORA-2019-6bda4c81f4.install_default_update_live.uefi.updates-workstation-live-iso.x86_64",
 

+         "name": "openqa.Update-FEDORA-2019-6bda4c81f4.install_default_update_live.uefi.updates-workstation-live-iso.x86_64"
 

+     },
 

+     "run": {
 

+         "url": "https://openqa.stg.fedoraproject.org/tests/583271",
 

+         "id": 583271,
 

+         "log": "https://openqa.stg.fedoraproject.org/tests/583271/file/autoinst-log.txt"
 

+     },
 

+     "version": "0.2.4",
 

+     "system": [
 

+         {
 

+             "variant": "Workstation",
 

+             "os": "fedora-29",
 

+             "architecture": "x86_64",
 

+             "provider": "openqa"
 

+         }
 

+     ],
 

+     "artifact": {
 

+         "release": {
 

+             "version": "29",
 

+             "name": "F29"
 

+         },
 

+         "type": "fedora-update",
 

+         "alias": "FEDORA-2019-6bda4c81f4",
 

+         "id": "sha256:246fd185570f27560e2f5b06817c2774ee4982fa732d015e70f05bf503307284",
 

+         "builds": [
 

+             {
 

+                 "nvr": "kernel-5.2.7-100.fc29"
 

+             },
 

+             {
 

+                 "nvr": "kernel-headers-5.2.7-100.fc29"
 

+             },
 

+             {
 

+                 "nvr": "kernel-tools-5.2.7-100.fc29"
 

+             }
 

+         ]
 

+     },
 

+     "contact": {
 

+         "name": "Fedora openQA",
 

+         "url": "https://openqa.stg.fedoraproject.org",
 

+         "docs": "https://fedoraproject.org/wiki/OpenQA",
 

+         "team": "Fedora QA",
 

+         "irc": "#fedora-qa",
 

+         "email": "qa-devel@lists.fedoraproject.org"
 

+     },
 

+     "test": {
 

+         "category": "validation",
 

+         "type": "install_default_update_live uefi updates-workstation-live-iso x86_64",
 

+         "namespace": "update",
 

+         "result": "passed"
 

+     },
 

+     "generated_at": "2019-08-08T16:40:18Z"
 

+ }

file added
+56 
@@ -0,0 +1,56 @@ 
 

+ {
 

+     "pipeline": {
 

+         "id": "openqa.Update-FEDORA-2019-e37c348348.install_default_update_netinst.64bit.updates-everything-boot-iso.x86_64",
 

+         "name": "openqa.Update-FEDORA-2019-e37c348348.install_default_update_netinst.64bit.updates-everything-boot-iso.x86_64"
 

+     },
 

+     "run": {
 

+         "url": "https://openqa.stg.fedoraproject.org/tests/583239",
 

+         "id": 583239,
 

+         "log": "https://openqa.stg.fedoraproject.org/tests/583239/file/autoinst-log.txt"
 

+     },
 

+     "version": "0.2.4",
 

+     "system": [
 

+         {
 

+             "os": "fedora-30",
 

+             "architecture": "x86_64",
 

+             "provider": "openqa"
 

+         }
 

+     ],
 

+     "artifact": {
 

+         "release": {
 

+             "version": "30",
 

+             "name": "F30"
 

+         },
 

+         "type": "fedora-update",
 

+         "alias": "FEDORA-2019-e37c348348",
 

+         "id": "sha256:53abded84bf881f4f674e3abb9cc2401de129a19a7f67de3e193dc708e62394a",
 

+         "builds": [
 

+             {
 

+                 "nvr": "kernel-5.2.7-200.fc30"
 

+             },
 

+             {
 

+                 "nvr": "kernel-headers-5.2.7-200.fc30"
 

+             },
 

+             {
 

+                 "nvr": "kernel-tools-5.2.7-200.fc30"
 

+             }
 

+         ]
 

+     },
 

+     "contact": {
 

+         "name": "Fedora openQA",
 

+         "url": "https://openqa.stg.fedoraproject.org",
 

+         "docs": "https://fedoraproject.org/wiki/OpenQA",
 

+         "team": "Fedora QA",
 

+         "irc": "#fedora-qa",
 

+         "email": "qa-devel@lists.fedoraproject.org"
 

+     },
 

+     "error": {
 

+         "reason": "parallel_failed"
 

+     },
 

+     "test": {
 

+         "category": "validation",
 

+         "type": "install_default_update_netinst 64bit updates-everything-boot-iso x86_64",
 

+         "namespace": "update"
 

+     },
 

+     "generated_at": "2019-08-08T16:10:13Z"
 

+ }

file added
+55 
@@ -0,0 +1,55 @@ 
 

+ {
 

+     "pipeline": {
 

+         "id": "openqa.Update-FEDORA-2019-6bda4c81f4.install_default_update_live.uefi.updates-workstation-live-iso.x86_64",
 

+         "name": "openqa.Update-FEDORA-2019-6bda4c81f4.install_default_update_live.uefi.updates-workstation-live-iso.x86_64"
 

+     },
 

+     "run": {
 

+         "url": "https://openqa.stg.fedoraproject.org/tests/583271",
 

+         "id": 583271,
 

+         "log": "https://openqa.stg.fedoraproject.org/tests/583271/file/autoinst-log.txt"
 

+     },
 

+     "version": "0.2.4",
 

+     "system": [
 

+         {
 

+             "variant": "Workstation",
 

+             "os": "fedora-29",
 

+             "architecture": "x86_64",
 

+             "provider": "openqa"
 

+         }
 

+     ],
 

+     "artifact": {
 

+         "release": {
 

+             "version": "29",
 

+             "name": "F29"
 

+         },
 

+         "type": "fedora-update",
 

+         "alias": "FEDORA-2019-6bda4c81f4",
 

+         "id": "",
 

+         "builds": [
 

+             {
 

+                 "nvr": "kernel-5.2.7-100.fc29"
 

+             },
 

+             {
 

+                 "nvr": "kernel-headers-5.2.7-100.fc29"
 

+             },
 

+             {
 

+                 "nvr": "kernel-tools-5.2.7-100.fc29"
 

+             }
 

+         ]
 

+     },
 

+     "contact": {
 

+         "name": "Fedora openQA",
 

+         "url": "https://openqa.stg.fedoraproject.org",
 

+         "docs": "https://fedoraproject.org/wiki/OpenQA",
 

+         "team": "Fedora QA",
 

+         "irc": "#fedora-qa",
 

+         "email": "qa-devel@lists.fedoraproject.org"
 

+     },
 

+     "test": {
 

+         "category": "validation",
 

+         "lifetime": 240,
 

+         "namespace": "update",
 

+         "type": "install_default_update_live uefi updates-workstation-live-iso x86_64"
 

+     },
 

+     "generated_at": "2019-08-08T15:42:19Z"
 

+ }

file modified
+2 -2 
@@ -20,9 +20,9 @@ 
 

      version:
 

          description:
 

              Version of the specification. Following semantic versioning
 

-             (https://semver.org/). Current version is 0.2.3.
 

+             (https://semver.org/). Current version is 0.2.4.
 

          examples:
 

-             - 0.2.3
 

+             - 0.2.4
 

          type: string
 

  

  type: object

file added
+42 
@@ -0,0 +1,42 @@ 
 

+ $id: fedora-update.test.complete
 

+ $schema: http://json-schema.org/draft-07/schema#
 

+ 

+ description:
 

+     Testing of the update has been completed.
 

+     This is a mandatory message.
 

+ 

+ properties:
 

+     contact:
 

+         $ref: contact.json
 

+     run:
 

+         $ref: run.json
 

+     artifact:
 

+         $ref: fedora-update.json
 

+     pipeline:
 

+         $ref: pipeline.json
 

+     test:
 

+         allOf:
 

+           - $ref: test-common.json
 

+           - $ref: test-complete.json
 

+     notification:
 

+         $ref: notification.json
 

+     system:
 

+         type: array
 

+         items:
 

+             $ref: system.json
 

+     generated_at:
 

+         $ref: common.json#properties/generated_at
 

+     version:
 

+         $ref: common.json#properties/version
 

+ 

+ required:
 

+     - contact
 

+     - run
 

+     - artifact
 

+     - pipeline
 

+     - test
 

+     - system
 

+     - generated_at
 

+     - version
 

+ 

+ type: object

file added
+40 
@@ -0,0 +1,40 @@ 
 

+ $id: fedora-update.test.error
 

+ $schema: http://json-schema.org/draft-07/schema#
 

+ 

+ description:
 

+     Testing has aborted, it was not finished, e.g. because of infrastructure
 

+     error, CI system error, etc. Note that a test failure is not an error.
 

+     Test failures should be exposed under the fedora-update.test.complete
 

+     topic. This is a mandatory message.
 

+ 

+ properties:
 

+     contact:
 

+         $ref: contact.json
 

+     run:
 

+         $ref: run.json
 

+     artifact:
 

+         $ref: fedora-update.json
 

+     pipeline:
 

+         $ref: pipeline.json
 

+     test:
 

+         $ref: test-common.json
 

+     error:
 

+         $ref: error.json
 

+     notification:
 

+         $ref: notification.json
 

+     generated_at:
 

+         $ref: common.json#properties/generated_at
 

+     version:
 

+         $ref: common.json#properties/version
 

+ 

+ required:
 

+     - contact
 

+     - run
 

+     - artifact
 

+     - pipeline
 

+     - test
 

+     - error
 

+     - generated_at
 

+     - version
 

+ 

+ type: object

file added
+33 
@@ -0,0 +1,33 @@ 
 

+ $id: fedora-update.test.queued
 

+ $schema: http://json-schema.org/draft-07/schema#
 

+ 

+ description:
 

+     Testing has been queued, but not started yet.
 

+     This is an optional message.
 

+ 

+ properties:
 

+     contact:
 

+         $ref: contact.json
 

+     run:
 

+         $ref: run.json
 

+     artifact:
 

+         $ref: fedora-update.json
 

+     pipeline:
 

+         $ref: pipeline.json
 

+     test:
 

+         $ref: test-common.json
 

+     generated_at:
 

+         $ref: common.json#properties/generated_at
 

+     version:
 

+         $ref: common.json#properties/version
 

+ 

+ required:
 

+     - contact
 

+     - run
 

+     - artifact
 

+     - pipeline
 

+     - test
 

+     - generated_at
 

+     - version
 

+ 

+ type: object

file added
+33 
@@ -0,0 +1,33 @@ 
 

+ $id: fedora-update.test.running
 

+ $schema: http://json-schema.org/draft-07/schema#
 

+ 

+ description:
 

+     Testing has been started and is in progress.
 

+     This is an optional message.
 

+ 

+ properties:
 

+     contact:
 

+         $ref: contact.json
 

+     run:
 

+         $ref: run.json
 

+     artifact:
 

+         $ref: fedora-update.json
 

+     pipeline:
 

+         $ref: pipeline.json
 

+     test:
 

+         $ref: test-common.json
 

+     generated_at:
 

+         $ref: common.json#properties/generated_at
 

+     version:
 

+         $ref: common.json#properties/version
 

+ 

+ required:
 

+     - contact
 

+     - run
 

+     - artifact
 

+     - pipeline
 

+     - test
 

+     - generated_at
 

+     - version
 

+ 

+ type: object

file added
+75 
@@ -0,0 +1,75 @@ 
 

+ htt$id: fedora-update
 

+ $schema: http://json-schema.org/draft-07/schema#
 

+ 

+ description:
 

+     Details about the Fedora update being tested.
 

+ 

+ properties:
 

+     type:
 

+         description:
 

+             Artifact type, in this case 'fedora-update'.
 

+         enum:
 

+             - fedora-update
 

+         type: string
 

+     alias:
 

+         description:
 

+             Alias of the update as provided by the update system
 

+         examples:
 

+             - FEDORA-2019-dc88f7f6ee
 

+         type: string
 

+     id:
 

+         description:
 

+             An identifier for the builds in the update. It should be computed
 

+             as the sha256 digest of the string produced by concatenating the
 

+             'nvr' values of all the builds in the update in alphabetical order,
 

+             with a 'sha256:' prefix
 

+         examples:
 

+             - sha256:df47e7e482d71dca07b86f70eaa7c52646ea808d8b87b0731370293893be2dbd
 

+         type: string
 

+     release:
 

+         description:
 

+             Information about the release the update is for. Format is similar
 

+             to the 'release' object in Bodhi fedora-messaging messages (not
 

+             all the properties defined there are defined here)
 

+         type: object
 

+         properties:
 

+             name:
 

+                 description:
 

+                     Name of the release, as provided by the update system
 

+                 examples:
 

+                     - F30
 

+                     - F31C
 

+                 type: string
 

+             version:
 

+                 description:
 

+                     Version of the release, as provided by the update system
 

+                 examples:
 

+                     - 29
 

+                     - 30
 

+                 type: string
 

+         required:
 

+             - name
 

+     builds:
 

+         description:
 

+             A list of the builds in the update
 

+         type: array
 

+         items:
 

+             description:
 

+                 Information about a single build contained in the update
 

+             type: object
 

+             properties:
 

+                 nvr:
 

+                     description:
 

+                         NVR that identifies the build in the build system
 

+                     type: string
 

+             required:
 

+                 - nvr
 

+ 

+ required:
 

+     - type
 

+     - alias
 

+     - id
 

+     - release
 

+     - builds
 

+ 

+ type: object

This adds a new 'fedora-update' artifact and associated schemas.
This is for tests of updates from Fedora's update system,
currently Bodhi. An 'update' is a distinct concept from a package
or a Koji build; notably an 'update' can contain multiple Koji
builds, and the builds it contains can change. Testing an update
means testing all the builds in that update at the time the test
is run together.

Messages conforming to these schemas will be published by Fedora
openQA instances; the staging instance is already publishing such
messages. The examples are real messages, massaged a bit to fix
some mistakes I noticed in actually writing these schemas (at the
same time I have fixed the publishing code so future messages
will be correct).

openQA is not currently capable of publishing 'running' messages
so there is currently no example for that. I can fake one up if
it's necessary.

Signed-off-by: Adam Williamson awilliam@redhat.com

So, bikesheds to point your paintbrush at:

  • The name fedora-update doesn't really follow the convention of koji-build or productmd-compose, but I don't really like bodhi-update as I suspect even if we renamed or replaced Bodhi a lot of this would still be valid - updates would still need IDs and things. But I can see both sides on this, so we could possibly make it bodhi-update instead...

  • The release dict inside the artifact is based on the one in Bodhi's own messages, see this example. As you can see it contains a lot more than just name and version but I'm not entirely sure whether we want to include any more of the information in our schema. A fly in the ointment here is that the release dict isn't actually in Bodhi's schemas at all (though it's in the published messages). think that's a bug so I reported it, but it means we don't know which properties in that dict we can rely on always being present. @bowlofeggs , thoughts here? Another odd thing is that the release dict doesn't include any "type" - you can't tell if this is an RPM-y, container-y, or module-y thing, though that may be by design, it may be that in theory a Bodhi release can contain updates of multiple types and the type is a property of the update, and it's just a convention that in Fedora we keep different types of updates in different Bodhi releases. On that note, I would put content_type in the artifact properties here only that's another thing that's in current published messages but not in the Bodhi schemas.

  • I'm not sure whether I was expected to put all 'objects' in their own files, so for now, the release object and the objects included in the build array are just defined in-line in fedora-update.yaml. We can easily split them out into files and reference them if that's preferred.

@mvadkert

Edited 4 years ago by adamwill

Oh, and the items in the builds array aren't defined by reference to product-build or rpm-build because Bodhi just doesn't provide all the information required by those schemas.

Oh, one more note: the release version being a string is not a mistake. It is a string in the Bodhi schema. For Fedora (so far) the string will always represent an integer, but presumably Bodhi is guarding against the possibility of us releasing Fedora 35.3a1 down the line. :)
Edited 4 years ago by adamwill

rebased onto cb1347091068c951e56d5adb4f8f6edece5beb0b
4 years ago

A question, @adamwill - do you care about the mutability of a fedora-update?

Here's a scenario: an update is created, with two builds attached. Tests pass on it, published as messages and recorded as results in association with the fedora-update and its unique id. Later, a build is added to the update, and now the tests fail... but there's also an infrastructure failure that prevents the failure message from being published and recorded.

From Bodhi's point of view, the latest known tests still pass for the given fedora-update and things could be promoted accordingly.

I've been thinking recently that for these kind of mutable collections (both fedora-update and redhat-advisory, we need to use identifiers somehow derived from the id values of the content in the list). Here's an example: you might have a bodhi update with 3 rpm builds on it. The id of each koji build is the nvr. You could construct the id of the bodhi update to be the sha256 digest of the alphabetical concatenation of the id values of the builds (the nvrs).

When some test runs that wants to report results on a bodhi update as a whole, it would have to report it in terms of this constructed digest id.

resultsdb-updater would have to store the result in terms of the constructed digest id.

Bodhi, when querying about what tests pass and what tests fail, could query in terms of this constructed digest id.

With this, when someone changes builds on the advisory, the constructed digest id changes which means that all previously reported values would no longer be considered when trying to determine if the update should be gated or not.

yeah, I think that's an interesting question. If we go that route I would at least like to have both ids compulsory in the messages, as there are more ways to skin this cat than just using the 'constructed' ID, from the PoV of a consumer. I don't think I care which one is called what as long as both are guaranteed to be present.

I guess I might look at it like this: in theory any consumer that cares about this can tell what builds are in the update at the time it's about to make its decision, and compare that list against the list in the message it's basing the decision off. Yes? So from that PoV, this is just a kind of 'convenience feature' to make doing that a little easier.

I guess a related question here is whether the builds dict should be compulsory. I made it optional at present for entirely selfish reasons: openQA doesn't currently publish this and I'd have to do some work to make it do that =)

rebased onto fa4198c32a87a3565b5d85fa03add2a8653acc29
4 years ago

If we go that route I would at least like to have both ids compulsory in the messages, as there are more ways to skin this cat than just using the 'constructed' ID, from the PoV of a consumer

:+1:, maybe make the id the computed value and alias the Bodhi-friendly identifier. (I think Bodhi calls those things aliases internally.

I guess a related question here is whether the builds dict should be compulsory. I made it optional at present for entirely selfish reasons: openQA doesn't currently publish this and I'd have to do some work to make it do that =)

Hehe, yeah. I guess that works.

I can imagine a consumer wanting to have that builds list for convenience reasons (so they could, say, display results next to a build saying that "for this build, in the context of a certain bodhi update, this OpenQA test failed". I dunno if that's a strong enough rationale to make it required or not.

A question to facilitate the decision: if we want to change this later, is it harder to go from not-required to required or to go from required to not-required?

On Fri, 2019-08-09 at 02:30 +0000, Adam Williamson wrote:

think that's a bug so I reported it, but it means we
don't know which properties in that dict we can rely on always being
present. @bowlofeggs , thoughts here?

I replied on the bodhi issue - the schema is purposefully "thin" with
the idea that we add to it when we know we want to support it and have
also thought about how it should be done.

Another odd thing is that the release dict doesn't include any
"type" - you can't tell if this is an RPM-y, container-y, or module-y=20
thing, though that may be by design, it may be that in theory a
Bodhi release can contain updates of multiple types and the type is
a property of the update, and it's just a convention that in Fedora
we keep different types of updates in different Bodhi releases.

This happened because we originally were going to have multiple types
in the same release but later Fedora decided not to do that even though
the code was written to support that. So I would now like to make Bodhi
have a "type" on releases but it currently does not.

The schemas and examples look good to me. Just in the test.complete schema there seems to be a copy/paste typo:

Testing of the compose has been completed.

Regarding the builds field: I think it should be made mandatory so that it could be used as a unique identifier of the update. Including the hash of the sorted nvrs could be handy for easy comparison. +1 from me, but we can add it later if needed/desired.

@adamwill could we make this version 0.2.4 and also update the version in schemas/common.yaml. I have no better solution for updating the version ...

OK, thanks for the notes folks, I'll update this this week.

rebased onto 04b6f15072932bc3696afde1ecd2a304f5d5c857
4 years ago

rebased onto 7e81f04baa29aa3ad6d4a6dc9d8a51d5f9061fb8
4 years ago

OK, so I tweaked this to include all suggestions. Version is 0.2.4, builds is mandatory, the stray 'compose' reference in the test.complete schema is fixed, and I added @ralph 's suggested id as a mandatory field and renamed the existing id to alias.

rebased onto 34ddcdc
4 years ago

LGTM. Any other feedback?

I think ti is fine now. The only thing I see problematci is the test type, but we plan to revisit the test case name creating anyway. The thing is it contains spaces, what will be weird if it would be part of the resultsdb testcase name. On downstream we create resultsdb testcase name as the compount of <namespace>.<category>.<type>

Merging :)

Pull-Request has been merged by mvadkert
4 years ago

hum, I see. well, we could change the concatenation somehow, it's just tricky finding characters that won't be used by any test system in the values...

@adamwill not needed. I think this deficiency will disappear once we introduce a new way how to name the test runs ... I am planning to work on that in the next weeks
Metadata
None
No Tags
Changes Summary 9
+55
file added
examples/fedora-update.test.complete.json
+56
file added
examples/fedora-update.test.error.json
+55
file added
examples/fedora-update.test.queued.json
+2 -2
file changed
schemas/common.yaml
+42
file added
schemas/fedora-update.test.complete.yaml
+40
file added
schemas/fedora-update.test.error.yaml
+33
file added
schemas/fedora-update.test.queued.yaml
+33
file added
schemas/fedora-update.test.running.yaml
+75
file added
schemas/fedora-update.yaml
Powered by Pagure 5.13.3
Documentation • File an Issue • About • SSH Hostkey/Fingerprint
© Red Hat, Inc. and others.