> * I kinda don't like the tree of files in git. It would work, but it
seems poor, like we don't know how to use a database. Along with just
strange to work with.

We could use Git repo of yaml files as the basis but import data upon
each commit for each branch into a locally mounted sqlite DB. Commits
would be rejected if the import could not be completed. Then setup just
a tiny API upon that sqlite DB served by some micro webapp.

Access control, versioning and write access would be handled by Git,
but user-friendly, fast, read-only data access would be handled by
the sqlite + http API pair.

The Git backend can also probably also added later.

I am writing this because I think it's an interesting option from the
technical perspective, not because I would be actually involved with
PDC at the moment. I just wanted to share the idea in case somebody
finds it applicable.


On Mon, Apr 23, 2018 at 7:34 PM, Ken Dreyer <ktdreyer@ktdreyer.com> wrote:
On Sun, Apr 22, 2018 at 2:23 AM, Stanislav Ochotnicky
<sochotnicky@redhat.com> wrote:
> 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...

Yeah, the fact that we have (at least) two different input and storage
methods there is a lot of complexity. I'm not sure that's a good
design in 2018.

Regardless, you're right, I'm envisioning that we'd have a tool to
generate the data commits and PRs (or just commit + push directly).
PDC had included its own rudimentary form of version control for
auditing and message bus integration. Git's experience is much richer.

- Ken
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-leave@lists.fedoraproject.org