Issue 1:
Is this a request for help? (If yes, you should use our troubleshooting guide and community support channels, see http://kubernetes.io/docs/troubleshooting/.):

Yes

What keywords did you search in Kubernetes issues before filing this one? (If you have found any duplicates, you should instead reply there.):

glusterfs

volume

provisioning

Is this a BUG REPORT or FEATURE REQUEST? (choose one):

BUG REPORT

Kubernetes version (use kubectl version):

Client Version: version.Info{Major:"1", Minor:"4", GitVersion:"v1.4.3", GitCommit:"4957b090e9a4f6a68b4a40375408fdc74a212260", GitTreeState:"clean", BuildDate:"2016-10-16T06:36:33Z", GoVersion:"go1.7.1", Compiler:"gc", Platform:"darwin/amd64"}
Server Version: version.Info{Major:"1", Minor:"4", GitVersion:"v1.4.1", GitCommit:"33cf7b9acbb2cb7c9c72a10d6636321fb180b159", GitTreeState:"clean", BuildDate:"2016-10-10T18:13:36Z", GoVersion:"go1.6.3", Compiler:"gc", Platform:"linux/amd64"}

Environment:

Cloud provider or hardware configuration: On-prem VSphere

OS (e.g. from /etc/os-release): Ubuntu 16.04 LTS

Kernel (e.g. uname -a):

Install tools: Kubeadm

Others:

Heketi

GlusterFS

What happened:

When provisioning a GlusterFS volume via PVC, GlusterFS volume is created but with a durability_type of "None" instead of "replicate" according to:

kubernetes/pkg/volume/glusterfs/glusterfs.go

Line 60
in
4e393fa

durabilitytype = "replicate"

When doing a heketi volume info on the created PV, this is the result:

[root@415dd3a6d47d /]# heketi-cli volume info 2f85f8c8c7eabf2daf3b50065bf3160d
Name: vol_2f85f8c8c7eabf2daf3b50065bf3160d
Size: 5
Volume Id: 2f85f8c8c7eabf2daf3b50065bf3160d
Cluster Id: 0ea05409eedd61cf1678d2e8693bdae8
Mount: 10.130.7.153:vol_2f85f8c8c7eabf2daf3b50065bf3160d
Mount Options: backup-volfile-servers=
Durability Type: none

What you expected to happen:

Durability Type should be replicate.

How to reproduce it (as minimally and precisely as possible):

Create a default storageclass for glusterfs that points to heketi's REST server

In your PVC, use glusterfs StorageClass

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: glusterclaim-1
annotations:
volume.beta.kubernetes.io/storage-class: "glusterfs"
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: "5Gi"

After doing a kubectl get pv, notice that the PV is created and bounded to the claim

Connect to the heketi server and do a heketi volume list and do a heketi volume info on the newly created volume.

You should notice that the volume is created with a Durability Type of 'none'

Anything else do we need to know:

Issue 2:
Broken out from #1007, which was unwieldy.

A configuration system needs to be able to diff a new desired state generated from the configuration with the current desired state registered with the system, in a generic, extensible manner, in order to determine which objects require updates (as well as potentially what kinds of updates). In order to do this, it needs uniform structure across all API objects, clean separation of input and output values, and clean differentiation of user-provided values and automatically determined values, including default values.

Currently, our API objects contain:

(all, even lists which is questionable) JSONBase, which includes Kind, ID, CreationTimestamp, SelfLink, ResourceVersion, and APIVersion

(Pod, ReplicationController, Service) Labels

(Pod, ReplicationController) DesiredState

(Pod only) CurrentState

In JSONBase, only ID is explicitly provided by the client and only ResourceVersion is mutable.

In Pod, DesiredState and CurrentState use the same schema, mixing input and output fields (Manifest, RestartPolicy, Host, HostIP, PodIP, Info).

Service lacks DesiredState and CurrentState.

ReplicationController lacks CurrentState (though that may change with #736).

Proposals:

Nest JSONBase in a named field, such as Metadata, to more coarsely bucket them within the objects.

Move Labels to JSONBase, so that they're in the same position in every object, together with other generic object metadata. Split Labels into FinalLabels and DynamicLabels. FinalLabels could only be specified at creation time, and would not be mutable. DynamicLabels would be applied at run time and would be ignored in the reconciliation diff. If people thought it would be useful, we could introduce a convenience field (e.g., Labels) that presented a merged view. An alternative would be to represent finality as a bit on each label.

Duplicate DesiredState into PrimaryDesiredState, FallbackDesiredState, and DesiredState, and add these to every object. PrimaryDesiredState would be the state set from configuration, and would be the only part of the objects diff'ed by the configuration reconciliation process. FallbackDesiredState would be set by automated processes, such as default values provided by configuration and deployment tools, default values initialized by apiserver itself, values filled in by other automation systems such as auto-scalers (e.g., the replicas field in replicationController), and so on. The PrimaryDesiredState values would always override the FallbackDesiredState values (called shadow values in #1007). DesiredState would present a merged view for components that needed to act upon the full DesiredState. Again, an alternative would be to keep track of whether values should be diff'ed with a bit on each field. That has at least one disadvantage, in that automatically initialized values would be lost in the case that they were overwritten by configuration that was then later reverted. However, it may be simpler for components that don't care about the distinction and may be more space efficient, depending on our internal representation.

Add CurrentState to all objects that are lacking it.

Use different representations for desired and current state in Pod, appropriately divide the fields between them, and merge ContainerManifest into the new PodDesiredState type.