Re: [Pulp-dev] Importer Name

[David Davis]

I was one of the voices of dissent on this but I am more of a -0/+0 than a
-1.


David

On Fri, Mar 23, 2018 at 2:56 PM, Dana Walker  wrote:

> FWIW, I've looked them over and think they're good, but given the +/- 1's
> discussion on IRC, you may want to get further grooming consensus still.
>
> --Dana
>
> Dana Walker
>
> Associate Software Engineer
>
> Red Hat
>
> 
> 
>
> On Fri, Mar 23, 2018 at 1:51 PM, Austin Macdonald 
> wrote:
>
>> Would anyone mind grooming these? Also, last change to shut it down :)
>> https://pulp.plan.io/issues/3488
>> https://pulp.plan.io/issues/3492
>>
>>
>>
>> On Fri, Mar 16, 2018 at 9:27 AM, Austin Macdonald 
>> wrote:
>>
>>> Ive created tasks to do this work.
>>>
>>> Rename:
>>> https://pulp.plan.io/issues/3488
>>>
>>> Move sync_mode, remove download_policy
>>> https://pulp.plan.io/issues/3492
>>>
>>> Each of these has corresponding plugin tasks, which are related to them.
>>>
>>> On Thu, Mar 15, 2018 at 4:16 PM, David Davis 
>>> wrote:
>>>
 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 usi

Re: [Pulp-dev] Importer Name

[Dennis Kliban]

Austin, those look good to me also. I've marked them as groomed and added
them to the sprint.

On Fri, Mar 23, 2018 at 2:56 PM, Dana Walker  wrote:

> FWIW, I've looked them over and think they're good, but given the +/- 1's
> discussion on IRC, you may want to get further grooming consensus still.
>
> --Dana
>
> Dana Walker
>
> Associate Software Engineer
>
> Red Hat
>
> 
> 
>
> On Fri, Mar 23, 2018 at 1:51 PM, Austin Macdonald 
> wrote:
>
>> Would anyone mind grooming these? Also, last change to shut it down :)
>> https://pulp.plan.io/issues/3488
>> https://pulp.plan.io/issues/3492
>>
>>
>>
>> On Fri, Mar 16, 2018 at 9:27 AM, Austin Macdonald 
>> wrote:
>>
>>> Ive created tasks to do this work.
>>>
>>> Rename:
>>> https://pulp.plan.io/issues/3488
>>>
>>> Move sync_mode, remove download_policy
>>> https://pulp.plan.io/issues/3492
>>>
>>> Each of these has corresponding plugin tasks, which are related to them.
>>>
>>> On Thu, Mar 15, 2018 at 4:16 PM, David Davis 
>>> wrote:
>>>
 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 sync

Re: [Pulp-dev] Importer Name

[Dana Walker]

FWIW, I've looked them over and think they're good, but given the +/- 1's
discussion on IRC, you may want to get further grooming consensus still.

--Dana

Dana Walker

Associate Software Engineer

Red Hat




On Fri, Mar 23, 2018 at 1:51 PM, Austin Macdonald 
wrote:

> Would anyone mind grooming these? Also, last change to shut it down :)
> https://pulp.plan.io/issues/3488
> https://pulp.plan.io/issues/3492
>
>
>
> On Fri, Mar 16, 2018 at 9:27 AM, Austin Macdonald 
> wrote:
>
>> Ive created tasks to do this work.
>>
>> Rename:
>> https://pulp.plan.io/issues/3488
>>
>> Move sync_mode, remove download_policy
>> https://pulp.plan.io/issues/3492
>>
>> Each of these has corresponding plugin tasks, which are related to them.
>>
>> On Thu, Mar 15, 2018 at 4:16 PM, David Davis 
>> wrote:
>>
>>> 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 define

[Pulp-dev] Pulp 3 release quality

[Dennis Kliban]

I've started putting together a Continuous Delivery of Pulp 3 page[0] on
our wiki.

This page outlines a plan for how we can ensure and prove the quality of
Pulp 3 releases by relying on pulp-smash tests and unit tests.

This plan enables anyone to improve the quality of Pulp 3 releases through
contributions to pulp-smash and unit tests.

Please take a look at the plan and provide feedback on this thread or feel
free to make edits directly on the page.

[0] https://pulp.plan.io/projects/pulp/wiki/Continuous_Delivery_of_Pulp_3

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

Re: [Pulp-dev] Importer Name

[Austin Macdonald]

Would anyone mind grooming these? Also, last change to shut it down :)
https://pulp.plan.io/issues/3488
https://pulp.plan.io/issues/3492



On Fri, Mar 16, 2018 at 9:27 AM, Austin Macdonald 
wrote:

> Ive created tasks to do this work.
>
> Rename:
> https://pulp.plan.io/issues/3488
>
> Move sync_mode, remove download_policy
> https://pulp.plan.io/issues/3492
>
> Each of these has corresponding plugin tasks, which are related to them.
>
> On Thu, Mar 15, 2018 at 4:16 PM, David Davis 
> wrote:
>
>> 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



 __

Re: [Pulp-dev] Pulp 3 Unit Test Plan Proposal

[Austin Macdonald]

-1 For a blocking check, -1 for attempting 100% coverage.

There is a *lot* of code in Pulp 3 that simply involves inheriting from
parents classes and defining attributes. If we add a ViewSet for instance,
there is nothing to test other than "asserting that we did what we did". I
have written lots of tests like that. IMO, they add no value and are time
consuming to write. Also, they are time consuming to maintain because every
change must also change the unit tests. This type of test almost never
catches a real problem.

A soft check would be a useful reminder to the contributor and the reviewer
to add tests where they make sense. + 1 soft check

Plugins: Each plugin team should determine their own unit test policy.


On Fri, Mar 23, 2018 at 1:26 PM, David Davis  wrote:

> We haven't had a unit test policy in Pulp 3, and the community and core
> committers would all like one. The general desire we've heard so far is to
> change course and encourage developers to add unit tests to their changes
> to Pulp 3.
>
> The policy we're suggesting is to add a coveralls[0] check for Pull
> Requests against the pulpcore 3.0-dev branch that shows the overall
> coverage percentage, e.g. 12.89%. This check would pass if and only if
> coverage increases or remains the same with the PR. We think this will
> eventually get us on the path to 100% unit test coverage.
>
> We propose the coveralls check be a soft check that allow for merging if
> it fails. We would document the policy and try to adhere to it even though
> it wouldn't formally block merging. At a future point when pulp3 (maybe the
> GA?) we could make this a hard check.
>
> Benefits:
> - It's easy, simple, and automatic
> - It's pretty objective and there's little room to argue with a number.
> - Helps us raise our unit test coverage gradually over time
>
> Downsides:
> - Could discourage community contributions
> - It can be a bit strict and unforgiving at times (especially if there's a
> hard check)
> - It only provides a guarantee around quantity of unit testing and not
> quality
>
>
> *Q: What about the existing functionality? Do we need to write unit tests
> for it?*
>
> We're not sure about this. We'd like community feedback. Is anyone
> interested in writing backfill unit tests? If so, then maybe we should.
>
> *Q: Will this also affect Pulp 2?*
>
> We're not planning on it but if we like this enough, we can look at adding
> it to Pulp 2.
>
> *Q: Will this affect plugins?*
>
> We want to start out with just pulpcore now and see how we like it. Then
> we'll look at adding it to pulp_file. In the future, we can also look at
> ways to make it easy for plugins to set this up.
>
> *Q: Do I no longer need to write pulp-smash test plan issues in Github for
> Pulp 3 features?*
>
> No, you should still do that.
>
> [0] https://coveralls.io/
>
> ___
> 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]

To make sure this was feasable, I've created proof of concept PRs for
pulpcore and pulp_file. All of the proposed changes are proofed, but not
all work is done. For example, sync is implemented, but not publish.

   - https://github.com/pulp/pulp/pull/3394
   - https://github.com/pulp/pulp_file/pull/61

I am very pleased with how it turned out, and I think it will make plugin
writing even easier. I documented the design on a redmine issue. I
encourage feedback/discussion on the issue.

https://pulp.plan.io/issues/3522

On Tue, Mar 20, 2018 at 7:46 AM, Milan Kovacik  wrote:

> On Fri, Mar 16, 2018 at 4:55 PM, Milan Kovacik 
> wrote:
> >
> >
> >
> > On Thu, Mar 15, 2018 at 9:21 PM, Austin Macdonald 
> wrote:
> >>
> >> 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.
> >
> >
> > +1 to generic Pulp concepts/objects staying outside of a plug-in
> namespace/path
> >
> >>
> >>
> >> 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.
> >
> >
> > - 1 as this might imply mixing  and  actions
> while all the time, asynchronous actions, such as the sync call, always
> create a task object; the user would be creating the task objects at one
> endpoint but deleting, filtering, tracking those at another.
> >
> >>
> >>
> >> "Task Object Based"
> >> POST v3/tasks/file/syncs/
> >> Note that "syncs" is plural. This is a POST that creates a file-sync
> task object,.
>
> Btw an interesting consequence of tasks not being objects in a file
> importer and publisher are these two issues:
>  - The parameters in the API schema for the sync and publish endpoints
> are incorrect [1]
>  - Not able to access documentation endpoint [2]
>
> In the former issue, the DRF isn't able to automatically figure out
> schema for e.g the `sync` endpoint of the file plug-in importer.
> The reason for it is even though the `sync` verb is attached to an
> importer object, the parameters passed in aren't supposed to be
> importer details so they shouldn't use the importer serializer to get
> e.g auto-documented.
> Moreover, the result of a call to this endpoint is supposed to be a
> task (json object), schema and serialization of which has to be
> repeated for the `sync` endpoint to some extent.
> Last but not least, it isn't clear whether the `sync` verb should
> belong to an importer or a repo, or something else as the call
> "responsibility" is spread somewhat between both and none.
>
> The latter issue is a consequence of the lack of sup

[Pulp-dev] Pulp 3 Unit Test Plan Proposal

[David Davis]

We haven't had a unit test policy in Pulp 3, and the community and core
committers would all like one. The general desire we've heard so far is to
change course and encourage developers to add unit tests to their changes
to Pulp 3.

The policy we're suggesting is to add a coveralls[0] check for Pull
Requests against the pulpcore 3.0-dev branch that shows the overall
coverage percentage, e.g. 12.89%. This check would pass if and only if
coverage increases or remains the same with the PR. We think this will
eventually get us on the path to 100% unit test coverage.

We propose the coveralls check be a soft check that allow for merging if it
fails. We would document the policy and try to adhere to it even though it
wouldn't formally block merging. At a future point when pulp3 (maybe the
GA?) we could make this a hard check.

Benefits:
- It's easy, simple, and automatic
- It's pretty objective and there's little room to argue with a number.
- Helps us raise our unit test coverage gradually over time

Downsides:
- Could discourage community contributions
- It can be a bit strict and unforgiving at times (especially if there's a
hard check)
- It only provides a guarantee around quantity of unit testing and not
quality


*Q: What about the existing functionality? Do we need to write unit tests
for it?*

We're not sure about this. We'd like community feedback. Is anyone
interested in writing backfill unit tests? If so, then maybe we should.

*Q: Will this also affect Pulp 2?*

We're not planning on it but if we like this enough, we can look at adding
it to Pulp 2.

*Q: Will this affect plugins?*

We want to start out with just pulpcore now and see how we like it. Then
we'll look at adding it to pulp_file. In the future, we can also look at
ways to make it easy for plugins to set this up.

*Q: Do I no longer need to write pulp-smash test plan issues in Github for
Pulp 3 features?*

No, you should still do that.

[0] https://coveralls.io/
___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev