This adds an alert to the File system configuration step that informs about newly disables `/usr` sub-directories.
It can be removed in two weeks after all the images with possible erroneous mount points are removed.
Sub-directories for `/usr` prefix are no longer supported in file system configuration. This replaces the possible erroneous path with a valid one so the user is not able to send an invalid image request via Recreate action.
The updated mountpoint policy merged in osbuild-composer upstream does
not allow sub-directories of `/usr` to be placed on a separate
partition. There are other changes, but this fix prevents users from
making an obvious error during image creation, until the updated policy
is reflected in the UI.
Related to https://issues.redhat.com/browse/COMPOSER-2030
Signed-off-by: Tomáš Hozza <thozza@redhat.com>
Bring in a review step in the wizard. The purpose is to incrementally
develop it while new steps are added to the mix. This way the Wizard
gets to be integration testable from the early beginning.
Right now the review step is only showing information about the Image
Output step. Even though the Image Output step contains data about the
target environment, these information are going to need the Target
Environment step to be developed in order to be fully shown.
Port the image output step to the new wizard v2.
This is also the first step in the new redesigned wizard and this commit
message is an opportunity to detail a bit the organisation of it:
The code is organised as followed:
- CreateImageWizard is the root and contains all the code associated
with the PF wizard. (i.e Wizard and WizardStep).
- Each step has its code under the step/ sub directory.
- The step directory is named after the step (i.e ImageOutput for the
Image Output step
- At the root of the step directory there is a file which contains the
code of the step (i.e ImageOutput.tsx).
- The main component of the step can access many subcomponents and they
have to be stored alongside it in its directory.
State management:
- The state management is only done with react use states, prop drilling
and state lifting. This is to ensure simplicity as it makes the wizard
- If necessary in the future, there might be needs for context and
reducers, but it's quite not the case RN. And using them come at the
cost of making exploring the code harder.
- CreateImageWizard will declare all the states
Developing a new wizard will require many pull requests and some of them
might even be worked on in parallel. To allow to develop all of that
without interfering with the legacy wizard this commit introduces a new
dev environment alongside an unleash flag when we later want to do the
switch.
To use the new dev en use `npm run stage-beta:experimental` or `npm run
stage-beta:msw+experimental` depending on what you want.
Then unleash flag to toggle in stage and prod is: `image-builder.new-wizard.enabled`
fixes: HMS-2859
Pre-authenticated requests for the OCI images expire 7 days after creation. This adds "Expires in <x> days" and "Expired" as possible statuses for the OCI images.
This adds an expired mock OCI image with an ID "0c1ec8d8-be39-47f2-9bd4-a3fff8244fce" and an expiring mock OCI image with an ID "ea23cfd6-fd8b-43ed-adfc-9f76bb8487ef".
This adds a row for OCI images in the ImagesTable. Details about the images show UUID of the image and the Object Storage URL which is needed to deploy the image.
"Image link" button in the Instance column contains instrucion on how to run an OCI image built by Image Builder in Oracle Cloud. The documentation link in the popover is just a placeholder for now as the documentation is being prepared.
Until the build is finished the "Image link" button is disabled as it would be missing the Object Storage URL which is creating on upload.
This adds a tile allowing to build an OCI image to the Image output step of the wizard. The tile is only visible in the Preview.
As there are no other customer information needed for the build, no addiional step for OCI was added.
Review step was also updated to include OCI images.
This commit extends the supported architectures to aarch64. In the image
output step (the first one of the wizard) the user is now faced with a
new select choices to pickup the architecture they want to build.
Now the set of compatible targets to build is dynamically loaded from
the backend and the UX changes what's accessible on the fly depending on
what's the user has been selected.
Refs HMS-1135
this commit adds filter for image_type to the getComposes endpoint,
enhancing the functionality of the Image Builder frontend table, which comprises two tabs: RPM and OSTree.
With this enhancement, users can now filter OSTree images from the RPM tab, preventing duplication.
Upgrading to PF5 caused the inputs on the file system customization
inputs to stack on each other.
This commit makes them appear in-line again by using the `<Grid>`
component.
Inspiration taken from this PF5 example:
https://www.patternfly.org/components/forms/form#grid-form
This dropdown needed to be update as part of the overall pf5 upgrade.
Each of the components in the select now need to be declared and
handled. Also, some of the Select and SelectOption props come from the
Menu props since Select inherits Menu.
This commit:
1. Removes the header from the Data Driven Forms wizard
2. Adds padding around the in-page wizard so it is visually consistent
with the images table
3. Refactors the images table header into a re-usable component that is
now used in both the images table and the wizard
4. Allows the repositories table to fill the available vertical space in
the wizard
5. Adjusts the package dual list selectors so that they fill the
available horizontal space in the wizard
There was a mixup on our side between what is a profile and what is a
policy. Long story short, a policy a super set of rules including a
profile. For now the wizard is only able to apply profiles and no
policies on images. So let's fix the terminology there.
This commit moves the notification dispatching for creating composes and
clones into a more sensible location – the Image Builder API slice.
It is more sensible because it separates the logic of the React
component (the wizard or share images modal) from the logic of handling
the request life cycle (which is now handled entirely in the slice).
There is a subtle but significant change – a new request will be
dispatched for every request. This is the correct way to do things as it
is possible that some requests succeed, and that others fail. Insights
causes the notifications to stack on top of each other neatly, so there
is no UI problem.
To facilitate this, we also need to use use Promise.allSettled instead
of Promise.all.
There was a bug preventing all the partitions required by an oscap
policy to show up in the fsc step. That bug was because the FSC
customizations were only accepted if they matched exactly the fix set of
base partitions directories.
So now there's a bit of string manipulation to avoid that but it's all
patched up.
fixes https://github.com/RedHatInsights/image-builder-frontend/issues/1385
The images table uses the useGetComposesQuery hook to fetch composes and
implement pagination. When this query is used, args are provided for the
offset and limit and a 'Compose' tag is provided for the query.
When a mutation is triggered (causing a POST request to be sent to the
`/compose` end point), the 'Compose' tag is invalidated which clears all
cached data from useGetComposesQuery hooks, which in turn causes the
table to refetch compose information.
If invalidating the `Compose` tag causes a refetch before the new compose
is available in image-builder, the result does not contain the new
compose and the table is not updated to include it.
This commit eliminates the race condition by waiting for the query to be
fulfilled before invalidating tags (and therefore before refetching the
data).
All of the above applies equally to the `cloneCompose` mutation, and its
race condition has also been eliminated.
This commit is loosely inspired by the RTK Query docs section on
pessimistic updates:
https://redux-toolkit.js.org/rtk-query/usage/manual-cache-updates#pessimistic-updates
Typescript complains about the type of the tags. It does not recognize
the tag types that are defined in the same enhanceEndpoint() function.
For now, we simply ignore the Typescript errors. There is some
discussion here: https://github.com/reduxjs/redux-toolkit/issues/1510
When the user clicks on the "create an image" button, the image wizard
shows up replacing the landing page. This allows to keep the quickstart
guides to the right of the wizard while the user is interacting with it.
When the user has selected a profile to customize their distribution,
the FSC step now shows immediately the manual configuration opened up
with the partitions coming from the profile already filled in.
If the user goes back to the Compliance step and changes anything, the
FSC step is going to be reinitialized.
HMS-2077
Do not show the oscap step outside of beta. Only protecting the step
itself is sufficient since the FSC and the Packages steps wont load any
profile data if no entry point allows to get one.
HMS-2077
wizardrecreatebeta
This commit adds the Compliance step to the wizard. In this step the
user can select a policy from the list of available policies. Their
image is going to be updated with the necessary changes on the later
steps.
IB and The compliance endpoint are both returning the list of policies a
user has access to. The oscap step computes the intersection of the
policies accessible before showing the select list to the user.
HMS-2077
Adding GCP image sharing option according to the discussion on slack(https://redhat-internal.slack.com/archives/C03AZ0264LW/p1692789579814619) and mocks(https://issues.redhat.com/browse/HMS-2352).
In summary, within our GCP sources, we store the project ID. Images cannot be shared directly with a project ID, but they can be shared with a service account or a Google account. Consequently, to launch instances in GCP, users are not required to provide their Google account; instead, the images should be shared with the provisioning service account. This ensures that the provisioning team has access to the necessary images, as sharing them with individual users would not allow that.
After a thorough discussion, we have collectively decided to introduce an option. This option allows users to exclusively utilize the Launch service without the need to share the image with a Google account.
The `<LaunchWizard>` architecture prop was specified incorrectly,
which caused the Instance dropdown in the Launch wizard to fail to load
instance types.
This commit is a hotfix that restores functionality to the Launch
wizard.
The `appendTo` variable can't be recomputed on every render. Wrap it in
a useState() hook to work properly.
Additionally, the `hasAccess` property was missing from the
<ProvisioningWizard> component.
To ensure full backwards compatibility, the component has also been
wrapped in a <Suspense> as it was previously.
The edge images table is going to be integrated in the frontend code
base in the coming weeks. To help smooth that development process there
is need for a feature flag that would keep the current behavior running
on stage and prod while the new image table is being developed.
For now dummy code is returned for when the flag is on, and legacy
behavior keeps on going when the flag is off.
The stage flag can be seen there:
- https://insights-stage.unleash.devshift.net/projects/default/features/image-builder.edge.local-image-table
The prod flag can be seen there:
- https://insights.unleash.devshift.net/projects/default/features/image-builder.edge.local-image-table
The commit brings in some documentation in the Readme. Any member of
the team should be able to follow these steps to add in new feature
flags and use them in the code base.
The commit also brings in two new testing files for the future
components to come. For now these tests only check that the mocking
value for the unleash flag is properly set.
