feat: Add DeviceTier config option description#2786
feat: Add DeviceTier config option description#2786elkoniu merged 1 commit intomendersoftware:masterfrom
Conversation
elkoniu
requested review from
alfrunes,
danielskinstad,
merlin-northern and
michalkopczan
| 5. **Configuration update**: The device configuration (on the device itself) must be updated to send the correct tier in future authentication requests | ||
|
|
||
| **Important considerations:** | ||
| !!!!! DeviceTier can't be changed via update. |
There was a problem hiding this comment.
I'm not sure about that. I think it actually is supported (or should be supported). @frodeha , you mentioned that this is something we should have, right?
There was a problem hiding this comment.
It is supported, yes. If you deploy an update that changes the DeviceTier value in mender.conf of a device, this will work given that you accept the new authentication set created by the server (e.g what's outlined below).
| ##### DeviceTier | ||
|
|
||
| This option describes class of an authenticated device in Mender. | ||
| Depending on the value - the server will treat device different and different |
There was a problem hiding this comment.
I would change it to
Depending on the value, different device limitations will be applied by the Server.
There was a problem hiding this comment.
Agreed, but I would go one step further as we're not exclusively talking about limitations. For some tiers (e.g system) we're unlocking new capabilities (manifest updates) not limiting existing ones. I quite like this formulation as it talks about both limitations and capabilities. Just my two cents.
There was a problem hiding this comment.
Rephrashed following your suggestions:)
| !!!!! DeviceTier can't be changed via update. | ||
|
|
||
| !!!!! Changing tiers requires creating a new authentication set and getting it authorized. | ||
|
|
||
| !!!!! Only one authentication set per device can be in the "accepted" state at a time. | ||
|
|
||
| - Changing tiers requires creating a new authentication set and getting it authorized | ||
| - Only one authentication set per device can be in the "accepted" state at a time | ||
| - The device must be reconfigured to send the correct tier value | ||
| - Deployments should be adjusted to account for the new tier's capabilities and restrictions | ||
| !!!!! The device must be reconfigured to send the correct tier value. | ||
|
|
||
| !!!! If device tier is not specified, the authentication set is treated as **Standard** device tier. | ||
| !!!!! Deployments should be adjusted to account for the new tier's capabilities and restrictions. |
There was a problem hiding this comment.
I found the previous formatting easier on the eyes. I would try not to overuse the notice boxes.
There was a problem hiding this comment.
True, I reverted this change.
| 5. **Configuration update**: The device configuration (on the device itself) must be updated to send the correct tier in future authentication requests | ||
|
|
||
| **Important considerations:** | ||
| !!!!! DeviceTier can't be changed via update. |
There was a problem hiding this comment.
Reading this seems to contradict the section header potentially leading the reader more confused.
There was a problem hiding this comment.
The missleading line has been removed.
elkoniu
force-pushed
the
MEN-9445
branch
2 times, most recently
from
e7b1d0d to
f547e47
Compare
| -- Changing tiers requires creating a new authentication set and getting it authorized. | ||
| -- Only one authentication set per device can be in the "accepted" state at a time. | ||
| -- The device must be reconfigured to send the correct tier value. | ||
| -- Deployments should be adjusted to account for the new tier's capabilities and restrictions. |
There was a problem hiding this comment.
Did you mean to create an unordered list? Currently this collapse to a single paragraph:
There was a problem hiding this comment.
Yes, my bad - copy pasted the diff with too many - signs. Updated.
| - Deployments should be adjusted to account for the new tier's capabilities and restrictions | ||
|
|
||
| !!!! If device tier is not specified, the authentication set is treated as **Standard** device tier. | ||
| - Changing tiers requires creating a new authentication set and getting it authorized. |
There was a problem hiding this comment.
I think a new authentication set is created by the app itself. Not sure.
There was a problem hiding this comment.
Maybe the wording is a bit confusing?
What it actually means in practice is that the client must generate a new private key for authentication.
There was a problem hiding this comment.
True, I clarified it following @alfrunes suggestion.
| - Deployments should be adjusted to account for the new tier's capabilities and restrictions | ||
|
|
||
| !!!! If device tier is not specified, the authentication set is treated as **Standard** device tier. | ||
| - Changing tiers requires creating a new authentication set and getting it authorized. |
There was a problem hiding this comment.
Maybe the wording is a bit confusing?
What it actually means in practice is that the client must generate a new private key for authentication.
Add missing DeviceTier configuration option description and refactor existing DeviceTier documentation to highlight important caveats. Ticket: MEN-9445 Signed-off-by: Paweł Poławski <pawel.polawski@northern.tech>
4 participants
Add missing DeviceTier configuration option description and refactor existing DeviceTier documentation to highlight important caveats.
Ticket: MEN-9445