3 ms·

The CoreOS Update Philosophy

37 points by thebeardisred 12y ago

quasse 12y ago
Here I was hoping to actually read about the update philosophies, but the linked page contains almost no content other than to say that Docker has been updated. If you're actually looking to read about them, they can be found here: http://coreos.com/using-coreos/updates/ http://coreos.com/using-coreos/updates/
- dang 12y ago
  Yes. We changed the url to that from https://coreos.com/blog/the-coreos-update-philosophy/ https://coreos.com/blog/the-coreos-update-philosophy/.
- thebeardisred 12y ago
  Sorry about that! If you've got questions about it, feel free to ask in this thread and we'll cover them.
js2 12y ago
We used Omaha at Rockmelt for both Mac and Windows, but of course we had to write our own backend since Google doesn't open source that part. I assume you guys had to do the same? Which repo contains the update server? I found https://github.com/coreos/go-omaha https://github.com/coreos/go-omaha but it's just the protocol.
- robszumski 12y ago
  Very interested to hear about your usage of Omaha... How was your overall experience? What's your process for promoting a release? Do you ship in channels per platform? What steps does your updater take when it installs a package?
  - js2 12y ago
    We used channels but only to separate our internal builds. All our externally released versions were on a single channel (well, one channel for Mac, another for Windows as I recall). We released a new version by rolling it out to 1% of our users and watching the crash rate, then 5%, etc, till we were at 100%. Our 1.0 product was based on Chromium, so we mostly re-used Chromium code on the client-side (Mac, Windows) as far as how the updater worked.
    - robszumski 12y ago
      Sounds like a similar situation on our side. We use a minimally modified updater from ChromeOS and have built some tools into the Omaha server to do rate-limited updates to the population of machines and track error rates in the same fashion.
- robszumski 12y ago
  There is an open-source implementation [1] of the server within the CoreOS SDK [2], but it's only meant for development. A different closed-source code base runs in production that handles scale. [1] https://github.com/coreos/dev-util/blob/master/devserver.py https://github.com/coreos/dev-util/blob/master/devserver.py [2] http://coreos.com/docs/sdk-distributors/sdk/modifying-coreos/ http://coreos.com/docs/sdk-distributors/sdk/modifying-coreos...
lfam 12y ago
FreeBSD offers an embedded version called nanobsd that seems to use the same update "philosophy". It's actually nanobsd.sh, a shell script by Poul-Henning Kamp. So, that IS open source, although I doubt it's GPL ;) http://www.freebsd.org/cgi/man.cgi?query=nanobsd http://www.freebsd.org/cgi/man.cgi?query=nanobsd

37 points by thebeardisred 12y ago

Here I was hoping to actually read about the update philosophies, but the linked page contains almost no content other than to say that Docker has been updated. If you're actually looking to read about them, they can be found here: http://coreos.com/using-coreos/updates/ http://coreos.com/using-coreos/updates/

dang 12y ago
Yes. We changed the url to that from https://coreos.com/blog/the-coreos-update-philosophy/ https://coreos.com/blog/the-coreos-update-philosophy/.
thebeardisred 12y ago
Sorry about that! If you've got questions about it, feel free to ask in this thread and we'll cover them.

js2 12y ago

We used Omaha at Rockmelt for both Mac and Windows, but of course we had to write our own backend since Google doesn't open source that part. I assume you guys had to do the same? Which repo contains the update server? I found https://github.com/coreos/go-omaha https://github.com/coreos/go-omaha but it's just the protocol.

robszumski 12y ago
Very interested to hear about your usage of Omaha... How was your overall experience? What's your process for promoting a release? Do you ship in channels per platform? What steps does your updater take when it installs a package?
- js2 12y ago
  We used channels but only to separate our internal builds. All our externally released versions were on a single channel (well, one channel for Mac, another for Windows as I recall). We released a new version by rolling it out to 1% of our users and watching the crash rate, then 5%, etc, till we were at 100%. Our 1.0 product was based on Chromium, so we mostly re-used Chromium code on the client-side (Mac, Windows) as far as how the updater worked.
  - robszumski 12y ago
    Sounds like a similar situation on our side. We use a minimally modified updater from ChromeOS and have built some tools into the Omaha server to do rate-limited updates to the population of machines and track error rates in the same fashion.
robszumski 12y ago
There is an open-source implementation [1] of the server within the CoreOS SDK [2], but it's only meant for development. A different closed-source code base runs in production that handles scale. [1] https://github.com/coreos/dev-util/blob/master/devserver.py https://github.com/coreos/dev-util/blob/master/devserver.py [2] http://coreos.com/docs/sdk-distributors/sdk/modifying-coreos/ http://coreos.com/docs/sdk-distributors/sdk/modifying-coreos...

lfam 12y ago

FreeBSD offers an embedded version called nanobsd that seems to use the same update "philosophy". It's actually nanobsd.sh, a shell script by Poul-Henning Kamp. So, that IS open source, although I doubt it's GPL ;) http://www.freebsd.org/cgi/man.cgi?query=nanobsd http://www.freebsd.org/cgi/man.cgi?query=nanobsd