FoswikiVagrant Development

This is the topic to discuss development of FoswikiVagrant

If you need support, go to Support.FoswikiVagrant where you can ask questions and find answers to previously asked questions. If you want to report a bug, or a feature request, go to Tasks.FoswikiVagrant where you can see already submitted issues and where you can submit a new bug report or feature request.

Active Items

Discussion

This project was originally started as EasyDevelopment using vagrant to enable a new (or even an experienced) FW developer a fast way to set-up an up to date Foswiki and contribute back to the project.

It's potentially a substantial workload therefore it's important to take this (and deliver something useful) step by step — indeed even initial EasyDevelopment work is being kept simple :

1. Ubuntu (Debian has been tested)
2. VirtualBox for the VM
3. Git based install (i.e. pseudo-install)
4. Full Fat install (all usual suspect extensions and maybe even more)
5. VM is completely clean with Foswiki the only web-service

It's become clear that the use of vagrant to quickly create a virtual machine on which Foswiki is ready to go (& manage) is very useful in a number of cases:

1. EasyDevelopment
2. Full Dependency Management
3. Enterprise/Continuous deployment
4. Integration with Ansible/Chef/Puppet etc
5. Continuous Integration
6. Bare Metal Install

It's important to realise that there is a lot of common ground here despite the differences.

The following will now discuss each case in more detail.

Easy Development

The basic concept from which the rest is growing, see EasyDevelopment for more details.

Full Dependency Management

EasyDevelopment currently has an option to choose Apache or Nginx. This really should be part of a dependency management system which knows to install one or the other and the related components that do or do not need to be installed.

This naturally extends to all Foswiki extensions knowing which further extensions to install and/or the appropriate packages (or cpan modules) of the relevant distro.

configure options are also dependencies which may infer other configure options are required or desirable or even further extensions need to be installed. Conversely, installing certain extensions infers certain configure options need to be set especially when used in conjunction with other extensions.

We often talk about optional items in our Foswiki dependencies when in practice they are conditional dependencies.

The existing configure code already contains some dependency management and the intent is to build on that work and improve it. It's seems to me that the Config.spec files and DEPENDENCIES files should be merged into a unified whole, probably in JSON. However, that will need more consideration.

A lot of existing work has been done in IT in general to solve the dependency management problem and also in the perl world in particular. We do need our own unique FW wheel as we are unique in some respects. Nonetheless, we can learn as much as possible from the principles and concepts that have already be learnt.

A current simplification is that we are only building on Ubuntu with a known base on which we install further options. If we wish to install on any distro in possibly any initial state then we will need more sophistication.

Enterprise/Continuous deployment

From the FoswikiCamp2015 is became clear that an important business driver is the need for rapid and low-cost updates to the latest FW software.

I have already been able to upgrade to the latest FW quickly and easily via git pull followed by restarting the relevant service and that's it. In these simplest of cases the changes are to the FW code only (e.g. perl scripts/modules, templates, javascript and css). A change requiring an impact to the underlying OS/Config/Services would need more than a git pull.

As a discussion point it could be argued that a 2.0.x release should be for bug fixes which impact FW code only; a 2.X.0 release for minor feature and/or bug fixes that impact FW code and/or the underlying OS/Config/Services and X.0.0 release for major features that are disruptive (i.e. break the broader API and/or require tools to convert the existing install in some way).

If this were agreed then a git-based pseudo-install ed site would already be able to use continuous deployment. As full dependency management matures this would extend to 2.X.0 releases and even X.0.0 releases if the conversion tools could be included in the dependency management.

Integration with Ansible/Chef/Puppet etc

When full dependency management is complete then this is hopefully a case of these tools calling a Foswiki install/upgrade tool to do all the work. Alternatively, the script may talk back to the tools informing it of changes required to the underlying OS/Config/Services and the FW install/upgrade tool (i.e. configure CLI?) completing the work.

A variant of the is a tool to generate the required Ansible/Chef/Puppet scripts(s) which are used to upgrade the underlying OS etc. and then call a Foswiki install/upgrade tool to complete the work.

Ultimately, I do not see how any of these tools can install/upgrade FW without them being extended in some way to know about FW dependencies. Ideally, we can defer to a FW tool and have minimal need to support these tools. However, I do not know how these tools are constructed and their design philosophy so exactly how this will pan out remains open.

Continuous Integration

With a mature FW install/upgrade capability it should be a relatively easy step to bring up various VMs with different configurations and run all the tests.

Note that this would not only be running the standard FW unit tests against various configs, but also that the related DEPENDENCIES and Config.spec files do not contain bugs. That is to say that the VM will not build correctly and the test failures would reflect that. As these dependency type files would also be part of the relevant git repositories they will of course be covered by good SCM practices.

Bare Metal Install

This actually also relates to running a FW install/upgrade tool on a VM in any state and the tool being able to correctly perform the necessary changes to the underlying OS/Config/Services and also install the correct FW code and extensions etc.

It is not clear how smart we can really make the tool it may be too tall an order; it will certainly be a challenge.

Commenting is disabled while not logged in