We are delighted to share fresh and crisp updates on OpenRegistry.
We have created a roadmap which shares the current updates and short-term goals of the application. Our immediate and ongoing goal is Web-app development with which we are going to transform the UI with illustrations and a new Logo for OpenRegistry. Although the task is in progress, there is going to be a sneak-peek into what it looks like in the making.
Apart from Web-app, there are several more features being developed and researched on at the same time. This post attempts to cover a few of them in details
With current implementation of OpenRegistry, we support basic authentication with JWT which is used for user on-boarding (i.e registration for beta through email, sign-in user with supplied credentials).
We are working on incorporation more AuthN mechanisms starting with Github. With this, OpenRegistry can use federated authentication from Github and the user doesn’t have to manage yet another pair of credentials. This will make developer experience smooth and simple.
There are however a few roadblocks while implementing this feature, the docker CLI needs for user to login with username and password. Since there are no credentials involved with github sign-in, the docker login might need a separate set of credentials to be created just for docker CLI. There are however alternate ways to work around this, one of which is using github token(gho token) for user authentication with Docker CLI and we are currently working on the making this process easier to adopt.
As we have already shared in our previous discussions, we have started working on implementing pluggable storage backends which will give us the capability of incorporating any new/modern database with zero changes in code. The old implementation of OpenRegistry used Badger KV store as database layer. There are no limitations with Badger, not to mention the super fast-ness and ease of implementation but it fails to achieve our goals of data structuring and scalability.
For the same reasons, we need pluggable storage backends.
For starters, we have re-written the database with PostgreSQL by implementing a Storage interface which in future will allow us to augment more database solutions like a Graph DB/GraphQL. We worked on implementing DGraph before going with PostgreSQL however it didn’t quite work for us at the time. We will give it another try in near future.
As for Database, We are not storing the user related data like their container images, PII or any other traceable information whatsoever. We only map the links to the hashes (which look like:-
_AkiSyle93oG7OBJ6erWAPhKtPvrmJgskdjRimRtb75zRMp1Q) to user friendly image names like
All of our code is Open Source, and can be found here
Here is the first draft of our Roadmap. A complete visual representation of Milestones, Goals, Features and Sub-Featured for OpenRegistry. We will continue update this roadmap time to time by adding new features, updating the status of existing ones and marking them done once completed.
Last but not the least, Our new Web-app is about ready to be launched with a new release of Open-Registry with added and modified features for better developer experience.