From a6bc8908999d99a09682e59ca4f84945c16f6656 Mon Sep 17 00:00:00 2001
From: SataQiu <1527062125@qq.com>
Date: Fri, 5 Oct 2018 16:24:45 +0800
Subject: [PATCH] fix typo (#10413)

---
 .../blog/_posts/2018-07-27-kubevirt-crds-for-virtualization.md  | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/content/en/blog/_posts/2018-07-27-kubevirt-crds-for-virtualization.md b/content/en/blog/_posts/2018-07-27-kubevirt-crds-for-virtualization.md
index 96eb8f5af5..b6ea48288c 100644
--- a/content/en/blog/_posts/2018-07-27-kubevirt-crds-for-virtualization.md
+++ b/content/en/blog/_posts/2018-07-27-kubevirt-crds-for-virtualization.md
@@ -99,7 +99,7 @@ A [CRD finalizer](https://kubernetes.io/docs/tasks/access-kubernetes-API/extend-
 
 The Kubernetes core APIs have the ability to support multiple versions for a single object type and perform conversions between those versions. This gives the Kubernetes core APIs a path for advancing the `v1alpha1` version of an object to a `v1beta1` version and so forth.
 
-Prior to Kubernetes 1.11, CRDs did not not have support for multiple versions. This meant when we wanted to progress a CRD from `kubevirt.io/v1alpha1` to `kubevirt.io/v1beta1`, the only path available to was to backup our CRD objects, delete the registered CRD from Kubernetes, register a new CRD with the updated version, convert the backed up CRD objects to the new version, and finally post the migrated CRD objects back to the cluster.
+Prior to Kubernetes 1.11, CRDs did not have support for multiple versions. This meant when we wanted to progress a CRD from `kubevirt.io/v1alpha1` to `kubevirt.io/v1beta1`, the only path available to was to backup our CRD objects, delete the registered CRD from Kubernetes, register a new CRD with the updated version, convert the backed up CRD objects to the new version, and finally post the migrated CRD objects back to the cluster.
 
 That strategy was not exactly a viable option for us.