1 / 29

Discussion on Lifecycle Management and Its Impact to CDL

Discussion on Lifecycle Management and Its Impact to CDL. Jun Tatemura NEC Laboratories America Feb 5, 2004. Motivation. CDDLM should cover (from Kojo’s slides) : Simple Job Submission (deploy and run) Provisioning Configuration change based on new resource assignment/reservation

kevina
Download Presentation

Discussion on Lifecycle Management and Its Impact to CDL

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Discussion on Lifecycle Management and Its Impact to CDL Jun Tatemura NEC Laboratories America Feb 5, 2004

  2. Motivation • CDDLM should cover (from Kojo’s slides): • Simple Job Submission (deploy and run) • Provisioning • Configuration change based on new resource assignment/reservation • Some components should be restarted or re-deployed • Failure Recovery • Investigation of lifecycle status of components • Resource reallocation if needed • Reconfiguration if needed • Restart some of components • How do they impact to LM and CD?

  3. Overview • Lifecycle management of individual components • issues: reconfiguration, failure handling • impact to CDL: “attribute value lifetime” • Lifecycle management of multiple, interrelated components • issues: lifecycle dependency graph, value propagation • impact to CDL

  4. Lifecycle Management of Individual Components • Lifecycle state chart is more complicated • Issues • reconfiguration issues (provisioning, failure recovery) • failure issues (failure recovery) reconfigure reconfigure[?] deploy start (resource reserved) deployed running stop remove (failure) recover[?] failed (failure) remove

  5. reconfigure deployed Is this alternative good enough? reconfigure [2] reconfigure [1] stop running deployed running [3] start Reconfiguration Issues • Do we need reconfiguration of deployed component? [Yes] • changing configuration parameters • changing content (update of software) • Do we need reconfiguration of running component? [maybe] • changing configuration values without stopping the component

  6. Job Manager CDDLM Job Manager CDDLM deploy Component deploy Component start start failure failure reconfigure destroy start deploy Component start Failure Handling Issues • Who should know failures? • CDDLM knows the result of LM operations (e.g., start operation failed) and returns failure to Job Manager • What about failure while component is running? • Who should be notified? (Job Manager? CDDLM?) • Decision making on “recover or not” should be done by Job Manager (not CDDLM) • recovery may require resource reallocation

  7. Impact to CDL • Some configuration values can be modified when running, some require restart, others require re-deployment • To manage the total system consistency, CDDLM should manage “attribute value lifetime” • deployment-time constant: the value must be constant during deployment (i.e., need re-deployment to modify) • run-time constant: the value must be constant during run-time (i.e., need restart to modify) • dynamic: the value can be modified without restarting • Any modification attempt that brakes the above rule should be rejected • Specifying “LAZY” would not be enough

  8. Lifecycle Management of Interrelated Components CDDLM lifecycle dependency graph start B A start A B C D E A A must be running when B starts E C ordering of LM operations B D ok

  9. Lifecycle Management of Interrelated Components (cont’d) • Lifecycle dependency should also be managed in provisioning, failure recovery cases restart stop E stop C stop A start A start C start B A stop A start A E C B D

  10. Issues • How CDDLM should handle configuration data dependency between multiple components? • Does CDDLM need to retrieve values from one component to process LM operations on another component? (value propagation issue)

  11. Value Propagation? (1) • Do we need deployment time propagation (resolution) of configuration values? • If we can fix all values by resource reservation, we will not need this propagation CDDLM A C X? A deploy deploying C needs X which is fixed after A is deployed E C get X B deploy with X D

  12. Value Propagation? (2) • Do we need start-up time propagation (resolution) of configuration values? X? A CDDLM A C E C start B starting C needs X which is fixed after A is started get X D set X start

  13. When Value Propagation is Required • Value propagation is required if (and only if) there are read-only, observable attributes which values are assigned by deployment platform instead of CDDLM • e.g., It is the case if nobody (including resource managers) can tell which port number will be used by a component before it is actually deployed. • Otherwise, CDDLM can fix all values based on information from Job Management and does not require value propagation • Question: Do we need such attributes? [maybe]

  14. Impact to CDL:Read-only Attributes • CDL should support “read-only” attributes when value propagation is required • read-only deployment-time constant • CDDLM should inquire values from components after they deployed • read-only run-time constant • CDDLM should inquire values from components after they started • read-only dynamic • It is not manageable! – such values can not be consistently propagated to others.

  15. XML CDL Jun Tatemura NEC Laboratories America Feb 5, 2004

  16. XML CDL should address manageability issues rather than readability (user friendliness) issues • Front-end CDL (e.g., SmartFrog) would provide user-friendly features • Impacts from Lifecycle management requirements addressed • lifetime of attribute values • read-only attributes • Made use of existing XML features • XML Schema for data type checking • QName (namespace) for reference

  17. Attribute Sets • Configuration is a set of attribute-value pairs • The “extends” operation (from SmartFrog) for extensibility of configuration • Every attribute set can be referred with a QName <attributeSet name=“ncname” extends=“qname”?> <attribute/>* </attributeSet> extends reuse override addition

  18. Using QName for Attribute Set Name • Namespace realizes a globally unique reference to specify an attribute set <cdl targetNamespace=“uri1”> <attributeSet name=“abc” .../> </cdl> <cdl xmlns:tmpl=“uri1”> <attributeSet name=“myabc” extends=“tmpl:abc” .../> </cdl> A template CDL provided by the application provider CDL specified by the application user

  19. Attributes • A pair of name and value • Augmented by <type>, <lifetime>, <use>, etc. • type: type definition (XML Schema) • lifetime: deployment | runtime | (dynamic) • use: required | optional | (readonly) <attribute> <name/> <type/>? <lifetime/>? <value/>? <use/>? </attribute> <attribute> <name>host</name> <type>xns:ipAddress</type> <lifetime>deployment</lifetime> <use>required</use> <value>15.144.56.243</value> </attribute>

  20. Nested Attribute Sets • An attribute can have an attribute set as its value • Nesting of attribute sets is flattened and linked with references (QNames) <attribute> <name>database-server</name> <type>cddlm:refToAttributeSet</type> <lifetime>deployment</lifetime> <use>required</use> <value>tns:database</value> </attribute> <attributeSet name=“database” extends=“oracle” > <attribute .../> ... </attributeSet>

  21. Benefit from Attribute Overriding + Augmentation • Augmentation (type, lifetime,..) can be used for “requirements” from template providers • We can split type definition (given by e.g., application providers) and value definition (given by e.g., application users) • We can use XML Schema to validate attribute values <attribute> <name>host</name> <type>xns:ipAddress</type> <lifetime>deployment</lifetime> <use>required</use> </attribute> <attribute> <name>host</name> <value>15.144.56.243</value> </attribute> extends The application user can specify the actual value (CDDLM can validate it) The application provider can specify requirements on the attribute used in a component

  22. Component • Component associates an attribute set with content (software) • TBD: format for reference to content? destination of deployment should be written here? <component name=“ncname”> <configuration>qname</configuration> <content>uri?</content> </component> <attributeSet name=“database” extends=“oracle” > <attribute .../> ... </attributeSet> <component name=“myDatabase”> <configuration>tns:database</configuration> <content>location-of-content</content> </component> content

  23. Lifecycle Dependency • Define System as a set of components • Define “deployAfter” and “startAfter” to represent lifecycle dependency <system name=“ncname”> <component name=“qname” >+ <deployAfter>qname</deployAfter>* <startAfter>qname</startAfter>* </component> </system>

  24. Reference to Attributes • Required for constraints • Value Dependency • Assertion • Why I don’t use QName for Attributes? • An attribute name is unique only within an attribute set • I don’t want to define a namespace for each attribute set <reference name=“ncname”?> <attributeSet>qname</attributeSet> <attributeName>xsd:string</attributeName> </reference>

  25. Value Dependency • Value assignment to attributes derived from other attribute values • TBD: data transform expression language? (XPath 2.0, MathML, or CDDLM original?) <dependencies language=“uri”?> <reference />* <assign>+ <to><reference/></to> <from>{<reference/>|<expression/>}</from> </assign> </dependencies> <dependencies > <reference name=“x” .../> <assign> <to><reference .../></to> <from> <expression>$x+1</expression> </from> </assign> </dependencies>

  26. Assertion • Conditions on attribute values • All conditions on fixed values must be true to procees LM operations • TBD: condition expression language? (XPath 2.0, MathML, or CDDLM original? <assertions language=“uri”?> <reference />+ <assert>condition</assert>+ </assertions> <assertions> <reference name=“xhost” .../> <reference name=“yhost” .../> <assert>$xhost == $yhost</assert> </assertions>

  27. Places of Constraints <attributeSet> <attributes>* <dependencies>? <assertions>? </attributeSet> <component> ... <dependencies>? <assertions>? </component> <system> ... <dependencies>? <assertions>? </system>

  28. CDDLM Processor • Given Config/LM operations on a system, generate Config/LM operations on components • CDLs are integrated and complied into five sets of data (components, lifecycle dependencies, attribute sets, dependencies, assertions) SF component compiled attribute sets lifecycle dependencies Config Operations component dependencies CDL components CDL CDL component assertions Config Operations (Get/Set) LM Operations LM Operations (deploy, start, stop, remove,...)

  29. platform dependant deployment CDL CDL Local CDDLM Local CDDLM CDL Global CDDLM CDL Local CDDLM CDL CDL LM Operations (deploy, start, stop, remove,...) LM Operations (deploy, start, stop, remove,...) Local and Global CDDLMProcessors • Local CDDLM processor: required to deploy components on actual platforms • Global CDDLM processor: required to deploy components in a federated environment Local CDDLM generates platform dependent operations Global CDDLM generates CDDLM operations to local CDDLM processors

More Related