Skip to content
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

[RFE] Allow fetching older flatcar packages when starting from scratch #591

Open
ffilippopoulos opened this issue Mar 31, 2022 · 5 comments

Comments

@ffilippopoulos
Copy link

Current situation

We have a case, after losing our postgres instance backing nebraska, where we want to start a fresh deployment that serves different packages to different groups. In this scenario, we want only our lower environments to run on latest flatcar, while keeping our production ones on previous versions until we are ready to update. For that purpose we create separate groups per environment and pin them to specific version and arch. As I understand, when deploying nebraska from scratch there is no option to fetch older packages and the only packages available can come from the current content of: https://public.update.flatcar-linux.net/v1/update/ (using default config)

I see that there is a sync-update-url url flag that one can use to trigger nebraska to sync from a different source than: https://public.update.flatcar-linux.net/v1/update/. From what I understand, this will allow us to run our own omaha server and serve older packages to cater for our prod. But still we'd have to maintain a separate nebraska deployment per environment at least as long as babysit our custom omaha servers.

Impact

This behaviour makes the postgres deployment more precious than it should be, holding state that could also be retrieved from public channels.

Ideal future situation

This is to propose adding a new flag that would allow nebraska to fetch older package info at startup. I do not know exactly what is going to be the source of truth, maybe: https://www.flatcar.org/releases-json/releases.json.

Additional information

If that is something completely out of the design scope, would there be a suggested workaround to achieve what we want here?

Thank you very much in advance!

@pothos
Copy link
Member

pothos commented Apr 1, 2022

Maybe a helper script can be used to populate the DB, see https://github.com/flatcar-linux/flatcar-build-scripts/blob/master/upload_package where you can throw away the ssh/scp part and only use the package registration based on the files like https://update.release.flatcar-linux.net/amd64-usr/3033.2.4/flatcar_production_update.gz - currently the sha1 checksum needs to be calculated but sha256 is in the checksum file, such as https://update.release.flatcar-linux.net/amd64-usr/3033.2.4/flatcar_production_update.gz.sha256

@george-angel
Copy link

Hey @pothos thanks, we can do it that way, we were hoping to gauge the appetite for having this functionality in Nebraska itself, to minimise random scripts on our side.

We are happy to PR if it sounds good / useful in principal. If you feel like its out of scope / doesn't belong / not useful - we'll work on some workaround on our side.

Thanks!

@pothos
Copy link
Member

pothos commented Apr 1, 2022

I think it makes more sense as a helper script in the Nebraska repo, which gets a list of Flatcar releases to register. Other ideas @joaquimrocha?

@joaquimrocha
Copy link
Collaborator

Yes. I think this is something we should have as an external helper. Still in the repo, but as a separate script that uses the rest API.

@george-angel
Copy link

Hello! We have ended up solving this with a generic Postgres backup / restore approach and so didn't need or implement a script to load existing packages via Nebraska API.

Feel free to close this issue if you prefer, we will not be working on this script for now.

Thank you for help and support.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants