Files

Loc Nguyen 513cebe7b7 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

2018-06-04 15:41:32 -07:00

3.3 KiB

Raw Blame History

Style and conventions

One sentence per line

To keep consistency throughout the Markdown files in the Open Container spec all files should be formatted one sentence per line. This fixes two things: it makes diffing easier with git and it resolves fights about line wrapping length. For example, this paragraph will span three lines in the Markdown source.

Traditionally hex settings should use JSON integers, not JSON strings

For example, "classID": 1048577 instead of "classID": "0x100001". The config JSON isn't enough of a UI to be worth jumping through string <-> integer hoops to support an 0x… form (source).

Constant names should keep redundant prefixes

For example, CAP_KILL instead of KILL in linux.capabilities. The redundancy reduction from removing the namespacing prefix is not useful enough to be worth trimming the upstream identifier (source).

Optional settings should have pointer Go types

So we have a consistent way to identify unset values (source). The exceptions are entries where the Go default for the type is a no-op in the spec, in which case omitempty is sufficient and no pointer is needed (sources here, here, and here).

Examples

Anchoring

For any given section that provides a notable example, it is ideal to have it denoted with markdown headers. The level of header should be such that it is a subheader of the header it is an example of.

Example

## Some Topic

### Some Subheader

#### Further Subheader

##### Example

To use Further Subheader, ...

### Example

To use Some Topic, ...

Content

Where necessary, the values in the example can be empty or unset, but accommodate with comments regarding this intention.

Where feasible, the content and values used in an example should convey the fullest use of the data structures concerned. Most commonly onlookers will intend to copy-and-paste a "working example". If the intention of the example is to be a fully utilized example, rather than a copy-and-paste example, perhaps add a comment as such.

### Example

{
    "foo": null,
    "bar": ""
}

vs.

### Example

Following is a fully populated example (not necessarily for copy/paste use)

{
    "foo": [
        1,
        2,
        3
    ],
    "bar": "waffles",
    "bif": {
        "baz": "potatoes"
    }
}

3.3 KiB Raw Blame History