Skip to content
Snippets Groups Projects
  1. Mar 23, 2010
  2. Mar 08, 2010
  3. Jan 04, 2010
  4. Oct 09, 2009
    • Guido Trotter's avatar
      ChrootManager: clean StopInstance · a2771c83
      Guido Trotter authored
      
      Currently it has lots for duplicated code, and internal retries.
      Clean it up with the following assumptions:
      
      We'll probably be called more than once.
      It is ok to fail to stop, unless we're called with force=True.
      If we're called only once, and with force=True it's ok not to run the
      chroot "cleanup" script (it's a destroy after all, why should chroots
      have more chances than other instances?).
      
      Signed-off-by: default avatarGuido Trotter <ultrotter@google.com>
      Reviewed-by: default avatarOlivier Tharan <olive@google.com>
      a2771c83
    • Guido Trotter's avatar
      Hypervisors: Add retry= to StopInstance · 07b49e41
      Guido Trotter authored
      
      Currently some hypervisors need the stop operations to be retried more
      than once, while other ones only do it in one pass. With this change
      we'll handle retries outside the hypervisor code, but telling whether
      this is the first try or not.
      
      Since this option is not used for now, all hypervisors just return if
      called with retry set to on, maintaining the old behavior. Since the
      fake hypervisor has an idempotent StopInstance call, we avoid returning
      in that case.
      
      Signed-off-by: default avatarGuido Trotter <ultrotter@google.com>
      Reviewed-by: default avatarOlivier Tharan <olive@google.com>
      07b49e41
  5. Sep 03, 2009
  6. May 22, 2009
  7. May 12, 2009
    • Iustin Pop's avatar
      New hypervisor implementation: chroot manager · 48297fa2
      Iustin Pop authored
      
      This patch adds a new hypervisor implementation: a chroot manager. This
      hypervisor type can be used to manage (in combination with special OS
      definitions) the start and stop of chroot areas, and if used with drbd
      instances, it allows (via failover) the migration of chroots between
      nodes.
      
      This is a work in progress, and the way chroots should work is not very
      clear and does not fit very well in the OS definition framework.
      However, the hypervisor works and (if the sshd in the chroot is well
      configured) it allows login to the instance both via ssh and console as
      for a normal instance.
      
      TODOs:
        - implement instance IP add/remove to/from the bridge, if the instance
          has a defined IP
        - investigate improvements to the OS API so that the create script has
          more information available, e.g. about the hypervisor type
        - mount extra disks in the chroot or alternatively refuse to start
          with more than one disk
      
      Signed-off-by: default avatarIustin Pop <iustin@google.com>
      Reviewed-by: default avatarGuido Trotter <ultrotter@google.com>
      48297fa2
Loading