Re: [Pulp-dev] Importer Name

[David Davis]

Austin and Jeff,

Thanks for the responses. I am happy with moving forward and opening an
issue in redmine for this change

I think I am +0 on dropping the fields. However, if we start to get
complaints from our users, I think we should consider adding them back.


David

On Wed, Mar 14, 2018 at 10:16 AM, Jeff Ortel  wrote:

> In pulp3, users need to keep track for a number of things.  For example,
> without auto publish, users need to keep track of which importer(s) and
> publishers need to be used for sync/publish workflows.  I fully expect that
> users using the API will be maintaining some kind of automation/
> orchestration on their end (shell scripts, ansible).  So, keeping track
> of sync and download policies does not seem like much of a burden.  Also,
> after further consideration, I don't think that storing either the sync
> (mode) or download policy on the repository is appropriate.
>
>
> On 03/13/2018 04:59 PM, David Davis wrote:
>
> Can you elaborate on what made you reconsider? Asking because I still see
> the point that you and Justin raised about dropping the fields as an issue.
>
>
> David
>
> On Mon, Mar 12, 2018 at 12:31 PM, Jeff Ortel  wrote:
>
>>
>>
>> On 03/12/2018 10:28 AM, Jeff Ortel wrote:
>>
>> On 03/08/2018 10:13 AM, Austin Macdonald wrote:
>>
>> Motivation:
>> The name "importer" carries some inaccurate implications.
>> 1) Importers should "import". Tasks like "sync" will do the actual
>> importing. The object only holds the configuration that happens to be used
>> by sync tasks.
>> 2) Sync tasks on mirror mode remove content as well as add it, so
>> "import" isn't quite right.
>>
>> Proposed name: Remote
>>
>> The inspiration for remote is "git remote". In git, remotes represent
>> external repositories, which is almost exactly what our importers do.
>>
>>
>> +1, The git/ostree "remote" concept applies very well to most of what an
>> "importer" defines in pulp.
>>
>>
>> ---
>> Part 2: Trim the fields
>>
>> Currently, Importers have settings that can be categorized in 2 ways. I
>> am proposing removing the "sync settings" from the Remote model:
>>
>> External Source information
>> name
>> feed_url
>> validate
>> ssl_ca_certificate
>> ssl_client_certificate
>> ssl_client_key
>> ssl_validation
>> proxy_url
>> username
>> password
>>
>> Sync settings
>> download_policy
>> sync_mode
>>
>> This had some advantages when Importers were related to Repositories. For
>> example, having a repository.importer that always used the same sync mode
>> made sense. However, the "how" to sync settings don't make much sense when
>> importers and repositories are not linked. It seems very reasonable that a
>> user might have 2 repositories that sync from the same source (ex EPEL). It
>> does not make sense for them to have create an Importer for the EPEL
>> repository twice or more just to change sync_mode or download policy.
>> Instead of modeling these fields, I propose that they should POST body
>> parameters.
>>
>>
>> I, as a user, don't like having to specify download_policy &  sync_mode
>> on every request.  The burden on the user to passing these consistently
>> seems unnecessary and prone to error.  And, like something that pulp should
>> store as part of it's value proposition.   Imagine an organization with
>> tons of repositories and admins.  They would need to maintain a
>> spreadsheet, notes, scripts for these settings so that admin A is syncing
>> using the same settings as admin B.
>>
>> Perhaps download_policy &  sync_mode should be attributes of the
>> repository.  Thoughts on moving them there.  The sync_mode
>> (mirror/additive) may need to be renamed in a way that changes it from
>> describing how the importer is syning to something that defines the type of
>> repository.  Like that the repository is intended to be a mirror or not.
>> Perhaps just a "mirror" (bool) attribute.
>>
>>
>> I have reconsidered this.  Disregard.
>>
>>
>> example
>>
>> POST v3/remotes/1234/sync/ repositorty=myrepo_href sync_mode=additive,
>> dl_policy=immediate
>> POST v3/remotes/1234/sync/ repositorty=myother_href sync_mode=mirror,
>> dl_policy=deferred
>>
>>
>>
>> ___
>> Pulp-dev mailing 
>> listPulp-dev@redhat.comhttps://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] Plugin relationship to tasks

[Austin Macdonald]

I spoke with daviddavis about this and I would like to narrow the scope a
bit. This discussion should be limited to endpoints that deploy tasks. The
possibility for collisions that David pointed out regarding
v3/content// is real, but should be discussed separately because
Content objects should follow the pattern of the other plugin defined
objects. All of them are master/detail so the namespacing
v3/plugin//content/ would go deeply against the grain.


On Mar 15, 2018 10:53, "David Davis"  wrote:

I have an amendment to this proposal. Instead of namespacing just the
plugin task routes, I’d propose we namespace all plugin routes. Thus all
plugin routes would be namespaced under something like
“/api/v3/plugin//“. For example, “/api/v3/content/file/” gets
moved to “/api/v3/plugin/file/content/” and so on.


For task routes, plugins could still route to a pulpcore viewset/action:

User route: POST /api/v3/plugin/file/repository_version/ add_content=[…]

Routes to: POST /api/v3/tasks plugin=file task=create_repository_version
add_content=[…]


AFAIK, we don't have a good mechanism for validating and re-routing
endpoints quite like this. Instead, a view or viewset would be created,
validation performed, and then a task is deployed. The task itself could be
a vanilla task from pulpcore though. Another issue is that a POST to
v3/plugin/file/repository_version/ implies that the resultant
repository_version is typed in some way. The created resource href would
still take the form v3/repositories/1234/versions/2/, so I think this is a
little misleading.

For the other endpoint:
 /api/v3/tasks plugin=file task=create_repository_version add_content=[…]

There is a still the problem is that POST requests should not contain
parameters that influence the allowable parameter set. For instance,
plugin=python might require an additional parameter that is not allowed for
the file plugin. In particular, this affects the auto-documented REST API.

However, the concept in general could work. I've adapted David's suggestion
and will present it side by side with the original idea. Note, this only
applies to "actions", which are sync, publish, add/remove, and
plugin-specific actions (including rich-dependency adding).

The difference between the two ideas is based in semantics. Both would
deploy the same task functions.

"Action Based"
POST v3/plugin/file/sync/
Note that "sync" is singular. This is a file-plugin action to sync using
the body parameters.

"Task Object Based"
POST v3/tasks/file/syncs/
Note that "syncs" is plural. This is a POST that creates a file-sync task
object,.

Discussion:
Another consideration is "Where will a Live API live?". A benefit of
David's proposal is that we would be providing plugins with a namespaced
area to do whatever they need, from live api to actions. We probably would
want to create this namespace for things like live apis even if we go in
the tasks/file/syncs/ direction. The only downside of this part of David's
proposal is that our endpoints will still be "action" verbs instead of
nouns, and I am ok with that.
___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev

Re: [Pulp-dev] 2.16.0 dev freeze -- 22:00 UTC Tuesday, March 13th

[Patrick Creech]

On Wed, 2018-03-14 at 15:53 -0400, Brian Bouterse wrote:
> Here is one final feature that was added as a dev-freeze exception through 
> discussion with rpm plugin devs and @pcreech:  
> https://pulp.plan.io/issues/3444  It is merged, tested, and ready to go.
> 
> @pcreech can you ack when pulp/pulp_rpm:2.16-release is rebased?
> 

Sorry, I didn't see this e-mail untill just now.  Very shortly after the above 
issue was merged to pulp_rpm, I updated the 2.16-release branch.  It will land 
with 2.16.0

> 
> On Tue, Mar 13, 2018 at 6:33 PM, Tatiana Tereshchenko  
> wrote:
> > The code for 2.16.0 is now frozen. There are a total of 9 
> > stories/tasks/refactors prepared for the release:
> > 
> > https://pulp.plan.io/issues?query_id=61
> > 
> > Tanya
> > 
> > On Tue, Mar 13, 2018 at 11:05 AM, Tatiana Tereshchenko 
> >  wrote:
> > > Any Pulp2 core or plugin code that you want included in the 2.16.0 
> > > release must be:
> > > 
> > > a) merged to master by 22:00 UTC, March 13th
> > > b) associated with a story, refactor, task or a bugfix issue.
> > > 
> > > If you want/need to adjust this date, please reply on list.
> > > 
> > > Thanks, 
> > > Tanya
> > > 
> > 
> > 
> > On Tue, Mar 13, 2018 at 11:05 AM, Tatiana Tereshchenko 
> >  wrote:
> > > Any Pulp2 core or plugin code that you want included in the 2.16.0 
> > > release must be:
> > > 
> > > a) merged to master by 22:00 UTC, March 13th
> > > b) associated with a story, refactor, task or a bugfix issue.
> > > 
> > > If you want/need to adjust this date, please reply on list.
> > > 
> > > Thanks, 
> > > Tanya
> > > 
> > 
> > 
> > ___
> > 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

signature.asc
Description: This is a digitally signed message part
___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev

Re: [Pulp-dev] 2.16.0 dev freeze -- 22:00 UTC Tuesday, March 13th

[Dennis Kliban]

Mihai, I believe your changes made it into 2.16.0.

On Tue, Mar 13, 2018 at 9:54 PM, Mihai Ibanescu 
wrote:

> Does that mean that https://github.com/pulp/pulp_rpm/pull/1093 did not
> make the cut?
>
> I think it would be a shame for that to be pushed to 2.17. But I'm biased
> since it's my code :-)
>
> On Tue, Mar 13, 2018 at 6:33 PM, Tatiana Tereshchenko  > wrote:
>
>> The code for 2.16.0 is now frozen. There are a total of 9
>> stories/tasks/refactors prepared for the release:
>>
>> https://pulp.plan.io/issues?query_id=61
>>
>> Tanya
>>
>> On Tue, Mar 13, 2018 at 11:05 AM, Tatiana Tereshchenko <
>> ttere...@redhat.com> wrote:
>>
>>> Any Pulp2 core or plugin code that you want included in the 2.16.0
>>> release must be:
>>>
>>> a) merged to master by 22:00 UTC, March 13th
>>> b) associated with a story, refactor, task or a bugfix issue.
>>>
>>> If you want/need to adjust this date, please reply on list.
>>>
>>> Thanks,
>>> Tanya
>>>
>>>
>>
>> On Tue, Mar 13, 2018 at 11:05 AM, Tatiana Tereshchenko <
>> ttere...@redhat.com> wrote:
>>
>>> Any Pulp2 core or plugin code that you want included in the 2.16.0
>>> release must be:
>>>
>>> a) merged to master by 22:00 UTC, March 13th
>>> b) associated with a story, refactor, task or a bugfix issue.
>>>
>>> If you want/need to adjust this date, please reply on list.
>>>
>>> Thanks,
>>> Tanya
>>>
>>>
>>
>> ___
>> 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] Removing a few sprint items?

[Jeremy Audet]

I should clarify tha my main concern with regards to #2921 is to have *any*
code in place that configures web serves for Pulp 3. Publicising it is a
nice thing too, but at this point in time, my target audience is developers
and QE. On a related note, references to Ansible were dropped from the Pulp
3 documentation.
___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev

Re: [Pulp-dev] Removing a few sprint items?

[Brian Bouterse]

Thank you both for the feedback. I share the concern that we may run out of
NEW items. I added a monday meeting agenda item for us to check-in on if
additional work needs to be added then. I'm wanting to defer adding more
today with the hope that sprint 34 will get to 100% modified and will have
nothing to carry forward.

With no -1's, let's, I'll remove those three. If others find this note
after it's been done and want to change it, please bring this back up.
Consensus on mailing lists is hard. :)

On Thu, Mar 15, 2018 at 9:30 AM, David Davis  wrote:

> I just want to point out that we only have 4 NEW non-plugin issues on the
> sprint and 2 weeks left. If we remove these three issues, then we’ll only
> have 2 pulpcore issues left.
>
> I’m not opposed to removing these issues but we should maybe consider
> adding a few.
>
>
> David
>
> On Thu, Mar 15, 2018 at 7:19 AM, Ina Panova  wrote:
>
>> #2988 was automatically moved to srpint 34 because it was in assigned
>> state and the assignee was not present on the planning so we moved it
>> forward and let the decision up to the assignee whether to continue to work
>> on this or drop form the sprint.
>> Since you're just unassigned it i think we can drop this issue from the
>> sprint.
>>
>>
>>
>>
>> 
>> Regards,
>>
>> Ina Panova
>> Software Engineer| Pulp| Red Hat Inc.
>>
>> "Do not go where the path may lead,
>>  go instead where there is no path and leave a trail."
>>
>> On Wed, Mar 14, 2018 at 5:03 PM, Brian Bouterse 
>> wrote:
>>
>>> I didn't get a chance until now to look at the sprint 34 items in a
>>> detailed way. I want us to consider removing three of them from the sprint.
>>> The reasoning is that these areas of work are not part of the pulp3 core
>>> beta deliverables.
>>>
>>> Exception when raising a user-Defined Exception that has a custom
>>> __init__ signature [0]
>>>
>>> Create and publish an ansible role to install apache and configure it
>>> for pulp [1]  <--- note the code already support Apache and nginx
>>>
>>> Distribute Pulp with Pulp [2]
>>>
>>> Can others give input on this decision?
>>>
>>> [0]: https://pulp.plan.io/issues/2988
>>> [1]: https://pulp.plan.io/issues/2921
>>> [2]: https://pulp.plan.io/issues/2325
>>>
>>> Thank you!
>>> Brian
>>>
>>> ___
>>> 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] Plugin relationship to tasks

[David Davis]

I have an amendment to this proposal. Instead of namespacing just the
plugin task routes, I’d propose we namespace all plugin routes. Thus all
plugin routes would be namespaced under something like
“/api/v3/plugin//“. For example, “/api/v3/content/file/” gets
moved to “/api/v3/plugin/file/content/” and so on.

For task routes, plugins could still route to a single pulpcore
viewset/action:

User route: POST /api/v3/plugin/file/repository_version/ add_content=[…]
Routes to: POST /api/v3/tasks plugin=file task=create_repository_version
add_content=[…]

User route: POST /api/v3/plugin/file/syncs/ repo=repo_href
importer=importer_href
Routes to: POST /api/v3/tasks plugin=file task=sync  repo=repo_href
importer=importer_href

We’d give a way for plugins to specify which URLs map to a task and what
the expected parameters are.

Benefits:
- Avoids all potential conflicts as long as plugin names are unique. For
example, if my plugin has multiple content types and one is ‘file’, I can
set up “/api/v3/content/file” which will conflict with pulp_file.
- No leaky abstraction in our URLs. Users don’t have to know whether a
particular URL produces a task or not to find its URL.
- It’s easy to find all the plugin routes (not just tasks routes) for a
particular plugin. They’re at “/api/v3/plugin//“.
- Plugins have more freedom and aren’t constrained to defining certain
predefined routes.


David

On Wed, Mar 14, 2018 at 3:58 PM, Jeremy Audet  wrote:

> I reviewed this proposal with Austin, mainly from the perspective of an
> end user. In my opinion, this proposal is a good one. I find the semantics
> intuitive and I think they do a good job of adhering to the Richardson
> Maturity Model
> . And
> although I don't have a great knowledge of how plugins work, I think this
> will grant more flexibility to plugins.
>
> ___
> 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] Removing a few sprint items?

[David Davis]

I just want to point out that we only have 4 NEW non-plugin issues on the
sprint and 2 weeks left. If we remove these three issues, then we’ll only
have 2 pulpcore issues left.

I’m not opposed to removing these issues but we should maybe consider
adding a few.


David

On Thu, Mar 15, 2018 at 7:19 AM, Ina Panova  wrote:

> #2988 was automatically moved to srpint 34 because it was in assigned
> state and the assignee was not present on the planning so we moved it
> forward and let the decision up to the assignee whether to continue to work
> on this or drop form the sprint.
> Since you're just unassigned it i think we can drop this issue from the
> sprint.
>
>
>
>
> 
> Regards,
>
> Ina Panova
> Software Engineer| Pulp| Red Hat Inc.
>
> "Do not go where the path may lead,
>  go instead where there is no path and leave a trail."
>
> On Wed, Mar 14, 2018 at 5:03 PM, Brian Bouterse 
> wrote:
>
>> I didn't get a chance until now to look at the sprint 34 items in a
>> detailed way. I want us to consider removing three of them from the sprint.
>> The reasoning is that these areas of work are not part of the pulp3 core
>> beta deliverables.
>>
>> Exception when raising a user-Defined Exception that has a custom
>> __init__ signature [0]
>>
>> Create and publish an ansible role to install apache and configure it for
>> pulp [1]  <--- note the code already support Apache and nginx
>>
>> Distribute Pulp with Pulp [2]
>>
>> Can others give input on this decision?
>>
>> [0]: https://pulp.plan.io/issues/2988
>> [1]: https://pulp.plan.io/issues/2921
>> [2]: https://pulp.plan.io/issues/2325
>>
>> Thank you!
>> Brian
>>
>> ___
>> 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] Removing a few sprint items?

[Ina Panova]

#2988 was automatically moved to srpint 34 because it was in assigned state
and the assignee was not present on the planning so we moved it forward and
let the decision up to the assignee whether to continue to work on this or
drop form the sprint.
Since you're just unassigned it i think we can drop this issue from the
sprint.





Regards,

Ina Panova
Software Engineer| Pulp| Red Hat Inc.

"Do not go where the path may lead,
 go instead where there is no path and leave a trail."

On Wed, Mar 14, 2018 at 5:03 PM, Brian Bouterse  wrote:

> I didn't get a chance until now to look at the sprint 34 items in a
> detailed way. I want us to consider removing three of them from the sprint.
> The reasoning is that these areas of work are not part of the pulp3 core
> beta deliverables.
>
> Exception when raising a user-Defined Exception that has a custom __init__
> signature [0]
>
> Create and publish an ansible role to install apache and configure it for
> pulp [1]  <--- note the code already support Apache and nginx
>
> Distribute Pulp with Pulp [2]
>
> Can others give input on this decision?
>
> [0]: https://pulp.plan.io/issues/2988
> [1]: https://pulp.plan.io/issues/2921
> [2]: https://pulp.plan.io/issues/2325
>
> Thank you!
> Brian
>
> ___
> 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] 2.16.0 dev freeze -- 22:00 UTC Tuesday, March 13th

[Mihai Ibanescu]

Does that mean that https://github.com/pulp/pulp_rpm/pull/1093 did not make
the cut?

I think it would be a shame for that to be pushed to 2.17. But I'm biased
since it's my code :-)

On Tue, Mar 13, 2018 at 6:33 PM, Tatiana Tereshchenko 
wrote:

> The code for 2.16.0 is now frozen. There are a total of 9
> stories/tasks/refactors prepared for the release:
>
> https://pulp.plan.io/issues?query_id=61
>
> Tanya
>
> On Tue, Mar 13, 2018 at 11:05 AM, Tatiana Tereshchenko <
> ttere...@redhat.com> wrote:
>
>> Any Pulp2 core or plugin code that you want included in the 2.16.0
>> release must be:
>>
>> a) merged to master by 22:00 UTC, March 13th
>> b) associated with a story, refactor, task or a bugfix issue.
>>
>> If you want/need to adjust this date, please reply on list.
>>
>> Thanks,
>> Tanya
>>
>>
>
> On Tue, Mar 13, 2018 at 11:05 AM, Tatiana Tereshchenko <
> ttere...@redhat.com> wrote:
>
>> Any Pulp2 core or plugin code that you want included in the 2.16.0
>> release must be:
>>
>> a) merged to master by 22:00 UTC, March 13th
>> b) associated with a story, refactor, task or a bugfix issue.
>>
>> If you want/need to adjust this date, please reply on list.
>>
>> Thanks,
>> Tanya
>>
>>
>
> ___
> 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] Importer Name

[Jeff Ortel]

In pulp3, users need to keep track for a number of things.  For example, 
without auto publish, users need to keep track of which importer(s) and 
publishers need to be used for sync/publish workflows.  I fully expect 
that users using the API will be maintaining some kind of 
automation/orchestration on their end (shell scripts, ansible). So, 
keeping track of sync and download policies does not seem like much of a 
burden.  Also, after further consideration, I don't think that storing 
either the sync (mode) or download policy on the repository is appropriate.



On 03/13/2018 04:59 PM, David Davis wrote:
Can you elaborate on what made you reconsider? Asking because I still 
see the point that you and Justin raised about dropping the fields as 
an issue.



David

On Mon, Mar 12, 2018 at 12:31 PM, Jeff Ortel > wrote:




On 03/12/2018 10:28 AM, Jeff Ortel wrote:

On 03/08/2018 10:13 AM, Austin Macdonald wrote:

Motivation:
The name "importer" carries some inaccurate implications.
1) Importers should "import". Tasks like "sync" will do the
actual importing. The object only holds the configuration that
happens to be used by sync tasks.
2) Sync tasks on mirror mode remove content as well as add it,
so "import" isn't quite right.

Proposed name: Remote

The inspiration for remote is "git remote". In git, remotes
represent external repositories, which is almost exactly what
our importers do.


+1, The git/ostree "remote" concept applies very well to most of
what an "importer" defines in pulp.



---
Part 2: Trim the fields

Currently, Importers have settings that can be categorized in 2
ways. I am proposing removing the "sync settings" from the
Remote model:

External Source information
    name
    feed_url
    validate
    ssl_ca_certificate
    ssl_client_certificate
    ssl_client_key
    ssl_validation
    proxy_url
    username
    password

Sync settings
    download_policy
    sync_mode

This had some advantages when Importers were related to
Repositories. For example, having a repository.importer that
always used the same sync mode made sense. However, the "how" to
sync settings don't make much sense when importers and
repositories are not linked. It seems very reasonable that a
user might have 2 repositories that sync from the same source
(ex EPEL). It does not make sense for them to have create an
Importer for the EPEL repository twice or more just to change
sync_mode or download policy. Instead of modeling these fields,
I propose that they should POST body parameters.


I, as a user, don't like having to specify download_policy & 
sync_mode on every request.  The burden on the user to passing
these consistently seems unnecessary and prone to error.  And,
like something that pulp should store as part of it's value
proposition.   Imagine an organization with tons of repositories
and admins.  They would need to maintain a spreadsheet, notes,
scripts for these settings so that admin A is syncing using the
same settings as admin B.

Perhaps download_policy &  sync_mode should be attributes of the
repository.  Thoughts on moving them there.  The sync_mode
(mirror/additive) may need to be renamed in a way that changes it
from describing how the importer is syning to something that
defines the type of repository.  Like that the repository is
intended to be a mirror or not. Perhaps just a "mirror" (bool)
attribute.


I have reconsidered this.  Disregard.



example
POST v3/remotes/1234/sync/ repositorty=myrepo_href
sync_mode=additive, dl_policy=immediate
POST v3/remotes/1234/sync/ repositorty=myother_href
sync_mode=mirror, dl_policy=deferred



___
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

[Pulp-dev] Removing a few sprint items?

[Brian Bouterse]

I didn't get a chance until now to look at the sprint 34 items in a
detailed way. I want us to consider removing three of them from the sprint.
The reasoning is that these areas of work are not part of the pulp3 core
beta deliverables.

Exception when raising a user-Defined Exception that has a custom __init__
signature [0]

Create and publish an ansible role to install apache and configure it for
pulp [1]  <--- note the code already support Apache and nginx

Distribute Pulp with Pulp [2]

Can others give input on this decision?

[0]: https://pulp.plan.io/issues/2988
[1]: https://pulp.plan.io/issues/2921
[2]: https://pulp.plan.io/issues/2325

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

Re: [Pulp-dev] 2.16.0 dev freeze -- 22:00 UTC Tuesday, March 13th

[Brian Bouterse]

Here is one final feature that was added as a dev-freeze exception through
discussion with rpm plugin devs and @pcreech:  https://pulp.plan.io/issues/
3444  It is merged, tested, and ready to go.

@pcreech can you ack when pulp/pulp_rpm:2.16-release is rebased?

The query now contains 10 items:  https://pulp.plan.io/issues?query_id=61

Brian



On Tue, Mar 13, 2018 at 6:33 PM, Tatiana Tereshchenko 
wrote:

> The code for 2.16.0 is now frozen. There are a total of 9
> stories/tasks/refactors prepared for the release:
>
> https://pulp.plan.io/issues?query_id=61
>
> Tanya
>
> On Tue, Mar 13, 2018 at 11:05 AM, Tatiana Tereshchenko <
> ttere...@redhat.com> wrote:
>
>> Any Pulp2 core or plugin code that you want included in the 2.16.0
>> release must be:
>>
>> a) merged to master by 22:00 UTC, March 13th
>> b) associated with a story, refactor, task or a bugfix issue.
>>
>> If you want/need to adjust this date, please reply on list.
>>
>> Thanks,
>> Tanya
>>
>>
>
> On Tue, Mar 13, 2018 at 11:05 AM, Tatiana Tereshchenko <
> ttere...@redhat.com> wrote:
>
>> Any Pulp2 core or plugin code that you want included in the 2.16.0
>> release must be:
>>
>> a) merged to master by 22:00 UTC, March 13th
>> b) associated with a story, refactor, task or a bugfix issue.
>>
>> If you want/need to adjust this date, please reply on list.
>>
>> Thanks,
>> Tanya
>>
>>
>
> ___
> 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] Plugin relationship to tasks

[Jeremy Audet]

I reviewed this proposal with Austin, mainly from the perspective of an end
user. In my opinion, this proposal is a good one. I find the semantics
intuitive and I think they do a good job of adhering to the Richardson
Maturity Model
. And
although I don't have a great knowledge of how plugins work, I think this
will grant more flexibility to plugins.
___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev