On 04/ 6/10 12:07 PM, John Fischer wrote:
All,
Here is the first draft of the AI Webserver design document.
Thanks to Ethan, Dave and Clay for their help in getting the
ideas, thoughts and design thus far.
Feedback appreciated,
Feedback below. Apologies for not noticing a couple of these issues in
earlier discussion.
Dave
1. Purpose
Could be a bit more verbose about the goals here, which would seem to be
about scalability, reliability and maintainability of the server.
There's nothing said here about the need to improve SMF's ability to
detect and recover failures in the service, for example, but there
should be.
2. Assumptions & Dependencies
- I would really expect to see some measurements of the overhead for the
cgi-bin approach before asserting it's insufficient. As I've noted in
the past, the criteria resolution seems to be a very minor piece of the
puzzle in terms of overall boot and installation performance in AI.
- Overall, I'm somewhat less concerned with up-front implementation cost
and more concerned with long-term support cost, both in terms of the
amount/complexity of code and the operational complexity (and thus
reliability) of the solution once deployed. If re-writing is better
from that point of view, then it should be considered rather than being
assumed out of scope.
- Not sure we can make any assumptions about what the apache group would
do. It seems reasonable to assert that any additional modules might be
packaged completely independently from apache (indeed, I'd think that
preferable) and so the dependency seems soft at best.
3. Solution
The overview subsection asserts that mod_python will be used, but then
in Considerations ModWSGI is stated to be the best solution. Components
also asserts mod_python.
Also in Overview, I don't understand why choice of port number affects
the number of properties on the services?
ModProxy is discussed twice in Considerations.
Considerations asserts the cost of cgi without supporting data. We're
using cgi to serve up other, larger hunks of the network boot
environment, so why is it inappropriate here?
A consideration that seems missing is whether & how we would secure the
manifest traffic in a future fully-secure WAN installation environment.
The wanboot infrastructure provides for authentication and encryption,
though we presently do not configure it in AI. However, this is a
likely future enhancement and I'd like to understand how your proposed
solution would integrate when we do.
Contraints - I don't see the need to differentiate between OpenSolaris
and Solaris here.
SMF AI server service - what's the justification for retaining the port
number and log file on each service? Do we need this flexibility?
AI Client - I see some dissonance here. You're proposing a modification
to the client (hence making an incompatible change to the protocol?) but
have bent over backwards on the server to provide compatibility with
existing services. But if we don't back-port the protocol change to the
older clients (which doesn't seem to be proposed), how will that work?
If a back-port is required, then why bother with the server compatibility?
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
