==================
Salt Stack Roadmap
==================

Salt is the core of a more complete goal, the Salt Stack. The Salt Stack is a
complete infrastructure management system which is comprised of many
components all functioning on top of Salt.

The majority of the functionality of the Salt Stack happens directly inside
Salt, but the information derived from Salt needs to be used to create a
transparent view of the infrastructure as a whole.

The information used in Salt States will be matched via a higher interface
and the low salt data will be visualized. This will allow the state data to
appear in the web interface.

The features listed here are only listed based on major version releases, the
plan is to have a clear long term goal but not to overly dictate the flow
of development. The project needs to be flexible enough to be able to receive
new features at a moment's notice. This model should spur ideas and make
allowing new community developers to join without issue. So just because
something is slated for a later reason does not mean that a developer is
going to have their code rejected or stalled.

1.0.0
=====

1.0.0 requires that remote execution is stable and that states are ready to
complete. We mostly just need to clean things up for 1.0.0.

Clean up code base
------------------

Go through the code, clean up PEP 8 violations and make sure we have
Python 3 compatible code.

Module Cross Calls
``````````````````

Many instances of using functions when we should be using module cross calls
exist in the code. Mostly from modules which were written before cross calls
were around. The big thing to look for are subprocess calls, since they should
all be running with the cmd module.

State Return Data Cleanup
`````````````````````````

The return structures in the state modules need to be uniform in how they are
declared, before we get too much of a following we should have as consistent
modules as possible. We want to hit the gate with very clean code!

States and Modules
------------------

More states need to be available.

User State
``````````

The user state needs to be expanded to support password setting and managing
the finger component

Clean up Bugs
-------------

We are finding a number of bugs in the new state system as we get more testers
there are a few bugs that been attention:

#66

We need to keep pushing through testing states on live systems and find as
many bugs as possible before 1.0, we have found too many 0 day bugs.

Documentation
-------------

The documentation has gotten a LOT better, but we still need more work in a
few places

Clean up formatting
```````````````````

The 1.0 PDF needs to be a document that we can publish to the world with pride

Expand the State Tutorial
`````````````````````````

We are learning a lot about how to teach states, we need to take this knowledge
and improve the states tutorial. We want people to be able to get going with
states in no time at all

Module Built in Docs
````````````````````
Double check all of the module built in docs for consistency. Make sure things
are clear and accurate.

Proposal System
---------------

I would like to have a proposal system in place for Salt, so that
community members can submit proposals for feature development for
review. Using Github's new issue system with support for tags
(blocker, feature...) seems like a good choice.

Workflow
--------

Gitflow not only makes for a good branching model everybody can
understand and work with but also scales well and just works (tm).
Let's start using it!

2.0.0
=====

2.0.0 will require a number of serious additions and overhauls. We wand to make
the transport layer much cleaner and clean up the crypto dependencies.
Figure out how to get more speed out of Salt and make it more memory
efficient. The security system needs some additions to make it more
secure.

There are also a number of features that should be pulled out of their classes
and made to stand alone. Also we want to MASSIVELY improve platform support and
module/state penetration.

This is only a subset of what we can expect 2.0.0 to be!

With 1.0.0 salt is a great option, with 2.0.0, using anything else is just plain
dumb!

Python 3 Support
----------------

The goal so far has been to write Salt with 3.0 in mind, but with 2.0
we want it to be a reality. This will mostly require that the
requirements are met.

Refine Security
---------------

Only One Crypt Backend
``````````````````````

Right now we have pycrypto and m2crypto, we need to pick just one. So far
the plan is to dump m2crypto and use just pycrypto.

Make the iv explicit
````````````````````

Right now the iv is implied by the length of the AES key, we want the iv to be
randomly applied and sent with the AES key.

Master Signatures
``````````````````

There is a theoretical vulnerability in the validation of transit messages, they
need to have a master private key signature somewhere.

Change Network Serialization
````````````````````````````

Right now it is pickle, this needs to be changed to something more
standard like JSON or maybe even something simpler/faster such as
tnetstrings as used by Mongrel2. We also need to change how messages
are formatted to speed up the serialization and lower network usage
more. A new model will be proposed.

State Generator
---------------

Since the state system is based on data structures we can generate them from
a uniform API, this needs to be available in renderer modules.

Separate out the File Server
----------------------------

Te built in file server should be less built in. We will make a standalone file
server from the existing built in one that is more powerful and can be used
with and without encryption and authentication. The updated file server should
also be faster, so that large files can be downloaded more quickly.

The salt-cp command needs to be moved to use the file server as well, so that
it can be used to copy large files as well.

Support for more Platforms
--------------------------

Platform support means a few things, primarily that we have support for the major
modules pertinent to the platforms and that Salt will run on these platforms at
least as a minion.

Solaris
Gentoo
Suse
Slackware
OpenBSD
NetBSD
AIX
HPUX
Windows

Language Library Modules and States
------------------------------------

Modules and States that support installing programming language packages.
Here is the list to start with:

pypi
rubygem
cpan
lua
haskell?

Firewall Support
----------------

This is going to be rather serious, this is a collection of modules for
iptables, pf, and the subsequent subsystems for other platforms. But in the
end, we want seamless firewall support for at least opening up ports for
services.

Advanced Grains
---------------

The grains system still needs an overhaul, the problem is that grains should
have access to each other, but they should still only be run once. Some plans
are in place to pull this off, but they need to be implemented.

More Renderers!
---------------

The renderer system needs to support more templating engines and language
bindings. Adding support for XML, Cheetah, Tenjin etc. will be simple. But
the main goal here is to allow sls files to be written in Ruby, Lua, Perl or
basically anything.

Unit Tests
----------

Need unit tests in place for everything, we are planning on using
Unittest2 and pytest.
