Suma feedback / potentital enh requests
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: * 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. * 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. * 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. * 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. * 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 * 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. * 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. Best regards, J-M Roth
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
Hello, Pau Garcia wrote:
On dt., 2021-03-23 at 15:04 +0000, J-M Roth wrote:
* 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. ...
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…
That rfc describes and seems to address the issue pretty well.
* System shows ok if there are non-compliant packages.
Do you think showing a yellow warning icon would be an acceptable solution?
I think this could be handled together with what I propose below, if it finds acceptance:
* 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.
Thanks, let me however go into more detail here. The global system list is largely update-centric currently, so it will almost always show red or yellow in the "Updates" column since the systems are never totally up-to-date, compared to the online repos at least. This may be different if you use Content Lifecycle. In other words, "Systems > System List > All" is mostly the same as "Systems > System List > Out of Date" all the time. Even the columns are identical in both views. The goal here would be to have "Systems > System List > All" provide a more holisitic overview of all managed systems. I've taken the liberty to use my modest image editing skills to illustrate what I mean more or less: https://pasteboard.co/K02UnR6.png Host 1: There are critical updates (red U), also it contains non-compliant packages (N-C). Host 2: This host has expired (the are no new patches / EOL). Host 3: No information for this host could be found ("(none)"). Host 4: This host is OK regarding all the mentioned criteria, however it requires reboot. Also, states didn't apply correctly lately. One should make sure that users are not experiencing an epileptic crisis when viewing this screen though. Maybe options could be included that would allow disabling display of the secondary states like non-compliant packages or state application failures on this screen. I'll leave this to UX experts.
* 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.
I mean the internal channels, not the repos. For the internal channels to contain up-to-date information, they have to be synced from the repos either manually or via schedule on Software > Manage > Channels > channel > Repositories > Sync. Currently, the list at Software > Manage > Channels only shows the channels and how many packages they contain. It does not show if they are up-to-date or when they were last synced. That information can only be obtained by drilling down into each of them manually one-by-one. The Channel Overview page could simply contain more columns with more details about the individual channel state (like the last synced time). It's a small usability fix. Best regards, J-M Roth
participants (3)
-
J-M Roth -
Marki . -
Pau Garcia