[Pulp-dev] fedorapeople.org fixtures

Brian Bouterse bmbouter at redhat.com
Tue May 5 13:45:25 UTC 2020


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 <bmbouter at redhat.com> 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 <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/20200505/b961dd2c/attachment.htm>


More information about the Pulp-dev mailing list