Container updates available in bodhi

[Clement Verna]

Dear all,

It is now possible to use bodhi to release a new container build. Currently
it is following the same flow as packages.

After a successful OSBS build, a bodhi update can be created. Fedpkg does
not yet support creating updates for containers [0], so you have to either
use bodhi web UI or the bodhi cli. For example

bodhi updates new --type enhancement --notes "cockpit update to version
181-2" cockpit-181-2.fc29

Once the update is pushed to testing, the container will be available in
the registry with the testing tag

podman pull registry.fedoraproject.org/f29/cockpit:testing

Then the container latest tag will be pushed to registry.fedoraproject.org,
if it receives +3 karma or waits 7 days in testing.

Thanks

[0] - https://pagure.io/fedpkg/issue/296

[Pierre-Yves Chibon]

Post by Clement Verna
Dear all,
It is now possible to use bodhi to release a new container build.
Currently it is following the same flow as packages.
After a successful OSBS build, a bodhi update can be created. Fedpkg does
not yet support creating updates for containers [0], so you have to either
use bodhi web UI or the bodhi cli. For example
    bodhi updates new --type enhancement --notes "cockpit update to
version 181-2"  cockpit-181-2.fc29
Once the update is pushed to testing, the container will be available in
the registry with the testing tag
    podman pull registry.fedoraproject.org/f29/cockpit:testing
Then the container latest tag will be pushed to
registry.fedoraproject.org, if it receives +3 karma or waits 7 days in
testing.
Thanks
[0] - https://pagure.io/fedpkg/issue/296

This is a great news!

Just to clarify for those like me who aren't playing with containers much.
What happened before? There was no updates of containers at all?
Assuming there was update, is this replacing the old workflow (in other words,
is it mandatory to use bodhi from now on to push update?)

Just to be sure I understand the impact of this properly :)

Thanks and kudos again to all those involved!
Pierre
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-***@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/***@lists.fedor

[Clement Verna]

Post by Pierre-Yves Chibon
This is a great news!
Just to clarify for those like me who aren't playing with containers much.
What happened before? There was no updates of containers at all?
Assuming there was update, is this replacing the old workflow (in other words,
is it mandatory to use bodhi from now on to push update?)

Great questions :)

Before releng was running a script every 2 weeks to push the candidate build to the production registry, this process has been difficult to maintain and broken for a little while so updates were not really happening lately.

With bodhi now supporting updates for container, this is now replacing the old workflow and gives back the control to the maintainer and frees up some time to releng

Post by Pierre-Yves Chibon
Just to be sure I understand the impact of this properly :)
Thanks and kudos again to all those involved!
Pierre

_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-***@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/deve

[Pierre-Yves Chibon]

Post by Clement Verna

Post by Pierre-Yves Chibon
This is a great news!
Just to clarify for those like me who aren't playing with containers much.
What happened before? There was no updates of containers at all?
Assuming there was update, is this replacing the old workflow (in other words,
is it mandatory to use bodhi from now on to push update?)

Great questions :)
Before releng was running a script every 2 weeks to push the candidate build to the production registry, this process has been difficult to maintain and broken for a little while so updates were not really happening lately.
With bodhi now supporting updates for container, this is now replacing the old workflow and gives back the control to the maintainer and frees up some time to releng

Cool, thanks for the answer.

Pierre
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-***@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/deve

[Petr Pisar]

Post by Clement Verna
After a successful OSBS build, a bodhi update can be created. Fedpkg does
not yet support creating updates for containers [0], so you have to either
use bodhi web UI or the bodhi cli. For example
bodhi updates new --type enhancement --notes "cockpit update to version
181-2" cockpit-181-2.fc29

This example refers to "cockpit-181-2.fc29" that is an rpms build. If
the intention is to create a container image update, shouldn't we refer
to a container build (e.g. "cockpit-0-9.f28container")? Or is there some
automatic lookup implemented?

And unrelated question: The koji build NVR does not contain dist-git
name space. Does that mean there will be race conditions between rpms
and container builds when the NVR string will conflict and preventing
from an successfull koji build?

-- Petr
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-***@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/

[Clement Verna]

Post by Clement Verna

Post by Clement Verna
After a successful OSBS build, a bodhi update can be created. Fedpkg does
not yet support creating updates for containers [0], so you have to

either

Post by Clement Verna
use bodhi web UI or the bodhi cli. For example
bodhi updates new --type enhancement --notes "cockpit update to

version

Post by Clement Verna
181-2" cockpit-181-2.fc29

This example refers to "cockpit-181-2.fc29" that is an rpms build. If
the intention is to create a container image update, shouldn't we refer
to a container build (e.g. "cockpit-0-9.f28container")? Or is there some
automatic lookup implemented?

Actually "cockpit-181-2.fc29" is a container build [0] and is tagged as
with the f29-container-* koji tags. Bodhi is then configured to root these
tags to the correct releas in that case the Fedora 29 Container release.

[0] - https://koji.fedoraproject.org/koji/buildinfo?buildID=1161976

Post by Clement Verna
And unrelated question: The koji build NVR does not contain dist-git
name space. Does that mean there will be race conditions between rpms
and container builds when the NVR string will conflict and preventing
from an successfull koji build?

OSBS grabs from koji the latest NVR available and increments the release
number, so we would not have identical NVR. But indeed that could mess up
the build of the rpm package if the release number was already used by
OSBS, that's something that needs to be improved.

Post by Clement Verna
-- Petr
_______________________________________________
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines

[Petr Pisar]

Post by Clement Verna

Post by Clement Verna

Post by Clement Verna
After a successful OSBS build, a bodhi update can be created. Fedpkg does
not yet support creating updates for containers [0], so you have to

either

Post by Clement Verna
use bodhi web UI or the bodhi cli. For example
bodhi updates new --type enhancement --notes "cockpit update to

version

Post by Clement Verna
181-2" cockpit-181-2.fc29

This example refers to "cockpit-181-2.fc29" that is an rpms build. If
the intention is to create a container image update, shouldn't we refer
to a container build (e.g. "cockpit-0-9.f28container")? Or is there some
automatic lookup implemented?

Actually "cockpit-181-2.fc29" is a container build [0]

Indeed. I saw 181-2 and checked 182-1. If only koji understands epochs
and name spaces.

-- Petr
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-***@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/***@lists.fedor

[Ken Dreyer]

Post by Clement Verna

Post by Petr Pisar
And unrelated question: The koji build NVR does not contain dist-git
name space. Does that mean there will be race conditions between rpms
and container builds when the NVR string will conflict and preventing
from an successfull koji build?

OSBS grabs from koji the latest NVR available and increments the release
number, so we would not have identical NVR. But indeed that could mess up the
build of the rpm package if the release number was already used by OSBS,
that's something that needs to be improved.

I think it's a good idea for Koji content generators to import builds
named with a particular suffix.

For OSBS, it makes sense to have all the container builds named with a
"-container" suffix. This is how we do it in another Koji+OSBS
instance I use. I guess there is nothing in OSBS (yet!) that enforces
this convention for the "BZComponent' or "com.redhat.component" labels
in the Dockerfile.

When we use name suffixes with content generator builds, we won't have
Release number collisions, or pollute "koji list-tagged --latest" or
"koji list-builds --package", or throw off getAverageBuildDuration,
etc.

- Ken
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-***@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/***@lists.f

[Clement Verna]

Post by Clement Verna

Post by Clement Verna

Post by Petr Pisar
And unrelated question: The koji build NVR does not contain dist-git
name space. Does that mean there will be race conditions between rpms
and container builds when the NVR string will conflict and preventing
from an successfull koji build?

OSBS grabs from koji the latest NVR available and increments the release
number, so we would not have identical NVR. But indeed that could mess

up the

Post by Clement Verna
build of the rpm package if the release number was already used by OSBS,
that's something that needs to be improved.

I think it's a good idea for Koji content generators to import builds
named with a particular suffix.
For OSBS, it makes sense to have all the container builds named with a
"-container" suffix. This is how we do it in another Koji+OSBS
instance I use. I guess there is nothing in OSBS (yet!) that enforces
this convention for the "BZComponent' or "com.redhat.component" labels
in the Dockerfile.
Yes I think that's a good idea, and will not be very difficult to put in

place. I have opened an issue [0] for the container SIG to implement that

[0] - https://pagure.io/ContainerSIG/container-sig/issue/20

Post by Clement Verna
When we use name suffixes with content generator builds, we won't have
Release number collisions, or pollute "koji list-tagged --latest" or
"koji list-builds --package", or throw off getAverageBuildDuration,
etc.
- Ken
_______________________________________________
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines