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
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
|
* EASY put the type, moduleName, methodName, config set in
a dict - or possibly a real object - instead of passing all
these around in all functions
* MEDIUM expand config file format with <section> blocks so the
same set of properties can be repeated for, for example,
a streamer component
* MEDIUM expose a raw dv stream as a second feed on the firewire
producer and allow the disker to connect to it
* MEDIUM decide on style for properties in xml:
mount-point, mountpoint or mountPoint
some of these are gotten from glade file !
* MEDIUM add api for admins to "subscribe" to admin methods in the
manager, so only relevant commands get sent
* EASY deprecate <source> tag and require base= attribute to <comp>
* EASY rename components, files, ... to be uniform
(e.g. web-camera -> webcam, ...)
* EASY remove all old deprecated bundling code everywhere
* EASY don't throw up the disconnect dialog when exiting admin client
* MEDIUM give useful error messages when there is no network !
(service network stop and start flumotion and see hang)
* EASY move muxers in their own dir ?
* MEDIUM component.component overrides .error and calls reactor.stop(),
this is dangerous, figure that out
* MEDIUM allow expression of
"test component depends on streamer component"
ie. non-feedcomponent dependencies
* EASY change rawstring regentry type to string, and make
pipelinestring for pipelines which need \n translated to space
* EASY and force update every minute,
or when stats are different from last,
in http streamer UI
* MEDIUM integration with monitoring tools:
big brother: either:
* HARD transfer ALL code from manager
* EASY decide if bouncer's base authenticate method should always
be overridden and thus raise
* MEDIUM if you specify a converter with feedname other than default
and a consumer eating from that feed and change the source
to the same feedname, it fails.
* MEDIUM webcams can be I420, YUY2, or others; we should detect this
gst-plugins 0.8.6 will detect automatically since there is a
new option for autoprobe-fps which we can then use
use halogen
* MEDIUM add runtime checks for plugin versions to provide decent
fallbacks for bugs like this
* HARD split up source code layout according to bundleability
* EASY run with debug level 3 and make all messages "sane"
and symmetric
* MEDIUM implement cacheable Heavens for workers and components
to admin
* HARD work on proxyable state so that manager can initially create
it then send it to admin who then becomes master
* MEDIUM create Directed Acyclic Graph class and use it for
- bundle dependencies
- component dependencies
and possibly remove feederset
* MEDIUM allow inspecting and changing debug level on the fly of
every process. This way when a problem arises, before
stopping and restarting, we can increase it and retry to
get debug info
* MEDIUM allow placing markers in the logs, preferably in all
processes at the same time, same marker. Allows you to
keep track of what you are doing during debugging
* MEDIUM allow to collect logs from all processes everywhere,
possibly truncating older data or from older run, and
bzip it up, and send it for debug
* MEDIUM add and test a feature allowing you to start a python shell
from the admin UI into any worker or manager
helps ENORMOUSLY in debugging strange errors at a point
where the system is broken - like AlreadyConnectedError
* MEDIUM merge before_show and worker_changed in wizard, since they
are pretty much the same anyway
* MEDIUM split out wizard steps into their component directories
* EASY add worker checks to all wizard steps now that infrastructure
is there
* MEDIUM refactor createComponent to be a real constructor
* MEDIUM make sure the entry point specified in xml is used instead
* MEDIUM when creating components in jobs, get the actual avatarId
in there in some other way than putting it in the config dict
* EASY change RequesterName to RequesterId
* MEDIUM block a feeding gst port, and have something eat from it ->
hangs in connect. kill it -> process stays around
* MEDIUM clean up ambiguous naming in registry/wizard code
e.g. registry.getComponent -> getComponentEntry (it's a
template for a component, not an actual component)
* MEDIUM flumotion.common.registry: ewww @ RegistryEntryEntry
rename generic Entry to Node ?
* MEDIUM allow the manager to reparse all known config files; easier
than restarting manager and all workers
* MEDIUM run all worker checks in a spawned process - segfaults are less
painful that way. maybe even start a job for it always
* MEDIUM when a component segfaults, have the worker tell the manager
that the component segfaulted and make it sad; maybe even allow
attaching gdb and filing a bug report
- API cleanup:
- manager/component.py:
- create/remove Avatar -> summon/expel
- work on only name or only component, so there is a clear API distinction
- name all arguments used in functions that are the same, with the same name
- rename components to avatars, and rename functions accordingly
- make an executable script/program that makes all required checks and
outputs a report, has a proper zero or non-zero exit status and
can't run forever if things are stuck (times out properly)
http component
- multiple sources
- rate limit
- make an http URL return a 2xx code when it works or a 5xx code
when it doesn't
- check for StringIO requests instances, which Twisted 1.3.0 implements
|
