-
Notifications
You must be signed in to change notification settings - Fork 249
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Remove opm registry serve
#1105
Comments
Notes from Tue 6th June operator framework meeting (see recording for more detail): Suggest to remove because it is diverging and has additional maintenance cost. Consumers who have not migrated to FBC could use the old OPM image for serving catalogs. It is easy to migrate an sqlite database to FBC to enable serving. Could we enable automatic migration and then just run the FBC serve? (concerns about implying that its ok for people to still use sqlite) Need to look more closely at the index commands, which make assumptions that there is an Note: If we are following semver, We'll need to rev the major version to 2.0.0 |
I did a quick experiment not long ago to see how much size I could take out of a catalog image by building just the FBC serve command from opm: https://github.com/jamstah/operator-registry/tree/opm-serve. It struck me that this could be a carrot for getting users to migrate to FBC in their catalogs - add an option for a smaller image but only if they use FBC. Might be overcomplicating things, but thought I'd share.
|
The sqlite-based commands in
opm
have been deprecated for almost two years. We know of some users still building sqlite-based catalogs, but they are also converting them to FBC and serving FBC.I propose that we remove the
opm registry serve
command so that we can avoid concerns around maintaining parity between the sqlite server (which is not receiving new features) and the FBC server (which is receiving new features).The text was updated successfully, but these errors were encountered: