solus-project/ferryd

Fast, safe and reliable transit for the delivery of software updates to users.

ferryd's Issues

Logo in Readme is Broken

it's returning an error, Cannot proxy the given URL.

Add ability to promote packages (incl deps)

One of the last standing issues with getting packages to users is now security updates outside of the standard repo syncs, or quick fixes to problems not spotted prior to sync e.g. https://dev.solus-project.com/T4575

• Seeing the full list of promoted packages before hand would be important, so we can validate the revdeps are safe to push (where the full repo may not be properly tested or in a sync state). It maybe that waiting for a full sync is a better option in some circumstances.
• Validating the repo (all packages can be installed, including release numbers), so a partial push doesn't create issues. Whether this is a part of ferryd or elsewhere.

Rework libdb to return Connection handle

We should have a simple system in place that returns a connection handle for a given duration (i.e. batched functions) and is then later closed. When the last connection is closed, set the connection count to 0, and after some timeout, close the underlying database connection again. This will help to ensure that leveldb memory is reclaimed and ensure recovery, etc, all work properly.

Without this, our memory usage is going to keep growing unbounded.

Use pool caching for deltas

Due to the sync/async/sync -> sync/async changes we have a lot of specialist code within the delta job.
This means we're always creating new deltas - we first need to check if the delta ID exists within the pool, and ref that. Otherwise we can just create and then ref.

Spawn async delta creation on pull

The delta repo job is fairly slow as it has to check every package in the repo, and is only really intended to be used after initial import. During a pull operation, track the names in the repo that are being modified, and then spawn a delta job for each one of them on the async queue.

This will greatly reduce the time it takes to delta the repo after sync windows.

attempt conversion to gorm/sqlite

tldr boltdb is really, really bad for concurrency.

Establish a simpler model that gets rid of all the bucket-orientated logic, and rely on many to many relationships:

struct RepoEntry {
    Repository Repository
    Published Package
    Packages []Package ..
    Deltas []Package
}

Basically rip out all the current boltdb crap, start a new subproject to test the data storage.

Actually implement this

Long story short I'm pulling me hair out with how long each repo settle is taking. This needs implementing immediately ..

In order of Things To Make It All Work:

• Add basic .eopkg add support (cache into pool and repo storage)
• Add eopkg-index.xml write support (stable sort + constant time emission)
• Add components.xml distribution.xml groups.xml merge support
• Add compression and validation files (.xz .sha1sum)
• Hook in deltas
• Throw the entire repo at it and ensure constant time is still true
• Now add the monitor
• Profit $$$

PullRepo should not delta

If we do a pull that results in 320 jobs, and average each sync job as ~11s, this is an hour added for no reason. Sure, it might not always index because deltas existing or not needed, but still, optimise it.

Just swap it out for a DeltaJob and then we can manually index it once status shows it done.

Marking it here so i don't actually forget..