Dave and Ethan,
The current design does not mean that adding an additional round trip
is precluded from future enhancements. If that is needed then it shouldn't
be that difficult to add it in.
Should I change the current design for this round trip?
Thanks,
John
On 05/18/10 02:57 PM, Dave Miner wrote:
On 05/18/10 05:41 PM, Ethan Quach wrote:
On 05/18/10 12:18, Dave Miner wrote:
On 05/18/10 03:12 PM, Ethan Quach wrote:
On 05/10/10 14:11, John Fischer wrote:
Dave,
Man, I can't sneak anything by you. :-)
You're right. I should have been more explicit with that change as
well.
I'll add something about it in the next version of the document. I
also
see no reason to keep the round-trip handshake.
The primary reason for the round-trip is because there is a non-zero
expense to have the client gather information about itself. The
set of
criteria today are fairly cheap for the client to gather, but this
set could
potentially grow to encompass other things that may not be so cheap.
The criteria that's needed depends on the actual criteria set up on
the
server, so it seems a waste for the client to spend time doing work to
gather some set of information that won't be used for the every-time
case.
Does the round-trip cost anyting wrt cgi-bin?
How expensive can this possibly be in comparison to the overall boot
and installation time?
Not very expensive compared to that. But I guess just in principle,
knowing we're executing code to produce something we don't need seems
unnecessary and also presents opportunity for additional failures.
With Derived Manifests, it seems unlikely we'd substantially expand
the criteria.
I agree with that. The round-trip doesn't seem all that complex however
(I could be wrong on that though) so I wanted to see if there was a
tradeoff we were making and if so, what it was. It sounds like the
motivation is that getting rid of that round trip would just make the
communication much more straight forward.
The one potential criteria addition I was thinking of was disk
information, which could be a non-trivial amount of time. But I have no
real data on that at this moment. Just knowing what libtd does, it's on
the order of seconds, but I would speculate it'd be much more
significant for systems with large amount of disks. Again, still no
comparison to the overall time, but potential for failure could be high.
Well, I could also envision modifying the protocol to be that the
client sends a trivial criteria set, and if there is more that is
needed, the server response could indicate as such and the client
could then go to an expanded criteria gathering. That would be an
improvement over the existing protocol, which guarantees 2 round trips.
Dave
-ethan
Dave
-ethan
The next rev should be out tomorrow sometime. It should include this
issue, Apache dependency, mention static content, reliability and
scalability.
Thanks,
John
On 05/10/10 01:51 PM, Dave Miner wrote:
On 05/ 4/10 12:26 PM, John Fischer wrote:
All,
After additional research I have redesigned the solution that I was
proposing. The original design had CherryPy as a back end to an
Apache webserver using mod_wsgi. This added to the architectural
complexity of the Automated Installation Webserver rather then
simplifying it.
The redesigned solution is to simply use Apache and cgi-bin scripts
to accomplish the same tasks. Further details can be found at:
http://hub.opensolaris.org/bin/download/Project+caiman/auto_install/AI-Webserver-Specification.odt
Or
http://hub.opensolaris.org/bin/download/Project+caiman/auto_install/AI-Webserver-Specification.pdf
One thing that wasn't quite explicit: you're not proposing to change
the client/server protocol to eliminate the two-phase criteria
handshake? It's noted in the background, but seems to be left alone
in the proposal. Is there a strong reason why we should retain it?
I realize eliminating it would leave a transition issue, but it's
not
clear that we're getting any value out of the extra round-trip.
Dave
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
