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 <ipan...@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 <davidda...@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 <bmbou...@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 <mikedep...@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 < >>>> 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 <p...@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-boun...@redhat.com <pulp-dev-boun...@redhat.com> on >>>>>> behalf of David Davis <davidda...@redhat.com> >>>>>> *Sent:* 28 April 2020 22:19:23 >>>>>> *To:* Pulp-dev <pulp-dev@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@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 <https://www.redhat.com/> >>>> >>>> IM: mikedep333 >>>> >>>> GPG: 51745404 >>>> <https://www.redhat.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 >>> >> _______________________________________________ >> 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
