openstack team mailing list archive
-
openstack team
-
Mailing list archive
-
Message #13978
[CHEF] Clarification on osops/chef-repo/roles/nova-compute.rb
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?
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]",
)
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
Follow ups