kinvolk/nebraska

Update monitor & manager for applications using the Omaha protocol, optimized for Flatcar Container Linux.

Nebraska

Nebraska is an update manager for Flatcar Container Linux.

Overview

Nebraska offers an easy way to monitor and manage the rollout of updates to applications that use the Omaha protocol, with special functionality for Flatcar Container Linux updates.

Features

• Monitor and control application updates;
• Optimized for serving updates to Flatcar Container Linux;
• Automatically fetch new Flatcar Container Linux updates;
• Store and serve Flatcar Container Linux payloads (optional);
• Compatible with any applications that use the Omaha protocol;
• Define groups, channels, and packages;
• Control what updates are rolled out for which instance groups, as well as when and how they are updates;
• Pause/resume updates at any time;
• Statistics about the versions installed for instances, status history, and updates progress, etc.;
• Activity timeline to quickly see important events or errors;

Screenshots

Issues

Please report any issues in here.

Code of Conduct

We follow the CNCF Code of Conduct.

Please contact private Maintainer mailing list or the Cloud Native Foundation mediator, [email protected], to report an issue.

Contributing

If you want to start contributing to Nebraska, please check out the contributing documentation.

Development

For a quickstart on setting up a development environment, please check the development documentation.

User Access

For instructions on how to set up user access, please check the authorization documentation.

License

Nebraska is released under the terms of the Apache 2.0, and was forked from the CoreRoller project.

nebraska's Issues

Check if some optional relationships can affect metrics

To get the application instances per channel metric, coreroller joins four tables: application, instance_application, groups and channel. The relationship betweeen instance_application and groups and between groups and channel is that the former optionally references the latter:

• https://github.com/kinvolk/coreroller/blob/059e188c4758c4874915ff6459d903fb9663bf1a/pkg/api/db/migrations/0001_initial.sql#L120
• https://github.com/kinvolk/coreroller/blob/059e188c4758c4874915ff6459d903fb9663bf1a/pkg/api/db/migrations/0001_initial.sql#L91

What needs to be done is:

• investigate is if it is possible to for those relationships to become nulled (in the frontend, for example)
• decide if the relationships can be nulled
• document those relationships maybe
• if we decide that some relationships can be nulled then likely the generation of the metrics needs to be amended, so the query still returns all the application instances, but likely some of them with a null channel, for example.

-enable-syncer doesn't work out of the box

Sep 24 15:17:03 ip-172-20-9-222 systemd[1]: Started Nebraska.
Sep 24 15:17:04 ip-172-20-9-222 docker[2669]: {"_t":"2019-09-24T15:17:04+0000", "_p":"1", "_l":"INF", "_n":"dat:sqlx", "_m":"Query time", "elapsed":"1.91489ms", "sql":"select setting from pg_settings where name='standard_conforming_strings'"}
Sep 24 15:17:04 ip-172-20-9-222 docker[2669]: {"_t":"2019-09-24T15:17:04+0000", "_p":"1", "_l":"INF", "_n":"dat:sqlx", "_m":"Query time", "elapsed":"1.36534ms", "sql":"SHOW server_version_num"}
Sep 24 15:17:04 ip-172-20-9-222 docker[2669]: {"_t":"2019-09-24T15:17:04+0000", "_p":"1", "_l":"INF", "_n":"dat:sqlx", "_m":"Query time", "elapsed":"6.594847ms", "sql":"SELECT row_to_json(dat__item.*) FROM ( SELECT id, name, description, created_ts, (SELECT array_agg(dat__groups.*) FROM (SELECT *, (SELECT array_agg(dat__version_breakdown.*) FROM (\n\tSELECT version, count(*) as instances, (count(*) * 100.0 / total) as percentage\n\tFROM instance_application, (\n\t\tSELECT count(*) as total \n\t\tFROM instance_application \n\t\tWHERE group_id=groups.id AND last_check_for_updates \u003e now() at time zone 'utc' - interval '1 days'\n\t\t) totals\n\tWHERE group_id=groups.id AND last_check_for_updates \u003e now() at time zone 'utc' - interval '1 days'\n\tGROUP BY version, total\n\tORDER BY regexp_matches(version, '(\\d+)\\.(\\d+)\\.(\\d+)')::int[] DESC\n\t) AS dat__version_breakdown) AS \"version_breakdown\", (SELECT row_to_json(dat__instances_stats.*) FROM (\n\tSELECT\n\t\tcount(*) total,\n\t\tsum(case when status IS NULL then 1 else 0 end) undefined,\n\t\tsum(case when status = 3 then 1 else 0 end) error,\n\t\tsum(case when status = 2 then 1 else 0 end) update_granted,\n\t\tsum(case when status = 4 then 1 else 0 end) complete,\n\t\tsum(case when status = 5 then 1 else 0 end) installed,\n\t\tsum(case when status = 6 then 1 else 0 end) downloaded,\n\t\tsum(case when status = 7 then 1 else 0 end) downloading,\n\t\tsum(case when status = 8 then 1 else 0 end) onhold\n\tFROM instance_application\n\tWHERE group_id=groups.id AND last_check_for_updates \u003e now() at time zone 'utc' - interval '1 days') AS dat__instances_stats) AS \"instances_stats\", (SELECT row_to_json(dat__channel.*) FROM (SELECT *, (SELECT row_to_json(dat__package.*) FROM (SELECT \n\t\t\tpackage.*, \n\t\t\tarray_agg(pcb.channel_id) FILTER (WHERE pcb.channel_id IS NOT NULL) as channels_blacklist\n\t\t, (SELECT row_to_json(dat__coreos_action.*) FROM (SELECT * FROM coreos_action WHERE package_id = package.id) AS dat__coreos_action) AS \"coreos_action\" FROM package LEFT JOIN package_channel_blacklist pcb ON package.id = pcb.package_id WHERE (package.id = channel.package_id) GROUP BY package.id ORDER BY regexp_matches(version, '(\\d+)\\.(\\d+)\\.(\\d+)')::int[] DESC) AS dat__package) AS \"package\" FROM channel WHERE (id = groups.channel_id) ORDER BY name ASC) AS dat__channel) AS \"channel\" FROM groups WHERE (application_id = application.id) ORDER BY created_ts DESC) AS dat__groups) AS \"groups\", (SELECT array_agg(dat__channels.*) FROM (SELECT *, (SELECT row_to_json(dat__package.*) FROM (SELECT \n\t\t\tpackage.*, \n\t\t\tarray_agg(pcb.channel_id) FILTER (WHERE pcb.channel_id IS NOT NULL) as channels_blacklist\n\t\t, (SELECT row_to_json(dat__coreos_action.*) FROM (SELECT * FROM coreos_action WHERE package_id = package.id) AS dat__coreos_action) AS \"coreos_action\" FROM package LEFT JOIN package_channel_blacklist pcb ON package.id = pcb.package_id WHERE (package.id = channel.package_id) GROUP BY package.id ORDER BY regexp_matches(version, '(\\d+)\\.(\\d+)\\.(\\d+)')::int[] DESC) AS dat__package) AS \"package\" FROM channel WHERE (application_id = application.id) ORDER BY name ASC) AS dat__channels) AS \"channels\", (SELECT array_agg(dat__packages.*) FROM (SELECT \n\t\t\tpackage.*, \n\t\t\tarray_agg(pcb.channel_id) FILTER (WHERE pcb.channel_id IS NOT NULL) as channels_blacklist\n\t\t, (SELECT row_to_json(dat__coreos_action.*) FROM (SELECT * FROM coreos_action WHERE package_id = package.id) AS dat__coreos_action) AS \"coreos_action\" FROM package LEFT JOIN package_channel_blacklist pcb ON package.id = pcb.package_id WHERE (application_id = application.id) GROUP BY package.id ORDER BY regexp_matches(version, '(\\d+)\\.(\\d+)\\.(\\d+)')::int[] DESC) AS dat__packages) AS \"packages\", (SELECT row_to_json(dat__instances.*) FROM (\n\tSELECT count(*)\n\tFROM instance_application \n\tWHERE application_id = application.id AND \n\t      last_check_for_updates \u003e now() at time zone 'utc' - interval '1 days'\n\t) AS dat__instances) AS \"instances\" FROM application WHERE (id = '{e96281a6-d1af-4bde-9a0a-97b76e56dc57}') ORDER BY created_ts DESC) as dat__item"}
Sep 24 15:17:04 ip-172-20-9-222 docker[2669]: {"_t":"2019-09-24T15:17:04+0000", "_p":"1", "_l":"ERR", "_n":"rollerd", "_m":"sql: no rows in result set"}
Sep 24 15:17:04 ip-172-20-9-222 systemd[1]: nebraska.service: Main process exited, code=exited, status=1/FAILURE
Sep 24 15:17:04 ip-172-20-9-222 systemd[1]: nebraska.service: Failed with result 'exit-code'.

Nebraska should work w/o any "sample data" in the database. Required data should be applied through a migration. A freshly installed instance should work with -enable-syncer and be usable out of the box.

Use prometheus client library for generating metrics

#8 adds metrics for prometheus, but currently I'm generating them myself with fmt.Fprintf. We should consider using https://github.com/prometheus/client_golang instead.

Include instances that have reported nothing in the progress

As you may have noticed, the percentages in the group's Update Progress do not sum up to 100%. This is because I have not included a circle graph for the instances that are connected but have not reported any events yet.

I can easily include that chart, but it will no longer be able to easily fit nicely in visual terms. I think the best solution for this would be to put it under the current instance count label, so at least it'd be aligned with it (or rather, move the "complete" chart to under that count label). Like the mockup here:

Reduce size of bundle / Add CRA-rewired

From Webpack:

WARNING in asset size limit: The following asset(s) exceed the recommended size limit (244 KiB).
This can impact web performance.
Assets:
main.js (1.46 MiB)

WARNING in entrypoint size limit: The following entrypoint(s) combined asset size exceeds the recommended limit (244 KiB). This can impact web performance.
Entrypoints:
main (1.46 MiB)
main.js

WARNING in webpack performance recommendations:
You can limit the size of your bundles by using import() or require.ensure to lazy load some parts of your application.
For more info visit https://webpack.js.org/guides/code-splitting/

So we should fix it, and probably a good way to do it is to integrate create-react-app (rewired) to the project.

Ban caching of index.html

Applicable after #16 is merged.

Currently browsers can cache index.html and that breaks the authentication a bit - if the page is cached and we are not authenticated we are likely to end up with a blank page, because browser renders the cached index.html and fetches just some css files from rollerd. The browser won't get them but it also won't redirect the user to the github.

Auto-complete list of packages when adding them to a channel

Showing the full list of packages in a select popup when adding assigning a package to a channel is a bit overwhelming and may cause performance issues depending on the number of packages, so this view should be replaced by an auto-complete popup (like the timezones' picker).

Here is the issue:

Add explanation widget to unclear form options

When creating a group, users can choose options like: safe update, only office hours, etc.
These options, also having a helper text, are not very clear to users initially, so we should add a popup or dialog explaining that.

Allow using multiple teams

Applicable after #16 is merged.

Currently when we log in, we pick up a single coreroller team (based on the github organization and team) and manage the applications maintained by that team only. Would be nice if after logging in, we could use all the coreroller teams that match all the github organizations and teams the user is member of.

Configurable oauth endpoints

Applicable after #16 is merged.

Currently it is hardcoded to github. @schu mentioned using dex.

Create Group detailed charts page

Currently Nebraska is only showing a quick progress of the versions + states for each group.
Any other info about the past and current states of the instances associated with the group is only available in a table.

We should implement a page to show all this info in a more organized state using charts, e.g.:
% of instances downloading
% of instances up to date
etc.

A detailed requirements doc is TBD.

Update and consolidate auth documentation

https://github.com/kinvolk/nebraska/blob/master/cmd/rollerd/README.md needs an update after we made the decision to not support groups in Nebraska.

I would also suggest we move the document to docs/auth.md or similar.

Allow to modify group from the extended view

When in the group extended view, it should be possible to edit the group, just like in the group list.

APP_ID for edge channel does not work

Currently on our coreroller UI, https://public.update.flatcar-linux.net, an edge channel is visible. That's just a manually created APP_ID.

When testing from any Flatcar machine, update_engine_client -update is not able to get the machine updated to the edge channel, when /etc/flatcar/update.conf has GROUP=edge. OTOH, it works fine when the GROUP is set to one of the other channels.

Probably we need to change the following code in coreroller.
https://github.com/kinvolk/coreroller/blob/059e188c4758c4874915ff6459d903fb9663bf1a/pkg/omaha/omaha.go#L20..L24

Update Omaha Go pkg

The Omaha Go package used in Nebraska is very old and unmaintained. We should replace it by a more up to date package.

Investigation TBD.

Cache the metrics

Instead of querying metrics from the database every time someone sends a request to /metrics endpoint, try to cache them. Basically have a cache that is updated at some (likely configurable) interval and then serve the contents of the cache on each request for metrics.

Make it clear that the data is from 1 day

Nebraska works by showing the info about instances' past events and by default shows it with an interval of 1 day.
However, this is not explicit anywhere in the UI, so we should add this note there.

Ideally we'll have #72 which fixes this issue too, but as an easier first step we can solve this one.

Remove Nivo dependency

Nivo is a charts library and it's being used for the stacked progress bar we have in the VersionBreakdown.
Even though the results are nice, I found it a bit complicated to customize out of the patterns it expects, e.g. the progress circle chart for #35 was getting very complicated to accomplish with Nivo, and with Victory it was much easier.

Victory also has many charts and it's more mature + used more, so I propose removing Nivo altogether and (hopefully) just use Victory.

Review the golang packages we use

Related to #70 and #34.

The "nothing fancy" or "quick wins" packages:

• github.com/blang/semver

  • Semver parser.
  • We should update it to github.com/blang/semver/v4, it's the release that's compatible with go modules.

• gopkg.in/fatih/set.v0

  • Just a set library. It's an archived and unmaintained project.
  • Just write our own set difference function.

• github.com/satori/go.uuid

  • Uuid generator and stuff.
  • Using latest release already.
  • Unmaintained and buggy, needs replacing.

The database packages:

• github.com/jmoiron/sqlx

  • Extended golang's database/sql.
  • Already updated to latest release. We will see if we need it when
    we decide on new ORM.
  • The goqu package also provides some wrappers around database/sql,
    which we don't currently use. We could see if goqu could replace this
    package.

• github.com/lib/pq

  • Postgresql driver.
  • Already at latest release.
  • Replaced with https://github.com/jackc/pgx

• github.com/rubenv/sql-migrate

  • Schema migration thingy.
  • Could be updated, there are no releases, though.

• gopkg.in/mgutz/dat.v1

  • That's an ORM, basically.
  • Alternatives:
    • https://github.com/jinzhu/gorm
    • https://github.com/go-pg/pg
  • We went with https://github.com/doug-martin/goqu

The web framework packages:

• github.com/ymichael/sessions

  • Related to the goji framework, so see below

• github.com/zenazn/goji

  • A web framework.
  • So. Many. Web. Frameworks.
  • https://github.com/mingrammer/go-web-framework-stars

Other packages:

• github.com/aquam8/go-omaha

  • Should use github.com/coreos/go-omaha or our own fork.

• github.com/facebookgo/grace

  • Used only in the demo.
  • Consider making the demo a separate module maybe.

• github.com/google/go-github

  • Library for talking to github.
  • Needs updating.

• github.com/mgutz/logxi

  • A logging solution.
  • Use logrus or glog.

• github.com/stretchr/testify

  • Some testing helpers.
  • Already using the latest release.
  • Do we want to use something else?

• golang.org/x/oauth2

  • Client for oauth2.
  • There are no releases, could bump it to latest revision.

Revisit Empty states

The empty states (when there are no groups, instances, etc.) are pretty dull ATM. They should show something more useful, like linking to docs + have a highlighted "Add" button.

Update README to reflect changes

Currently the README is woefully out of sync with the changes. In order for others to understand be able to understand the project and get started with testing, contributing and using Nebraska we should fix this.

Create an Instance view

The only way to see what is going on an instance is to check the list view in the Group detailed view. However, it'd be great if we should offer a more detailed view into the events related to an instance an maybe even show a version chart for it too.

A requirements doc is TBD.

Configurable store for sessions

Applicable after #16 is merged.

Sessions library we are using allows storing sessions in memory (that's what we have hardcoded for now) or in a redis instance. I think that the upside of using redis is the session expiration.

This could be configurable.

Add links from the instance status charts to the instance page

We should have a link from the status charts in the group details page to the instance list view. The idea is that the link sends the user directly to the instance list view but with the fliters already set up according to the status that was selected (e.g. "Complete" instances).

Use postgresql driver other than gopkg.in/dat.v1

At the moment Nebraska relies heavily on gopkg.in/dat.v1 for communicating with its Postgresql database. That's inherited from the coreroller era.

However, both dat and logxi, its logging library, are not maintained since many years. So it's not possible to migrate dependent projects to Go modules, and it's unlikely that any upstream PRs against the projects could be merged.

We need to think about an option to replace dat with a Postgres driver which is widely used and actively developed, for example:

• https://github.com/jackc/pgx
• https://github.com/lib/pq

Handle github subteams

On github teams can have subteams, which can likely have subsubteams and so on. For such teams, their coreroller counterpart should be likely named <ORG>/<TEAM>/<SUBTEAM>/<SUBSUBTEAM>/…

Add CLI

Like updateservicectl we should investigate how to provide a CLI for Nebraska, either by modifying https://github.com/coreos/updateservicectl or by providing a new tool.

The motivation would be to easily list and retrieve the update payloads from the command-line.

Update react and other JS and CSS libraries to new versions

Setup CI

We will likely want to setup travis as we already have a travis config file in the tree.

While doing it, the config file could be tweaked to not use the coreroller/postgres, but maybe use upstream postgres docker image. @schu ran the tests as follows:

docker run --rm --name coreroller-test-postgres -p 5432:5432 -d postgres
psql -h localhost -U postgres -c 'create database coreroller'
psql -h localhost -U postgres -c 'create database coreroller_tests'
go test -p 1 ./...

coreroller/postgres creates the database in its entrypoint:

    gosu postgres psql -c "CREATE DATABASE coreroller;"
    gosu postgres psql -c "ALTER DATABASE coreroller SET TIMEZONE = 'UTC';"

    gosu postgres psql -c "CREATE DATABASE coreroller_tests;"
    gosu postgres psql -c "ALTER DATABASE coreroller_tests SET TIMEZONE = 'UTC';"

Investigate if we will need to extend the contents of the `event_type` table

The event_type table has 4 columns - id, event type, event result and a human-readable description. Event type and event result come from the omaha protocol. For more information about them see here: https://github.com/google/omaha/blob/master/doc/ServerProtocolV3.md#event-request

In short there are 30 event types and 11 event results. On top of that, coreroller apparently defines an extra event type of numerical value 800 which is about an update being prevented by an instance in some way. That gives 341 combinations of event types and event results. Of course, not every pair makes sense. Most likely, a majority of them does not make sense. Still, currently the event_type table (which has a misleading name, because it is not an omaha event type thing) lists mere 6 combinations:

-- Event types
insert into event_type (type, result, description) values (3, 0, 'Instance reported an error during an update step.');
insert into event_type (type, result, description) values (3, 1, 'Updater has processed and applied package.');
insert into event_type (type, result, description) values (3, 2, 'Instances upgraded to current channel version.');
insert into event_type (type, result, description) values (13, 1, 'Downloading latest version.');
insert into event_type (type, result, description) values (14, 1, 'Update package arrived successfully.');
insert into event_type (type, result, description) values (800, 1, 'Install success. Update completion prevented by instance.');

Possibly these are all the combinations of event type and event result that an updater of Container Linux/Flatcar Linux uses, but if we want coreroller to become more generic as a part of our offering, we will likely need to add more of them. Or rethink this event_type table.

Note that rollerd expects that whatever combination of event type and event result it receives over the omaha protocols exists in the event_type table.

Add number of instances info to the progress charts

In the group's update progress section, the charts are showing the percentage of instances in a certain state. It would be nice to show the actual number of machines that are in that state. Maybe on hover, with a chart tooltip.

Building a frontend gives a scary message about multiple vulnerabilities

npm prints a following message: found 40 vulnerabilities (14 low, 16 moderate, 7 high, 3 critical)

For more details do make frontend && cd frontend && npm audit.

Switch to a trusted source for go-bindata (or switch to an alternative tool)

Alternatives I know of are (in no particular order):

• https://github.com/gobuffalo/packr
• https://github.com/rakyll/statik
• https://github.com/mjibson/esc

Support a "letter" as the Group avatar

Currently we have group avatars as simple colored circles. While this is fine for many users, it is a problem for color-blind users, and in general it's easier to identify groups if we add a letter/symbol to them.

This requires:

1. Another field for writing the unicode symbol/letter
2. Computing a symbol's color that contrasts well with the avatar color (this can be done automatically using something like https://github.com/moroshko/accessible-colors ).

Make layouts responsive

The layouts are not set up to be responsive because of the extra testing required for it.
But we should planning on doing this work now that most of the core changes are getting tackled.
So let's track it here.

List Flatcar package types with the right logos

Even though Nebraska allows to add Flatcar type packages, these are still getting listed with the CoreOS name and logo.

Flatcar's logo is here.

Update the UI theme

Add group initial as group avatar

The context/reason for this is the same as #35 but this one is supposed to be an easier 1st step by just taking the group name's first letter.

As part of this ticket we should also improve the way that the color picker button is being set up. Instead of a quirky squarish looking button, it should possibly be the avatar itself, so it's serve as a preview too. Bonus points if that avatar picker displays the letter as the user edits the name.

Limit the height of the activity section

The activity section grows in height with the number of "activities", so if those are a lot, that section is just huge.

We should limit that height by showing only the latest N, and have a "Show all" link if the user wants to see more.

UI: Fix alignment for short-text activities

Activities with entries that have short text don't look very well since the entries are vertically aligned to the center. We should align them to the top.

Make syncer look for Flatcar

Nebraska has the possibility of creating packages auomatically when a new version of CoreOS is available. It should of course instead get the flatcar update load.

`TestGetUpdatePackage_MaxTimedOutUpdatesLimitReached` can be a bit flaky?

I've got a failure once:

--- FAIL: TestGetUpdatePackage_MaxTimedOutUpdatesLimitReached (1.13s)
        Error Trace:    updates_test.go:177
        Error:      	Not equal: 
                    	expected: *errors.errorString(&errors.errorString{s:"coreroller: max concurrent updates limit reached"})
                    	actual  : <nil>(<nil>)
        Test:       	TestGetUpdatePackage_MaxTimedOutUpdatesLimitReached
FAIL

Running the test again succeeded, so I suppose the error was because of a flaky test.

Second update request unexpectedly returns updateInProgressOnInstance

When sending a first request to the update server the response is the new version as expected. However, subsequent requests show error-updateInProgressOnInstance which is not consistent with CoreOS' CoreUpdate.

How to reproduce

Using this request file:

<?xml version="1.0" encoding="UTF-8"?>
<request protocol="3.0" version="update_engine-0.4.10" updaterversion="update_engine-0.4.10" installsource="scheduler" ismachine="1">
    <os version="Chateau" platform="CoreOS" sp="2191.0.0_x86_64"></os>
    <app appid="{e96281a6-d1af-4bde-9a0a-97b76e56dc57}" version="2191.0.0" track="alpha" bootid="{90b0e235-2b50-4a0e-9619-bc014ca2fcfd}" oem="" oemversion="" alephversion="2191.0.0" machineid="592cfdb69c7f4a29a6b361b60cedd954" lang="en-US" board="amd64-usr" hardware_class="" delta_okay="false" >
        <ping active="1"></ping>
        <updatecheck></updatecheck>
        <event eventtype="3" eventresult="2" previousversion="0.0.0.0"></event>
    </app>
</request>
</xml>
</details>

Nebraska behavior

core@flatcar-01 ~ $ curl -s -X POST -d @request.xml https://public.update.flatcar-linux.net/v1/update/ | xmllint --pretty 1 -
<?xml version="1.0"?>
<response protocol="3.0" server="coreroller">
  <daystart elapsed_seconds="0"/>
  <app appid="{e96281a6-d1af-4bde-9a0a-97b76e56dc57}" version="2191.0.0" status="ok" track="alpha">
    <ping status="ok"/>
    <updatecheck status="ok">
      <urls>
        <url codebase="https://update.release.flatcar-linux.net/amd64-usr/2275.0.0/"/>
      </urls>
      <manifest version="2275.0.0">
        <packages>
          <package hash="Xh+rt5I8pFTDVj1j+eKlt85JsKE=" name="flatcar_production_update.gz" size="466774008" required="true"/>
        </packages>
        <actions>
          <action event="postinstall" ChromeOSVersion="" sha256="mHsavz23FdX0uvlF1NHHcpJz2HU9qY33eoyC1Y6F+2Q=" needsadmin="false" IsDelta="false" DisablePayloadBackoff="true"/>
        </actions>
      </manifest>
    </updatecheck>
    <event status="ok"/>
  </app>
</response>
core@flatcar-01 ~ $ curl -s -X POST -d @request.xml https://public.update.flatcar-linux.net/v1/update/ | xmllint --pretty 1 -
<?xml version="1.0"?>
<response protocol="3.0" server="coreroller">
  <daystart elapsed_seconds="0"/>
  <app appid="{e96281a6-d1af-4bde-9a0a-97b76e56dc57}" version="2191.0.0" status="error-updateInProgressOnInstance" track="alpha">
    <ping status="ok"/>
    <event status="ok"/>
  </app>
</response>

CoreUpdate behavior

core@flatcar-01 ~ $ curl -X POST -d @request.xml https://public.update.core-os.net/v1/update/
<?xml version="1.0" encoding="UTF-8"?>
<response protocol="3.0" server="update.core-os.net">
 <daystart elapsed_seconds="0"></daystart>
 <app appid="e96281a6-d1af-4bde-9a0a-97b76e56dc57" status="ok">
  <updatecheck status="ok">
   <urls>
    <url codebase="https://update.release.core-os.net/amd64-usr/2275.0.0/"></url>
   </urls>
   <manifest version="2275.0.0">
    <packages>
     <package name="update.gz" hash="2dePfsufko+c0o/OJOG2VHzf0OA=" hash_sha256="xLPJ8UYxT4ywyn34JIKe1q23/9/GNDJhMQ8AMe3nBBw=" size="467681292" required="false"></package>
    </packages>
    <actions>
     <action event="postinstall" sha256="xLPJ8UYxT4ywyn34JIKe1q23/9/GNDJhMQ8AMe3nBBw=" DisablePayloadBackoff="true"></action>
    </actions>
   </manifest>
  </updatecheck>
 </app>
</response>
core@flatcar-01 ~ $ curl -X POST -d @request.xml https://public.update.core-os.net/v1/update/
<?xml version="1.0" encoding="UTF-8"?>
<response protocol="3.0" server="update.core-os.net">
 <daystart elapsed_seconds="0"></daystart>
 <app appid="e96281a6-d1af-4bde-9a0a-97b76e56dc57" status="ok">
  <updatecheck status="ok">
   <urls>
    <url codebase="https://update.release.core-os.net/amd64-usr/2275.0.0/"></url>
   </urls>
   <manifest version="2275.0.0">
    <packages>
     <package name="update.gz" hash="2dePfsufko+c0o/OJOG2VHzf0OA=" hash_sha256="xLPJ8UYxT4ywyn34JIKe1q23/9/GNDJhMQ8AMe3nBBw=" size="467681292" required="false"></package>
    </packages>
    <actions>
     <action event="postinstall" sha256="xLPJ8UYxT4ywyn34JIKe1q23/9/GNDJhMQ8AMe3nBBw=" DisablePayloadBackoff="true"></action>
    </actions>
   </manifest>
  </updatecheck>
 </app>
</response>

Rename this repo to Nebraska

@schu suggested we name this project after the Omaha protocol that it uses.

Consider installing the tools used during build instead of building them

Currently we build two tools during building the backend - go-bindata and golangci-lint. We could also install it with some curl + tar -xf magic. We also need to make sure that it won't be a PITA for developers to do that.

Rename remaining bits of the project

The project was renamed from CoreRoller to Nebraska but there are still many places where CoreRoller is visible as a name (logging, README, etc.). We should do the remaining changes for the renaming.

Fix color for "information activity status"

It's orangish... It was supposed to be blueish.

UI: Support a logo in the app bar

We should support having a logo to the app bar.
This should be done by having a configuration that can be overridden.

Add version breakdown over time chart

We should add a chart for the version breakdown over time, so it is easier to greap the progress of the updates.

Allow to select time interval for data display

By default Nebraska shows the instances' event history for the past 24h. However, users may be interested in changing this time interval to something different, so we should show those options in the UI.