forked from natea/collective.hostout
-
Notifications
You must be signed in to change notification settings - Fork 7
/
TODO.txt
62 lines (37 loc) · 2.61 KB
/
TODO.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
Todo list
*********
- ask the user before doing any bootstrap operation
- don't require sudo-parts or any other sudo command on a normal deploy. Deploy only via key
- import fabfiles so they don't produce warnings
- fix bug that packages every egg during hostout
- fix tests
- [DONE] move ubuntu redhat etc into collective.hostout. Enable ability to detect hostos.
- make a more explicit commandline (argsparse). make more similar to fabric cl
- optionally use rsync for buildout and include files. This will make django deployment usable.
- [DONE] finish bootstrap from source that works on any kind of linux
- [DONE] use decorators for picking user for commands instead of initcommand hack. new fabric should help here
- make generic init.d installer so hostout.supervisor can use this
- implement api.env.super.somemethod() to allow an overridden command choose if it wants to run
the command it overrode or not.
- hostout.plone for database handling including backing up, moving between development, staging and production
regardless of location.
- Integrate with SCM to tag all parts so deployments can be rolled back.
- Handle basic rollback when no SCM exists, for instance when buildout fails. For instance
make a log file of each deployment including all versions that were deployed. Version each buildout.cfg
sent to the server so as long as the egg cache is the same, you can rerun an old buildout.
e.g. bin/hostout host revert ~1
- Help deploy DNS settings, possibly by hosting company specific plugins
- Support firewalled servers by an optional tunnel back to a client side web proxy. Would also make
more reliable. Can use Egg proxy locally and parimoko should allow tunnels I hope.
- Explore ways to make an even easier transition from default plone install to fully hosted site.
Integrate zopeskel or similar create a production.cfg. Could do the same for wsgi or django.
Perhaps ploneboutique can help here
- Ensure we can support workflow where no hashed packages are used and instead a private egg cache is used and version
numbers have to be incremented to make a release
- create a command to download a remote buildout, including pinned versions and develp eggs.
- hide extra output unless verbose mode is used. look at mr.awesome code for this
- get hostout.cloud working for micro ec2
- dry run feature. Show combined fab commands before with actually running them. help developers decide
if they want to use the system or not.
- need to handle case where multiple buildouts on one machine have different buildout users. buildout cache
permissions then becomes an issue. maybe need buildout-cache group.