Open Stack

Hi everyone,

thanks for all your answers, I will answer all of you in a single message.

Clint, I agree. Actually, right now I'm able to deploy a HA openstack 
environtment with Ceph and other extra features like Zabbix with Fuel.
I took me a while to get used to it, but now I see it really does the 
job very well.

However... like I said... sometimes it just stops working and it seems 
that you need experts to maintain Openstack.

What about Cloudstack? mmm.... not much so. At the end of the day... you 
have a bunch of nodes like in the "old days" that are connected to each 
other in the classical way: different roles (compute, storage, etc) and 
different NICs to separate the traffic. You connect them however you 
want and then you install a cloudstack agent that receives orders from 
the servers. Let's say that it is like orchestrating your typical 
virtualization platform with Chef. The difference is that in Chef you 
have to do everything on your own (write your own recipes I mean) and 
with Cloudstack you are given all the "recipes" and you don't have to do 
anything.

Michael, Cloudstack does not offer an Object Store, but it can use Swift 
or even Amazon S3, or a plain NFS server. Correct me if I'm wrong, but 
do we actually need a high performing Object store? In both Openstack 
and Cloudtack, the secondary storage is only used to store templates, 
images and so on, not to run instances on them. So... unless I'm missing 
something here, a bare NFS server can be enough to store the images.

As for the horror stories, you might be right, but I can tell you that 
I've managed to install different versions from Cloudstack 4.x without 
any problem, while I wasn't able to install Openstack Icehouse or Juno 
with any tool (not even the cloud-install script that different vendors 
are supplying or scripts done by the community) until I found Mirantis' 
Fuel).
May be in Cloudstack 3.x or earlier that was the case, but I can't say.

As for the upgrades... constant upgrades don't guarantee stability (and 
I could long talk about cases where this is very true). Falling behind? 
Again... feature-wise, I can see that both do the same things. Even 
Cloudstack has some cool features available from the GUI that Openstack 
doesn't seem to have or that are not easy or straightforward to 
implement (like the IOPS limitation).

Yitao, thanks for the link, I hadn't seen it and it is very recent and 
interesting.

Mark, I've read the document you sent (and other similar ones) about 
scaling Ceph. One system that was designed from scratch to be 
scalable... I mean, it has to be, It wouldn't make sense otherwise. But 
other distributed storage systems that I've tried (and storage is my 
thing) are scalable without limit (if you look at the algorithm) but 
they start to suffer from serious performance issues when they reach a 
certain number of nodes. You start facing different bottlenecks like the 
devices not being able to provide more IOPS or two many interruptions in 
the NIC because of workload from visitors and also replication of data 
between nodes.
The only thing you can do if you want to scale without limit of storage 
nodes is going somewhere >10Gb/s (note that I'm saying only greater 
than) and using flash storage arrays. Obviously then you have the issue 
with price and the durability of the array, but performance-wise is 
really limitless.

But as Jay pointed out, Ceph != Openstack, so let's not waste too much 
energy on this as I'm more concerned about technical functionalities.

thanks.



On 09/12/14 06:46, Clint Byrum wrote:
> Excerpts from Jay Pipes's message of 2014-12-08 13:52:38 -0800:
>> 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:
>>> 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.
>>
> We've at least decided, in spirit, to provide a single mission for
> automated Deployment using OpenStack itself. HP is even shipping a
> product, Helion, that uses it.
>
> Turns out this isn't the easiest thing in the world. OpenStack is a
> service oriented architecture, and making a _generic_ deployment tool,
> even just focusing on the default configurations, is a challenge with
> such a flexible architecture.
>
> Keep your eyes on the Tuskar space. It is intended to be a nice GUI for
> planning and deploying OpenStack. That, combined with a more generally
> consumable Deployment program, should have us in much better shape soon.
>
> _______________________________________________
> 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
>