On dt., 2021-03-23 at 15:04 +0000, J-M Roth wrote:
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
This is in the works, here you can see how this will be implemented and
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
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
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
* 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
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
* 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
- Show a warning if product does not exist at all (instead of green,
- Reboot required could be shown in that same list (like after an SP
- 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
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
Probably this is not fixable, still it was something that caught our
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.
Pau Garcia Quiles
SUSE Manager Product Owner & Technical Project Manager
Phone: +34 91 048 7632
SUSE Software Solutions Spain