-
Type: Task
-
Status: Closed
-
Priority: Major
-
Resolution: Unresolved
-
Affects Version/s: None
-
Fix Version/s: None
-
Component/s: Primer
-
Labels:None
This approach tentatively approved by the TC on 10/25:
a. Previous scenarios are good, but they're a bit too granular. Operating at the IaaS layer isn't really where the industry is headed. We want to show people how a more fine-grained approach to componentizing applications can be done (ie. head towards a more PaaS approach).
b. So, now we're going to take the previous examples and rather than snapshotting an entire VM and deploying that, we're going to just deploy the application code from within the VM. Meaning, we're just going to deploy something akin to a WAR/EAR file into a TOSCA container provided runtime.
c. Likewise, for the DB, rather than taking on the responsibility of managing a DB ourselves, we're going to use one provided to us by the TOSCA environment.
d. Change one VM deployment artifact for a WAR/EAR file - or whatever is appropriate to move us closer to the SugarCRM scenario.
e. Change the other VM (the DB) into whatever is needed to indicate that we're asking the TOSCA environment for a new SQL DB instance rather than us deploying the DB instance ourselves via a new VM.
f. Create the service template xml file
g. Create the CSAR file