On Sat 21 Apr 2018 05:06:32 PM CEST Ken Dreyer wrote:
> On Fri, Apr 20, 2018 at 11:34 AM, Pierre-Yves Chibon
> <pingou@xxxxxxxxxxxx> wrote:
>> I propose we start the discussion on the list and plan for a meeting sometime
>> late next week to discuss it further with the interested parties (please signal
>> yourself)
>
> I am reimplementing a small piece of PDC as well, because the RH Ceph
> Storage product uses/used PDC's
> v1/releases/{release_id}/rpm-mapping/{package}/ endpoint. I'd be
> interested in hearing where Fedora may be heading with their
> replacement ideas. Please let me know the time of the meeting :)
>
> Prior to PDC, we had/have another internal solution that used a
> PostgreSQL database for what PDC calls rpm-mappings. We thought PDC
> would eventually replace this database. With this sytem, it was
> impossible to submit changes to the data store unless you were one of
> the few people who had rights to submit changes in postgres. Even
> reading the data out into something a mere mortal can understand was a
> chore.
>
> Obviously there are many orthogonal problems there, and we could solve
> them with better APIs, docs, etc and still keep the Postgres backend.
> However it does strike me that flat YAML files in Git are an
> attractive backing store. It would make make it easier to submit and
> approve data changes, because anyone can submit pull requests to the
> flat files, and a CI system could test the changes before merging (or
> even auto-merge), etc.
The difference is that PDC rpm-mappings API endpoint was result of two
sources:
* Manual per-rpm mappings (overrides) - this is sort of suitable if you
have a product with just a couple source packages so it's manageable
this way (i.e Ceph case)
* Results of compose metadata import - this is what Fedora/RHEL uses
because several thousands of source packages are not manageable
one-by-one by humans manually.
You could still make a system that would create "PRs" for the generated
files for second case, but then querying the current state will still be
a bit tricky. I guess...
--
Stanislav Ochotnicky <sochotnicky@xxxxxxxxxx>
Software Engineer, PnT DevOps - Brno
PGP: F434 2286 27DC 7D9B 2B64 0866 BCBD 752E 7B08 7241
Red Hat Inc. http://www.redhat.com
_______________________________________________
infrastructure mailing list -- infrastructure@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to infrastructure-leave@xxxxxxxxxxxxxxxxxxxxxxx
