Merge pull request #1621 from advancedtelematic/feat/prep-2020.5

Feat/prep 2020.5

CHANGELOG.md

@@ -7,6 +7,17 @@ Our versioning scheme is `YEAR.N` where `N` is incremented whenever a new releas
 ## [??? (unreleased)]
 
 
+## [2020.5] - 2020-04-01
+
+### Changed
+
+- Fetch garage-sign from new AWS bucket via CNAME: [PR #1619](https://github.com/advancedtelematic/aktualizr/pull/1619) and [PR #1622](https://github.com/advancedtelematic/aktualizr/pull/1622)
+
+### Fixed
+
+- Abort update immediately if Secondary metadata verification fails: [PR](https://github.com/advancedtelematic/aktualizr/pull/1612)
+
+
 ## [2020.4] - 2020-03-24
 
 ### Added

docs/README.adoc

@@ -36,6 +36,7 @@ The link above is for the doxygen docs on master. Doxygen docs for the following
 * https://advancedtelematic.github.io/aktualizr/2020.2/index.html[2020.2]
 * https://advancedtelematic.github.io/aktualizr/2020.3/index.html[2020.3]
 * https://advancedtelematic.github.io/aktualizr/2020.4/index.html[2020.4]
+* https://advancedtelematic.github.io/aktualizr/2020.5/index.html[2020.5]
 ====
 
 == Release process

docs/ota-client-guide/antora.yml

@@ -1,6 +1,6 @@
 name: ota-client
 title: OTA Connect Developer Guide
 version: latest
-display_version: 2020.3 (latest)
+display_version: 2020.5 (latest)
 nav:
 - modules/ROOT/nav.adoc

docs/ota-client-guide/modules/ROOT/nav.adoc

@@ -44,7 +44,7 @@ ifndef::env-github[:pageroot:]
 .Integrate OTA Connect
 * xref:{pageroot}intro-prep.adoc[Recommended steps]
 * xref:{pageroot}recommended-clientconfig.adoc[Recommended configurations]
-* xref:{pageroot}account-setup.adoc[Set up multiple accounts]
+* xref:{pageroot}add-environments.adoc[Set up additional environments]
 
 * xref:{pageroot}libaktualizr-why-use.adoc[Integrate libaktualizr into your solution]
 ** xref:{pageroot}libaktualizr-getstarted.adoc[Get started with libaktualizr]

docs/ota-client-guide/modules/ROOT/pages/_partials/aktualizr-version.adoc

@@ -3,6 +3,8 @@
 // the version being viewed, but when we are referencing aktualizr from
 // the other, non-versioned docs, we want to make sure we're using the
 // latest version.
-:aktualizr-version: 2020.4
+:aktualizr-version: 2020.5
 
 :yocto-version: 3.0
+
+:yocto-branch: zeus

docs/ota-client-guide/modules/ROOT/pages/_partials/recommended-steps.adoc

@@ -29,17 +29,20 @@ We support a couple of demo boards "out of the box". You don't need to worry abo
 
 //  tag::integrate-steps[]
 
-* *Set up different user logins*
+* *Set up different environments*
 +
-In OTA Connect, each user account gets its own personal software repositories and device inventory. However, you don't want to mix up test software and production software by putting all of your builds and devices on the same account.
+When you first create an account on the https://connect.ota.here.com[OTA Connect Portal], you get a home xref:ota-web::environments-intro.adoc[environment]--where you can create and manage software update projects. You can also create up to 10 additional environments within your OTA Connect account. This helps because you don't want to mix up test software and production software.
 +
-A better strategy for production is to create separate user logins to manage the different stages. For example, you might want a three-step process:
+In a proper production workflow, you'll need separate environments to manage the different stages:
 +
-. A developer user such as "\dev@acme.com".
-. A QA user such as "\qa@acme.com".
-. A production user such as "\prod@acme.com".
+. A developer environment.
+. A QA environment.
+. A production environment.
 +
-These logins provide you with a way of clearly separating your development, QA and production resources.
+In your OTA Connect account, you can easily switch between the different environments and also add your colleagues as members in each of the environments. For instructions on how to manage members, see the xref:ota-web::manage-members.adoc[related] section in the User Guide.
++
+Seperate environments provide you with a convenient way of separating your development, QA, and production resources.
+
 
 ////
 COMMENTING OUT UNTIL ORGANIZATIONS STOPS BEING "ALPHA"

docs/ota-client-guide/modules/ROOT/pages/add-environments.adoc

@@ -0,0 +1,34 @@
+= Set up additional environments
+:page-aliases: account-setup.adoc
+ifdef::env-github[]
+
+[NOTE]
+====
+We recommend that you link:https://docs.ota.here.com/ota-client/latest/{docname}.html[view this article in our documentation portal]. Not all of our articles render correctly in GitHub.
+====
+endif::[]
+
+
+An xref:ota-web::environments-intro.adoc[environment] is your working space in your https://connect.ota.here.com[OTA Connect account], where you can create and manage software update projects.
+
+If you do not want to mix up test and production software during xref:evaluation-to-prod.adoc#_integrate_ota_connect[integration with OTA Connect], you may create additional environments. You can xref:ota-web::create-environment.adoc[create] up to 10 additional environments in one OTA Connect account.
+
+For example, you may need to have different environments for development, QA, and production.
+
+IMPORTANT: The limit of 10 additional environments applies even if you leave the environments that you have created. There is currently no way to delete environments.
+
+== Environments for production workflow
+
+To manage the different stages of production workflow, you should create the following additional environments:
+
+* A developer environment
+* A QA environment
+* A production environment
+
+These environments provide you with a convenient way to separate your development, QA, and production resources.
+
+
+After you create an environment, you can xref:ota-web::manage-members.adoc[add] your colleagues to work together on device provisioning, device groups, software versions, software updates, and campaigns.
+
+To get more information on the *Environments* feature, see the xref:ota-web::environments-intro.adoc[Environments] section in the OTA Connect User Guide.
+

docs/ota-client-guide/modules/ROOT/pages/aktualizr-config-options.adoc

@@ -7,6 +7,8 @@ We recommend that you link:https://docs.ota.here.com/ota-client/latest/{docname}
 ====
 endif::[]
 
+include::_partials/aktualizr-version.adoc[]
+
 :page-layout: page
 :page-categories: [client-config]
 :page-date: 2018-07-05 11:14:01
@@ -38,7 +40,7 @@ For examples of configuration files, see the following resources:
 
 * link:{aktualizr-github-url}/config/[Config files used by unit tests]
 * link:{aktualizr-github-url}/tests/config/[Config files used by continuous integration tests]
-* link:https://github.com/advancedtelematic/meta-updater/tree/zeus/recipes-sota/config/files[Configuration fragments used in meta-updater recipes].
+* link:https://github.com/advancedtelematic/meta-updater/tree/{yocto-branch}/recipes-sota/config/files[Configuration fragments used in meta-updater recipes].
 
 All fields are optional, and most have reasonable defaults that should be used unless you have a particular need to do otherwise.
 

docs/ota-client-guide/modules/ROOT/pages/build-agl.adoc

@@ -28,12 +28,12 @@ include::build-raspberry.adoc[tags=prereqs]
 
 === Get the AGL code
 
-First, use the manifest file for AGL's Happy Halibut release to download the required repositories:
+First, use the manifest file for AGL's Itchy Icefish release to download the required repositories:
 
 ----
 mkdir myproject
 cd myproject
-repo init -b halibut -m halibut_8.0.2.xml -u https://gerrit.automotivelinux.org/gerrit/AGL/AGL-repo
+repo init -b icefish -m icefish_9.0.0.xml -u https://gerrit.automotivelinux.org/gerrit/AGL/AGL-repo
 repo sync
 ----
 
@@ -57,13 +57,14 @@ IMPORTANT: Only `raspberrypi3` and `qemux86-64` will work out of the box. If you
 
 === Additional configuration for Raspberry Pi 3
 
-As described in the link:https://wiki.automotivelinux.org/agl-distro/agl-raspberrypi#sota[AGL wiki], you will need to edit your `bblayers.conf` to replace `meta-updater-qemux86-64` with `meta-updater-raspberrypi`.
+As described in the link:https://docs.automotivelinux.org/docs/en/master/getting_started/reference/getting-started/machines/raspberrypi.html#sota[AGL documentation], you will need to edit your `bblayers.conf` to add `meta-updater-raspberrypi`.
 
 === Additional configuration for QEMU
 
 // This has been moved upstream:
 // https://gerrit.automotivelinux.org/gerrit/c/AGL/meta-agl/+/23953
-// But it's only in master at present, not even icefish.
+// But it's only in master at present, not even the initial icefish release.
+// See 99c55be1635a8ff30317417093da54fbcd8eb250 in the icefish branch of meta-agl.
 
 By default, AGL for QEMU boots into an initrd before loading the root filesystem, but as of thud, meta-updater by default uses an initramfs. You will need to force the build to use an initramfs by adding this to your `local.conf`:
 

docs/ota-client-guide/modules/ROOT/pages/build-raspberry.adoc

@@ -54,15 +54,14 @@ Also, make sure that you've generated your xref:generating-provisioning-credenti
 // tag::env-setup[]
 
 
-
 == Create your Yocto build environment
 
 First, clone a manifest file for the quickstart project:
 
 ----
 mkdir myproject
 cd myproject
-repo init -u https://github.com/advancedtelematic/updater-repo.git -m zeus.xml
+repo init -u https://github.com/advancedtelematic/updater-repo.git -m {yocto-branch}.xml
 repo sync
 ----
 

docs/ota-client-guide/modules/ROOT/pages/client-provisioning-methods.adoc

@@ -80,11 +80,12 @@ image::img::device-cred-provisioning.png[width=100%]
 
 If you want to use "shared credential" provisioning, you don't have to do anything at all. When your account was created, we already generated a Fleet Root CA and keypair for you, and stored them on the OTA Connect server. We take the security of these keys extremely seriously: following industry best practices, they are kept in a Vault instance and only taken out when you request them.
 
-If you want to use "device credential" provisioning, you'll need to provide us with your own Fleet Root CA so that the OTA Connect server can verify devices.
-Of course, you can use both methods, but in that case, we recommend that you maintain separate user accounts:
+If you want to use "device credential" provisioning, provide us with your Fleet Root CA so that the OTA Connect server can verify devices.
+Of course, you can use both methods, but in that case, we recommend that you maintain separate xref:ota-web::environments-intro.adoc[environments]:
 
-* one account for testing with "shared credential" provisioning
-* one account for production with "device credential" provisioning
+* one for testing with "shared credential" provisioning
+* one for production with "device credential" provisioning
+
+It is not possible to migrate from a test environment to a production environment. Therefore, we recommend that you test with devices that do not go into production or devices that can be completely wiped and reset once they are ready to deploy.
+Once you are ready for production, you should use your production environment, your own Fleet Root certificate, and production devices that have their device certificates preinstalled.
 
-Migrating devices from a test account to a production account is an extremely complex process and should be avoided.  Instead, we recommend that you test with devices that will not go into production or devices that can be completely wiped and reset once they are ready to deploy.
-Once you are ready for production, you should use your production account, your own Fleet Root certificate, and production devices that have their device certificates preinstalled.

docs/ota-client-guide/modules/ROOT/pages/cross-deploy-images.adoc

@@ -1,4 +1,4 @@
-= Transfer disk images to a software repository in another account
+= Transfer disk images to a software repository in another environment
 ifdef::env-github[]
 
 [NOTE]
@@ -14,20 +14,20 @@ endif::[]
 :icons: font
 :sectnums:
 
-For our recommended production workflow, you will need to move disk images from one account to another from time to time. For example, you might want to send a development build that you're happy with to the QA team, or send that build to the deployment team once it's passed QA. You can do this with our `garage-deploy` tool.
+For our recommended production workflow, you will need to move disk images from one environment to another from time to time. For example, you might want to send a development build that you're happy with to the QA team, or send that build to the deployment team once it's passed QA. You can do this with our `garage-deploy` tool.
 
 Before you start, make sure that you've installed the xref:install-garage-sign-deploy.adoc[`garage-deploy`] tool first.
 
-To transfer disk images to a different account, follow these steps: ::
+To transfer disk images to a different environment, follow these steps: ::
 . xref:getstarted::generating-provisioning-credentials.adoc[Download provisioning keys] for both accounts.
 +
 We'll assume that you named them `source-credentials.zip` and `dest-credentials.zip`.
 +
-. Select an image and commit ID to deploy, and the hardware ID(s) to deploy it to
+. Select an image and commit ID to deploy, and the hardware ID(s) to deploy them to.
 +
-The image name is the one that appears in your {product-name} account--it will be the same as the `MACHINE` setting in Yocto by default, or the `OSTREE_BRANCHNAME` option if you set it. The commit ID is the hash of the OSTree commit, visible in the package details. The hardware IDs are for the destination account, and are equivalent to the `MACHINE` setting in your Yocto build.
+The image name is the one that appears in your {product-name} account--it is the same as the `MACHINE` setting in Yocto by default, or the `OSTREE_BRANCHNAME` option if you set it. The commit ID is the hash of the OSTree commit, visible in the package details. The hardware IDs are for the destination environment, and are equivalent to the `MACHINE` setting in your Yocto build.
 +
-. Run `garage-deploy`
+. Run `garage-deploy`.
 +
 You can see the available options with `--help`:
 +
@@ -48,11 +48,11 @@ garage-deploy command line options:
                                  same format as curl --cacert
 ----
 +
-For example, to deploy an image called `acme-modelB` with SHA `001ee11a28e3e08f3e93e31425f0721a7fb44946919284b629ca85a1cc3073cb` and make it installable on all Raspberry Pi devices on your target account, the command would be:
+For example, to deploy an image called `acme-modelB` with SHA `001ee11a28e3e08f3e93e31425f0721a7fb44946919284b629ca85a1cc3073cb` and make it installable on all Raspberry Pi devices in your target environment, use the following command:
 +
 ----
 garage-deploy --commit 001ee11a28e3e08f3e93e31425f0721a7fb44946919284b629ca85a1cc3073cb \
   --name acme-modelB -f source-credentials.zip -p dest-credentials.zip -h raspberrypi3
 ----
 +
-. Log into the destination account, and verify that your image has been deployed
+. Go to your destination environment and verify that your image is deployed.

docs/ota-client-guide/modules/ROOT/pages/deploy-checklist.adoc

@@ -16,12 +16,12 @@ Here is a checklist for all the tasks you should consider when moving to product
 |====================
 | Task  | Summary | Documentation
 |**Register the root certificate for your fleet ** |
-* If you followed our recommendations, you should have accounts for development, testing and production.
-** If you also followed our recommendation to use device-credential provisioning, you need to register your Fleet Root certificate with your production account
+* If you followed our recommendations, you should have separate environments for development, testing, and production.
+** If you also followed our recommendation to use device-credential provisioning, you need to register your Fleet Root certificate with your production environment.
 
-* You might have already registered a self-signed root certificate with your test account.
+* You might have already registered a self-signed root certificate with your test environment.
 +
-However, regardless of the type of certficate that you use, you'll need to register a new certificate with your *production* account. |
+However, regardless of the type of certficate that you use, you'll need to register a new certificate with your *production* environment. |
 * xref:client-provisioning-methods.adoc[Device provisioning methods]
 * xref:provide-root-cert.adoc[Register the Root Certificate for your Fleet]
 
@@ -35,14 +35,14 @@ You can then automate the process of either generating the device certificates o
 * xref:generate-devicecert.adoc[Generate a device certificate]
 * xref:enable-device-cred-provisioning.adoc[Enable device-credential provisioning and install device certificates]
 |**Rotate production keys**  |
-* In line with our security concept, we recommend that you sign software version with secure, offline keys.
+* In line with our security concept, we recommend that you sign the software version with secure, offline keys.
 
-* Even if you've done this already for with a test account, you need to do it again with a `credentials.zip` from your production account.
+* Even if you've done this already in a test environment, you need to do it again with a `credentials.zip` file from your production environment.
 
-* You should keep these keys on a secure storage medium such as a link:https://www.yubico.com/[YubiKey]. You would only plug in your YubiKey when you need to sign metadata on your local computer.|  xref:rotating-signing-keys.adoc[Manage keys for software metadata]
+* You should keep these keys on a secure storage medium such as a link:https://www.yubico.com/[YubiKey]. Only plug in your YubiKey when you need to sign metadata on your local computer.|  xref:rotating-signing-keys.adoc[Manage keys for software metadata]
 
 |**Transfer disk images to your production repository**  |
-* When you're ready to deploy your software to production, you'll need to move all approved disk images from the software repository in your testing account to the one in your production account.  |  xref:cross-deploy-images.adoc[Transfer software to another repository]
+* When you're ready to deploy your software to production, you'll need to move all approved disk images from the software repository in your testing environment to the one in your production environment.  |  xref:cross-deploy-images.adoc[Transfer software to another repository]
 |**Create production-ready client configuration**  |
 * You'll need to update the configuration for aktualizr or libaktualizr.
 +