Open Stack

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.
matt at opscode.com | (512) 731-2218
Twitter, IRC, GitHub: mattray


On Tue, Jul 10, 2012 at 10:22 AM, Jay Pipes <jaypipes at gmail.com> 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     : openstack at lists.launchpad.net
>>> <mailto:openstack at lists.launchpad.net>
>>> Unsubscribe : https://launchpad.net/~openstack
>>> More help   : https://help.launchpad.net/ListHelp
>>
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack at lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp