Closed alohr51 closed 4 years ago
@stephenkinder Did we decide to move this out of 070 and into 080?
From Dave, an example of output from the list stacks endpoint from the CLI API
"kabanero stacks": [
{
"name": "java-microprofile",
"status": [
{
"digest check passed": true,
"version": "0.2.26",
"image digest": "5c7bec7fc901b88aef6da457144873657640cbe520504379731d856c480deb9a",
"kabanero digest": "5c7bec7fc901b88aef6da457144873657640cbe520504379731d856c480deb9a",
"status": "active"
}
]
},
PR #209 has the code written that it needs to:
Allow users to update the digest policy according to https://github.com/kabanero-io/docs/pull/366/files#diff-6388a1bc1f22f42dd9d1b77b20bbc730R12-R18
Use the output from the CLI API to display on the console UI if the digest check passed or not.
CLI Services did a check for the strictDigest policy and released that so we can start testing. I talked to Dave and they will need to implement the check for the other 3 policies. Once they finish that we’ll do a final test with all the policy options.
Feature description
The Kabanero stack CR is going to have a digest key/value added to it. This digest value will be set at the time the stack was activated.
The Operator will manage that new field for each stack.
The CLI will need to be updated to give the current digest for a stack. If the digest in the stack CR doesn't match one from CLI we have a problem.
What needs to be done is the console needs to compare those 2 digests and display a warning on the stacks page if they do not match. The warning can be a yellow warning triangle next to the stack name.
Feature design or visual mockup
https://github.com/stephenkinder/kabanero-foundation/blob/digest/design/digest.md
Operator has finished their work - info on how to get the digest from the CRD is in this operator PR comment
Additional context
Why this is a problem
Example scenario: A developer will have configured Appsody to point at tag
0.3
and0.3
tag points to0.3.2
, but Kabanero doesn't have the0.3.2
stack activated.Today, when this happens we currently "warn" - saying hey we're going to give you the
0.3.2
stack, even though the stack maintainer didn't say it was explicitly okay to use it (they would explicitly say okay by activating the stack)Currently, this takes away the whole point of activating/deactivating stacks - if we just ignore if they're active or not.
The Kabanero CR will have a policy for what to do when we hit mismatching digests: warn, fail, no action. (console may allow users to change this via UI in future, but is not a part of this work the update would be a Global policy change for all configured stack indexes due to how the CLI handles stacks as 1 big group)