Hi all,

I have long been managing some of my tools using non-interactive
provisioning scripts − historically using Shell [1], and increasingly
moving towards Ansible playbooks [2] [3].

Both methods boil down to:
* SSH onto bastion host
* `become tool`
* Execute steps: git pull, install dependencies,etc.

I have not always been able to fulfill my 'non-interactive' requirement.
For my projects which require Node dependencies, I did have to manually
drop into a shell (webservice --backend=kubernetes nodejs shell) in order
to run npm.

(I also had a bit of a hard time when trying to manage crontabs using
Ansible, as  the `crontab` executable override seems to be doing all kinds
of magic − I kind of tinkered until I reached a "looks like it works!"
point ^_^)

As I was reading through the Trusty migration docs [4], it is somewhat
hinted that virtualens (for Python dependencies) should also be installed
in an interactive container shell, and not from the Bastion host [5].

Can someone help me with the following questions?

* Is it appropriate to create python virtual envs from the Bastion host?
* Is there a recommended way to execute inside a kubernetes container
remotely / in a non-interactive fashion (eg using a tool like Ansible)?
* in general, am I doing something fundamentally at odds with the Toolforge
environment with such configuration management?

Thanks!

[1]
https://phabricator.wikimedia.org/diffusion/THER/browse/master/bin/build-python.sh
[2]
https://phabricator.wikimedia.org/source/tool-wikiloves/browse/master/deploy/main.yml
[3]
https://github.com/JeanFred/universalviewer-toolforge/blob/master/deploy/main.yml
[4]
https://wikitech.wikimedia.org/wiki/News/Toolforge_Trusty_deprecation#Rebuild_virtualenv_for_python_users
[5] https://phabricator.wikimedia.org/T214086#4890276
-- 
Jean-Fred
_______________________________________________
Wikimedia Cloud Services mailing list
[email protected] (formerly [email protected])
https://lists.wikimedia.org/mailman/listinfo/cloud

Reply via email to