API and service for importer

[ctron]

Right now, one can run the importer from the command line. We already talked about having that as a core service.

My proposal is to transform/enhance the current importer, making it a service which has:

• An API to for creating new import jobs (CRUD): CSAF/SBOM, schedule, status
• Create a continuously-running version of the importer, polling the schedule, making progress on imports
• Add this to the "server" crate in way that the actual importing process can be enabled/disabled as a module, but the API is always present

The importer would re-use the existing internal APIs (Rust, not HTTP).

[ctron]

A first PR: #75

[bobmcwhirter]

Agreed, with one possible exception...

Maybe we consider server crate to be the REST server, and... add another that runs that + the non-HTTP-facing services?

[ctron]

Yes, I was wondering about that too. "server" seems to be a bit too generic IMHO. I think we have two components: "a process running all services" and "a service running the http endpoints". In addition to "a service running the importer loop".

Being bad at naming things, I have no idea how to name them.

Run previous discussions I would expect that we have the ability:

• to run all services/modules in a single process
• to (later on) run each service/module individually (from the same binary)

[bobmcwhirter]

Naming is indeed hard.

Howsabout api-server for the REST stuff, and trustd for The One Engine To Rule Them All?

[bobmcwhirter]

and somewhere in importer would be the loop-de-loop for them?