> In my experience, most users are able to get a grip on using salt fairly > quickly
I suspect you have a biased sample or that said users are not experimenting as heavily as I am. But I am not experimenting that heavily: I'm doing things like trying to copy files with files.recurse, and change file_roots to a directory under /home/user. > It would help if you explained what the source of your frustration is, > and so what could be improved. Firstly, there are some Qubes issues, such as files.recurse permission copy and changing file_roots to somewhere outside of /srv not being supported. But the main issue is the error messages. As Marek has also experienced, often when SALT fails, no error message is displayed. When I did get a stack trace, it was often followed by "During handling of the above exception, another exception occurred". As for what could be improved with Qubes, I think we have a lot of things going on that don't need to be going on and it causes confusion. Some super simple features are, IMO, obfuscated. For example, to enable a top file, you just drop it (or a link to it) in /srv/salt/_tops/base or /srv/salt/_tops/user. To add user states, you simply drop them in /srv/user_salt. That's all great! But then instead of just using those, we have top.enable and state.sls qubes.user-dirs. Those two commands together, along with issue #9885 caused some people, myself included initially, to think that user_dirs should be enabled. The addition of SALT environments, along with how they are set up to work with Qubes and the lack of documentation about such, is also confusing. I would expect if we have two different environments, that they would be totally separate and that adding saltenv=user would run only the user states, saltenv=base would run only the base states, etc. In reality, it seems that running all envs and running with saltenv=base will both pull in user SALT states enabled by top.enable but not user SALT states defined in /srv/user_salt/top.sls, whereas running with saltenv=user will only look at user's top.sls file, but not the user states enabled by top.enable. It seems that because /srv/salt/top.sls pulls in files from /srv/user_salt/, the environments get mixed and we end up with issues like #9916 where modifying the user env causes the base env to fail with error 20 and no error message. I suspect its because of the same error as in #9985, but its hard to tell because there's no error message. Another random issue is that top.disable <state that does not exist> throws a stack trace. It even sometimes throws a stack trace when the state does exist. Issue #9915. The real question though is should developers target Ansible? Why keep targeting SALT if we are hoping to slowly phase it out? Or is the Qubes' team of two minds as to whether we're moving to Ansible or not and want to try it out a bit before committing? #9885: https://github.com/QubesOS/qubes-issues/issues/9885 #9915: https://github.com/QubesOS/qubes-issues/issues/9915 #9916: https://github.com/QubesOS/qubes-issues/issues/9916 -- -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/qubes-devel/87bjsihh41.fsf%40zazbrown.com.
