On dt., 2021-03-23 at 15:04 +0000, J-M Roth wrote:
Hello,
We've been in contact with our Suse Account Team after evaluating and getting a Suma subscription to show our support. First, congrats, the product seems pretty stable, usability is high (GUI is very reactive), it is well-integrated with Saltstack while at the same time providing interfaces for customization. Concerning potential feedback and enhancement requests they told us to come here. So here is my current list:
Hello Jean-Marc, thank you for your feedback!
* VERY DANGEROUS: Using groups: It is not clear from the system view that a state/config channel is applied to a system via a group.
If a system is managed through a group, that should be made clear on the Systems > system > Configuration > Overview screen and also Systems
system > States > Configuration Channels screen of that individual system. This is _very_ dangerous because applying a highstate might do unexpected things since the system is mostly invisibly part of a group.
In the same way, Configuration > Channels > channel > Systems does not show that the currently selected channel applies to any group (or a list of systems expanded from the group, for that matter).
It looks like groups were retrofitted, this really needs to be cleaned up.
This is in the works, here you can see how this will be implemented and some mockups: https://github.com/uyuni-project/uyuni-rfc/blob/master/accepted/00076-state-... Feel free to provide feedback, that will help us immensely.
* System shows ok (up-to-date) if product does not exist at all.
If you add a system for which the product is not mirrored to Suma at all, the "Updates" column of System List shows a green checkmark while the "base repo" column shows "(none)". The green checkmark is misleading, at most there should be a grey icon or so meaning that there is actually no info.
What operating system is the client system running? I can imagine this happening for SLE 15, maybe even for openSUSE Leap, when you register them as Salt clients. For any other client, this should fail because of missing client tools. But you are right the status report is not correct. Could you please file a bug report via Support? That way you will be able to track the resolution.
* System shows ok if there are non-compliant packages.
A green checkmark appears in System List if system contains non- compliant packages (Systems > system > Software > Packages > Non Compliant). The system list could somehow reflect the presence of non-compliant packages. These could for example pose a security risk.
Do you think showing a yellow warning icon would be an acceptable solution?
* Very old OS release shows as ok/up-to-date.
For example, a fully patched SLES11-SP1 is shown with a green checkmark. Technically, this information therefore correct. However, in reality, the OS has been end-of-life for several years. It should show something other than the green checkmark which is creating a false belief that the system is ok while it should be replaced.
Certainly it would not be impossible to look at for example the release date of the latest patch. If it's too old, there can be a warning.
Ideally, a warning like that should be based on EOL information. I'll add this to the backlog, seems useful. I suggest you file a feature request via Support, that way you will be able to track the progress.
* In general, the system list/overview page could provide an even more holistic view by making more distinctions in the "Updates" column (or adding another "Status" perhaps) - Show a warning for very old OS (see above) - Show a warning if system contains non-compliant packages (see above) - Show a warning if product does not exist at all (instead of green, see above) - Reboot required could be shown in that same list (like after an SP migration) - State apply failures could also reflect in that list
I'll add this to our usability backlog. Again, if you file a feature request via Support, you will be able to track the progress.
* Suma bootstrapping does not recognize enabled modules/products
If the system being onboarded was previously registered to SCC, SMT or RMT, the previously enabled modules (for example SDK or Web- Scripting-Module etc.) are not automatically activated, even if Suma has correctly mirrored them. Instead, you have to compare which modules were used previously and perform manual actions to add them again.
Probably this is not fixable, still it was something that caught our attention.
The technical solution is not necessarily complex (can even be scripted in the bootstrap script) but this poses a "phisosophical" problem: if the sysadmin who registered the client with the Server decided to enable only channels X and Y, should channel Z be enabled too just because it was enabled before that client machine was brought into management (i. e. while it was "in the wild") ?
* Software Channel Management
Software > Manage > Channels page could show the sync policy for the individual channels. Currently there is no overview of the sync policies of the individual channels. You have to click on each one, open it and take a look.
If I understood you correctly, you should be able to find that information under Admin > Products > Products. There are icons showing whether a base channel and all its child channels are synchronized. Thank you Pau Garcia Quiles SUSE Manager Product Owner & Technical Project Manager Phone: +34 91 048 7632 SUSE Software Solutions Spain