Just as an FYI (to whom it may concern): For me, personally, my primary focus has been (and continues to be) on bringing true storage Quality of Service (QoS) to CloudStack (guaranteed IOPS on a per-CloudStack-volume basis).
Prior to 4.2, CloudStack expected an admin to preallocate large amounts of storage (ex. a large volume on a SAN), then introduce this storage to his hypervisor, then create Primary Storage in CloudStack to represent that hypervisor-configured storage. At this point, a user could then create root and data disks that leveraged this storage (i.e. multiple root and data disks running on the same storage volume). That model may be efficient in terms of, say, number of iSCSI connections, but it is not very useful from the point of view of a storage system that is designed to deliver true QoS (eliminating the Noisy Neighbor effect by guaranteeing IOPS on a per-volume basis). In such a storage system, each volume on the SAN has independent QoS settings. In this world, it is ideal to map a single CloudStack volume to a single volume on the SAN. This means being able to create volumes on the SAN dynamically (ex. when a CloudStack volume is attached to a VM for the first time). Much of what Edison Su worked on for 4.2's storage-framework changes enabled me to take a large first step in that I could create a plug-in that could dynamically create volumes on our SAN (SolidFire SAN). However, the concept of preallocated storage is so embedded in CloudStack that I've needed to update core components of CloudStack, as well as CloudStack hypervisor-related code, to deal with dynamically created volumes. In 4.2 I released support for storage QoS with data disks on XenServer and VMware. In 4.3 I am releasing support for storage Qos with data disks on KVM. As we move forward, I plan to support storage QoS with root volumes on these hypervisors, as well (most likely starting with XenServer). It has been a bit tricky to support hypervisor snapshots in this model (where volumes are created dynamically on a SAN and the hypervisor data structures like SRs or datastores are created behind the scenes). This is another area I'm tackling for the 4.3 release (for XenServer and VMware). On Wed, Nov 13, 2013 at 11:50 AM, Steve Wilson <steve.wil...@citrix.com>wrote: > Hi Daan, Prasanna, Simon, David and Andrei! > > Thanks for chiming in. Great way to kick off the discussion. > > In my thinking, we might want to look at things in three buckets: > > 1. Things that could go into a maintenance release like a 4.2.x > 2. Things that could go into a minor release like a 4.4 > 3. Things that would require major architecture changes and might wind up > in 5.0 or something like it > > From a Citrix perspective, we're definitely looking at things that fall > into all three of these buckets. We've contributed a huge number of fixes > to 4.2.1 and a number of features to 4.3. We're also now starting to plan > our contributions to 4.4 as well. However, since I joined the community, > I've seen very little discussion of what's really next. What are the > major things we'd like to see done? I don¹t have a particular timeframe > in mind for these things, I'm just looking to spark discussion -- > especially as we go to Collab next week. > > Things that are interesting to me that fit in bucket three. Here are a > couple: > > What level of scale should CloudStack be able to support? I imagine we'll > bee CloudStack clouds managing millions of VMs in the next few years. > What do we need to do to make that effective? > > I think people will want to manage "micro-clouds" -- very small, but > flexible clouds for special purpose needs. What would CloudStack need to > do to scale down very small and still be cost effective to run? > > Any thoughts about these, or any other ideas? > > -Steve > > > On 11/12/13 9:58 PM, "Daan Hoogland" <daan.hoogl...@gmail.com> wrote: > > >I don't see any sugestions I don't like (including not breaking api) but, > > > >- I like to second Simnons 'HA for VPC routers' > >extra. It is hurting not having that. > > > >- smaller releases is another one. monthly preferably or maybe an db > >upgrade model that allows for running snapshots and upgrading them > >regularly. The time to market for new features is now between 4 and 8 > >months:( > > > >- related: master as a stable/always building and passing unit tests > > > >On Wed, Nov 13, 2013 at 6:39 AM, Prasanna Santhanam <t...@apache.org> > >wrote: > >> On Tue, Nov 12, 2013 at 11:41:17PM +0000, Steve Wilson wrote: > >>> Hi All, > >>> > >>> As we ramp towards freeze on 4.3 and start talking about 4.4, I > >>> thought it would be fun to queue up a discussion here on the list > >>> before Collab next week. > >>> > >>> What do you envision in the next MAJOR release of CloudStack? Call > >>> it 5.0 or whatever you like, but what would you like to see there? > >>> What would you change? What would you enhance? Are there big bets > >>> we should be placing as a community? > >>> > >>> Feel free to post any thoughts here and I'll look forward to talking > >>> to many of you in person at Collab next week. You are coming to > >>> Collab, right? > >>> > >> > >> simplified upgradeability at all stages of development from version x > >> to version y. > >> > >> -- > >> Prasanna., > >> > >> ------------------------ > >> Powered by BigRock.com > >> > > -- *Mike Tutkowski* *Senior CloudStack Developer, SolidFire Inc.* e: mike.tutkow...@solidfire.com o: 303.746.7302 Advancing the way the world uses the cloud<http://solidfire.com/solution/overview/?video=play> *™*
