Skip to content
This repository has been archived by the owner on Nov 9, 2020. It is now read-only.

Shared plugin: refactor kvstore and docker ops #1687

Merged
merged 1 commit into from
Aug 7, 2017

Conversation

luomiao
Copy link
Contributor

@luomiao luomiao commented Aug 3, 2017

  • Create a new kvStore interface, and have etcd as one of
    the implementations of the kvStore interface.
  • Move docker host related operations to dockerops package

local testbed e2e passed.

}

// VolumeCreate - create volume from docker host with specific volume driver
func (d *DockerOps) VolumeCreate(volumeDriver string, volName string, options map[string]string) error {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could name as just Create(), Mount()... like what we have for vmdkops. Since all these ops are on volumes may not need to call out Volume in each function.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1 on this

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't agree since we are not just having volume operations here.
Below we have the function to launch the file sharing servers, which is not volume operation.
And later we will add more function like the ones to get swarm information here too.

)

// DockerOps is the interface for docker host related operations
type DockerOps struct {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should this be VolumeOps and thats using docker on the backend to create and manage the volumes. Something like vmdkops that manages vmdks via ESX.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's not only for create and manage volumes... We have all the operations who will directly talk to docker host sitting in this struct. We will also need to do operations like launch services in this package too.

}

// StartSMBServer - Start SMB server
func (d *DockerOps) StartSMBServer(volName string) bool {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Won't these be a separate interface. Or at least should be named differently?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Inside this function, we will talk to docker host in order to start a swarm service. It will need the same information as other operations who need to talk to docker host. That's why I put it here. All the functions inside this structure is related to docker host.

ReadVolMetadata(keys []string) ([]KvPair, error)

// DeleteVolMetadata - Delete volume metadata in KV store
DeleteVolMetadata(name string) error
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These three could be like WriteMetaData, ReadMetaData, DeleteMetaData, List.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1 on this

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

will update.

@@ -94,27 +78,28 @@ const (

// VolumeMetadata - Contains metadata of shared volumes
type VolumeMetadata struct {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pls. add a description of the fields as done for the VolumeDriver struct. For example what is port here, is it the samba service port for this specific volume? How does a VM on a different ESX host access the same volume via the single samba instance. Is it via looking up the service name? How to figure which VM is running the samba service?

Copy link
Contributor Author

@luomiao luomiao Aug 3, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The description is already done above. :)

ServiceName string `json:"serviceName,omitempty"`
Username string `json:"username,omitempty"`
Password string `json:"password,omitempty"`
ClientList []string `json:"clientList,omitempty"`
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are these passwords in clear text? Also, is it possible for a user to gain access to the etcd and be able to retrieve this meta-data? This should be documented.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1 on this

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This information will be protected by etcd security in the future.

// WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
// See the License for the specific language governing permissions and
// limitations under the License.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please add comment about this file. What functionality will be provided by this file.

}

// VolumeCreate - create volume from docker host with specific volume driver
func (d *DockerOps) VolumeCreate(volumeDriver string, volName string, options map[string]string) error {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1 on this

@@ -12,7 +12,7 @@
// See the License for the specific language governing permissions and
// limitations under the License.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please add comments for this file.

// See the License for the specific language governing permissions and
// limitations under the License.

package kvstore
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please add comments for this file.

// VolStatus: Datatype for keeping status of a shared volume
type VolStatus string

/*
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Have we documented/added comments for the possible state transition? It would be very helpful for others to understand the code

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The state transition will be documented on the wiki page.

ReadVolMetadata(keys []string) ([]KvPair, error)

// DeleteVolMetadata - Delete volume metadata in KV store
DeleteVolMetadata(name string) error
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1 on this

ServiceName string `json:"serviceName,omitempty"`
Username string `json:"username,omitempty"`
Password string `json:"password,omitempty"`
ClientList []string `json:"clientList,omitempty"`
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1 on this

}

// if node is not in active swarm mode, return error
if info.Swarm.LocalNodeState != swarm.LocalNodeStateActive {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Have we explored other docker swarm states, like pending?
https://docs.docker.com/engine/swarm/admin_guide/#monitor-swarm-health

Thinking about the case where node reboots. Does swarm status become Active before plugin loads? (probably not relevant for tech preview)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's ok even we return error here when the swarm state is pending.
The plugin will try to restart again and it will come to here again and again until the state is active :)

// CompareAndPutStateOrBusywait - Compare the volume state with oldVal
// if equal, replace with newVal and return true; or else, return false;
// waits if volume is in a state from where it can reach the ready state
CompareAndPutStateOrBusywait(key string, oldVal string, newVal string) bool
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This function will only be used to compare-and-put volume state. Maybe we shouldn't take "key string" here as it only busywaits depending on volume state.

Lets take volume name as input here and turn it into key inside the function.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we pass in volume name instead of a key, this function is in fact "CompareAndPutVolStateOrBusywait".
But if you take a look at other KvStore interface methods, they are not "volume" operations. Instead, they are more generic "key-value" operations.
I know that inside the ETCD implementation we explicitly have all those volume state comparison. But still let's keep the methods at "key-value" level instead of "volume" level for consistency.

sambaImageName = "dperson/samba"
sambaUsername = "root"
sambaPassword = "badpass"
stateIdx = 0
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These are basically useless. The values are returned in the same order as the keys[] requested in ReadMetaData().

If the caller doesnt stick to stateIDX=0, gRefIdx=1... convention, these wont work.

Should we really introduce them to avoid writing 1-2 integers as array indices? (I know.. I introduced them)

Copy link
Contributor

@shivanshu21 shivanshu21 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Left few reviews.

Have we added a separate mount path for shared volumes?

Eg. /mnt/vmdk/vol1 -> /mnt/vshared/vol1?

@luomiao
Copy link
Contributor Author

luomiao commented Aug 4, 2017

@shivanshu21
Edit: this change will be done in another separate PR.

* Create a new kvStore interface, and have etcd as one of
the implementations of the kvStore interface.
* Move docker host related operations to dockerops package
@luomiao luomiao merged commit 5ee941f into vmware-archive:master Aug 7, 2017
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants