Joseph J. VLcek wrote: > Jean McCormack wrote: >> I'll post these to opensolaris when I'm able to sign in, hopefully >> sometime today. >> >> >> Attendees: Sue, Jean, Sarah, Glenn, Jan, Alok, William >> >> Open Items to do to get ready for review. >> >> Clarification on Dry run requirements from Andre deferred until he >> gets back on >> the 9th. >> >> Configuration and manifest validation: Jumpstart provides this with dry >> run. We need to >> answer what dry run really means in the context of AI. What are the >> requirements? What value do we add? >> Alok: Test wanted a sanity test. Making sure the manifest was >> semantically and syntactically correct. Also, the IPS repo was actually >> acceptable. >> Sue: Also what service is going to be run. >> Sarah: So we would show them the configuration, service, repo, manifest >> validation >> Alok: disk target, packages valid. >> Jean: user account, timezone. >> Sarah: We need to figure out what we want to validate and list those to >> drive the dry run. >> >> Todo: Clarification in spec of what we think we're providing with dry >> run. >> >> Jan: We might have dependency on IPS for this. He thinks that IPS has a >> dependency on an image-create having been run. >> >> If the pkg dry run takes a long time we might need a way to override >> this for Andre. But others may want this. Possible >> dependency in functional spec about IPS dry run. >> >> VMC: >> Talk about using http to publish the logfile. Glenn not sure if this is >> the right thing. Sarah, it's up to the server/ whomever to do what they >> want with the data. In the case of Glenn's project, it's up to them to >> do what they want with it. >> >> It's only pertinent while the install is going on. After that they can >> log in and see it. >> >> If we have a minimal webserver running on the client, we don't want it >> hanging around after the reboot. >> >> No input as to which light weight webserver. >> >> The current research for the webserver project seems like it's probably >> heavy weight. It's probably too big for us. >> We need to do a little research on this. >> >> If we use a webserver to publish then what does the use case look like? >> It doesn't stream data. Which is what we really want. >> But the consumer could determine the pull interval. Unless we have a >> callback mechanism, the data will have somewhat of a lag. >> Currently the clients provide callbacks that provide status update. We >> try to be as accurate as possible but it's really a rough idea. >> >> Requirement is for remote observability which includes the log and the >> progress info. The idea is that progress would be in the log. >> Would http access with parsing work for now with more research as to how >> Amber Road does this. >> >> This is ugly. We need more research as to what else we could use. >> >> How would the server know it should be polling? Are we going to use this >> for the install server also? Or something else? >> Is there any way of using the "old" way of updating the install server >> to work for all cases. i.e. Glenn too. >> >> Who else is a consumer we know of? The install server. >> >> VMC requirements: Wants real time which means he wants to provide >> progress reporting and ability to detect error conditions. >> This is similar to what liborchestrator does for the GUI. >> >> How do we provide this? Probably just exporting via http doesn't quite >> do this. >> >> Jan, suggested SNMP. This is still a pull mechanism. > > SNMP management agent can retrieve (get) or alter (set) variables on Yeah. I thought he had said it was a pull mechanism but after looking into snmp more I discovered you could push. > > So I think this may mean we could set it up so the agent is the VM or > the agent is the host. Either way we still need a mechanism to > communicate network info between the two. > > And if the networking info can be available then why not simply > provide access to the log file(s) on the VM running the install client? We're actually looking at something using Ajax to provide a nice consistent user interface to progress and log. More when we get the details. > > Also > > CIM - Common Interface Model could also be investigated. Yes. But it's fairly heavy weight. Not sure we need that.
Jean > > From my understanding the difficulty is in communicating the hosts > network address to the client. If SNMP or CIM were used network info > would also be needed. > > > // > > >> >> Glenn: AI client boots and starts a process which can take connection >> requests from a remote observer. Once connected the AI client starts >> sending data to the remote consumer who can do what they want with it. >> >> What if the AI server was the remote consumer? Do we have the push of >> the log automatically happen? Or do we connect? >> >> Alok: likes Jan's suggestion of SNMP. We can have a variety of snmp >> traps and the consumer can pick which ones to detect. >> >> William: propose something something similar to SNMP traps. The AI >> client starts up receiving the remote consumer IP >> address via boot params. Same problem as we need to have the AI server >> know to listen. >> >> Jan: Would like to be able to connect at any time to observe the AI >> client. i.e. go home and from there connect and observe. >> >> Sarah: Thinks the consumer should be initiating the connection. >> The requirement is that we provide remote observability into the client. >> >> Sue: How would the AI server know when to connect? >> >> Alok & Sarah: The AI webserver has a connection because the client has >> asked for the manifest. >> >> William: tcp/ip connection suggestion. >> >> Summary: >> Requirement is to provide remote observability. We will provide log >> files and/or progress information. >> Research will be done to come with a proposal as to whether this will be >> a push or pull operation. >> >> Alok and Jean will look into tcp/ip, snmp, webserver plus others. >> >> Multiple disk: >> >> William: He has put out some email on corrections and extensions but >> needs to get out a proposal. (will be out by 6:00 am Pacific >> June 4) >> Needs to talk with Ethan yet about his issues. >> >> Changes not expected to be extensive. >> >> Proposing 9:00 P/10:00M/6:00 Prague on Monday June 8 for review of >> functional spec. >> >> Jan: Doesn't think it changes the design, but wanted to mention that he >> thinks AI will need to support extended partitions. This could go >> into the spec under enhancements. >> >> >> >> _______________________________________________ >> caiman-discuss mailing list >> caiman-discuss at opensolaris.org >> http://mail.opensolaris.org/mailman/listinfo/caiman-discuss >
