Thanks Justin for the update. Let me put my 2 cents in.
Hey Bernhard, Thanks for the reply! Let me try to address some of your
Unfortunately, I don’t really get the point why we should now change
to pulp 3. It looks like, no new type of pulp 3 must be supported by
katello asap. So, there is no pressure.
Pulp 3 has some really interesting concepts like repository versions
and direct lifecycle management (see
This would move some katello features back to pulp - which I really like.
Yes, the plan is to utilize some of these features under the hood. (for
example a repository version will be used in our Content View
Versions). We plan on exposing the versions as well on the main library
repository too. We will use their distributions as our lifecycle
management. Are there other ways you’d want to utilize these
features? I’m very interested in any new ideas
Therefore, I would recommend to work together with the pulp team to
get the missing content types done and then move from pulp 2 to pulp 3
in one step. This should be a easier migration than doing this step
multiple times. Additionally, you can drop a lot of katello
functionality and rely on pulp 3. I guess, having both pulp (2 and 3)
running together might be need some bad workarounds / hacks which are
The the reason for the prolonged migration is largely due to software
development processes. When we did the pulp 1 to pulp 2 migration we
tried to do it all in one large migration. This involved having a
branch of code opened with a large amount of re-factoring for many
months. Rebasing became hard since other work continued. It was not
fun. This migration plan was done intentionally to be incremental, so
that we avoid the pains of the past. I don’t think that having both
pulp 2 and pulp 3 running at the same time will require anything close
to hacks. If you look through the technical document, i’ve tried to
write up a ‘guide’ for how to accomplish all this. The goal is to
completely avoid a large amount of if pulp2 else pulp3 statements
littered through the code. They should be very isolated and rare and
I imagine if you look at the code base now, you won’t see how this is
all possible, but we plan on refactoring the code base first and make it
more manageable for a change of this magnitude. These refactorings I
think are worthwhile regardless to improve the overall quality.
Another possibility would be, to that pulp 2 and pulp 3 are installed
side by side and there is a foreman-installer option to switch between
pulp 2 and pulp 3. In this case, only the content types can be used,
which exists on the used pulp version then.
I’m not sure this is all that viable. What if a user is using two
content types and wants to upgrade? They would have to live some subset
of content to be disabled until some future version?
Regarding replacement of gofer / katello-agent, I guess remote
execution with SSH is good enough. Right?
Some users are not able to use SSH due to the nature of it. The goal is
to provide some alternative REX provider that originates communication
from the clients instead of from the server. We are still somewhat
exploring this to see how much its actually needed, but we have many
users that have reported being unable to use ssh-based REX.