Hi Lakmal, Thanks for the clarification, now I got a clear picture of what we meant by an application for the initial release. I was under the impression that an application is pre built and deployed later.
Let me try to put together a sample work flow according to this design: Tenant Admin Tasks: 1. Define IaaS configuration 2. Register docker clusters 3. Deploy partitions 4. Deploy autoscaling policies 5. Deploy deployment policies 6. Deploy cartridges Tenant User Tasks: 1. Create service groups 2. Create an application using available cartridges, policies, by defining dependencies, etc 3. Deploy application Dakshika: Shall we use this work flow in the UI? Thanks On Wed, Nov 5, 2014 at 8:05 PM, Lakmal Warusawithana <[email protected]> wrote: > > > On Wed, Nov 5, 2014 at 11:44 AM, Imesh Gunaratne <[email protected]> wrote: > >> On Wed, Nov 5, 2014 at 12:54 AM, Lakmal Warusawithana <[email protected]> >> wrote: >> >>> >>> No, it should through the application deploy. If its a single cartridge, >>> then application json has single cartridge info. >>> >> >> Lakmal: I understand that the current design is to start all service >> clusters when the application is deployed. However I see following >> limitations with this design: >> - We cannot maintain a list of available applications within Stratos >> unless we connect an app store. >> > > We may have pre build application templates, but not in this stage. We > can't have all in one release IMO, but that was the plan. > Shall we come up with UI for application creation using cartridges, > policies, dependancies ..etc > > >> - Since all service clustered get created at the application deployment >> time, resources will get allocated even when applications are not used by >> tenants. >> > > What is an application, why tenant/user create/deploy an application. We > are deploy an application, that because we need run time for my > application, yes that mean, it need resource allocation which is the > expectation. (same as previous cartridge subscription). Application > resources can down to minimum when tenants are not using, thats why auto > scaling policies meant to do. > > >> - Applications are not reusable by multiple tenants: Since the >> application definition contains the artifact repo information the deployed >> application get bound to the given repository. If another tenant needs the >> same application we need to deploy it again with a different settings. >> >> > You mean application jsons? If you refer it as application, has some > confusion with the runtime :). We have to provide generate application > templates with the defined application json, by removing all tenants level > information. Again, IMO in the next release. :) > > > WDYT? >> >> Thanks >> >> On Wed, Nov 5, 2014 at 10:27 AM, Lahiru Sandaruwan <[email protected]> >> wrote: >> >>> >>> >>> On Tue, Nov 4, 2014 at 11:54 PM, Imesh Gunaratne <[email protected]> >>> wrote: >>> >>>> Hi Devs, >>>> >>>> In Stratos 4.0.0 release we used following terminology: >>>> >>>> *Create a Cartridge * >>>> Create a VM/docker image, configuration management (puppet) module and >>>> specify cartridge definition >>>> >>>> *Deploy a Cartridge* >>>> Upload a cartridge definition to Stratos. >>>> >>>> *Subscribe to a Cartridge* >>>> Create an instance/cluster of above cartridge >>>> >>>> *Un-Subscribe from a Cartridge* >>>> Remove the instance/cluster created in the subscription >>>> >>>> *Un-Deploy a Cartridge* >>>> Remove a cartridge definition from Stratos >>>> >>>> Now with service grouping things have been changed slightly and we may >>>> need to consider using new terminology for this process. How do you like >>>> following terminology: >>>> >>>> *Create an Application* >>>> Create VM/docker images, configuration management (puppet) modules, >>>> specify cartridge definitions, dependencies and application definition >>>> >>>> *Deploy an Application* >>>> Upload an application definition to Stratos >>>> >>>> *Start an Application* >>>> Create an instance of the application and create clusters for the >>>> corrosponding cartridges. >>>> >>> >>> +1 for separation of these actions. It will increase the usability. >>> >>>> >>>> *Stop an Application* >>>> Remove the application instance and clusters created in application >>>> startup process. >>>> >>>> *Un-Deploy an Application* >>>> Remove an application definition from Stratos >>>> >>>> In addition to these we may still use the terms: Create/Deploy/Undeploy >>>> Cartridge. >>>> >>>> I noticed that with the latest grouping changes we have removed the >>>> concept of subscription and included it in the deployment phase. IMO it >>>> would be better to have a separation between these two steps because >>>> otherwise all applications deployed in Stratos will be up and running all >>>> the time. >>>> >>>> Thanks >>>> >>>> >>>> >>>> -- >>>> Imesh Gunaratne >>>> >>>> Technical Lead, WSO2 >>>> Committer & PMC Member, Apache Stratos >>>> >>> >>> >>> >>> -- >>> -- >>> Lahiru Sandaruwan >>> Committer and PMC member, Apache Stratos, >>> Senior Software Engineer, >>> WSO2 Inc., http://wso2.com >>> lean.enterprise.middleware >>> >>> email: [email protected] blog: http://lahiruwrites.blogspot.com/ >>> linked-in: http://lk.linkedin.com/pub/lahiru-sandaruwan/16/153/146 >>> >>> >> >> >> -- >> Imesh Gunaratne >> >> Technical Lead, WSO2 >> Committer & PMC Member, Apache Stratos >> > > > > -- > Lakmal Warusawithana > Vice President, Apache Stratos > Director - Cloud Architecture; WSO2 Inc. > Mobile : +94714289692 > Blog : http://lakmalsview.blogspot.com/ > > -- Imesh Gunaratne Technical Lead, WSO2 Committer & PMC Member, Apache Stratos
