Sarah,
Thanks again for the comments. My responses are inline.
Sarah Jelinek wrote:
> Hi Sundar and Keith,
>
> I am going to answer only to Sundar's email and include any answers
> from Keith that are different, with my responses to both inline...
>
>> 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.
>
> Ok, fair enough.
>>>
>>> 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.
>
> I think in the case of this project, scalability and performance are
> tightly coupled. Perhaps we should have one section that discusses
> performance and scalability for this project. Rather than separating
> these out.
Okay. We will combine the two.
>
>
>>>
>>> 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.
>
> Ok, thanks.
>>>
>>>
>>> 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.
>
> Ok.
>>>
>>> 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.
>
> Ok, so we are not providing a mechanism by which the users could tune
> the transport? It is specific to the transport chosen and must be done
> via the transport mechanisms?
Yes.
>
>>>
>>>
>>> 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.
>
> Yes, I am talking about section 5, sorry. I am confused by the use of
> the word 'should'. I guess what I am trying to get at is that if what
> is required is listed in Section 5, then we should say, for example,
> "The client program we should will provide that data can be
> transferred securely", or something like that. So, when a decision is
> made about, in this case, the client program, we can clearly
> articulate we have met the requirements.
The work ' should' is not appropriate since some we are not requiring
all the features to be available in all transports. If the transport
supports the feature, we will enable it.We will update the specs.
>
>>>
>>> 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.
>>
>>
>>>
> Ok, thanks for adding this.
>
>>> 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.
> We could probably reword this as Keith suggests to be a bit clearer
> about the server goal for this.
okay.
>
>>>
>>> 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.
>
> Ok, fair enough. To answer Keith, I don't think you should limit the
> scope of the use cases necessarily for this project, It might be good
> to say however, that this project will not be addressing any redesign
> for this use case.
>
>
>
>>>
>>> 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.
> Ok.. however, if we change the use of solarismisc.zlib to be say
> 'image file' or something like that, then these two could be combined.
> The failure described here is the inability to successfully transmit
> the full image.
Agreed. We will change it.
>
>
>>>
>>> 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.
>
> So you expect to make the choice of transport mechanism as ongoing
> work with the functional spec, or do you feel that you have made the
> choice in the current functional spec? I am not seeing a choice
> specified. The reason I am asking this is that this project appears to
> have two major goals:
>
> 1. Provide a modular interface for consumers of the AI transport
> mechanism.
> 2. Choose a transport that serves the needs of the consumers for the
> initial release. However, this transport could be changed and added
> under the modular interface provided.
Right.
>
> The other goal which I am not seeing and want to check to see if it is
> part of this redesign effort is what we originally started with:
>
> -Remove the multiple web servers running on an AI server.
>
> Is this still a goal of this project?
The implementation was a bug. We started looking at the problem by
looking at the transport requirements of installation. Multiple web
servers is a symptom of the problem and I don't consider it as a goal.
But we will make sure that we don't end up with similar situation (two
web servers) with the new design.
Thanks,
Sundar
>
> thanks,
> sarah
> ****
>
>
>
> thanks,
> sarah
> ****
>>
>> 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
>>>
>>
>
