Jean McCormack wrote: > Dave Miner wrote: >> Ethan Quach wrote: >>> >>> Jean McCormack wrote: >>>> Dave Miner wrote: >>>>> Jean McCormack wrote: >>>>>> Jens Deppe wrote: >>>>>>> Hi Jean, >>>>>>> >>>>>>> One comment inline... >>>>>>> >>>>>>> On 05/21/09 14:19, Jean McCormack wrote: >>>>>>>> Progress Reporting: >>>>>>>> >>>>>>>> The output to the console to reflect the progress of the >>>>>>>> auto-install should be of the format: >>>>>>>> >>>>>>>> (pseudo progress bar) High level description of current >>>>>>>> functionality >>>>>>>> >>>>>>>> Example (general idea, wording is not exact) : >>>>>>>> >>>>>>>> (.....................) Discovering available services >>>>>>>> (..... ) Choosing service >>>>>>>> >>>>>>>> The .'s indicate percentage completion. This means we have a >>>>>>>> dependency upon IPS to supply size information for the packages. >>>>>>>> A return is only implemented when the install moves from one >>>>>>>> major block of functionality to the next. Otherwise, the text is >>>>>>>> overwritten with updates to the dots to indicate progress. >>>>>>>> >>>>>>>> The use of virtual console was considered as a possibility if a >>>>>>>> more detailed progress >>>>>>>> is required. Preliminary investigation indicates that this >>>>>>>> currently is not in our microroot and would >>>>>>>> be too large to include there. >>>>>>> Please consider enabling the log file to be retrieved/accessed >>>>>>> remotely. Simply exposing it via an http service would be a *big* >>>>>>> help. Especially when installing systems remotely. >>>>>> Does this meet your needs? >>>>>> >>>>>> The log file will also be written to the AI server at >>>>>> /var/ai/client_logs/ip_address/install_log. >>>>>> >>>>> I'd be thinking about this being configurable, and putting it >>>>> outside of a BE-enclosed path so as not to exacerbate our existing >>>>> space-management issues in /var. >>>>> >>>>> Dave >>>>> >>>> We did discuss making this configurable. The issue with that was >>>> related to the fact that we have to do the service discovery and >>>> service choosing before we get the manifest with configuration >>>> information in it. If the user would like to see the log before that >>>> time, they wouldn't find it in their configurable path. Any >>>> suggestions? >>> >>> Making it configurable per client seems like overkill --would that >>> add any value? Why not just make it configurable as a server-side >>> configuration, if configurable at all. >>> >> >> The client shouldn't need to know it, at all. I suspect there's a >> hidden assumption here that you're going to use NFS? That wouldn't >> work with the WAN environments AI means to support... >> >> Dave > > > My assumption was that we would use the webserver (or whatever they > define that to be) to push the log file. >
OK, but I thought previously you said that the data would be streamed back to the server, which isn't quite the same implication as pushing a log file at the end. > Here's some ideas: > > The default server side location is : /rpool/ai/logs/<client_unique_name> > I think you're meaning to say in a dataset rpool/ai/logs which would be mounted at /ai/logs. However, on further consideration that isn't going to be a good answer for porting the server side onto non-OpenSolaris servers. There'll be resistance to putting it outside the "standard" top-level paths. I think this is where we need to dust off Ethan's work around a /var/shared that's a BE-invariant dataset. > To customize.... > > The user can create a server side log area via : installadm log_path > <path> and all client log files would be placed in path/unique_name > The user could specify the actual file name with : installadm > create-client -log <file_name> > I'm not sure the per-client customization is all that useful, though we need some discussion around the proposal for generating unique names. Dave
