openstack team mailing list archive

[Jay Pipes <jaypipes@xxxxxxxxx>]

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
>