Today @dkliban, @daviddavis, and I met with two Katello developers,
@jsherrill and @paji, to talk through some of the integration of Katello
and Pulp3. Here is a recap of what we discussed, a goal we identified, and
# What we discussed
We went through Katello's UI and learned about:
- the various filtering needs of Katello. Pulp is pretty well setup to do
this already. I say filtering because the value is being matched, compared,
substring matched, etc for a specific field. They need to filter by a group
of repositories. For example, show me all RPM packages that are in
repositories X, Y, and Z as one filter. Similarly show me all RPM packages
that are in repository versions W, Q, T.
- full text search. Katello needs to be able to search for a term,
full-text style across some set of tables. Pulp does not have this
currently. It would be limited to some tables; knowing which tables need to
be searched would always be known.
- "groups of repos". Katello subscribes a machine to a "set of repos" all
of which Katello treats as one thing. This allows the client to stay
subscribed to one set of content which makes repo protection easier because
you don't have to change certs constantly. Then the content in those repos
is what changes. This means when Katello does something it typically
involves that same operation for a group of repos.
- applicability. There are calculations that Katello has done above and
beyond Pulp even in Pulp2. Pulp should be able to run all calculations that
Katello needs to avoid them having to reindex the content to run those same
# A goal identified
To move work into Pulp such that Katello never needs to reindex Pulp's
# Next Steps
We're going to map out the existing Katello application page-by-page and
capture use cases for each. We will do this over a series of meetings,
two-per week. At our next meeting we are outlining a schedule of all the
For each item we will outline a very-brief technical plan (a few words) of
the steps katello will take when interacting with Pulp for each. We will
also clearly sort use cases into those that have all the necessary Pulp
parts already in place and those that Pulp cannot yet fulfill.
Our next report will contain the list of topics with a proposed schedule of
the first few and what they will cover. This will likely live on the wiki.
Comments, ideas, discussion, concerns, etc are all welcome.
Pulp-dev mailing list