> I can confirm that the suggested workaround (removing StorageCluster (In reply to Martin Bukatovic from comment #8) Honestly, my ideal would be to not rely on any CRD-based interface at all as it would give us much more flexibility in terms of displayed names and placements of a variety of UI elements, but I'm pretty sure that's out of the question for this release. Obviously for existing customers upgrading this may be something of a jump, so that also needs to be considered. With that in mind we have to get a decision on just how much we want to lean on StorageSystems or StorageClusters as the primary interface for our UI customers. We're currently stuck with whatever UI is in the actual Console itself, but if I remember right everything outside the installation wizard will be coming in our dynamic plugin, so we still have some time and flexibility there. The direction this BZ has taken is a perfect example of this.Īll that said, at this point this is more a product decision than a technical one. IMO it's basically a race to the bottom of "what's the absolutely bare minimum amount of information we need to expose", leading to all sorts of headaches and conversations around vague definitions of actual users. This product has a history, from its inception, of designing its UI to abstract and hide. As such, I'm open to doing what we can to make its interactions with the UI more agreeable, as long as the overall design doesn't suffer because of it. It provides basically no technical benefit otherwise. However, the StorageSystem CR is almost entirely a convenience API for the Console to deal with both OCS and IBM with some level of abstraction, deriving from multiple high-level discussions between product owners many months ago. Imho the 1st option makes more sense, but I don't see the whole picture here atįor context, I have to emphasize that the current backend design was taking into consideration scenarios outside of the UI, especially ones of headless automation. That we don't allow delete operation on StorageSystem CR (via k8s validation). StorageCluster first? Then we need to redesign most of the UI, and make sure
It will naturally occurs to them that to uninstall it, one need to remove Do we want storage admin to understand components of StorageSystem, so that Make it better representation of the storage system as a whole. Work with? Then we need to change the way who StorageCluster CRD works, and Do we want to have StorageCluster as the main resource for storage admin to Question is how do we want to resolve it: So it seems that the design of new CRD's and UI doesn't align well. While the StorageCluster is still there, it's basically hidden away so that Would also assume it's the right place to uninstall it. The user to understand the overall status of the storage system, and that one StorageCluster, and one would expect that this resource is the main point for Have StorageSystem resource clearly presented in the UI instead of "Create StorageSystem" button and wizard. Provides, and when you want to have a cluster installed, you go do so via In ODF 4.9, the operator advertises StorageSystem CRD as the only API it "remove" operation on the StorageCluster resource. If you decided to uninstall the cluster later, you used Then the StorageCluster resource is clearly present in
#Uninstall and yet it moves install
Important API it provides, and when you wanted to actually install OCS managedĬeph cluster, you used "Create StorageCluster" button to start "Create In OCS 4.8, the operator clearly advertised StorageCluster CRD as the most Mitigates this problem (quick and reliable way to remove storage system) toĪh, it seems that a root cause behind this problem is bit more severe andĬomplex, and that some design overhaul will be necessary. StorageSystem with different configuration. Whole cluster to be able to retry StorageSystem installation again or check
Way: instead of quick uninstallation of StorageSystem, we have to remove the This is declared as a test blocker since it slows down testing in a significant Uninstallation fails, StorageSystem gets stuck in Terminating state (see Initiate removal of StorageSystem via OCP Console. Wait for the StorageSystem to be installed.Ħ. Start "Create a StorageSystem" wizard in OCP Console web UI and completeĥ. Install OCS/ODF (OpenShift Data Foundation) operator.Ĥ. Version-Release number of selected componentĢ. This is a regression compared to OCS 4.8. It's not possible to uninstall ODF StorageSystem via OCP Console web UI.
0 kommentar(er)
