513cebe7b7
* Add Virtual Kubelet provider for VIC Initial virtual kubelet provider for VMware VIC. This provider currently handles creating and starting of a pod VM via the VIC portlayer and persona server. Image store handling via the VIC persona server. This provider currently requires the feature/wolfpack branch of VIC. * Added pod stop and delete. Also added node capacity. Added the ability to stop and delete pod VMs via VIC. Also retrieve node capacity information from the VCH. * Cleanup and readme file Some file clean up and added a Readme.md markdown file for the VIC provider. * Cleaned up errors, added function comments, moved operation code 1. Cleaned up error handling. Set standard for creating errors. 2. Added method prototype comments for all interface functions. 3. Moved PodCreator, PodStarter, PodStopper, and PodDeleter to a new folder. * Add mocking code and unit tests for podcache, podcreator, and podstarter Used the unit test framework used in VIC to handle assertions in the provider's unit test. Mocking code generated using OSS project mockery, which is compatible with the testify assertion framework. * Vendored packages for the VIC provider Requires feature/wolfpack branch of VIC and a few specific commit sha of projects used within VIC. * Implementation of POD Stopper and Deleter unit tests (#4) * Updated files for initial PR
1.7 KiB
Application topologies
This describes the core application topologies that will be used to validate function and determine relative priority of feature implementation. This is by no means a complete list and the ordering may change over time as we gain additional feedback from users.
Prime topology - platform 2.5 tiered application
Description
This is the topology currently being used as the primary touchstone for feature support and priority. It's based off the docker voting app as a great example of a mapping from a traditional tiered application to a containerized environment. This is not assumed to be a pure twelve factor app because while that significantly simplifies the infrastructure requirements it's not a viable assumption for all workloads.
There are two scenarios described in the breakdown:
- unmodified voting app
- voting app using non-containerized database with direct exposure to an external network on the front-end
Application workflow has examples on building these applications. The voting app illustrates scenario 1, discussed above. In this example, the entire voting app and all tiers are created as a self-enclosed set of containers. Docker-compose is used to orchestrate the deployment.
The second scenario is assumed to be a better reflection of probable deployment scenarios as people are moving to containerized workloads, hence the description of this as a 2.5 platform application.
TODO: Add an example to the application workflow docs illustrating scenario 2.