Open Stack

Erik,  

Most of these issues have corresponding blueprints/bugs filed in Launchpad:

1. https://bugs.launchpad.net/savanna/+bug/1204943
2. https://blueprints.launchpad.net/savanna/+spec/modifying-cluster-template
    https://blueprints.launchpad.net/savanna/+spec/modifying-node-group-template
3. https://bugs.launchpad.net/savanna/+bug/1174612
4. https://bugs.launchpad.net/savanna/+bug/1183387


I agree that these are really usability issues and need to be resolved eventually.

Issue #4 is the most complicated. As a first step we need to implement common code which would gather detailed cluster status with info about each node. Once it's done we'll be able to apply policies you're suggesting.


Ruslan  


On Monday, September 16, 2013 at 8:43 PM, Erik Bergenholtz wrote:

> I want to start a dialog around adding some usability features to Savanna, now that I have had a chance to spend a fair amount of time provisioning, scaling and changing clusters. Here is a list of items that I believe are important to address; comments welcomed:  
> 1. Changing an OpenStack flavor associated with a node-group template has a ripple effect on both node group and cluster templates. The reason for this is that OpenStack does not support modification of flavors; when a flavor is modified (RAM, CPU, Root Disk, etc.) the flavor is deleted and a new one is created resulting in a new flavor id. The implication is that both node-group referencing the flavor [id] and any cluster templates referencing the affected node-group become stale and unusable. A user then has to start from scratch, creating new node-groups and cluster templates for a simple flavor change.
> a. A possible solution to this is to internally associate flavor name with node-group and look up the flavor id based on flavor name when provisioning instances
> b. At a minimum it should be possible to change the flavor id associated with a node-group. See #2.
>  
> 2. Cluster templates and node group templates are immutable. This is more of an issue at the node-group level as I often times want to make changes to a node-group and want to affect all cluster templates that make use of that node-group. I see this as being fairly commonplace.
>  
> 3. Before provisioning a cluster, quotas should be checked to make sure that enough quota exists. I know this can be done transactionally (check quota, spawn cluster), but a basic check would go a long way.
>  
> 4. Spawning a large cluster comes with some problems today, as Savanna will abort if a single VM fails. In deploying large clusters (100’s to x1000), which will be commonplace, having a single slave VM (i.e. data node) not spawn properly should not necessarily be a reason to abort the entire deployment, in particular in a scaling operation. Obviously the failing VM cannot be a master service. This applies both to the plugin as well as controller as they are both involved in the deployment. I could see a possible solution being the creation of an error/fault policy allowing a user to specify (perhaps optionally) a % or hard number for minimum # of nodes that need to come up without aborting deployment.
> a. This also applies to scaling the cluster by larger increments
>  
> Just some thoughts based on my experience last week; comments welcomed.
>  
> Best,
>  
> Erik
>  
>  
> CONFIDENTIALITY NOTICE
> NOTICE: This message is intended for the use of the individual or entity to which it is addressed and may contain information that is confidential, privileged and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient, you are hereby notified that any printing, copying, dissemination, distribution, disclosure or forwarding of this communication is strictly prohibited. If you have received this communication in error, please contact the sender immediately and delete it from your system. Thank You.
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org (mailto:OpenStack-dev at lists.openstack.org)
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev