Open Stack

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
>