Last modified 7 years ago Last modified on 10/02/12 13:20:21

DevOps Weekly Meeting | October, 2 2012

Time & Location: 11am-12:30am in LHL164


2012-10-02 Agenda

  • Agenda bash
  • RCDay 2012 outcomes
  • NGS seminar
    • good presentations
  • Lustre status
    • recovery-based rebuild is progressing
      • object store has been indexed
      • metadata is being rebuilt
    • scatch policy is being made more explicit, eg. UABGRID_PROJECTS renamed to UABGRID_SHARED_SCRATCH
    • more aggressive expiration policy
      • scan for usage
      • expiration policy tuning
    • operational processes are being reviewed
  • Research storage
    • design
    • use cases
      • enable user to mount cloud storage or other fabrics to move off data results from scratch (eg. fusermount of S3)
      • enable user to mount disk images on compute nodes for more efficient performance of Lustre with small files (many small files in one big file image)
      • test drdb on virtual drives
  • Data analysis
    • matlab + sql exploration
      • added comments to ticket:211
      • look to add the mysql jar to the class path using pathtool from the matlab command line
      • possibly use errorbar plot or box plot to analyze queue wait times
  • Research projects updates
    • Galaxy
      • references to existing files will be broken because original lustre is offline
      • the importfs needs to be recreated
      • update users on the status of lustre rebuild
      • will base restart on expectations of lustre timeframe
  • Automation, Agile, Puppet, Dev Processes
    • working with apache module for puppet
    • two approaches: mod file directly or use module with interfaces that expose services
    • rspec is a behavior driven development testing approach: my class will look like X, will test if the output matches template
    • we could take a top-down view of our processes and implement modules that satisfy the abstractions of our requirements, not general purpose modules for all aspects of a target
    • some limitations of puppet are only the server knows state. it doesn't care about client state and will implement state based on the facts it knows about the client. this is a core approach of puppet. it doesn't negotiate changes between peers as bcfg2 might. but we are still in a single system space so we can be dictatorial in our changes to core system. as we grow on our process understanding we may look to tools like chef but at this stage we are still in need of puppets constraints.
    • we are in a good position and are learning what boundaries exist and how to work within them
    • one potential analogy for puppet is the svn v. git features. in svn there is one dominate workflow that can be supported whereas git has built-in features for multi-master replication
  • Env curation, research process, reliability, data security dialogs
    • didn't explicitly discuss, wrapped up in dev process and info security notes

Reference DevOps-2012-09-11 for background on the last time we had a general DevOps meeting