Created
September 6, 2023 18:41
-
-
Save abadger/68e4ed8d44494df9ed9a2473d5f77da2 to your computer and use it in GitHub Desktop.
Front end format for MVP (script
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The problem (as you pointed out earlier) is that you really want to apply one or more | |
transformations to the raw data to make it easier for the front end to work with it. I knew that | |
we would need to transform the results but there was a miscommunication about where that | |
transformation would occur. We thought it would be done somewhere after the data was passed back | |
from the client and the front end folks thought it would occur somewhere before they got it and no | |
one checked with the folks in the middle to make sure they understood that the only place left for | |
the transformation was in their code. Transformations that I know are needed: | |
* For each message, our unique key is a combination of the action's id (an action is one discrete | |
test or action that we can verify works prior to committing to going through with a conversion) | |
and the message's id. It's like each action creates a namespace for the messages that are emitted | |
when it runs. | |
* We have results in a separate field from the list of messages. This was a conscious choice on | |
convert2rhel's part because there is only one result but multiple messages. That's an easy | |
constraint when result is a single value separate from the list of messages but hard when they're | |
mixed together. For working with the front end as given by the mockups, though, it'll be easiest | |
to flatten that so results are just another message. (Note: We intentionally made the structure of | |
results and messages the same and made the action_id:message_id combination unique for the | |
combined set of results and messages. So flattening the data has been anticipated). | |
* Status needs a way to map to extra information. (High Risk from LEAPP and Error from convert2rhel | |
both fall into the same "category" of status. So the plan is that they use the same icon and | |
color scheme to express that they are very similar. But that relationship isn't known by the | |
individual tasks which live in isolation from the other tasks which the Tasks App might host). | |
[...] | |
I think we're going to need a plan for MVP and a plan for enabling more and more applications to use | |
Tasks as a framework for running their code and displaying the results. Where possible, we want to | |
make sure what we code for the MVP can continue to work with the long term plan. | |
At the meeting yesterday, we mostly talked about the plan for MVP. There is definitely no time to | |
make changes to the output from convert2rhel (freeze for the release that will be MVP is in two | |
days). What we can do is make the necessary transformations in the playbook/script since that can | |
continue to be modified until closer to the deadline. Rodolfo thinks he has time to do them there. | |
We can produce something roughly like what you have. Something like this probably makes sense? | |
(Although I don't know if we need to turn it into a list given how objects and dicts can be iterated | |
over. And a list means that the front end would need a little more code if it wants to sort by | |
key): | |
Note: format_version here should be the Tasks format_version[See below], not the convert2rhel | |
format_version. | |
{ | |
"format_version": "1.0", | |
"action_results": [ | |
{ | |
"key": "IS_LOADED_KERNEL_LATEST::INVALID_KERNEL_VERSION", | |
"title": "Kernel version available in RHEL", | |
"description": "Check whether RHEL contains a kernel of the same or more recent version as | |
the one currently loaded on the host.", | |
"diagnosis": "The version of the loaded kernel is different from the latest version in the | |
enabled system repositories.\n* Latest kernel version available in updates: 3.10.0-1160.90.1.el7\n* | |
Loaded kernel version: 3.10.0-1160.88.1.el7", | |
"level": "ERROR", | |
"remediation": "To proceed with the conversion, update the kernel version by executing the | |
following steps:\n1. yum install 3.10.0-1160.90.1.el7 -y\n2. reboot" | |
} | |
] | |
} | |
I think that will get us to MVP. Can you think of anything else? |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment