1. 14 May, 2013 3 commits
  2. 13 May, 2013 2 commits
  3. 10 May, 2013 3 commits
  4. 09 May, 2013 5 commits
  5. 08 May, 2013 2 commits
    • Mike Hibler's avatar
      First round of client-side support for node-local storage "slices". · c1d21b9a
      Mike Hibler authored
      Supports the three coarse-grained placements we decided on:
      
        "SYSVOL" is special. You can declare a single blockstore with this
             placement and it will create a "native" (ufs/ext) filesystem on
             the 4th partition of the boot disk. This is how you create an
             extra storage partition that can be captured in a custom image.
             We don't use a volume manager here because imagezip doesn't
             recognize any of them (lvm, zfs, vinum).
      
        "ANY" coalesces all "available" storage from all disks into a logical
              volume manager pool and dishes out storage from that for
              individual blockstores. Typically this would include, the 4th
          partition of the boot disk (if not in use) and the second hard
          drive. If the machine has more than 2 drives, it will include
          all the extra drives.
      
        "NONSYSVOL" coalesces all "available" storage that is NOT on the
             boot disk into a logical volume manager pool and dishes out
             storage from that for individual blockstores. This case is if
             you want to avoid interfere with the system disk.
      
      Only implemented on FreeBSD 8/9 with "vinum" right now. It only creates
      "concat" (JBOD) volumes right now.
      
      This stuff will probably get split out into its own perl module(s) at
      some point, as it is getting large.
      
      Next up is LVM on Linux and then maybe ZFS on Freebsd.
      c1d21b9a
    • Kirk Webb's avatar
      Fix nested mountpoint comparison. · 98dda6ef
      Kirk Webb authored
      98dda6ef
  6. 07 May, 2013 1 commit
  7. 06 May, 2013 4 commits
  8. 03 May, 2013 6 commits
  9. 02 May, 2013 5 commits
  10. 01 May, 2013 2 commits
  11. 30 Apr, 2013 7 commits
    • Kirk Webb's avatar
    • Kirk Webb's avatar
      Add complete local node storage support from parser down to tcmd. · dab52801
      Kirk Webb authored
      Doing this required adding columns to the virt and physical blockstores
      tables to mark the attributes that will be considered for mapping.
      Unmarked entries just flow through to the client-side.
      
      This commit also introduces filesystem support in the form of passing
      through a mount point to the client-side.  It is left to the client to
      decide what filesystem and fs options to use to setup the space, including
      any logical volume aggregation required to support the request.
      dab52801
    • Kirk Webb's avatar
      Support multiple blockstores per local node. · d981ca72
      Kirk Webb authored
      d981ca72
    • Kirk Webb's avatar
      Parser hacks for blockstores · bb2563cf
      Kirk Webb authored
      * Translate bandwidth spec "~" to 10Kbps, and complain if any other value
        is used on a lan with blockstores.
      
      * Allow blockstores to be fixed to nodes.  Shunt through cases where the
        node a blockstore is fixed to isn't a blockstore pseudo-VM via a
        features / desires hack.  We do this to avoid having a more heavyweight
        blockstore pseudo-VM representation show up when users just want more
        local disk space setup on their nodes.
      bb2563cf
    • Kirk Webb's avatar
      Make storage lans use vlan encapsulation. · ffe332be
      Kirk Webb authored
      Also, blockstores VMs can't be the sync server...
      ffe332be
    • Mike Hibler's avatar
      Avoid redundent output in hwinfo command. · d468c60f
      Mike Hibler authored
      d468c60f
    • Mike Hibler's avatar
      Implement the "hwinfo" call. · 636e6436
      Mike Hibler authored
      This call returns info about the HW on the node (duh!) for the benefit
      of the upcoming "nodetest". It returns whatever info about the CPU, memory,
      disks and network interfaces is in the DB. The info comes from a variety of
      places:
        node_attributes, node_type_attributes, blockstores, blockstore_attributes,
        blockstore_type_attributes, and interfaces
      at last count.
      
      We will need to add some new node_type_attributes for cpu/memory.
      Even though some of the info exists already (e.g., "memory", "frequency"),
      I chose to use uniformly prefixed attributes (hw_cpu_*, hw_mem_*) to
      make my tmcd-life easier.
      636e6436