* Alok Aggarwal (Alok.Aggarwal at Sun.COM) wrote: > Glenn Lagasse wrote: >> * Jean McCormack (Jean.McCormack at Sun.COM) wrote: >>> Glenn and I talked today about this requirement. >>> >>> The basics are in this case the VM is the AI client and there is no AI >>> server. The DC is running the VM but the VM knowns nothing about DC. >>> However, he would like the DC to be able to monitor what is going on. >>> The more generic case of this was brought up by Jens Deppe on the >>> caiman-discuss alias last week. (Subject: AI client redesign for >>> progress reporting and error reporting/logging) >>> >>> We talked about some general ideas: >>> >>> 1) ssh - no due to security issues >>> 2) Have the DC start up a webserver - no, too complicated and might >>> not work for the generic case which doesn't have DC running >>> 3) Glenn's idea to have a deamon running on the client which could be >>> connected to from the outside to receive data. >>> >>> Glenn will send a more detailed write up on #3. >> >> For #3, I don't have a lot of details. It was merely something that >> came to mind when I started thinking about the problem. If an AI client >> could expose an interface such that remote 'clients' could connect to >> the AI client being installed and receive telemetry, that might be very >> useful. In the VM Constructor project it would be very useful. >> >> For simplicity sake I'm just going to talk about the AI client in a >> general context and not in any specific context to VM Construction. >> What I imagined was that the AI client would start up and start some >> process/daemon which listens for incoming connections from the network. > > One could also concieve that exposing the log simply via http would > suffice here.
I don't think it does. Parsing the install log in an automated process and trying to report overall progress and capture error conditions and status doesn't lend itself to parsing a log file imho. More so if we'd make all consumers have to write their own log parsers. >> Clients (ie parties interested in what the AI install is doing) would >> connect to this 'service' (process/daemon). Once connected, the >> 'client' (not the AI client) would start receiving telemetry from the AI >> client such as progress reporting (so that a progress bar could be >> constructed) as well as error conditions and information messages. The >> 'client' could then act upon that telemetry (though not through >> interfacing with the AI client) in whatever way it needs. >> >> In the instance of the VM constructor project, we would display a >> progress bar to the DC user much like what is displayed in the GUI >> installer. We also could act upon error conditions (stopping the >> construction process and providing user feedback) as well as knowing >> when the installation of the AI client is complete so we can shut down >> the VM and move on to post-processing. >> >> Anyway, that was my thought. The telemetry would need to be sorted out. >> I don't think we want to make remote 'clients' (those which would >> connect to the AI client to gather the telemetry) to write their own >> 'parsing' mechanism. >> >> Thoughts? > > Since we're talking about the AI client in the general WAN context, it > would be important to not expose any security sensitive data as part of > the telemetry data (username/encrypted passwords being the obvious ones > there). I agree with this. I am not convinced however that just exposing the install log is a great interface for remote clients who want to observe an AI client install. For interactive observation, perhaps. But for automated observation (as the VM Construction project will need) not so much. -- Glenn
