Sarah,
Thanks for the review. My comments are in-line.
Sarah Jelinek wrote:
> Hi Sundar,
>
> My comments/questions...
>
> General question:
>
> Why is the primary objective of this project include design and
> implement two example mechanisms? Is this for design research?
The objective is to provide modular mechanism in which user can swap the
transport. To make sure that we meet the objective we would like to
design one server-client transport and another peer-peer transport.
>
> Section 2e:
>
> I would think we would want to have some performance requirements to
> ensure our choices with regard to design are the right ones.
>
> I think part of what you outlined in 2f are performance requirements.
Performance and scalability are related. We can change 2f to
performance and scalability. We can put boundaries for performance. I
think scalability is more important when it comes to transport.
>
> Section 2c:
> I would like to see a list of the functionality that you plan to
> provide with regard to observability. Even if these functional pieces
> are phased in, I would like to have a list to know what we are going
> to provide. The statements in this section say 'may be provided'.
That is fair. We will change it to "will be provided" and we will try to
enumerate the complete list.
>
>
> Also, what does this mean:
>> Explicitly, we will not be transporting observability data as that
>> task will belong to future observability work.
The transport redesign looks at the data that is required for
installation. If we decide that we will upload the observability data
using the same transport, it can be done.
>
> Section 3:
>
>>
>> User interface interaction with the transport mechanism are minimal.
>> Server user interface is limited to starting and stopping the
>> service. Observability data will be provided to the user through
>> observability tools provided by later external work. Client user
>> interface is limited to the SMF service which controls the start and
>> stop of auto-install.
>
> Is there any user interaction or user interface that allows the users
> to configure their server to support their environment needs?
The transport could be configured depending on the environment. For
example the configuration parameters of the transport (web server or
bittorrant) could be tuned and it depends on the chosen transport.
>
>
> In section 4: Deliverables:
>
> I am a little confused by the use of the word 'should' when describing
> the functionality provided for the major components of the AI
> transport. Is there decision on what will be provided that we can
> clearly identify?
Are you talking about section 5b? There are requirements for choosing
the server side transport (in the case of HTTP, apache, cherrypy etc.)
and client side program (wget, curl etc.) We want to choose the option
that satisfies most of our requirements.
>
> Also, do we need to include on the server the ability to provide
> dynamic content to clients? Not required now for any known Caiman
> project, but maybe for the future?
We need to come up with use cases, the amount of data and frequency of
the data request to select a transport that provide dynamic content. By
choosing a transport that doesn't prevent adding dynamic content in the
future is the right choice. We will add this information to the
functional specification. We looked at several options and the
information is there at
http://www.opensolaris.org/os/project/caiman/auto_install/ai_design/transport_options.pdf.
>
> 6. Use cases:
>
>> Server Goals -
>>
>> 1. Receives requests for data files
>> 2. Sends requested data files
>> 3. Determines the AI manifest for each specific client
> Is it really a server goal for the transport mechanism to determine
> the AI manifest for the clients? It is part of the AI processing, but
> not a part of this project, is it?
The transport we choose should allow the processing on the server to
choose the AI manifest.
>
> General note:
> I don't think we should mention specifically that the client requests
> the solaris.zlib file. Perhaps we say something like client requests
> image file. Because we may not have a solaris.zlib specifically for
> the client to request if we change the layout of the images.
We started with the diagram at
http://www.opensolaris.org/os/project/caiman/auto_install/ai_design/transport_data_diagram.pdf.
We wanted to be specific with the use case. I agree that it should be
changed to something generic terms.
>
> So, why are we including under Use Cases, the transport of the NBP,
> when we don't have control of this at this point in time? Does the
> transport mechanism redesign include this? Are there things we plan to
> do with regard to re-design or new features in this area?
That information is there for completeness. We started looking at all
the transport requirements between the client and the server.
>
> How is use case #2 different from use case #1?
It is different only in the case of observability. We have part of the
AI image and failed to complete the transfer of rest of the image. We
may provide different message to the user.
>
> So, a few general questions:
> 1. The outcome of the redesign work, past the functional spec, is to
> provide a set of modules and interfaces that abstract the data
> transport mechanism from client to server, right?
Yes.
>
> 2. The choice of transport mechanism and application that does the
> transporting, e.g. webserver/http, is part of this project as well?
I think the choice is part of the functional specification.
Thanks,
Sundar
>
> thanks,
> sarah
> *****
>
>> 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
>>
>> Thanks,
>> Sundar
>> _______________________________________________
>> caiman-discuss mailing list
>> caiman-discuss at opensolaris.org
>> http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
>
