Thread Previous • Date Previous • Date Next • Thread Next |
Working on that now, we just need to get our ducks in a row first :) -Carl On 07/10/2012 08:22 AM, Jay Pipes wrote:
Gah... probably would be good if you guys either shut down the repo or made a big notice on the README then :( -jay On 07/09/2012 05:25 PM, Joe Breu wrote: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! -jayThanks 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_______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@xxxxxxxxxxxxxxxxxxx Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Thread Previous • Date Previous • Date Next • Thread Next |