* I kinda don't like the tree of files in git. It would work, but
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(a)ktdreyer.com> wrote:
On Sun, Apr 22, 2018 at 2:23 AM, Stanislav Ochotnicky
> The difference is that PDC rpm-mappings API endpoint was result of two
> * 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.
infrastructure mailing list -- infrastructure(a)lists.fedoraproject.org
To unsubscribe send an email to infrastructure-leave@lists.