Community Use-Cases

Agenda

• Introductions
• "Four Questions" description
• Discussion around the four questions

Introduction

Pulp3 was designed and built in response to the experience of running Pulp2 in several different environments.

We'd like to take this time to hear about real-world use-cases from our current user-community. The purpose here is three-fold:

• Find areas where Pulp3 can already help, but maybe needs more in the way of docs/examples
• Find areas that the Pulp3 team hadn't thought about, that we can target for future development
• Learn more about what's really important to the community, to help us prioritize work

To put some form/focus around this effort, I have four questions for people to think about/answer here.

The Four Questions

• What Problem(s) Are You Solving?
  Tell us something about who your users are, and how Pulp serves their needs, or how it helps you serve your users.
• What Plugins do you use?
  What kind(s) of content are important to your users?
• What Does Your Workflow Look Like?
  What does "a day in the life" look like for you? How much do you sync? How often? How does create/sync/publish work in your environment?
• What One Thing Could Pulp3 Do To Make Your Life Easier?

Template

Who Are You?

• What Problem(s) Are You Solving?
• What Does Your Workflow Look Like?
• What Plugins do you use?
• What One Thing Could Pulp3 Do To Make Your Life Easier?

Responses

Douglas Furlong

• Programming Experience
  • first major programming job was "working with Pulp2"
• What Problem(s) Are You Solving?
  • Have been using Pulp2 to manage internal/external repos
  • 3d party packages (EPEL, etc)
  • Salt used to associate repositories to hosts
  • control injecting new packages thru release-process
  • 2 streams, "current" (active-in-primary) and "new" (#soon)
    • looking to be able to 'promote' a package directly into those streams
    • Pulp3 repo-versioning makes it possible, but it's "cumbersome"
      • "version-trees" would be useful
      • this has been discussed in the past
      • in Pulp2, used multiple repos - but it's expensive
        • Pulp3 approach might be faster?
  • 1Ks of repos, TBs of data, 2Ks of clients
  • multiple Pulp servers
    • primary, multiple secondaries - internal tooling to sync
• What Does Your Workflow Look Like?
  • mirroring upstream
    • "dirty" repo - verbatim copy of upstream
    • "trunk" repo - explicitly choosing/limiting pkg-prmotion
      • security errata, bugs, internal request
    • weekly, copy of trunk becomes "release"
      • presented to various "risk groups"
  • backups - if primary fails, recopver data from secondaries
    • every release, store rpm-related data in a separate database
• What Plugins do you use?
  • only pulp_rpm currently
  • looking to use file and container soon
  • deb and python "later"
• What One Thing Could Pulp3 Do To Make Your Life Easier?
  • moving framework to pulp3 - still early stages
  • using client-libraries and how to best use
    • handle cross-plugin decision-making - lots of 'if' clauses currently
    • "generic" publication model would be nice
    • katello input: used a class/subclass approach
  • There is value in the tooling that katello/wibbit/cli are building to make the pulp user's job easier
    • expand client-lib documentation
    • pointing to existing repositories
    • documentation about "library above the specific plugin libs"
    • "opinionated" layers vs "abstract"
  • The more complicated the lifecycle process is, the more work it takes to figure out exactly what happened when
    • Would tagging help with this scenario?
      • would be exceptionally useful to describe everything in a "release"

Sebastian Skracic/Martin Minar

• What Problem(s) Are You Solving?
  • RHUI (Red Hat Update Infrastructure)
    • scalable, redundant framework for managing repos/content
    • primarily used by Cloud Providers to provide content for their customers' instances
    • Red Hat and custom content
  • 2 kinds-of users
    • provide content for 'internal' clients (10Ks machines)
      • 'targeted' repos (eg, specific release)
      • 'frozen' repos
    • 'real' clouds (AWS, Azure, GCE, etc) providing content for 'external' customers
      • 2K repos sync'd daily, 2x/day
      • 3-4TB data
  • Most difficult task in pulp2 is managing thousands of repos at once
    • specifically task-management
• What Does Your Workflow Look Like?
  • All The Content sync'd into pulp-instance
  • distribution nodes act as pulp-clients
  • losing pulp-database
    • reinstall db node
    • resync all repos against mounted (not lost) RPM binaries
• What Plugins do you use?
  • RHUI 3 based on Pulp2 is current production
    • pulp_rpm, pulp_file, ostree
  • RHUI 4 in dev't against Pulp3
    • pulp_rpm
• What One Thing Could Pulp3 Do To Make Your Life Easier?
  • Chaining sync/distribute/publish into one operation/scheduled-task would make our life much easier
    • would it help do do on client-side?
  • Task-APIs enriched to have more data in 'waiting' tasks
    • can't find 'reserved' tasks
  • add metadata-pair to repos (eg, gpg-key-to-repo)