VMware vSphere Integrated Containers provider (#206)
* 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
This commit is contained in:
Loc Nguyen
52
vendor/github.com/vmware/vic/doc/processes/BRANCHING.md
generated
vendored
Normal file
52
vendor/github.com/vmware/vic/doc/processes/BRANCHING.md
generated
vendored
Normal file
@@ -0,0 +1,52 @@
|
||||
# VIC Branching
|
||||
|
||||
This document is used to define a strategy to enable development and testing of
|
||||
release candidate, patch found issues, while allowing development of future
|
||||
releases by way of branching and tagging.
|
||||
|
||||
## Requirements
|
||||
|
||||
_(Not in priority order)_
|
||||
* To insulate development of future releases from RC / GA testing and development.
|
||||
* Allow development of future releases.
|
||||
* Avoid breaking RC releases while in testing.
|
||||
|
||||
_Non requirements_
|
||||
* Define how to enable development of new features on MASTER or otherwise.
|
||||
* Define how to test RC / GA releases.
|
||||
* Define criteria for backporting or forward porting of found bugfixes, features, etc.
|
||||
* Define release trains for patching GA released builds.
|
||||
* Define release criteria for RC
|
||||
|
||||
## Proposal
|
||||
|
||||
We can keep changes isolated from RC / GA testing by way of `git` branches.
|
||||
|
||||
###Branching###
|
||||
* Use [master](http://github.com/vmware/vic) for future release work.
|
||||
* Use RC branch (`releases/MAJOR.MINOR.MACRO`) for RC release work.
|
||||
* `TAG` branch for each RC
|
||||
* `TAG` with `MACRO++` for each patch.
|
||||
|
||||
###Accounting###
|
||||
* Targeting
|
||||
* Bugs found in RC branch need an issue before merging fix to branch targeted to RC, e.g. `targeted/<RC branch name>`
|
||||
* Ideally patch should be merged to `MASTER` first if it exists there too.
|
||||
* Only if issue is targeted for RC, a different PR with the same issue number for the RC branch.
|
||||
* Only close issue after each relevant and targeted release has had a fixed merged to it. We can use targeting to verify this.
|
||||
* Bugs found in `MASTER` or any RC branch need to be tagged, e.g.`exists/<branches>`
|
||||
* The release branch will live as long as our support contract exists on that branch, once support sunsets we can remove the branch
|
||||
* The CI system will build all branches within the `releases/*` naming convention on push or tag event and publish the binary to our public binary location
|
||||
|
||||
```
|
||||
|
||||
MASTER -------------------------------------------------->
|
||||
\ \
|
||||
0.7---------------- \
|
||||
\ \ \
|
||||
TAG 0.7.1 TAG 0.7.2 \
|
||||
\
|
||||
0.8---->
|
||||
|
||||
|
||||
```
|
||||
65
vendor/github.com/vmware/vic/doc/processes/RELEASE-PROCESS.md
generated
vendored
Normal file
65
vendor/github.com/vmware/vic/doc/processes/RELEASE-PROCESS.md
generated
vendored
Normal file
@@ -0,0 +1,65 @@
|
||||
# VIC Engine Release Process
|
||||
|
||||
## Release cycle
|
||||
|
||||
VIC Engine is developed using a feature driven model. Requirements are broken
|
||||
down into features and then sized to ensure they will fit into our monthly
|
||||
releases. Any features that do not are then reworked until they will fit. Any
|
||||
features under active development that do not make the monthly release will be
|
||||
pushed into the next months version.
|
||||
|
||||
See [CONTRIBUTING.md](../../CONTRIBUTING.md#reporting-bugs-and-creating-issues)
|
||||
for details on how issues are prioritized and tracked.
|
||||
|
||||
## Release Versioning
|
||||
|
||||
The VIC Engine project follows Semantic Versioning 2.0.0. This is described in
|
||||
detail at http://semver.org/
|
||||
|
||||
## Example VIC Engine Versions Major revisions:
|
||||
|
||||
v1.0.0-beta1 v1.0.0-beta2 v1.0.0-beta v1.0.0 v2.0.0-alpha v2.0.0-beta
|
||||
v2.0.0
|
||||
|
||||
Minor revisions:
|
||||
|
||||
v1.1.0-beta v1.1.0 v2.2.0
|
||||
|
||||
Update or patch revisions:
|
||||
|
||||
v1.12.1 v1.12.20
|
||||
|
||||
## Release details
|
||||
|
||||
VIC Engine is released in both source and binary form. The source is tagged
|
||||
using github tagging methods. This is manual for now.
|
||||
|
||||
The binary releases are posted at https://console.cloud.google.com/storage/browser/vic-engine-releases/
|
||||
|
||||
### Update README.md and documentation
|
||||
|
||||
The main repo README contains a project status relating to the latest tagged
|
||||
release along with guidance on how to build, deploy, et al. The latter should
|
||||
be updated by any commits changing those workflows, but the status and what's
|
||||
new needs to be addressed as part of the release process.
|
||||
|
||||
* Create a PR, "Release x.y", with the corresponding doc updates once tagging
|
||||
is imminent merge that PR as the last thing that occurs prior to tagging tag
|
||||
the release as described in the next section.
|
||||
|
||||
###NOTE: Make sure that the last commit before tag does NOT have [skip ci] in the title
|
||||
|
||||
### Tag The Release
|
||||
|
||||
* Follow the above Release Versioning for choosing the new version. Gather the
|
||||
Release Notes file. Go to https://github.com/vmware/vic/releases and click
|
||||
on Draft a new release. Add the tag version that meets the requirements for
|
||||
this release.
|
||||
* Title the release "vSphere Integrated Containers Engine Version X.Y.Z" where
|
||||
X.Y.Z meets the versioning requirements.
|
||||
* Paste the release note file contents into the Write field and preview.
|
||||
* If this is release is non-production ready select the "This is a pre-release"
|
||||
box.
|
||||
* After a successful build on tag event, you can find the release here:
|
||||
https://console.cloud.google.com/storage/browser/vic-engine-releases/
|
||||
* Update the github releases page with the link to the final release tarball
|
||||
Reference in New Issue
Block a user