You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cloudstack.apache.org by Steve Wilson <st...@citrix.com> on 2013/11/13 00:41:17 UTC
CloudStack.next
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?
-Steve
Steve Wilson
VP, Cloud Engineering
Citrix
twitter: @virtualsteve
Re: CloudStack.next
Posted by Nux! <nu...@li.nux.ro>.
On 18.11.2013 21:32, Chiradeep Vittal wrote:
> Realhostip.com is not required. See:
> http://support.citrix.com/article/CTX133468
>
>
> But I agree that realhostip should not be made the default (default
> should
> be http).
Can this be tweaked from Global Settings?
Lucian
--
Sent from the Delta quadrant using Borg technology!
Nux!
www.nux.ro
Re: CloudStack.next
Posted by Chiradeep Vittal <Ch...@citrix.com>.
Realhostip.com is not required. See:
http://support.citrix.com/article/CTX133468
But I agree that realhostip should not be made the default (default should
be http).
On 11/16/13 2:30 AM, "Nux!" <nu...@li.nux.ro> wrote:
>On 12.11.2013 23:41, 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?
>
>My wishlist, based on not very intensive use so far:
>- better support for KVM (VM snapshots, SPICE support etc)
>- get rid of realhostip.com
>- dynamic size for the ROOT disk (so openstack templates can be used
>with minimal modifications)
>- good support for SDN (make VXLAN default etc)
>
>Lucian
>
>--
>Sent from the Delta quadrant using Borg technology!
>
>Nux!
>www.nux.ro
Re: CloudStack.next
Posted by Nux! <nu...@li.nux.ro>.
On 12.11.2013 23:41, 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?
My wishlist, based on not very intensive use so far:
- better support for KVM (VM snapshots, SPICE support etc)
- get rid of realhostip.com
- dynamic size for the ROOT disk (so openstack templates can be used
with minimal modifications)
- good support for SDN (make VXLAN default etc)
Lucian
--
Sent from the Delta quadrant using Borg technology!
Nux!
www.nux.ro
Re: CloudStack.next
Posted by Yoshikazu Nojima <ma...@ynojima.net>.
+1 especially to CI process improvement.
IMO, we need to improve the patch review process.
Sometimes we encounter that the master branch is broken. Low quality
commit slows down our developing and testing on the master branch.
I think we should change the patch review process to check that a
patch pass unit test before it is merged to the master.
There are Jenkins plugins that help pre-commit testing.
They observe a patch submission, create a test branch that merges the
master branch and the patch, run tests on the branch, and write back
the result on the ReviewBoard or the Github PullRequest.
https://wiki.jenkins-ci.org/display/JENKINS/Jenkins-Reviewbot (for ReviewBoard)
https://wiki.jenkins-ci.org/display/JENKINS/GitHub+pull+request+builder+plugin
(for Github PullRequest)
we need to consider these kind pre-commit auto testing tool adoption.
> -our testing infra needs to get much better, continuous testing for all branches, testing on commits etc…maybe we should find a way to get help from cloudbees to get us on the right tracks. Overall > we need to be able to release at any instant with confidence.
- Noji
2013/11/15 Sebastien Goasguen <ru...@gmail.com>:
> Hi, this is a bit of a brain dump:
>
> I tend to see different types of buckets:
>
> 1-Processes
> Involves getting better as a community in terms of release, bug fixing, committing code, documentation and user support. Some of these have already been discussed partially but we need to come to consensus and act.
> For example:
> -we should have no unanswered questions on the lists. Anyway to have an official volunteer support team ? With a 24/7 twilio number on the site that rings up someone out there :) ?
> -we should catch up on bug fixing (and great job on 4.2.1 btw)
> -when we commit we cannot break master, and I also would argue for committing docs when it's a new feature, right now master is a catch all, instead of a super stable, high quality branch.
> -we need much better docs
> -we need to define standards for releases: RN, changes file, upgrade paths, testing etc.
> -our testing infra needs to get much better, continuous testing for all branches, testing on commits etc…maybe we should find a way to get help from cloudbees to get us on the right tracks. Overall we need to be able to release at any instant with confidence.
> -no feature should be un-documented and/or un-tested. for instance: there was a recent complaint about lack of F5 documentation, and right now I have no clue who is testing the F5 integration.
>
> 2-Ecosystem
> We need to build up the ecosystem around cloudstack and advertize it.
> We integrate with almost everything out there, yet people don't know it. I wish that:
> 2.1 we would improve on support in existing software: all configuration mgt systems, main cloud libraries, PaaS etc...
> 2.2 work with everyone in that ecosystem to advertize and demo CloudStack integration
> 2.3 work on extending that ecosystem (e.g Docker support, Cloudfoundry, Mesos, Spark, OpenDaylight controller) some of it is just a matter of writing a tutorial, some of it there is actual coding involved.
> 2.4 restart effort on AWS: as mentioned IAM is needed but there is more, we need to catch with euca and integrate with netflixOSS software. Bring EMR, ELB, CloudWatch etc…I have plans to work on this and hopefully propose a standalone AWS-ACS bridge with extended services.
>
> 3-Code (caveat, I am not a java developer)
> I still would love to see a lot of cleanup and review. For example I believe the KVM agent uses some python scripts in cloud-cli, those don't use Marvin. We should try to consolidate these. There is code in the tree that is unused, we should clean it up. In the UI when you add a cluster we still list 'OVM' yet it's broken, we need to clean. OStypes in image creation, we need to clean up...
> Packaging and mavenization, we should finish that up and really make it super strong. We need to call out to maven and package experts for a hand.
> We had a small thread on KVM agent and we will have a talk at the hackathon, here I will pick on Xen:
> We need much better support for Xen_Project without using xapi (the xapi install on XP is a pain), without xapi we could easily have ARM / Ceph support…
> Overall I would like to see a strong core emerge with clean code separation with UI, DB abstraction, backend drivers and plugins. ( A bit pie in the sky, but a non java guy should be able to keep the core and replace/add any other component, plug and play)
> Biggest item is probably a software architecture blueprint, right now we don't have that. No UML diagram, no sequence diagram, most people don't know how cloudstack actually works.
>
> -seb (I will invest time on the ecosystem bucket)
>
> On Nov 14, 2013, at 10:18 PM, Chiradeep Vittal <Ch...@citrix.com> wrote:
>
>> +1 to IAM.
>>
>> An Autoscale service independent of Netscaler.
>> I'd like to see the built-in GRE controller fully fleshed out as a
>> distributed/cross-AZ virtual network provider. Make it the out-of-the-box
>> virtual network provider instead of VLAN.
>> Easier service vm insertion into virtual networks.
>> Better fidelity with AWS VPC APIs
>>
>>
>>
>>
>> On 11/12/13 6:09 PM, "Simon Murphy" <si...@vifx.co.nz> wrote:
>>
>>> As a CloudStack user, here are the ares that I feel need attention:
>>>
>>> - improved IAM and implementation of a full RBAC security model. This is
>>> hurting us right now.
>>> - improved VM import functionality (ie bulk import of VM's and import of
>>> running VM's from existing vSphere clusters)
>>> - improved backup functionality and integration with 3rd party tools
>>> - HA for VPC routers
>>>
>>> Cheers,
>>> Simon Murphy
>>> Solutions Architect
>>>
>>> ViFX | Cloud Infrastructure
>>> Level 7, 57 Fort Street, Auckland, New Zealand 1010
>>> PO Box 106700, Auckland, New Zealand 1143
>>> M +64 21 285 4519 | S simon_a_murphy
>>> www.vifx.co.nz <http://www.vifx.co.nz/> follow us on twitter
>>> <https://twitter.com/ViFX>
>>> Auckland | Wellington | Christchurch
>>>
>>>
>>>
>>> experience. expertise. execution.
>>>
>>> This email and any files transmitted with it are confidential, without
>>> prejudice and may contain information that is subject to legal privilege.
>>> It is intended solely for the use of the individual/s to whom it is
>>> addressed in accordance with the provisions of the Privacy Act (1993). The
>>> content contained in this email does not, necessarily, reflect the
>>> official policy position of ViFX nor does ViFX have any responsibility for
>>> any alterations to the contents of this email that may occur following
>>> transmission. If you are not the addressee it may be unlawful for you to
>>> read, copy, distribute, disclose or otherwise use the information
>>> contained within this email. If you are not the intended recipient, please
>>> notify the sender prior to deleting this email message from your system.
>>> Please note ViFX reserves the right to monitor, from time to time, the
>>> communications sent to and from its email network.
>>>
>>>
>>>
>>>
>>>
>>>
>>> On 13/11/13 1:18 PM, "David Nalley" <da...@gnsa.us> wrote:
>>>
>>>> On Tue, Nov 12, 2013 at 6:41 PM, Steve Wilson <st...@citrix.com>
>>>> 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?
>>>>>
>>>>
>>>>
>>>> Hi Steve,
>>>>
>>>> I'll be contrarian ;) - I don't see 5.0 (e.g. API breaking changes)
>>>> coming in at least the next 12-18 months. Breaking API compatibility
>>>> is a BIG DEAL IMO and should be done very deliberately and with a lot
>>>> of consideration, and a plan around how we help folks adapt.
>>>>
>>>> Think about the tons of integrations that we have now: Chef, Puppet,
>>>> Salt, libcloud, fog, jclouds, dasein, etc etc. Breaking that directly
>>>> disrupts our users who stand a good chance of using one of those
>>>> integrations or consume CloudStack via one of those tools.
>>>>
>>>> --David
>>>
>>
>
RE: CloudStack.next
Posted by Radhika Puthiyetath <ra...@citrix.com>.
+ 1 to process improvements and ecosystems (advertising CloudStack, reaching out to the student community, which I always stand for)
-----Original Message-----
From: Sebastien Goasguen [mailto:runseb@gmail.com]
Sent: Friday, November 15, 2013 7:38 PM
To: dev@cloudstack.apache.org
Subject: Re: CloudStack.next
Hi, this is a bit of a brain dump:
I tend to see different types of buckets:
1-Processes
Involves getting better as a community in terms of release, bug fixing, committing code, documentation and user support. Some of these have already been discussed partially but we need to come to consensus and act.
For example:
-we should have no unanswered questions on the lists. Anyway to have an official volunteer support team ? With a 24/7 twilio number on the site that rings up someone out there :) ?
-we should catch up on bug fixing (and great job on 4.2.1 btw) -when we commit we cannot break master, and I also would argue for committing docs when it's a new feature, right now master is a catch all, instead of a super stable, high quality branch.
-we need much better docs
-we need to define standards for releases: RN, changes file, upgrade paths, testing etc.
-our testing infra needs to get much better, continuous testing for all branches, testing on commits etc...maybe we should find a way to get help from cloudbees to get us on the right tracks. Overall we need to be able to release at any instant with confidence.
-no feature should be un-documented and/or un-tested. for instance: there was a recent complaint about lack of F5 documentation, and right now I have no clue who is testing the F5 integration.
2-Ecosystem
We need to build up the ecosystem around cloudstack and advertize it.
We integrate with almost everything out there, yet people don't know it. I wish that:
2.1 we would improve on support in existing software: all configuration mgt systems, main cloud libraries, PaaS etc...
2.2 work with everyone in that ecosystem to advertize and demo CloudStack integration
2.3 work on extending that ecosystem (e.g Docker support, Cloudfoundry, Mesos, Spark, OpenDaylight controller) some of it is just a matter of writing a tutorial, some of it there is actual coding involved.
2.4 restart effort on AWS: as mentioned IAM is needed but there is more, we need to catch with euca and integrate with netflixOSS software. Bring EMR, ELB, CloudWatch etc...I have plans to work on this and hopefully propose a standalone AWS-ACS bridge with extended services.
3-Code (caveat, I am not a java developer) I still would love to see a lot of cleanup and review. For example I believe the KVM agent uses some python scripts in cloud-cli, those don't use Marvin. We should try to consolidate these. There is code in the tree that is unused, we should clean it up. In the UI when you add a cluster we still list 'OVM' yet it's broken, we need to clean. OStypes in image creation, we need to clean up...
Packaging and mavenization, we should finish that up and really make it super strong. We need to call out to maven and package experts for a hand.
We had a small thread on KVM agent and we will have a talk at the hackathon, here I will pick on Xen:
We need much better support for Xen_Project without using xapi (the xapi install on XP is a pain), without xapi we could easily have ARM / Ceph support... Overall I would like to see a strong core emerge with clean code separation with UI, DB abstraction, backend drivers and plugins. ( A bit pie in the sky, but a non java guy should be able to keep the core and replace/add any other component, plug and play) Biggest item is probably a software architecture blueprint, right now we don't have that. No UML diagram, no sequence diagram, most people don't know how cloudstack actually works.
-seb (I will invest time on the ecosystem bucket)
On Nov 14, 2013, at 10:18 PM, Chiradeep Vittal <Ch...@citrix.com> wrote:
> +1 to IAM.
>
> An Autoscale service independent of Netscaler.
> I'd like to see the built-in GRE controller fully fleshed out as a
> distributed/cross-AZ virtual network provider. Make it the
> out-of-the-box virtual network provider instead of VLAN.
> Easier service vm insertion into virtual networks.
> Better fidelity with AWS VPC APIs
>
>
>
>
> On 11/12/13 6:09 PM, "Simon Murphy" <si...@vifx.co.nz> wrote:
>
>> As a CloudStack user, here are the ares that I feel need attention:
>>
>> - improved IAM and implementation of a full RBAC security model. This
>> is hurting us right now.
>> - improved VM import functionality (ie bulk import of VM's and import
>> of running VM's from existing vSphere clusters)
>> - improved backup functionality and integration with 3rd party tools
>> - HA for VPC routers
>>
>> Cheers,
>> Simon Murphy
>> Solutions Architect
>>
>> ViFX | Cloud Infrastructure
>> Level 7, 57 Fort Street, Auckland, New Zealand 1010 PO Box 106700,
>> Auckland, New Zealand 1143 M +64 21 285 4519 | S simon_a_murphy
>> www.vifx.co.nz <http://www.vifx.co.nz/> follow us on twitter
>> <https://twitter.com/ViFX> Auckland | Wellington | Christchurch
>>
>>
>>
>> experience. expertise. execution.
>>
>> This email and any files transmitted with it are confidential,
>> without prejudice and may contain information that is subject to legal privilege.
>> It is intended solely for the use of the individual/s to whom it is
>> addressed in accordance with the provisions of the Privacy Act
>> (1993). The content contained in this email does not, necessarily,
>> reflect the official policy position of ViFX nor does ViFX have any
>> responsibility for any alterations to the contents of this email that
>> may occur following transmission. If you are not the addressee it may
>> be unlawful for you to read, copy, distribute, disclose or otherwise
>> use the information contained within this email. If you are not the
>> intended recipient, please notify the sender prior to deleting this email message from your system.
>> Please note ViFX reserves the right to monitor, from time to time,
>> the communications sent to and from its email network.
>>
>>
>>
>>
>>
>>
>> On 13/11/13 1:18 PM, "David Nalley" <da...@gnsa.us> wrote:
>>
>>> On Tue, Nov 12, 2013 at 6:41 PM, Steve Wilson
>>> <st...@citrix.com>
>>> 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?
>>>>
>>>
>>>
>>> Hi Steve,
>>>
>>> I'll be contrarian ;) - I don't see 5.0 (e.g. API breaking changes)
>>> coming in at least the next 12-18 months. Breaking API compatibility
>>> is a BIG DEAL IMO and should be done very deliberately and with a
>>> lot of consideration, and a plan around how we help folks adapt.
>>>
>>> Think about the tons of integrations that we have now: Chef, Puppet,
>>> Salt, libcloud, fog, jclouds, dasein, etc etc. Breaking that
>>> directly disrupts our users who stand a good chance of using one of
>>> those integrations or consume CloudStack via one of those tools.
>>>
>>> --David
>>
>
Re: CloudStack.next
Posted by Sebastien Goasguen <ru...@gmail.com>.
Hi, this is a bit of a brain dump:
I tend to see different types of buckets:
1-Processes
Involves getting better as a community in terms of release, bug fixing, committing code, documentation and user support. Some of these have already been discussed partially but we need to come to consensus and act.
For example:
-we should have no unanswered questions on the lists. Anyway to have an official volunteer support team ? With a 24/7 twilio number on the site that rings up someone out there :) ?
-we should catch up on bug fixing (and great job on 4.2.1 btw)
-when we commit we cannot break master, and I also would argue for committing docs when it's a new feature, right now master is a catch all, instead of a super stable, high quality branch.
-we need much better docs
-we need to define standards for releases: RN, changes file, upgrade paths, testing etc.
-our testing infra needs to get much better, continuous testing for all branches, testing on commits etc…maybe we should find a way to get help from cloudbees to get us on the right tracks. Overall we need to be able to release at any instant with confidence.
-no feature should be un-documented and/or un-tested. for instance: there was a recent complaint about lack of F5 documentation, and right now I have no clue who is testing the F5 integration.
2-Ecosystem
We need to build up the ecosystem around cloudstack and advertize it.
We integrate with almost everything out there, yet people don't know it. I wish that:
2.1 we would improve on support in existing software: all configuration mgt systems, main cloud libraries, PaaS etc...
2.2 work with everyone in that ecosystem to advertize and demo CloudStack integration
2.3 work on extending that ecosystem (e.g Docker support, Cloudfoundry, Mesos, Spark, OpenDaylight controller) some of it is just a matter of writing a tutorial, some of it there is actual coding involved.
2.4 restart effort on AWS: as mentioned IAM is needed but there is more, we need to catch with euca and integrate with netflixOSS software. Bring EMR, ELB, CloudWatch etc…I have plans to work on this and hopefully propose a standalone AWS-ACS bridge with extended services.
3-Code (caveat, I am not a java developer)
I still would love to see a lot of cleanup and review. For example I believe the KVM agent uses some python scripts in cloud-cli, those don't use Marvin. We should try to consolidate these. There is code in the tree that is unused, we should clean it up. In the UI when you add a cluster we still list 'OVM' yet it's broken, we need to clean. OStypes in image creation, we need to clean up...
Packaging and mavenization, we should finish that up and really make it super strong. We need to call out to maven and package experts for a hand.
We had a small thread on KVM agent and we will have a talk at the hackathon, here I will pick on Xen:
We need much better support for Xen_Project without using xapi (the xapi install on XP is a pain), without xapi we could easily have ARM / Ceph support…
Overall I would like to see a strong core emerge with clean code separation with UI, DB abstraction, backend drivers and plugins. ( A bit pie in the sky, but a non java guy should be able to keep the core and replace/add any other component, plug and play)
Biggest item is probably a software architecture blueprint, right now we don't have that. No UML diagram, no sequence diagram, most people don't know how cloudstack actually works.
-seb (I will invest time on the ecosystem bucket)
On Nov 14, 2013, at 10:18 PM, Chiradeep Vittal <Ch...@citrix.com> wrote:
> +1 to IAM.
>
> An Autoscale service independent of Netscaler.
> I'd like to see the built-in GRE controller fully fleshed out as a
> distributed/cross-AZ virtual network provider. Make it the out-of-the-box
> virtual network provider instead of VLAN.
> Easier service vm insertion into virtual networks.
> Better fidelity with AWS VPC APIs
>
>
>
>
> On 11/12/13 6:09 PM, "Simon Murphy" <si...@vifx.co.nz> wrote:
>
>> As a CloudStack user, here are the ares that I feel need attention:
>>
>> - improved IAM and implementation of a full RBAC security model. This is
>> hurting us right now.
>> - improved VM import functionality (ie bulk import of VM's and import of
>> running VM's from existing vSphere clusters)
>> - improved backup functionality and integration with 3rd party tools
>> - HA for VPC routers
>>
>> Cheers,
>> Simon Murphy
>> Solutions Architect
>>
>> ViFX | Cloud Infrastructure
>> Level 7, 57 Fort Street, Auckland, New Zealand 1010
>> PO Box 106700, Auckland, New Zealand 1143
>> M +64 21 285 4519 | S simon_a_murphy
>> www.vifx.co.nz <http://www.vifx.co.nz/> follow us on twitter
>> <https://twitter.com/ViFX>
>> Auckland | Wellington | Christchurch
>>
>>
>>
>> experience. expertise. execution.
>>
>> This email and any files transmitted with it are confidential, without
>> prejudice and may contain information that is subject to legal privilege.
>> It is intended solely for the use of the individual/s to whom it is
>> addressed in accordance with the provisions of the Privacy Act (1993). The
>> content contained in this email does not, necessarily, reflect the
>> official policy position of ViFX nor does ViFX have any responsibility for
>> any alterations to the contents of this email that may occur following
>> transmission. If you are not the addressee it may be unlawful for you to
>> read, copy, distribute, disclose or otherwise use the information
>> contained within this email. If you are not the intended recipient, please
>> notify the sender prior to deleting this email message from your system.
>> Please note ViFX reserves the right to monitor, from time to time, the
>> communications sent to and from its email network.
>>
>>
>>
>>
>>
>>
>> On 13/11/13 1:18 PM, "David Nalley" <da...@gnsa.us> wrote:
>>
>>> On Tue, Nov 12, 2013 at 6:41 PM, Steve Wilson <st...@citrix.com>
>>> 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?
>>>>
>>>
>>>
>>> Hi Steve,
>>>
>>> I'll be contrarian ;) - I don't see 5.0 (e.g. API breaking changes)
>>> coming in at least the next 12-18 months. Breaking API compatibility
>>> is a BIG DEAL IMO and should be done very deliberately and with a lot
>>> of consideration, and a plan around how we help folks adapt.
>>>
>>> Think about the tons of integrations that we have now: Chef, Puppet,
>>> Salt, libcloud, fog, jclouds, dasein, etc etc. Breaking that directly
>>> disrupts our users who stand a good chance of using one of those
>>> integrations or consume CloudStack via one of those tools.
>>>
>>> --David
>>
>
Re: CloudStack.next
Posted by Chiradeep Vittal <Ch...@citrix.com>.
+1 to IAM.
An Autoscale service independent of Netscaler.
I'd like to see the built-in GRE controller fully fleshed out as a
distributed/cross-AZ virtual network provider. Make it the out-of-the-box
virtual network provider instead of VLAN.
Easier service vm insertion into virtual networks.
Better fidelity with AWS VPC APIs
On 11/12/13 6:09 PM, "Simon Murphy" <si...@vifx.co.nz> wrote:
>As a CloudStack user, here are the ares that I feel need attention:
>
>- improved IAM and implementation of a full RBAC security model. This is
>hurting us right now.
>- improved VM import functionality (ie bulk import of VM's and import of
>running VM's from existing vSphere clusters)
>- improved backup functionality and integration with 3rd party tools
>- HA for VPC routers
>
>Cheers,
>Simon Murphy
>Solutions Architect
>
>ViFX | Cloud Infrastructure
>Level 7, 57 Fort Street, Auckland, New Zealand 1010
>PO Box 106700, Auckland, New Zealand 1143
>M +64 21 285 4519 | S simon_a_murphy
>www.vifx.co.nz <http://www.vifx.co.nz/> follow us on twitter
><https://twitter.com/ViFX>
>Auckland | Wellington | Christchurch
>
>
>
>experience. expertise. execution.
>
>This email and any files transmitted with it are confidential, without
>prejudice and may contain information that is subject to legal privilege.
>It is intended solely for the use of the individual/s to whom it is
>addressed in accordance with the provisions of the Privacy Act (1993). The
>content contained in this email does not, necessarily, reflect the
>official policy position of ViFX nor does ViFX have any responsibility for
>any alterations to the contents of this email that may occur following
>transmission. If you are not the addressee it may be unlawful for you to
>read, copy, distribute, disclose or otherwise use the information
>contained within this email. If you are not the intended recipient, please
>notify the sender prior to deleting this email message from your system.
>Please note ViFX reserves the right to monitor, from time to time, the
>communications sent to and from its email network.
>
>
>
>
>
>
>On 13/11/13 1:18 PM, "David Nalley" <da...@gnsa.us> wrote:
>
>>On Tue, Nov 12, 2013 at 6:41 PM, Steve Wilson <st...@citrix.com>
>>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?
>>>
>>
>>
>>Hi Steve,
>>
>>I'll be contrarian ;) - I don't see 5.0 (e.g. API breaking changes)
>>coming in at least the next 12-18 months. Breaking API compatibility
>>is a BIG DEAL IMO and should be done very deliberately and with a lot
>>of consideration, and a plan around how we help folks adapt.
>>
>>Think about the tons of integrations that we have now: Chef, Puppet,
>>Salt, libcloud, fog, jclouds, dasein, etc etc. Breaking that directly
>>disrupts our users who stand a good chance of using one of those
>>integrations or consume CloudStack via one of those tools.
>>
>>--David
>
Re: CloudStack.next
Posted by Simon Murphy <si...@vifx.co.nz>.
As a CloudStack user, here are the ares that I feel need attention:
- improved IAM and implementation of a full RBAC security model. This is
hurting us right now.
- improved VM import functionality (ie bulk import of VM's and import of
running VM's from existing vSphere clusters)
- improved backup functionality and integration with 3rd party tools
- HA for VPC routers
Cheers,
Simon Murphy
Solutions Architect
ViFX | Cloud Infrastructure
Level 7, 57 Fort Street, Auckland, New Zealand 1010
PO Box 106700, Auckland, New Zealand 1143
M +64 21 285 4519 | S simon_a_murphy
www.vifx.co.nz <http://www.vifx.co.nz/> follow us on twitter
<https://twitter.com/ViFX>
Auckland | Wellington | Christchurch
experience. expertise. execution.
This email and any files transmitted with it are confidential, without
prejudice and may contain information that is subject to legal privilege.
It is intended solely for the use of the individual/s to whom it is
addressed in accordance with the provisions of the Privacy Act (1993). The
content contained in this email does not, necessarily, reflect the
official policy position of ViFX nor does ViFX have any responsibility for
any alterations to the contents of this email that may occur following
transmission. If you are not the addressee it may be unlawful for you to
read, copy, distribute, disclose or otherwise use the information
contained within this email. If you are not the intended recipient, please
notify the sender prior to deleting this email message from your system.
Please note ViFX reserves the right to monitor, from time to time, the
communications sent to and from its email network.
On 13/11/13 1:18 PM, "David Nalley" <da...@gnsa.us> wrote:
>On Tue, Nov 12, 2013 at 6:41 PM, Steve Wilson <st...@citrix.com>
>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?
>>
>
>
>Hi Steve,
>
>I'll be contrarian ;) - I don't see 5.0 (e.g. API breaking changes)
>coming in at least the next 12-18 months. Breaking API compatibility
>is a BIG DEAL IMO and should be done very deliberately and with a lot
>of consideration, and a plan around how we help folks adapt.
>
>Think about the tons of integrations that we have now: Chef, Puppet,
>Salt, libcloud, fog, jclouds, dasein, etc etc. Breaking that directly
>disrupts our users who stand a good chance of using one of those
>integrations or consume CloudStack via one of those tools.
>
>--David
Re: CloudStack.next
Posted by David Nalley <da...@gnsa.us>.
On Tue, Nov 12, 2013 at 6:41 PM, Steve Wilson <st...@citrix.com> 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?
>
Hi Steve,
I'll be contrarian ;) - I don't see 5.0 (e.g. API breaking changes)
coming in at least the next 12-18 months. Breaking API compatibility
is a BIG DEAL IMO and should be done very deliberately and with a lot
of consideration, and a plan around how we help folks adapt.
Think about the tons of integrations that we have now: Chef, Puppet,
Salt, libcloud, fog, jclouds, dasein, etc etc. Breaking that directly
disrupts our users who stand a good chance of using one of those
integrations or consume CloudStack via one of those tools.
--David
Re: CloudStack.next
Posted by Steve Wilson <st...@citrix.com>.
Hi Mike,
Really interesting stuff and very differentiaing!
-Steve
On 11/13/13 12:33 PM, "Mike Tutkowski" <mi...@solidfire.com>
wrote:
>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
><st...@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" <da...@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 <ts...@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.tutkowski@solidfire.com
>o: 303.746.7302
>Advancing the way the world uses the
>cloud<http://solidfire.com/solution/overview/?video=play>
>*™*
Re: CloudStack.next
Posted by Mike Tutkowski <mi...@solidfire.com>.
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 <st...@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" <da...@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 <ts...@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.tutkowski@solidfire.com
o: 303.746.7302
Advancing the way the world uses the
cloud<http://solidfire.com/solution/overview/?video=play>
*™*
Re: CloudStack.next
Posted by Steve Wilson <st...@citrix.com>.
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" <da...@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 <ts...@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
>>
Re: CloudStack.next
Posted by Daan Hoogland <da...@gmail.com>.
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 <ts...@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
>
Re: CloudStack.next
Posted by Prasanna Santhanam <ts...@apache.org>.
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
Re: CloudStack.next
Posted by Steve Wilson <st...@citrix.com>.
Lots of interesting ideas there. Thanks for sharing! BTW, I really share your interest in making CloudStack and Docker work really well together.
On Nov 17, 2013, at 9:57 AM, Rohit Yadav <bh...@apache.org> wrote:
> Hi,
>
> On Wed, Nov 13, 2013 at 5:11 AM, Steve Wilson <st...@citrix.com>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
>
>
> If we're not changing/breaking APIs and since we had adopted semantic
> versioning, we should not change the major version.
>
>
>> what would you like to see there? What would you change?
>
>
> Few things I'm personally looking forward to is to have CloudStack have
> better abilities and ease for controlling containers (lxc using docker or
> what have you) and a being able to act as a container coordinator between
> baremetal/virtual machines. I guess this is not a new request and we know
> ACS already supports LXC but I would like to use ACS as a tool that works
> for me to configure, deploy and manage containers using docker. In essence,
> we can have something like a recipe, a DSL or infra-management-as-code to
> automate infrastructure at a higher level just like we use Puppet or Chef,
> we could have something for our infrastructure that just works.
>
> What would you enhance?
>
>
> Probably next iteration of cloudmonkey and add tests (in my free time).
>
>
>> Are there big bets we should be placing as a community?
>>
>
> There is a lot of architectural debt that CloudStack is paying for, maybe
> we could introduce and implement cloud engine, new api services and the
> other next gen stuff that we had discussed in that past; I would like to
> contribute if that happens.
>
> The cluster management service and the way agents and ACS mgmt server
> communicate can be improved, things like Raft could be implemented as our
> consensus problem is not solved (in case of network/io issue, the agents
> and ACS mgmt server may have different view of the world, for example).
>
> The codebase is monstrous, we can maybe bet of splitting every part as a
> plugin and maybe move some code to other languages that are interoperable
> and run on JVM like Scala. One motivation for this is the fact that a lot
> of infrastructure code in the last one year has been written in Scala which
> works perfectly with existing Java based ecosystem. Since I've some
> experience of Scala and ACS's API layer, web services, plugin system, ACS's
> ORM and build system I can think refactoring and rewriting stuff in Scala
> would greatly reduce a lot of code while it would be still interoperable
> with the rest of the components.
>
> If you think about ACS from a top level bird's eye view, ACS is a big
> resource consuming poorly written web app that takes in some request, spits
> answers for read queries (sync commands) or enqueues in its job queue
> (async jobs) and stores information what it knows about (from MySQL) and/or
> cache (in/via DAOs). There are a lot of moving parts and SPOFs. If all
> these components could be a ran as a separate service which could run on
> different or same server, they could be cleanly separated and they can
> become more testable, easier to understand, enhance and develop.
>
> Just my views :)
>
> Regards.
>
>
>
>>
>> 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?
>>
>> -Steve
>>
>> Steve Wilson
>> VP, Cloud Engineering
>> Citrix
>> twitter: @virtualsteve
>>
Re: CloudStack.next
Posted by Rohit Yadav <bh...@apache.org>.
Hi,
On Wed, Nov 13, 2013 at 5:11 AM, Steve Wilson <st...@citrix.com>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
If we're not changing/breaking APIs and since we had adopted semantic
versioning, we should not change the major version.
> what would you like to see there? What would you change?
Few things I'm personally looking forward to is to have CloudStack have
better abilities and ease for controlling containers (lxc using docker or
what have you) and a being able to act as a container coordinator between
baremetal/virtual machines. I guess this is not a new request and we know
ACS already supports LXC but I would like to use ACS as a tool that works
for me to configure, deploy and manage containers using docker. In essence,
we can have something like a recipe, a DSL or infra-management-as-code to
automate infrastructure at a higher level just like we use Puppet or Chef,
we could have something for our infrastructure that just works.
What would you enhance?
Probably next iteration of cloudmonkey and add tests (in my free time).
> Are there big bets we should be placing as a community?
>
There is a lot of architectural debt that CloudStack is paying for, maybe
we could introduce and implement cloud engine, new api services and the
other next gen stuff that we had discussed in that past; I would like to
contribute if that happens.
The cluster management service and the way agents and ACS mgmt server
communicate can be improved, things like Raft could be implemented as our
consensus problem is not solved (in case of network/io issue, the agents
and ACS mgmt server may have different view of the world, for example).
The codebase is monstrous, we can maybe bet of splitting every part as a
plugin and maybe move some code to other languages that are interoperable
and run on JVM like Scala. One motivation for this is the fact that a lot
of infrastructure code in the last one year has been written in Scala which
works perfectly with existing Java based ecosystem. Since I've some
experience of Scala and ACS's API layer, web services, plugin system, ACS's
ORM and build system I can think refactoring and rewriting stuff in Scala
would greatly reduce a lot of code while it would be still interoperable
with the rest of the components.
If you think about ACS from a top level bird's eye view, ACS is a big
resource consuming poorly written web app that takes in some request, spits
answers for read queries (sync commands) or enqueues in its job queue
(async jobs) and stores information what it knows about (from MySQL) and/or
cache (in/via DAOs). There are a lot of moving parts and SPOFs. If all
these components could be a ran as a separate service which could run on
different or same server, they could be cleanly separated and they can
become more testable, easier to understand, enhance and develop.
Just my views :)
Regards.
>
> 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?
>
> -Steve
>
> Steve Wilson
> VP, Cloud Engineering
> Citrix
> twitter: @virtualsteve
>
Re: CloudStack.next
Posted by Andrei Mikhailovsky <an...@arhont.com>.
Steve,
I would like to see better error messages in the gui. Some errors that I get are absolutely meaningless and don't tell anything about what needs doing to overcome the errors. This is very important in my opinion. Errors like Could not start vm or router due to Null is just no go. I've also seen pointless errors while trying to delete resources like primary/secondary storage, network resources, etc. In my mind, a commercial product should have a meaningful error reporting and documented solutions on fixing these errors.
In terms of functionality, I would like to see better KVM support for things like change of service offering on live vm, ability to snapshot/restore the entire vm, not just volume by volume.
Also, ability to snapshot/import/export account settings, including networks, firewall rules, virtual machines, policies, etc.
Redundant Virtual routers checks also need to be improved to make sure you always have two virtual routers running, as at the moment, if one of the VRs crash or host server running a VR crashes ACS doesn't automatically restart it making sure that you always have two running VRs.
Cheers
Andrei
----- Original Message -----
From: "Steve Wilson" <st...@citrix.com>
To: dev@cloudstack.apache.org
Sent: Tuesday, 12 November, 2013 11:41:17 PM
Subject: CloudStack.next
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?
-Steve
Steve Wilson
VP, Cloud Engineering
Citrix
twitter: @virtualsteve