Merge pull request #19 from kthcloud/harsha

Fixed title and grammar

hugo/content/News/2024-04-29.md

@@ -2,31 +2,31 @@
 title: From CloudStack to KubeVirt, the Journey to a New Cloud.
 ---
 
-# From CloudStack to KubeVirt: The Journey to a New Cloud
+# Hej KubeVirt
 
 __Harsha Krishna, 2024-04-29__
 
 Earlier this month we [announced](https://docs.cloud.cbh.kth.se/News/2024-04-14/) that we are moving to KubeVirt. We had detailed how the new system would work.
 
-Thanks to the efforts of Emil and Pierre, the move to KubeVirt is almost complete. We are in the process of moving some apps which were running using the old virtual machine system to the new version which uses Kubernetes.
+Thanks to the efforts of Emil and Pierre, the move to KubeVirt is almost complete. We are in the process of moving the final apps which are running using the old virtual machine system to the new version.
 
 ## Goodbye to CloudStack
 
-While the cluster was setup with few users in the beginning, we were using [Apache CloudStack](https://cloudstack.apache.org), to orchestrate both Kubernetes clusters as well as independent virtual machines and to administrate them. We used this design as we needed a way to administer the distribution of graphic cards, which used to be bound to a given virtual machine. Normal apps proceeded to use a Kubernetes cluster.
+The first cluster was setup with few users. We were using [Apache CloudStack](https://cloudstack.apache.org), to orchestrate both Kubernetes clusters as well as independent virtual machines and to administer them. We used this design as we needed a way to administer the distribution of graphic cards, which were bound to a given virtual machine.
 
-While the purpose for a while, the number of users in the cloud increased and the demand for the least avaliable source, the GPU also increased. We needed a better way to distribute them.
+While this worked for a while, the increase in number of users in the cloud and the demand for the least available resource, the GPU, also increased. We needed a better way to distribute them.
 
-While CloudStack is good for a very large planned cluster, it required significant amount of effort to maintain. CloudStack has limited community and is still lacks some of the feature for a cluster like ours, which is based on donated hardware (We don't always now what we get :smiley face: ) . It uses an extensive combination of virtual networks and its own virtual machines in order to orchestrate various clusters and VMs in the cluster. Things really came to head when we had the incident in March which required a immediate shutdown following a failed upgrade. At this time the entire cluster became unstable.
+While CloudStack is good for a very large data-centers type setup, it requires significant effort to maintain. CloudStack has limited community and still lacks some of the features for our requirements, which is based on donated hardware (We don't always know what we get :smiley face: ). It uses an extensive combination of virtual networks and system virtual machines in order to orchestrate various clusters and VMs across different centers. Things really came to head when we had the [incident in March](https://docs.cloud.cbh.kth.se/News/2024-03-22/) which required an immediate shutdown following a failed upgrade. At this time the entire cluster became unstable.
 
 ## Hello KubeVirt
 
-Fortunately, Emil was testing a new method to create VMs within a Kubernetes cluster. This allowed us to run the entire infrastructure as pure Kubernetes system. It also has the added advantage of running different loads as scheduled nodes with or without GPUs. This allows for quicker rotation of GPUs and possibly fairer sharing.
+Fortunately, Emil was testing a new method to create VMs within a Kubernetes cluster. This allowed us to run the entire infrastructure as pure Kubernetes system. It also has the added advantage of running different loads as scheduled jobs with or without GPUs. This allows for quicker rotation of GPUs and possibly fairer sharing.
 
 The new system will use [Rancher](https://www.rancher.com) to manage individual Kubernetes clusters. As users you will notice some minor changes to the UI when you log into your cloud console. However, thanks to Pierre and Emil, a lot of the complexity is now under the hood.
 
 ## What to expect and timeline
 
-The upgrade to the servers are almost complete. Soon we will retire the CloudStack instance. We thank users for their patience. We will announce the rollout in 2 weeks time for the new system.
+The upgrade to the servers are almost complete. Soon we will retire the CloudStack instance. We thank users for their patience. Any new system being deployed will already use the new system. We will complete and finalise the rollout in 2 weeks.
 
 __NOTE:__ that older VMs created in CloudStack will be deleted. If your VM is running and you need to make backups of your data or configurations, we request you to do so within this week. There will be no effect on your Kubernetes instances.