Re: [Pulp-dev] Plugin Writer's Coding Workshop Feedback

[Matthias Dellweg]

You forgot to mention the huge amount of fun, we had while debugging
the designated pulp3 development environment.
But i agree, that focussing on one environment (that fits all,
including core and plugin development) sounds reasonable. And the
vagrant setup with ansible roles sounds like my first choice. It is
quite reliable and reproducable. Also it works well in the pulp2 case.
Thank you for the good discussions at Gent,
  cheers Matthias

On Mon, 12 Feb 2018 16:57:04 -0500
Brian Bouterse  wrote:

> 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"
> https://github.com/pulp/pulp_file/blob/master/pulp_file/app/tasks.py#L139
> - 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 settings.py
> 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]: http://cfgmgmtcamp.eu/fringe.html#foreman
> [1]:
> https://docs.pulpproject.org/en/3.0/nightly/installation/index.html
> 
> ** 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@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev

Re: [Pulp-dev] Adding Model.created.

[Jeff Ortel]

FYI: https://github.com/pulp/pulp/pull/3325

On 02/12/2018 03:01 PM, Dennis Kliban wrote:

+1 to created and +1 to updated.

On Mon, Feb 12, 2018 at 3:52 PM, David Davis > wrote:


+1. Also, wondering if we should add a Model.last_updated field as
well.


David

On Mon, Feb 12, 2018 at 12:22 PM, Jeff Ortel > wrote:

A few of our models have a field:

created = models.DateTimeField(auto_now_add=True)

To support ordering needed by a FilePlugin use case, I'm
planning to add Content.created as it seems generally useful
and I believe will be needed by most plugins.  This raises a
more general question: should we add Model.created instead? 
Knowing when most things get created seems generally useful. 
For example, knowing when an artifact got created tells uses
when it got downloaded.  Things like that.

Thoughts?



___
Pulp-dev mailing list
Pulp-dev@redhat.com 
https://www.redhat.com/mailman/listinfo/pulp-dev




___
Pulp-dev mailing list
Pulp-dev@redhat.com 
https://www.redhat.com/mailman/listinfo/pulp-dev





___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev

Re: [Pulp-dev] Adding Model.created.

[Dennis Kliban]

+1 to created and +1 to updated.

On Mon, Feb 12, 2018 at 3:52 PM, David Davis  wrote:

> +1. Also, wondering if we should add a Model.last_updated field as well.
>
>
> David
>
> On Mon, Feb 12, 2018 at 12:22 PM, Jeff Ortel  wrote:
>
>> A few of our models have a field:
>>
>> created = models.DateTimeField(auto_now_add=True)
>>
>> To support ordering needed by a FilePlugin use case, I'm planning to add
>> Content.created as it seems generally useful and I believe will be needed
>> by most plugins.  This raises a more general question: should we add
>> Model.created instead?  Knowing when most things get created seems
>> generally useful.  For example, knowing when an artifact got created tells
>> uses when it got downloaded.  Things like that.
>>
>> Thoughts?
>>
>>
>>
>> ___
>> Pulp-dev mailing list
>> Pulp-dev@redhat.com
>> https://www.redhat.com/mailman/listinfo/pulp-dev
>>
>>
>
> ___
> Pulp-dev mailing list
> Pulp-dev@redhat.com
> https://www.redhat.com/mailman/listinfo/pulp-dev
>
>
___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev

Re: [Pulp-dev] Adding Model.created.

[David Davis]

+1. Also, wondering if we should add a Model.last_updated field as well.


David

On Mon, Feb 12, 2018 at 12:22 PM, Jeff Ortel  wrote:

> A few of our models have a field:
>
> created = models.DateTimeField(auto_now_add=True)
>
> To support ordering needed by a FilePlugin use case, I'm planning to add
> Content.created as it seems generally useful and I believe will be needed
> by most plugins.  This raises a more general question: should we add
> Model.created instead?  Knowing when most things get created seems
> generally useful.  For example, knowing when an artifact got created tells
> uses when it got downloaded.  Things like that.
>
> Thoughts?
>
>
>
> ___
> Pulp-dev mailing list
> Pulp-dev@redhat.com
> https://www.redhat.com/mailman/listinfo/pulp-dev
>
>
___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev

[Pulp-dev] Adding Model.created.

[Jeff Ortel]

A few of our models have a field:

created = models.DateTimeField(auto_now_add=True)

To support ordering needed by a FilePlugin use case, I'm planning to add 
Content.created as it seems generally useful and I believe will be 
needed by most plugins. This raises a more general question: should we 
add Model.created instead?  Knowing when most things get created seems 
generally useful.  For example, knowing when an artifact got created 
tells uses when it got downloaded.  Things like that.


Thoughts?


___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev

Re: [Pulp-dev] Release Announcing and Versioning

[Brian Bouterse]

The first one or two releases we do this for, we'll do by hand, but here is
the redmine ticket on the automation to match:
https://pulp.plan.io/issues/3348

Can someone groom or comment on it?


On Tue, Feb 6, 2018 at 3:20 PM, Jeremy Audet  wrote:

> > Nope, it does not.  THe tooling I'm looking at modifying to use with
> pulp from my end can handle that situation, as wel as multiple commits to
> an issue.
>
> Great!
>
> ___
> Pulp-dev mailing list
> Pulp-dev@redhat.com
> https://www.redhat.com/mailman/listinfo/pulp-dev
>
>
___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev

[Pulp-dev] 2.15.2 dev freeze -- 22:00 UTC Tuesday Feb 13th

[Brian Bouterse]

Any Pulp2 core or plugin code that you want included in the 2.15.2 release
must be:

a) merged to master by 22:00 UTC, Tuesday Feb 13th
b) be associated with a bugfix issue. stories, refactors, and tasks are not
included in z-stream releases.

This is a new process so send any questions or ideas!

-Brian
___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev