Announce: Fedora Layered Image Release

[Adam Miller]

Hello all,
On behalf of the Fedora Atomic WG[0] and Fedora Release
Engineering[1], I am pleased to announce the latest Fedora Layered
Image Release. This follows the latest Atomic Host Release that came
out today[2].

At this time the following Container Images are available in the
Fedora Registry.

Updated Base Images:

Note that the "latest" tag currently points to "27" and the "rawhide"
tag currently points to "28", if no tag is provided in your pull
command then it will always default to "latest"

registry.fedoraproject.org/fedora:latest
registry.fedoraproject.org/fedora:rawhide
registry.fedoraproject.org/fedora:27
registry.fedoraproject.org/fedora:26
registry.fedoraproject.org/fedora:25

Updated/Released Layered Images:

(Note: Layered Images are namespaced in the registry and at this time
we are releasing for the f26 and f27 namespaces.)

registry.fedoraproject.org/f27/kubernetes-master:0-2.f27container
registry.fedoraproject.org/f27/kubernetes-master:0
registry.fedoraproject.org/f27/kubernetes-master
registry.fedoraproject.org/f27/kubernetes-node:0-2.f27container
registry.fedoraproject.org/f27/kubernetes-node:0
registry.fedoraproject.org/f27/kubernetes-node
registry.fedoraproject.org/f27/kubernetes-scheduler:0-2.f27container,
registry.fedoraproject.org/f27/kubernetes-scheduler:0,
registry.fedoraproject.org/f27/kubernetes-scheduler,
registry.fedoraproject.org/f27/kubernetes-apiserver:0-2.f27container,
registry.fedoraproject.org/f27/kubernetes-apiserver:0,
registry.fedoraproject.org/f27/kubernetes-apiserver,
registry.fedoraproject.org/f27/kubernetes-proxy:0-2.f27container,
registry.fedoraproject.org/f27/kubernetes-proxy:0,
registry.fedoraproject.org/f27/kubernetes-proxy,
registry.fedoraproject.org/f27/kubernetes-controller-manager:0-2.f27container,
registry.fedoraproject.org/f27/kubernetes-controller-manager:0,
registry.fedoraproject.org/f27/kubernetes-controller-manager,
registry.fedoraproject.org/f27/kubernetes-kubelet:0-2.f27container,
registry.fedoraproject.org/f27/kubernetes-kubelet:0,
registry.fedoraproject.org/f27/kubernetes-kubelet


registry.fedoraproject.org/f26/kubernetes-scheduler:0-5.f26container
registry.fedoraproject.org/f26/kubernetes-scheduler:0
registry.fedoraproject.org/f26/kubernetes-scheduler
registry.fedoraproject.org/f26/nodejs:0-5.f26container
registry.fedoraproject.org/f26/nodejs:0
registry.fedoraproject.org/f26/nodejs
registry.fedoraproject.org/f26/kubernetes-apiserver:0-5.f26container
registry.fedoraproject.org/f26/kubernetes-apiserver:0
registry.fedoraproject.org/f26/kubernetes-apiserver
registry.fedoraproject.org/f26/tools:0-4.f26container
registry.fedoraproject.org/f26/tools:0
registry.fedoraproject.org/f26/tools
registry.fedoraproject.org/f26/httpd:0-1.f26container
registry.fedoraproject.org/f26/httpd:0
registry.fedoraproject.org/f26/httpd
registry.fedoraproject.org/f26/php:0-5.f26container
registry.fedoraproject.org/f26/php:0
registry.fedoraproject.org/f26/php
registry.fedoraproject.org/f26/kubernetes-proxy:0-5.f26container
registry.fedoraproject.org/f26/kubernetes-proxy:0
registry.fedoraproject.org/f26/kubernetes-proxy
registry.fedoraproject.org/f26/redis:0-5.f26container
registry.fedoraproject.org/f26/redis:0
registry.fedoraproject.org/f26/redis
registry.fedoraproject.org/f26/s2i-base:1-12.f26container
registry.fedoraproject.org/f26/s2i-base:1
registry.fedoraproject.org/f26/s2i-base
registry.fedoraproject.org/f26/etcd:0-9.f26container
registry.fedoraproject.org/f26/etcd:0
registry.fedoraproject.org/f26/etcd
registry.fedoraproject.org/f26/flannel:0-8.f26container
registry.fedoraproject.org/f26/flannel:0
registry.fedoraproject.org/f26/flannel
registry.fedoraproject.org/f26/kubernetes-controller-manager:0-5.f26container
registry.fedoraproject.org/f26/kubernetes-controller-manager:0
registry.fedoraproject.org/f26/kubernetes-controller-manager
registry.fedoraproject.org/f26/python-classroom:0.3-5.f26container
registry.fedoraproject.org/f26/python-classroom:0.3
registry.fedoraproject.org/f26/python-classroom
registry.fedoraproject.org/f26/mongodb:0-5.f26container
registry.fedoraproject.org/f26/mongodb:0
registry.fedoraproject.org/f26/mongodb
registry.fedoraproject.org/f26/mirrormanager2-mirrorlist:0.7.3-12.f26container
registry.fedoraproject.org/f26/mirrormanager2-mirrorlist:0.7.3
registry.fedoraproject.org/f26/mirrormanager2-mirrorlist
registry.fedoraproject.org/f26/waiverdb:0-7.f26container
registry.fedoraproject.org/f26/waiverdb:0
registry.fedoraproject.org/f26/waiverdb
registry.fedoraproject.org/f26/cockpit:135-15.f26container
registry.fedoraproject.org/f26/cockpit:135
registry.fedoraproject.org/f26/cockpit
registry.fedoraproject.org/f26/docker-distribution:2.5.1-5.f26container
registry.fedoraproject.org/f26/docker-distribution:2.5.1
registry.fedoraproject.org/f26/docker-distribution
registry.fedoraproject.org/f26/mariadb:10.1-13.f26container
registry.fedoraproject.org/f26/mariadb:10.1
registry.fedoraproject.org/f26/mariadb

Announce: Fedora Layered Image Release

[Adam Miller]

Hello all,
On behalf of the Fedora Atomic WG[0] and Fedora Release
Engineering[1], I am pleased to announce the latest Fedora Layered
Image Release. This follows the latest Atomic Host Release that came
out today[2].

At this time the following Container Images are available in the
Fedora Registry.

Updated Base Images:

(Note that the "latest" tag currently points to "26" and the "rawhide"
tag currently points to "28", if no tag is provided in your pull
command then it will always default to "latest")

registry.fedoraproject.org/fedora:latest
registry.fedoraproject.org/fedora:rawhide
registry.fedoraproject.org/fedora:28
registry.fedoraproject.org/fedora:27
registry.fedoraproject.org/fedora:26
registry.fedoraproject.org/fedora:25

registry.fedoraproject.org/fedora-minimal:latest
registry.fedoraproject.org/fedora-minimal:rawhide
registry.fedoraproject.org/fedora-minimal:28
registry.fedoraproject.org/fedora-minimal:27
registry.fedoraproject.org/fedora-minimal:26
registry.fedoraproject.org/fedora-minimal:25

Updated/Released Layered Images:

(Note: Layered Images are namespaced in the registry and at this time
we are releasing for the f25 and f26 namespaces.)

registry.fedoraproject.org/f25/kubernetes-scheduler:0.1-18.f25container
registry.fedoraproject.org/f25/kubernetes-scheduler:0.1
registry.fedoraproject.org/f25/kubernetes-scheduler
registry.fedoraproject.org/f25/nodejs:0-8.f25container
registry.fedoraproject.org/f25/nodejs:0
registry.fedoraproject.org/f25/nodejs
registry.fedoraproject.org/f25/kubernetes-apiserver:0.1-18.f25container
registry.fedoraproject.org/f25/kubernetes-apiserver:0.1
registry.fedoraproject.org/f25/kubernetes-apiserver
registry.fedoraproject.org/f25/httpd:0-10.f25container
registry.fedoraproject.org/f25/httpd:0
registry.fedoraproject.org/f25/httpd
registry.fedoraproject.org/f25/php:0-7.f25container
registry.fedoraproject.org/f25/php:0
registry.fedoraproject.org/f25/php
registry.fedoraproject.org/f25/container-engine:0-3.f25container
registry.fedoraproject.org/f25/container-engine:0
registry.fedoraproject.org/f25/container-engine
registry.fedoraproject.org/f25/kubernetes-proxy:0-18.f25container
registry.fedoraproject.org/f25/kubernetes-proxy:0
registry.fedoraproject.org/f25/kubernetes-proxy
registry.fedoraproject.org/f25/redis:0-8.f25container
registry.fedoraproject.org/f25/redis:0
registry.fedoraproject.org/f25/redis
registry.fedoraproject.org/f25/etcd:0.1-18.f25container
registry.fedoraproject.org/f25/etcd:0.1
registry.fedoraproject.org/f25/etcd
registry.fedoraproject.org/f25/kubernetes-controller-manager:0.1-18.f25container
registry.fedoraproject.org/f25/kubernetes-controller-manager:0.1
registry.fedoraproject.org/f25/kubernetes-controller-manager
registry.fedoraproject.org/f25/mongodb:0-7.f25container
registry.fedoraproject.org/f25/mongodb:0
registry.fedoraproject.org/f25/mongodb
registry.fedoraproject.org/f25/mirrormanager2-mirrorlist:0.7.3-10.f25container
registry.fedoraproject.org/f25/mirrormanager2-mirrorlist:0.7.3
registry.fedoraproject.org/f25/mirrormanager2-mirrorlist
registry.fedoraproject.org/f25/waiverdb:0-3.f25container
registry.fedoraproject.org/f25/waiverdb:0
registry.fedoraproject.org/f25/waiverdb
registry.fedoraproject.org/f25/cockpit:135-13.f25container
registry.fedoraproject.org/f25/cockpit:135
registry.fedoraproject.org/f25/cockpit
registry.fedoraproject.org/f25/mariadb:10.1-16.f25container
registry.fedoraproject.org/f25/mariadb:10.1
registry.fedoraproject.org/f25/mariadb
registry.fedoraproject.org/f25/ruby:0-11.f25docker
registry.fedoraproject.org/f25/ruby:0
registry.fedoraproject.org/f25/ruby
registry.fedoraproject.org/f25/s2i-base:1-16.f25container
registry.fedoraproject.org/f25/s2i-base:1
registry.fedoraproject.org/f25/s2i-base
registry.fedoraproject.org/f25/flannel:0.1-15.f25container
registry.fedoraproject.org/f25/flannel:0.1
registry.fedoraproject.org/f25/flannel
registry.fedoraproject.org/f25/kubernetes-master:0.1-20.f25container
registry.fedoraproject.org/f25/kubernetes-master:0.1
registry.fedoraproject.org/f25/kubernetes-master
registry.fedoraproject.org/f25/toolchain:1-14.f25container
registry.fedoraproject.org/f25/toolchain:1
registry.fedoraproject.org/f25/toolchain
registry.fedoraproject.org/f25/kubernetes-node:0.1-17.f25container
registry.fedoraproject.org/f25/kubernetes-node:0.1
registry.fedoraproject.org/f25/kubernetes-node
registry.fedoraproject.org/f25/kubernetes-kubelet:0-17.f25container
registry.fedoraproject.org/f25/kubernetes-kubelet:0
registry.fedoraproject.org/f25/kubernetes-kubelet
registry.fedoraproject.org/f25/docker:0-7.f25container
registry.fedoraproject.org/f25/docker:0
registry.fedoraproject.org/f25/docker


registry.fedoraproject.org/f26/kubernetes-scheduler:0-2.f26container
registry.fedoraproject.org/f26/kubernetes-scheduler:0
registry.fedoraproject.org/f26/kubernetes-scheduler
registry.fedoraproject.org/f26/nodejs:0-3.f26container
registry.fedoraproject.org/f26/nodejs:0
registry.fedoraproject.org/f26/nodejs

Announce: Fedora Layered Image Release

[Adam Miller]

Hello all,
On behalf of the Fedora Atomic WG[0] and Fedora Release
Engineering[1], I am pleased to announce the latest Fedora Layered
Image Release. This follows the latest Atomic Host Release that came
out today[2].

At this time the following Container Images are available in the
Fedora Registry.

Updated Base Images:

(Note that the "latest" tag currently points to "25" and the "rawhide"
tag currently points to "27", if no tag is provided in your pull
command then it will always default to "latest")

registry.fedoraproject.org/fedora:latest
registry.fedoraproject.org/fedora:rawhide
registry.fedoraproject.org/fedora:27
registry.fedoraproject.org/fedora:26
registry.fedoraproject.org/fedora:25

Updated/Released Layered Images:

(Note: Layered Images are namespaced in the registry and at this time
we are releasing for the f25 and f26 namespaces.)

registry.fedoraproject.org/f25/ruby:0-10.f25docker
registry.fedoraproject.org/f25/ruby:0
registry.fedoraproject.org/f25/ruby
registry.fedoraproject.org/f25/kubernetes-master:0.1-18.f25container
registry.fedoraproject.org/f25/kubernetes-master:0.1
registry.fedoraproject.org/f25/kubernetes-master
registry.fedoraproject.org/f25/kubernetes-kubelet:0-16.f25container
registry.fedoraproject.org/f25/kubernetes-kubelet:0
registry.fedoraproject.org/f25/kubernetes-kubelet
registry.fedoraproject.org/f25/redis:0-7.f25container
registry.fedoraproject.org/f25/redis:0
registry.fedoraproject.org/f25/redis
registry.fedoraproject.org/f25/etcd:0.1-17.f25container
registry.fedoraproject.org/f25/etcd:0.1
registry.fedoraproject.org/f25/etcd
registry.fedoraproject.org/f25/container-engine:0-2.f25container
registry.fedoraproject.org/f25/container-engine:0
registry.fedoraproject.org/f25/container-engine
registry.fedoraproject.org/f25/cockpit:135-12.f25container
registry.fedoraproject.org/f25/cockpit:135
registry.fedoraproject.org/f25/cockpit
registry.fedoraproject.org/f25/postgresql:0-1.f25docker
registry.fedoraproject.org/f25/postgresql:0
registry.fedoraproject.org/f25/postgresql
registry.fedoraproject.org/f25/postgresql:0-1.f25docker
registry.fedoraproject.org/f25/postgresql:0
registry.fedoraproject.org/f25/postgresql
registry.fedoraproject.org/f25/mongodb:0-6.f25container
registry.fedoraproject.org/f25/mongodb:0
registry.fedoraproject.org/f25/mongodb
registry.fedoraproject.org/f25/php:0-6.f25container
registry.fedoraproject.org/f25/php:0
registry.fedoraproject.org/f25/php
registry.fedoraproject.org/f25/s2i-base:1-15.f25container
registry.fedoraproject.org/f25/s2i-base:1
registry.fedoraproject.org/f25/s2i-base
registry.fedoraproject.org/f25/docker:0-6.f25container
registry.fedoraproject.org/f25/docker:0
registry.fedoraproject.org/f25/docker
registry.fedoraproject.org/f25/nodejs:0-7.f25container
registry.fedoraproject.org/f25/nodejs:0
registry.fedoraproject.org/f25/nodejs
registry.fedoraproject.org/f25/kubernetes-controller-manager:0.1-17.f25container
registry.fedoraproject.org/f25/kubernetes-controller-manager:0.1
registry.fedoraproject.org/f25/kubernetes-controller-manager
registry.fedoraproject.org/f25/mariadb:10.1-15.f25container
registry.fedoraproject.org/f25/mariadb:10.1
registry.fedoraproject.org/f25/mariadb
registry.fedoraproject.org/f25/kubernetes-scheduler:0.1-17.f25container
registry.fedoraproject.org/f25/kubernetes-scheduler:0.1
registry.fedoraproject.org/f25/kubernetes-scheduler
registry.fedoraproject.org/f25/kubernetes-node:0.1-16.f25container
registry.fedoraproject.org/f25/kubernetes-node:0.1
registry.fedoraproject.org/f25/kubernetes-node
registry.fedoraproject.org/f25/kubernetes-proxy:0-17.f25container
registry.fedoraproject.org/f25/kubernetes-proxy:0
registry.fedoraproject.org/f25/kubernetes-proxy
registry.fedoraproject.org/f25/waiverdb:0-2.f25container
registry.fedoraproject.org/f25/waiverdb:0
registry.fedoraproject.org/f25/waiverdb
registry.fedoraproject.org/f25/httpd:0-9.f25container
registry.fedoraproject.org/f25/httpd:0
registry.fedoraproject.org/f25/httpd
registry.fedoraproject.org/f25/toolchain:1-13.f25container
registry.fedoraproject.org/f25/toolchain:1
registry.fedoraproject.org/f25/toolchain
registry.fedoraproject.org/f25/kubernetes-apiserver:0.1-17.f25container
registry.fedoraproject.org/f25/kubernetes-apiserver:0.1
registry.fedoraproject.org/f25/kubernetes-apiserver
registry.fedoraproject.org/f25/mirrormanager2-mirrorlist:0.7.3-9.f25container
registry.fedoraproject.org/f25/mirrormanager2-mirrorlist:0.7.3
registry.fedoraproject.org/f25/mirrormanager2-mirrorlist
registry.fedoraproject.org/f25/flannel:0.1-15.f25container
registry.fedoraproject.org/f25/flannel:0.1
registry.fedoraproject.org/f25/flannel


registry.fedoraproject.org/f26/nodejs:0-2.f26container
registry.fedoraproject.org/f26/nodejs:0
registry.fedoraproject.org/f26/nodejs
registry.fedoraproject.org/f26/mariadb:10.1-10.f26container
registry.fedoraproject.org/f26/mariadb:10.1
registry.fedoraproject.org/f26/mariadb
registry.fedoraproject.org/f26/redis:0-2.f26container

[atomic-wg] Issue #295: Start using new mailing list/IRC channel around f26 release time

[Adam Miller]

maxamillion added a new comment to an issue you are following:
``
+1 to jberkus' proposal. :thumbsup: 
``

To reply, visit the link below or just reply to this email
https://pagure.io/atomic-wg/issue/295
___
cloud mailing list -- cloud@lists.fedoraproject.org
To unsubscribe send an email to cloud-le...@lists.fedoraproject.org

[atomic-wg] Issue #297: Disable deltarpms in the Fedora base docker image

[Adam Miller]

The issue: `Disable deltarpms in the Fedora base docker image` of project: 
`atomic-wg` has been assigned to `maxamillion` by maxamillion.

https://pagure.io/atomic-wg/issue/297
___
cloud mailing list -- cloud@lists.fedoraproject.org
To unsubscribe send an email to cloud-le...@lists.fedoraproject.org

[atomic-wg] Issue #215: Move redis httpd container image from Fedora-Dockerfiles GitHub into DistGit

[Adam Miller]

The issue: `Move redis httpd container image from Fedora-Dockerfiles GitHub 
into DistGit` of project: `atomic-wg` has been reset by maxamillion.

https://pagure.io/atomic-wg/issue/215
___
cloud mailing list -- cloud@lists.fedoraproject.org
To unsubscribe send an email to cloud-le...@lists.fedoraproject.org

[atomic-wg] Issue #295: Start using new mailing list/IRC channel around f26 release time

[Adam Miller]

maxamillion added a new comment to an issue you are following:
``
I'm +1 to this

Also note, that I created `ato...@lists.fedoraproject.org` months ago and 
discussed it at one of the meetings but we never really moved over. It's there, 
it's just "inactive" because there's been zero email to it so the Hyperkitty 
webUI hides it by default in the UI.
``

To reply, visit the link below or just reply to this email
https://pagure.io/atomic-wg/issue/295
___
cloud mailing list -- cloud@lists.fedoraproject.org
To unsubscribe send an email to cloud-le...@lists.fedoraproject.org

[atomic-wg] Issue #284: Fedora OSBS RFE: install go-md2man to buildroot image

[Adam Miller]

maxamillion added a new comment to an issue you are following:
``
I meant to update this ticket, I'll get this out to the Infra as soon as we're 
out of Infrastructure Freeze. (Post Fedora 26 Release, so later this week)
``

To reply, visit the link below or just reply to this email
https://pagure.io/atomic-wg/issue/284
___
cloud mailing list -- cloud@lists.fedoraproject.org
To unsubscribe send an email to cloud-le...@lists.fedoraproject.org

Announce: Fedora Layered Image Release

[Adam Miller]

Hello all,
On behalf of the Fedora Atomic WG[0] and Fedora Release
Engineering[1], I am pleased to announce the latest Fedora Layered
Image Release. This follows the latest Atomic Host Release that came
out today[2].

At this time the following Container Images are available in the
Fedora Registry.

Updated Base Images:

(Note that the "latest" tag currently points to "25" and the "rawhide"
tag currently points to "27", if no tag is provided in your pull
command then it will always default to "latest")

registry.fedoraproject.org/fedora:latest
registry.fedoraproject.org/fedora:rawhide
registry.fedoraproject.org/fedora:27
registry.fedoraproject.org/fedora:26
registry.fedoraproject.org/fedora:25


Updated Layered Images:

(Note: Layered Images are namespaced in the registry and at this time
we are only releasing for the f25 namespace.)

registry.fedoraproject.org/f25/ruby:0-9.f25docker
registry.fedoraproject.org/f25/ruby:0
registry.fedoraproject.org/f25/ruby
registry.fedoraproject.org/f25/kubernetes-master:0.1-16.f25container
registry.fedoraproject.org/f25/kubernetes-master:0.1
registry.fedoraproject.org/f25/kubernetes-master
registry.fedoraproject.org/f25/kubernetes-kubelet:0-15.f25container
registry.fedoraproject.org/f25/kubernetes-kubelet:0
registry.fedoraproject.org/f25/kubernetes-kubelet
registry.fedoraproject.org/f25/redis:0-6.f25container
registry.fedoraproject.org/f25/redis:0
registry.fedoraproject.org/f25/redis
registry.fedoraproject.org/f25/etcd:0.1-16.f25container
registry.fedoraproject.org/f25/etcd:0.1
registry.fedoraproject.org/f25/etcd
registry.fedoraproject.org/f25/cockpit:135-11.f25container
registry.fedoraproject.org/f25/cockpit:135
registry.fedoraproject.org/f25/cockpit
registry.fedoraproject.org/f25/mongodb:0-6.f25container
registry.fedoraproject.org/f25/mongodb:0
registry.fedoraproject.org/f25/mongodb
registry.fedoraproject.org/f25/php:0-5.f25container
registry.fedoraproject.org/f25/php:0
registry.fedoraproject.org/f25/php
registry.fedoraproject.org/f25/s2i-base:1-14.f25container
registry.fedoraproject.org/f25/s2i-base:1
registry.fedoraproject.org/f25/s2i-base
registry.fedoraproject.org/f25/nodejs:0-6.f25container
registry.fedoraproject.org/f25/nodejs:0
registry.fedoraproject.org/f25/nodejs
registry.fedoraproject.org/f25/kubernetes-controller-manager:0.1-15.f25container
registry.fedoraproject.org/f25/kubernetes-controller-manager:0.1
registry.fedoraproject.org/f25/kubernetes-controller-manager
registry.fedoraproject.org/f25/mariadb:10.1-14.f25container
registry.fedoraproject.org/f25/mariadb:10.1
registry.fedoraproject.org/f25/mariadb
registry.fedoraproject.org/f25/kubernetes-scheduler:0.1-15.f25container
registry.fedoraproject.org/f25/kubernetes-scheduler:0.1
registry.fedoraproject.org/f25/kubernetes-scheduler
registry.fedoraproject.org/f25/kubernetes-node:0.1-15.f25container
registry.fedoraproject.org/f25/kubernetes-node:0.1
registry.fedoraproject.org/f25/kubernetes-node
registry.fedoraproject.org/f25/kubernetes-proxy:0-15.f25container
registry.fedoraproject.org/f25/kubernetes-proxy:0
registry.fedoraproject.org/f25/kubernetes-proxy
registry.fedoraproject.org/f25/httpd:0-8.f25container
registry.fedoraproject.org/f25/httpd:0
registry.fedoraproject.org/f25/httpd
registry.fedoraproject.org/f25/toolchain:1-12.f25container
registry.fedoraproject.org/f25/toolchain:1
registry.fedoraproject.org/f25/toolchain
registry.fedoraproject.org/f25/kubernetes-apiserver:0.1-15.f25container
registry.fedoraproject.org/f25/kubernetes-apiserver:0.1
registry.fedoraproject.org/f25/kubernetes-apiserver
registry.fedoraproject.org/f25/mirrormanager2-mirrorlist:0.7.3-8.f25container
registry.fedoraproject.org/f25/mirrormanager2-mirrorlist:0.7.3
registry.fedoraproject.org/f25/mirrormanager2-mirrorlist
registry.fedoraproject.org/f25/flannel:0.1-14.f25container
registry.fedoraproject.org/f25/flannel:0.1
registry.fedoraproject.org/f25/flannel

The source of this content is provided in DistGit which can easily be
searched via the container pkgdb namespace[3].

As always, we welcome feedback and would encourage anyone interested
to come join the Fedora Atomic WG[0] as we continue to iterate on
integrating the Project Atomic[4] family of technologies into Fedora.
Anyone interested in contributing Container Images, please feel free
to join in and submit one for Review[5][6].

Thank you,
-AdamM

[0] - https://pagure.io/atomic-wg
[1] - https://docs.pagure.org/releng/
[2] - 
https://lists.fedoraproject.org/archives/list/cloud@lists.fedoraproject.org/thread/CCYVMZIO4YLJC4QMW2PGY7TILTCHC7G5/
[3] - https://admin.fedoraproject.org/pkgdb/packages/container/%2A/
[4] - https://www.projectatomic.io/
[5] - https://fedoraproject.org/wiki/Container:Review_Process
[6] - https://fedoraproject.org/wiki/Container:Guidelines
___
cloud mailing list -- cloud@lists.fedoraproject.org
To unsubscribe send an email to cloud-le...@lists.fedoraproject.org

[atomic-wg] Issue #276: Set architecture label in the base container image

[Adam Miller]

maxamillion added a new comment to an issue you are following:
``
PR Submitted to imagefactory to add this functionality. 
https://github.com/redhat-imaging/imagefactory/pull/402

Once merged, we'll get the configurations in place with 
[pungi-fedora](https://pagure.io/pungi-fedora)
``

To reply, visit the link below or just reply to this email
https://pagure.io/atomic-wg/issue/276
___
cloud mailing list -- cloud@lists.fedoraproject.org
To unsubscribe send an email to cloud-le...@lists.fedoraproject.org

Announce: Fedora Layered Image Release

[Adam Miller]

Hello all,
On behalf of the Fedora Atomic WG[0] and Fedora Release
Engineering[1], I am pleased to announce the latest Fedora Layered
Image Release. This follows the latest Atomic Host Release that came
out yesterday[2].

At this time the following Container Images are available in the
Fedora Registry.

Updated Base Images:

(Note that the "latest" tag currently points to "25" and the "rawhide"
tag currently points to "27", if no tag is provided in your pull
command then it will always default to "latest")

registry.fedoraproject.org/fedora:latest
registry.fedoraproject.org/fedora:rawhide
registry.fedoraproject.org/fedora:27
registry.fedoraproject.org/fedora:26
registry.fedoraproject.org/fedora:25


Updated Layered Images:

(Note: Layered Images are namespaced in the registry and at this time
we are only releasing for the f25 namespace.)

registry.fedoraproject.org/f25/ruby:0-8.f25docker
registry.fedoraproject.org/f25/ruby:0
registry.fedoraproject.org/f25/ruby
registry.fedoraproject.org/f25/kubernetes-master:0.1-16.f25container
registry.fedoraproject.org/f25/kubernetes-master:0.1
registry.fedoraproject.org/f25/kubernetes-master
registry.fedoraproject.org/f25/kubernetes-kubelet:0-14.f25container
registry.fedoraproject.org/f25/kubernetes-kubelet:0
registry.fedoraproject.org/f25/kubernetes-kubelet
registry.fedoraproject.org/f25/redis:0-5.f25container
registry.fedoraproject.org/f25/redis:0
registry.fedoraproject.org/f25/redis
registry.fedoraproject.org/f25/etcd:0.1-15.f25container
registry.fedoraproject.org/f25/etcd:0.1
registry.fedoraproject.org/f25/etcd
registry.fedoraproject.org/f25/cockpit:135-10.f25container
registry.fedoraproject.org/f25/cockpit:135
registry.fedoraproject.org/f25/cockpit
registry.fedoraproject.org/f25/mongodb:0-5.f25container
registry.fedoraproject.org/f25/mongodb:0
registry.fedoraproject.org/f25/mongodb
registry.fedoraproject.org/f25/php:0-4.f25container
registry.fedoraproject.org/f25/php:0
registry.fedoraproject.org/f25/php
registry.fedoraproject.org/f25/s2i-base:1-13.f25container
registry.fedoraproject.org/f25/s2i-base:1
registry.fedoraproject.org/f25/s2i-base
registry.fedoraproject.org/f25/nodejs:0-5.f25container
registry.fedoraproject.org/f25/nodejs:0
registry.fedoraproject.org/f25/nodejs
registry.fedoraproject.org/f25/kubernetes-controller-manager:0.1-15.f25container
registry.fedoraproject.org/f25/kubernetes-controller-manager:0.1
registry.fedoraproject.org/f25/kubernetes-controller-manager
registry.fedoraproject.org/f25/mariadb:10.1-13.f25container
registry.fedoraproject.org/f25/mariadb:10.1
registry.fedoraproject.org/f25/mariadb
registry.fedoraproject.org/f25/kubernetes-scheduler:0.1-15.f25container
registry.fedoraproject.org/f25/kubernetes-scheduler:0.1
registry.fedoraproject.org/f25/kubernetes-scheduler
registry.fedoraproject.org/f25/kubernetes-node:0.1-14.f25container
registry.fedoraproject.org/f25/kubernetes-node:0.1
registry.fedoraproject.org/f25/kubernetes-node
registry.fedoraproject.org/f25/kubernetes-proxy:0-15.f25container
registry.fedoraproject.org/f25/kubernetes-proxy:0
registry.fedoraproject.org/f25/kubernetes-proxy
registry.fedoraproject.org/f25/httpd:0-7.f25container
registry.fedoraproject.org/f25/httpd:0
registry.fedoraproject.org/f25/httpd
registry.fedoraproject.org/f25/toolchain:1-11.f25container
registry.fedoraproject.org/f25/toolchain:1
registry.fedoraproject.org/f25/toolchain
registry.fedoraproject.org/f25/kubernetes-apiserver:0.1-15.f25container
registry.fedoraproject.org/f25/kubernetes-apiserver:0.1
registry.fedoraproject.org/f25/kubernetes-apiserver
registry.fedoraproject.org/f25/mirrormanager2-mirrorlist:0.7.3-7.f25container
registry.fedoraproject.org/f25/mirrormanager2-mirrorlist:0.7.3
registry.fedoraproject.org/f25/mirrormanager2-mirrorlist
registry.fedoraproject.org/f25/flannel:0.1-13.f25container
registry.fedoraproject.org/f25/flannel:0.1
registry.fedoraproject.org/f25/flannel


The source of this content is provided in DistGit which can easily be
searched via the container pkgdb namespace[3].

As always, we welcome feedback and would encourage anyone interested
to come join the Fedora Atomic WG[0] as we continue to iterate on
integrating the Project Atomic[4] family of technologies into Fedora.
Anyone interested in contributing Container Images, please feel free
to join in and submit one for Review[5][6].

Thank you,
-AdamM

[0] - https://pagure.io/atomic-wg
[1] - https://docs.pagure.org/releng/
[2] - 
https://lists.fedoraproject.org/archives/list/cloud@lists.fedoraproject.org/thread/LU57S5TNFZRHVOM4ZK2HAUMGEOR5GFDB/
[3] - https://admin.fedoraproject.org/pkgdb/packages/container/%2A/
[4] - https://www.projectatomic.io/
[5] - https://fedoraproject.org/wiki/Container:Review_Process
[6] - https://fedoraproject.org/wiki/Container:Guidelines
___
cloud mailing list -- cloud@lists.fedoraproject.org
To unsubscribe send an email to cloud-le...@lists.fedoraproject.org

[atomic-wg] Issue #276: Set architecture label in the base container image

[Adam Miller]

maxamillion added a new comment to an issue you are following:
``
Do you want this to be a LABEL or an ENV?
``

To reply, visit the link below or just reply to this email
https://pagure.io/atomic-wg/issue/276
___
cloud mailing list -- cloud@lists.fedoraproject.org
To unsubscribe send an email to cloud-le...@lists.fedoraproject.org

[atomic-wg] Issue #276: Set architecture label in the base container image

[Adam Miller]

The issue: `Set architecture label in the base container image` of project: 
`atomic-wg` has been assigned to `maxamillion` by maxamillion.

https://pagure.io/atomic-wg/issue/276
___
cloud mailing list -- cloud@lists.fedoraproject.org
To unsubscribe send an email to cloud-le...@lists.fedoraproject.org

[atomic-wg] Issue #284: Fedora OSBS RFE: install go-md2man to buildroot image

[Adam Miller]

The issue: `Fedora OSBS RFE: install go-md2man to buildroot image` of project: 
`atomic-wg` has been assigned to `maxamillion` by maxamillion.

https://pagure.io/atomic-wg/issue/284
___
cloud mailing list -- cloud@lists.fedoraproject.org
To unsubscribe send an email to cloud-le...@lists.fedoraproject.org

[atomic-wg] Issue #277: Enforce ENV usage as a requirement for release label

[Adam Miller]

The status of the issue: `Enforce ENV usage as a requirement for release label` 
of project: `atomic-wg` has been updated to: Closed by maxamillion.

https://pagure.io/atomic-wg/issue/277
___
cloud mailing list -- cloud@lists.fedoraproject.org
To unsubscribe send an email to cloud-le...@lists.fedoraproject.org

[atomic-wg] Issue #277: Enforce ENV usage as a requirement for release label

[Adam Miller]

maxamillion added a new comment to an issue you are following:
``
Done
``

To reply, visit the link below or just reply to this email
https://pagure.io/atomic-wg/issue/277
___
cloud mailing list -- cloud@lists.fedoraproject.org
To unsubscribe send an email to cloud-le...@lists.fedoraproject.org

Announce: Fedora Layered Image Release

[Adam Miller]

Hello all,
On behalf of the Fedora Atomic WG[0] and Fedora Release
Engineering[1], I am pleased to announce the latest Fedora Layered
Image Release. This follows the latest Atomic Host Release[2].

At this time the following Container Images are available in the
Fedora Registry.


Base Images:

(Note that the "latest" tag currently points to "25" and the "rawhide"
tag currently points to "27", if no tag is provided in your pull
command then it will always default to "latest")

registry.fedoraproject.org/fedora:latest
registry.fedoraproject.org/fedora:rawhide
registry.fedoraproject.org/fedora:27
registry.fedoraproject.org/fedora:26
registry.fedoraproject.org/fedora:25
registry.fedoraproject.org/fedora:24


Layered Images:

(Note: Layered Images are namespaced in the registry and at this time
we are only releasing for the f25 namespace.)

registry.fedoraproject.org/f25/ruby:0-6.f25docker
registry.fedoraproject.org/f25/ruby:0
registry.fedoraproject.org/f25/ruby
registry.fedoraproject.org/f25/kubernetes-master:0.1-15.f25container
registry.fedoraproject.org/f25/kubernetes-master:0.1
registry.fedoraproject.org/f25/kubernetes-master
registry.fedoraproject.org/f25/kubernetes-kubelet:0-12.f25container
registry.fedoraproject.org/f25/kubernetes-kubelet:0
registry.fedoraproject.org/f25/kubernetes-kubelet
registry.fedoraproject.org/f25/redis:0-4.f25container
registry.fedoraproject.org/f25/redis:0
registry.fedoraproject.org/f25/redis
registry.fedoraproject.org/f25/etcd:0.1-14.f25container
registry.fedoraproject.org/f25/etcd:0.1
registry.fedoraproject.org/f25/etcd
registry.fedoraproject.org/f25/cockpit:135-9.f25container
registry.fedoraproject.org/f25/cockpit:135
registry.fedoraproject.org/f25/cockpit
registry.fedoraproject.org/f25/mongodb:0-4.f25container
registry.fedoraproject.org/f25/mongodb:0
registry.fedoraproject.org/f25/mongodb
registry.fedoraproject.org/f25/php:0-2.f25container
registry.fedoraproject.org/f25/php:0
registry.fedoraproject.org/f25/php
registry.fedoraproject.org/f25/s2i-base:1-12.f25container
registry.fedoraproject.org/f25/s2i-base:1
registry.fedoraproject.org/f25/s2i-base
registry.fedoraproject.org/f25/nodejs:0-3.f25container
registry.fedoraproject.org/f25/nodejs:0
registry.fedoraproject.org/f25/nodejs
registry.fedoraproject.org/f25/kubernetes-controller-manager:0.1-7.f25docker
registry.fedoraproject.org/f25/kubernetes-controller-manager:0.1
registry.fedoraproject.org/f25/kubernetes-controller-manager
registry.fedoraproject.org/f25/mariadb:10.1-12.f25container
registry.fedoraproject.org/f25/mariadb:10.1
registry.fedoraproject.org/f25/mariadb
registry.fedoraproject.org/f25/kubernetes-scheduler:0.1-13.f25container
registry.fedoraproject.org/f25/kubernetes-scheduler:0.1
registry.fedoraproject.org/f25/kubernetes-scheduler
registry.fedoraproject.org/f25/kubernetes-node:0.1-13.f25container
registry.fedoraproject.org/f25/kubernetes-node:0.1
registry.fedoraproject.org/f25/kubernetes-node
registry.fedoraproject.org/f25/kubernetes-proxy:0-13.f25container
registry.fedoraproject.org/f25/kubernetes-proxy:0
registry.fedoraproject.org/f25/kubernetes-proxy
registry.fedoraproject.org/f25/httpd:0-5.f25container
registry.fedoraproject.org/f25/httpd:0
registry.fedoraproject.org/f25/httpd
registry.fedoraproject.org/f25/toolchain:1-10.f25container
registry.fedoraproject.org/f25/toolchain:1
registry.fedoraproject.org/f25/toolchain
registry.fedoraproject.org/f25/kubernetes-apiserver:0.1-13.f25container
registry.fedoraproject.org/f25/kubernetes-apiserver:0.1
registry.fedoraproject.org/f25/kubernetes-apiserver
registry.fedoraproject.org/f25/mirrormanager2-mirrorlist:0.7.3-6.f25container
registry.fedoraproject.org/f25/mirrormanager2-mirrorlist:0.7.3
registry.fedoraproject.org/f25/mirrormanager2-mirrorlist
registry.fedoraproject.org/f25/flannel:0.1-12.f25container
registry.fedoraproject.org/f25/flannel:0.1
registry.fedoraproject.org/f25/flannel


The source of this content is provided in DistGit which can easily be
searched via the container pkgdb namespace[3].

As always, we welcome feedback and would encourage anyone interested
to come join the Fedora Atomic WG[0] as we continue to iterate on
integrating the Project Atomic[4] family of technologies into Fedora.
Anyone interested in contributing Container Images, please feel free
to join in and submit one for Review[5][6].


Thank you,
-AdamM

[0] - https://pagure.io/atomic-wg
[1] - https://docs.pagure.org/releng/
[2] - 
https://lists.fedoraproject.org/archives/list/cloud@lists.fedoraproject.org/thread/ZVBWUSUKH5LZGKLOVBPFOICZUEZ7IAF6/
[3] - https://admin.fedoraproject.org/pkgdb/packages/container/%2A/
[4] - https://www.projectatomic.io/
[5] - https://fedoraproject.org/wiki/Container:Review_Process
[6] - https://fedoraproject.org/wiki/Container:Guidelines
___
cloud mailing list -- cloud@lists.fedoraproject.org
To unsubscribe send an email to cloud-le...@lists.fedoraproject.org

Re: registry.fedoraproject.org/fedora:25 cannot install packages

[Adam Miller]

On Fri, Jun 9, 2017 at 9:37 AM, Jonathan Lebon  wrote:
> Thanks Adam for the quick resolution. Would it be easy to
> have an automated workflow to gate these updates on some
> quick sanity tests? E.g. push to `:next` first, run some
> tests, and then push to `:latest`?

+1

That's the plan, we want to wire that up through the new Taskotron
container testing stuff but it's just a matter of finding someone with
the spare cycles to write the code to do it.

>
> We're starting to rely more and more on this image in
> upstream tests, which means that any image issues can
> potentially block up merge queues across multiple projects!
>

This is both good (horray for adoption) and bad (we have to be more
careful not to break things).

> I don't want to sound like I'm signing you (nor me) up for
> any extra work. Just checking if the infra is already there
> for something like this to be implemented straightforwardly.
> If yes, then let's log an issue in the
>

No worries at all, that's certainly something that's desired and
something I'd like to see happen. Please file an issue ticket so we
can at least get it on the radar more broadly and we can discuss it at
a meeting and see if anyone has the cycles to get that going.

-AdamM

>
> - Original Message -
>> On Fri, Jun 9, 2017 at 1:08 AM, Jan Pazdziora  wrote:
>> >
>> > Hello,
>> >
>> > it seems registry.fedoraproject.org/fedora:25 was recently updated to
>> > some 10 month old version f3535ce68198 where packages cannot be
>> > installed due to missing
>> > /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-25-x86_64:
>> >
>> > https://bugzilla.redhat.com/show_bug.cgi?id=1460094
>> >
>>
>> Apologies, this was an oversight on my part. I did a sync and
>> specified the wrong koji tag to query for the latest base image. This
>> should be resolved now, if you have any further issues please let me
>> know.
>>
>> -AdamM
>>
>> > --
>> > Jan Pazdziora
>> > Senior Principal Software Engineer, Identity Management Engineering, Red
>> > Hat
>> > ___
>> > cloud mailing list -- cloud@lists.fedoraproject.org
>> > To unsubscribe send an email to cloud-le...@lists.fedoraproject.org
>> ___
>> cloud mailing list -- cloud@lists.fedoraproject.org
>> To unsubscribe send an email to cloud-le...@lists.fedoraproject.org
>>
> ___
> cloud mailing list -- cloud@lists.fedoraproject.org
> To unsubscribe send an email to cloud-le...@lists.fedoraproject.org
___
cloud mailing list -- cloud@lists.fedoraproject.org
To unsubscribe send an email to cloud-le...@lists.fedoraproject.org

Announce: Fedora Layered Image Release

[Adam Miller]

Hello all,
On behalf of the Fedora Atomic WG[0] and Fedora Release
Engineering[1], I am pleased to announce the latest Fedora Layered
Image Release. This follows the latest Atomic Host Release that came
out earlier today[2].

At this time the following Container Images are available in the
Fedora Registry.

Updated Base Images:

(Note that the "latest" tag currently points to "25" and the "rawhide"
tag currently points to "27", if no tag is provided in your pull
command then it will always default to "latest")

registry.fedoraproject.org/fedora:latest
registry.fedoraproject.org/fedora:rawhide
registry.fedoraproject.org/fedora:27
registry.fedoraproject.org/fedora:26
registry.fedoraproject.org/fedora:25


Updated Layered Images:

(Note: Layered Images are namespaced in the registry and at this time
we are only releasing for the f25 namespace.)

registry.fedoraproject.org/f25/kubernetes-master:0.1-12.f25container
registry.fedoraproject.org/f25/kubernetes-master:0.1
registry.fedoraproject.org/f25/kubernetes-master
registry.fedoraproject.org/f25/kubernetes-kubelet:0-11.f25container
registry.fedoraproject.org/f25/kubernetes-kubelet:0
registry.fedoraproject.org/f25/kubernetes-kubelet
registry.fedoraproject.org/f25/redis:0-2.f25container
registry.fedoraproject.org/f25/redis:0
registry.fedoraproject.org/f25/redis
registry.fedoraproject.org/f25/etcd:0.1-11.f25container
registry.fedoraproject.org/f25/etcd:0.1
registry.fedoraproject.org/f25/etcd
registry.fedoraproject.org/f25/cockpit:135-7.f25container
registry.fedoraproject.org/f25/cockpit:135
registry.fedoraproject.org/f25/cockpit
registry.fedoraproject.org/f25/mongodb:0-2.f25container
registry.fedoraproject.org/f25/mongodb:0
registry.fedoraproject.org/f25/mongodb
registry.fedoraproject.org/f25/s2i-base:1-10.f25container
registry.fedoraproject.org/f25/s2i-base:1
registry.fedoraproject.org/f25/s2i-base
registry.fedoraproject.org/f25/nodejs:0-2.f25container
registry.fedoraproject.org/f25/nodejs:0
registry.fedoraproject.org/f25/nodejs
registry.fedoraproject.org/f25/kubernetes-controller-manager:0.1-13.f25container
registry.fedoraproject.org/f25/kubernetes-controller-manager:0.1
registry.fedoraproject.org/f25/kubernetes-controller-manager
registry.fedoraproject.org/f25/mariadb:10.1-10.f25container
registry.fedoraproject.org/f25/mariadb:10.1
registry.fedoraproject.org/f25/mariadb
registry.fedoraproject.org/f25/kubernetes-scheduler:0.1-12.f25container
registry.fedoraproject.org/f25/kubernetes-scheduler:0.1
registry.fedoraproject.org/f25/kubernetes-scheduler
registry.fedoraproject.org/f25/kubernetes-node:0.1-11.f25container
registry.fedoraproject.org/f25/kubernetes-node:0.1
registry.fedoraproject.org/f25/kubernetes-node
registry.fedoraproject.org/f25/kubernetes-proxy:0-12.f25container
registry.fedoraproject.org/f25/kubernetes-proxy:0
registry.fedoraproject.org/f25/kubernetes-proxy
registry.fedoraproject.org/f25/httpd:0-4.f25container
registry.fedoraproject.org/f25/httpd:0
registry.fedoraproject.org/f25/httpd
registry.fedoraproject.org/f25/toolchain:1-8.f25container
registry.fedoraproject.org/f25/toolchain:1
registry.fedoraproject.org/f25/toolchain
registry.fedoraproject.org/f25/kubernetes-apiserver:0.1-12.f25container
registry.fedoraproject.org/f25/kubernetes-apiserver:0.1
registry.fedoraproject.org/f25/kubernetes-apiserver
registry.fedoraproject.org/f25/mirrormanager2-mirrorlist:0.7.3-4.f25container
registry.fedoraproject.org/f25/mirrormanager2-mirrorlist:0.7.3
registry.fedoraproject.org/f25/mirrormanager2-mirrorlist
registry.fedoraproject.org/f25/flannel:0.1-9.f25container
registry.fedoraproject.org/f25/flannel:0.1
registry.fedoraproject.org/f25/flannel


The source of this content is provided in DistGit which can easily be
searched via the container pkgdb namespace[3].

As always, we welcome feedback and would encourage anyone interested
to come join the Fedora Atomic WG[0] as we continue to iterate on
integrating the Project Atomic[4] family of technologies into Fedora.
Anyone interested in contributing Container Images, please feel free
to join in and submit one for Review[5][6].

Thank you,
-AdamM

[0] - https://pagure.io/atomic-wg
[1] - https://docs.pagure.org/releng/
[2] - 
https://lists.fedoraproject.org/archives/list/cloud@lists.fedoraproject.org/thread/WLSPN4LPUXEYRRPFLFXDTNMONGZDU6JK/
[3] - https://admin.fedoraproject.org/pkgdb/packages/container/%2A/
[4] - https://www.projectatomic.io/
[5] - https://fedoraproject.org/wiki/Container:Review_Process
[6] - https://fedoraproject.org/wiki/Container:Guidelines
___
cloud mailing list -- cloud@lists.fedoraproject.org
To unsubscribe send an email to cloud-le...@lists.fedoraproject.org

[atomic-wg] Issue #277: Enforce ENV usage as a requirement for release label

[Adam Miller]

maxamillion reported a new issue against the project: `atomic-wg` that you are 
following:
``
Currently the [Container Guidelines on LABELS 
https://fedoraproject.org/wiki/Container:Guidelines#LABELS] *recommend* the use 
of `ENV` declarations for the `release` but it appears as though this should be 
a requirement because of the way that python-dockerfile_parse performs ENV 
inheritance, if this method is not used then we lose `$DISTGIT` and `$FGC` 

I would like to request that the Working Group vote to make this mandatory in 
the guidelines.

Thank you,
-AdamM
``

To reply, visit the link below or just reply to this email
https://pagure.io/atomic-wg/issue/277
___
cloud mailing list -- cloud@lists.fedoraproject.org
To unsubscribe send an email to cloud-le...@lists.fedoraproject.org

Re: Announce: Fedora Layered Image Release

[Adam Miller]

On Tue, May 23, 2017 at 9:38 AM, Jan Pazdziora <jpazdzi...@redhat.com> wrote:
> On Mon, May 15, 2017 at 03:45:32PM -0500, Adam Miller wrote:
>> >
>> > Is the infrastructure now ready for the respin?
>>
>> It appears the builds are still failing because of
>> https://bugzilla.redhat.com/show_bug.cgi?id=144
>
> The bugzilla was addressed -- can we give
>
> registry.fedoraproject.org/fedora:26
>
> another try?
>

Yes, it's on the agenda for today to go out with the layered image
release that will follow today's Atomic Host release.

-AdamM

> --
> Jan Pazdziora
> Senior Principal Software Engineer, Identity Management Engineering, Red Hat
> ___
> cloud mailing list -- cloud@lists.fedoraproject.org
> To unsubscribe send an email to cloud-le...@lists.fedoraproject.org
___
cloud mailing list -- cloud@lists.fedoraproject.org
To unsubscribe send an email to cloud-le...@lists.fedoraproject.org

Re: Announce: Fedora Layered Image Release

[Adam Miller]

On Mon, May 15, 2017 at 8:16 AM, Jan Pazdziora <jpazdzi...@redhat.com> wrote:
> On Thu, May 11, 2017 at 10:04:19AM -0500, Dennis Gilmore wrote:
>> El mié, 10-05-2017 a las 22:47 -0500, Adam Miller escribió:
>> > On Tue, May 9, 2017 at 7:22 AM, Jan Pazdziora <jpazdzi...@redhat.com>
>> > wrote:
>> > >
>> > > One problem with the current Fedora 26 image is that it enables
>> > > rawhide repo and not the 26 development repo. So anybody using that
>> > > image to build something which installs additional packages will
>> > > get
>> > > Fedora 27, not Fedora 26 packages installed.
>> > >
>> > > Could the registry.fedoraproject.org/fedora:26 be respun to point
>> > > to
>> > > the correct Fedora 26 package source?
>> >
>> > Absolutely. I went to look into that today but the koji builder tasks
>> > were having an issue for the last few weeks. It turns out that there
>> > was a bug in oz (which is used in image builds in koji). This has
>> > been
>> > fixed and we should be able to get updates out tomorrow.
>>
>> the bug was not in oz. I suspect it was a regression in nss, all the
>> gory details are in
>> https://pagure.io/releng/issue/6776https://pagure.io/releng/issue/6776
>
> Is the infrastructure now ready for the respin?
>

It appears the builds are still failing because of
https://bugzilla.redhat.com/show_bug.cgi?id=144

-AdamM

> --
> Jan Pazdziora
> Senior Principal Software Engineer, Identity Management Engineering, Red Hat
> ___
> cloud mailing list -- cloud@lists.fedoraproject.org
> To unsubscribe send an email to cloud-le...@lists.fedoraproject.org
___
cloud mailing list -- cloud@lists.fedoraproject.org
To unsubscribe send an email to cloud-le...@lists.fedoraproject.org

Re: Announce: Fedora Layered Image Release

[Adam Miller]

On Tue, May 9, 2017 at 7:22 AM, Jan Pazdziora <jpazdzi...@redhat.com> wrote:
> On Mon, May 08, 2017 at 01:59:36PM -0500, Adam Miller wrote:
>> On Thu, May 4, 2017 at 6:55 AM, Jan Pazdziora <jpazdzi...@redhat.com> wrote:
>> > On Thu, Apr 20, 2017 at 10:39:22PM -0500, Adam Miller wrote:
>> >> Hello all,
>> >> On behalf of the Fedora Atomic WG[0] and Fedora Release
>> >> Engineering[1], I am pleased to announce the latest Fedora Layered
>> >> Image Release. This follows the latest Atomic Host Release that came
>> >> out yesterday[2].
>> >>
>> >> At this time the following Container Images are available in the
>> >> Fedora Registry.
>> >>
>> >>
>> >> Base Images:
>> >>
>> >> (Note that the "latest" tag currently points to "25" and the "rawhide"
>> >> tag currently points to "27", if no tag is provided in your pull
>> >> command then it will always default to "latest")
>> >>
>> >> registry.fedoraproject.org/fedora:latest
>> >> registry.fedoraproject.org/fedora:rawhide
>> >> registry.fedoraproject.org/fedora:27
>> >
>> > The current registry.fedoraproject.org/fedora:rawhide and
>> > registry.fedoraproject.org/fedora:27 image 202b880ac136 says it's
>> > 7 weeks old,
>> >
>> >> registry.fedoraproject.org/fedora:26
>> >
>> > Fedora 26 image is 4 months old.
>> >
>> > What are the plans for respining these images on regular basis?
>> > Especially the development "releases" tend to change quite heaving and
>> > if we do not want to encourage the use of
>> >
>> > RUN dnf upgrade -y
>> >
>> > in every Dockerfile, we might want to make it easy for people to
>> > consume fresh content.
>> >
>> > Incidently, registry.fedoraproject.org/fedora:25 is rather new, just
>> > 13 days old.
>>
>> Yes, the current stable is planned to be respun on a two-week average.
>> The others as well but they aren't priority right now. There's an
>> automation process in the works and once that is done then all of
>> these will happen automatically.
>
> One problem with the current Fedora 26 image is that it enables
> rawhide repo and not the 26 development repo. So anybody using that
> image to build something which installs additional packages will get
> Fedora 27, not Fedora 26 packages installed.
>
> Could the registry.fedoraproject.org/fedora:26 be respun to point to
> the correct Fedora 26 package source?
>

Absolutely. I went to look into that today but the koji builder tasks
were having an issue for the last few weeks. It turns out that there
was a bug in oz (which is used in image builds in koji). This has been
fixed and we should be able to get updates out tomorrow.

-AdamM

> Thank you,
>
> --
> Jan Pazdziora
> Senior Principal Software Engineer, Identity Management Engineering, Red Hat
> ___
> cloud mailing list -- cloud@lists.fedoraproject.org
> To unsubscribe send an email to cloud-le...@lists.fedoraproject.org
___
cloud mailing list -- cloud@lists.fedoraproject.org
To unsubscribe send an email to cloud-le...@lists.fedoraproject.org

Re: Announce: Fedora Layered Image Release

[Adam Miller]

On Thu, May 4, 2017 at 6:55 AM, Jan Pazdziora <jpazdzi...@redhat.com> wrote:
> On Thu, Apr 20, 2017 at 10:39:22PM -0500, Adam Miller wrote:
>> Hello all,
>> On behalf of the Fedora Atomic WG[0] and Fedora Release
>> Engineering[1], I am pleased to announce the latest Fedora Layered
>> Image Release. This follows the latest Atomic Host Release that came
>> out yesterday[2].
>>
>> At this time the following Container Images are available in the
>> Fedora Registry.
>>
>>
>> Base Images:
>>
>> (Note that the "latest" tag currently points to "25" and the "rawhide"
>> tag currently points to "27", if no tag is provided in your pull
>> command then it will always default to "latest")
>>
>> registry.fedoraproject.org/fedora:latest
>> registry.fedoraproject.org/fedora:rawhide
>> registry.fedoraproject.org/fedora:27
>
> The current registry.fedoraproject.org/fedora:rawhide and
> registry.fedoraproject.org/fedora:27 image 202b880ac136 says it's
> 7 weeks old,
>
>> registry.fedoraproject.org/fedora:26
>
> Fedora 26 image is 4 months old.
>
> What are the plans for respining these images on regular basis?
> Especially the development "releases" tend to change quite heaving and
> if we do not want to encourage the use of
>
> RUN dnf upgrade -y
>
> in every Dockerfile, we might want to make it easy for people to
> consume fresh content.
>
> Incidently, registry.fedoraproject.org/fedora:25 is rather new, just
> 13 days old.

Yes, the current stable is planned to be respun on a two-week average.
The others as well but they aren't priority right now. There's an
automation process in the works and once that is done then all of
these will happen automatically.

-AdamM

>
> --
> Jan Pazdziora
> Senior Principal Software Engineer, Identity Management Engineering, Red Hat
> ___
> cloud mailing list -- cloud@lists.fedoraproject.org
> To unsubscribe send an email to cloud-le...@lists.fedoraproject.org
___
cloud mailing list -- cloud@lists.fedoraproject.org
To unsubscribe send an email to cloud-le...@lists.fedoraproject.org

Re: Announce: Fedora Layered Image Release

[Adam Miller]

On Fri, Apr 28, 2017 at 2:39 AM, Jan Pazdziora <jpazdzi...@redhat.com> wrote:
> On Thu, Apr 20, 2017 at 10:39:22PM -0500, Adam Miller wrote:
>> Hello all,
>> On behalf of the Fedora Atomic WG[0] and Fedora Release
>> Engineering[1], I am pleased to announce the latest Fedora Layered
>> Image Release. This follows the latest Atomic Host Release that came
>> out yesterday[2].
>>
>> At this time the following Container Images are available in the
>> Fedora Registry.
>>
>> Base Images:
>>
>> (Note that the "latest" tag currently points to "25" and the "rawhide"
>> tag currently points to "27", if no tag is provided in your pull
>> command then it will always default to "latest")
>>
>> registry.fedoraproject.org/fedora:latest
>> registry.fedoraproject.org/fedora:rawhide
>> registry.fedoraproject.org/fedora:27
>> registry.fedoraproject.org/fedora:26
>> registry.fedoraproject.org/fedora:25
>> registry.fedoraproject.org/fedora:24
>
> What is the relationship to docker.io/fedora?
>
> Running docker pull for various images and then docker images, I can see
>
> REPOSITORY  TAG IMAGE ID
> CREATED SIZE
> docker.io/fedora24  f623aaef07f05 
> months ago204.4 MB
> registry.fedoraproject.org/fedora   24  f623aaef07f05 
> months ago204.4 MB
>
> so for Fedora 24 the images are the same, but
>
> REPOSITORY  TAG IMAGE ID
> CREATED SIZE
> docker.io/fedora25  15895ef0b3b26 
> days ago  230.9 MB
> registry.fedoraproject.org/fedora   25  b414411f6e007 
> days ago  230.9 MB
>
> So it looks like docker.io/fedora has newer Fedora 25 image than
> registry.fedoraproject.org/fedora. Is that expected?
>
> If we are building building images
>
> FROM fedora:25
>
> should we start using
>
> FROM registry.fedoraproject.org/fedora:25
>
> instead in Dockerfiles? If merely fedora does not point to whatever
> is the authoritative location for Fedora images, shouldn't it be purged
> in docker.io to avoid confusion?

We do have 'FROM registry.fedoraproject.org/fedora:25' in our
Container Guidelines[0] today.

As a note though, we do maintain the docker base images on the Docker
Hub also, they are made from the same rootfs of the Fedora Official
ones that comes from Koji but we have to extract the rootfs from the
archive file and add a Dockerfile to comply with Docker Library's
upload workflow[1]. However, we do not upload pre-GA Releases
(branched) or rawhide to Docker Hub currently because of this added
manual work that is required.

We are also aiming to sync out all layered image content to Docker Hub
(and potentially other publicly available registries such as Quay.io)
but that is not currently high in priority. Hopefully in the next
couple months. As a point of note, layered image content can easily be
sync'd via the fedora Docker Hub account once the automatic release
process is in place (currently being worked on[2]) but base images are
considered special.

-AdamM

[0] - https://fedoraproject.org/wiki/Container:Guidelines
[1] - https://github.com/fedora-cloud/docker-brew-fedora
[2] - 
https://fedoraproject.org/wiki/Changes/ReleaseEngineeringAutomationWorkflowEngine

>
> --
> Jan Pazdziora
> Senior Principal Software Engineer, Identity Management Engineering, Red Hat
> ___
> cloud mailing list -- cloud@lists.fedoraproject.org
> To unsubscribe send an email to cloud-le...@lists.fedoraproject.org
___
cloud mailing list -- cloud@lists.fedoraproject.org
To unsubscribe send an email to cloud-le...@lists.fedoraproject.org

[atomic-wg] Issue #255: Consider creating redirection site for image Help Files

[Adam Miller]

maxamillion added a new comment to an issue you are following:
``
This is a request we would need to file with [Fedora 
Infrastructure](https://pagure.io/fedora-infrastructure) if it's something we 
actually want. No one in the WG has the capabilities to do this in an official 
capacity.
``

To reply, visit the link below or just reply to this email
https://pagure.io/atomic-wg/issue/255
___
cloud mailing list -- cloud@lists.fedoraproject.org
To unsubscribe send an email to cloud-le...@lists.fedoraproject.org

Announce: Fedora Layered Image Release

[Adam Miller]

Hello all,
On behalf of the Fedora Atomic WG[0] and Fedora Release
Engineering[1], I am pleased to announce the latest Fedora Layered
Image Release. This follows the latest Atomic Host Release that came
out yesterday[2].

At this time the following Container Images are available in the
Fedora Registry.


Base Images:

(Note that the "latest" tag currently points to "25" and the "rawhide"
tag currently points to "27", if no tag is provided in your pull
command then it will always default to "latest")

registry.fedoraproject.org/fedora:latest
registry.fedoraproject.org/fedora:rawhide
registry.fedoraproject.org/fedora:27
registry.fedoraproject.org/fedora:26
registry.fedoraproject.org/fedora:25
registry.fedoraproject.org/fedora:24


Layered Images:

(Note: Layered Images are namespaced in the registry and at this time
we are only releasing for the f25 namespace.)

registry.fedoraproject.org/f25/cockpit:135-4.f25docker
registry.fedoraproject.org/f25/cockpit:135
registry.fedoraproject.org/f25/cockpit
registry.fedoraproject.org/f25/kubernetes-node:0.1-8.f25docker
registry.fedoraproject.org/f25/kubernetes-node:0.1
registry.fedoraproject.org/f25/kubernetes-node
registry.fedoraproject.org/f25/kubernetes-controller-manager:0.1-8.f25docker
registry.fedoraproject.org/f25/kubernetes-controller-manager:0.1
registry.fedoraproject.org/f25/kubernetes-controller-manager
registry.fedoraproject.org/f25/mariadb:10.1-7.f25docker
registry.fedoraproject.org/f25/mariadb:10.1
registry.fedoraproject.org/f25/mariadb
registry.fedoraproject.org/f25/kubernetes-apiserver:0.1-8.f25docker
registry.fedoraproject.org/f25/kubernetes-apiserver:0.1
registry.fedoraproject.org/f25/kubernetes-apiserver
registry.fedoraproject.org/f25/kubernetes-scheduler:0.1-8.f25docker
registry.fedoraproject.org/f25/kubernetes-scheduler:0.1
registry.fedoraproject.org/f25/kubernetes-scheduler
registry.fedoraproject.org/f25/kubernetes-master:0.1-9.f25docker
registry.fedoraproject.org/f25/kubernetes-master:0.1
registry.fedoraproject.org/f25/kubernetes-master
registry.fedoraproject.org/f25/s2i-base:1-5.f25docker
registry.fedoraproject.org/f25/s2i-base:1
registry.fedoraproject.org/f25/s2i-base
registry.fedoraproject.org/f25/kubernetes-kubelet:0-8.f25docker
registry.fedoraproject.org/f25/kubernetes-kubelet:0
registry.fedoraproject.org/f25/kubernetes-kubelet
registry.fedoraproject.org/f25/flannel:0.1-7.f25docker
registry.fedoraproject.org/f25/flannel:0.1
registry.fedoraproject.org/f25/flannel
registry.fedoraproject.org/f25/kubernetes-proxy:0-8.f25docker
registry.fedoraproject.org/f25/kubernetes-proxy:0
registry.fedoraproject.org/f25/kubernetes-proxy
registry.fedoraproject.org/f25/etcd:0.1-9.f25docker
registry.fedoraproject.org/f25/etcd:0.1
registry.fedoraproject.org/f25/etcd
registry.fedoraproject.org/f25/toolchain:1-6.f25docker
registry.fedoraproject.org/f25/toolchain:1
registry.fedoraproject.org/f25/toolchain


As a reminder, the source of this content is provided in DistGit which
can easily be searched via the container-specific pkgdb namespace[3].

As always, we welcome feedback and would encourage anyone interested
to come join the Fedora Atomic WG[0] as we continue to iterate on
integrating the Project Atomic[4] family of technologies into Fedora.
Anyone interested in contributing Container Images, please feel free
to join in and submit one for Review[5][6].

Thank you,
-AdamM

[0] - https://pagure.io/atomic-wg
[1] - https://docs.pagure.org/releng/
[2] - 
https://lists.fedoraproject.org/archives/list/cloud@lists.fedoraproject.org/thread/7MTNJIPL4EJOS7WXX6W65JU6S4SI4QEM/
[3] - https://admin.fedoraproject.org/pkgdb/packages/docker/%2A/
[4] - https://www.projectatomic.io/
[5] - https://fedoraproject.org/wiki/Container:Review_Process
[6] - https://fedoraproject.org/wiki/Container:Guidelines
[7] - https://github.com/jessfraz/reg/tree/master/server
[8] - https://bugzilla.redhat.com/show_bug.cgi?id=1432214
___
cloud mailing list -- cloud@lists.fedoraproject.org
To unsubscribe send an email to cloud-le...@lists.fedoraproject.org

[atomic-wg] Issue #248 `Container Guidelines: Layered Images used as a base for other Layered Builds`

[Adam Miller]

maxamillion added a new comment to an issue you are following:
``
What @jasonbrooks said.
``

To reply, visit the link below or just reply to this email
https://pagure.io/atomic-wg/issue/248
___
cloud mailing list -- cloud@lists.fedoraproject.org
To unsubscribe send an email to cloud-le...@lists.fedoraproject.org

Announce: Fedora Layered Image Release

[Adam Miller]

Hello all,
On behalf of the Fedora Atomic WG[0] and Fedora Release
Engineering[1], I am pleased to announce the latest Fedora Layered
Image Release. This follows the latest Atomic Host Release that came
out yesterday[2].

At this time the following Container Images are available in the
Fedora Registry.

registry.fedoraproject.org/f25/cockpit:130-1.8.f25docker
registry.fedoraproject.org/f25/cockpit:130
registry.fedoraproject.org/f25/cockpit
registry.fedoraproject.org/f25/kubernetes-node:0.1-6.f25docker
registry.fedoraproject.org/f25/kubernetes-node:0.1
registry.fedoraproject.org/f25/kubernetes-node
registry.fedoraproject.org/f25/kubernetes-controller-manager:0.1-6.f25docker
registry.fedoraproject.org/f25/kubernetes-controller-manager:0.1
registry.fedoraproject.org/f25/kubernetes-controller-manager
registry.fedoraproject.org/f25/mariadb:10.1-5.f25docker
registry.fedoraproject.org/f25/mariadb:10.1
registry.fedoraproject.org/f25/mariadb
registry.fedoraproject.org/f25/kubernetes-apiserver:0.1-6.f25docker
registry.fedoraproject.org/f25/kubernetes-apiserver:0.1
registry.fedoraproject.org/f25/kubernetes-apiserver
registry.fedoraproject.org/f25/kubernetes-scheduler:0.1-6.f25docker
registry.fedoraproject.org/f25/kubernetes-scheduler:0.1
registry.fedoraproject.org/f25/kubernetes-scheduler
registry.fedoraproject.org/f25/kubernetes-master:0.1-7.f25docker
registry.fedoraproject.org/f25/kubernetes-master:0.1
registry.fedoraproject.org/f25/kubernetes-master
registry.fedoraproject.org/f25/s2i-base:1-4.f25docker
registry.fedoraproject.org/f25/s2i-base:1
registry.fedoraproject.org/f25/s2i-base
registry.fedoraproject.org/f25/kubernetes-kubelet:0.1-5.f25docker
registry.fedoraproject.org/f25/kubernetes-kubelet:0.1
registry.fedoraproject.org/f25/kubernetes-kubelet
registry.fedoraproject.org/f25/flannel:0.1-5.f25docker
registry.fedoraproject.org/f25/flannel:0.1
registry.fedoraproject.org/f25/flannel
registry.fedoraproject.org/f25/kubernetes-proxy:0.1-5.f25docker
registry.fedoraproject.org/f25/kubernetes-proxy:0.1
registry.fedoraproject.org/f25/kubernetes-proxy
registry.fedoraproject.org/f25/etcd:0.1-7.f25docker
registry.fedoraproject.org/f25/etcd:0.1
registry.fedoraproject.org/f25/etcd
registry.fedoraproject.org/f25/toolchain:1-4.f25docker
registry.fedoraproject.org/f25/toolchain:1
registry.fedoraproject.org/f25/toolchain

As a reminder, the source of this content is provided in DistGit which
can easily be searched via the container-specific pkgdb namespace[3].

As always, we welcome feedback and would encourage anyone interested
to come join the Fedora Atomic WG[0] as we continue to iterate on
integrating the Project Atomic[4] family of technologies into Fedora.
Anyone interested in contributing Container Images, please feel free
to join in and submit one for Review[5][6].

Also, it was previously mentioned that we're aiming to provide a webUI
in front of our registry. We're currently planning to use MIT Licensed
reg-server[7] which we will deploy once we have a completed package
review[8] and a Fedora CSS theme from the websites group. Updates on
that will come as we are able to accomplish these tasks.

Thank you,
-AdamM

[0] - https://pagure.io/atomic-wg
[1] - https://docs.pagure.org/releng/
[2] - 
https://lists.fedoraproject.org/archives/list/cloud@lists.fedoraproject.org/thread/CS6NKTLLYWEC3AXJPYQ2LPBTFSD43HRC/
[3] - https://admin.fedoraproject.org/pkgdb/packages/docker/%2A/
[4] - https://www.projectatomic.io/
[5] - https://fedoraproject.org/wiki/Container:Review_Process
[6] - https://fedoraproject.org/wiki/Container:Guidelines
[7] - https://github.com/jessfraz/reg/tree/master/server
[8] - https://bugzilla.redhat.com/show_bug.cgi?id=1432214
___
cloud mailing list -- cloud@lists.fedoraproject.org
To unsubscribe send an email to cloud-le...@lists.fedoraproject.org

[atomic-wg] Issue #249 `The build system should provide an automatically populated VERSION label`

[Adam Miller]

The issue: `The build system should provide an automatically populated VERSION 
label` of project: `atomic-wg` has been assigned to `maxamillion` by 
maxamillion.

https://pagure.io/atomic-wg/issue/249
___
cloud mailing list -- cloud@lists.fedoraproject.org
To unsubscribe send an email to cloud-le...@lists.fedoraproject.org

[atomic-wg] Issue #236 `container scratch build without a dist-git`

[Adam Miller]

maxamillion added a new comment to an issue you are following:
``
We can not currently, absolutely need to. I'll add this to the TODO list. Will 
update later with a Taiga card in the Fedora RelEng Tools space for context and 
on-going work.
``

To reply, visit the link below or just reply to this email
https://pagure.io/atomic-wg/issue/236
___
cloud mailing list -- cloud@lists.fedoraproject.org
To unsubscribe send an email to cloud-le...@lists.fedoraproject.org

Re: Updated Container Guidelines

[Adam Miller]

On Thu, Feb 23, 2017 at 12:07 PM, Honza Horak  wrote:
> Hi Adam & co.,
>
> I think the container guidelines should include a section about the Layered
> Images used as a base for other Layered Builds. I've created an updated
> draft that also fixes label names to use the lower-case convention:
>
> https://fedoraproject.org/wiki/User:Hhorak/Draft/Container:Review_Process
>
> Is it possible to merge the changes? Or is there any process for it?

Sorry for the delayed response.

Absolutely 100% of those guidelines are open for continued
improvement. Please file an issue ticket in the atomic-wg[0] space and
mark it with the meeting tag so we can get some review from the
Working Group and then get changes merged.

Thanks!
-AdamM


[0] - https://pagure.io/atomic-wg/issues

>
> Honza
___
cloud mailing list -- cloud@lists.fedoraproject.org
To unsubscribe send an email to cloud-le...@lists.fedoraproject.org

Announce: Fedora Layered Image Release

[Adam Miller]

Hello all,
On behalf of the Fedora Atomic WG[0] and Fedora Release
Engineering[1], I am pleased to announce the latest Fedora Layered
Image Release. This follows the latest Atomic Host Release that came
out yesterday[2].

At this time the following Container Images are available in the
Fedora Registry.

registry.fedoraproject.org/f25/cockpit:130-1.3.f25docker
registry.fedoraproject.org/f25/cockpit:130
registry.fedoraproject.org/f25/cockpit
registry.fedoraproject.org/f25/kubernetes-node:0.1-3.f25docker
registry.fedoraproject.org/f25/kubernetes-node:0.1
registry.fedoraproject.org/f25/kubernetes-node
registry.fedoraproject.org/f25/mariadb:10.1-2.f25docker
registry.fedoraproject.org/f25/mariadb:10.1
registry.fedoraproject.org/f25/mariadb
registry.fedoraproject.org/f25/kubernetes-apiserver:0.1-3.f25docker
registry.fedoraproject.org/f25/kubernetes-apiserver:0.1
registry.fedoraproject.org/f25/kubernetes-apiserver
registry.fedoraproject.org/f25/kubernetes-master:0.1-5.f25docker
registry.fedoraproject.org/f25/kubernetes-master:0.1
registry.fedoraproject.org/f25/kubernetes-master
registry.fedoraproject.org/f25/flannel:0.1-3.f25docker
registry.fedoraproject.org/f25/flannel:0.1
registry.fedoraproject.org/f25/flannel
registry.fedoraproject.org/f25/kubernetes-proxy:0.1-3.f25docker
registry.fedoraproject.org/f25/kubernetes-proxy:0.1
registry.fedoraproject.org/f25/kubernetes-proxy
registry.fedoraproject.org/f25/etcd:0.1-5.f25docker
registry.fedoraproject.org/f25/etcd:0.1
registry.fedoraproject.org/f25/etcd
registry.fedoraproject.org/f25/toolchain:1-2.f25docker
registry.fedoraproject.org/f25/toolchain:1
registry.fedoraproject.org/f25/toolchain

As a reminder, the source of this content is provided in DistGit which
can easily be searched via the container-specific pkgdb namespace[3].

As always, we welcome feedback and would encourage anyone interested
to come join the Fedora Atomic WG[0] as we continue to iterate on
integrating the Project Atomic[4] family of technologies into Fedora.
Anyone interested in contributing Container Images, please feel free
to join in and submit one for Review[5][6].

Thank you,
-AdamM

[0] - https://pagure.io/atomic-wg
[1] - https://docs.pagure.org/releng/
[2] - 
https://lists.fedoraproject.org/archives/list/cloud@lists.fedoraproject.org/message/63LXWH33QYZKTNOFNJ5T6TRNNJ376RC7/
[3] - https://admin.fedoraproject.org/pkgdb/packages/docker/%2A/
[4] - https://www.projectatomic.io/
[5] - https://fedoraproject.org/wiki/Container:Review_Process
[6] - https://fedoraproject.org/wiki/Container:Guidelines
___
cloud mailing list -- cloud@lists.fedoraproject.org
To unsubscribe send an email to cloud-le...@lists.fedoraproject.org

Announce: Fedora Layered Image Release

[Adam Miller]

Hello all,
On behalf of the Fedora Atomic WG[0] and Fedora Release
Engineering[1], I am pleased to announce the first ever Fedora Layered
Image Release. Each Container Image is released with the following
streams which aim to provide lifecycle management choices to our
users:

Name
Name-Version
Name-Version-Release

Each of the Name and Name-Version tags will be updated in place with
their respective updates for as long as the maintainer supports them
and the Name-Version-Release will always be a frozen in time reference
to that particular release of the Container Image.

At this time the following Container Images are available in the
Fedora Registry.

registry.fedoraproject.org/f25/cockpit:130-1.f25docker
registry.fedoraproject.org/f25/cockpit:130
registry.fedoraproject.org/f25/cockpit
registry.fedoraproject.org/f25/kubernetes-node:0.1-2.f25docker
registry.fedoraproject.org/f25/kubernetes-node:0.1
registry.fedoraproject.org/f25/kubernetes-node
registry.fedoraproject.org/f25/toolchain:1-1.f25docker
registry.fedoraproject.org/f25/toolchain:1
registry.fedoraproject.org/f25/toolchain
registry.fedoraproject.org/f25/kubernetes-master:0.1-3.f25docker
registry.fedoraproject.org/f25/kubernetes-master:0.1
registry.fedoraproject.org/f25/kubernetes-master

From now on we will be doing regularly scheduled releases of Fedora
Layered Image content that will match the Fedora Atomic Two Week
Release schedule.

We are currently working on a way to provide browse and search
functionality for Fedora Container Images so please stay tuned for
that.

For those interested, the source of this content is provided in
DistGit which can easily be searched via the container-specific pkgdb
namespace[2].

As always, we welcome feedback and would encourage anyone interested
to come join the Fedora Atomic WG[0] as we continue to iterate on
integrating the Project Atomic[3] family of technologies into Fedora.

Anyone interested in contributing Container Images, please feel free
to join in and submit one for Review[4][5].

Thank you,
-AdamM

[0] - https://pagure.io/atomic-wg
[1] - https://docs.pagure.org/releng/
[2] - https://admin.fedoraproject.org/pkgdb/packages/docker/%2A/
[3] - http://www.projectatomic.io/
[4] - https://fedoraproject.org/wiki/Container:Review_Process
[5] - https://fedoraproject.org/wiki/Container:Guidelines
___
cloud mailing list -- cloud@lists.fedoraproject.org
To unsubscribe send an email to cloud-le...@lists.fedoraproject.org

Re: Ownership of the Cloud Base Image

[Adam Miller]

On Wed, Feb 8, 2017 at 7:01 PM, Dusty Mabe  wrote:
>
> After some discussions with mattdm and sgallagh about the cloud base
> image and the server WG we have decided for now to leave the cloud
> base image out of the server WG. Obviously it doesn't make sense to
> have it stay as owned by the Atomic WG so here is what I would like to
> propose:
>
> - Have the cloud base image owned by a CLOUD SIG
> - Mainly members of the old CLOUD WG that care about the cloud
>   base image, including me.
> - Create a new pagure issue tracker for the cloud sig.
>

+1

> I had also toyed around with splitting out the atomic working group
> into a new mailing list atomic@fp.o and a new IRC channel #fedora-atomic
> but I'm not sure if that is necessary. I think as long as we have a
> separation of ownership (mainly different issue trackers) then that
> should take care of some of the issues.

+1

-AdamM
>
> Thoughts?
>
> Dusty
> ___
> cloud mailing list -- cloud@lists.fedoraproject.org
> To unsubscribe send an email to cloud-le...@lists.fedoraproject.org
___
cloud mailing list -- cloud@lists.fedoraproject.org
To unsubscribe send an email to cloud-le...@lists.fedoraproject.org

[atomic-wg] Issue #215 `Move redis httpd container image from Fedora-Dockerfiles GitHub into DistGit`

[Adam Miller]

The issue: `Move redis httpd container image from Fedora-Dockerfiles GitHub 
into DistGit` of project: `atomic-wg` has been assigned to `maxamillion` by 
maxamillion.

https://pagure.io/atomic-wg/issue/215
___
cloud mailing list -- cloud@lists.fedoraproject.org
To unsubscribe send an email to cloud-le...@lists.fedoraproject.org

[atomic-wg] Issue #225 `Review Container Request for owncload (replacement of Fedora-Dockerfiles GitHub)`

[Adam Miller]

maxamillion added a new comment to an issue you are following:
``
Note that the Review Requiest in from jhogarth would replace the owncloud 
Dockerfile from GitHub.
``

To reply, visit the link below or just reply to this email
https://pagure.io/atomic-wg/issue/225
___
cloud mailing list -- cloud@lists.fedoraproject.org
To unsubscribe send an email to cloud-le...@lists.fedoraproject.org

[atomic-wg] Issue #219 `Move registry container image from Fedora-Dockerfiles GitHub into DistGit`

[Adam Miller]

The issue: `Move registry container image from Fedora-Dockerfiles GitHub into 
DistGit` of project: `atomic-wg` has been reset by maxamillion.

https://pagure.io/atomic-wg/issue/219
___
cloud mailing list -- cloud@lists.fedoraproject.org
To unsubscribe send an email to cloud-le...@lists.fedoraproject.org

[atomic-wg] Issue #219 `Move registry container image from Fedora-Dockerfiles GitHub into DistGit`

[Adam Miller]

The status of the issue: `Move registry container image from Fedora-Dockerfiles 
GitHub into DistGit` of project: `atomic-wg` has been updated to: Closed by 
maxamillion.

https://pagure.io/atomic-wg/issue/219
___
cloud mailing list -- cloud@lists.fedoraproject.org
To unsubscribe send an email to cloud-le...@lists.fedoraproject.org

[atomic-wg] Issue #219 `Move registry container image from Fedora-Dockerfiles GitHub into DistGit`

[Adam Miller]

The issue: `Move registry container image from Fedora-Dockerfiles GitHub into 
DistGit` of project: `atomic-wg` has been assigned to `maxamillion` by 
maxamillion.

https://pagure.io/atomic-wg/issue/219
___
cloud mailing list -- cloud@lists.fedoraproject.org
To unsubscribe send an email to cloud-le...@lists.fedoraproject.org

[atomic-wg] Issue #219 `Move registry container image from Fedora-Dockerfiles GitHub into DistGit`

[Adam Miller]

maxamillion added a new comment to an issue you are following:
``
bowlofeggs has already started a review request for the registry:

https://bugzilla.redhat.com/show_bug.cgi?id=1420568
``

To reply, visit the link below or just reply to this email
https://pagure.io/atomic-wg/issue/219
___
cloud mailing list -- cloud@lists.fedoraproject.org
To unsubscribe send an email to cloud-le...@lists.fedoraproject.org

[atomic-wg] Issue #213 `Move atpmic_scan_openscap container image from Fedora-Dockerfiles GitHub into DistGit`

[Adam Miller]

The status of the issue: `Move atpmic_scan_openscap container image from 
Fedora-Dockerfiles GitHub into DistGit` of project: `atomic-wg` has been 
updated to: Closed as Duplicate by maxamillion.

https://pagure.io/atomic-wg/issue/213
___
cloud mailing list -- cloud@lists.fedoraproject.org
To unsubscribe send an email to cloud-le...@lists.fedoraproject.org

[atomic-wg] Issue #223 `Move container-best-practices container image from Fedora-Dockerfiles GitHub into DistGit`

[Adam Miller]

maxamillion reported a new issue against the project: `atomic-wg` that you are 
following:
``
https://github.com/fedora-cloud/Fedora-Dockerfiles/tree/master/container-best-practices
``

To reply, visit the link below or just reply to this email
https://pagure.io/atomic-wg/issue/223
___
cloud mailing list -- cloud@lists.fedoraproject.org
To unsubscribe send an email to cloud-le...@lists.fedoraproject.org

[atomic-wg] Issue #222 `Move systemd-apache httpd container image from Fedora-Dockerfiles GitHub into DistGit`

[Adam Miller]

maxamillion reported a new issue against the project: `atomic-wg` that you are 
following:
``
https://github.com/fedora-cloud/Fedora-Dockerfiles/tree/master/systemd/apache
``

To reply, visit the link below or just reply to this email
https://pagure.io/atomic-wg/issue/222
___
cloud mailing list -- cloud@lists.fedoraproject.org
To unsubscribe send an email to cloud-le...@lists.fedoraproject.org

[atomic-wg] Issue #220 `Move earthquake container image from Fedora-Dockerfiles GitHub into DistGit`

[Adam Miller]

maxamillion reported a new issue against the project: `atomic-wg` that you are 
following:
``
https://github.com/fedora-cloud/Fedora-Dockerfiles/tree/master/earthquake
``

To reply, visit the link below or just reply to this email
https://pagure.io/atomic-wg/issue/220
___
cloud mailing list -- cloud@lists.fedoraproject.org
To unsubscribe send an email to cloud-le...@lists.fedoraproject.org

[atomic-wg] Issue #219 `Move registry container image from Fedora-Dockerfiles GitHub into DistGit`

[Adam Miller]

maxamillion reported a new issue against the project: `atomic-wg` that you are 
following:
``
https://github.com/fedora-cloud/Fedora-Dockerfiles/tree/master/registry
``

To reply, visit the link below or just reply to this email
https://pagure.io/atomic-wg/issue/219
___
cloud mailing list -- cloud@lists.fedoraproject.org
To unsubscribe send an email to cloud-le...@lists.fedoraproject.org

[atomic-wg] Issue #218 `Move postgresql container image from Fedora-Dockerfiles GitHub into DistGit`

[Adam Miller]

maxamillion reported a new issue against the project: `atomic-wg` that you are 
following:
``
https://github.com/fedora-cloud/Fedora-Dockerfiles/tree/master/postgresql
``

To reply, visit the link below or just reply to this email
https://pagure.io/atomic-wg/issue/218
___
cloud mailing list -- cloud@lists.fedoraproject.org
To unsubscribe send an email to cloud-le...@lists.fedoraproject.org

[atomic-wg] Issue #215 `Move redis httpd container image from Fedora-Dockerfiles GitHub into DistGit`

[Adam Miller]

maxamillion reported a new issue against the project: `atomic-wg` that you are 
following:
``
https://github.com/fedora-cloud/Fedora-Dockerfiles/tree/master/redis
``

To reply, visit the link below or just reply to this email
https://pagure.io/atomic-wg/issue/215
___
cloud mailing list -- cloud@lists.fedoraproject.org
To unsubscribe send an email to cloud-le...@lists.fedoraproject.org

[atomic-wg] Issue #213 `Move atpmic_scan_openscap container image from Fedora-Dockerfiles GitHub into DistGit`

[Adam Miller]

maxamillion reported a new issue against the project: `atomic-wg` that you are 
following:
``
https://github.com/fedora-cloud/Fedora-Dockerfiles/tree/master/atomic_scan_openscap
``

To reply, visit the link below or just reply to this email
https://pagure.io/atomic-wg/issue/213
___
cloud mailing list -- cloud@lists.fedoraproject.org
To unsubscribe send an email to cloud-le...@lists.fedoraproject.org

[atomic-wg] Issue #214 `Move tools container image from Fedora-Dockerfiles GitHub into DistGit`

[Adam Miller]

maxamillion reported a new issue against the project: `atomic-wg` that you are 
following:
``
https://github.com/fedora-cloud/Fedora-Dockerfiles/tree/master/tools
``

To reply, visit the link below or just reply to this email
https://pagure.io/atomic-wg/issue/214
___
cloud mailing list -- cloud@lists.fedoraproject.org
To unsubscribe send an email to cloud-le...@lists.fedoraproject.org

[atomic-wg] Issue #212 `Move qpid container image from Fedora-Dockerfiles GitHub into DistGit`

[Adam Miller]

maxamillion reported a new issue against the project: `atomic-wg` that you are 
following:
``
https://github.com/fedora-cloud/Fedora-Dockerfiles/tree/master/qpid
``

To reply, visit the link below or just reply to this email
https://pagure.io/atomic-wg/issue/212
___
cloud mailing list -- cloud@lists.fedoraproject.org
To unsubscribe send an email to cloud-le...@lists.fedoraproject.org

[atomic-wg] Issue #211 `Move rabbitmq container image from Fedora-Dockerfiles GitHub into DistGit`

[Adam Miller]

maxamillion reported a new issue against the project: `atomic-wg` that you are 
following:
``
https://github.com/fedora-cloud/Fedora-Dockerfiles/tree/master/rabbitmq
``

To reply, visit the link below or just reply to this email
https://pagure.io/atomic-wg/issue/211
___
cloud mailing list -- cloud@lists.fedoraproject.org
To unsubscribe send an email to cloud-le...@lists.fedoraproject.org

[atomic-wg] Issue #210 `Move systemd-systemd container image from Fedora-Dockerfiles GitHub into DistGit`

[Adam Miller]

maxamillion reported a new issue against the project: `atomic-wg` that you are 
following:
``
https://github.com/fedora-cloud/Fedora-Dockerfiles/tree/master/systemd/systemd
``

To reply, visit the link below or just reply to this email
https://pagure.io/atomic-wg/issue/210
___
cloud mailing list -- cloud@lists.fedoraproject.org
To unsubscribe send an email to cloud-le...@lists.fedoraproject.org

[atomic-wg] Issue #208 `Move mariadb container image from Fedora-Dockerfiles GitHub into DistGit`

[Adam Miller]

maxamillion reported a new issue against the project: `atomic-wg` that you are 
following:
``
https://github.com/fedora-cloud/Fedora-Dockerfiles/tree/master/mariadb
``

To reply, visit the link below or just reply to this email
https://pagure.io/atomic-wg/issue/208
___
cloud mailing list -- cloud@lists.fedoraproject.org
To unsubscribe send an email to cloud-le...@lists.fedoraproject.org

[atomic-wg] Issue #207 `Move couchdb container image from Fedora-Dockerfiles GitHub into DistGit`

[Adam Miller]

maxamillion reported a new issue against the project: `atomic-wg` that you are 
following:
``
https://github.com/fedora-cloud/Fedora-Dockerfiles/tree/master/couchdb
``

To reply, visit the link below or just reply to this email
https://pagure.io/atomic-wg/issue/207
___
cloud mailing list -- cloud@lists.fedoraproject.org
To unsubscribe send an email to cloud-le...@lists.fedoraproject.org

[atomic-wg] Issue #206 `Move nginx container image from Fedora-Dockerfiles GitHub into DistGit`

[Adam Miller]

maxamillion reported a new issue against the project: `atomic-wg` that you are 
following:
``
https://github.com/fedora-cloud/Fedora-Dockerfiles/tree/master/nginx
``

To reply, visit the link below or just reply to this email
https://pagure.io/atomic-wg/issue/206
___
cloud mailing list -- cloud@lists.fedoraproject.org
To unsubscribe send an email to cloud-le...@lists.fedoraproject.org

[atomic-wg] Issue #205 `Move memcached container image from Fedora-Dockerfiles GitHub into DistGit `

[Adam Miller]

maxamillion reported a new issue against the project: `atomic-wg` that you are 
following:
``
https://github.com/fedora-cloud/Fedora-Dockerfiles/tree/master/memcached
``

To reply, visit the link below or just reply to this email
https://pagure.io/atomic-wg/issue/205
___
cloud mailing list -- cloud@lists.fedoraproject.org
To unsubscribe send an email to cloud-le...@lists.fedoraproject.org

[atomic-wg] Issue #204 `Move ssh container image from Fedora-Dockerfiles GitHub into DistGit `

[Adam Miller]

maxamillion reported a new issue against the project: `atomic-wg` that you are 
following:
``
https://github.com/fedora-cloud/Fedora-Dockerfiles/tree/master/ssh
``

To reply, visit the link below or just reply to this email
https://pagure.io/atomic-wg/issue/204
___
cloud mailing list -- cloud@lists.fedoraproject.org
To unsubscribe send an email to cloud-le...@lists.fedoraproject.org

[atomic-wg] Issue #203 `Move apache httpd container image from Fedora-Dockerfiles GitHub into DistGit`

[Adam Miller]

maxamillion reported a new issue against the project: `atomic-wg` that you are 
following:
``
https://github.com/fedora-cloud/Fedora-Dockerfiles/tree/master/apache
``

To reply, visit the link below or just reply to this email
https://pagure.io/atomic-wg/issue/203
___
cloud mailing list -- cloud@lists.fedoraproject.org
To unsubscribe send an email to cloud-le...@lists.fedoraproject.org

[atomic-wg] Issue #200 `Planning for interim container releases: To rebuild or not rebuild?`

[Adam Miller]

maxamillion added a new comment to an issue you are following:
``
> We should do what's needed to ensure that our images pick up the most recent 
> rpms -- when you say rebuild all content, do you mean rebuild the rpms 
> themselves, or rebuild all the images?

Sorry for lack of clarification, I meant "Rebuild all images" which would pull 
in the latest stable rpms without requiring maintainer intervention.

``

To reply, visit the link below or just reply to this email
https://pagure.io/atomic-wg/issue/200
___
cloud mailing list -- cloud@lists.fedoraproject.org
To unsubscribe send an email to cloud-le...@lists.fedoraproject.org

[atomic-wg] Issue #202 `Syncing released Fedora container images to Docker Hub`

[Adam Miller]

maxamillion reported a new issue against the project: `atomic-wg` that you are 
following:
``
Currently the plan is to sync all container images from Fedora's Registry to 
the Docker Hub. Do we want to do this under the current [fedora 
namespace](https://hub.docker.com/u/fedora/) or create a new one? If we'd like 
to keep the current namespace, we will need to coordinate a transfer of 
ownership to either the Fedora Infrastructure or Fedora Release Engineering 
Team so that the task can be automated.
``

To reply, visit the link below or just reply to this email
https://pagure.io/atomic-wg/issue/202
___
cloud mailing list -- cloud@lists.fedoraproject.org
To unsubscribe send an email to cloud-le...@lists.fedoraproject.org

[atomic-wg] Issue #201 `Planning for the first Atomic VFAD`

[Adam Miller]

maxamillion reported a new issue against the project: `atomic-wg` that you are 
following:
``
Following along with the [proposal that reached general consensus on the 
mailing 
list](https://lists.fedoraproject.org/archives/list/cloud@lists.fedoraproject.org/message/2QXK5JSLBMPSNYOWIF3272R45PQT6UZB/),
 I would like to take some time to schedule what work we will do on the very 
first Atomic VFAD. My initial proposal for what to work on is to move the 
[Fedora-Dockerfiles](https://github.com/fedora-cloud/Fedora-Dockerfiles) from 
GitHub into DistGit.

I will also write up this workflow somewhere in the Cloud Wiki space (we should 
really move that to Atomic).
``

To reply, visit the link below or just reply to this email
https://pagure.io/atomic-wg/issue/201
___
cloud mailing list -- cloud@lists.fedoraproject.org
To unsubscribe send an email to cloud-le...@lists.fedoraproject.org

[atomic-wg] Issue #200 `Planning for interim container releases: To rebuild or not rebuild?`

[Adam Miller]

maxamillion reported a new issue against the project: `atomic-wg` that you are 
following:
``
The upstream OSBS development group has had to push out the deadlines for the 
automated rebuild work and Factory 2.0 isn't ready yet (it wasn't planned to 
be, but it is noted for posterity) which means that Fedora needs to make a 
decision on how we will handle container image updates. We're targeting 
releases every two weeks but in order to get rpm content updates automatically 
included and parent image update inheritance taken into consideration we will 
need to write some automation tooling to accomplish that until both OSBS 
layered rebuilds are done and Factory 2.0 rpm-content triggered rebuild work is 
completed. 

The question to the group is: do we want to force a rebuild of all content 
before each container image release (likely the day before) in the mean time?

The reason we can't realistically detect when/if content changes that would 
require a rebuild is because the Factory 2.0 work that is still ongoing is what 
will create the content database(PDC/resultsdb) to track the relationship 
between a set of rpms and a container image.
``

To reply, visit the link below or just reply to this email
https://pagure.io/atomic-wg/issue/200
___
cloud mailing list -- cloud@lists.fedoraproject.org
To unsubscribe send an email to cloud-le...@lists.fedoraproject.org

Re: Fedora Atomic WG Workflow Proposal

[Adam Miller]

On Thu, Jan 12, 2017 at 12:02 PM, Adam Miller
<maxamill...@fedoraproject.org> wrote:
> On Wed, Jan 11, 2017 at 4:50 PM, Adam Miller
> <maxamill...@fedoraproject.org> wrote:
>> Hello all,
>> Recently I attempted to start a mailing list thread that was the
>> product of a discussion on IRC about putting together an Atomic WG
>> workshop session[0] at DevConf[1].
>>
>> This was then discussed during today's Atomic WG Meeting[2] where it
>> was decided that we should make this Workshop into a re-occurring
>> Virtual Fedora Activity Day(FAD[3]) instead taking place every 2
>> months.
>>
>> I would like to propose the following:
>> Each Virtual FAD occurs on a Thursday, the day after a Fedora
>> Atomic WG meeting such that we can use the meeting the day before to
>> plan out the work to be done at the Virtual FAD. All work will be
>> tracked in a kanban[4] board, I've created one for this purpose in
>> Fedora's Taiga instance[5] (Note: I don't know why my FAS name is in
>> the URL, Taiga just does that).
>> In the kanban board, we would create cards in the NEW column
>> through out the two month cycle between Virtual FADs (these should
>> correlate to tickets in pagure[6]), then on the meeting before the FAD
>> we would "groom" the NEW cards that we want to accomplish on the
>> following day of the Virtual FAD, these "groomed" cards would be
>> placed into the READY column to signify they are ready to be worked
>> on. On the day of the VFAD, participants/contributors would then
>> assign a card to themselves that they want to work on, and move the
>> card into "IN PROGRESS" so that everyone knows what is being worked on
>> and nobody attempts to work on the same thing (unless that's
>> intentional, in that case both people's names should be listed in the
>> card description for reference). Once a task is done, then it should
>> be moved to the DONE column. This will give a good reflection of what
>> work was accomplished during the VFAD and we can (optionally) have a
>> retrospective meeting after the VFAD about what went well, what didn't
>> go well, and what we could do better next time. Also the day before
>> the next VFAD at the start of the "grooming" session (the weekly
>> Atomic WG meeting), all the previous VFAD's cards in the DONE column
>> from the previous VFAD should be moved to ARCHIVED for posterity.
>>
>> Cards created should be units of work that can feasibly be
>> accomplished in a day or less worth of work.
>
> Based on previous feedback in the thread I have come with a modified
> proposal (effectively the same, just a different tracking mechanism so
> we're doing everything in one place).
>
> Modifications to proposal:
> We will create a Pagure Roadmap Milestone[0] for each Virtual FAD,
> items that we want to accomplish in that VFAD that we groom in the
> meeting before the VFAD will be assigned to that milestone. From there
> we will create the Pagure Labels: NEW and IN_PROGRESS (we can
> un-capitalize or format differently if anyone has a preference).
> Everyone will also create a Pagure Label with their FAS name that can
> be applied to Issue Tickets that people are working on (this will also
> be nice because a Ticket can have multiple labels so if multiple
> people are working on a single Ticket, we can track that).
> Tickets will be given the NEW Label when they are assigned to a
> Milestone during grooming. On the day of the VFAD, at the point in
> time someone wants to work on something: the NEW Label is removed, he
> IN_PROGRESS Label is applied, and the FAS account name Label of the
> person(s) working on the Ticket is added. Once a Ticket is complete:
> the IN_PROGRESS label should be removed, and the Ticket Closed. This
> will leave it  in the Milestone of the VFAD but mark it as Closed,
> effectively both completing it and archiving it.
>
> I created a milestone demo and added everyone from the atomic-wg[1]
> pagure repo there in case anyone wants to play around with the
> proposed workflow[0].
>
> Also as a side, we should really have an atomic-wg FAS group. :)
>
> Thoughts?

Thread bump. Anyone had a chance to read this? Any comments?

-AdamM

>
> Thanks,
> -AdamM
>
> [0] - https://pagure.io/milestones-demo/roadmap
> [1] - https://pagure.io/atomic-wg
>
>>
>> I would like to ultimately propose we move to a more iterative cycle
>> where we use this workflow weekly instead of dedicating a single day
>> every 2 months (these periods of time are often known as a "sprint" in
>> Agile[7]) but my hope is that t

Re: Fedora Atomic WG Workflow Proposal

[Adam Miller]

On Wed, Jan 11, 2017 at 4:50 PM, Adam Miller
<maxamill...@fedoraproject.org> wrote:
> Hello all,
> Recently I attempted to start a mailing list thread that was the
> product of a discussion on IRC about putting together an Atomic WG
> workshop session[0] at DevConf[1].
>
> This was then discussed during today's Atomic WG Meeting[2] where it
> was decided that we should make this Workshop into a re-occurring
> Virtual Fedora Activity Day(FAD[3]) instead taking place every 2
> months.
>
> I would like to propose the following:
> Each Virtual FAD occurs on a Thursday, the day after a Fedora
> Atomic WG meeting such that we can use the meeting the day before to
> plan out the work to be done at the Virtual FAD. All work will be
> tracked in a kanban[4] board, I've created one for this purpose in
> Fedora's Taiga instance[5] (Note: I don't know why my FAS name is in
> the URL, Taiga just does that).
> In the kanban board, we would create cards in the NEW column
> through out the two month cycle between Virtual FADs (these should
> correlate to tickets in pagure[6]), then on the meeting before the FAD
> we would "groom" the NEW cards that we want to accomplish on the
> following day of the Virtual FAD, these "groomed" cards would be
> placed into the READY column to signify they are ready to be worked
> on. On the day of the VFAD, participants/contributors would then
> assign a card to themselves that they want to work on, and move the
> card into "IN PROGRESS" so that everyone knows what is being worked on
> and nobody attempts to work on the same thing (unless that's
> intentional, in that case both people's names should be listed in the
> card description for reference). Once a task is done, then it should
> be moved to the DONE column. This will give a good reflection of what
> work was accomplished during the VFAD and we can (optionally) have a
> retrospective meeting after the VFAD about what went well, what didn't
> go well, and what we could do better next time. Also the day before
> the next VFAD at the start of the "grooming" session (the weekly
> Atomic WG meeting), all the previous VFAD's cards in the DONE column
> from the previous VFAD should be moved to ARCHIVED for posterity.
>
> Cards created should be units of work that can feasibly be
> accomplished in a day or less worth of work.

Based on previous feedback in the thread I have come with a modified
proposal (effectively the same, just a different tracking mechanism so
we're doing everything in one place).

Modifications to proposal:
We will create a Pagure Roadmap Milestone[0] for each Virtual FAD,
items that we want to accomplish in that VFAD that we groom in the
meeting before the VFAD will be assigned to that milestone. From there
we will create the Pagure Labels: NEW and IN_PROGRESS (we can
un-capitalize or format differently if anyone has a preference).
Everyone will also create a Pagure Label with their FAS name that can
be applied to Issue Tickets that people are working on (this will also
be nice because a Ticket can have multiple labels so if multiple
people are working on a single Ticket, we can track that).
Tickets will be given the NEW Label when they are assigned to a
Milestone during grooming. On the day of the VFAD, at the point in
time someone wants to work on something: the NEW Label is removed, he
IN_PROGRESS Label is applied, and the FAS account name Label of the
person(s) working on the Ticket is added. Once a Ticket is complete:
the IN_PROGRESS label should be removed, and the Ticket Closed. This
will leave it  in the Milestone of the VFAD but mark it as Closed,
effectively both completing it and archiving it.

I created a milestone demo and added everyone from the atomic-wg[1]
pagure repo there in case anyone wants to play around with the
proposed workflow[0].

Also as a side, we should really have an atomic-wg FAS group. :)

Thoughts?

Thanks,
-AdamM

[0] - https://pagure.io/milestones-demo/roadmap
[1] - https://pagure.io/atomic-wg

>
> I would like to ultimately propose we move to a more iterative cycle
> where we use this workflow weekly instead of dedicating a single day
> every 2 months (these periods of time are often known as a "sprint" in
> Agile[7]) but my hope is that this is a good place to start and we can
> improve over time.
>
> If this is acceptable as a change we would like to adopt as a group, I
> am happy to pre-populate the kanban board with work items we had
> previously discussed that we wanted to accomplish as the original
> agenda to the (now defunct) DevConf Workshop. From there I would
> propose that the first meeting after DevConf  (2017-02-01) be used as
> the first grooming session and the following Thursday be the first
> VFAD (2017-02-02). From there we wou

Re: Fedora Atomic WG Workflow Proposal

[Adam Miller]

On Thu, Jan 12, 2017 at 8:22 AM, Mike Ruckman <ro...@fedoraproject.org> wrote:
> On Wed, 11 Jan 2017 16:50:03 -0600
> Adam Miller <maxamill...@fedoraproject.org> wrote:
>
> 
>
>>
>> Cards created should be units of work that can feasibly be
>> accomplished in a day or less worth of work.
>>
>> I would like to ultimately propose we move to a more iterative cycle
>> where we use this workflow weekly instead of dedicating a single day
>> every 2 months (these periods of time are often known as a "sprint" in
>> Agile[7]) but my hope is that this is a good place to start and we can
>> improve over time.
>
> I'm in favor of both the vFAD every 2 months as well has utilizing the
> board for a more iterative workflow. It'd be nice if there was some
> integration between pagure and tiaga so we didn't have to duplicate
> information (as Dusty pointed out). Overall I think it's a good idea,
> and even if we duplicate some information the first time around, it'll
> give us a good idea of how we want to do it different the next time.

I agree the potential duplication of information could become
problematic (and likely will). I'll look into Pagure Milestones and
see if I can't come up with a proposal of workflow using that.

-AdamM

>
>> If this is acceptable as a change we would like to adopt as a group, I
>> am happy to pre-populate the kanban board with work items we had
>> previously discussed that we wanted to accomplish as the original
>> agenda to the (now defunct) DevConf Workshop. From there I would
>> propose that the first meeting after DevConf  (2017-02-01) be used as
>> the first grooming session and the following Thursday be the first
>> VFAD (2017-02-02). From there we would set a schedule for every 2
>> months to have a VFAD.
>>
>> If everyone is in agreement, I'll also get a section of the Wiki page
>> (which we need to move out of the Cloud namespace) added to document
>> this workflow for newcomers who would like to join the Atomic WG.
>>
>> Thank you,
>> -AdamM
>>
>>
>> [0] -
>> https://lists.fedoraproject.org/archives/list/cloud@lists.fedoraproject.org/thread/WBTWBLOYWG66EDXJO2I4G3XY3X6EFAIF/
>> [1] - https://devconf.cz/index.html [2] -
>> https://lists.fedoraproject.org/archives/list/cloud@lists.fedoraproject.org/thread/36EBX5WS36OSO57GDWBJVIU6CXRXT237/
>> [3] - https://fedoraproject.org/wiki/Fedora_Activity_Day_-_FAD [4] -
>> https://en.wikipedia.org/wiki/Kanban [5] -
>> https://taiga.fedorainfracloud.org/project/maxamillion-fedora-atomic-wg/kanban
>> [6] - https://pagure.io/atomic-wg/issues [7] -
>> https://en.wikipedia.org/wiki/Agile_software_development
>
>
>
>
> --
> // Mike
> --
> Fedora QA
> freenode: roshi
> http://roshi.fedorapeople.org
>
> ___
> cloud mailing list -- cloud@lists.fedoraproject.org
> To unsubscribe send an email to cloud-le...@lists.fedoraproject.org
>
___
cloud mailing list -- cloud@lists.fedoraproject.org
To unsubscribe send an email to cloud-le...@lists.fedoraproject.org

Re: Fedora Atomic WG Workflow Proposal

[Adam Miller]

On Wed, Jan 11, 2017 at 10:05 PM, Dusty Mabe <du...@dustymabe.com> wrote:
>
>
> On 01/11/2017 05:50 PM, Adam Miller wrote:
>> Hello all,
>> Recently I attempted to start a mailing list thread that was the
>> product of a discussion on IRC about putting together an Atomic WG
>> workshop session[0] at DevConf[1].
>>
>> This was then discussed during today's Atomic WG Meeting[2] where it
>> was decided that we should make this Workshop into a re-occurring
>> Virtual Fedora Activity Day(FAD[3]) instead taking place every 2
>> months.
>>
>> I would like to propose the following:
>> Each Virtual FAD occurs on a Thursday, the day after a Fedora
>> Atomic WG meeting such that we can use the meeting the day before to
>> plan out the work to be done at the Virtual FAD. All work will be
>> tracked in a kanban[4] board, I've created one for this purpose in
>> Fedora's Taiga instance[5] (Note: I don't know why my FAS name is in
>> the URL, Taiga just does that).
>> In the kanban board, we would create cards in the NEW column
>> through out the two month cycle between Virtual FADs (these should
>> correlate to tickets in pagure[6]), then on the meeting before the FAD
>> we would "groom" the NEW cards that we want to accomplish on the
>> following day of the Virtual FAD, these "groomed" cards would be
>> placed into the READY column to signify they are ready to be worked
>> on. On the day of the VFAD, participants/contributors would then
>> assign a card to themselves that they want to work on, and move the
>> card into "IN PROGRESS" so that everyone knows what is being worked on
>> and nobody attempts to work on the same thing (unless that's
>> intentional, in that case both people's names should be listed in the
>> card description for reference). Once a task is done, then it should
>> be moved to the DONE column. This will give a good reflection of what
>> work was accomplished during the VFAD and we can (optionally) have a
>> retrospective meeting after the VFAD about what went well, what didn't
>> go well, and what we could do better next time. Also the day before
>> the next VFAD at the start of the "grooming" session (the weekly
>> Atomic WG meeting), all the previous VFAD's cards in the DONE column
>> from the previous VFAD should be moved to ARCHIVED for posterity.
>
> This sounds good but I'm not sure I'm ready to have work items broken
> out into another place. Could we get something close by using labels
> on issues in pagure? Really what I'm trying to do here is prevent
> extra overhead and also prevent duplicated information where there is
> a question of what is right and what is wrong?
>

Not to the best of my knowledge. Pagure doesn't have a feature that is
similar to a kanban board and I don't know of a way to structure the
labels that would really make the work track-able using them. If we
can generate a report view of the labels, maybe it would work but then
we'd end up with a lot of tickets and cross-linking tickets to
correlate small units of work with the original ticket. (Which might
be fine, but I thought I'd point that out as a concern).

There is the Roadmap view in Pagure (example[0]) and we could
potentially come up with a convention around that.

In my original proposal, I was thinking that tickets would be the
similar to an "Epic" such that small tasks that roll up under a more
broad statement of work would exist in Taiga (we could even make a
Tagia label for each ticket and label cards accordingly for easy
filter/reporting) and the broad statement of work (epic) would live in
Taiga. I probably didn't articulate this well.

My desire to use Taiga for this is not at all a slight at Pagure, it's
a fine tool, but we're moving into the space of Project Management and
out of the space of Git Forge which Pagure just isn't currently
targeting for the former with it's feature set.

However, if Pagure was to add a kanban-style view/UX similar to GitHub
Projects[1] then I wouldn't consider suggesting Taiga and if we were
to go the route of the initial proposal (or even sort out a way to
make pagure lables/milestones work), we could certainly transition in
the future.


>>
>> Cards created should be units of work that can feasibly be
>> accomplished in a day or less worth of work.
>>
>> I would like to ultimately propose we move to a more iterative cycle
>> where we use this workflow weekly instead of dedicating a single day
>> every 2 months (these periods of time are often known as a "sprint" in
>> Agile[7]) but my hope is that this is a good place to start and we can
>> improve over time.
>>
>> If this is accepta

Fedora Atomic WG Workflow Proposal

[Adam Miller]

Hello all,
Recently I attempted to start a mailing list thread that was the
product of a discussion on IRC about putting together an Atomic WG
workshop session[0] at DevConf[1].

This was then discussed during today's Atomic WG Meeting[2] where it
was decided that we should make this Workshop into a re-occurring
Virtual Fedora Activity Day(FAD[3]) instead taking place every 2
months.

I would like to propose the following:
Each Virtual FAD occurs on a Thursday, the day after a Fedora
Atomic WG meeting such that we can use the meeting the day before to
plan out the work to be done at the Virtual FAD. All work will be
tracked in a kanban[4] board, I've created one for this purpose in
Fedora's Taiga instance[5] (Note: I don't know why my FAS name is in
the URL, Taiga just does that).
In the kanban board, we would create cards in the NEW column
through out the two month cycle between Virtual FADs (these should
correlate to tickets in pagure[6]), then on the meeting before the FAD
we would "groom" the NEW cards that we want to accomplish on the
following day of the Virtual FAD, these "groomed" cards would be
placed into the READY column to signify they are ready to be worked
on. On the day of the VFAD, participants/contributors would then
assign a card to themselves that they want to work on, and move the
card into "IN PROGRESS" so that everyone knows what is being worked on
and nobody attempts to work on the same thing (unless that's
intentional, in that case both people's names should be listed in the
card description for reference). Once a task is done, then it should
be moved to the DONE column. This will give a good reflection of what
work was accomplished during the VFAD and we can (optionally) have a
retrospective meeting after the VFAD about what went well, what didn't
go well, and what we could do better next time. Also the day before
the next VFAD at the start of the "grooming" session (the weekly
Atomic WG meeting), all the previous VFAD's cards in the DONE column
from the previous VFAD should be moved to ARCHIVED for posterity.

Cards created should be units of work that can feasibly be
accomplished in a day or less worth of work.

I would like to ultimately propose we move to a more iterative cycle
where we use this workflow weekly instead of dedicating a single day
every 2 months (these periods of time are often known as a "sprint" in
Agile[7]) but my hope is that this is a good place to start and we can
improve over time.

If this is acceptable as a change we would like to adopt as a group, I
am happy to pre-populate the kanban board with work items we had
previously discussed that we wanted to accomplish as the original
agenda to the (now defunct) DevConf Workshop. From there I would
propose that the first meeting after DevConf  (2017-02-01) be used as
the first grooming session and the following Thursday be the first
VFAD (2017-02-02). From there we would set a schedule for every 2
months to have a VFAD.

If everyone is in agreement, I'll also get a section of the Wiki page
(which we need to move out of the Cloud namespace) added to document
this workflow for newcomers who would like to join the Atomic WG.

Thank you,
-AdamM


[0] - 
https://lists.fedoraproject.org/archives/list/cloud@lists.fedoraproject.org/thread/WBTWBLOYWG66EDXJO2I4G3XY3X6EFAIF/
[1] - https://devconf.cz/index.html
[2] - 
https://lists.fedoraproject.org/archives/list/cloud@lists.fedoraproject.org/thread/36EBX5WS36OSO57GDWBJVIU6CXRXT237/
[3] - https://fedoraproject.org/wiki/Fedora_Activity_Day_-_FAD
[4] - https://en.wikipedia.org/wiki/Kanban
[5] - 
https://taiga.fedorainfracloud.org/project/maxamillion-fedora-atomic-wg/kanban
[6] - https://pagure.io/atomic-wg/issues
[7] - https://en.wikipedia.org/wiki/Agile_software_development
___
cloud mailing list -- cloud@lists.fedoraproject.org
To unsubscribe send an email to cloud-le...@lists.fedoraproject.org

Re: Fedora Cloud DevConf Workshop

[Adam Miller]

On Tue, Jan 10, 2017 at 12:55 PM, Adam Miller
<maxamill...@fedoraproject.org> wrote:
> On Tue, Jan 10, 2017 at 12:52 PM, Adam Miller
> <maxamill...@fedoraproject.org> wrote:
>> Hello all,
>>During the last Fedora Cloud/Atomic WG meeting jberkus brought up
>> the idea of having a workshop at DevConf to tackle some Layered Image
>> items which we, at the time, seemed in agreement on. Josh and I were
>> talking on irc today and I wanted to make a proposal to the list and
>> find out what others thought.
>>
>> Meeting Time: 14:00 (localtime at DevConf)
>> Meeting Location: TBD
>> Virtual-Meeting Location: #fedora-cloud
>>
>> Work-Tracking (we should make cards for tasks):
>> 
>> https://taiga.fedorainfracloud.org/project/maxamillion-fedora-layered-images/kanban
>>
>> Work to accomplish:
>
> I accidentally hit "send" 
>
> Work to accomplish:
> - Discuss and improve current Dockerfile guidelines[0]
> - Move as many fedora-dockerfiles[1] from github into distgit as possible
> - $Your_Suggestion_Here
>
> I'm open to other suggestions on any of this, but wanted to get the
> discussion started because DevConf is just a couple weeks away.

This was discussed in today's Atomic WG Meeting and it was proposed
that we come up with a more generic re-occurring Virtual Fedora
Activity Day. I will start a new thread with that information as well
as documentation around the proposal.

-AdamM

>
> -AdamM
>
> [0] - https://fedoraproject.org/wiki/Container:Guidelines
> [1] - https://github.com/fedora-cloud/Fedora-Dockerfiles
___
cloud mailing list -- cloud@lists.fedoraproject.org
To unsubscribe send an email to cloud-le...@lists.fedoraproject.org

[atomic-wg] Issue #180 `Future of Fedora Dockerfiles`

[Adam Miller]

maxamillion added a new comment to an issue you are following:
``
Proposal for Workshop to work on this stuff at DevConf sent to the mailing list 
-> 
https://lists.fedoraproject.org/archives/list/cloud@lists.fedoraproject.org/thread/WBTWBLOYWG66EDXJO2I4G3XY3X6EFAIF/
``

To reply, visit the link below or just reply to this email
https://pagure.io/atomic-wg/issue/180
___
cloud mailing list -- cloud@lists.fedoraproject.org
To unsubscribe send an email to cloud-le...@lists.fedoraproject.org

Re: Proposal: require DESCRIPTION, USAGE label for images

[Adam Miller]

On Tue, Jan 10, 2017 at 1:47 PM, Josh Berkus  wrote:
> On 01/10/2017 10:52 AM, Matthew Miller wrote:
>> On Tue, Jan 10, 2017 at 10:44:03AM -0800, Josh Berkus wrote:
 On Tue, Jan 10, 2017 at 10:33:05AM -0800, Josh Berkus wrote:
>>   USAGE: single command line giving usage example
>>  for invoking the container; will be "N/A" for
>>  some containers.

 Why N/A? What circumstances would this be?
>>> CNI Networking container for Kubernetes, for example.  A bunch of
>>> "infra" containers only get invoked by other containers and/or the
>>> orchestration system.
>>
>> Could we develop standard wording for that? Like
>>
>>   USAGE: Invoked by $OTHERCONTAINER
>>
>> or
>>
>>   USAGE: Invoked by Kubernetes when $WHATEVERTRIGGERS
>>
>> or are there too many possibilities?
>
> I don't think there are.  I'd suggest:
>
> ---
>
> USAGE: Invoked by $SOMEPROCESS.  Not for direct use.
>
> "$SOMEPROCESS" should be the name of the infrastructure tool, container,
> or other utility which consumes this container.
>
> ---
>

+1 - I like that idea, makes it very clear to the user.

-AdamM

> --
> --
> Josh Berkus
> Project Atomic
> Red Hat OSAS
> ___
> cloud mailing list -- cloud@lists.fedoraproject.org
> To unsubscribe send an email to cloud-le...@lists.fedoraproject.org
___
cloud mailing list -- cloud@lists.fedoraproject.org
To unsubscribe send an email to cloud-le...@lists.fedoraproject.org

Re: Fedora Cloud DevConf Workshop

[Adam Miller]

On Tue, Jan 10, 2017 at 12:52 PM, Adam Miller
<maxamill...@fedoraproject.org> wrote:
> Hello all,
>During the last Fedora Cloud/Atomic WG meeting jberkus brought up
> the idea of having a workshop at DevConf to tackle some Layered Image
> items which we, at the time, seemed in agreement on. Josh and I were
> talking on irc today and I wanted to make a proposal to the list and
> find out what others thought.
>
> Meeting Time: 14:00 (localtime at DevConf)
> Meeting Location: TBD
> Virtual-Meeting Location: #fedora-cloud
>
> Work-Tracking (we should make cards for tasks):
> 
> https://taiga.fedorainfracloud.org/project/maxamillion-fedora-layered-images/kanban
>
> Work to accomplish:

I accidentally hit "send" 

Work to accomplish:
- Discuss and improve current Dockerfile guidelines[0]
- Move as many fedora-dockerfiles[1] from github into distgit as possible
- $Your_Suggestion_Here

I'm open to other suggestions on any of this, but wanted to get the
discussion started because DevConf is just a couple weeks away.

-AdamM

[0] - https://fedoraproject.org/wiki/Container:Guidelines
[1] - https://github.com/fedora-cloud/Fedora-Dockerfiles
___
cloud mailing list -- cloud@lists.fedoraproject.org
To unsubscribe send an email to cloud-le...@lists.fedoraproject.org

Fedora Cloud DevConf Workshop

[Adam Miller]

Hello all,
   During the last Fedora Cloud/Atomic WG meeting jberkus brought up
the idea of having a workshop at DevConf to tackle some Layered Image
items which we, at the time, seemed in agreement on. Josh and I were
talking on irc today and I wanted to make a proposal to the list and
find out what others thought.

Meeting Time: 14:00 (localtime at DevConf)
Meeting Location: TBD
Virtual-Meeting Location: #fedora-cloud

Work-Tracking (we should make cards for tasks):

https://taiga.fedorainfracloud.org/project/maxamillion-fedora-layered-images/kanban

Work to accomplish:
___
cloud mailing list -- cloud@lists.fedoraproject.org
To unsubscribe send an email to cloud-le...@lists.fedoraproject.org

Re: Proposal: require DESCRIPTION, USAGE label for images

[Adam Miller]

On Tue, Dec 13, 2016 at 3:24 PM, Josh Berkus  wrote:
> Folks,
>
> Looking at the new FDLIBS, I'm noticing that there's not a narrative
> description of the image required or provided anywhere that I can find.
> Clearly one is needed for users.  So, here's a proposal:
>
> New Required LABELs:
>
> USAGE: single command line giving usage example
>  for invoking the container; will be "N/A" for
>  some containers.
>
> DESCRIPTION: Narrative description incuding:
>   * What service/software it provides
>   * What specific purpose it fulfills, if required
>   * Notes on how to use it, if not covered by USAGE,
> such as how to supply configuration files
>   * Depedencies on other images (e.g. "requires a database")
>   * Links to documentation for the Software, if any
>

+1 - I like this, it follows nicely with the upstream guidelines[0]
referenced in Fedora's that I'd like to further adopt as all of this
evolves in Fedora space.

I'd also at some point like to discuss the labels needed for atomic
app install/uninstall and OpenShift guidelines[1] that we should at
least provide information on how to offer the 'atomic install' and
OpenShift deployment functionality for a container to users.

-AdamM

[0] - https://github.com/projectatomic/ContainerApplicationGenericLabels
[1] - 
https://docs.openshift.org/latest/creating_images/guidelines.html#openshift-specific-guidelines

> --
> --
> Josh Berkus
> Project Atomic
> Red Hat OSAS
> ___
> cloud mailing list -- cloud@lists.fedoraproject.org
> To unsubscribe send an email to cloud-le...@lists.fedoraproject.org
___
cloud mailing list -- cloud@lists.fedoraproject.org
To unsubscribe send an email to cloud-le...@lists.fedoraproject.org

Re: Announcement: Fedora Docker Layered Image Build Service is GO!

[Adam Miller]

On Tue, Dec 13, 2016 at 4:18 PM, Adam Miller
<maxamill...@fedoraproject.org> wrote:
> On Tue, Dec 13, 2016 at 2:52 PM, Igor Gnatenko <ignate...@redhat.com> wrote:
>> On Tue, Dec 13, 2016 at 8:36 PM, Adam Miller
>> <maxamill...@fedoraproject.org> wrote:
>>> It is with great pleasure that the Fedora Project Announces the availability
>>> of the Fedora Docker Layered Image Build Service[0] to the Fedora 
>>> Contributor
>>> Community!
>>>
>>> With this announcement we are opening availability of the Docker Layered
>>> Image Build Service for the Docker Layered Images[1] that the Fedora Cloud
>>> SIG[2] has been the primary maintainers[3] of on GitHub into DistGit as
>>> official components of Fedora. From there we will be extending an invitation
>>> to all Fedora Contributors to maintain Docker Layered Image Containers for
>>> official release by the Fedora Project. Currently this effort is to enable
>>> the Fedora Cloud/Atomic WG[2] goals which target Fedora Atomic Host[4] as a
>>> primary deliverable to power the future of Cloud. This is also to enable the
>>> Fedora Modularity[5] work be delivered as Containers in the future as Fedora
>>> becomes fundamentally more modular in nature.
>>>
>>> How do I get started?
>>>
>>> Contributors will go through a simliar process as what they currently do
>>> with RPM Review Requests. There will be Container Reviews as well as
>>> Container Guidelines:
>>>
>>> https://fedoraproject.org/wiki/Container:Review_Process
>>> https://fedoraproject.org/wiki/Container:Guidelines
>> Nice job!
>>
>> I have couple of questions:
>> * why "FROM fedora:25", how do I choose version on which I want to
>> base container?
>
> The 'FROM fedora:25' line should coordinate with the branch of DistGit
> you're working in. Since Docker doesn't have a mechanism like RPMs do
> with macros where we can parameterize things like that, we just have
> to define it for now (we may later change it to where the 'FROM
> fedora:$version' is inferred and something makes a modification to the
> Dockerfile before building.
>
>> * is there containers in registry for rawhide?
>
> There are not at this moment, only for Fedora 24 and Fedora 25. I hope
> to have rawhide enabled very soon though. The layout of DistGit
> branches correlated to Fedora release information fed into the Build
> System is something that needs be sorted since "branched" Fedora
> Releases have a version number tied to DistGit but Rawhide is
> technically f26 right now. I'll update as soon as this is live.

Rawhide is now live, you can 'fedpkg container-build' from DistGit
master branch just like you can 'fedpkg build' for rawhide RPMs.

Apologies for the delay,
-AdamM

>
> -AdamM
>
>>>
>>> At this time the Cloud/Atomic WG[2] will maintain the Guidelines as well as
>>> the Review Process along with input from all Fedora Contributors. This may
>>> change later with the formation of a Fedora Container Committee (similar to
>>> the Fedora Packaging Committee[6]).
>>>
>>> Please note that both the Guidelines and the Review Process are likely to
>>> evolve along with the Container technologies as we move into the future so
>>> we encourage community members to check the documentation for updates.
>>>
>>> For more information, please see the following Fedora Community Blog:
>>>
>>> 
>>> https://communityblog.fedoraproject.org/fedora-docker-layered-image-build-service-now-available/
>>>
>>> [0] - 
>>> https://fedoraproject.org/wiki/Changes/Layered_Docker_Image_Build_Service
>>> [1] - https://fedoraproject.org/wiki/Cloud
>>> [2] - 
>>> https://docs.docker.com/engine/userguide/storagedriver/imagesandcontainers/
>>> [3] - https://github.com/fedora-cloud/Fedora-Dockerfiles
>>> [4] - https://getfedora.org/en/atomic/download/
>>> [5] - https://fedoraproject.org/wiki/Modularity
>>> [6] - https://fedoraproject.org/wiki/Packaging_Committee
>>> ___
>>> devel mailing list -- de...@lists.fedoraproject.org
>>> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>>
>>
>>
>> --
>> -Igor Gnatenko
>> ___
>> devel mailing list -- de...@lists.fedoraproject.org
>> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
___
cloud mailing list -- cloud@lists.fedoraproject.org
To unsubscribe send an email to cloud-le...@lists.fedoraproject.org

Re: Announcement: Fedora Docker Layered Image Build Service is GO!

[Adam Miller]

On Thu, Dec 15, 2016 at 5:49 AM, Trishna Guha <trishnaguh...@gmail.com> wrote:
> On Wed, Dec 14, 2016 at 1:06 AM, Adam Miller
> <maxamill...@fedoraproject.org> wrote:
>> Contributors will go through a simliar process as what they currently do
>> with RPM Review Requests. There will be Container Reviews as well as
>> Container Guidelines:
>
> Absolutely great news.
>
> I have couple of questions regarding Container review process.
> After container build are we going to request updates for fedora
> release braches using Bodhi?
> As discussed in 15-12-2016 Atomic-wg meeting we are going to have
> taskotron automated testcases as well.
> Are these all going to use Bodhi interface like it happens for RPM packages?
>

At this time there will not be Bodhi updates, but there will be a
RelEng process that will perform releases every other week
(alternating with the weeks that we do Two Week Atomic Releases). Once
the Taskotron work is in place (being released soon), we'll have
automated testing happening on every container build in koji and then
there will be fedmsg data stored in datagrepper that we can query to
find out the latest version of a container that is successfully
passing all it's tests.

I'll update the wiki page with information about this.

-AdamM

>
> --
> Regards,
> Trishna Guha
>
> trishnaguh...@gmail.com
> trishnag.wordpress.com
> ___
> cloud mailing list -- cloud@lists.fedoraproject.org
> To unsubscribe send an email to cloud-le...@lists.fedoraproject.org
___
cloud mailing list -- cloud@lists.fedoraproject.org
To unsubscribe send an email to cloud-le...@lists.fedoraproject.org

Re: [DOC] Review Request for Fedora Atomic

[Adam Miller]

On Fri, Dec 2, 2016 at 3:12 AM, Trishna Guha  wrote:
> Hi,
>
> As discussed in Fedora Cloud FAD 2016, We had decided to focus on 
> Documentation for Fedora Atomic working group.
>
> Our Documentation is live on [1]. This is the work done so far on 
> documentation.
> We have some Pull requests opened [2] for the Documentation repository [3].
>
> Kushal and I have been working on the Documentation.
> It would be helpful if someone can review the PRs :-).
> Also if someone has any idea that we are missing any Doc please feel free to 
> reply to the thread
> or probably open issue here [4]? And Pull requests are most welcome ;-).

This is great! Thank you for working on this.

Were the pull requests requesting feedback ever looked at?

-AdamM

>
> [1] http://fedoracloud.readthedocs.io
> [2] https://github.com/fedora-cloud/fedoracloud/pulls
> [3] https://github.com/fedora-cloud/fedoracloud
> [4] https://github.com/fedora-cloud/fedoracloud/issues/new
>
>
> Thanks,
> Trishna
> ___
> cloud mailing list -- cloud@lists.fedoraproject.org
> To unsubscribe send an email to cloud-le...@lists.fedoraproject.org
___
cloud mailing list -- cloud@lists.fedoraproject.org
To unsubscribe send an email to cloud-le...@lists.fedoraproject.org

Re: Announcement: Fedora Docker Layered Image Build Service is GO!

[Adam Miller]

On Tue, Dec 13, 2016 at 2:52 PM, Igor Gnatenko <ignate...@redhat.com> wrote:
> On Tue, Dec 13, 2016 at 8:36 PM, Adam Miller
> <maxamill...@fedoraproject.org> wrote:
>> It is with great pleasure that the Fedora Project Announces the availability
>> of the Fedora Docker Layered Image Build Service[0] to the Fedora Contributor
>> Community!
>>
>> With this announcement we are opening availability of the Docker Layered
>> Image Build Service for the Docker Layered Images[1] that the Fedora Cloud
>> SIG[2] has been the primary maintainers[3] of on GitHub into DistGit as
>> official components of Fedora. From there we will be extending an invitation
>> to all Fedora Contributors to maintain Docker Layered Image Containers for
>> official release by the Fedora Project. Currently this effort is to enable
>> the Fedora Cloud/Atomic WG[2] goals which target Fedora Atomic Host[4] as a
>> primary deliverable to power the future of Cloud. This is also to enable the
>> Fedora Modularity[5] work be delivered as Containers in the future as Fedora
>> becomes fundamentally more modular in nature.
>>
>> How do I get started?
>>
>> Contributors will go through a simliar process as what they currently do
>> with RPM Review Requests. There will be Container Reviews as well as
>> Container Guidelines:
>>
>> https://fedoraproject.org/wiki/Container:Review_Process
>> https://fedoraproject.org/wiki/Container:Guidelines
> Nice job!
>
> I have couple of questions:
> * why "FROM fedora:25", how do I choose version on which I want to
> base container?

The 'FROM fedora:25' line should coordinate with the branch of DistGit
you're working in. Since Docker doesn't have a mechanism like RPMs do
with macros where we can parameterize things like that, we just have
to define it for now (we may later change it to where the 'FROM
fedora:$version' is inferred and something makes a modification to the
Dockerfile before building.

> * is there containers in registry for rawhide?

There are not at this moment, only for Fedora 24 and Fedora 25. I hope
to have rawhide enabled very soon though. The layout of DistGit
branches correlated to Fedora release information fed into the Build
System is something that needs be sorted since "branched" Fedora
Releases have a version number tied to DistGit but Rawhide is
technically f26 right now. I'll update as soon as this is live.

-AdamM

>>
>> At this time the Cloud/Atomic WG[2] will maintain the Guidelines as well as
>> the Review Process along with input from all Fedora Contributors. This may
>> change later with the formation of a Fedora Container Committee (similar to
>> the Fedora Packaging Committee[6]).
>>
>> Please note that both the Guidelines and the Review Process are likely to
>> evolve along with the Container technologies as we move into the future so
>> we encourage community members to check the documentation for updates.
>>
>> For more information, please see the following Fedora Community Blog:
>>
>> 
>> https://communityblog.fedoraproject.org/fedora-docker-layered-image-build-service-now-available/
>>
>> [0] - 
>> https://fedoraproject.org/wiki/Changes/Layered_Docker_Image_Build_Service
>> [1] - https://fedoraproject.org/wiki/Cloud
>> [2] - 
>> https://docs.docker.com/engine/userguide/storagedriver/imagesandcontainers/
>> [3] - https://github.com/fedora-cloud/Fedora-Dockerfiles
>> [4] - https://getfedora.org/en/atomic/download/
>> [5] - https://fedoraproject.org/wiki/Modularity
>> [6] - https://fedoraproject.org/wiki/Packaging_Committee
>> ___
>> devel mailing list -- de...@lists.fedoraproject.org
>> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>
>
>
> --
> -Igor Gnatenko
> ___
> devel mailing list -- de...@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
___
cloud mailing list -- cloud@lists.fedoraproject.org
To unsubscribe send an email to cloud-le...@lists.fedoraproject.org

Re: Announcement: Fedora Docker Layered Image Build Service is GO!

[Adam Miller]

On Tue, Dec 13, 2016 at 2:45 PM, Dennis Gregorovic <dgre...@redhat.com> wrote:
>
>
> On 12/13/2016 02:36 PM, Adam Miller wrote:
>> It is with great pleasure that the Fedora Project Announces the availability
>> of the Fedora Docker Layered Image Build Service[0] to the Fedora Contributor
>> Community!
>>
>> With this announcement we are opening availability of the Docker Layered
>> Image Build Service for the Docker Layered Images[1] that the Fedora Cloud
>> SIG[2] has been the primary maintainers[3] of on GitHub into DistGit as
>> official components of Fedora. From there we will be extending an invitation
>> to all Fedora Contributors to maintain Docker Layered Image Containers for
>> official release by the Fedora Project. Currently this effort is to enable
>> the Fedora Cloud/Atomic WG[2] goals which target Fedora Atomic Host[4] as a
>> primary deliverable to power the future of Cloud. This is also to enable the
>> Fedora Modularity[5] work be delivered as Containers in the future as Fedora
>> becomes fundamentally more modular in nature.
>>
>> How do I get started?
>
> [snip]
>
> Adam, this is great news!
>
> Reading through the announcement and links, one thing that wasn't clear to me 
> is which docker registry will store the layered images and how they will be 
> organized in repos.  Also, what is the release / update process?  Thank you 
> in advance for pointers to this information.

Apologies, I forgot to add some background info to the Wiki about the
layout and such. I've provided a section to the Wiki that will
hopefully answer questions you have. If not please feel free to ask
and I'll make to get it all documented.

https://fedoraproject.org/wiki/Container:Guidelines#General_Fedora_Docker_Information

-AdamM

>
> Cheers
> -- Dennis
___
cloud mailing list -- cloud@lists.fedoraproject.org
To unsubscribe send an email to cloud-le...@lists.fedoraproject.org

Announcement: Fedora Docker Layered Image Build Service is GO!

[Adam Miller]

It is with great pleasure that the Fedora Project Announces the availability
of the Fedora Docker Layered Image Build Service[0] to the Fedora Contributor
Community!

With this announcement we are opening availability of the Docker Layered
Image Build Service for the Docker Layered Images[1] that the Fedora Cloud
SIG[2] has been the primary maintainers[3] of on GitHub into DistGit as
official components of Fedora. From there we will be extending an invitation
to all Fedora Contributors to maintain Docker Layered Image Containers for
official release by the Fedora Project. Currently this effort is to enable
the Fedora Cloud/Atomic WG[2] goals which target Fedora Atomic Host[4] as a
primary deliverable to power the future of Cloud. This is also to enable the
Fedora Modularity[5] work be delivered as Containers in the future as Fedora
becomes fundamentally more modular in nature.

How do I get started?

Contributors will go through a simliar process as what they currently do
with RPM Review Requests. There will be Container Reviews as well as
Container Guidelines:

https://fedoraproject.org/wiki/Container:Review_Process
https://fedoraproject.org/wiki/Container:Guidelines

At this time the Cloud/Atomic WG[2] will maintain the Guidelines as well as
the Review Process along with input from all Fedora Contributors. This may
change later with the formation of a Fedora Container Committee (similar to
the Fedora Packaging Committee[6]).

Please note that both the Guidelines and the Review Process are likely to
evolve along with the Container technologies as we move into the future so
we encourage community members to check the documentation for updates.

For more information, please see the following Fedora Community Blog:


https://communityblog.fedoraproject.org/fedora-docker-layered-image-build-service-now-available/

[0] - https://fedoraproject.org/wiki/Changes/Layered_Docker_Image_Build_Service
[1] - https://fedoraproject.org/wiki/Cloud
[2] - 
https://docs.docker.com/engine/userguide/storagedriver/imagesandcontainers/
[3] - https://github.com/fedora-cloud/Fedora-Dockerfiles
[4] - https://getfedora.org/en/atomic/download/
[5] - https://fedoraproject.org/wiki/Modularity
[6] - https://fedoraproject.org/wiki/Packaging_Committee
___
cloud mailing list -- cloud@lists.fedoraproject.org
To unsubscribe send an email to cloud-le...@lists.fedoraproject.org

Re: Fedora Atomic Host Two Week Release Announcement

[Adam Miller]

On Wed, Dec 7, 2016 at 3:31 PM,   wrote:
>
> A new update of Fedora Cloud Atomic Host has been released and can be
> downloaded at:
>
> Images can be found here:
>
> https://getfedora.org/en/cloud/download/atomic.html
>
> Respective signed CHECKSUM files can be found here:
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-Atomic-25-20161205.0/Atomic/x86_64/iso/Fedora-Atomic-25-20161205.0-x86_64-CHECKSUM
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-Atomic-25-20161205.0/CloudImages/x86_64/images/Fedora-CloudImages-25-20161205.0-x86_64-CHECKSUM

This was reported incorrectly because there's currently a bug in
AutoCloud[0] which is reporting false positive test failures. The
actual compose id is Fedora-Atomic-25-20161207.0 URLs and the CHECKSUM
URLs are below:

Respective signed CHECKSUM files can be found here:
https://dl.fedoraproject.org/pub/alt/atomic/stable/Fedora-Atomic-25-20161207.0/Atomic/x86_64/iso/Fedora-Atomic-25-20161207.0-x86_64-CHECKSUM
https://dl.fedoraproject.org/pub/alt/atomic/stable/Fedora-Atomic-25-20161207.0/CloudImages/x86_64/images/Fedora-CloudImages-25-20161207.0-x86_64-CHECKSUM

Apologies,
-AdamM

[0] - https://pagure.io/atomic-wg/issue/182

>
> For direct download, the "latest" targets are always available here:
> https://getfedora.org/atomic_iso_latest
> https://getfedora.org/atomic_qcow2_latest
> https://getfedora.org/atomic_raw_latest
> https://getfedora.org/atomic_vagrant_libvirt_latest
> https://getfedora.org/atomic_vagrant_virtualbox_latest
>
> Filename fetching URLs are available here:
> https://getfedora.org/atomic_iso_latest_filename
> https://getfedora.org/atomic_qcow2_latest_filename
> https://getfedora.org/atomic_raw_latest_filename
> https://getfedora.org/atomic_vagrant_libvirt_latest_filename
> https://getfedora.org/atomic_vagrant_virtualbox_latest_filename
>
> For more information about the latest targets, please reference the Fedora
> Cloud Wiki space.
>
> https://fedoraproject.org/wiki/Cloud#Quick_Links
>
> Do note that it can take some of the mirrors up to 12 hours to "check-in" at
> their own discretion.
>
> Thank you,
> Fedora Release Engineering
>
> ___
> cloud mailing list -- cloud@lists.fedoraproject.org
> To unsubscribe send an email to cloud-le...@lists.fedoraproject.org
>
___
cloud mailing list -- cloud@lists.fedoraproject.org
To unsubscribe send an email to cloud-le...@lists.fedoraproject.org

Re: Docker Layered Image Naming and Tagging

[Adam Miller]

On Thu, Oct 27, 2016 at 11:19 AM, Matthew Miller
<mat...@fedoraproject.org> wrote:
> On Thu, Oct 27, 2016 at 08:55:33AM -0500, Adam Miller wrote:
>> The main thing that concern I have is that with modularity there is
>> going to be a concept of "base runtime" which will have a "generation"
>> associated with it (most likely, the "generation" will share a name
>> with the Fedora release number it was built from). Containers will be
>> built on top of the base runtime and depending on the modules
>> requirements, a module may select different generations of the base
>> runtime and since there's plans to distribute modules (at least
>> optionally) as containers, we'll likely need a way to distinguish
>> between "generations" of the base runtime upon which a container was
>> built.
>
> *nod* I guess that makes the question mostly whether the generation is
> something users need to fundamentally care about, or an insider detail.
>
>
>> Of course, that might not be something we need to worry about in the
>> event that the modularity metadata handles all the book keeping and
>> just maps the appropriate information to a specific docker image tag.
>> If that ends up being the case, I'd almost just say drop the first
>> httpd and make it registry.fedoraproject.org/httpd:latest

I spent some time looking through the OSBS code yesterday and it's
written in a such a way that is nice and flexible because we can write
plugins that will provide us with whatever tagging strategy we can
dream up. We can even have multiple tagging strategies aggregate, so
effectively the same image can be tagged by many names based one
whatever criteria we hammer out.

>
> I'd hate to make it top-level simply because modularity forgot to
> handle this because we forgot to tell them...
>
>
>> Thoughts? Should we bring this to the modularity group for review?
>
> Yes. Oh, for @-mentions in email. I'll find someone and bug them.

Any update here?

-AdamM

>
> --
> Matthew Miller
> <mat...@fedoraproject.org>
> Fedora Project Leader
> ___
> cloud mailing list -- cloud@lists.fedoraproject.org
> To unsubscribe send an email to cloud-le...@lists.fedoraproject.org
___
cloud mailing list -- cloud@lists.fedoraproject.org
To unsubscribe send an email to cloud-le...@lists.fedoraproject.org

Re: Docker Layered Image Naming and Tagging

[Adam Miller]

On Thu, Oct 27, 2016 at 8:55 AM, Adam Miller
<maxamill...@fedoraproject.org> wrote:
> On Wed, Oct 26, 2016 at 10:13 AM, Matthew Miller
> <mat...@fedoraproject.org> wrote:
>> On Tue, Oct 25, 2016 at 04:43:55PM -0500, Adam Miller wrote:
>>> > I'm not sure we should put base distro and distro version as the
>>> > primary distinguisher. As a user, it's the application (and possibly
>>> > major version of that application) that I care about. How about just:
>>> >registry.fedoraproject.org/httpd/24/http:latest
>>> >registry.fedoraproject.org/httpd/24/http:2.4.23
>>> > with Fedora version indicated by labels?
>>
>> Or even just
>>
>> registry.fedoraproject.org/httpd/http:latest
>>
>> and *really* have the Fedora version as an implementation detail (just
>> the label, nothing in the path at all). Does that present any practical
>> problems that I'm not seeing?
>
> The main thing that concern I have is that with modularity there is
> going to be a concept of "base runtime" which will have a "generation"
> associated with it (most likely, the "generation" will share a name
> with the Fedora release number it was built from). Containers will be
> built on top of the base runtime and depending on the modules
> requirements, a module may select different generations of the base
> runtime and since there's plans to distribute modules (at least
> optionally) as containers, we'll likely need a way to distinguish
> between "generations" of the base runtime upon which a container was
> built.
>
> Of course, that might not be something we need to worry about in the
> event that the modularity metadata handles all the book keeping and
> just maps the appropriate information to a specific docker image tag.
> If that ends up being the case, I'd almost just say drop the first
> httpd and make it registry.fedoraproject.org/httpd:latest
>
> Thoughts? Should we bring this to the modularity group for review?
>

Oh, also. The Project Atomic upstream group has some naming schemes on
this that we might want to follow along with.

https://github.com/projectatomic/ContainerApplicationGenericLabels/blob/master/vendor/redhat/names.md

-AdamM

> -AdamM
>
>>
>> --
>> Matthew Miller
>> <mat...@fedoraproject.org>
>> Fedora Project Leader
>> ___
>> cloud mailing list -- cloud@lists.fedoraproject.org
>> To unsubscribe send an email to cloud-le...@lists.fedoraproject.org
___
cloud mailing list -- cloud@lists.fedoraproject.org
To unsubscribe send an email to cloud-le...@lists.fedoraproject.org

Re: Docker Layered Image Naming and Tagging

[Adam Miller]

On Wed, Oct 26, 2016 at 10:13 AM, Matthew Miller
<mat...@fedoraproject.org> wrote:
> On Tue, Oct 25, 2016 at 04:43:55PM -0500, Adam Miller wrote:
>> > I'm not sure we should put base distro and distro version as the
>> > primary distinguisher. As a user, it's the application (and possibly
>> > major version of that application) that I care about. How about just:
>> >registry.fedoraproject.org/httpd/24/http:latest
>> >registry.fedoraproject.org/httpd/24/http:2.4.23
>> > with Fedora version indicated by labels?
>
> Or even just
>
> registry.fedoraproject.org/httpd/http:latest
>
> and *really* have the Fedora version as an implementation detail (just
> the label, nothing in the path at all). Does that present any practical
> problems that I'm not seeing?

The main thing that concern I have is that with modularity there is
going to be a concept of "base runtime" which will have a "generation"
associated with it (most likely, the "generation" will share a name
with the Fedora release number it was built from). Containers will be
built on top of the base runtime and depending on the modules
requirements, a module may select different generations of the base
runtime and since there's plans to distribute modules (at least
optionally) as containers, we'll likely need a way to distinguish
between "generations" of the base runtime upon which a container was
built.

Of course, that might not be something we need to worry about in the
event that the modularity metadata handles all the book keeping and
just maps the appropriate information to a specific docker image tag.
If that ends up being the case, I'd almost just say drop the first
httpd and make it registry.fedoraproject.org/httpd:latest

Thoughts? Should we bring this to the modularity group for review?

-AdamM

>
> --
> Matthew Miller
> <mat...@fedoraproject.org>
> Fedora Project Leader
> ___
> cloud mailing list -- cloud@lists.fedoraproject.org
> To unsubscribe send an email to cloud-le...@lists.fedoraproject.org
___
cloud mailing list -- cloud@lists.fedoraproject.org
To unsubscribe send an email to cloud-le...@lists.fedoraproject.org

Re: Docker Layered Image Naming and Tagging

[Adam Miller]

On Fri, Oct 21, 2016 at 11:10 AM, Matthew Miller
<mat...@fedoraproject.org> wrote:
> On Fri, Oct 21, 2016 at 10:06:41AM -0500, Adam Miller wrote:
>> For layered images, we would follow something similar to:
>>
>> registry.fedoraproject.org/fedora/24/httpd:latest
>> registry.fedoraproject.org/fedora/24/httpd:2.4
>> registry.fedoraproject.org/fedora/24/httpd:2.4.23
>
> I'm not sure we should put base distro and distro version as the
> primary distinguisher. As a user, it's the application (and possibly
> major version of that application) that I care about. How about just:
>
>registry.fedoraproject.org/httpd/24/http:latest
>registry.fedoraproject.org/httpd/24/http:2.4.23
>
> with Fedora version indicated by labels?
>

I like it.

Anyone else with opinions?

-AdamM

>
> --
> Matthew Miller
> <mat...@fedoraproject.org>
> Fedora Project Leader
> ___
> cloud mailing list -- cloud@lists.fedoraproject.org
> To unsubscribe send an email to cloud-le...@lists.fedoraproject.org
___
cloud mailing list -- cloud@lists.fedoraproject.org
To unsubscribe send an email to cloud-le...@lists.fedoraproject.org

Re: [atomic-devel] Announcing Fedora Atomic "latest" download URLs

[Adam Miller]

On Fri, Sep 30, 2016 at 11:57 AM, Josh Berkus <jber...@redhat.com> wrote:
> On 09/30/2016 08:58 AM, Adam Miller wrote:
>> On Thu, Sep 29, 2016 at 1:54 PM, Josh Berkus <jber...@redhat.com> wrote:
>>> On 09/29/2016 08:18 AM, Adam Miller wrote:
>>>> On behalf of the Fedora Cloud Working Group, I am happy to
>>>> announce that we now have a persistent point of download for users who
>>>> would like to simply reference a single URL for scripting purposes or
>>>> otherwise. There is also a companion set of URLs that provide the
>>>> image name that can be downloaded for informational purposes or
>>>> scripting. This will allow users to download the image and know the
>>>> resulting image name without any human interaction needed. The
>>>> rationale behind this was to make sure that users always be aware of
>>>> the version (compose id) of the image they downloaded in order to not
>>>> have issues/bugs filed against an image named "latest" that is
>>>> changing out from under users every two weeks.
>>>
>>> Yaaay!
>>>
>>>>
>>>> The new URLs are below
>>>
>>> ISO URL?
>>>
>>
>> Oversight, the ISO isn't in the fedmsg data from AutoCloud so it had
>> to be handled as a special case.
>>
>> fedora-websites pull request here:
>> https://pagure.io/fedora-websites/pull-request/43
>>
>> Once that's merged the following URLs should be live within 30 minutes
>> of the merge:
>>
>> https://getfedora.org/atomic_iso_latest
>> https://getfedora.org/atomic_iso_latest_filename
>
> Double yay!
>

Sorry, I forgot to update the list.

There was an issue with cache invalidation in the website build
tooling introduced by the patch I submitted, threebean got us all
sorted out so the ISO URL has been added and the wiki updated.

https://fedoraproject.org/wiki/Cloud#Fedora_Cloud_Atomic_Image_Download_Links

-AdamM

>
> --
> --
> Josh Berkus
> Project Atomic
> Red Hat OSAS
___
cloud mailing list -- cloud@lists.fedoraproject.org
To unsubscribe send an email to cloud-le...@lists.fedoraproject.org

No Two Week Atomic Release

[Adam Miller]

Hello all,
I just wanted to post a quick update that there has not been a
compose that passed all AutoCloud testing criteria for release in the
past two weeks. It appears that the Vagrant libvirt images are
failing.

We will try again for a release next Two Week window.

Thank you,
-AdamM
___
cloud mailing list -- cloud@lists.fedoraproject.org
To unsubscribe send an email to cloud-le...@lists.fedoraproject.org

Re: Cloud and Server Q

[Adam Miller]

On Tue, Oct 4, 2016 at 6:21 AM, Kushal Das  wrote:
> On 30/09/16, Josh Berkus wrote:
>> On 09/30/2016 02:01 PM, Josh Boyer wrote:
>>
>> > 16:44:56  Cloud base image is the only blocking deliverable.
>> > 16:44:59  Atomic is not.
>> >
>> > I realize this WG is in the middle of rebooting itself, but to have
>> > clearly conflicting information from the WG members is a bit
>> > concerning.
>>
> Atomic host image is the deliverable for the Atomic WG, which is under 2
> week release cycle. We sync up with the official release version at the
> time of GA, but we continue to be in our 2 week atomic release cycle
> then on the 6month old GA. This is my understanding about all the work
> done for 2 Week Atomic.
>
> Now I may be completely wrong to understand our 2 week release cycle
> process, but this is what I followed for the release-infra work till
> now.
>

This is correct, Fedora Atomic Two-Week Release was meant to allow
Fedora Atomic more flexibility in it's release cycle. Part of the
initial proposal was to remove it from being directly bound to the
standard six month release cycle. If this is something we want to
change, that's fine. However, if we do that we need to get buy in from
all groups involved in that process instead of just change things out
from everyone. Also, people will need to show up to do the work in
Fedora QA because there's a lot of it and we can't realistically ask
them to take on what is effectively 5 new deliverable artifacts
without assistance (ISO, qcow2, raw, vagrant-vbox, vagrant-libvirt).

-AdamM

> Kushal
> --
> Fedora Cloud Engineer
> CPython Core Developer
> https://kushaldas.in
> https://dgplug.org
> ___
> cloud mailing list -- cloud@lists.fedoraproject.org
> To unsubscribe send an email to cloud-le...@lists.fedoraproject.org
___
cloud mailing list -- cloud@lists.fedoraproject.org
To unsubscribe send an email to cloud-le...@lists.fedoraproject.org

Re: Cloud and Server Q

[Adam Miller]

On Fri, Sep 30, 2016 at 8:35 AM, Matthew Miller
 wrote:
> On Thu, Sep 29, 2016 at 04:16:15PM -0700, Adam Williamson wrote:
>> > think QA clearly understands what cloud image(s) are release blocking,
>> > as previously they were just the non-atomic images.
>> Which images are prominent on the download pages and how much of a
>> relationship there is between that and 'release blocking' status is
>> *also* not my problem, but I'd agree with you (Chris) that it'd be
>> rather strange for the most prominently advertised deliverable for a
>> given product not to be a release-blocking one.
>
> I don't think that Atomic *needs* to be release blocking, because if it
> misses the grand unified release, we have the ability to update it at
> the next cycle, so it's less of a big deal. But if we collectively
> prefer to make sure everything is lined up on the release day... I can
> see arguments for that, too.
>

Note that the cycle that Matt is mentioning here is Two-Week
iterations for Atomic Host so the window to release is relatively
rapid compared to the standard ~6 months.

-AdamM


>
> --
> Matthew Miller
> 
> Fedora Project Leader
> ___
> cloud mailing list -- cloud@lists.fedoraproject.org
> To unsubscribe send an email to cloud-le...@lists.fedoraproject.org
___
cloud mailing list -- cloud@lists.fedoraproject.org
To unsubscribe send an email to cloud-le...@lists.fedoraproject.org

Re: Cloud and Server Q

[Adam Miller]

On Fri, Sep 30, 2016 at 8:35 AM, Matthew Miller
 wrote:
> On Thu, Sep 29, 2016 at 04:16:15PM -0700, Adam Williamson wrote:
>> > think QA clearly understands what cloud image(s) are release blocking,
>> > as previously they were just the non-atomic images.
>> Which images are prominent on the download pages and how much of a
>> relationship there is between that and 'release blocking' status is
>> *also* not my problem, but I'd agree with you (Chris) that it'd be
>> rather strange for the most prominently advertised deliverable for a
>> given product not to be a release-blocking one.
>
> I don't think that Atomic *needs* to be release blocking, because if it
> misses the grand unified release, we have the ability to update it at
> the next cycle, so it's less of a big deal. But if we collectively
> prefer to make sure everything is lined up on the release day... I can
> see arguments for that, too.
>
>
> --
> Matthew Miller
> 
> Fedora Project Leader
> ___
> cloud mailing list -- cloud@lists.fedoraproject.org
> To unsubscribe send an email to cloud-le...@lists.fedoraproject.org
___
cloud mailing list -- cloud@lists.fedoraproject.org
To unsubscribe send an email to cloud-le...@lists.fedoraproject.org

Re: Docker Layered Image Naming and Tagging

[Adam Miller]

On Thu, Sep 29, 2016 at 6:45 PM, Josh Berkus <jber...@redhat.com> wrote:
> On 09/29/2016 03:03 PM, Adam Miller wrote:
>> Hello all,
>> I was recently discussing some items around docker layered image
>> release process in the future with Randy (bowlofeggs) and Patrick
>> (puiterwijk). As a side effect of our discussion there were two
>> questions I wanted to ask of the Cloud WG:
>>
>> 1) Do we want to maintain docker images for every Fedora Release or do
>> we want to focus only on latest? (i.e. - do we want to maintain them
>> like we do rpms or take a different position)
>
> By "images" do you mean "base image" or "layered images"?

Layered Images, the base images will only sport the tag of their major
release number as they do today: 24, 25, 26, etc etc.

>
> Basically each layered image has a single application for which we are
> about the version.  The version of Fedora underneath that is fairly
> inconsequential, but major version of the application can be very important.
>
> Take everyone's favorite destruction test case, PostgreSQL.  For
> Postgres, replication doesn't necessarily work between major versions,
> so once we put out a major version we need to keep it out.
>
> If we have a PostgreSQL-9.5.3 image on Fedora 24 Base out there, then:
>
> A. it's OK to replace it with a PostgreSQL-9.5.4 image on Fedora 24
> B. it's OK to replace it with a PostgreSQL-9.5.4 image on Fedora 25
> C. it's NOT OK to drop it any only have a PostgreSQL-9.6.1 image available
>
> I have mixed feelings about whether or not we should do (B) as policy.
> In cases like this, I usually come down to: what's easier? Freezing the
> base image for the major version of the application, or advancing it?

I think both ways can pose their own challenges, if we freeze on each
version then Layered image maintainers have to pay attention to
multiple Fedora releases but if we focus only on the latest then there
will be a cut over period where some people end up broken because of
unforeseen side effects of the base image upgrade.

>
>>
>> 2) Do we want to keep around multiple versions of a container?
>>
>> For example:
>> If we had the following images:
>>
>> registry.fedoraproject.org/cockpit:0.95-1.23
>> registry.fedoraproject.org/cockpit:0.95-1.24
>> registry.fedoraproject.org/cockpit:0.95-1.25
>>
>> One we release to stable 0.95-1.25, can we delete -1.24 and/or
>> -1.23? What kind of retention do we want here? (Note that rpm content
>> does not currently maintain a N and N-1 in the repositories)
>
> Just so you know, cockpit has moved to integer version numbers.  Current
> release is 119.

I am aware, this is just an old example I pulled out of a stage koji
build I grabbed from a while back for the sake of explaining the
situation.

>
> If I could have anything I wanted, my answer would be "no, let's not
> keep any old versions around."  I certainly don't think that we should
> keep any more old versions around than we absolutely have to.

Doesn't that run into the Postregesql example you gave above? If we
truly only did one image per thing, we'd break everyone with the 9.5.4
-> 9.6.1 cut over wouldn't we?

>
> However, there's a problem with that, which is existing Docker practice.
>  Devs are taught to use specific versions of containers, and not
> ":latest", because for many images on Docker Hub "latest" is some
> experimental version.  It's going to be hard for us to change that.  And
> if they use specific versions in some build script, then they're going
> to expect that version to be around when they use the same build script
> 6 months later.  If we break that regularly, we'll just lose.
>
> One thing we can do to ameliorate that is make sure we name images after
> the major version of the app and not after the patch release, i.e. the
> PostgreSQL container will be
>
>registry.fedoraproject.org/postgresql:9.5
>
> Not the way RPM files are named, like:
>
>registry.fedoraproject.org/postgresql:9.5.3-021
>
> ... which means that we don't need to keep older patch releases and
> build versions around.
>
> However, that doesn't help us *at all* with "continuous release"
> projects like Cockpit which don't have separate major releases, just
> incremental releases every week.  I'm not sure how to handle those; how
> do we do it for RPMs right now?

RPMs have the native concept of Version-Release which actually mean
something to the package manager, Docker does not so we're basically
just attempting to assign meaning to an arbitrary string that could
very well be "blargh". RPM also has the concept of transactions wh

Re: [atomic-devel] Announcing Fedora Atomic "latest" download URLs

[Adam Miller]

On Thu, Sep 29, 2016 at 1:54 PM, Josh Berkus <jber...@redhat.com> wrote:
> On 09/29/2016 08:18 AM, Adam Miller wrote:
>> On behalf of the Fedora Cloud Working Group, I am happy to
>> announce that we now have a persistent point of download for users who
>> would like to simply reference a single URL for scripting purposes or
>> otherwise. There is also a companion set of URLs that provide the
>> image name that can be downloaded for informational purposes or
>> scripting. This will allow users to download the image and know the
>> resulting image name without any human interaction needed. The
>> rationale behind this was to make sure that users always be aware of
>> the version (compose id) of the image they downloaded in order to not
>> have issues/bugs filed against an image named "latest" that is
>> changing out from under users every two weeks.
>
> Yaaay!
>
>>
>> The new URLs are below
>
> ISO URL?
>

Oversight, the ISO isn't in the fedmsg data from AutoCloud so it had
to be handled as a special case.

fedora-websites pull request here:
https://pagure.io/fedora-websites/pull-request/43

Once that's merged the following URLs should be live within 30 minutes
of the merge:

https://getfedora.org/atomic_iso_latest
https://getfedora.org/atomic_iso_latest_filename

-AdamM


> --
> --
> Josh Berkus
> Project Atomic
> Red Hat OSAS
___
cloud mailing list -- cloud@lists.fedoraproject.org
To unsubscribe send an email to cloud-le...@lists.fedoraproject.org

Docker Layered Image Naming and Tagging

[Adam Miller]

Hello all,
I was recently discussing some items around docker layered image
release process in the future with Randy (bowlofeggs) and Patrick
(puiterwijk). As a side effect of our discussion there were two
questions I wanted to ask of the Cloud WG:

1) Do we want to maintain docker images for every Fedora Release or do
we want to focus only on latest? (i.e. - do we want to maintain them
like we do rpms or take a different position)

2) Do we want to keep around multiple versions of a container?

For example:
If we had the following images:

registry.fedoraproject.org/cockpit:0.95-1.23
registry.fedoraproject.org/cockpit:0.95-1.24
registry.fedoraproject.org/cockpit:0.95-1.25

One we release to stable 0.95-1.25, can we delete -1.24 and/or
-1.23? What kind of retention do we want here? (Note that rpm content
does not currently maintain a N and N-1 in the repositories)

Thank you,
-AdamM
___
cloud mailing list -- cloud@lists.fedoraproject.org
To unsubscribe send an email to cloud-le...@lists.fedoraproject.org

Announcing Fedora Atomic "latest" download URLs

[Adam Miller]

Hello all,
On behalf of the Fedora Cloud Working Group, I am happy to
announce that we now have a persistent point of download for users who
would like to simply reference a single URL for scripting purposes or
otherwise. There is also a companion set of URLs that provide the
image name that can be downloaded for informational purposes or
scripting. This will allow users to download the image and know the
resulting image name without any human interaction needed. The
rationale behind this was to make sure that users always be aware of
the version (compose id) of the image they downloaded in order to not
have issues/bugs filed against an image named "latest" that is
changing out from under users every two weeks.

The new URLs are below:

https://getfedora.org/atomic_qcow2_latest
https://getfedora.org/atomic_raw_latest
https://getfedora.org/atomic_vagrant_libvirt_latest
https://getfedora.org/atomic_vagrant_virtualbox_latest

https://getfedora.org/atomic_qcow2_latest_filename
https://getfedora.org/atomic_raw_latest_filename
https://getfedora.org/atomic_vagrant_libvirt_latest_filename
https://getfedora.org/atomic_vagrant_virtualbox_latest_filename


I have also updated the Cloud Wiki[0] page to include information
about these as well as a sample script of how to use them together.

Thank you,
-AdamM

[0] - 
https://fedoraproject.org/wiki/Cloud#Fedora_Cloud_Atomic_Image_Download_Links
___
cloud mailing list -- cloud@lists.fedoraproject.org
To unsubscribe send an email to cloud-le...@lists.fedoraproject.org

Re: Fedora Atomic Host Two Week Release Announcement

[Adam Miller]

On Wed, Sep 21, 2016 at 3:47 PM, Adam Miller
<maxamill...@fedoraproject.org> wrote:
> On Wed, Sep 21, 2016 at 12:53 PM, Adam Miller
> <maxamill...@fedoraproject.org> wrote:
>> On Wed, Sep 21, 2016 at 12:26 PM, Chris Murphy <li...@colorremedies.com> 
>> wrote:
>>> This notification still seems broken. That page says:
>>>
>>> The latest two week build did not meet our testing criteria. The
>>> images available are from over 22 days ago. Check the Project Atomic
>>> blog for updates and information about Atomic blocker bugs. And the
>>> image available for download is
>>> https://download.fedoraproject.org/pub/alt/atomic/stable/Atomic/x86_64/iso/Fedora-Atomic-dvd-x86_64-24-20160820.0.iso
>>>
>>>
>>
>> Unfortunately there's a lag time between when the release happens and
>> when the website is auto-updated with the latest release information
>> from the fedmsg data. If it's not resolved within the next hour I'll
>> ping someone from the websites team.
>>
>> In the future once we have our rel-eng automation tooling in place
>> (currently in flight), the automated email will be disjoint from the
>> release process and the email won't be sent until the website has
>> finished updating.
>>
>
> There's an issue that's been found with the new N and N-1 change that
> affected the data sent to the websites via fedmsg, I am working to
> resolve it now.
>

This has been resolved.

-AdamM

> Apologies,
> -AdamM
>
>> -AdamM
>>
>>> On Wed, Sep 21, 2016 at 10:45 AM,  <nore...@fedoraproject.org> wrote:
>>>>
>>>> A new update of Fedora Cloud Atomic Host has been released and can be
>>>> downloaded at:
>>>>
>>>> Images can be found here:
>>>>
>>>> https://getfedora.org/en/cloud/download/atomic.html
>>>>
>>>> Respective signed CHECKSUM files can be found here:
>>>> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-Atomic-24-20160921.0/CloudImages/x86_64/images/Fedora-CloudImages-24-20160921.0-x86_64-CHECKSUM
>>>> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-Atomic-24-20160921.0/Atomic/x86_64/iso/Fedora-Atomic-24-20160921.0-x86_64-CHECKSUM
>>>>
>>>> Thank you,
>>>> Fedora Release Engineering
>>>>
>>>> ___
>>>> cloud mailing list -- cloud@lists.fedoraproject.org
>>>> To unsubscribe send an email to cloud-le...@lists.fedoraproject.org
>>>>
>>>
>>>
>>>
>>> --
>>> Chris Murphy
>>> ___
>>> rel-eng mailing list -- rel-...@lists.fedoraproject.org
>>> To unsubscribe send an email to rel-eng-le...@lists.fedoraproject.org
___
cloud mailing list -- cloud@lists.fedoraproject.org
To unsubscribe send an email to cloud-le...@lists.fedoraproject.org

Re: Fedora Atomic Host Two Week Release Announcement

[Adam Miller]

On Wed, Sep 21, 2016 at 12:53 PM, Adam Miller
<maxamill...@fedoraproject.org> wrote:
> On Wed, Sep 21, 2016 at 12:26 PM, Chris Murphy <li...@colorremedies.com> 
> wrote:
>> This notification still seems broken. That page says:
>>
>> The latest two week build did not meet our testing criteria. The
>> images available are from over 22 days ago. Check the Project Atomic
>> blog for updates and information about Atomic blocker bugs. And the
>> image available for download is
>> https://download.fedoraproject.org/pub/alt/atomic/stable/Atomic/x86_64/iso/Fedora-Atomic-dvd-x86_64-24-20160820.0.iso
>>
>>
>
> Unfortunately there's a lag time between when the release happens and
> when the website is auto-updated with the latest release information
> from the fedmsg data. If it's not resolved within the next hour I'll
> ping someone from the websites team.
>
> In the future once we have our rel-eng automation tooling in place
> (currently in flight), the automated email will be disjoint from the
> release process and the email won't be sent until the website has
> finished updating.
>

There's an issue that's been found with the new N and N-1 change that
affected the data sent to the websites via fedmsg, I am working to
resolve it now.

Apologies,
-AdamM

> -AdamM
>
>> On Wed, Sep 21, 2016 at 10:45 AM,  <nore...@fedoraproject.org> wrote:
>>>
>>> A new update of Fedora Cloud Atomic Host has been released and can be
>>> downloaded at:
>>>
>>> Images can be found here:
>>>
>>> https://getfedora.org/en/cloud/download/atomic.html
>>>
>>> Respective signed CHECKSUM files can be found here:
>>> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-Atomic-24-20160921.0/CloudImages/x86_64/images/Fedora-CloudImages-24-20160921.0-x86_64-CHECKSUM
>>> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-Atomic-24-20160921.0/Atomic/x86_64/iso/Fedora-Atomic-24-20160921.0-x86_64-CHECKSUM
>>>
>>> Thank you,
>>> Fedora Release Engineering
>>>
>>> ___
>>> cloud mailing list -- cloud@lists.fedoraproject.org
>>> To unsubscribe send an email to cloud-le...@lists.fedoraproject.org
>>>
>>
>>
>>
>> --
>> Chris Murphy
>> ___
>> rel-eng mailing list -- rel-...@lists.fedoraproject.org
>> To unsubscribe send an email to rel-eng-le...@lists.fedoraproject.org
___
cloud mailing list -- cloud@lists.fedoraproject.org
To unsubscribe send an email to cloud-le...@lists.fedoraproject.org

Re: Fedora Atomic Host Two Week Release Announcement

[Adam Miller]

On Wed, Sep 21, 2016 at 12:26 PM, Chris Murphy  wrote:
> This notification still seems broken. That page says:
>
> The latest two week build did not meet our testing criteria. The
> images available are from over 22 days ago. Check the Project Atomic
> blog for updates and information about Atomic blocker bugs. And the
> image available for download is
> https://download.fedoraproject.org/pub/alt/atomic/stable/Atomic/x86_64/iso/Fedora-Atomic-dvd-x86_64-24-20160820.0.iso
>
>

Unfortunately there's a lag time between when the release happens and
when the website is auto-updated with the latest release information
from the fedmsg data. If it's not resolved within the next hour I'll
ping someone from the websites team.

In the future once we have our rel-eng automation tooling in place
(currently in flight), the automated email will be disjoint from the
release process and the email won't be sent until the website has
finished updating.

-AdamM

> On Wed, Sep 21, 2016 at 10:45 AM,   wrote:
>>
>> A new update of Fedora Cloud Atomic Host has been released and can be
>> downloaded at:
>>
>> Images can be found here:
>>
>> https://getfedora.org/en/cloud/download/atomic.html
>>
>> Respective signed CHECKSUM files can be found here:
>> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-Atomic-24-20160921.0/CloudImages/x86_64/images/Fedora-CloudImages-24-20160921.0-x86_64-CHECKSUM
>> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-Atomic-24-20160921.0/Atomic/x86_64/iso/Fedora-Atomic-24-20160921.0-x86_64-CHECKSUM
>>
>> Thank you,
>> Fedora Release Engineering
>>
>> ___
>> cloud mailing list -- cloud@lists.fedoraproject.org
>> To unsubscribe send an email to cloud-le...@lists.fedoraproject.org
>>
>
>
>
> --
> Chris Murphy
> ___
> rel-eng mailing list -- rel-...@lists.fedoraproject.org
> To unsubscribe send an email to rel-eng-le...@lists.fedoraproject.org
___
cloud mailing list -- cloud@lists.fedoraproject.org
To unsubscribe send an email to cloud-le...@lists.fedoraproject.org

Re: overlayfs for AFTER Fedora 25

[Adam Miller]

On Wed, Sep 14, 2016 at 2:14 PM, Dusty Mabe  wrote:
>
> In the cloud meeting today I brought up overlayfs and F25. After
> discussing with the engineers closer to the technology they recommend
> waiting to move to overlayfs as the default in F26.
>
> I think this will work well because it will give us some time to allow
> people to "try" overlayfs in F25 (we should provide good docs on this)
> and then give us feedback before we go with it as default in F26. If
> the feedback is bad then maybe we wouldn't even go with it in F26, but
> hopefully that won't be the case.
>
> Thoughts?

Seems a little conservative, but I'm not opposed.

I've been under the impression that part of the point of the Two Week
Release cycle was to be able to deliver new stuff faster and fix
issues faster but playing it safe isn't inherently a bad approach
either.

-AdamM

>
> Dusty
> ___
> cloud mailing list
> cloud@lists.fedoraproject.org
> https://lists.fedoraproject.org/admin/lists/cloud@lists.fedoraproject.org
___
cloud mailing list
cloud@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/cloud@lists.fedoraproject.org

No Two Week Atomic Host this cycle

[Adam Miller]

Hello all,
There have not been any composes that have passed all AutoCloud Tests
this Two-Week cycle and we will therefore be deferring release until the
next cycle. The main blocker bug is being worked on[0].

Thank you,
-AdamM

[0] - https://bugzilla.redhat.com/show_bug.cgi?id=1353688
___
cloud mailing list
cloud@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/cloud@lists.fedoraproject.org

Re: Proposal to test AMIs using Autocloud

[Adam Miller]

On Thu, Sep 1, 2016 at 9:22 AM, Sayan Chowdhury
 wrote:
> Hi,
>
> I am planning to move the testing functionality to test AMIs from
> fedimg to Autocloud. Right now, the fedimg just runs the /bin/true
> command to test if the AMIs is proper or not. Therefore, I am planning
> to completely remove this functionality from fedimg and move to
> Autocloud.
>
> The plan:
>
> 1. Once fedimg creates a new AMI. It will be sending out a fedmsg
> message with a new topic 'fedimg.ami.create'.
> 2. Autocloud will be listening to this topic and schedule a testing
> for the AMI using Tunir. This process will be completely separate and
> will have no overlap with the current process of testing images.
> 3. If the test passes, Autocloud emits fedmsg message with topic
> 'ami.passed'. Fedimg listens to this topic and makes that particular
> AMI public and copies the AMI to other regions.
> 4. If the test fails, Autocloud emits fedmsg message with topic
> 'ami.failed. Fedimg also  listens to this topic and deletes all the
> AMis and related resources.
>
> This will give the provision to test the AMIs properly and we can have
> a separate dashboard for the same. As soon as deployed, we can run
> tests from the current set of testcases we have.
>
>
> Do share your thoughts or questions on this proposal.


Sounds good.

+1

-AdamM

>
> --
> Sayan Chowdhury 
> Senior Software Engineer, Fedora Engineering - Emerging Platform
> GPG Fingerprint : 0F16 E841 E517 225C 7D13  AB3C B023 9931 9CD0 5C8B
>
>
> Proud to work at The Open Organization!
> ___
> cloud mailing list
> cloud@lists.fedoraproject.org
> https://lists.fedoraproject.org/admin/lists/cloud@lists.fedoraproject.org
___
cloud mailing list
cloud@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/cloud@lists.fedoraproject.org