Skip to content

Instantly share code, notes, and snippets.

@abadger
Created September 6, 2023 18:41
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save abadger/68e4ed8d44494df9ed9a2473d5f77da2 to your computer and use it in GitHub Desktop.
Save abadger/68e4ed8d44494df9ed9a2473d5f77da2 to your computer and use it in GitHub Desktop.
Front end format for MVP (script
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