Issue 5968: The submission only gives one choice for managing node resources (deployment-ftf) Source: PrismTech (Mr. Gerald Lee Bickle, jerry.bickle@prismtechusa.com) Nature: Uncategorized Issue Severity: Summary: The submission only gives one choice for managing node resources, which is always done by the domain (target manager). There is no capability of allowing a node/device to manage its resources and its states, and to indicate which node resources can be managed at the domain and which ones at the node or device level. Recommendation is add the capability in the description elements to indicate if the resources are managed by the node/device or by the domain, and operations to the node/device to manage this capability Resolution: Revised Text: 1. In section 6.10.5.2 add a boolean attribute to the SatisfierProperty to indicate whether its value is dynamic: dynamic : Boolean Whether the value of this property can change during run-time. 2. In section 6.4.19.4 add an OCL constraint on the Capability class that the value of the dynamic attribute of all associated SatisfierProperty instances be false and dynamic <> false 3. In section 6.7.2.1, change "UpdateAvailable" to "UpdateDynamic". 4. In section 6.7.2.5, change "In case of UpdateAvailable, information about the available capacity of resources is updated." to "In case of UpdateDynamic, the update contains new dynamic values for SatisfierProperties that are dynamic". 5. In section 6.9.3.2, add an argument updateIntervalUsec : unsigned long to the joinDomain operation, with the description: "The updateIntervalUsec argument specifies the maximum time interval between updates of changing dynamic SatisfierProperty values by the NodeManager using updateDomain operations to the TargetManager. The NodeManager should make best effort to not exceed this time interval, while getting as close to it as possible. A value of zero indicates that no such updates are requested." 6. In section 6.9.3.2, add the getDynamicResources operation as follows: getDynamicResources() : Resources[] Retrieves the values of dynamic SatisfierProperties associated with the node. Actions taken: June 18, 2003: received issue May 9, 2005: closed issue Discussion: Resolution: Add the possibility to update properties of nodes dynamically. End of Annotations:===== Subject: Deployment Issues To: issues@omg.org Cc: deployment-ftf@omg.org, swradio@omg.org X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 From: Gerald_L_Bickle@raytheon.com Date: Wed, 18 Jun 2003 08:35:48 -0500 X-MIMETrack: Serialize by Router on NotesServer3/HDC(Release 5.0.12 |February 13, 2003) at 06/18/2003 08:38:39 AM X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id h5IDjfkM021179 Initial Deployment Issues: 4. The submission only gives one choice for managing node resources, which is always done by the domain (target manager). There is no capability of allowing a node/device to manage its resources and its states, and to indicate which node resources can be managed at the domain and which ones at the node or device level. Recommendation is add the capability in the description elements to indicate if the resources are managed by the node/device or by the domain, and operations to the node/device to manage this capability. X-Dreamscape-Track-Mars-A: dhcp64-134-229-180.cmad.atl.wayport.net [64.134.229.180] X-Dreamscape-Track-Mars-B: Mon, 24 May 2004 22:33:49 -0400 (EDT) Date: Mon, 24 May 2004 22:33:10 -0400 From: James Kulp Organization: Mercury Computer Systems, Inc. User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en,pdf To: Andreas Hoffmann CC: Deployment FTF Subject: As requested, solution to issue 5968 from St. Louis 1. In section 6.10.5.2 add a boolean attribute to the SatisfierProperty to indicate whether its value is dynamic: dynamic : Boolean Whether the value of this property can change during run-time. 2. In section 6.4.19.4 add an OCL constraint on the Capability class that the value of the dynamic attribute of all associated SatisfierProperty instances be false. and dynamic <> false 3. In section 6.7.2.1, change "UpdateAvailable" to "UpdateDynamic" 4. In section 6.7.2.5, change "In case of UpdateAvailable, information about the available capacity of resources is updated." to "In case of UpdateDynamic, the update contains new dynamic values for SatisfierProperties that are dynamic". 5. In section 6.9.3.2, add an argument updateIntervalUsec : unsigned long to the joinDomain operation, with the description: "The updateIntervalUsec argument specifies the maximum time interval between updates of changing dynamic SatisfierProperty values by the NodeManager using updateDomain operations to the TargetManager. The NodeManager should make best effort to not exceed this time interval, while getting as close to it as possible. A value of zero indicates that no such updates are requested." 6. In section 6.9.3.2, add the getDynamicResources operation as follows: getDynamicResources() : Resources[] Retrieves the values of dynamic SatisfierProperties associated with the node. Subject: Re: Reminder: Deployment RTF voting (1st poll), closing 23rd August 2004 20:00 GMT Date: Mon, 23 Aug 2004 11:01:27 -0400 Thread-Topic: Reminder: Deployment RTF voting (1st poll), closing 23rd August 2004 20:00 GMT Thread-Index: AcSGv66ieIUpiR43QnC532CV7JSuhQB8XsBgABsbzAA= From: "Pilhofer, Frank" To: "Deployment RTF" OMG Issue No: 5968: No. The resolution doesn't address the stated issue. A resolution which rejected the issue could be reasonable, but it should explicitly do so. The proposed resolution allows for both the domain to pull "dynamic" data from the nodes (if the updateInterval is zero), as well as for nodes to push dynamic data to the target manager (if the updateInterval is non-zero). In the first case, nodes are able to manage their own resources, because the Target Manager is able to request updates as necessary, instead of maintaining the data itself. I think Jim intended to tie in this resolution with a new (unposted) issue and resolution to associate committed resources with a kind of identifier, so that nodes can report committed but unused resources as available. OMG Issue No: 7163: No. An xor 0..1 composition of four other classes indicates that refactoring is needed. (And yes, if the resolution is defeated I will provide this.) If the resolution is accepted, feel free to post a new issue and resolution, if you have a good suggestion. Frank Subject: Re: Reminder: Deployment RTF voting (1st poll), closing 23rd August 2004 20:00 GMT To: "Pilhofer, Frank" Cc: "Deployment RTF" X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 From: Gerald_L_Bickle@raytheon.com Date: Mon, 23 Aug 2004 10:42:17 -0500 X-MIMETrack: Serialize by Router on NotesServer3/HDC(Release 5.0.13a |April 8, 2004) at 08/23/2004 10:42:22 AM X-SPAM: 0.00 The capability model is not managed by the node or device in this resolution. The domain is still interpretting the resource value against a capacity model instead of the node and device. Jerry Bickle Engineering Fellow Network Centric Systems 1010 Production Rd Fort Wayne, IN 46808-4711 260-429-6280 260-429-5060 Fax "Pilhofer, Frank" To: "Deployment RTF" cc: 08/23/2004 10:01 Subject: Re: Reminder: Deployment RTF voting (1st poll), closing 23rd August 2004 AM 20:00 GMT OMG Issue No: 5968: No. The resolution doesn't address the stated issue. A resolution which rejected the issue could be reasonable, but it should explicitly do so. The proposed resolution allows for both the domain to pull "dynamic" data from the nodes (if the updateInterval is zero), as well as for nodes to push dynamic data to the target manager (if the updateInterval is non-zero). In the first case, nodes are able to manage their own resources, because the Target Manager is able to request updates as necessary, instead of maintaining the data itself. I think Jim intended to tie in this resolution with a new (unposted) issue and resolution to associate committed resources with a kind of identifier, so that nodes can report committed but unused resources as available. OMG Issue No: 7163: No. An xor 0..1 composition of four other classes indicates that refactoring is needed. (And yes, if the resolution is defeated I will provide this.) If the resolution is accepted, feel free to post a new issue and resolution, if you have a good suggestion. Frank Date: Mon, 23 Aug 2004 12:16:45 -0400 From: James Kulp Organization: Mercury Computer Systems, Inc. User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en,pdf To: Gerald_L_Bickle@raytheon.com Cc: "Pilhofer, Frank" , Deployment RTF Subject: Re: Reminder: Deployment RTF voting (1st poll), closing 23rd August 2004 20:00 GMT X-Virus-Scanned: by Clam AntiVirus When we discussed this in our previous meetings, the issue (node-managed-resources) was described as a dynamic resource issue, which is solved in this resolution. I think you are now raising a new issue (which may indeed be connected for you), which is to not only have dynamic resources, but also have resource vs. requirement matching ALSO delegated to nodes. If this is for static as well as dynamic resources it would be very slow, communication-intensive, and not scalable. Buy supporting "push updates" of dynamic resources, as defined in the resolution, you get the performance of centralized resources, with the dynamism of node-managed resources. So, I would propose you raise a new issue if you want this, and include a use case that shows an improved behavior over using the facilities in the existing model. We really need to be focused mostly on stuff that is shown to be broken, as opposed to adding new modes and features (although we are all guilty of this at one time or another). Jim Gerald_L_Bickle@raytheon.com wrote: The capability model is not managed by the node or device in this resolution. The domain is still interpretting the resource value against a capacity model instead of the node and device. Jerry Bickle Engineering Fellow Network Centric Systems 1010 Production Rd Fort Wayne, IN 46808-4711 260-429-6280 260-429-5060 Fax "Pilhofer, Frank" To: "Deployment RTF" cc: 08/23/2004 10:01 Subject: Re: Reminder: Deployment RTF voting (1st poll), closing 23rd August 2004 AM 20:00 GMT OMG Issue No: 5968: No. The resolution doesn't address the stated issue. A resolution which rejected the issue could be reasonable, but it should explicitly do so. The proposed resolution allows for both the domain to pull "dynamic" data from the nodes (if the updateInterval is zero), as well as for nodes to push dynamic data to the target manager (if the updateInterval is non-zero). In the first case, nodes are able to manage their own resources, because the Target Manager is able to request updates as necessary, instead of maintaining the data itself. I think Jim intended to tie in this resolution with a new (unposted) issue and resolution to associate committed resources with a kind of identifier, so that nodes can report committed but unused resources as available. OMG Issue No: 7163: No. An xor 0..1 composition of four other classes indicates that refactoring is needed. (And yes, if the resolution is defeated I will provide this.) If the resolution is accepted, feel free to post a new issue and resolution, if you have a good suggestion. Frank Subject: Re: Reminder: Deployment RTF voting (1st poll), closing 23rd August 2004 20:00 GMT To: James Kulp Cc: Deployment RTF , "Pilhofer, Frank" X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 From: Gerald_L_Bickle@raytheon.com Date: Tue, 24 Aug 2004 05:48:44 -0500 X-MIMETrack: Serialize by Router on NotesServer3/HDC(Release 5.0.13a |April 8, 2004) at 08/24/2004 05:48:51 AM X-SPAM: 0.00 I will repost the issue of being more specific so misunderstanding of the intent of initial issue posted. Not all systems fit the central controller design pattern, there should be flexibility for a decentralized approach. Let System Architectures determine which approach is the best also it may be a mixture approach. One shoe does not fit all. Jerry Bickle Engineering Fellow Network Centric Systems 1010 Production Rd Fort Wayne, IN 46808-4711 260-429-6280 260-429-5060 Fax James Kulp To: Gerald_L_Bickle@raytheon.com cc: "Pilhofer, Frank" , Deployment RTF 08/23/2004 11:16 AM Subject: Re: Reminder: Deployment RTF voting (1st poll), closing 23rd August 2004 20:00 GMT When we discussed this in our previous meetings, the issue (node-managed-resources) was described as a dynamic resource issue, which is solved in this resolution. I think you are now raising a new issue (which may indeed be connected for you), which is to not only have dynamic resources, but also have resource vs. requirement matching ALSO delegated to nodes. If this is for static as well as dynamic resources it would be very slow, communication-intensive, and not scalable. Buy supporting "push updates" of dynamic resources, as defined in the resolution, you get the performance of centralized resources, with the dynamism of node-managed resources. So, I would propose you raise a new issue if you want this, and include a use case that shows an improved behavior over using the facilities in the existing model. We really need to be focused mostly on stuff that is shown to be broken, as opposed to adding new modes and features (although we are all guilty of this at one time or another). Jim Gerald_L_Bickle@raytheon.com wrote: >The capability model is not managed by the node or device in this >resolution. The domain is still interpretting the resource value against a >capacity model instead of the node and device. > > >Jerry Bickle >Engineering Fellow >Network Centric Systems >1010 Production Rd >Fort Wayne, IN 46808-4711 >260-429-6280 >260-429-5060 Fax > > > > > "Pilhofer, Frank" > To: "Deployment RTF" > cc: > 08/23/2004 10:01 Subject: Re: Reminder: Deployment RTF voting (1st poll), closing 23rd August 2004 > AM 20:00 GMT > > > > > > > > > > OMG Issue No: 5968: No. The resolution doesn't address the stated issue. > A resolution which rejected the issue could be reasonable, but it should > explicitly do so. > >The proposed resolution allows for both the domain to pull "dynamic" data >from the nodes (if the updateInterval is zero), as well as for nodes to >push dynamic data to the target manager (if the updateInterval is >non-zero). > >In the first case, nodes are able to manage their own resources, because >the Target Manager is able to request updates as necessary, instead of >maintaining the data itself. > >I think Jim intended to tie in this resolution with a new (unposted) issue >and resolution to associate committed resources with a kind of identifier, >so that nodes can report committed but unused resources as available. > > OMG Issue No: 7163: No. An xor 0..1 composition of four other classes > indicates that refactoring is needed. (And yes, if the resolution is > defeated I will provide this.) > > If the resolution is accepted, feel free to post a new issue and >resolution, if you have a good suggestion. > >Frank > > > > > > > >