Jean McCormack wrote: > 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 >> >
Thanks for the reply. I think CIM and SNMP would both be heavy weight. Joe
