openstack team mailing list archive

[Judd Maltin <judd@xxxxxxxxxxxxxx>]

Hey andi,

I'm psyched to collaborate on this.  I'm a busy guy, but I'm dedicating Sunday to this. So if you have time Sunday, that would be best to catch up via IRC, IM or voice.

Having a node classifier of some sort is critical.

-Judd

Judd Maltin
+1 917 882 1270
Happiness is a straight line and a goal. -fn

On Apr 28, 2011, at 11:59, andi abes <andi.abes@xxxxxxxxx> wrote:

> Judd,
> 
>  Ok. Here are some of the thoughts I've had (and have  mostly working, but hitting some swift snags..) Maybe we can collaborate on this?
> 
> Since Chef promotes idempotent operations and cookbooks, I put some effort in making sure that changes are only made if they're required, particularly around destructive or expensive operations.
> The 2 main cases are:
> - partitioning disks, which is obviously destructive
> - building / rebuilding the ring files - rebalancing the ring is relatively expensive.
> 
> for both cases I've built a LWRP which reads the current state of affairs, and decides if and what are the required changes. For disks, I'm using '
> 'parted', which produces machine friendly output. For ring files I'm using the output from ring-builder.
> 
> the LWRP are driven by recipes which inspect databag - very similar to your approach. However, they also utilize inventory information about available resources created by crowbar in chef during the initial bring up of the deployment.
> 
> (As a side note - Dell has announced plans to opensource most of crowbar, but there's legalese involved)
> 
> 
> I'd be more than happy to elaborate and collaborate on this !
> 
> 
> a
> 
> 
> 
> 
> 
> 
> 
> 
> On Thu, Apr 28, 2011 at 11:35 AM, Judd Maltin <judd@xxxxxxxxxxxxxx> wrote:
> 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@xxxxxxxxx> 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@xxxxxxxxx> 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@xxxxxxxxxxxxxx> 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@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
> 
> 
> 
> 
> -- 
> Judd Maltin
> T: 917-882-1270
> F: 501-694-7809
> A loving heart is never wrong.
> 
> 
> 
>