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@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
