kubernetes-sigs/cluster-api-provider-vsphere

Operating system and Container cache should live on different VMDKs

Open

#894 opened on Apr 9, 2020

View on GitHub
 (10 comments) (4 reactions) (0 assignees)Go (320 forks)auto 404
help wantedkind/featurelifecycle/frozenpriority/important-soon

Repository metrics

Stars
 (417 stars)
PR merge metrics
 (PR metrics pending)

Description

/kind feature

Describe the solution you'd like I would like to see CAPV separate the operating system from the local container cache, this would be achieved by cloning the OS from a template, and then creating a new disk of the size specified with VSPHERE_DISK_GIB that would host the local image cache, enabling faster provisioning time and the ability to specify a disk size when using linked clones.

Anything else you would like to add: This could also help during upgrade, the new node could simply mount the existing local image cache and that would speed up significantly the restart of workloads after an upgrade.

/cc @randomvariable @yastij @rosskukulinski

Contributor guide

Research direction
Investigate CAPV codebase to understand current disk provisioning for VMs, specifically how the OS disk and container cache are handled. Look for opportunities to separate them by creating a new disk for container cache from the specified `VSPHERE DISK GIB`. Consider linked clone behavior and how to mount existing cache for upgrades.
Tech stack
go
Domain
infrastructure
Issue type
Feature
DifficultyEstimated implementation difficulty for a new contributor, from 1 for very small changes to 5 for expert-level work.
3
Estimated timeA rough time range for an experienced contributor to investigate, implement, test, and prepare a pull request.
1-2 days
Activity statusHow available the issue appears right now: fresh, active, stale, blocked, or waiting on maintainer input.
Active
ClarityHow clearly the issue explains the expected change, acceptance criteria, and next step.
Clear
Prerequisites
GoKubernetesvSphere
Newbie friendlinessA 1-100 score estimating how approachable this issue is for first-time contributors.
30