Open Stack

Last time I checked:

- CloudStack does not offer or have built in Object Store, you could of
course run your own Swift cluster but why bother.
- CloudStack offers a nice monolithic install from my experience where
OpenStack has many individual services. I have read horror stories about
both install procedures and failures to launch.
- Adoption and upgrades - Cloudstack seems behind, like it was abandoned
and OpenStack has the adoption of vendors and the community. I just checked
and wow, they did have a release in 2014, in a matter of fact two!!!

>From my point of view, CloudStack could have been amazing. It could have
been OpenStack but it seems like no one heard of it and it was not getting
regular updates until recently. Like the OpenStack bandwagon stirred the
pot and CloudStack figured "I guess we should provide an update I guess".

Personally I prefer Python over Java, so I am OpenStack bias. At least
Python code I can debug if needed to help figure out an issue.

Michael





On Mon, Dec 8, 2014 at 7:46 PM, Yitao Jiang <willierjyt at gmail.com> wrote:

> Article from shapeblue hopes can help you
>
>
> http://shapeblue.com/uncategorized/cloudstack-and-openstack-chalk-and-cheese/
>
>
> ---
> Thanks,
> Yitao(依涛 姜)
> jiangyt.github.io
>
> On Tue, Dec 9, 2014 at 5:52 AM, Jay Pipes <jaypipes at gmail.com> wrote:
>
>> Hi Jordi, thank you SO much for this email. It is excellent feedback for
>> our community and our developers. I've provided some comments inline, but
>> overall just wanted to thank you for bringing some of these product needs
>> to our attention.
>>
>> On 12/03/2014 01:42 PM, Jordi Moles Blanco wrote:
>>
>>> Hi everyone,
>>>
>>> I've been looking though the old messages in this list and I haven't
>>> found this kind of information (sorry if it is present somewhere and I
>>> couldn't find), so I decided to ask you because you are the experts on
>>> this.
>>>
>>> We want to build a new cloud platform and we have been playing with both
>>> options for a while.
>>>
>>> There are plenty of articles where people give their opinion about which
>>> stack technology is better, but they are more business-oriented than
>>> technically-oriented.
>>>
>>
>> Agreed. And, to be fair, we try not to promote the idea that there is
>> always a one-size-fits-all solution for everybody's needs.
>>
>> Both OpenStack and Cloudstack are solutions that work well for certain
>> customers -- anybody who says one is a good solution and the other isn't is
>> being dishonest or shallow.
>>
>>  I don't want to do that, I don't think there are good or bad players in
>>> this game, just different options that you have to know very well before
>>> you make your decision.
>>>
>>
>> ++
>>
>>  And that's why I'm asking you as Openstack experts. You see, I managed
>>> to deploy a Cloustack 4.4.1 platform with 2 compute nodes (for
>>> live-migration testing) in less than 2 hours, while it took me days to
>>> deploy an Openstack infrastructure that was functional and sometimes it
>>> just breaks and I have to reboot some nodes or redeploy with Fuel.
>>>
>>
>> This is an extremely common complaint about OpenStack. That it is just
>> too difficult to install and configure a simple OpenStack environment with
>> common compute, block storage, and networking functionality.
>>
>> I could sit here and say that this problem is due to the fact that
>> OpenStack's community has embraced each and every configuration management
>> system, deployment architecture, and package management platform and
>> therefore the complexity you find is simply due to the dizzying array of
>> options and flexibility offered by the ecosystem.
>>
>> But, of course, that would be a complete cop-out and terrible excuse. The
>> fact is, our installation and deployment story is currently overly
>> complicated, inconsistently documented, and difficult for newcomers to get
>> their heads around. That needs to be fixed.
>>
>>  I know, I'm just an inexperienced Openstack user, but that is one of my
>>> points: For any company that wants to go all the way to Openstack, it
>>> may inevitably face a big transformation and I don't think that everyone
>>> is ready for that. Sure, you do that because you want to change, you
>>> want to be able to provide infrastructure much faster, but there are
>>> other options that don't mean such a big change.
>>>
>>
>> Agreed.
>>
>> <snip>
>>
>>> What I do care about is having a platform that eases the process of vm
>>> provisioning and at the same time is easy to install, configure and
>>> maintain.
>>>
>>> Both platforms do that, but I feel that in order to do that, you need to
>>> have a group of highly trained people in Openstack whose only job is
>>> keeping the infrastructure running, while due to Cloudstack
>>> architecture, It doesn't seem like you need the same kind of expertise.
>>>
>>
>> Yes, completely agreed. It's something we need to do much better at.
>>
>>  If you don't want to dedicate resources, you can always pay for a
>>> managed Openstack solution, but then you are outsourcing your platform
>>> and, again, not everyone is ready for that, both for culture and pricing.
>>>
>>> I've also read several times that Openstack is a more mature project,
>>> with more features than other projects.
>>>
>>> Here are some thoughts:
>>>
>>> -As for vm provisioning, they both do that.
>>> -Cloudstack also has something similar to Ceilometer.
>>> -Cloudstack network management is also able to provide Network As a
>>> service: vpn, lb, etc.
>>> -Support for several commercial hypervisors on both.
>>> -Orchestration tools on top of the stack. It is true that Openstack
>>> comes with things like Heat, Juju or Openshift, but you can also use
>>> Juju with instances from Cloudtack and there are things like Cloudstack
>>> integration in Vagrant.
>>>
>>
>> To be clear, the only thing directly related to OpenStack is Heat.
>>
>> Juju is a tool from Canonical that can be used to install/deploy
>> applications in various VMs. OpenShift is a platform from Red Hat that
>> provides an application container system for developers to deploy their
>> applications into a cloud infrastructure.
>>
>> There is OpenStack "integration" with Vagrant via various things like
>> devstack-vagrant:
>>
>> https://github.com/openstack-dev/devstack-vagrant
>>
>>  -Both can integrate well with Amazon.
>>> -Things like deploying Hadoop with a click from Horizon is great, but it
>>> is virtualized and not suitable for all needs. Also, you can deploy
>>> Hadoop with Juju on Cloudstack vms.
>>>
>>> Obviously, I know pretty well what we will do with the Cloud
>>> infraestructure: vm provisioning that will allow us to sell services to
>>> end users. We won't sell vms to the end-user, only services: web, dns,
>>> mysql, etc. We will also probably go for containers, but you don't need
>>> Openstack for that, tools like Kubernetes let you play with Docker at
>>> scale in a very easy way.
>>>
>>
>> True enough. OpenStack Nova/Glance/Cinder/Ironic/Neutron is about the
>> infrastructure underneath those containers, though, not the containers
>> themselves. You still need a system to provision the bare metal and/or VM
>> resources in which the containers will be hosted.
>>
>>  So... given all that and the complexity of running Openstack, I just
>>> want to know, feature-wise, why you think Openstack is a better option.
>>>
>>> For example, I can think of scalability. Openstack has the storage
>>> system built-in with Swift and Ceph.
>>>
>>
>> Note that Ceph != OpenStack. Ceph is great, but it's entirely separate
>> from OpenStack. It's true that Glance, Cinder, and Nova contain various
>> drivers that support RBD/Ceph, but the Ceph project is not in OpenStack
>> itself.
>>
>>  Ceph is great and very scalable, while Cloudstack only asks you to add
>>> an external storage system (mainly NAS or SAN).
>>> So, in Cloudstack, you have to prepare and scale if necessary an
>>> independent storage system or create a new zone with a new pool.
>>> I wonder how much you can actually scale Ceph and if you don't have to
>>> make a new deployment of Openstack when you reach a certain number of
>>> Ceph nodes or computes nodes (specially because performance declines
>>> after a certain number of Ceph nodes).
>>>
>>
>> Not sure. I'll let the Ceph experts handle that question...
>>
>>  We are right now testing both projects and their features seem equally
>>> advanced for what we want to do (I would even say that Cloudstack has
>>> some cool features like the ability to limit how many IOPS an instance
>>> can use.
>>>
>>
>> Note that OpenStack also has the ability to limit IOPS that an instance
>> can use, however, like many things in OpenStack, this feature is not
>> particularly well documented and is awkward to configure:
>>
>> https://wiki.openstack.org/wiki/InstanceResourceQuota#IO_limits
>>
>>  Can you highlight some Openstack advantages that we may be missing in
>>> our tests?
>>>
>>
>> There are few technical differences between the features offered by
>> Cloudstack and OpenStack. OpenStack generally supports more driver options
>> and topology options than Cloudstack, with the cost of increased complexity.
>>
>> The primary differences between Cloudstack and OpenStack are the
>> non-technical differences that you said you were less interested in: the
>> size and breadth of the community providing support, the focus on GUI
>> configuration versus command-line + GUI interfaces, etc.
>>
>> All the best,
>> -jay
>>
>> _______________________________________________
>> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/
>> openstack
>> Post to     : openstack at lists.openstack.org
>> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/
>> openstack
>>
>
>
> _______________________________________________
> Mailing list:
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> Post to     : openstack at lists.openstack.org
> Unsubscribe :
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>
>


-- 

“The Man who says he can, and the man who says he can not.. Are both
correct”
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20141208/d79c467d/attachment.html>