From Fedora Project Wiki
(Notes from Flock 2018 workshop)
 
(Formatting)
 
(One intermediate revision by the same user not shown)
Line 1: Line 1:
Fedora containers: next steps (workshop)
= Notes from Flock 2018 container workshop =
https://public.etherpad-mozilla.org/p/flock-2018-containers-workshop
* How do you get the new build to bodhi?
 
** Code is done.
1. Introduction.
** Can push images to registry
Who are we?
** Needs to pass final testing.
Who are you?
* Multiarch images are coming soon
We are here for you and we can talk about things you are interested in.
** intel, arm, power, s390
Introduction of the Container SIG
* Betka (sync upstream content to downstream)
OSBS new features ( Automatic Release bump, Automatic Rebuild when base image is updated, ...)
** fedmsg -- parse messages
 
** pagure webhooks
2. Introduction of what we did at Red Hat (processes) and introduction to our tools.
* Flatpak builds container images from module dist-git.
Pagure over dist-git. - T
* Build container images automatically out of modules.
https://src.fedoraproject.org/container/tools/pull-request/3
* Pingou wrote koji-simple-ci tool to build RPMs as scratch builds in koji.
colin -> Zdravomil - linting dockerfiles. - D
** Get inspired for the same thing for container images.
Betka - syncing changes from upstream to downstream dist-git. -J
* 2 weeks rebuild: we should have an automation in-place to create bodhi updates.
Solenya - create a scratch build once new pull-request arrive to pagure - D
** A service which would create bodhi update once a container image build is done (via fedmsg).
ucho + celery - what is the home of our bots and how they cooperate
* TODO: open source the bots finally!
How do you get the new build to bodhi? - T
** Create tasks in container SIG and get help from community.
code done
* Enable using candidate registry as a base image for builds.
can push images to registry
* SIG
final release test
** We need a leader who would organize the whole SIG -- connect people, coordinate, decide things.
 
** Focus
3. Design discussion on what can we do at Fedora side:
*** Guidelines
Validation.
**** Review existing guidelines (an easy way to submit and maintain container images)
How can I use taskotron to validate my image?
*** https://github.com/projectatomic/ContainerApplicationGenericLabels figure out status
Dockerfile linting
*** https://github.com/container-images update template repo and status of the images
Does it run in OpenShift? (Do we care about this?)
*** Inftrastructure
Automation (least amount of steps for container maintainers).
**** Run on top of Fedora based one (using packages and images build on our infrstructure).
Delivery (can I have the container on my system ASAP?).
**** tools, etc
 
*** Support the container users
 
**** image streams,...
4. Hacking time?
*** Define the tasks well so anyone can pick them up.
Do we wanna start hacking on things we just discussed?
** issues
We could get people to submit PRs to update the Dockerfiles in distgit since I think there are a few that are a bit out of date.
*** not @packager, but @container-maintainer
open issues here --> https://pagure.io/ContainerSIG/container-sig/issues 
*** time and place of the IRC meeting
Automatic versioning based on a "main rpm" version (maybe we work on that during hacking time)
**** #fedora-containers
Moving issues from atomic-wg to container SIG.
*** write down best practices for container SIG: where do we discuss what?
https://pagure.io/atomic-wg/issues?status=Open&tags=containers
**** Fedora CoreOS: discourse - users, pagure - design discussions
 
*** Fedora taiga?
Adding people to the containerSIG group on pagure.io
*** Issue tracking for container images
 
**** Dusty suggests pagure dist-git issue tracker
Parking lot (potential topics for discussion):
**** Clement uses WG issue tracker
 
* F30 is the time when atomic thing will start going away
Notes
* CentOS has a container something SIG (CCCP) -- do we join forces?
Multiarch images coming soon
** Invite them for our SIG meeting
intel, arm, power, s390
* Validation.
Betka
** How can I use taskotron to validate my image?
fedmsg -- parse messages
** Dockerfile linting
pagure webhooks
** Does it run in OpenShift? (Do we care about this?)
Flatpak builds container images from module dist-git
* Automation (least amount of steps for container maintainers).
Build container images automatically out of modules
* We could get people to submit PRs to update the Dockerfiles in distgit since I think there are a few that are a bit out of date.
pingou wrote koji-simple-ci tool to build RPMs as scratch builds in koji
* Automatic versioning based on a "main rpm" version (maybe we work on that during hacking time)
get inspired for container images
2 weeks rebuild: we should have an automation in-place to create bodhi updates
a service which would create bodhi update once a container image build is done (via fedmsg)
TODO: open source the bots finally!
create tasks in container SIG and get help from community
enable using candidate registry as a base image for builds
SIG
We need a leader who would organize the whole SIG -- connect people, coordinate, decide things
Focus
Guidelines
Review existing guidelines (an easy way to submit and maintain container images)
https://github.com/projectatomic/ContainerApplicationGenericLabels figure out status
https://github.com/container-images update template repo and status of the images
Inftrastructure
Run on top of Fedora based one(using packages and images build on our infrstructure)
Support the container packagers
tools, etc
Support the container users
image streams,...
Define the tasks well so anyone can pick them up
issues
not @packager, but @container-maintainer
time and place of the IRC meeting
#fedora-containers
write down best practices: where do we discuss what?
CoreOS: discourse - users, pagure - design discussions
Fedora taiga?
Issue tracking for container images
Dusty suggests pagure dist-git issue tracker
Clement uses WG issue tracker
F30 is the time when atomic thing will start going away
CentOS has a container something SIG (CCCP) -- do we join forces?
Invite them for our SIG meeting

Latest revision as of 14:24, 10 August 2018

Notes from Flock 2018 container workshop

  • How do you get the new build to bodhi?
    • Code is done.
    • Can push images to registry
    • Needs to pass final testing.
  • Multiarch images are coming soon
    • intel, arm, power, s390
  • Betka (sync upstream content to downstream)
    • fedmsg -- parse messages
    • pagure webhooks
  • Flatpak builds container images from module dist-git.
  • Build container images automatically out of modules.
  • Pingou wrote koji-simple-ci tool to build RPMs as scratch builds in koji.
    • Get inspired for the same thing for container images.
  • 2 weeks rebuild: we should have an automation in-place to create bodhi updates.
    • A service which would create bodhi update once a container image build is done (via fedmsg).
  • TODO: open source the bots finally!
    • Create tasks in container SIG and get help from community.
  • Enable using candidate registry as a base image for builds.
  • SIG
    • We need a leader who would organize the whole SIG -- connect people, coordinate, decide things.
    • Focus
    • issues
      • not @packager, but @container-maintainer
      • time and place of the IRC meeting
        • #fedora-containers
      • write down best practices for container SIG: where do we discuss what?
        • Fedora CoreOS: discourse - users, pagure - design discussions
      • Fedora taiga?
      • Issue tracking for container images
        • Dusty suggests pagure dist-git issue tracker
        • Clement uses WG issue tracker
  • F30 is the time when atomic thing will start going away
  • CentOS has a container something SIG (CCCP) -- do we join forces?
    • Invite them for our SIG meeting
  • Validation.
    • How can I use taskotron to validate my image?
    • Dockerfile linting
    • Does it run in OpenShift? (Do we care about this?)
  • Automation (least amount of steps for container maintainers).
  • We could get people to submit PRs to update the Dockerfiles in distgit since I think there are a few that are a bit out of date.
  • Automatic versioning based on a "main rpm" version (maybe we work on that during hacking time)