[Pulp-dev] Pulp 3 in One Container

Wed Apr 22 15:56:52 UTC 2020

Hi Mike,

I owed you a reply to your robust email.

*Naming Conventions*

The first thing I noticed on going through the links and the information
that you provided me, which probably needs discussing with the wider group:

Can we have a conversation about how we refer to certain tools and
features? I think this will go a long way to adding a professional look and
feel to the content on the Pulp site. For example, if we had formal and
standardized feature names for the following list. They read like file
names rather than the culmination of rigorous intellectual labour of the
Pulp team::

   -

   pulp-insta-demo.sh
   -

   pulp-operator
   -

   docker-pulp
   -

   pulp_rpm_repos

*Related Tooling Page and Installation Options*

https://pulpproject.org/related-tooling/

I will happily take a look at some resources and work on a draft to
describe Pulp Operator, then open it up to you to comment on.

When I looked at this related tooling page, I had the following thoughts
about how to progress:

   -

   I am very new so I could be very wrong, but some of these look like "I
   can install and run Pulp to start building what I need here", while Foreman
   is a tool that has already achieved what it needs through its Pulp
   integration? Foreman is a final product that uses Pulp, while the others
   are options to start building something with Pulp? Again, apologies if I
   have confused this.
   -

   If the above assumption is correct, I would like to leave
   Foreman/Katello here (if possible add more, similar examples, however big
   or small)  and move some of the others into an installation options
   section..
   -

   I think something like a “Try Pulp” menu item with a progressive list of
   installation options, whether it is (I’m making these things up). “For
   Docker Users”, “For Kubernetes Users”, “Pulp in One Container”, “Installing
   with Ansible” or “”Manual” , with details on each, would be the way
   forward.
   - As you said, because it is possible to deploy Pulp in so many ways
   doesn't mean we should recommend all ways, so hopefully we can refine the
   list by defining key scenarios for end users.

I am happy to hear any thoughts or suggestions on this.

Thanks,

Melanie

On Thu, Apr 16, 2020 at 5:45 PM Mike DePaulo <mikedep333 at redhat.com> wrote:

> On Thu, Apr 16, 2020 at 10:26 AM Melanie Corr <mcorr at redhat.com> wrote:
>
>> Hi all,
>>
>> I was reading Dennis Kilban's blog post [1] that talks about using Pulp 3
>> in a container. Although this is not production-ready as of yet, it is a
>> valuable tool for users.
>>
>> I would like to take the content of Dennis's blog and create a 'Try Pulp
>> 3 in a Container' page so that it is easy for new users to find, with the
>> caveat that this is not production ready.
>>
>> One thing that I think could improve is the location of the container.
>> Currently it is located in Dennis's GitHub space. It would be better, if we
>> were to store it somewhere within the main Pulp project space.
>>
>> Do you think that would be possible?
>>
>> Thanks,
>>
>> Melanie
>>
>> [1]
>> https://pulpproject.org/2020/03/15/pulp-fedora31-single-container/
>>
>> --
>>
>> Melanie Corr, RHCE
>>
>> Community Manager
>>
>> Red Hat <https://www.redhat.com>
>>
>> Remote, Ireland
>>
>> mcorr at redhat.com
>> M: +353857774436     IM: mcorr
>> <https://www.redhat.com>
>>
>> _______________________________________________
>> Pulp-dev mailing list
>> Pulp-dev at redhat.com
>> https://www.redhat.com/mailman/listinfo/pulp-dev
>>
>
> Hi Melanie,
>
> Creating a new page is a good idea, but I think we need to do some other
> documentation/overviews first, to avoid confusion around our multiple
> containers approaches (single container vs pulp-operator.) Also to decide
> on which easy approach to promote as the best way to *try* pulp.
>
> I agree with you on moving the repo, but note that a rename is planned, so
> they should probably be done at the same time.
>
>
> *Background*:
>
> We started work on pulp-operator (a Kubernetes operator) as a
> sophisticated set of containers for running Pulp months ago. Once
> production ready, it will be easy to run for users *if* they already have a
> full Kubernetes container infrastructure; operators are supposed to provide
> an app-store like experience where the # of containers is abstracted away.
>
> Later on, we discovered that we could provide a quick & easy way for users
> to try Pulp 3 by writing an install script around pulp-operator and K3s
> (lightweight kubernetes.) It's almost like an alternate mode of
> pulp-operator. It is called "pulp-insta-demo.sh", and it is listed on our
> home page as "Quickly Try Pulp": https://pulpproject.org/ . All users
> have to do is run it on a standard Linux desktop. laptop or server, without
> any options or config, and it usually works.
>
> Because many users need to use a single host to run a single container,
> with directories for storage, etc, we later started work on the single
> container.
>
> I've been meaning to write a post about pulp-operator, introducing it, but
> didn't have time.
>
> Then Dennis and I intended to add a comparison to pulp-operator in his
> post, but it fell through the cracks in this hectic (global crisis) month.
>
> I did however write a related-tooling page afterwards, that minimally
> introduces pulp-operator, and compares pulp-operator to the single
> container:
> https://pulpproject.org/related-tooling/
> https://github.com/pulp/pulpproject.org/pull/253 (PR I just submitted to
> add pulp-insta-demo.sh)
>
>
> *What I propose we do*:
>
> I think we should write a post introducing pulp-operator, including
> pulp-insta-demo.sh .
>
> Then write another post comparing the 2 container solutions
> (pulp-operator/pulp-insta-demo vs the single container) in greater detail
> than the "related tooling" page does.
> Perhaps it should be a page (rather than blog post) comparing
> pulp_installer as well. An overview of all the ways to install Pulp 3.
> (To make matters more complicated, we also have manual install
> instructions, which is a manual way of deploying Pulp how pulp_installer
> does.)
>
> Then we should decide which approach (single container vs pulp-insta-demo
> mod of pulp-operator) to list as the recommended way to try Pulp 3. (Again,
> currently the home page has pulp-insta-demo.)
>
> Then we should write a page about the easiest way to try Pulp 3.
>
>
> Again, these are only my thoughts, and what I've been planning to do. I am
> very glad you joined our team; because having multiple installers/packages
> is a situation that I really feel we need community manager guidance on.
>
> -Mike
>
> --
>
> Mike DePaulo
>
> He / Him / His
>
> Service Reliability Engineer, Pulp
>
> Red Hat <https://www.redhat.com/>
>
> IM: mikedep333
>
> GPG: 51745404
> <https://www.redhat.com/>
>

-- 

Melanie Corr, RHCE

Community Manager

Red Hat <https://www.redhat.com>

Remote, Ireland

mcorr at redhat.com
M: +353857774436     IM: mcorr
<https://www.redhat.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/pulp-dev/attachments/20200422/d17776ff/attachment.htm>