[Pulp-dev] fedorapeople.org fixtures

Tue May 5 13:48:52 UTC 2020

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