... | @@ -333,6 +333,13 @@ configuration management interface "creeping in" next to Puppet. The |
... | @@ -333,6 +333,13 @@ configuration management interface "creeping in" next to Puppet. The |
|
intention of this deployment is to have the absolute minimal amount of
|
|
intention of this deployment is to have the absolute minimal amount of
|
|
code needed to do things Puppet cannot do, not to replace it.
|
|
code needed to do things Puppet cannot do, not to replace it.
|
|
|
|
|
|
|
|
One major problem with Fabric is that it creates pretty terrible code:
|
|
|
|
it is basically a glorified Makefile, because we cannot actually run
|
|
|
|
Python code on the remote servers directly. (Well, we could, but we'd
|
|
|
|
first need to upload the code and call it a shell command, so it is
|
|
|
|
not real IPC.) In that sense, Mitogen is a real eye-opener and
|
|
|
|
game-changer.
|
|
|
|
|
|
## Cost
|
|
## Cost
|
|
|
|
|
|
Time and labor.
|
|
Time and labor.
|
... | @@ -501,29 +508,46 @@ mitogen only. |
... | @@ -501,29 +508,46 @@ mitogen only. |
|
|
|
|
|
The biggest advantage of transiliance is that it builds on top of
|
|
The biggest advantage of transiliance is that it builds on top of
|
|
mitogen, because we can run Python code remotely, transparently. Zini
|
|
mitogen, because we can run Python code remotely, transparently. Zini
|
|
was also especially careful about creating a simple API.
|
|
was also especially careful about creating a somewhat simple API.
|
|
|
|
|
|
The biggest flaw is that it is basically just a prototype with limited
|
|
The biggest flaw is that it is basically just a prototype with limited
|
|
documentation and no stability promises. It's not exactly clear how to
|
|
documentation and no stability promises. It's not exactly clear how to
|
|
write new actions, for example, unless you count [this series of blog
|
|
write new actions, for example, unless you count [this series of blog
|
|
posts](https://www.enricozini.org/blog/2021/transilience/use-ansible-actions-in-a-script/).
|
|
posts](https://www.enricozini.org/blog/2021/transilience/use-ansible-actions-in-a-script/). It might also suffer [second-system syndrome](https://en.wikipedia.org/wiki/Second-system_effect) in the
|
|
|
|
sense that it might become also complicated as it tries to replicate
|
|
|
|
more of Ansible's features. It could still offer a good source of
|
|
|
|
library items to do common tasks like install packages and so on.
|
|
|
|
|
|
### spicerack and cumin
|
|
### spicerack and cumin
|
|
|
|
|
|
The Wikimedia Foundation (WMF, the organisation running Wikipedia)
|
|
The Wikimedia Foundation (WMF, the organisation running Wikipedia)
|
|
created a set of tools called [spicerack](https://github.com/wikimedia/operations-software-spicerack). It is a framework of
|
|
created a set of tools called [spicerack](https://doc.wikimedia.org/spicerack/master/) ([source code](https://github.com/wikimedia/operations-software-spicerack)). It is
|
|
Python code built on top of [Cumin](cumin), on top of which they wrote a
|
|
a framework of Python code built on top of [Cumin](cumin), on top of which
|
|
set of [cookbooks](https://gerrit.wikimedia.org/r/plugins/gitiles/operations/cookbooks) to automate various ad-hoc operations on the
|
|
they wrote a set of [cookbooks](https://gerrit.wikimedia.org/r/plugins/gitiles/operations/cookbooks) to automate various ad-hoc
|
|
cluster.
|
|
operations on the cluster.
|
|
|
|
|
|
Like Fabric, it doesn't ship Python code on the remote servers: it
|
|
Like Fabric, it doesn't ship Python code on the remote servers: it
|
|
merely executes shell commands. The advantage over Fabric is that it
|
|
merely executes shell commands. The advantage over Fabric is that it
|
|
bridges with the Cumin inventory system to target servers based on the
|
|
bridges with the Cumin inventory system to target servers based on the
|
|
domain-specific language (DSL) available there.
|
|
domain-specific language (DSL) available there.
|
|
|
|
|
|
It is also very WMF-specific, and probably would be useless outside of
|
|
It is also very WMF-specific, and could be difficult to use outside of
|
|
that context. It does have good examples of how Cumin can be used as a
|
|
that context. Specifically, there might be a lot of hardcoded
|
|
library for certain operations, however.
|
|
assumptions in the code that we'd need to patch out (example, [Ganeti
|
|
|
|
instance creation code](https://github.com/wikimedia/operations-software-spicerack/blob/1a9aa78197d983b87756da38fe5a6414c16ef866/spicerack/ganeti.py#L229), which would then therefore require a
|
|
|
|
fork. Fortunately, [spicerack has regular releases](https://github.com/wikimedia/operations-software-spicerack/tags) which makes
|
|
|
|
tracking forks easier. Collaboration with upstream is possible, but
|
|
|
|
requires registering and contributing to their [Gerrit instance](https://gerrit.wikimedia.org/)
|
|
|
|
(see for example [the work anarcat did on Cumin](https://gerrit.wikimedia.org/r/q/owner:anarcat%2540debian.org)).
|
|
|
|
|
|
|
|
It does have good examples of how Cumin can be used as a library for
|
|
|
|
certain operations, however.
|
|
|
|
|
|
|
|
One major limitation of Spicerack is that it uses Cumin as a
|
|
|
|
transport, which implies that it can only execute shell commands on
|
|
|
|
the remote server: no complex business logic can be carried over to
|
|
|
|
the remote side, or, in other words, we can't run Python code
|
|
|
|
remotely.
|
|
|
|
|
|
### Other Python tools
|
|
### Other Python tools
|
|
|
|
|
... | | ... | |