Architecture Team Telecon
17 December 2009

Author: Karl Schopmeyer
Modification Date: 17 Dec 2009

Attendees

Marek

Robert

Thilo

Greg

Sahana

Venkat

Karl

Notes

          0. Agenda

            See the web page

1. Minutes

2. Actions

3. Build Status

Nightly Build Status

Nothing new this week

4. Bugs

8623 - No conclusion

8659 - Mike Brasher needs to respond to this one.

6. PEPs

None

7. Any Other Business

1. Cancel telecon next week due to holidays.  Next telecon abut 6 Jan 2010.

2. Are we ready for the Function Complete tag? Conclusion yes. 2.10 Function Complete tag goes on tonight. Karl noted that he was late with the Pull code and will submit the bug for that before the next telecon. Then we can decide what to do with that code.

3. Discussion of the error trailer we add for enumerates.  This subject was on the agenda for today as follows:

[ (k_schopmeyer) Problem with current operations. Note that we will NOT use the chunking for now in the pull operations but still have the problem with the current multiobject operations. In brief, we used a trailer defined in a preliminary version of DMTF cimxml spec as means of announcing errors for these operations because there is no other way to announce an a error once output has started per our specifications. However, since this trailer never made final, the client may never see an error we generate. Note that getting around this issue was much of the reason for pull.
Hosever, the problem still exists even after we install pull. The question is 'what do w do about this issue? 1) Is there any other way we could announce an error and so continue to use the chunked output (ex. terminate the connection)? 2) Should we make a more public way to enable/disable this trailer since may users may still want it if they control their clients (i.e. use a client that they know accepts the trailer? 3 Should we make the issue more public? or 4) Just leave it assuming that the whole issue will eventually go away when these operations are finally deprecated (whoops remember that we will only pull instances, not classes)?.
Remember that disabling chunking could be really horrible for memory usage on enumerate operations (we were seeing spikes of 100 MB) just for class enumerates in the past.

We agreed that there is an issue in that Pegasus is using a trailer that is NOT in the cimxml specifications any more.  Note that this occurred because we built Pegasus off of a preliminary verson of the cim/xml specification (1.2 preliminary) that had been the latest version version for some time but that in a very short period was modified to remove this trailer and passed to final.  The Pegasus group did not catch this until after the 1.2 final was approved by DMTF and released.

We discussed a number of possible alternatives to the trailer including:

  1. Drop the trailer completely - Everybody agreed that this is not possible.

  2. Leave everything as it is. - We concluded that this could cause real issues in the future.

  3. Find some other way to indicate errors.  Nobody has a solution for this today.

  4. Whether chunking is really required for network performance if the whole response is prepared before transmitting.  We noted that some systems chunk by simply taking the response and breaking it up into fixed size chunks based on the perception that this helps the network.

We concluded that we would propose a number of actions including the following:

  1. Really document the issue so that a client can work with it including the format of the trailer, etc. so that clients who work with Pegasus can design to utilize pegasus

  2. Push for that trailer back in the cim/xml spec. There is not other solution to the problem of terminating multiobject responses in error that we know and there is always the possibility of error if multiple objects are being delivered, even class responses.

  3. Add Pegasus special field that tells server to use the trailer.  This special field in the request would determine if we could use the trailer rather than simply the chunking flags.

  4. Make sure we are only using when we have to.  This is just a coding issue but Karl noted that he thinks we are actually using the trailer when we do not need to.

ACTION: Update the discussion into a working document. Karl

4. Agenda for next 3 months.  Keep the accident of two points for every category. ACTION: Karl make new agenda. Marek document source for our general train schedules.

5. Schedules for 2.10.1 and 2.11.   We discussed the next schedules and noted that our general trend is a) major release each 9 - 11 months, b) revison to that release about 6 months after the release, c) revisions to the previous releases staged after i) the release, ii) the revision to the current version of the platform (This allows bug fixes to flow back from the current release to each earlier release easily).  Actions: Prepare the pages for 2.11, 2.10.1 based on this and also a table with all major dates in it for the WIKI (Karl) for the next telecon.

We discussed the possibilities for setting schedules for the future.  Generally we agreed that the major train schedule is important to keep.  It sets expectations for the future.  However, We also feel that there may be specific cases where we want to introduce new functionality on a more immediate schedule and that we could as a group set up intermediate releases.  The specific example was that we will propose 2.11 per our 9 - 11 month schedule.

However, if there was a reason, we could consider making an interim release of 2.11 and redefine 2.11 release schedule as 2.12.

 

  

 

.