Dave Miner wrote: > 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. Wording mistake. What I meant is that we would be incrementally updating the log file on the server. It would not be a single copy at the end of the install. > >> 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 From reading the caiman-discuss logs on this topic, it does appear that this could be what we want. We would then put the logs in a path like /var/shared/ai_logs . The user would also have the option of customizing this path. > >> 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.
I had a brief discussion with Sue, William and Jan about this. Here are some options that came out of these discussions: - dns name (if present) - mac address - ip address (but the concern here is that when this changes it becomes useless) We talked about making the dns name the preference followed by the mac address if there wasn't a dns name. The thought being that the admin might have set up his network such that each system has a dns name. If so, we would use that. Do we know what people with large installations do in order to track systems? i.e. do they give dns names or do they actually track them via mac addresses? My thought around client customization was that a unique name might not be very friendly and it would be nice to give the user an opportunity to provide a name that will mean something to them. Depending on the resolution for the unique name topic, this might easily get ditched. Jean
