mirror of
https://github.com/valitydev/salt.git
synced 2024-11-08 01:18:58 +00:00
241 lines
7.2 KiB
ReStructuredText
241 lines
7.2 KiB
ReStructuredText
==================
|
|
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.
|