openstack team mailing list archive

[Joe Breu <joseph.breu@xxxxxxxxxxxxx>]

Hi Jay,

The chef cookbooks at https://github.com/osops are no longer maintained.  Our current cookbooks are at  https://github.com/rcbops/chef-cookbooks



---
Joseph Breu
Deployment Engineer
Rackspace Cloud Builders
210-312-3508

On Jul 9, 2012, at 8:01 AM, Jay Pipes wrote:

Vish and Ron, just getting back to this... see inline continued
questions for you both.

On 07/02/2012 04:24 PM, Vishvananda Ishaya wrote:

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.

OK, I will work on splitting this out a bit more effectively.

One additional question, though. In opening up the
/cookbooks/nova/recipes/nova/compute.rb file, you will notice this at
the top:

include_recipe "nova::api"

Therefore, unless I am mistaken, the nova-compute *role*'s runlist
actually doesn't need to contain both nova-api AND nova-compute since
apparently the nova-compute *recipe* already includes all of the
nova-api recipe.

Would you agree with that?

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?

Ron, any disagreement here?

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.

Either of you, any thoughts on this front?

Thanks!
-jay

Thanks and all the best guys,
-jay

[1]
https://github.com/trystack/openstack-chef/tree/stable/diablo/cookbooks/heartbeat



_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to     : openstack@xxxxxxxxxxxxxxxxxxx<mailto:openstack@xxxxxxxxxxxxxxxxxxx>
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp