-
Notifications
You must be signed in to change notification settings - Fork 223
Ideas for Rex 2
This is just brainstorming.
This is a page to track all the ideas what can be made different with the 2.x version.
These ideas can contain everything, for example:
- code
- perl modules to use
- the syntax of the Rexfiles (which doesn't necessary mean that we will break compatibility, just to see if there are cool ideas)
- OS support
- Rex modules (Rex::Box, CMDB, ...)
- documentation
- testing
- anything else
Some of these points here may be implemented sometime, while others may not.
The first release of 2.x is planned to happen somewhere in 2015 - no exact plans or dealines though.
This will not make the 0.x/1.x version obsolete. The 1.x version will be maintained and supported until at least 2017-03-31 (EOL date for RHEL/CentOS 5).
- Object Orientation System:
- boolean for better boolean handling, especially for JSON/YAML
- perl5i
- true for auto adding "1" to the end of files
- File::Rsync - see also #35
- easy to install and use
- easy to extend with custom modules
- easy to read the source code, even if new to perl
- transport mechanism should be modular, so that it is possible to use other transports than ssh (for faster runs)
- can be used as library in own scripts
- with default usage, no dependencies on the remote host (except for a normal perl installation, and a running sshd)
- An offical and powerful webui (in progress, see Rex-JobControl)
We need an architecture where we can replace each layer with new (or other) code without affecting other layers.
- different layers encapsulating
- DSL
- connection handling
- resources
- state handling
- reporting
- execution
We need to have multiple connection methods (SSH, Rex Agent over SSH (like rsync), zeromq, ...).
We need to have a central state handling, so that we can query the resources (and build dependencies on resources) from other systems.
Resources exists of a resource function (like pkg()) and at least one provider. A provider provides the ability to execute the resource for a given "thing". For example a package provider for "apt", "yum", "zypper", "cpanm", ...
All resources should be monitored and generate reports for the changes they have done. The reporting interface must be extendable. So that it is possible to connect the reporting to any system.
The error messages needs to be better understandable. Some modules that may help:
- pluggable logger, so that one can use Log::Log4perl or Log::Handler or sth else...