1. 20 Nov, 2012 4 commits
    • Apollon Oikonomopoulos's avatar
      Implement LUNetworkQuery · 306bed0e
      Apollon Oikonomopoulos authored
      
      
      Summarily list all existing networks
      Supply detailed info for every existing network
       - List used/free IPs
       - List instances with NICs assigned to the corresponding network
       - List NIC index and IP for the above instances
      
      Implement complementary config methods for retrieving networks.
      Signed-off-by: default avatarApollon Oikonomopoulos <apollon@noc.grnet.gr>
      Signed-off-by: default avatarDimitris Aragiorgis <dimara@grnet.gr>
      Reviewed-by: default avatarIustin Pop <iustin@google.com>
      306bed0e
    • Dimitris Aragiorgis's avatar
      Basic IP pool management logic · 6c0a75db
      Dimitris Aragiorgis authored
      
      
      Implement LUs for corresponding opcodes:
       * LUNetworkAdd:
         - Check for IP validity
         - Reserves all necessary IPs
         - Create new Network config object
       * LUNetworkRemove:
         - Checks if connected to any nodegroup
         - Remove a Network config object
      
      Implement basic config methods:
       * LookupNetwork()
         - Given the network name return the network UUID
       * AddNetwork()
         - Add a new network to the config
       * RemoveNetwork()
         - Remove a network from the config
      
      Add new locking level: LEVEL_NETWORK
      
      Add various useful config methods for retrieving network info.
      Signed-off-by: default avatarApollon Oikonomopoulos <apollon@noc.grnet.gr>
      Signed-off-by: default avatarDimitris Aragiorgis <dimara@grnet.gr>
      Reviewed-by: default avatarIustin Pop <iustin@google.com>
      6c0a75db
    • Dimitris Aragiorgis's avatar
      IP pool related objects, opcodes and constants · eaa4c57c
      Dimitris Aragiorgis authored
      
      
      Config objects:
       * Introduce L{Network} with
        - IPv4 network field (mandatory)
        - IPv4 gateway, IPv6 (network/gateway), mac prefix, type (optional)
       * Modify existing config objects to support networks:
        - Add new slot 'network' to L{NIC} config object
        - Add new slot 'networks' to L{NodeGroup} config object
      
      Opcodes:
       * Introduce new opcodes for networks
        - add/remove/modify/query/connect/disconnect.
       * In InstanceCreate/InstanceSetParams add conflicts_check option
      
      Constants:
       * INIC_PARAM 'INIC_NETWORK'
       * NIC_IP_POOL for automaticaly obtain an IP from a pool
       * NETWORK_TYPE_PUBLIC/PRIVATE for network types
      
      Checking of network_type handled by the opcode parameter validation.
      Introduce _CheckCIDR*Notation() functions for network parameters
      validation.
      Signed-off-by: default avatarApollon Oikonomopoulos <apollon@noc.grnet.gr>
      Signed-off-by: default avatarDimitris Aragiorgis <dimara@grnet.gr>
      Reviewed-by: default avatarIustin Pop <iustin@google.com>
      eaa4c57c
    • Iustin Pop's avatar
      Cleanup ht's use of positive/strictpositive · 2c9fa1ff
      Iustin Pop authored
      Currently, ht.py uses a bad terminology for positive/non-negative
      numbers. Per http://en.wikipedia.org/wiki/Positive_number
      
      , this is the
      correct terminology:
      
      - A number is positive if it is greater than zero.
      - A number is negative if it is less than zero.
      - A number is non-negative if it is greater than or equal to zero.
      - A number is non-positive if it is less than or equal to zero.
      
      So this patch renames things as follows:
      
      - TPositiveInt            ⇒ TNonNegativeInt
      - TStrictPositiveInt      ⇒ TPositiveInt
      - TMaybePositiveInt       ⇒ dropped, not used anywhere
      - TMaybeStrictPositiveInt ⇒ TMaybePositiveInt
      - TPositiveFloat          ⇒ TNonNegativeFloat
      - TStrictNegativeInt      ⇒ TNegativeInt
      Signed-off-by: default avatarIustin Pop <iustin@google.com>
      Reviewed-by: default avatarMichael Hanselmann <hansmi@google.com>
      2c9fa1ff
  2. 19 Nov, 2012 1 commit
  3. 12 Nov, 2012 1 commit
    • Iustin Pop's avatar
      Improve error message when migration status fail · 4041a4e3
      Iustin Pop authored
      Commit 6a1434d7
      
       (“Make migration RPC non-blocking”) changed the API
      for reporting migration status, but has a small cosmetic bug: if the
      migration status if failure, but the RPC itself to get the status
      didn't fail, it shows the following error message:
      
        Could not migrate instance instance2: None
      
      since it always uses result.fail_msg, irrespective of which part of
      the if condition failed.
      
      This patch simply updates the msg if not already set, leading to:
      
        Could not migrate instance instance2: hypervisor returned failure
      
      Proper error display can be done once the migration status objects can
      return failure information as well, beside status.
      Signed-off-by: default avatarIustin Pop <iustin@google.com>
      Reviewed-by: default avatarHelga Velroyen <helgav@google.com>
      4041a4e3
  4. 02 Nov, 2012 1 commit
  5. 01 Nov, 2012 1 commit
  6. 30 Oct, 2012 3 commits
  7. 26 Oct, 2012 1 commit
  8. 19 Oct, 2012 2 commits
    • Iustin Pop's avatar
      Update blockdev's "info" at instance rename · 48e175a2
      Iustin Pop authored
      
      
      Currently, we set "info" metadata on block devices at device creation
      time, but we never update it, leading to stale data in case of
      instance renames. This would not be a big problem in case of regular
      renames (assuming this is a rare operation), but importing instances
      into the cluster via the import/export feature usually is done with a
      rename; this means that all imported instances have wrong information
      in their block devices.
      Signed-off-by: default avatarIustin Pop <iustin@google.com>
      Reviewed-by: default avatarMichael Hanselmann <hansmi@google.com>
      48e175a2
    • Iustin Pop's avatar
      Fix disk adoption interaction with ipolicy checks · ba147ff8
      Iustin Pop authored
      
      
      In Ganeti 2.6, disk adoption is broken due to the ipolicy checks being
      done before we read volume size from remote nodes. We fix this by
      simply moving these checks to after the disk adoption code which
      updates the disk size; it's not that nice that we fail a (almost)
      config-level check after we've reserved the LVs, etc., but we need to
      do so in order to validate the ipolicy correctly.
      
      Tested:
      
      - normal instance creation
      - creation via adoption with good size (pass)
      - creation via adoption with wrong LV size (fail as expected)
      - QA in progress
      Signed-off-by: default avatarIustin Pop <iustin@google.com>
      Reviewed-by: default avatarMichael Hanselmann <hansmi@google.com>
      ba147ff8
  9. 17 Oct, 2012 1 commit
  10. 11 Oct, 2012 2 commits
  11. 05 Oct, 2012 4 commits
  12. 04 Oct, 2012 1 commit
  13. 03 Oct, 2012 4 commits
  14. 27 Sep, 2012 3 commits
  15. 24 Sep, 2012 2 commits
  16. 21 Sep, 2012 1 commit
  17. 18 Sep, 2012 1 commit
  18. 14 Sep, 2012 1 commit
  19. 13 Sep, 2012 1 commit
  20. 12 Sep, 2012 5 commits