You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
With the recent update of Flist v2 #1467, the flists can now be served from any location using the new self-contained format. However, users lose a crucial feature that was, in fact, overused—the Docker convert feature from the hub.
As a user, I would like to have a single binary (e.g., flist-server) that not only serves the new flists but can also be used to convert Docker images.
To Consider
Authorization: How to authorize the caller. I suggest maintaining a list of secrets that can be configured in a TOML file. toml is optional, can be anything
Conversion Process: How to handle the conversion. It is recommended to utilize the docker2fl tool (or the library). we should allow the user specify the registry, username, email or token to be able to pull the image from the registry. This enables the users to use their own private registries, which isn't possible in the current version of the hub, and also as a security measure because anyone on the hub can access all of the flists.
Backend Store: Consideration for the backend store.
Technology: The implementation should be in Rust.
The text was updated successfully, but these errors were encountered:
xmonader
changed the title
flist-server: serve flists and image conversion support
flist-server: serve flists with docker image conversion support
Dec 17, 2023
Imho the flist-server need to provide the following:
The user need to configure a (backend storage) that is supported by rfs and/or docker2fl.
This backend is then used during creation of the flist (from a tar upload, or docker conversion)
The flist-server also need to allow to server .fl files. Those can also be stored on disk and sever over http, since this does not scale, using an S3 storage (minio or something else) can give us the flexibility to scale or distribute. Again this should be configurable by the user based on the scale of his setup.
The server can also be configured to support multiple authentication backends. this can be
A configurable set of username/passwords
A username/password registration module.
Google login, github login, etc...
Should we support multiple ways?
As a start the authentication module can implement only one module of the above (say configurable list of usernames/passwords)
Once you are logged-in the user can see a hub like interface.
When the user upload a tar, or does a conversion, the blobs are pushed to backend storage and the fl is pushed to fl storage.
With the recent update of Flist v2 #1467, the flists can now be served from any location using the new self-contained format. However, users lose a crucial feature that was, in fact, overused—the Docker convert feature from the hub.
As a user, I would like to have a single binary (e.g.,
flist-server
) that not only serves the new flists but can also be used to convert Docker images.To Consider
Authorization: How to authorize the caller. I suggest maintaining a list of secrets that can be configured in a TOML file. toml is optional, can be anything
Conversion Process: How to handle the conversion. It is recommended to utilize the
docker2fl
tool (or the library). we should allow the user specify the registry, username, email or token to be able to pull the image from the registry. This enables the users to use their own private registries, which isn't possible in the current version of the hub, and also as a security measure because anyone on the hub can access all of the flists.Backend Store: Consideration for the backend store.
Technology: The implementation should be in Rust.
The text was updated successfully, but these errors were encountered: