Notes for Sprint 2013.28-Block.4.2
==================================

Rob
---
Ben L.
-----
-20130708
    - CCI-1.2.0 deployed on Friday (7/5/2013) w/ CJones
    - Updating CLOAKN object to use gzip instead of csv object format (7/8/2013)

Chris B.
--------
-20130708
    - Replaced instances of the old resource map in the d1_cn_index_processor project with the new foresite backed resource map.
    - Working on writing a test for the integration using SolrFieldXPathEmlTest.java as a model. 
    - Working with David on documentation for ORC.

Skye
----
-20130708
    -Checking in initial versions of solr, jetty, solr/jetty bridge dpkg installers
        - Testing this week in dev
        - To support replication auditing reporting.
    -Testing some index and mercury updates
        -Fixed eml xslt issue in mercury
        -Updated index parsing for last name, last name case normalized.
            - Need to test in dev
            - Support for ONEDrive author sort.
    -Need to prepare index, mercury, cn_common for 1.2.1 release
        - including 1.2 branches for components

David
-----
        - New DataONE sysadmin to-dos/to-haves
        - ORC filesystem structure for host hardware
        - Structure and interconnections of host hardware at ORC
        - Procedures for common DataONE sysadmin tasks    (building/maintaining VMs on D1 ORC infrastructure, other best practices and procedures)
        - Training: Ansible, Vim, others

Robert
------
Roger
-----
Chris
-----
Dealing with G+ not connecting ! Ugh.

Dave V.
-------
20130715
20130712
20130710
20130708
1.2.1 Release Notes
--------------------

1) How to version/branch/tag ansible for Monday Rollout
    a) do we move ansible versions with the control properties
        i) add in the versions of the debian packages to the ansible yaml files before tagging. cci 1.2.1
    b) can we use our control properties for ansible configuration
        i) no, lets type them by hand for now... maybe look at a future task for automating updates of the ansible yaml files
        ii) we should add into the control properties file the ansible version
    
2) use of automated updates
    a) no automated update, but move to system where sys admins are informed of security updates to apply. 
    b)  pin slapd, tomcat, postgres, apache, java let the others float (Maybe openssl lib since we use certs everywhere in the infrastructure)

3) Version locking of packages
    a) /etc/apt/preferences use of Pin
    b) use of dpkg holds
    c) create a run upgrade-playbook that excludes dataone sensitive packages
        i) maintain a listing of all active debian package for an ubuntu release
        ii) no create of grand listing of all debian pacakges installed on a system, maybe we pin packages via /etc/apt/preferences.  have a general playbook that runs updates on non-pinned packages.
    
4) How do we structure environments and ansible host fil
    a) currently, each environment has a unique set of playbooks that may be run in coordination with a master host file. The dev and sandbox playbooks will be similar with the exception that the playbooks and modules are specific to the environment by a yaml 'hosts:' line. In the trunk, the hosts line will be the only distinguishing factor between these subdirectories.  In the branch, the staging and prod branches will be edited to reflect the specific version installed on each environment.   It may be simpler to generalize the hosts line to indicate a generic environment 'dataone' and maintain separate host files in svn that are then refered to on the commandline.  Another option maybe to maintain a single master host file, default the host line to the yaml file to 'all', and then restrict the environment to which the playbooks are applied via the commandline limit argument.
    
5) How to handle dist-upgrades
    a) issue by hand