[Pulp-dev] Pulp 3 installer re-work proposal

Jeremy Audet jaudet at redhat.com
Mon Dec 11 17:45:53 UTC 2017

Here's what I *meant* to send.

> Jeremy,
> I know we discussed this idea before - thank you very much for putting
> together a write up & sending it to the list for discussion. I hope
> you get lots of feedback.
> Quick feedback:
> #1. A date of when you would like feedback would be helpful.

Sooner is better. There is no deadline for this. It's a case of "the longer
this drags on, the longer the technical debt under discussion will hurt us."

How about wrapping up this discussion by Monday, January 8th? That'll give
us a little over two weeks to discuss this.

> #2. Implementation Strategy section - it would be helpful is you named
> each option something short & sweet, and then refer to them farther
> on. In quickly reading over "this strategy" is a bit hard to keep
> track of which option you are providing thoughts on.

Good point. I'll revise it.

> #3. In quick scanning of this write up, I remember you anticipated
> that developer's had different needs than end users and QE. I don't
> see them listed very clearly - have you had a chance to describe your
> knowledge/assumption of what those needs are and how the proposals
> either do or don't address them? I take it that in proposing the 3rd
> option that those concerns are addressed?

In short, "the developer installer installs Pulp directly from source in
editable mode, along with numerous extra tools, and it enables settings
like debug mode. The end user installer installs Pulp from PyPI packages,
without extra tools, and without enabling settings like debug mode."

There are some other differences in how developers and end users use the
Pulp 3 installer(s). But I'm intent on resolving those differences by
making the installer(s) more capable. For example, developers currently
deploy Pulp 3 on Vagrant (Fedora or RHEL) hosts, whereas end users
currently deploy Pulp on arbitrary (Fedora or RHEL) hosts. My solution is
to make the dev installer more capable, so that it can install Pulp 3  on
any (Fedora or RHEL) host.

> #4 I'd end your proposal with a quick summary of your proposed solution.

To summarize:

   1. Continue distributing Pulp 3 with Ansible.
   2. Enable the following use case:

   git clone https://github.com/pulp/devel.git --branch 3.0-devcd devel/ansible
   ansible-galaxy dev-install.yml -i pulp-dev.example.com,
   ansible-galaxy src-install.yml -i pulp-src.example.com,
   ansible-galaxy pypi-install.yml -i pulp-pypi.example.com,

   3. Get there by evolving the developer installer.

> I'm still not quite clear what next steps are. But I don't have much
> experience in this area. It seems like you are asking for feedback in
> support of the last option, but I am not clear on what next steps or
> what proceeding with support on that proposal would look like.

How about this?

   1. Approve the work.
   2. Assign someone to the task. I'm game.

I'm unsure how y'all do this. There's PUPs, several issue trackers, lots of
meetings, etc. Can you help me out here?

> Thanks for sharing your thoughts here.
> Robin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/pulp-dev/attachments/20171211/865ded42/attachment.htm>

More information about the Pulp-dev mailing list