If I further explain the implementation design, When we create a cartridge definition, we can give whether it is required a persistence volume. Then subscription time, there will be a option to request persistence volume, and it validate the auto scaling policy. Then the Cloud Controller will create a volume and attache to the create instance, and pass detail into instance via the payload. So cartridge creator, when the cartridge creation phase, have to take this into how it can use for the particular cartridge. (like formatting, mounting ..etc). Also CC will update the topology with these volume details under member information. Then the event of member crashed or terminate, AS and CC will make sure re-attached the above volume to replaced instance.
On Wed, Jan 15, 2014 at 7:16 PM, Lakmal Warusawithana <[email protected]>wrote: > > > > On Wed, Jan 15, 2014 at 6:56 PM, Afkham Azeez <[email protected]> wrote: > >> So in this case we are only concerned about single instance, single >> volume deployment scenarios? That should be fine for now, but we need to >> think about how to deploy clustered data cartridges. Perhaps for the time >> being, it would be acceptable not to have autoscaling, but define the >> number of instances required, and then also have a volume per cartridge >> created. When it comes to assigning volumes, we could pick up one of the >> unattached volumes & attach it to the cartridge. Setting the min & max >> instances to the same value should prevent the autoscaler from trying to >> spin up new instances right? >> > > Yes, from auto scaling policy (which we can set min,max) we can prevent > the autoscaling. With the "min" property it will guarantee number of > instance required, and in that case it will create per volume for instance. > > >> >> Azeez >> >> >> On Wed, Jan 15, 2014 at 6:39 PM, Lakmal Warusawithana <[email protected]>wrote: >> >>> Hi Azeez, >>> >>> This persistence volumes only deal with "Data Cartridges", with in this >>> release we are not addressing auto scaling. We need to come with proper >>> solution for scaling data cartridges, mainly how we can handle data >>> replication. In this release we only address, in the case of cashed or >>> termination of the data cartridge, to recover the data. In this case it >>> will spin new instance and re-attached the previously create volume. >>> >>> >>> On Wed, Jan 15, 2014 at 6:29 PM, Afkham Azeez <[email protected]> wrote: >>> >>>> How will this work with autoscaling? Do you have to create the volumes >>>> in advance, and keep them ready to be mounted? One volume can be mounted to >>>> only one active instance right? >>>> >>>> Azeez >>>> >>>> >>>> On Tue, Jan 7, 2014 at 12:29 PM, Udara Liyanage <[email protected]> wrote: >>>> >>>>> Hi, >>>>> >>>>> I was in the process of implementing $subject for Stratos. I was able >>>>> to attach a volume in Amazon EC2. Though the volume is attached, currently >>>>> we have to mount the volume manually. Following are the solutions that I >>>>> am >>>>> thinking of now. >>>>> >>>>> 1) send the volume disk name via payload so within the agent shell >>>>> script we can manually mount the volume. >>>>> 2) find a way of mounting using jclouds >>>>> 2) find a way to automatically mount from the IAAS side. >>>>> >>>>> I think 1) is possible. Any better suggestions appreciated? >>>>> >>>>> -- >>>>> Udara Liyanage >>>>> Software Engineer >>>>> WSO2, Inc.: http://wso2.com >>>>> lean. enterprise. middleware >>>>> >>>>> web: http://udaraliyanage.wordpress.com >>>>> phone: +94 71 443 6897 >>>>> >>>> >>>> >>>> >>>> -- >>>> *Afkham Azeez* >>>> Director of Architecture; WSO2, Inc.; http://wso2.com, >>>> *Member; Apache Software Foundation; >>>> **http://www.apache.org/*<http://www.apache.org/> >>>> >>>> *email: **[email protected]* <[email protected]> >>>> * cell: +94 77 3320919 <%2B94%2077%203320919> blog: * >>>> *http://blog.afkham.org* <http://blog.afkham.org> >>>> *twitter: >>>> **http://twitter.com/afkham_azeez*<http://twitter.com/afkham_azeez> >>>> * linked-in: **http://lk.linkedin.com/in/afkhamazeez >>>> <http://lk.linkedin.com/in/afkhamazeez>* >>>> >>>> >>>> *Lean . Enterprise . Middleware* >>>> >>>> >>> >>> >>> -- >>> Lakmal Warusawithana >>> Software Architect; WSO2 Inc. >>> Mobile : +94714289692 >>> Blog : http://lakmalsview.blogspot.com/ >>> >>> >> >> >> -- >> *Afkham Azeez* >> Director of Architecture; WSO2, Inc.; http://wso2.com, >> *Member; Apache Software Foundation; >> **http://www.apache.org/*<http://www.apache.org/> >> >> *email: **[email protected]* <[email protected]> >> * cell: +94 77 3320919 <%2B94%2077%203320919> blog: * >> *http://blog.afkham.org* <http://blog.afkham.org> >> *twitter: **http://twitter.com/afkham_azeez*<http://twitter.com/afkham_azeez> >> * linked-in: **http://lk.linkedin.com/in/afkhamazeez >> <http://lk.linkedin.com/in/afkhamazeez>* >> >> *Lean . Enterprise . Middleware* >> >> > > > -- > Lakmal Warusawithana > Software Architect; WSO2 Inc. > Mobile : +94714289692 > Blog : http://lakmalsview.blogspot.com/ > > -- Lakmal Warusawithana Software Architect; WSO2 Inc. Mobile : +94714289692 Blog : http://lakmalsview.blogspot.com/
