Open Stack

On Jul 2, 2012, at 7:28 AM, Jay Pipes wrote:

> Hi Ron, cc'ing the openstack ML for extra eyes and opinions...
> 
> So, Nati and I are looking to use either the osops chef-repo or
> something similar as the basis of the new TryStack zone chef deployment.
> I've been going through the recipes and roles and I have a question on
> the nova-compute *role*:
> 
> https://github.com/osops/chef-repo/blob/master/roles/nova-compute.rb
> 
> I'm wondering why the nova-api recipe is in the runlist for nova-compute?

Because metadata needs to run on the compute hosts in the default layout. This should
be switched to use nova-api-metadata instead of nova-api, but the split out hasn't been done yet.
> 
> In addition, I was wondering if y'all had considered making more use of
> roles instead of recipes to allow most of the attribute assignment and
> variation to be in the combination of roles assigned to a host, instead
> of recipes combined in a role?
> 
> For example, right now, there is a "nova-controller" role that looks
> like this:
> 
> name "nova-controller"
> description "Nova controller node (vncproxy + rabbit)"
> run_list(
>  "role[base]",
>  "recipe[nova::controller]"
> )
> 
> Because most of the special sauce is in the nova::controller recipe, I
> have to go into that recipe to see what the role is composed of:
> 
> include_recipe "mysql::server"
> include_recipe "openssh::default"
> 
> include_recipe "rabbitmq::default"
> include_recipe "keystone::server"
> include_recipe "glance::registry"
> include_recipe "glance::api"
> include_recipe "nova::nova-setup"
> include_recipe "nova::scheduler"
> include_recipe "nova::api"
> 
> if platform?(%w{fedora})
>  # Fedora skipping vncproxy for right now
> else
>  include_recipe "nova::vncproxy"
> end
> 
> But what this recipe really is is an opinionated description of a
> "controller role". If the role was, instead, structured like so:
> 
> name "nova-controller"
> description "Nova Controller - All major API services and control
> servers like MySQL and Rabbit"
> run_list(
>  "role[base]",
>  "recipe[mysql::server]",
>  "recipe[openssh::default]",
>  "recipe[rabbitmq::default]",
>  "recipe[keystone::server]",
>  "recipe[glance::api]",
>  "recipe[glance::registry]",
>  "recipe[nova::scheduler]",
>  "recipe[nova::api]",
> )
> 
> Then the deployer can more easily switch up the way they deploy
> OpenStack servers by merely changing the role -- say, removing the
> Rabbit service and putting it somewhere else -- WITHOUT having to modify
> a recipe in a Git submodule in the upstream cookbooks.
> 
> Furthermore, if we broke out more roles -- such as "control-services"
> which might be MySQL and Rabbit only -- than we could make the "super
> roles" ,like the nova-controller role above, more of a "put this and
> that role together, like so:
> 
> name "nova-controller"
> description "Nova Controller - All major API services and control
> servers like MySQL and Rabbit"
> run_list(
>  "role[base]",
>  "role[control_services]",
>  "recipe[keystone::server]",
>  "recipe[glance::api]",
>  "recipe[glance::registry]",
>  "recipe[nova::scheduler]",
>  "recipe[nova::api]",
> )

This all makes sense to me.  Ron?

> 
> Finally, I've noticed that there are aren't any HA options in the osops
> recipes -- specifically around MySQL. Are there plans to do so? We use
> heartbeat/Pacemaker/DRBD in the original TryStack cookbooks [1] and
> environments to get simple HA solutions up and would love to see those
> in the upstream.
> 
> Thanks and all the best guys,
> -jay
> 
> [1]
> https://github.com/trystack/openstack-chef/tree/stable/diablo/cookbooks/heartbeat