From Fedora Project Wiki

< Container SIG

Revision as of 14:24, 10 August 2018 by Ttomecek (talk | contribs) (Formatting)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

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)