[Pulp-dev] Any interest in prometheus integration for pulp?

[Adrian Likins]

I have a PR for pulpcore at https://github.com/pulp/pulpcore/pull/518
that will enable basic prometheus support in pulp by using the
https://github.com/korfuri/django-prometheus package.

This is something we use/need for pulp_ansible in ansible galaxy, and find
it a little troublesome to patch into pulp plugins with changes similar to
this PR.

The pr only adds basic support, but further iteration could include some
default custom pulp metrics.

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

Re: [Pulp-dev] Required fields for models at the DB level

[Brian Bouterse]

Recently a group of developers investigated if pulpcore needed to make any
changes regarding the concerns discussed in this thread from a while ago.
Here are the conclusions we reached, please let us know if you have other
ideas or concerns:

* We lack documentation advising plugin writers that they need to use DRF
serializers to validate models. This includes cases where the data didn't
come from users but from a remote source during sync. That docs addition is
being tracked here https://pulp.plan.io/issues/5927
* No pulpcore code changes are needed since Pulpcore does not create any
objects, e.g. Content, it only saves objects already created by plugin code
in the Stages API first stage.

We'll proceed with the docs and that should resolve this issue. Please let
us know if you have concerns, questions, or ideas.

Thanks to the devs who collaborated in this effort.

-Brian


On Tue, Dec 10, 2019 at 3:39 AM Tatiana Tereshchenko 
wrote:

> +1 to have additional serializer for validation content fields and use
> current serializers for upload case
> +1 to validate during sync
>
> On Fri, Dec 6, 2019 at 8:31 PM David Davis  wrote:
>
>> I talked to @ttereshc this afternoon and a couple questions came up.
>>
>> First, in pulp_rpm we have a PackageSerializer[0] that handles creating
>> and displaying packages. The problem is that the package field values are
>> derived from the artifact and not the user so most fields are readonly and
>> not required. I'm imagining we'll have to split this serializer in two (ie
>> a PackageSerializer and a PackageUploadSerializer) in order to use it to
>> validate package data. Does that make sense or is there a better way?
>>
>> Secondly, I don't think we're validating data during sync. What if a user
>> syncs data from a remote that has bad data? I think we'll need to have the
>> stages somehow use serializers as well? If others agree, I can file an
>> issue.
>>
>> [0]
>> https://github.com/pulp/pulp_rpm/blob/326d189bbae9267d59282d62ada1fa36467a2d8f/pulp_rpm/app/serializers.py#L69
>>
>> David
>>
>>
>> On Thu, Dec 5, 2019 at 6:32 AM David Davis  wrote:
>>
>>> This makes sense to me. I wonder if we should document what you've
>>> outlined in the plugin writers guide? If so, then maybe we should repurpose
>>> 5828?
>>>
>>> David
>>>
>>>
>>> On Tue, Dec 3, 2019 at 12:14 PM Brian Bouterse 
>>> wrote:
>>>
 After some IRC discussion during open floor, I think the consensus is
 that we should not have BaseModel call full_clean(). Plugin writers doing a
 lot of object creation without involving DRF serializers should call
 full_clean() either in application code or their specific model's save()
 method. Here's some recap about the motivations for this:

 * By having full_clean() called with all model save it gives Pulp "two
 validation layers" when there only needs to be one. DRF's validation layer
 is the serializer, and it isn't prepared to do error handling from a
 "second" layer. This is partly an echo of the concerns from Tom Christie's
 writing.
 * DRF is primarily designed to have data flow through its serializers.
 This issue is more problematic in cases where data is not flowing through
 the serializer. Thus we should try to include the serializer whenever
 possible.
 * If we cannot include the serializer, those are cases where we would
 specifically benefit from calling full_clean manually.

 Other thoughts and concerns are welcome. If nothing major comes up then
 we can close https://pulp.plan.io/issues/5828 as WONTFIX.



 On Mon, Dec 2, 2019 at 6:52 PM Simon Baatz  wrote:

> On Mon, Dec 02, 2019 at 03:53:06PM -0500, Brian Bouterse wrote:
> >If anyone has concerns with us enabling Model validation by
> default on
> >all models please let us know soon.
>
> I don't know (yet) if I have concerns, but DRF seems to have, see
>
> https://www.django-rest-framework.org/community/3.0-announcement/#differences-between-modelserializer-validation-and-modelform
>
> According to DRF's design, all validation logic should be at one
> place, which is the serializer.  This seems to be a controversial
> issue, see e.g.
> https://github.com/encode/django-rest-framework/issues/3144.  From
> that issue:
>
> What happens in the case where in your models you are forcing a
> full_clean (perhaps by including it in the save method)?  Will
> serializers know how to handle an exception from an explicit
> full_clean?
>
> And Tom Christie's answer:
>
> I'd recommend that application level validation should generally
> happen prior to save, not during it.  Personally I'd avoid
> full_clean, and instead ensure that state changing operations on
> model instances are only ever made via method calls that can provide
> a boundary that ensures that only valid state changes may ever be
> made by 

[Pulp-dev] Markdown docs - pulpcore and plugins

[Fabricio Aguiar]

Due issue 6518 , about documenting the
python clients,
I searched about how to use markdown on sphinx and found this [1]
This helped me to document pulp_file client [2], currently, it introduces
markdown docs from the client, keeping the pulp_file rst docs.

Instead of getting mixed formats for docs,
I propose we move our current docs to markdown,
please share your thoughts!

[1] https://www.sphinx-doc.org/en/master/usage/markdown.html
[2] https://github.com/pulp/pulp_file/pull/386

Best regards,
Fabricio Aguiar
Software Engineer, Pulp Project
Red Hat Brazil - Latam 
+55 11 999652368
___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev

Re: [Pulp-dev] Pulp 3 CLI MVP

[David Davis]

Today we met to discuss some ideas for a technical design for how the CLI
would work. Here's a copy of our notes:

https://hackmd.io/aH9RqAS_TrGyxoi1UGRgig#Technical-discussion

And there is a rough design in the document as well:

https://hackmd.io/aH9RqAS_TrGyxoi1UGRgig#Design

I have also entered the CLI user stories from our meeting last week into
redmine under the Pulp CLI project:

https://pulp.plan.io/versions/93

And I've filed a user story that we talked about today that would handle
sync, publish, and distribution of repos. Feedback welcome:

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

Matthias and I are planning to meet next week to look at creating a proof
of concept that would provide 2-3 commands. If anyone is interested in
joining us, please let me know and I can add you.

David


On Tue, Apr 28, 2020 at 8:06 AM David Davis  wrote:

> I've also started working on some questions about how the CLI will work.
> Feel free to add some of your own:
>
> https://hackmd.io/aH9RqAS_TrGyxoi1UGRgig?view#Technical-discussion
>
> David
>
>
> On Tue, Apr 28, 2020 at 8:05 AM David Davis  wrote:
>
>> I have set up a meeting to discuss the CLI technical design. Below are
>> the details. I think a video conference might be easier for technical
>> discussion but am open to consider meeting on #pulp-meeting again.
>>
>> URL: https://meet.google.com/vgx-bzbb-wnh
>> Date/time: April 30, 2020 at 9:00am ET (1pm UTC)
>>
>> David
>>
>>
>> On Fri, Apr 24, 2020 at 10:29 AM David Davis 
>> wrote:
>>
>>> Today we met in #pulp-meeting on freenode to discuss the user stories
>>> for a Pulp 3 CLI MVP. The document with the user stories is available
>>> below. I'd like to ask for any feedback from users or plugin writers.
>>>
>>> The goal of the CLI MVP is to cover the pulp_file happy path (sync,
>>> publish, distribute) and make it possible for plugin writers to generate
>>> and write their own commands. I'm imagining that plugins will release their
>>> own sets of CLI commands after we complete the initial MVP.
>>>
>>> https://hackmd.io/aH9RqAS_TrGyxoi1UGRgig
>>>
>>> Feedback is welcome. I plan to enter these user stories into redmine
>>> next week.
>>>
>>> David
>>>
>>
___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev

Re: [Pulp-dev] RPM plugin meeting notes

[Robin Chan]

>
>
>-
>
>From now on, add functional tests at the same time as features
>-
>
>   At least a happy path
>
> +1 - Let's start building this into feature delivery estimates and
commitments to stakeholders

Robin Chan

She/Her/Hers

Satellite Software Engineering Manager - Pulp

Red Hat 

IRC: rchan




On Thu, Apr 30, 2020 at 12:37 PM Tatiana Tereshchenko 
wrote:

> Pulp 3:
>
>-
>
>3.3.0 is released
>-
>
>From now on, add functional tests at the same time as features
>-
>
>   At least a happy path
>
> +1 - Let's start building this into feature delivery estimates and
commitments to stakeholders


>
>-
>
>List of RPM features to test and/or to ensure are present in the docs
>-
>
>   AI: Please review areas you are familiar with and which you think
>   deserve a happy-path test or a note in the docs
>   -
>
>Reminder: relative path problem still unsolved, another meeting on
>Monday to discuss
>-
>
>Features
>-
>
>   Mirrorlist support from @lmjachky
>   -
>
>  https://pulp.plan.io/issues/6225
>  -
>
>  In progress https://github.com/pulp/pulp_rpm/pull/1690
>  -
>
>   config.repo feature from @lieter
>   -
>
>  There is a problem with determining the name of the public key
>  file
>  -
>
> AI: dkliban will send a note to list about needing to
> strengthen the interface for signing services. Will for now 
> provide docs
> that recommend using a specific name for a public key.
>
>
> Pulp 2:
>
>-
>
>All 2.21.2 items are done.
>-
>
>   dalley is taking care of it instead of dkliban
>   -
>
>Need to reply to Katello
>-
>
>   CentOS 8 kickstarts  https://pulp.plan.io/issues/6470
>   -
>
>   can't be fixed in pulp2, will be fixed in pulp 3, dkliban to reach
>   out to Katello
>
>
> Open PRs:
>
>-
>
>https://github.com/pulp/pulp_rpm/pulls
>
>
> Triage:
>
>-
>
>Un-triaged bugs
>https://pulp.plan.io/projects/pulp_rpm/issues?query_id=30
>
>
>
> Sprint planning prep:
>
>-
>
>planned to be worked on during sprint and estimated time for each
>-
>
>   ppicka - tests planning/implementation (full time)
>   -
>
>   dkliban - kickstarts issues (1 day)
>   -
>
>   dalley - pulp 2 release (1 day)
>
> ___
> 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] the "relative path" problem

[Daniel Alley]

Cool, so the only difference is whether to try to store the relationship in
the DB, or leverage the fact that we already have the metadata and just
re-parse it.

I know the latter approach has yet to be written up, but my concern there
is that adding another layer of indirection between "repository version"
and "content" is going to have an adverse impact on performance, since it
is already the most complex and demanding query we issue to the DB and one
of the most common and important.

On Thu, Apr 30, 2020 at 12:50 PM David Davis  wrote:

> Yes but I was imagining the mapping would be stored not as Content but as
> a separate object. So we wouldn't use filename for the mapping (rather we'd
> use ContentArtifact pk) and  we wouldn't need to change ContentArtifact's
> relative_path at all. That said, I think your solution captures the idea
> though and is better in some ways.
>
> Changing the RepositoryContent model to point to ContentArtifacts and
> store relative_paths is probably the best and most correct solution in
> theory. However, it's going to be painful to implement for both core and
> plugins.
>
> David
>
>
> On Thu, Apr 30, 2020 at 12:33 PM Daniel Alley  wrote:
>
>> @David Davis   so this proposal would go
>> something like this, correct?:
>>
>> * For the signed metadata / exact mirror use-case we need to store the
>> repository metadata itself as a content unit inside the RepositoryVersion
>> anyway (because the hash must be equal)
>> * Because we have this metadata lying around, we can reference it at
>> publish time to discover the appropriate PublishedArtifact.relative_path
>>* Create a map of "filename" -> "location_href" and look up the
>> filename of each RPM package to find the appropriate path
>>* This should be pretty fast for the RPM plugin since createrepo_c is
>> doing all the hard work
>> * Data migration to ensure ContentArtifact.relative_path is only storing
>> the filename (and I would suggest we also change the name to "filename")
>> * If metadata isn't present in the RepositoryVersion, then just tweak the
>> PublishedArtifact.relative_path so that it uses whichever our default repo
>> layout is
>>
>> On Tue, Apr 28, 2020 at 11:41 AM David Davis 
>> wrote:
>>
>>> Yes, that's correct. During our meeting we discussed two options: the
>>> first was to extend RepositoryContent to store relative path per
>>> ContentArtifact as storing a relative_path per Content won't work for
>>> multi-Artifact Content units.
>>>
>>> An alternative that I pitched was to have plugins (or maybe even core
>>> someday) store this information outside RepositoryContent and then use this
>>> information during publishing to set relative_path on PublishedArtifacts.
>>> We'd have to modify the content app if we wanted to support pass through
>>> publications but I think asking plugins to use published artifacts in this
>>> case is warranted. That said, I don't think anyone else was keen on this
>>> idea though.
>>>
>>> David
>>>
>>>
>>> On Tue, Apr 28, 2020 at 10:30 AM Matthias Dellweg 
>>> wrote:
>>>
 That is only used for passthrough publication afaik. If you publish
 each content unit "by hand", you create a new relative path for each
 published artifact. That is, why it can be empty and still the content can
 be published.

 On Tue, Apr 28, 2020 at 4:09 PM Daniel Alley  wrote:

> We realized in our discussion that the original proposal described in
> my email will not work, because "relative_path" ultimately describes the
> path of the published *artifacts* (not content), and for content
> types with multiple artifacts, storing this information in a field on
> RepositoryContent would not be possible.
>
> On Mon, Apr 27, 2020 at 6:08 PM Daniel Alley 
> wrote:
>
>> There is a video call scheduled to discuss this issue tomorrow
>> (Tuesday April 28th) at 13:30 UTC (please convert to your local time).
>> https://meet.google.com/scy-csbx-qiu
>>
>> On Sat, Apr 25, 2020 at 7:02 AM David Davis 
>> wrote:
>>
>>> I had a chance to think about this some more yesterday and wanted to
>>> email out my thoughts. I also think that this change sounds scary and 
>>> will
>>> have a big impact on plugin writers so I thought of a couple 
>>> alternatives:
>>>
>>> First, we could add a relative_path field to RepositoryContent
>>> instead of moving it there. This would be an optional field. It would 
>>> be up
>>> to plugins to manage this field and they would still need to populate 
>>> the
>>> relative_path field on ContentArtifact. But plugins could use this 
>>> optional
>>> field to store relative paths per repository and then use this field 
>>> when
>>> generating publications.
>>>
>>> The second alternative is one that is already laid out in the
>>> original email but to call it out again: it would be to not solve this 
>>> in
>>> 

Re: [Pulp-dev] the "relative path" problem

[David Davis]

Yes but I was imagining the mapping would be stored not as Content but as a
separate object. So we wouldn't use filename for the mapping (rather we'd
use ContentArtifact pk) and  we wouldn't need to change ContentArtifact's
relative_path at all. That said, I think your solution captures the idea
though and is better in some ways.

Changing the RepositoryContent model to point to ContentArtifacts and store
relative_paths is probably the best and most correct solution in theory.
However, it's going to be painful to implement for both core and plugins.

David


On Thu, Apr 30, 2020 at 12:33 PM Daniel Alley  wrote:

> @David Davis   so this proposal would go something
> like this, correct?:
>
> * For the signed metadata / exact mirror use-case we need to store the
> repository metadata itself as a content unit inside the RepositoryVersion
> anyway (because the hash must be equal)
> * Because we have this metadata lying around, we can reference it at
> publish time to discover the appropriate PublishedArtifact.relative_path
>* Create a map of "filename" -> "location_href" and look up the
> filename of each RPM package to find the appropriate path
>* This should be pretty fast for the RPM plugin since createrepo_c is
> doing all the hard work
> * Data migration to ensure ContentArtifact.relative_path is only storing
> the filename (and I would suggest we also change the name to "filename")
> * If metadata isn't present in the RepositoryVersion, then just tweak the
> PublishedArtifact.relative_path so that it uses whichever our default repo
> layout is
>
> On Tue, Apr 28, 2020 at 11:41 AM David Davis 
> wrote:
>
>> Yes, that's correct. During our meeting we discussed two options: the
>> first was to extend RepositoryContent to store relative path per
>> ContentArtifact as storing a relative_path per Content won't work for
>> multi-Artifact Content units.
>>
>> An alternative that I pitched was to have plugins (or maybe even core
>> someday) store this information outside RepositoryContent and then use this
>> information during publishing to set relative_path on PublishedArtifacts.
>> We'd have to modify the content app if we wanted to support pass through
>> publications but I think asking plugins to use published artifacts in this
>> case is warranted. That said, I don't think anyone else was keen on this
>> idea though.
>>
>> David
>>
>>
>> On Tue, Apr 28, 2020 at 10:30 AM Matthias Dellweg 
>> wrote:
>>
>>> That is only used for passthrough publication afaik. If you publish each
>>> content unit "by hand", you create a new relative path for each published
>>> artifact. That is, why it can be empty and still the content can be
>>> published.
>>>
>>> On Tue, Apr 28, 2020 at 4:09 PM Daniel Alley  wrote:
>>>
 We realized in our discussion that the original proposal described in
 my email will not work, because "relative_path" ultimately describes the
 path of the published *artifacts* (not content), and for content types
 with multiple artifacts, storing this information in a field on
 RepositoryContent would not be possible.

 On Mon, Apr 27, 2020 at 6:08 PM Daniel Alley  wrote:

> There is a video call scheduled to discuss this issue tomorrow
> (Tuesday April 28th) at 13:30 UTC (please convert to your local time).
> https://meet.google.com/scy-csbx-qiu
>
> On Sat, Apr 25, 2020 at 7:02 AM David Davis 
> wrote:
>
>> I had a chance to think about this some more yesterday and wanted to
>> email out my thoughts. I also think that this change sounds scary and 
>> will
>> have a big impact on plugin writers so I thought of a couple 
>> alternatives:
>>
>> First, we could add a relative_path field to RepositoryContent
>> instead of moving it there. This would be an optional field. It would be 
>> up
>> to plugins to manage this field and they would still need to populate the
>> relative_path field on ContentArtifact. But plugins could use this 
>> optional
>> field to store relative paths per repository and then use this field when
>> generating publications.
>>
>> The second alternative is one that is already laid out in the
>> original email but to call it out again: it would be to not solve this in
>> pulpcore. RPM would create its own object that would map content in a
>> repository to relative_paths.
>>
>> David
>>
>>
>> On Tue, Apr 21, 2020 at 9:22 AM Quirin Pamp  wrote:
>>
>>> Hi,
>>>
>>>
>>> I am not currently very well versed in the classes involved, but
>>> moving relative_path around sounds slightly scary with the potential to
>>> break things.
>>>
>>>
>>> As such, I would be interested to be kept in the loop as this moves
>>> forward. (Mailing list once there is some movement is entirely 
>>> sufficient
>>> )
>>>
>>>
>>> Thanks,
>>>
>>> Quirin Pamp
>>> 

[Pulp-dev] RPM plugin meeting notes

[Tatiana Tereshchenko]

Pulp 3:

   -

   3.3.0 is released
   -

   From now on, add functional tests at the same time as features
   -

  At least a happy path
  -

   List of RPM features to test and/or to ensure are present in the docs
   -

  AI: Please review areas you are familiar with and which you think
  deserve a happy-path test or a note in the docs
  -

   Reminder: relative path problem still unsolved, another meeting on
   Monday to discuss
   -

   Features
   -

  Mirrorlist support from @lmjachky
  -

 https://pulp.plan.io/issues/6225
 -

 In progress https://github.com/pulp/pulp_rpm/pull/1690
 -

  config.repo feature from @lieter
  -

 There is a problem with determining the name of the public key file
 -

AI: dkliban will send a note to list about needing to
strengthen the interface for signing services. Will for
now provide docs
that recommend using a specific name for a public key.


Pulp 2:

   -

   All 2.21.2 items are done.
   -

  dalley is taking care of it instead of dkliban
  -

   Need to reply to Katello
   -

  CentOS 8 kickstarts  https://pulp.plan.io/issues/6470
  -

  can't be fixed in pulp2, will be fixed in pulp 3, dkliban to reach
  out to Katello


Open PRs:

   -

   https://github.com/pulp/pulp_rpm/pulls


Triage:

   -

   Un-triaged bugs https://pulp.plan.io/projects/pulp_rpm/issues?query_id=30



Sprint planning prep:

   -

   planned to be worked on during sprint and estimated time for each
   -

  ppicka - tests planning/implementation (full time)
  -

  dkliban - kickstarts issues (1 day)
  -

  dalley - pulp 2 release (1 day)
___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev

Re: [Pulp-dev] the "relative path" problem

[Daniel Alley]

@David Davis   so this proposal would go something
like this, correct?:

* For the signed metadata / exact mirror use-case we need to store the
repository metadata itself as a content unit inside the RepositoryVersion
anyway (because the hash must be equal)
* Because we have this metadata lying around, we can reference it at
publish time to discover the appropriate PublishedArtifact.relative_path
   * Create a map of "filename" -> "location_href" and look up the filename
of each RPM package to find the appropriate path
   * This should be pretty fast for the RPM plugin since createrepo_c is
doing all the hard work
* Data migration to ensure ContentArtifact.relative_path is only storing
the filename (and I would suggest we also change the name to "filename")
* If metadata isn't present in the RepositoryVersion, then just tweak the
PublishedArtifact.relative_path so that it uses whichever our default repo
layout is

On Tue, Apr 28, 2020 at 11:41 AM David Davis  wrote:

> Yes, that's correct. During our meeting we discussed two options: the
> first was to extend RepositoryContent to store relative path per
> ContentArtifact as storing a relative_path per Content won't work for
> multi-Artifact Content units.
>
> An alternative that I pitched was to have plugins (or maybe even core
> someday) store this information outside RepositoryContent and then use this
> information during publishing to set relative_path on PublishedArtifacts.
> We'd have to modify the content app if we wanted to support pass through
> publications but I think asking plugins to use published artifacts in this
> case is warranted. That said, I don't think anyone else was keen on this
> idea though.
>
> David
>
>
> On Tue, Apr 28, 2020 at 10:30 AM Matthias Dellweg 
> wrote:
>
>> That is only used for passthrough publication afaik. If you publish each
>> content unit "by hand", you create a new relative path for each published
>> artifact. That is, why it can be empty and still the content can be
>> published.
>>
>> On Tue, Apr 28, 2020 at 4:09 PM Daniel Alley  wrote:
>>
>>> We realized in our discussion that the original proposal described in my
>>> email will not work, because "relative_path" ultimately describes the path
>>> of the published *artifacts* (not content), and for content types with
>>> multiple artifacts, storing this information in a field on
>>> RepositoryContent would not be possible.
>>>
>>> On Mon, Apr 27, 2020 at 6:08 PM Daniel Alley  wrote:
>>>
 There is a video call scheduled to discuss this issue tomorrow (Tuesday
 April 28th) at 13:30 UTC (please convert to your local time).
 https://meet.google.com/scy-csbx-qiu

 On Sat, Apr 25, 2020 at 7:02 AM David Davis 
 wrote:

> I had a chance to think about this some more yesterday and wanted to
> email out my thoughts. I also think that this change sounds scary and will
> have a big impact on plugin writers so I thought of a couple alternatives:
>
> First, we could add a relative_path field to RepositoryContent instead
> of moving it there. This would be an optional field. It would be up to
> plugins to manage this field and they would still need to populate the
> relative_path field on ContentArtifact. But plugins could use this 
> optional
> field to store relative paths per repository and then use this field when
> generating publications.
>
> The second alternative is one that is already laid out in the original
> email but to call it out again: it would be to not solve this in pulpcore.
> RPM would create its own object that would map content in a repository to
> relative_paths.
>
> David
>
>
> On Tue, Apr 21, 2020 at 9:22 AM Quirin Pamp  wrote:
>
>> Hi,
>>
>>
>> I am not currently very well versed in the classes involved, but
>> moving relative_path around sounds slightly scary with the potential to
>> break things.
>>
>>
>> As such, I would be interested to be kept in the loop as this moves
>> forward. (Mailing list once there is some movement is entirely sufficient
>> )
>>
>>
>> Thanks,
>>
>> Quirin Pamp
>> --
>> *From:* pulp-dev-boun...@redhat.com  on
>> behalf of Ina Panova 
>> *Sent:* 21 April 2020 14:07:13
>> *To:* Daniel Alley 
>> *Cc:* Pulp-dev 
>> *Subject:* Re: [Pulp-dev] the "relative path" problem
>>
>> Daniel,
>>
>> how about setting up a meeting and brainstorm the alternatives,
>> pros/cons there?
>>
>>
>> 
>> 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, Apr 17, 2020 at 5:57 PM Daniel Alley 
>> wrote:
>>
>> Bump, this item needs to move forwards soon.  Does anyone have any
>> 

Re: [Pulp-dev] fedorapeople.org fixtures

[Mike DePaulo]

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 
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 in my
>> pulplift boxes using the pfixtures command (essential when working on new
>> fixtures).
>>
>> This command could be made a bit more flexible (right now it always runs
>> in the foreground and always uses the latest container image from quay.io),
>> but those would be trivial changes.
>>
>> As a result, I personally have no problems with retiring the fixtures on
>> fedorapeople.org completely.
>>
>> The disadvantage of the approach is that it requires either downloading
>> the (pretty large) fixtures container from quay.io, or building it
>> locally.
>>
>>
>> Quirin (quba42)
>> --
>> *From:* pulp-dev-boun...@redhat.com  on
>> behalf of David Davis 
>> *Sent:* 28 April 2020 22:19:23
>> *To:* Pulp-dev 
>> *Subject:* [Pulp-dev] fedorapeople.org fixtures
>>
>> Our Jenkins jobs for Pulp 2 are disabled and that also includes the job
>> that builds the fixtures and publishes them to fedorapeople.org[0]. With
>> the new pulp-fixtures container[1], it's less essential that we have
>> fixtures published somewhere. I think the two options we have are to either
>> retire the fedorapeople.org fixtures and remove them, or to move where
>> the job runs and possibly the place where they are hosted.
>>
>> Thoughts?
>>
>> [0] https://repos.fedorapeople.org/pulp/pulp/fixtures/
>> [1] https://quay.io/repository/pulp/pulp-fixtures
>>
>>
>> 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
>


-- 

Mike DePaulo

He / Him / His

Service Reliability Engineer, Pulp

Red Hat 

IM: mikedep333

GPG: 51745404

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

[Pulp-dev] New pulp-deb 2.3.0b1 (beta) release

[Quirin Pamp]

pulp-deb 2.3.0b1 (beta) has been released to https://pypi.org/project/pulp-deb/ 
today.

(I prepared, and Mathias Dellweg carried out the release, my thanks to him.)

This beta release is compatible with pulpcore 3.3 and contains SigningService 
support and several bug fixes.

Change log is available here: 
https://github.com/pulp/pulp_deb/blob/2.3/CHANGES.rst
___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev