<commit_before>* CURRENT: QuickStart for Chef & OpenStack
** add chefignore for .gitignores
** rebase rcbops and compare
** osops-utils
** nova!
** librarian-chef for spiceweasel
** weekly status emails
** QuickStart
* backlog
** remotefilemirror->pxe_dust and others?
** checkout knife spaghetti-roles
** roles
*** base
    remove validator.pem?
    chef-client?
*** os-database
    document this
*** os-networks
    document this
*** rabbitmq-server
    http://tickets.opscode.com/browse/COOK-1496 drop the recipe[apt] once that's merged and released
    rename to "messaging" role
*** mysql-master
    need to switch to using a "database" role and the database cookbook
*** keystone
*** nova config/setup
*** nova::compute
*** nova::scheduler
*** nova::api
*** nova::network
*** nova::vncproxy
*** nova::volume
*** nova::project
*** horizon

** cookbooks
*** rabbitmq
    waiting on 1.5.1 with http://tickets.opscode.com/browse/COOK-1496
*** build-essential
    here for mysql
*** mysql
    since we're using the chef-full installer, we ran into the inability to use the mysql gem properly
    http://tickets.opscode.com/browse/COOK-1009
*** keystone
    removed monitoring
    understand use of osops
    why is there a sleep?
    tag and release 5.0.0
    gotta think Fog is a better solution to some of the Keystone manipulations
    need a keystone:client to wrap
    package "python-keystone" do
    action :install
    end
*** osops-utils
    should this be a data bag or partial search
    need to read through this thoroughly to understand purpose
    fix writing of etc/hosts to be idempotent
    remove database stuff, just use the database cookbook (extraneous abstaction)
*** glance
    make a glance::client for other cookbooks
*** nova
    rabbit setup seems naive
    Break out hypervisor support into separate cookbooks
    nova-common should pass hashes instead of so many attributes, that would make conditional rendering blocks simpler
    tag and release 5.0.0
*** horizon
    tag and release 5.0.0
*** swift
    compare with Dell's implementation
    make documentation more consistent with other cookbooks
    tag and release 5.0.0
** foodcritic all the cookbooks
   bring in Etsy's rules too?
** Document source of packages for all repos and break out to make them interchangeable
** Diagrams for Role/Cookbook relationships
   knife-spaghetti-roles
   Keystone
   Glance
   Nova
* Roadmap
** knife-rackspace v2, via fog or openstack
** knife-hp, via fog or openstack
** Testing, testing, testing
** Folsom milestones
** XenServer support
** LXC support
** Hyper-V support
** PostgreSQL support
** Fedora support
** RHEL support
** Debian support
** OpenSuSE/SLES support
** IPv6 support
* Open Questions
** Do we planning on sticking with distro-repos and for how long? When and how do we start supporting Folsom milestones or source builds?
   move packages into nova-install recipe, key off of attribute to determine which technique to use to get all binaries in place used by other nova-* recipes (nova as example), source can be a version of this
   keep a node['openstack']['version'] and node['openstack']['previous_version'] for upgrades, also node['nova']['version'] and node['nova']['previous_version'] for component-specific versioning
** Are we deprecating supporting anything before Ubuntu 12.04/Debian 6/RHEL 6.2/Fedora 17?
** Do we want to use Environments for anything?
** Should we add kong and exerstack to the repo so people can validate their deployments?
** How agressive should we be on not supporting earlier versions of Chef and Chef Solo?
** What features do we NOT plan on supporting?
** We're going to want some CI and more testing for sure. FoodCritic, Test-Kitchen and TravisCI?
** does search make sense for things like nova::common if you have 1000 compute nodes?
   would a data bag be cleaner? perhaps a notification handler that automatically updates it?
   as soon as the new search syntax is supported, switch to that (available now)
* Technical Debt
  Rackspace->Rackspace US, Inc.
  there are a lot of :upgrades for packages rather than :install, let's clean that up.
  osops-utils as a stand-alone cookbook just for managing networks with Chef? LWRPs driven by a cookbook?
  osops-utils is heavily dependent on searching by roles... should we use recipes instead?
* Weekly Status 8/10
** Goals for next week:
*** nova deployed and working
*** test using librarian-chef to manage mix of community and github-based cookbooks https://github.com/applicationsonline/librarian
*** push openstack cookbooks to community site and Opscode github repos
*** start on the Quick Start for Chef and OpenStack
** DreamHost Chef for OpenStack Hackday August 21 in Los Angeles
** visit Rackspace Wednesday
** cookbooks
*** mysql - fork updated, waiting on new release with 12.04 omnibus well-supported COOK-1384
*** osops-utils - merged upstream, a few minor patches ahead for debugging
*** sysctl - new dep, need to get upstreamed
*** apt - waiting on COOK-1530
*** rabbitmq - fix for COOK-1496<commit_msg>clean up after Rackspace discussion, more to come<commit_after>* CURRENT: QuickStart for Chef & OpenStack
** rebase rcbops and compare
** nova!
** librarian-chef for spiceweasel
** weekly status emails
** QuickStart
* backlog
** remotefilemirror->pxe_dust and others?
** roles/cookbooks
*** base
    remove validator.pem?
    chef-client?
*** os-database
    document this
*** os-networks
    document this
*** osops-utils
    waiting for partial search
    need to document this thoroughly to explain purpose
    fix writing of etc/hosts to be idempotent
*** rabbitmq-server
    rename to "messaging" role
    waiting on 1.5.2 with http://tickets.opscode.com/browse/COOK-1496
    is rabbit too brittle? Is Qpid a better longterm solution?
    rackspace is sending a rabbitmq::distro recipe
*** mysql-master
    need to switch to using a "database" role and the database cookbook
    mysql having issues with 12.04 and omnibus
    is the cookbook too brittle? rackspace proposes a simplified replacement
*** keystone
    removed monitoring
    understand use of osops
    why is there a sleep?
    tag and release 5.0.0
    gotta think Fog is a better solution to some of the Keystone manipulations
    need a keystone:client to wrap
    package "python-keystone" do
    action :install
    end
*** glance
    make a glance::client for other cookbooks
*** nova config/setup
    needs cleanup to be safe to run partial Nova deploys
    nova-common should pass hashes instead of so many attributes, that would make conditional rendering blocks simpler
*** nova::scheduler
*** nova::api
*** nova::network
*** nova::vncproxy
*** nova::volume
*** nova::project
*** nova::compute
    abstract out hypervisors and key off of attribute
*** horizon
    tag and release 5.0.0
*** swift
    compare with other implementations
    make documentation more consistent with other cookbooks
    tag and release 5.0.0
** foodcritic all the cookbooks
   sure would be nice if you could turn off individual rules within a recipe
** Document source of packages for all repos and break out to make them interchangeable
** Diagrams for Role/Cookbook relationships
   knife-spaghetti-roles
   Keystone
   Glance
   Nova
* Roadmap
** knife-rackspace v2, via fog or openstack
** knife-hp, via fog or openstack
** Testing, testing, testing
** Folsom milestones
** XenServer support
** LXC support
** Hyper-V support
** PostgreSQL support
** Fedora support
** RHEL support
** Debian support
** OpenSuSE/SLES support
** IPv6 support
* Open Questions
** Do we planning on sticking with distro-repos and for how long? When and how do we start supporting Folsom milestones or source builds?
   move packages into nova-install recipe, key off of attribute to determine which technique to use to get all binaries in place used by other nova-* recipes (nova as example), source can be a version of this
   keep a node['openstack']['version'] and node['openstack']['previous_version'] for upgrades, also node['nova']['version'] and node['nova']['previous_version'] for component-specific versioning
** Are we deprecating supporting anything before Ubuntu 12.04/Debian 6/RHEL 6.2/Fedora 17?
** Do we want to use Environments for anything?
** Should we add kong and exerstack to the repo so people can validate their deployments?
** How agressive should we be on not supporting earlier versions of Chef and Chef Solo?
** What features do we NOT plan on supporting?
** We're going to want some CI and more testing for sure. FoodCritic, Test-Kitchen and TravisCI?
** does search make sense for things like nova::common if you have 1000 compute nodes?
   would a data bag be cleaner? perhaps a notification handler that automatically updates it?
   as soon as the new search syntax is supported, switch to that (available now)
* Technical Debt
  Rackspace->Rackspace US, Inc.
  there are a lot of :upgrades for packages rather than :install, let's clean that up.
  osops-utils as a stand-alone cookbook just for managing networks with Chef? LWRPs driven by a cookbook?
  osops-utils is heavily dependent on searching by roles... should we use recipes instead?
* Weekly Status 8/10
** Goals for next week:
*** nova deployed and working
*** test using librarian-chef to manage mix of community and github-based cookbooks https://github.com/applicationsonline/librarian
*** push openstack cookbooks to community site and Opscode github repos
*** start on the Quick Start for Chef and OpenStack
** DreamHost Chef for OpenStack Hackday August 21 in Los Angeles
** visited Rackspace Wednesday
   Discussed the roadmap for the cookbooks and where we want to go with these. Folsom milestones will attempt to be kept in the same branch, RS would strongly prefer to stick with packages for installation and avoid working with trunk. This is of course, open for someone else to pursue if they can actively maintain it without breaking Essex. They should be providing a patch for a RabbitMQ recipe that does sticks with the distro version instead of rabbitmq.org's version (for consistency and security patches). The churn on the community MySQL cookbook has been disconcerting, we may explore a simplified MySQL cookbook if it continues to be an issue. We discussed osops-utils, it mostly needs more documentation but it's sticking around for now until time is invested to make better approaches to the problems it solves.
** cookbooks
   Tracked with Librarian now
*** mysql - fork updated, waiting on new release with 12.04 omnibus well-supported COOK-1384
*** osops-utils - merged upstream, a few minor patches ahead for debugging
*** sysctl - new dep, need to get upstreamed
*** apt - waiting on COOK-1530
*** rabbitmq - fix for COOK-1496
{'fraction_non_alphanumeric': 0.07146845337800112, 'fraction_numerical': 0.01107388795831007, 'mean_word_length': 4.161863592699327, 'pattern_counts': {'":': 0, '<': 3, '<?xml version=': 0, '>': 7, 'https://': 2, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '5535533', 'n_tokens_mistral': 3049, 'n_tokens_neox': 2824, 'n_words': 1416}