Just a heads up, I'm working on building unified community-driven cookbooks over in https://github.com/opscode/openstack-chef-repo (and repos for the individual cookbooks). These are forked from Rackspace's cookbooks and I'm working with them and others to make reusable, well-documented and supported Chef cookbooks for OpenStack. I'll make a larger announcement around them once I have a working quickstart document for them.
tl;dr; https://github.com/opscode/openstack-chef-repo Thanks, Matt Ray Senior Technical Evangelist | Opscode Inc. [email protected] | (512) 731-2218 Twitter, IRC, GitHub: mattray On Tue, Jul 10, 2012 at 10:22 AM, Jay Pipes <[email protected]> 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! >>> -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 : [email protected] >>> <mailto:[email protected]> >>> Unsubscribe : https://launchpad.net/~openstack >>> More help : https://help.launchpad.net/ListHelp >> > > > _______________________________________________ > Mailing list: https://launchpad.net/~openstack > Post to : [email protected] > Unsubscribe : https://launchpad.net/~openstack > More help : https://help.launchpad.net/ListHelp _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : [email protected] Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
