Open Stack

Hi Andi,

Indeed, the swift recipes hadn't been updated since mid 2010, so I pushed
forward with my own.

Thanks!
-judd

On Thu, Apr 28, 2011 at 10:03 AM, andi abes <andi.abes at gmail.com> wrote:

> Judd,
>
>  this is a great idea... actually so great, that some folks @Dell and
> OpsCode, me included, have been working on it.
>
> Have a peek on :
> https://github.com/opscode/openstack-cookbooks/tree/master/cookbooks
>
> This effort is also being included into Crowbar (take a peek here:
> http://robhirschfeld.com/tag/crowbar/) which adds the steps needed to
> start with bare metal (rather than installed OS), then using chef to get to
> a working Open stack deployment.
> (if you're at the design meeting, there are demos scheduled).
>
> That said - I'm updating the swift cookbook, and hope to update github
> soon.
>
> a.
>
>
>
>
>
> On Wed, Apr 27, 2011 at 9:55 PM, Jay Payne <letterj at gmail.com> wrote:
>
>> Judd,
>>
>> I'm not that familiar with Chef (I'll do some research) but I have a
>> couple of questions and some thoughts:
>>
>> 1.  Is this for a multi-server environment?
>> 2.  Are all your proxy nodes going to have "allow_account_management =
>> true" in the configs?   It might be a good idea to have a second proxy
>> config for account management only
>> 3.  Have you looked at using swauth instead of auth?
>> 4.  Have you thought about an admin or client node that has utilities
>> on it like st and stats-report?
>> 5.  How where will you do on-going ring management or changes?
>> 6.  I would think about including some type of functional test at the
>> end of the deployment process to verify everything was created
>> properly and that all nodes can communicate.
>>
>>
>>
>> --J
>>
>> On Wed, Apr 27, 2011 at 6:18 PM, Judd Maltin <judd at newgoliath.com> wrote:
>> > Hi Folks,
>> >
>> > I've been hacking away at creating an automated deployment system for
>> Swift
>> > using Chef.  I'd like to drop a design idea on you folks (most of which
>> I've
>> > already implemented) and get feedback from this esteemed group.
>> >
>> > My end goal is to have a "manifest" (apologies to Puppet) which will
>> define
>> > an entire swift cluster, deploy it automatically, and allow edits to the
>> > ingredients to manage the cluster.  In this case, a "manifest" is a
>> > combination of a chef databag describing the swift settings, and a
>> > spiceweasel infrastructure.yaml file describing the OS configuration.
>> >
>> > Ingredients:
>> > - swift cookbook with base, proxy and server recipes.  proxy nodes also
>> > (provisionally) contain auth services. storage nodes handle object,
>> > container and account services.
>> > -- Base recipe handles common package install, OS user creation.  Sets
>> up
>> > keys.
>> > -- Proxy recipe handles proxy nodes: network config, package install,
>> > memcache config, proxy and auth package config, user creation, ring
>> > management (including builder file backup), user management
>> > -- Storage recipe handles storage nodes: network config, storage device
>> > config, package install, ring management.
>> >
>> > - chef databag that describes a swift cluster (eg:
>> mycluster_databag.json)
>> > -- proxy config settings
>> > -- memcached settings
>> > -- settings for all rings and devices
>> > -- basic user settings
>> > -- account management
>> >
>> > - chef "spiceweasel" file that auto-vivifies the infrastructure: (eg:
>> > mycluster_infra.yaml)
>> > -- uploads cookbooks
>> > -- uploads roles
>> > -- uploads the cluster's databag
>> > -- kicks off node provisioning by requesting from infrastructure API
>> (ec2 or
>> > what have you) the following:
>> > --- chef roles applied (role[swift:proxy] or role[swift:storage])
>> > --- server flavor
>> > --- storage device configs
>> > --- hostname
>> > --- proxy and storage network details
>> >
>> > By calling this spiceweasel file, the infrastructure can leap into
>> > existence.
>> >
>> > I'm more or less done with all this stuff - and I'd really appreciate
>> > conceptual feedback before I take out all the non-sense code I have in
>> the
>> > files and publish.
>> >
>> > Many thanks!  Happy spring, northern hemispherians!
>> > -judd
>> >
>> > Judd Maltin
>> > T: 917-882-1270
>> > F: 501-694-7809
>> > A loving heart is never wrong.
>> >
>> >
>> >
>> >
>> > _______________________________________________
>> > 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
>> >
>> >
>>
>> _______________________________________________
>> 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
>>
>
>


-- 
Judd Maltin
T: 917-882-1270
F: 501-694-7809
A loving heart is never wrong.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20110428/a2c306d4/attachment.html>