Re: [Pulp-dev] signing service interface

[Dennis Kliban]

On Tue, May 5, 2020 at 3:39 AM Quirin Pamp  wrote:

> Could you explain the reasoning for a 'public.key' file?
>

The public.key file is the file that a yum/dnf client can use to verify
that the metadata in an RPM repository was signed by the signing service
associated with the repository. The name of the file can be anything - the
path to it needs to be specified in the repository config on the client.


> In the case of the AptReleaseSigningService we built for pulp_deb we saw
> zero need for this file and consequently did not add it in.
>
> (It would not be hard to add it just to satisfy the interface, it just
> would not serve any useful purpose.)
>

It is definitely up to each plugin if it wants to provide the public key as
part of the publication. It is currently impossible for the plugin to know
exactly what files are produced by the signing service. This is where I
would like to see an improvement in the API. Pupcore should provide a
guarantee to plugin writers that a signing service configured by an
administrator is functioning in a predictable way. One possible way to do
that is with an interface that lets a plugin writer inspect a signing
service without executing it. Though I am looking for other ideas in this
area.


>
> Since we are on the topic of signing services, a colleague has had a PR
> relating to them just sitting their waiting for a review for quite a while
> now ;-):
> https://github.com/pulp/pulpcore/pull/659
>
>
> It would be great if you (or somebody else) could have a look at it. I
> believe it is mostly ready, but probably needs the eyes of an experienced
> pulp core developer to look over it and suggest style consistency changes
> and where and whether to add documentation. ;-)
>

I'll take a look at this PR.



>
> Quirin
> --
> *From:* pulp-dev-boun...@redhat.com  on
> behalf of Dennis Kliban 
> *Sent:* 04 May 2020 22:50:54
> *To:* Pulp-dev 
> *Subject:* [Pulp-dev] signing service interface
>
> The Plugin API of Signing Services in Pulp 3 is too vague. I came to this
> conclusion while working with @lieter on an RPM plugin feature that allows
> users to download a repo config file from a distribution[0]. As a result,
> we decided to document that the signing service needs to produce a public
> key file named 'public.key'[1].
>
> We should revisit the design of the signing service API to ensure that we
> enforce this naming convention.
>
> [0] https://pulp.plan.io/issues/5356
> [1]
> https://github.com/pulp/pulp_rpm/pull/1687/files#diff-c91893c1f4e7afe73e414d1a76162463R30
>
___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev

Re: [Pulp-dev] Installer project

[Ina Panova]

+1 to the plan.

On Tue, 5 May 2020, 19:33 Fabricio Aguiar, 
wrote:

> Yes, it makes sense
>
> Best regards,
> Fabricio Aguiar
> Software Engineer, Pulp Project
> Red Hat Brazil - Latam 
> +55 11 999652368
>
>
> On Tue, May 5, 2020 at 12:24 PM David Davis  wrote:
>
>> Cool. If we go down this path, would this plan make sense?
>>
>> 1. Create an installer project in redmine
>> 2. Move over all issues (opened and closed) to this project that are
>> tagged "Pulp 3 installer"
>> 3. Remove the "Pulp 3 installer" tag
>>
>> David
>>
>>
>> On Tue, May 5, 2020 at 11:10 AM Fabricio Aguiar <
>> fabricio.agu...@redhat.com> wrote:
>>
>>> +1 for creating a new project,
>>> Installer query: https://pulp.plan.io/projects/pulp/issues?query_id=154
>>>
>>> Best regards,
>>> Fabricio Aguiar
>>> Software Engineer, Pulp Project
>>> Red Hat Brazil - Latam 
>>> +55 11 999652368
>>>
>>>
>>> On Tue, May 5, 2020 at 11:48 AM David Davis 
>>> wrote:
>>>
 During triage today, a majority of the issues that came up were for the
 installer but only a handful of people could really speak to these issues.
 I proposed that we skip these issues during triage and let the installer
 team triage them.

 In order to do so, we'd have to create a separate project in redmine.
 My initial feeling is that this makes sense since the installer work has
 really grown into its own project and is no longer in the purview of
 pulpcore.

 Thoughts?

 I'll put a deadline on this discussion for May 8 unless we don't reach
 a consensus by then.

 David
 ___
 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] Fwd: Status of pulp-python

[Robin Chan]

Hello Christoph,

The Python plugin isn't abandoned, but we have not been able to maintain it
due to other higher priority issues for other plugins. Our best case
scenario would be to find a user or users who use the Python plugin and are
interested in helping maintain this plugin.  We would definitely be able to
support those efforts including PR reviews and help with coming up to speed
on how to contribute.

I'd suggest a first step of working with Daniel (Python plugin maintainer)
to come up with a gap analysis on what you would need from the Python
plugin for your use cases. We could commit to PR reviews on bug fixes but
no feature development in the near future (this next calendar quarter
already planned out commitments.) To be realistic, I would recommend
someone from your organization know how to send PR for any future
discovered critical bugs to make this a feasible option. I'm anticipating
together you may discover some additional efforts like CI/test fixes or
releasing a new version that may be needed as well since it's probably a
bit behind on that. Those aren't off the table but I'd support Daniel
spending some time to figure out where we are with this. Does that sound
like something you would be interested in?

-Robin

Robin Chan

She/Her/Hers

Satellite Software Engineering Manager - Pulp

Red Hat 

IRC: rchan




On Tue, May 5, 2020 at 4:18 AM Christoph Höger <
christoph.hoe...@celeraone.com> wrote:

> Dear all,
>
> I am currently in the process of investigating the usage of pulp for our
> company's repository management and think I can fulfill all the
> requirements except for a pypi mirror. While this is exactly what
> pulp-python seems to provides it has a showstopper bug:
>
> https://pulp.plan.io/issues/5452
>
> which appears to be the same as:
>
> https://pulp.plan.io/issues/5387
>
> I assume that I could get one of our python guys working on the matter, if
> I can refer them to a) someone to talk to about the project and b) get some
> assurance that this plugin is not dead already.
>
> So do you know what the status of pulp-python is? Is it just not very high
> on the priorities or is it already more or less abandoned? I am asking
> this, because pulpcore and some other plugins seem to have a relatively
> fast pace. If pulp-python is abandoned we might just go on with deb/rpm
> support and use something else to mirror pypi.
>
> thank you very much,
>
> Christoph
>
> --
> Christoph Höger
>
> Email: christoph.hoe...@celeraone.com 
> Web: www.celeraone.com
> ___
> 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] Installer project

[Fabricio Aguiar]

Yes, it makes sense

Best regards,
Fabricio Aguiar
Software Engineer, Pulp Project
Red Hat Brazil - Latam 
+55 11 999652368


On Tue, May 5, 2020 at 12:24 PM David Davis  wrote:

> Cool. If we go down this path, would this plan make sense?
>
> 1. Create an installer project in redmine
> 2. Move over all issues (opened and closed) to this project that are
> tagged "Pulp 3 installer"
> 3. Remove the "Pulp 3 installer" tag
>
> David
>
>
> On Tue, May 5, 2020 at 11:10 AM Fabricio Aguiar <
> fabricio.agu...@redhat.com> wrote:
>
>> +1 for creating a new project,
>> Installer query: https://pulp.plan.io/projects/pulp/issues?query_id=154
>>
>> Best regards,
>> Fabricio Aguiar
>> Software Engineer, Pulp Project
>> Red Hat Brazil - Latam 
>> +55 11 999652368
>>
>>
>> On Tue, May 5, 2020 at 11:48 AM David Davis 
>> wrote:
>>
>>> During triage today, a majority of the issues that came up were for the
>>> installer but only a handful of people could really speak to these issues.
>>> I proposed that we skip these issues during triage and let the installer
>>> team triage them.
>>>
>>> In order to do so, we'd have to create a separate project in redmine. My
>>> initial feeling is that this makes sense since the installer work has
>>> really grown into its own project and is no longer in the purview of
>>> pulpcore.
>>>
>>> Thoughts?
>>>
>>> I'll put a deadline on this discussion for May 8 unless we don't reach a
>>> consensus by then.
>>>
>>> David
>>> ___
>>> 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] Migration plugin meeting notes

[Tatiana Tereshchenko]

   -

   In progress
   -

  [ipanova] Remotes tracking
  -

 https://github.com/pulp/pulp-2to3-migration/pull/145/
 -

  [dalley] Progress report planning
  -

 Discussion happened on https://pulp.plan.io/issues/6590
 -

 Dalley to file a new issue about detailed progress reporting and
 start discussion on pulp-dev
 -

  [ttereshc] started on errata issue https://pulp.plan.io/issues/6531
  -

   Priorities
   -

  One migration at a time https://pulp.plan.io/issues/6639
  -

 Needs to be solved in the pulpcore 3.3.1 timeline
 -

  simple/complex plan https://pulp.plan.io/issues/6516
  -

  Publication tracking https://pulp.plan.io/issues/6376



Open PRs https://github.com/pulp/pulp-2to3-migration/pulls
Un-triaged bugs https://pulp.plan.io/projects/migration/issues?query_id=30
___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev

Re: [Pulp-dev] Installer project

[David Davis]

Cool. If we go down this path, would this plan make sense?

1. Create an installer project in redmine
2. Move over all issues (opened and closed) to this project that are tagged
"Pulp 3 installer"
3. Remove the "Pulp 3 installer" tag

David


On Tue, May 5, 2020 at 11:10 AM Fabricio Aguiar 
wrote:

> +1 for creating a new project,
> Installer query: https://pulp.plan.io/projects/pulp/issues?query_id=154
>
> Best regards,
> Fabricio Aguiar
> Software Engineer, Pulp Project
> Red Hat Brazil - Latam 
> +55 11 999652368
>
>
> On Tue, May 5, 2020 at 11:48 AM David Davis  wrote:
>
>> During triage today, a majority of the issues that came up were for the
>> installer but only a handful of people could really speak to these issues.
>> I proposed that we skip these issues during triage and let the installer
>> team triage them.
>>
>> In order to do so, we'd have to create a separate project in redmine. My
>> initial feeling is that this makes sense since the installer work has
>> really grown into its own project and is no longer in the purview of
>> pulpcore.
>>
>> Thoughts?
>>
>> I'll put a deadline on this discussion for May 8 unless we don't reach a
>> consensus by then.
>>
>> David
>> ___
>> 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] Installer project

[Fabricio Aguiar]

+1 for creating a new project,
Installer query: https://pulp.plan.io/projects/pulp/issues?query_id=154

Best regards,
Fabricio Aguiar
Software Engineer, Pulp Project
Red Hat Brazil - Latam 
+55 11 999652368


On Tue, May 5, 2020 at 11:48 AM David Davis  wrote:

> During triage today, a majority of the issues that came up were for the
> installer but only a handful of people could really speak to these issues.
> I proposed that we skip these issues during triage and let the installer
> team triage them.
>
> In order to do so, we'd have to create a separate project in redmine. My
> initial feeling is that this makes sense since the installer work has
> really grown into its own project and is no longer in the purview of
> pulpcore.
>
> Thoughts?
>
> I'll put a deadline on this discussion for May 8 unless we don't reach a
> consensus by then.
>
> David
> ___
> 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] Installer project

[David Davis]

During triage today, a majority of the issues that came up were for the
installer but only a handful of people could really speak to these issues.
I proposed that we skip these issues during triage and let the installer
team triage them.

In order to do so, we'd have to create a separate project in redmine. My
initial feeling is that this makes sense since the installer work has
really grown into its own project and is no longer in the purview of
pulpcore.

Thoughts?

I'll put a deadline on this discussion for May 8 unless we don't reach a
consensus by then.

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

Re: [Pulp-dev] Fwd: Moving to travis-ci.com

[David Davis]

Strangely, it looks like both travis-ci.com and travis-ci.org are building
pulp_gem so I disabled the latter.

David


On Tue, May 5, 2020 at 10:16 AM Matthias Dellweg 
wrote:

>
>
> -- Forwarded message -
> From: Matthias Dellweg 
> Date: Tue, May 5, 2020 at 2:17 PM
> Subject: Re: [Pulp-dev] Moving to travis-ci.com
> To: Tatiana Tereshchenko 
>
>
> Thank you!
> +1 for pulp_gem
>
> On Tue, May 5, 2020 at 2:15 PM Tatiana Tereshchenko 
> wrote:
>
>> Thank you! +1 for pulp_rpm to migrate.
>>
>> Tanya
>>
>> On Tue, May 5, 2020 at 1:38 PM David Davis  wrote:
>>
>>> I migrated over pulp_ansible, pulp-smash, and pulp-ci. I think at this
>>> point, these are the only pulp 3 repos still on travis-ci.org:
>>>
>>> - pulp_rpm
>>> - pulp_python
>>> - pulp_gem
>>>
>>> If any of the plugins want me to migrate these over, please let me know.
>>>
>>> David
>>>
>>>
>>> On Mon, May 4, 2020 at 7:12 AM Ina Panova  wrote:
>>>
 +1 to move pulp3 projects.
 Thank you for taking care of this.


 
 Regards,

 Ina Panova
 Senior 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 Fri, May 1, 2020 at 9:22 PM Brian Bouterse 
 wrote:

> Thank you for porting these! I'm +1 to moving all Pulp3 projects with
> an ack from each plugin team first.
>
> I can ack for pulp_ansible, if it's possible to move that one please.
> Let me know how I can help also.
>
> On Wed, Apr 29, 2020 at 6:43 AM David Davis 
> wrote:
>
>> Out of curiosity this morning I tried migrating pulp_file over to
>> travis-ci this morning and it worked. So then I went back and tried
>> pulp-certguard and that worked as well. So now both projects are on
>> travis-ci.com.
>>
>> I think these are the main projects still on travis-ci.org:
>> - pulp_ansible
>> - pulp_rpm
>> - pulp
>> - pulp_python
>> - pulp_gem
>> - pulp-smash
>> - pulp-ci
>> - Pulp-2-Tests
>> - pulp_ostree
>> - crane
>>
>> Should we move these projects over as well? Maybe just the Pulp 3
>> ones? I'd also like confirmation from plugin teams though before we move
>> their repos over.
>>
>> David
>>
>>
>> On Thu, Apr 23, 2020 at 11:01 AM Daniel Alley 
>> wrote:
>>
>>> I kid, but it is a funny situation
>>>
>>> On Thu, Apr 23, 2020 at 10:01 AM David Davis 
>>> wrote:
>>>
 LOL.

 To answer your question though, we're kind of in a holding pattern
 right now. There are some missing features like sharing jobs between
 workflows and restarting jobs within workflows that we're hoping Github
 Actions adds. Maybe we can revisit though at our next CI meeting.

 David


 On Thu, Apr 23, 2020 at 9:46 AM Daniel Alley 
 wrote:

> travis-ci.org is broken
>>
> migrating away from travis-ci.org is also broken
>>
>
> So, uh, when will github actions be ready xD
>
> On Thu, Apr 23, 2020 at 8:40 AM David Davis 
> wrote:
>
>> I wrote to Travis support yesterday and they responded (below). I
>> tried again this morning and it's still broken. I'll wait a few more 
>> days
>> unless anyone objects.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> *Thank you for reaching out! We are sorry about the issue that
>> you are having.We are currently aware of a bug related to migrating
>> repositories from travis-ci.org  to 
>> travis-ci.com
>>  and our Engineering Team is working on this 
>> issue to
>> be solved as soon as possible.Until the fix is deployed, we would 
>> kindly
>> suggest you build your projects on travis-ci.org
>> .Thank you for your patience and once again we 
>> are
>> extremely sorry about the issue.*
>>
>> David
>>
>>
>> On Thu, Apr 23, 2020 at 8:34 AM Brian Bouterse <
>> bmbou...@redhat.com> wrote:
>>
>>>
>>>
>>> On Wed, Apr 22, 2020 at 3:48 PM David Davis <
>>> davidda...@redhat.com> wrote:
>>>
 Ok, I agree. I tried to migrate certguard to travis-ci.com and
 hit a 500 error. Looks like we're not alone both in status updates 
 not
 being reported from travis-ci.org and having problems trying
 to migrate:


 https://travis-ci.community/t/github-status-not-posted-on-commits-on-repositories-using-legacy-service-integration/7798/16

 I'll wait a day for 

[Pulp-dev] Fwd: Moving to travis-ci.com

[Matthias Dellweg]

-- Forwarded message -
From: Matthias Dellweg 
Date: Tue, May 5, 2020 at 2:17 PM
Subject: Re: [Pulp-dev] Moving to travis-ci.com
To: Tatiana Tereshchenko 


Thank you!
+1 for pulp_gem

On Tue, May 5, 2020 at 2:15 PM Tatiana Tereshchenko 
wrote:

> Thank you! +1 for pulp_rpm to migrate.
>
> Tanya
>
> On Tue, May 5, 2020 at 1:38 PM David Davis  wrote:
>
>> I migrated over pulp_ansible, pulp-smash, and pulp-ci. I think at this
>> point, these are the only pulp 3 repos still on travis-ci.org:
>>
>> - pulp_rpm
>> - pulp_python
>> - pulp_gem
>>
>> If any of the plugins want me to migrate these over, please let me know.
>>
>> David
>>
>>
>> On Mon, May 4, 2020 at 7:12 AM Ina Panova  wrote:
>>
>>> +1 to move pulp3 projects.
>>> Thank you for taking care of this.
>>>
>>>
>>> 
>>> Regards,
>>>
>>> Ina Panova
>>> Senior 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 Fri, May 1, 2020 at 9:22 PM Brian Bouterse 
>>> wrote:
>>>
 Thank you for porting these! I'm +1 to moving all Pulp3 projects with
 an ack from each plugin team first.

 I can ack for pulp_ansible, if it's possible to move that one please.
 Let me know how I can help also.

 On Wed, Apr 29, 2020 at 6:43 AM David Davis 
 wrote:

> Out of curiosity this morning I tried migrating pulp_file over to
> travis-ci this morning and it worked. So then I went back and tried
> pulp-certguard and that worked as well. So now both projects are on
> travis-ci.com.
>
> I think these are the main projects still on travis-ci.org:
> - pulp_ansible
> - pulp_rpm
> - pulp
> - pulp_python
> - pulp_gem
> - pulp-smash
> - pulp-ci
> - Pulp-2-Tests
> - pulp_ostree
> - crane
>
> Should we move these projects over as well? Maybe just the Pulp 3
> ones? I'd also like confirmation from plugin teams though before we move
> their repos over.
>
> David
>
>
> On Thu, Apr 23, 2020 at 11:01 AM Daniel Alley 
> wrote:
>
>> I kid, but it is a funny situation
>>
>> On Thu, Apr 23, 2020 at 10:01 AM David Davis 
>> wrote:
>>
>>> LOL.
>>>
>>> To answer your question though, we're kind of in a holding pattern
>>> right now. There are some missing features like sharing jobs between
>>> workflows and restarting jobs within workflows that we're hoping Github
>>> Actions adds. Maybe we can revisit though at our next CI meeting.
>>>
>>> David
>>>
>>>
>>> On Thu, Apr 23, 2020 at 9:46 AM Daniel Alley 
>>> wrote:
>>>
 travis-ci.org is broken
>
 migrating away from travis-ci.org is also broken
>

 So, uh, when will github actions be ready xD

 On Thu, Apr 23, 2020 at 8:40 AM David Davis 
 wrote:

> I wrote to Travis support yesterday and they responded (below). I
> tried again this morning and it's still broken. I'll wait a few more 
> days
> unless anyone objects.
>
>
>
>
>
>
>
>
>
> *Thank you for reaching out! We are sorry about the issue that you
> are having.We are currently aware of a bug related to migrating
> repositories from travis-ci.org  to 
> travis-ci.com
>  and our Engineering Team is working on this 
> issue to
> be solved as soon as possible.Until the fix is deployed, we would 
> kindly
> suggest you build your projects on travis-ci.org
> .Thank you for your patience and once again we 
> are
> extremely sorry about the issue.*
>
> David
>
>
> On Thu, Apr 23, 2020 at 8:34 AM Brian Bouterse <
> bmbou...@redhat.com> wrote:
>
>>
>>
>> On Wed, Apr 22, 2020 at 3:48 PM David Davis <
>> davidda...@redhat.com> wrote:
>>
>>> Ok, I agree. I tried to migrate certguard to travis-ci.com and
>>> hit a 500 error. Looks like we're not alone both in status updates 
>>> not
>>> being reported from travis-ci.org and having problems trying to
>>> migrate:
>>>
>>>
>>> https://travis-ci.community/t/github-status-not-posted-on-commits-on-repositories-using-legacy-service-integration/7798/16
>>>
>>> I'll wait a day for Travis support to respond but I think we
>>> could also just enable the repos and start from scratch in
>>> travis-ci.com. I think we'd lose past build information and
>>> settings though if we don't migrate.
>>>
>> This also sounds good to me. If you want to tag-team via irc or
>> video we can do 

Re: [Pulp-dev] New pulpcore release (3.3.1?)

[Tatiana Tereshchenko]

+1 for 3.3.1

Could those be included?
1. Adding TaskGroup to the plugin API
https://github.com/pulp/pulpcore/pull/677
2. Adding all_task_dispatched field to indicate that no more tasks will
spawn https://github.com/pulp/pulpcore/pull/682

They may sound like features/improvements however, without both, task
groups are close to unusable.
Katello integrates with pulpcore 3.3 and migration plugin which uses task
groups.
Migration plugin can workaround the first problem by importing directly
from the pulpcore.
Without #2, there is no way to know whether all tasks have been dispatched
or not, it means no way to know the overall state of the migration.

To my knowledge, task groups are used by import/export (which is in tech
preview) and by the migration plugin. So those PRs seem to me like a
low-risk change.

Any thoughts?

Thanks,
Tanya

On Mon, May 4, 2020 at 8:41 PM David Davis  wrote:

> I think Katello would like a few of the bug fixes from the past couple
> weeks. Would a 3.3.1 release make sense? Would anyone have time this week
> to work on it?
>
> David
> ___
> 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] fedorapeople.org fixtures

[David Davis]

Awesome, thanks for the update. 15 minutes is more than ok as we've had
gaps of days (weeks?) between updates to fedorapeople.org.

David


On Tue, May 5, 2020 at 9:45 AM Brian Bouterse  wrote:

> The osci.io team is going to try to stand up fixtures.pulproject.org by
> May 15th. I'll post updates here also as I continue to correspond with them.
>
> They will likely use openshift for the hosting which checks for changes
> every 15 minutes, so fixtures.pulproject.org would be a max of 15 minutes
> behind the git repo. I think this is ok since CI and developers both would
> be using locally hosted fixtures and these are more for convenience. If
> anyone feels differently please let us know.
>
> I put some updates on the ticket also https://pulp.plan.io/issues/6638
>
> Feedback is welcome.
>
>
> On Mon, May 4, 2020 at 12:25 PM Brian Bouterse 
> wrote:
>
>> I filed this infrastructure ticket https://pulp.plan.io/issues/6638 for
>> fixtures.pulpproject.org and emailed osci.io contacts asking if they are
>> willing to make https://fixtures.pulpproject.org for us. I'll share back
>> to the thread with what they say.
>>
>> Since we're on the topic, I want to share my perspective on our docs
>> examples. When possible, I imagined our docs would try to use "in the wild"
>> examples, e.g. for RPM to use centos syncing instead of from our fixtures.
>> My thinking is it's a more real-world example and users would have an
>> easier time recognizing it as valuable. That may not always be possible
>> though, e.g. pulp_file may not have an "in the wild repo". Just an opinion
>> I wanted to share, feel free to disregard/disagree.
>>
>> On Mon, May 4, 2020 at 7:06 AM Ina Panova  wrote:
>>
>>> I am also in favour of hosting fixtures.
>>> Eventually we'd also need to update our tests and workflows in the docs
>>> that point to the fedorapeople.orf fixtures.
>>>
>>>
>>> 
>>> Regards,
>>>
>>> Ina Panova
>>> Senior 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 Mon, May 4, 2020 at 1:03 PM David Davis 
>>> wrote:
>>>
 I agree with @ttereshc that having fixtures hosted somewhere provides
 value.

 @bmbouter, your proposal sounds like a good idea. Can you see if it's
 feasible this week?

 David


 On Fri, May 1, 2020 at 3:17 PM Brian Bouterse 
 wrote:

> I'm +1 on stopping the use of fixtures on fedora people (see some
> reasoning below). I'd like to offer to contact the folks who host other
> Pulp infrastructure ( https://osci.io/ ) to inquire if they could
> standup an auto-refreshing container to serve fixtures. This would pull 
> the
> container every time it changes, checking every few min, from wherever we
> publish it to. Maybe we use https://fixtures.pulpproject.org/   What
> do you think?
>
> Here's some reasoning about why I believe Pup should discontinue its
> fedorapeople use for fixtures going forward:
>
> * The fedorapeople servers are configured with a Content-Type that
> incorrectly advertises gzip content as already compressed to cause clients
> to "auto-unzip". While this is nice for fedorapeople users, it's an
> issue for Pulp testing because the expected hashes don't match when it is
> expecting the content as-is, and yet the webserver instructs the client to
> uncompress it first. They won't change the default so we have to open
> tickets to have the "pulp portion of fedorapeople's configs" fixed to
> advertise the content like a normal webserver should. This is further
> complicated by ...
>
> * Very few people have access to it because it's the place where the
> Pulp2 production bits are hosted. So we probably can't open it up to a
> broader group. This means that we're architecturally we can't have more
> people involved. To me this is a concern.
>
>
> On Thu, Apr 30, 2020 at 10:01 AM Mike DePaulo 
> wrote:
>
>> quba42 does have a point: We can publish the fixtures image to quay
>> (or other registries), but then host it locally like the `pfixtures`
>> command does.
>>
>> Another option (technology-wise) is to upload to an S3 bucket or
>> other object storage. It would cost a small amount of $ per month.
>>
>> -Mike
>>
>> On Wed, Apr 29, 2020 at 10:30 AM Tatiana Tereshchenko <
>> ttere...@redhat.com> wrote:
>>
>>> I personally prefer to keep fixtures published somewhere,
>>> fedorapeople or not, doesn't matter.
>>> It is convenient to refer to in situations which are not related to
>>> feature development or functional testing:
>>>  - when one files a redmine issue and provides steps to reproduce
>>>  - when one works with, say, Katello, or any other related project
>>> and needs to try/test something quickly
>>>  - when one tries to help some 

Re: [Pulp-dev] fedorapeople.org fixtures

[Brian Bouterse]

The osci.io team is going to try to stand up fixtures.pulproject.org by May
15th. I'll post updates here also as I continue to correspond with them.

They will likely use openshift for the hosting which checks for changes
every 15 minutes, so fixtures.pulproject.org would be a max of 15 minutes
behind the git repo. I think this is ok since CI and developers both would
be using locally hosted fixtures and these are more for convenience. If
anyone feels differently please let us know.

I put some updates on the ticket also https://pulp.plan.io/issues/6638

Feedback is welcome.


On Mon, May 4, 2020 at 12:25 PM Brian Bouterse  wrote:

> I filed this infrastructure ticket https://pulp.plan.io/issues/6638 for
> fixtures.pulpproject.org and emailed osci.io contacts asking if they are
> willing to make https://fixtures.pulpproject.org for us. I'll share back
> to the thread with what they say.
>
> Since we're on the topic, I want to share my perspective on our docs
> examples. When possible, I imagined our docs would try to use "in the wild"
> examples, e.g. for RPM to use centos syncing instead of from our fixtures.
> My thinking is it's a more real-world example and users would have an
> easier time recognizing it as valuable. That may not always be possible
> though, e.g. pulp_file may not have an "in the wild repo". Just an opinion
> I wanted to share, feel free to disregard/disagree.
>
> On Mon, May 4, 2020 at 7:06 AM Ina Panova  wrote:
>
>> I am also in favour of hosting fixtures.
>> Eventually we'd also need to update our tests and workflows in the docs
>> that point to the fedorapeople.orf fixtures.
>>
>>
>> 
>> Regards,
>>
>> Ina Panova
>> Senior 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 Mon, May 4, 2020 at 1:03 PM David Davis  wrote:
>>
>>> I agree with @ttereshc that having fixtures hosted somewhere provides
>>> value.
>>>
>>> @bmbouter, your proposal sounds like a good idea. Can you see if it's
>>> feasible this week?
>>>
>>> David
>>>
>>>
>>> On Fri, May 1, 2020 at 3:17 PM Brian Bouterse 
>>> wrote:
>>>
 I'm +1 on stopping the use of fixtures on fedora people (see some
 reasoning below). I'd like to offer to contact the folks who host other
 Pulp infrastructure ( https://osci.io/ ) to inquire if they could
 standup an auto-refreshing container to serve fixtures. This would pull the
 container every time it changes, checking every few min, from wherever we
 publish it to. Maybe we use https://fixtures.pulpproject.org/   What
 do you think?

 Here's some reasoning about why I believe Pup should discontinue its
 fedorapeople use for fixtures going forward:

 * The fedorapeople servers are configured with a Content-Type that
 incorrectly advertises gzip content as already compressed to cause clients
 to "auto-unzip". While this is nice for fedorapeople users, it's an
 issue for Pulp testing because the expected hashes don't match when it is
 expecting the content as-is, and yet the webserver instructs the client to
 uncompress it first. They won't change the default so we have to open
 tickets to have the "pulp portion of fedorapeople's configs" fixed to
 advertise the content like a normal webserver should. This is further
 complicated by ...

 * Very few people have access to it because it's the place where the
 Pulp2 production bits are hosted. So we probably can't open it up to a
 broader group. This means that we're architecturally we can't have more
 people involved. To me this is a concern.


 On Thu, Apr 30, 2020 at 10:01 AM Mike DePaulo 
 wrote:

> quba42 does have a point: We can publish the fixtures image to quay
> (or other registries), but then host it locally like the `pfixtures`
> command does.
>
> Another option (technology-wise) is to upload to an S3 bucket or other
> object storage. It would cost a small amount of $ per month.
>
> -Mike
>
> On Wed, Apr 29, 2020 at 10:30 AM Tatiana Tereshchenko <
> ttere...@redhat.com> wrote:
>
>> I personally prefer to keep fixtures published somewhere,
>> fedorapeople or not, doesn't matter.
>> It is convenient to refer to in situations which are not related to
>> feature development or functional testing:
>>  - when one files a redmine issue and provides steps to reproduce
>>  - when one works with, say, Katello, or any other related project
>> and needs to try/test something quickly
>>  - when one tries to help some user remotely and ask to sync this or
>> that.
>>
>> It's not a strong reason, it's just a matter of convenience, in my
>> opinion.
>>
>> Tanya
>>
>>
>> On Wed, Apr 29, 2020 at 8:31 AM Quirin Pamp  wrote:
>>
>>> I have grown used to always running the fixtures container locally

Re: [Pulp-dev] Moving to travis-ci.com

[David Davis]

Done. I think you'll have to update the branch protection and status check
requirements once it has some builds on travis-ci.com.

Also, I noticed that the cherry pick job is failing for pulp_rpm:

https://travis-ci.com/github/pulp/pulp_rpm/builds/163940787

David


On Tue, May 5, 2020 at 8:14 AM Tatiana Tereshchenko 
wrote:

> Thank you! +1 for pulp_rpm to migrate.
>
> Tanya
>
> On Tue, May 5, 2020 at 1:38 PM David Davis  wrote:
>
>> I migrated over pulp_ansible, pulp-smash, and pulp-ci. I think at this
>> point, these are the only pulp 3 repos still on travis-ci.org:
>>
>> - pulp_rpm
>> - pulp_python
>> - pulp_gem
>>
>> If any of the plugins want me to migrate these over, please let me know.
>>
>> David
>>
>>
>> On Mon, May 4, 2020 at 7:12 AM Ina Panova  wrote:
>>
>>> +1 to move pulp3 projects.
>>> Thank you for taking care of this.
>>>
>>>
>>> 
>>> Regards,
>>>
>>> Ina Panova
>>> Senior 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 Fri, May 1, 2020 at 9:22 PM Brian Bouterse 
>>> wrote:
>>>
 Thank you for porting these! I'm +1 to moving all Pulp3 projects with
 an ack from each plugin team first.

 I can ack for pulp_ansible, if it's possible to move that one please.
 Let me know how I can help also.

 On Wed, Apr 29, 2020 at 6:43 AM David Davis 
 wrote:

> Out of curiosity this morning I tried migrating pulp_file over to
> travis-ci this morning and it worked. So then I went back and tried
> pulp-certguard and that worked as well. So now both projects are on
> travis-ci.com.
>
> I think these are the main projects still on travis-ci.org:
> - pulp_ansible
> - pulp_rpm
> - pulp
> - pulp_python
> - pulp_gem
> - pulp-smash
> - pulp-ci
> - Pulp-2-Tests
> - pulp_ostree
> - crane
>
> Should we move these projects over as well? Maybe just the Pulp 3
> ones? I'd also like confirmation from plugin teams though before we move
> their repos over.
>
> David
>
>
> On Thu, Apr 23, 2020 at 11:01 AM Daniel Alley 
> wrote:
>
>> I kid, but it is a funny situation
>>
>> On Thu, Apr 23, 2020 at 10:01 AM David Davis 
>> wrote:
>>
>>> LOL.
>>>
>>> To answer your question though, we're kind of in a holding pattern
>>> right now. There are some missing features like sharing jobs between
>>> workflows and restarting jobs within workflows that we're hoping Github
>>> Actions adds. Maybe we can revisit though at our next CI meeting.
>>>
>>> David
>>>
>>>
>>> On Thu, Apr 23, 2020 at 9:46 AM Daniel Alley 
>>> wrote:
>>>
 travis-ci.org is broken
>
 migrating away from travis-ci.org is also broken
>

 So, uh, when will github actions be ready xD

 On Thu, Apr 23, 2020 at 8:40 AM David Davis 
 wrote:

> I wrote to Travis support yesterday and they responded (below). I
> tried again this morning and it's still broken. I'll wait a few more 
> days
> unless anyone objects.
>
>
>
>
>
>
>
>
>
> *Thank you for reaching out! We are sorry about the issue that you
> are having.We are currently aware of a bug related to migrating
> repositories from travis-ci.org  to 
> travis-ci.com
>  and our Engineering Team is working on this 
> issue to
> be solved as soon as possible.Until the fix is deployed, we would 
> kindly
> suggest you build your projects on travis-ci.org
> .Thank you for your patience and once again we 
> are
> extremely sorry about the issue.*
>
> David
>
>
> On Thu, Apr 23, 2020 at 8:34 AM Brian Bouterse <
> bmbou...@redhat.com> wrote:
>
>>
>>
>> On Wed, Apr 22, 2020 at 3:48 PM David Davis <
>> davidda...@redhat.com> wrote:
>>
>>> Ok, I agree. I tried to migrate certguard to travis-ci.com and
>>> hit a 500 error. Looks like we're not alone both in status updates 
>>> not
>>> being reported from travis-ci.org and having problems trying to
>>> migrate:
>>>
>>>
>>> https://travis-ci.community/t/github-status-not-posted-on-commits-on-repositories-using-legacy-service-integration/7798/16
>>>
>>> I'll wait a day for Travis support to respond but I think we
>>> could also just enable the repos and start from scratch in
>>> travis-ci.com. I think we'd lose past build information and
>>> settings though if we don't migrate.
>>>
>> This also sounds good to me. 

Re: [Pulp-dev] Moving to travis-ci.com

[Tatiana Tereshchenko]

Thank you! +1 for pulp_rpm to migrate.

Tanya

On Tue, May 5, 2020 at 1:38 PM David Davis  wrote:

> I migrated over pulp_ansible, pulp-smash, and pulp-ci. I think at this
> point, these are the only pulp 3 repos still on travis-ci.org:
>
> - pulp_rpm
> - pulp_python
> - pulp_gem
>
> If any of the plugins want me to migrate these over, please let me know.
>
> David
>
>
> On Mon, May 4, 2020 at 7:12 AM Ina Panova  wrote:
>
>> +1 to move pulp3 projects.
>> Thank you for taking care of this.
>>
>>
>> 
>> Regards,
>>
>> Ina Panova
>> Senior 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 Fri, May 1, 2020 at 9:22 PM Brian Bouterse 
>> wrote:
>>
>>> Thank you for porting these! I'm +1 to moving all Pulp3 projects with an
>>> ack from each plugin team first.
>>>
>>> I can ack for pulp_ansible, if it's possible to move that one please.
>>> Let me know how I can help also.
>>>
>>> On Wed, Apr 29, 2020 at 6:43 AM David Davis 
>>> wrote:
>>>
 Out of curiosity this morning I tried migrating pulp_file over to
 travis-ci this morning and it worked. So then I went back and tried
 pulp-certguard and that worked as well. So now both projects are on
 travis-ci.com.

 I think these are the main projects still on travis-ci.org:
 - pulp_ansible
 - pulp_rpm
 - pulp
 - pulp_python
 - pulp_gem
 - pulp-smash
 - pulp-ci
 - Pulp-2-Tests
 - pulp_ostree
 - crane

 Should we move these projects over as well? Maybe just the Pulp 3 ones?
 I'd also like confirmation from plugin teams though before we move their
 repos over.

 David


 On Thu, Apr 23, 2020 at 11:01 AM Daniel Alley 
 wrote:

> I kid, but it is a funny situation
>
> On Thu, Apr 23, 2020 at 10:01 AM David Davis 
> wrote:
>
>> LOL.
>>
>> To answer your question though, we're kind of in a holding pattern
>> right now. There are some missing features like sharing jobs between
>> workflows and restarting jobs within workflows that we're hoping Github
>> Actions adds. Maybe we can revisit though at our next CI meeting.
>>
>> David
>>
>>
>> On Thu, Apr 23, 2020 at 9:46 AM Daniel Alley 
>> wrote:
>>
>>> travis-ci.org is broken

>>> migrating away from travis-ci.org is also broken

>>>
>>> So, uh, when will github actions be ready xD
>>>
>>> On Thu, Apr 23, 2020 at 8:40 AM David Davis 
>>> wrote:
>>>
 I wrote to Travis support yesterday and they responded (below). I
 tried again this morning and it's still broken. I'll wait a few more 
 days
 unless anyone objects.









 *Thank you for reaching out! We are sorry about the issue that you
 are having.We are currently aware of a bug related to migrating
 repositories from travis-ci.org  to travis-ci.com
  and our Engineering Team is working on this 
 issue to
 be solved as soon as possible.Until the fix is deployed, we would 
 kindly
 suggest you build your projects on travis-ci.org
 .Thank you for your patience and once again we 
 are
 extremely sorry about the issue.*

 David


 On Thu, Apr 23, 2020 at 8:34 AM Brian Bouterse 
 wrote:

>
>
> On Wed, Apr 22, 2020 at 3:48 PM David Davis 
> wrote:
>
>> Ok, I agree. I tried to migrate certguard to travis-ci.com and
>> hit a 500 error. Looks like we're not alone both in status updates 
>> not
>> being reported from travis-ci.org and having problems trying to
>> migrate:
>>
>>
>> https://travis-ci.community/t/github-status-not-posted-on-commits-on-repositories-using-legacy-service-integration/7798/16
>>
>> I'll wait a day for Travis support to respond but I think we
>> could also just enable the repos and start from scratch in
>> travis-ci.com. I think we'd lose past build information and
>> settings though if we don't migrate.
>>
> This also sounds good to me. If you want to tag-team via irc or
> video we can do that.
>
>
>> David
>>
>>
>> On Wed, Apr 22, 2020 at 3:21 PM Brian Bouterse <
>> bmbou...@redhat.com> wrote:
>>
>>> OK now more than an annoyance, travis-ci.org not notifying
>>> github is preventing certguard from merging without me disabling 
>>> the CI
>>> check  :(
>>>
>>> I think we need to do this asap.
>>>
>>> On Wed, Apr 22, 2020 at 9:21 AM 

Re: [Pulp-dev] Moving to travis-ci.com

[David Davis]

I migrated over pulp_ansible, pulp-smash, and pulp-ci. I think at this
point, these are the only pulp 3 repos still on travis-ci.org:

- pulp_rpm
- pulp_python
- pulp_gem

If any of the plugins want me to migrate these over, please let me know.

David


On Mon, May 4, 2020 at 7:12 AM Ina Panova  wrote:

> +1 to move pulp3 projects.
> Thank you for taking care of this.
>
>
> 
> Regards,
>
> Ina Panova
> Senior 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 Fri, May 1, 2020 at 9:22 PM Brian Bouterse  wrote:
>
>> Thank you for porting these! I'm +1 to moving all Pulp3 projects with an
>> ack from each plugin team first.
>>
>> I can ack for pulp_ansible, if it's possible to move that one please. Let
>> me know how I can help also.
>>
>> On Wed, Apr 29, 2020 at 6:43 AM David Davis 
>> wrote:
>>
>>> Out of curiosity this morning I tried migrating pulp_file over to
>>> travis-ci this morning and it worked. So then I went back and tried
>>> pulp-certguard and that worked as well. So now both projects are on
>>> travis-ci.com.
>>>
>>> I think these are the main projects still on travis-ci.org:
>>> - pulp_ansible
>>> - pulp_rpm
>>> - pulp
>>> - pulp_python
>>> - pulp_gem
>>> - pulp-smash
>>> - pulp-ci
>>> - Pulp-2-Tests
>>> - pulp_ostree
>>> - crane
>>>
>>> Should we move these projects over as well? Maybe just the Pulp 3 ones?
>>> I'd also like confirmation from plugin teams though before we move their
>>> repos over.
>>>
>>> David
>>>
>>>
>>> On Thu, Apr 23, 2020 at 11:01 AM Daniel Alley  wrote:
>>>
 I kid, but it is a funny situation

 On Thu, Apr 23, 2020 at 10:01 AM David Davis 
 wrote:

> LOL.
>
> To answer your question though, we're kind of in a holding pattern
> right now. There are some missing features like sharing jobs between
> workflows and restarting jobs within workflows that we're hoping Github
> Actions adds. Maybe we can revisit though at our next CI meeting.
>
> David
>
>
> On Thu, Apr 23, 2020 at 9:46 AM Daniel Alley 
> wrote:
>
>> travis-ci.org is broken
>>>
>> migrating away from travis-ci.org is also broken
>>>
>>
>> So, uh, when will github actions be ready xD
>>
>> On Thu, Apr 23, 2020 at 8:40 AM David Davis 
>> wrote:
>>
>>> I wrote to Travis support yesterday and they responded (below). I
>>> tried again this morning and it's still broken. I'll wait a few more 
>>> days
>>> unless anyone objects.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> *Thank you for reaching out! We are sorry about the issue that you
>>> are having.We are currently aware of a bug related to migrating
>>> repositories from travis-ci.org  to travis-ci.com
>>>  and our Engineering Team is working on this 
>>> issue to
>>> be solved as soon as possible.Until the fix is deployed, we would kindly
>>> suggest you build your projects on travis-ci.org
>>> .Thank you for your patience and once again we are
>>> extremely sorry about the issue.*
>>>
>>> David
>>>
>>>
>>> On Thu, Apr 23, 2020 at 8:34 AM Brian Bouterse 
>>> wrote:
>>>


 On Wed, Apr 22, 2020 at 3:48 PM David Davis 
 wrote:

> Ok, I agree. I tried to migrate certguard to travis-ci.com and
> hit a 500 error. Looks like we're not alone both in status updates not
> being reported from travis-ci.org and having problems trying to
> migrate:
>
>
> https://travis-ci.community/t/github-status-not-posted-on-commits-on-repositories-using-legacy-service-integration/7798/16
>
> I'll wait a day for Travis support to respond but I think we could
> also just enable the repos and start from scratch in travis-ci.com.
> I think we'd lose past build information and settings though if we 
> don't
> migrate.
>
 This also sounds good to me. If you want to tag-team via irc or
 video we can do that.


> David
>
>
> On Wed, Apr 22, 2020 at 3:21 PM Brian Bouterse <
> bmbou...@redhat.com> wrote:
>
>> OK now more than an annoyance, travis-ci.org not notifying
>> github is preventing certguard from merging without me disabling the 
>> CI
>> check  :(
>>
>> I think we need to do this asap.
>>
>> On Wed, Apr 22, 2020 at 9:21 AM Brian Bouterse <
>> bmbou...@redhat.com> wrote:
>>
>>> I don't know the answer to your question about capacity, but
>>> I've been hitting this "not-updating-github" issue a lot recently. 
>>> +1 to
>>> moving everything to travis-ci.com.

[Pulp-dev] Fwd: Status of pulp-python

[Christoph Höger]

Dear all,

I am currently in the process of investigating the usage of pulp for our
company's repository management and think I can fulfill all the
requirements except for a pypi mirror. While this is exactly what
pulp-python seems to provides it has a showstopper bug:

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

which appears to be the same as:

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

I assume that I could get one of our python guys working on the matter, if
I can refer them to a) someone to talk to about the project and b) get some
assurance that this plugin is not dead already.

So do you know what the status of pulp-python is? Is it just not very high
on the priorities or is it already more or less abandoned? I am asking
this, because pulpcore and some other plugins seem to have a relatively
fast pace. If pulp-python is abandoned we might just go on with deb/rpm
support and use something else to mirror pypi.

thank you very much,

Christoph

-- 
Christoph Höger

Email: christoph.hoe...@celeraone.com 
Web: www.celeraone.com
___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev

Re: [Pulp-dev] signing service interface

[Quirin Pamp]

Could you explain the reasoning for a 'public.key' file?


In the case of the AptReleaseSigningService we built for pulp_deb we saw zero 
need for this file and consequently did not add it in.

(It would not be hard to add it just to satisfy the interface, it just would 
not serve any useful purpose.)


Since we are on the topic of signing services, a colleague has had a PR 
relating to them just sitting their waiting for a review for quite a while now 
;-):
https://github.com/pulp/pulpcore/pull/659


It would be great if you (or somebody else) could have a look at it. I believe 
it is mostly ready, but probably needs the eyes of an experienced pulp core 
developer to look over it and suggest style consistency changes and where and 
whether to add documentation. ;-)


Quirin


From: pulp-dev-boun...@redhat.com  on behalf of 
Dennis Kliban 
Sent: 04 May 2020 22:50:54
To: Pulp-dev 
Subject: [Pulp-dev] signing service interface

The Plugin API of Signing Services in Pulp 3 is too vague. I came to this 
conclusion while working with @lieter on an RPM plugin feature that allows 
users to download a repo config file from a distribution[0]. As a result, we 
decided to document that the signing service needs to produce a public key file 
named 'public.key'[1].

We should revisit the design of the signing service API to ensure that we 
enforce this naming convention.

[0] https://pulp.plan.io/issues/5356
[1] 
https://github.com/pulp/pulp_rpm/pull/1687/files#diff-c91893c1f4e7afe73e414d1a76162463R30
___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev