nerves-hub / nerves_hub_web Goto Github PK
View Code? Open in Web Editor NEWManage firmware updates for Nerves devices
Home Page: https://nerves-hub.org/
License: Apache License 2.0
Manage firmware updates for Nerves devices
Home Page: https://nerves-hub.org/
License: Apache License 2.0
Acceptance Criteria
Current behavior:
When you upload a .fw file, the browser acts like it is working, but it's hard to tell how far it's gotten.
Expected behavior:
There's a progress bar or some feedback that lets you know that things are happening.
Steps to reproduce:
Go to the firmware tab, browse and then upload a .fw file.
Hi.
So without any concern of how things get done, or what anyone else needs, I've looked the deployments from a birds eye view of how I'd like things to work. I figured I'd jot it down here. Feel free to ignore or dismiss as unworkable lol. It could be a good starting point or at least we can define our use cases by analyzing what this misses.
To me it seems like we are missing something in our current schemas. I'd add a Product and a DeviceGroup (names tbd).
So, a Tenant has multiple Products.
A Product has one or more DeviceGroups.
A DeviceGroup would hold the set of conditions that defined its membership (processor, memory, etc) and have one or more deployments, some active, some inactive, one Deployment which is "current".
A Deployment should have one firmware, possibly some conditions and zero or more devices that have reported running that firmware. I would like to keep this info static, so it could provide a history of what device got what firmware when.
So the paths a product would go on...
Case 1:
Identity DeviceGroup, its criteria is '*' and it has one active and current deployment. Whenever you release a new firwmare you would upload it to the DeviceGroup and mark it as current and active. It would create a new deployment with with that firmware and start notifying whatever Devices are logged in, adding them to the deployment once they have updated. The former current deployment would be marked as inactive and hidden but would still be there. So you'd have a history of what devices got what firmware when, which could be useful.
Case 2:
Still the identity DeviceGroup, but theres now just a happy path, ie all devices get version 1.2.0 except v0.9.0 which needs v1.0.1 first, etc. So theres an still a current deployment with firmware v1.2 but an extra active deployment exists that differentiates by v0.9.0. But you could differentiate on other things too. We could set it up where the order does matter for the non current and active deployments and if they all fail, apply the current one.
Case 3:
For a split in the Product firmware builds we would need to create a second DeviceGroup for the product. To indicate a hardware change most likely, but it could be anything, even a firmware version that could not be upgraded, anything that required a different build of the firmware. Devices logging in would be queried and placed in the current DeviceGroup by any number of criteria and receive the correct deployment. Each DeviceGroup would be on its own as far as receiving new deployments and persisting the devices that have upgraded.
Alpha, Beta, BleedingEdge etc.
It seems like all of the non production kind of labels would really want to be applied at the DeviceGroup level. If you were shipping one beta firmware for DeviceGroup RPI0 and one for DeviceGroup RPI0W you would want to be testing devices for each firmware. So there would be one beta tag, but which firmwware each device gets depends on what DeviceGroup its in. That would be adding an extra active deployment to each DeviceGroup using tags instead of firmware version as the qualifier. These you would want to make sure are applied first.
Anyway thanks for taking the time to read this! Its just an idea and I'm sure there are plenty of necessary use cases it doesn't encompass.
Acceptance Criteria
When on the tenant settings, there should be a remove button or X icon to the side of each key, when clicked it should confirm you want to remove the key and then remove it
Setup initial schema:
tenants
id
name
jwt/auth key? - or user specific?
public key(s)
users
id
tenant_id
name
email
password
devices
id
tenant_id
identifier (name?) text, unique
current_version
target_version
last_comm
last_update?
channel
architecture/platform?
tags array<string>
metadata - from [nerves](https://github.com/nerves-project/nerves_runtime#nerves-system-and-firmware-metadata)
firmwares
id
tenant_id
signed?
in_use?
s3/gcs/identifier (start with s3, can be adapted)
(can extract metadata)
channel
architecture/platform
deployments
id
tenant_id
conditions/query
firmware_id
status
started_at
finished_at
Since we're requiring client-side certificates, offering a JIT registration capability seems really convenient. See https://aws.amazon.com/blogs/iot/just-in-time-registration-of-device-certificates-on-aws-iot/ for how AWS handles it.
Acceptance Criteria:
References: https://github.com/nerves-hub/nerves_hub/blob/master/docs/client-server.md
Next, the server compares the running version of the firmware to the target version for that device on NervesHub. If those versions are different, then the channel queues a firmware update message to be sent as soon as the channel finishes the join process.
Depends On: #78
Create an S3 Firmware Upload module that can be configured to use instead of the Beamware.Firmware.Upload.File
module that uploads firmware files to Amazon S3 and generates download links when requested. Should implement both upload_file
and download_file
like Beamware.Firmware.Upload.File
The idea here is to expose an API for CI servers and other systems to interact with the nerves_hub
and be able to do the same things that humans can do via the web UI.
Instead of requesting all devices to update simultaneously, it's useful to roll out the updates. This has two benefits:
Acceptance Criteria:
Currently, firmware metadata
is being parsed for a few key fields, and then the entire metadata
string is being stored in a metadata
string field on a firmware
record.
The current issue, is that it is very common in the real world for the metadata
field to be greater than the database imposed limit of 255 characters.
The proposed fix:
metadata
string field, and adds the following relevant fields supplied by @fhunleth:meta-product
meta-description
meta-version
meta-author
meta-platform
meta-architecture
meta-vcs-identifier
meta-misc
meta-uuid
firmware_controller
and the firmware
schema to handle these changes as well.Acceptance Criteria:
There are a few ways of creating certificates for devices. This issue covers having a screen that lets users enter in a name or ID for a device and then having the server generate (with the help of nerves_hub_ca
) a device certificate. The user would then download the certificate and keys and would install them on the device. I think that this is part of the device creation page, but if another part of the UI makes more sense, it could be there too. We will eventually want to allow users to create certificates for devices as a separate step to creating/registering the device with Nerves Hub. However, that separation could be done as part of another issue if it is involved.
Acceptance Criteria:
The device delete and disable buttons are on the main device listing screen at the moment. This is fine for now, but it would be nice to move them to either a device detail screen or have a sequence of "are you sure" screens. The idea is to prevent an accidental delete or disable since those should be rare operations in production and they have big consequences to devices.
Accessed from the Deployment List
Acceptance Criteria
References: https://github.com/nerves-hub/nerves_hub/blob/master/docs/client-server.md
The final step of the join process is to respond to the device with a list of the group channels that it should join.
Depends On: #79
Acceptance Criteria:
This issue tracks whether we'll use Bootstrap 3, 4 or Materialize for the initial web framework. While the UI should be straightforward, there is an expectation there will be enough client-side validation and and feedback that we might as well start with one.
(Stub)
(stub)
Acceptance Criteria:
Detail view of a deployment
Acceptance Criteria
Technical Acceptance Criteria
status
to a boolean is_active
fieldAcceptance Criteria:
(stub)
Right now it's impossible, so #38 will never return an upgrade.
Minimum requirements for the device to report to Nerves Hub:
Minimum needed to send back down to the device:
Nice to have notifications from the device:
Other items to consider:
Acceptance Criteria
Need additional detail for S3 upload
Acceptance Criteria:
Acceptance Criteria:
GET /firmware-update
X-Client-Dn
header is missing.X-Client-Dn
header is not in the format CN=identifier
.identifier
in the X-Client-Dn
header is not the case-sensitive identifier of a device in the devices
table.Version.match?/3
){
"eligible_firmware_update": "http://example.com/path/to/firmware/1.0.1/file.fw"
}
(If not eligible for a firmware update, null is returned:)
{
"eligible_firmware_update": null
}
Notes:
identifier
. This is an acknowledged major problem with this first version; we'll need to address it before using the product.It's useful to know a high level status of the device (like red, yellow, green or failed, warnings, ok). The idea is that once you get enough devices, it's convenient to be able to see at a glance what's happening rather than clicking through to a device detail view.
It seems difficult to combine all interesting device status into one field, so here's a high level idea that has two columns:
Overall status
Firmware update status
The firmware update status field would replace the "update pending" column
Acceptance Criteria:
/
-- but it detects they're logged in so it doesn't show the login page).When a firmware file is uploaded, we verify the firmware is valid and then check if it is signed, and if so, match the verify the signature with they key(s) on the tenant.
The way we determine a firmware is signed is no longer valid - update to use fwup
's programmatic interface
Acceptance Criteria
(For the purpose of eventually limiting the amount of disk space a single tenant's firmwares can take up.)
References: https://github.com/nerves-hub/nerves_hub/blob/master/docs/client-server.md
The device joins device:#{device_identifier} with a payload of %{"version" => version}. The server first verifies that the device is joining its own channel, by comparing the id in the channel name to the id on the certificate.
It would be nice if the server could maintain an interaction history with each device. This doesn't have to be fancy. It could just contain things like "device connected at time x", "firmware update requested", "device's firmware version is now y". The idea is to have historical information about a device if a bug report is incomplete or there's an issue with firmware updates reverting.
Currently the web app lists all devices per tenant. A tenant likely will have multiple products. It is expected that users will want to focus on one product at a time. Some way of filtering or grouping firmware, devices, and deployments on a per product basis would be good.
Some notes on products:
.fw
files contain a meta-product
tag that has the product name. This could be extracted for to categorize firmware, devices, and deployments.fwup
scripts used with Nerves don't force the meta-product
tag to match what's running on devices. This makes it possible to turn one product into another.meta-product
names that correspond to one "product" in the UI.Acceptance Criteria:
We don't want just anyone signing up on nerves_hub yet.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.