# 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)