Dave,
Thanks for the review.
Dave Miner wrote:
> Sundar Yamunachari wrote:
>> Hi,
>>
>> The functional specifications for AI transport (Web Server
>> redesign) is available at
>> http://wikis.sun.com/display/OSOLInstall/Web+Server+Redesign+Functional+Specification.
>>
>> Please review the specs and provide your feedback by 06/15/09
>>
>
> Most of this looks pretty good. Some things to consider:
>
> General: Please retitle this from redesign to version 2, or similar.
okay
>
> 1.b: I've never encountered use of the security attributes noted here
> for torrents; is there a reference you can point to on cases where
> this has been done?
That may be a typo. Keith looked at the bittorrant and I will check with
him.
>
> 2.f.: Could use discussion of goals for multiple servers might
> interact, and how to scale the server infrastructure. Will a
> transport be expected to work correctly with content caching
> infrastructures such as squid? What would a high-availability server
> environment look like? Are we relying merely on clustering for HA?
We discussed caching proxies like squid. The discussion is documented at
http://www.opensolaris.org/os/project/caiman/auto_install/ai_design/transport_options.pdf.
We haven't discussed about high-availability environments. We will have
a discussion and update the spec.
>
> 5.c: Are all transports required to provide secure options?
We looked at the security options that can be supported in the
transport. It should be noted that it is optional. If the transport
support security, we will provide means to enable the security. I will
update the spec to indicate that it is optional and depends on the
transport.
>
> 5.f: There seem to be requirements here to enhance the TFTP service.
> Should discuss with networking team.
That is a good idea. Who is the contact in the networking team?
>
> 6.b: This is identical, or nearly so, to 6.a, which isn't surprising
> since they are really just two pieces of the same puzzle. Recommend
> consolidating and up-leveling: rather than specific reference to
> solaris.zlib or solarismisc.zlib (both are undefined terms in this
> document), I would suggest referring generally to "archives required
> to assemble the complete installation environment" or something of
> that ilk.
We will fix the use case. We started with the transport diagram
(http://www.opensolaris.org/os/project/caiman/auto_install/ai_design/transport_data_diagram.pdf)
with a single step for getting all the stuff other than the
boot_archive. To understand the current use case, it is split in to two.
>
> 6.d: I'm not sure how well this use case maps to a P2P transport; they
> typically operate on a pull model, yet this appears to be a push model.
We are learning about the P2P model. So this needs work.
>
> 6.e: Standard term is derived manifests.
Okay
>
> 6.f: Is P2P really a use case? It seems like a solution to (at least
> some of) the other use cases, rather than a use case in its own right.
We try to fit our current transport requirements to P2P. We will work on
it to make it better.
>
> A use case for archive-based installation seems worth adding.
You mean replication? I can have a use case bases on existing flash
technology with out any of the implementation details of flash.
>
> Finally, I'm wondering how this relates to a "serverless" automated
> installation, which is what the Virtual Machine Constructor seems to
> be requiring. Is there a sort of "null" transport that would be used
> there? Just trying to sort out how the architecture is anticipated to
> adapt to that case.
In our use cases, the client ask for the specific data and server
provides the data. In the case self-contained AI, the client will not
use any transport. So I think it should work. Still have to think about
how the client gets the AI manifest.
Thanks,
Sundar
>
> Dave
