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 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? Also CIM - Common Interface Model could also be investigated. 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
