Skip to content

Refactor VirtualMachineManager #808

Description

@aionick

The reason this is an interface is so that we can have one official production implementation (which is VmFactoryImplementation - perhaps better naming is needed to get these more in sync) and still have the ability to create mock VirtualMachineManager instances for unit (and even integ) tests to contrive certain behaviours.

Currently VirtualMachineManager depends on VM, which is defined in its child. Actually VM should probably just be moved out of the child, since even mocked implementations will require this same VM behaviour.

There is a third class, VirtualMachineProvider, which acts as an arbitrary provider of VirtualMachineManager implementations. By default, the production VmFactoryImplementation is used, but there is an ability to set this manager so that tests can inject a mocked implementation into the BulkExecution via this path.

VirtualMachineProvider is what's used by the BulkExecutor to grab a virtual machine, and this is also the class that Aion uses at bootup to initialize and shutdown the virtual machines.

Aside from moving VM into its own class and some re-naming, we probably also want to ensure that this model makes sense.. there may be a much cleaner way of being able to inject mocked & production implementations into the bulk executor.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions