Small repository who’s responsibility is to maintain a Vagrant workspace so we can work locally on webplatform/salt-states.
Use-cases
In production we pull external formula using gitfs_remotes but we can’t edit them in production.
We should be able to work on them locally as simple repo clones.
In production some services runs in containers (i.e. Docker/lxc).
We need to be able to build/maintain them in the same configuration as in production.
In production, we build packages so that we don’t need to compile them at creation time (i.e. no make, no pecl install, etc).
We need to have a workbench where we can pull packaging tools such as fpm and build-essentials so we can make .deb files and production only extracts them
In production we rely on many VM types, but to develop on them we always had to use an external provider.
We should support to add any number of local Vagrant VMs and treat them as if we were on DreamCompute/OpenStack.
Working on states always had been about working from the salt master. This can create problems if somebody else comes in and runs highstate without looking if something isn’t completed.
We should be able to have a set of git repos all in place, in the same setup as production, but locally and remove the potential of human errors.
Tasks
List of external saltstack formulas, pulled in as file_roots so we can work on them
Workspace utilities to load [python, nodejs, php, ruby] packaging dependencies
Make the source repos clones on the host machine but mounted into the vagrant "workbench" so we can trash it and rebuild anytime.
Small repository who’s responsibility is to maintain a Vagrant workspace so we can work locally on webplatform/salt-states.
Use-cases
gitfs_remotes
but we can’t edit them in production. We should be able to work on them locally as simple repo clones.make
, nopecl install
, etc). We need to have a workbench where we can pull packaging tools such asfpm
andbuild-essentials
so we can make .deb files and production only extracts themTasks