[Pulp-dev] fedorapeople.org fixtures

Mon May 4 16:25:46 UTC 2020

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 <ipanova at redhat.com> 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 <daviddavis at redhat.com> 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 <bmbouter at redhat.com>
>> 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 <mikedep333 at redhat.com>
>>> 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 <
>>>> ttereshc at 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 <pamp at atix.de> 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-bounces at redhat.com <pulp-dev-bounces at redhat.com> on
>>>>>> behalf of David Davis <daviddavis at redhat.com>
>>>>>> *Sent:* 28 April 2020 22:19:23
>>>>>> *To:* Pulp-dev <pulp-dev at redhat.com>
>>>>>> *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 at redhat.com
>>>>>> https://www.redhat.com/mailman/listinfo/pulp-dev
>>>>>>
>>>>> _______________________________________________
>>>>> Pulp-dev mailing list
>>>>> Pulp-dev at redhat.com
>>>>> https://www.redhat.com/mailman/listinfo/pulp-dev
>>>>>
>>>>
>>>>
>>>> --
>>>>
>>>> Mike DePaulo
>>>>
>>>> He / Him / His
>>>>
>>>> Service Reliability Engineer, Pulp
>>>>
>>>> Red Hat <https://www.redhat.com/>
>>>>
>>>> IM: mikedep333
>>>>
>>>> GPG: 51745404
>>>> <https://www.redhat.com/>
>>>> _______________________________________________
>>>> Pulp-dev mailing list
>>>> Pulp-dev at redhat.com
>>>> https://www.redhat.com/mailman/listinfo/pulp-dev
>>>>
>>> _______________________________________________
>>> Pulp-dev mailing list
>>> Pulp-dev at redhat.com
>>> https://www.redhat.com/mailman/listinfo/pulp-dev
>>>
>> _______________________________________________
>> Pulp-dev mailing list
>> Pulp-dev at redhat.com
>> https://www.redhat.com/mailman/listinfo/pulp-dev
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/pulp-dev/attachments/20200504/f7f313b2/attachment.htm>