I suggest the following: 1. Add full handling of failure recovery, recovery of database from selected snapshot/ backup version. download of snapshots and backups etc.
2. Improve the FAQ and documentation. For example: What to do in failure scenarios How to secure default Scalr AMIs How to setup default AMI for production. Optimizing, adding caching etc.. (I know it is not in Scalr scope/responsibility, but it will make Scalr more accessible and useful.) 3. Improve backup scenarios. (In my case) Mysql backup hurts the slave performance. There are some ways to avoid it like creating a temporary slave for backup which is not accessed by int/ext-mysql-slave. This should be supported in the Scalr level, not the application level. On Jul 14, 11:16 pm, Sebastian Stadil <[email protected]> wrote: > Hi everyone, > > We published our roadmap past Scalr 2.0 (which adds support for any linux > server and opens up capability to support any cloud) > athttp://wiki.scalr.net/Roadmap. Past that, proposals include: > > - Raid over EBS > - Accounts and Environments > - Scalable services (Cassandra, more suggestions? ffmpeg?) > - Scalable apps (Drupal, more suggestions?) > > From scalr.crowdsound.com, there's > > - LAMP stack setup > - Windows support > - Alerting / monitoring improvements > > What else? -- You received this message because you are subscribed to the Google Groups "scalr-discuss" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/scalr-discuss?hl=en.
