-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On 03/19/2017 07:49 PM, Marek Marczykowski-Górecki wrote:
> On Mon, Mar 20, 2017 at 12:08:15AM +0000, Unman wrote:
>> On Sun, Mar 19, 2017 at 05:31:05AM -0400, Jean-Philippe Ouellet
>> wrote:
>>> Hello,
>>>
>>> I am not criticizing the choice of salt, I am just curious
>>> about why exactly it was chosen over the alternatives. From the
>>> list archives it appears that it was just suddenly being worked
>>> on, and I'd be interested to know what lead to choosing it
>>> instead of {ansible,chef,puppet,etc.}. I could not find any
>>> public discussion on our list archives evaluating their
>>> relative merits.
>>>
>>> Regards, Jean-Philippe
>
>> I suspect that, as with Fedora in dom0, it was what the
>> developers were comfortable with. There have been discussions
>> about other management stacks, and some proposed solutions, but I
>> haven't seen many of those since salt was adapted to Qubes.
>
> See here: https://www.qubes-os.org/news/2015/12/14/mgmt-stack/
>
>> From all the available projects, we have chosen Salt Stack,
>> because of its wide adoption, ability to run without any network
>> service (“local” mode), clean and easy to read configuration, and
>> ease of extensibility (python API for modules). In addition, it
>> has the ability to manage (possibly remote) system which doesn’t
>> have Salt stack agent (“minion”), a mechanism known as salt-ssh
>> (which in fact isn’t that unique to Salt Stack). With Salt Stack,
>> we have implemented a module to handle Qubes configuration,
>> specifically managing VMs.
>
> An alternative we've considered was Ansible, which is also wide
> adopted, but finally decided for Salt mostly for two reasons: -
> Salt syntax (in our opinion) better encourage to write declarative
> configuration (describe desired system state, not a sequence of
> actions to perform) - we (mostly nrgaway at that time) were more
> familiar with Salt architecture
>
>
I'm been poking at an implementation for Ansible currently:
https://github.com/kulinacs/ansible-qubes
In contrast to the current solution by Rudd-O, I'm attempting to avoid
any dependencies outside qubes-core-admin and Ansible itself. I
wouldn't recommend use outside of testing yet, but I have yet to have
any problems with it. It's more or less just a combination of
qvm-create, qvm-prefs, and qvm-remove at the current moment, driven by
Ansible. The next things on my list are an Ansible transport module,
which will hopefully mimic qubesctl, and qubes-prefs, with the end
goal of having 1:1 feature compatibility with qubes-core-admin.
- --
kulinacs <[email protected]>
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCAAdFiEEPL+ie5e8l/3OecVUuXLc0JPgMlYFAljRzVcACgkQuXLc0JPg
MlbTmw//Wf5EVVNEVV9auK607l2YlG+7R4EsrvWdvuOltnZ6Zc5cywmk67DyIa6x
PnVA0LZXv14owMoPsxcDl9VtJKCoHp+aBao8FwXtZqimLA4lu1/68LF1/SCVb2zp
eBLgRYN1YbTAevZOPHGDQ4blfDgJdnRN3Wc3834S08IZLpWSuML9AH08UyOfzKEE
QGkLU+GPj0Bq5p7uZourJTvS0+dmquDeazVWPN+klMpuWLkrQ9QkhVJbOA0oX3JX
PW6A0Qdmbvha+kD6ugyckfwHvRpkfjYLoXlRQUupK3HKdXANfyjK1FSn/JdMc5EU
xt4scKi0dkvQdrZwPNC9VUUB0yTPeK47X/DVamx9l9gyy6hidh9qqwwsUlIywNaS
l2GpzNxW5pWU89/J9Sf0p3egZYKGHG0uzPcRy2+5TnuLWlcXVdL6VZTwt/5CwAfv
cfxMPeWED95PZ3d4OQdE3rdkUzcyBz8n1BbjULQiHhE6CsNTYnS8lde9rtFHAQmL
JPqnYtvOq+24AGJ7FOQ7TZfFaV5wpsmVAGE6NtEyawaz3zfa79FdwCK7TpgU3FLt
FPD6RqunnSM80T3sRmOP0lQM3IdUkYFPBXLhTileeTJv2/BvIJdwwAjnw1/yR478
gLCKl8NriwtPMGUASDRdsnSXSKn5K/s9l9eubGkmY9Ejl5jiqdM=
=P4oj
-----END PGP SIGNATURE-----
--
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 [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/qubes-devel/eabd6f28-5ef3-2cbd-032a-92268c1740e2%40kulinacs.com.
For more options, visit https://groups.google.com/d/optout.
