kraken-hpc / imageapi Goto Github PK

Currently, if we use a cascading call and it only partially completes we could leave orphaned mounts/attaches. This could be easily remedied by implementing some simple garbage collection that clears out allowable objects automatically.

...the issue is with how we call go-fork in the func init(), which ends up getting called for all makebb processes. Need to move go-fork logic into func main() somewhere, even though that risks tainting generted code.

...it's just good form

Need to tighten up the security, and this is an easy step.

Need to tighten up security.

The concept here is that you want to be able to create a referencable mount or device that natively exists on the underlying system without any real mount or attach taking place.

...the current version (even with patches) does a multi-stage login when it doesn't need to and forces unnecessary parameter negotiation.

One way to hande things like squash over NFS is to add /attach/loopback that sets up loopback devices to files.

...this example won't actually work on the latest versions.

We need some basic tests to provide CircleCI coverage

Add support to copy an RBD image, NFS squashfs file, etc from network storage to local ramdisk or node local storage, then loop mount and overlay as normal.

This will be useful for cases where an admin doesn't want the node to have a hard dependency on the network storage being up, and doesn't care about the increased boot time and load.

...mounts and attachments could be handled in a much more generic way through interfaces, and this will pay off as we add different mount/attach methods.

Currently, required modules must be independently loaded before imageapi starts.

It should be relatively easy for drivers to declare kernel modules they need, and to attempt to modprobe them on first use.

Allow images to run scripts at different stages of image lifecycle.

Grab & extract ramdisks and present them as mounts.

/hpc/imageapi?