thanks for the summary!
I took the liberty to go thru this list and file Redmine issues where I
found the description to be straightforward; please see links inline.
My intention is to be able to track and triage these so that the invaluable
plug-in writer feedback isn't lost.


On Mon, Feb 12, 2018 at 10:57 PM, Brian Bouterse <>

> At the Foreman Construction day [0] last Wednesday, we had our first code
> focused plugin writer's workshop. About 6 people were actively engaged as
> we talked through the plugin API, example code, and then tried to install
> Pulp3. All of this happened over about 4-5 hours. In contrast to the
> devconf workshop which was planning focused, this was a "let's look at and
> write some code together" workshop. Two attendees came to both, and they
> got all the way to calling their own sync code.
> We got a lot of feedback, which I will try to group into some areas. (my
> feedback in parens)
> [installation issues]
> - the pypi install commands are missing the migrations and they produce
> broken installations

> - the vagrantcloud boxes couldn't have a plugin installed on them :(
> - the dev environments worked great but we didn't recommend them until we
> realized all of these other methods were broken
> - we assume the user 'pulp' in a lot of places, e.g. systemd file,
> ansible, etc
> - assumptions about Fedora both in ansible, but also the copy/paste
> commands
> - some users who copied and pasted commands didn't realize they weren't
> for their OS
> [desire for simpler things]
> - there is a strong desire to use sqlite as the default db not postgresql

> - desire to not install a message bus. (I think this is unavoidable)

> [need examples]
> - pulp_file is our example, but it's laid out into different functions and
> classes. People were confused by this because they thought the classes and
> function names are meaningful when they aren't. For example we were asked
> "what is a synchronizer"
> file/blob/master/pulp_file/app/
> - pulp_file doesn't provide a good example because changesets do
> everything for you. (The main pulp_file should be a simple, direct example
> of the objects they have to save).
> - people found pulp_example via github and thought "oh here is what I
> needed to find!" only to base their code on outdated code (we need to
> delete pulp_example)
> - a database picture would be helpful to show off the data layer objects,
> foreign keys, and attributes.
> [specific things]
> - 'id' on the inherited content unit conflicted with a content unit which
> also uses 'id'.

> - qpid vs rabbitmq defaults confusion. The settings.yaml says we default
> to qpid so they installed qpid, but really in it's rabbitmq.
> (this is a 1 line fix)

> In terms of the installation challenges, we should consider consolidating
> onto a single installation method of pip with virtualenv. Of all the
> methods we offer [1] that is the one everyone could use and no one minded.
> We could remove the other options from the install page so that for for now
> (pre-GA) everyone is doing the same, simple thing. I think we should
> consolidate our effort and not focus on end-user installations as the main
> thing right now.**
> I also think we should do these things:
> * switch pulp to use sqlite3 by default. An ansible installer can both
> install postgres and configure it, later.
> * rewrite pulp_file to be a really really simple example

> * delete pulp_example

> Please send ideas, questions, or any kind of feedback.
> [0]:
> [1]:
> ** I still see Ansible as the right cross-distro installer as we approach
> the GA date. @ichimonji10 I  am still +1 on your proposal, I think we just
> need to consolidate both dev and testing effort for now. This is similar to
> the approach for the migration tool which we know is really important but
> we aren't starting yet.
> -Brian
> _______________________________________________
> Pulp-dev mailing list
Pulp-dev mailing list

Reply via email to