# cpouta Published articles for cpouta. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## cPouta Cloud Object Storage Service has been updated to run CEPH Luminous! DevFeed: [cPouta Cloud Object Storage Service has been updated to run CEPH Luminous!]() Original publisher: [Read original article]() Author: Unknown (noreply@blogger.com) Published: 2019-02-06T10:03:00Z Content type: release Language: en Sources: [CSC - IT Center For Science - Cloud Team]() Topics: [ceph](), [Amazon S3](), [Cloud](), [configuration](), [Command-line interface]() Tags: [amazon-s3](), [api](), [automatic](), [ceph](), [cli](), [configuration](), [cpouta](), [format](), [object-storage](), [openstack](), [radosgw](), [s3](), [storage](), [upgrade](), [xml]() ### AI overview The CSC Pouta Cloud Team describes an upgrade of its Ceph Object Storage Gateway from Jewel to Luminous. The update enables AWS4 signatures by default and adds support for several S3 features, including bucket lifecycle, website hosting, and request payment. The article also begins an example of configuring an S3 lifecycle policy with s3cmd and XML. ### Source excerpt We (the CSC Pouta Cloud Team) has finally upgraded CEPH Object Storage Gateway from Jewel to Luminous! There may come more blog posts about other improvements to other of our Openstack services (cinder and glance) which use CEPH. No need to use s3 --signature-v2 anymore! Before this upgrade, anyone using the S3 protocol needed to use the "AWS2" for most actions to work. Now that we run Luminous it is no longer necessary and the default AWS4 signature is working. Yay! In general things should be faster, shinier and also more API calls are supported. Comparing http://docs.ceph.com/docs/luminous/radosgw/s3/ and http://docs.ceph.com/docs/jewel/radosgw/s3/ these features* have gone from unsupported to supported: Bucket Lifecycle Supported Removing expired files is supported Bucket Website Supported Bucket Request Payment Supported Which got me a bit excited! Now to learn a bit about these and see if they work on our setup and if possible if we can make them work without breaking anything for existing objects & users: Bucket Lifecycle This is about expiration/automatic removal of objects at a certain time or after a certain time has passed. Let's start with S3 Some more details about the policies from Amazon S3: https://docs.aws.amazon.com/AmazonS3/latest/dev/lifecycle-configuration-examples.html https://docs.aws.amazon.com/AmazonS3/latest/dev/set-lifecycle-cli.html Telefonica open cloud has some nice documentation with s3cmd examples: https://support.telefonicaopencloud.com/en-us/ugs3cmd/obs/en-us_topic_0051518501.html I have not found anything better on docs.ceph.com -- Step 1. Create a lifecycle policy with s3cmd and in the XML format. (there is a JSON style with awscli and "aws s3api get-bucket-lifecycle-configuration --bucket mybucketname" ): Call the file expiry.xml and make the content something like this: ExampleRule expire_these_ Enabled 1 ) Original publisher: [Read original article]() Author: Unknown (noreply@blogger.com) Published: 2018-12-31T06:50:00Z Content type: article Language: en Sources: [CSC - IT Center For Science - Cloud Team]() Topics: [mount](), [Filesystems](), [Linux](), [Cloud]() Tags: [cinder](), [cloud](), [cpouta](), [filesystem](), [fstab](), [image](), [linux](), [maintenance](), [mount](), [openstack](), [pouta](), [server](), [storage](), [systemd](), [volume](), [volumes]() ### AI overview This article explains how to mount block-device volumes in Linux instances and why relying on standard /etc/fstab entries can prevent an instance from booting when a volume is missing or differs after an image-based deployment. It recommends mount options such as nofail and discusses noauto. ### Source excerpt Some background: As part of the CSC Pouta Cloud Openstack installation we provide the cinder service. This allows our customers to attach block devices to their instances. A common way to illustrate what this means is to say: ".. it's like attaching a USB drive to the instance. " - Some Openstack trainer After attaching the block devices one has to format it with a filesystem and mount it. The usual way to mount block devices (in most Linux based distributions I've seen, if you know other ways please comment below!) every time the server reboots is to put something like this into /etc/fstab: /dev/vdb1 /mnt ext4 defaults 0 0 All clear so far I hope. It mounts block device /dev/vdb to /mnt as filesystem ext4 with the defaults mount options and the last two fields (numbers) are about dumping and file system checks. (Sometimes it's wise to use UUID or LABEL and not /dev/vdb1 in case you have more than two volumes.) But what happens if disk with is not there anymore? Well, with the above fstab your instance will not boot into the operating system. You'll be stuck having to perhaps enter single user mode or attaching a volume and then rebooting and modifying fstab. Single user mode is probably OK sometimes (it's inconvenient and takes time). But let's say you took a snapshot of an instance in Openstack with the glance service. This creates an image of the root disk. If you then spawn a new instance with that image as a root disk it will still have that /dev/vdb1 in /etc/fstab. Hey ho, the new instance booted from the image will not boot. Here you could of course just create a new volume and attach it. But if you used UUID or LABEL in fstab then it wouldn't find those and also break! So what is the best(tm) way? By using some nice fstab mount options. For example nofail UUID=1c7fc2f-f9d9-4e01-8d0f-190f05416831 /mnt ext4 nofail,defaults 0 0 There's another mount option called "noauto". The difference is put quite nicely in this stackoverflow question which has a piece from ## cPouta Flavour Pikkujoulu 2018 Communiqué DevFeed: [cPouta Flavour Pikkujoulu 2018 Communiqué]() Original publisher: [Read original article]() Author: Unknown (noreply@blogger.com) Published: 2018-11-26T14:44:00Z Content type: release Language: en Sources: [CSC - IT Center For Science - Cloud Team]() Topics: [cloud-infrastructure](), [ceph](), [Hardware]() Tags: [capacity](), [ceph](), [cpouta](), [energy](), [hardware](), [hpc](), [standard](), [storage]() ### AI overview The communiqué announces changes to cPouta VM flavours: several older HPC flavours will no longer be available for new launches, while new hpc.4 and standard.xxlarge flavours will be added. The hpc.4 flavours use Ceph for VM root-disk backing storage, replacing older hardware without adding cPouta capacity. ### Source excerpt We are making some changes to the cPouta flavours offering tl;dr You won't be able to launch _new_ hpc-gen1.*core, hpc-gen2.2core, hpc-gen2.8core, hpc-gen2.16core flavours. We are adding hpc.4 flavours. We are adding a standard.xxlarge flavour. The new hpc.4 flavours The hpc.4 flavours are similar to the similarly named flavour in ePouta. The big difference between the hpc-genX is that hpc.4 will be using Ceph as default backing storage for VM root disks. We have wholesome experiences from Ceph in ePouta where all hpc-flavours are using Ceph as backing storage. One of the benefit is that if a hypervisor breaks, we can either migrate the customer instances away without customer noticing anything, or if the hypervisor has catastrophic failure the instance can be booted up on a new hypervisor without loss of data. Furthermore the sequential reads are much faster than on local spinning disks. This change will not bring additional capacity in cPouta, but replace old energy inefficient hardware in-kind with newer hardware. The new bigger standard flavour standard.xxlarge The standard flavours are the most popular flavours by a huge margin. An interesting thing that we have noticed is that if you combine the amount of hpc-gen2.8core and hpc-gen1.8core flavours that would be the second most popular flavour. We belivie that many will prefer to use standard.xxlarge instead of hpc flavours with similar amount of RAM. The new flavours hpc.4.5core - 5 cores 22GB RAM - replacement for hpc-gen1.1core, hpc-gen1.4core, alternative to hpc-gen2.2core, hpc.4.10core - 10 cores 44GB RAM - replacement for hpc-gen1.8core, alternative to hpc-gen2.8core hpc.4.20core - 20 cores 88GB RAM - replacement for hpc-gen1.16core, alternative to hpc-gen2.16core and hpc-gen2.24core standard.xxlarge - 8 oversubscribed cores, 32GB RAM - alternative to hpc-gen2.8core, hpc-gen1.8core, hpc4.5core and hpc.4.10core Why are the hpc-gen1 flavours disappearing? Existing instances of these flavour will continue to ## Ubuntu 18.04 images published in cPouta and ePouta DevFeed: [Ubuntu 18.04 images published in cPouta and ePouta]() Original publisher: [Read original article]() Author: Unknown (noreply@blogger.com) Published: 2018-10-17T07:30:00Z Content type: release Language: en Sources: [CSC - IT Center For Science - Cloud Team]() Topics: [Ubuntu](), [Cloud](), [ssh](), [Command-line interface](), [releases]() Tags: [cli](), [cloud](), [cpouta](), [diskimage](), [ed25519](), [epouta](), [horizon](), [image](), [lts](), [openstack](), [release](), [ssh](), [ubuntu]() ### AI overview Ubuntu 18.04 LTS images are available in the cPouta and ePouta cloud environments. The article explains that the images use Canonical's unmodified image, the default SSH user is ubuntu, and users can upload other Ubuntu cloud images or configure users with cloud-init and the OpenStack CLI. ### Source excerpt Hello Ubuntu fan boys and girls! An image containing latest LTS Ubuntu release (18.04 Bionic Beaver) is now available in c and ePouta! This time we opted to use the image provided by Canonical without any modifications. This means the user used to ssh in is now "ubuntu" instead of "cloud-user". In any case, trying to ssh in as root will tell you which user to ssh in as In case you want to try even newer versions of Ubuntu, say the "in-between" releases like 18.10 Cosmic Cuttlefish - head over to http://cloud-images.ubuntu.com/ , select the release and fetch the "cloudimg-amd64.img" - for example "cosmic-server-cloudimg-amd64.img" - which is a QCOW2 image. This you can then upload as an image in your c/ePouta project. Our user guide has some pictures and instructions how to work with and upload new images: https://research.csc.fi/pouta-adding-images To add your ssh key under a new "cloud-user" (in case you don't want to use ubuntu user) you can do something like below. First create a file that has the cloud-init user data. Then use that file as input to the openstack CLI tool. $ cat cloud-init.cfg #cloud-config users: - default: - default_user: name: cloud-user gecos: Cloud User sudo: ["ALL=(ALL) NOPASSWD:ALL"] ssh_authorized_keys: - ssh-ed25519 AAAAMYKEYQ user@email.example.org And then the openstack CLI command : $ openstack server create ubuntu1804 --flavor standard.small --image Ubuntu-18.04 --key mykey --security-group default --security-group ssh-group --user-data cloud-init.cfg It is if course possible to use horizon to supply the user data as well. p.s. Yes, ed25519 keys works this way! The web interface openstack horizon still does not support them yet. ## Customer Invisible Maintenance of the CSC Object Storage Servers DevFeed: [Customer Invisible Maintenance of the CSC Object Storage Servers]() Original publisher: [Read original article]() Author: Unknown (noreply@blogger.com) Published: 2018-03-14T07:36:00Z Content type: article Language: en Sources: [CSC - IT Center For Science - Cloud Team]() Topics: [BGP](), [networking](), [Load Balancing](), [Availability](), [round robin]() Tags: [bgp](), [ceph](), [cpouta](), [dns](), [exabgp](), [failover](), [ha](), [high-availability](), [load-balancing](), [maintenance](), [network](), [networking](), [object-storage](), [radosgw](), [round-robin](), [routing](), [server]() ### AI overview The CSC Pouta Cloud Team describes using ExaBGP on object storage servers to combine round-robin DNS load balancing with BGP routing for high availability and failover during maintenance. ### Source excerpt Hello! It's the CSC Pouta Cloud Team again! You may recognize us from other object storage films such as: http://pouta.blog.csc.fi/2018/02/admin-stories-implement-object-storage.html where we go through in excruciating detail how we configured CEPH RadosGW and why we configured it like we did http://pouta.blog.csc.fi/2018/01/objectively-speaking-in-cpouta.html where we announced object storage! In this episode we're going to talk a bit about how we implemented invisible(*) maintenance for our Object Storage customers. Configuration of ExaBGP with Object Storage CSC - IT Center for Science Ltd. has a close collaboration with the Finnish University and Research Network - FUNET, and because of that we are in a great position to do some fun network stuff. Actually, as long as your network has a BGP relationship with its internet provider you can also do what we have done. When we first launched Object Storage we just had a DNS entry pointing to two IP addresses. This gave us some load balancing and if we really wanted to we could take a node out of the DNS and do maintenance. But we wanted more! *ExaBGP enters the stage* In short we installed ExaBGP on our object storage linux servers, configured one dummy network interface per server and started to announce two IP addresses from each server. Then we pointed object.pouta.csc.fi DNS entry to these two IP addresses. The objective was to use round-robin DNS for load-balancing and BGP routing for High Availability. For failover this means that if one node goes down, the other IP is reachable on the other node and stuff will keep magically(*) working! There are some other BGP softwares out there, like BIRD or Quagga. Despite this, we never actually tried any other software since ExaBG has some great qualities such as: it came recommended by the network team at CSC who uses it for some services its low resource footprint and small number of software dependencies it is not a full routing suite - it is meant to be used for basi ## Admin Stories: Implement Object Storage in CSC's cPouta DevFeed: [Admin Stories: Implement Object Storage in CSC's cPouta]() Original publisher: [Read original article]() Author: Unknown (noreply@blogger.com) Published: 2018-02-12T12:58:00Z Content type: article Language: en Sources: [CSC - IT Center For Science - Cloud Team]() Topics: [ceph](), [Amazon S3](), [Cloud](), [API]() Tags: [backend](), [ceph](), [cpouta](), [infrastructure](), [object](), [object-storage](), [openstack](), [rados](), [radosgw](), [rgw](), [s3](), [server](), [servers](), [storage](), [volume]() ### AI overview This article explains the decisions behind implementing object storage in CSC's cPouta cloud. It describes using Ceph RADOS Gateway with existing Ceph clusters and clarifies the relationship between S3 buckets, Swift containers, accounts, and OpenStack project IDs. ### Source excerpt In our previous user survey we found out that you were interested in "OpenStack admin stories". This will be our first attempt in doing that. User guide: https://research.csc.fi/pouta-user-guide While implementing object storage we made a few decisions. This blog post is about highlighting the decisions and their backing thought process. Some background information: cPouta uses OpenStack as the underlying cloud middleware, and Ceph for storing volumes and images. And going forward, objects, too. Terminology RADOS Gateway/RadosGW/RGW/Ceph RGW/Ceph radosgw/radosgw. We mean the same thing. It's a piece of software which exposes an API for storing and retrieving objects. Ceph - the storage system which RadosGW daemons access as a client. Buckets in S3 and Containers in Swift are synonymous. The Ceph radosgw-admin tool also operates on buckets. The latter are mostly the same, but can contain a bit more information i.e. OpenStack project ID. If we write about buckets, the reader can presume we are referring to S3 buckets and Swift containers unless otherwise noted. Account is something that RGW binds usage data into. In some of the radosgw-admin CLI calls, accounts are referred to as users or UIDs. These users and/or accounts get a mapping to OpenStack project IDs in our configuration. So be it account/user/project, we are always talking about the same thing. - Why Ceph RadosGW The other option we briefly looked at for an Object Storage server was the OpenStack Swift server. Yes, there is an API called Swift and a piece of sofware called Swift which serves the Swift API. Not to mention the programming language Swift, the ISO standard SWIFT or the Scottish potato variant Swift. In the end we used none of these for backend because we prefer to reuse existing infrastructure. We already have Ceph clusters used for Virtual Machine image and block (volume) storage in our clouds. Installing some Ceph RadosGW servers and pointing those to an existing Ceph cluster utilizes a lot o ## cPouta Releases Object Storage for All Customers DevFeed: [cPouta Releases Object Storage for All Customers]() Original publisher: [Read original article]() Author: Kalle Happonen (noreply@blogger.com) Published: 2018-01-31T11:32:00Z Content type: release Language: en Sources: [CSC - IT Center For Science - Cloud Team]() Topics: [Cloud](), [cloud-infrastructure](), [data]() Tags: [access-control](), [backups](), [cloud-storage](), [cpouta](), [datasets](), [images](), [object-storage](), [pipeline](), [release](), [storage](), [web]() ### AI overview cPouta has released object storage for all customers. The cloud storage service stores and retrieves data over HTTPS, can be accessed from inside or outside cPouta, and supports different access-control levels and use cases such as website assets, datasets, research pipelines, and backups. ### Source excerpt We're pleased to release one of the most sought after features in cPouta - object storage! Object storage is now usable by all cPouta customers. It's a new service with new usage models, so for details I suggest that you check out our user documentation. This cat lives in the cPouta object storage. What is Object Storage? Object storage is a cloud storage service, where you can store and retrieve data over HTTPS. This is not tied to any individual virtual machines, and it's accessible from anywhere, inside and outside cPouta. There is also a variety of ways to share the data with others. Why should I use it? Object storage is generally used for a different purpose that many other storage solutions. Some benefits include You do not need to set up a virtual machine to serve or receive the data. The data can be accessed from anywhere using the same URL. The data can have different levels of access control. What can it be Used for? The object storage has tons of different use cases. Web sites can host their assets there (images, videos), researchers can publish their datasets, you can use it as a data staging platform for your research pipeline, you can push your backups there, among a horde of other things. The Inevitable "But" As with all new services, the first public release is never perfect. In the coming months we will upgrade things on the backend, to improve the system after real-scale experience. This should mostly be invisible to the you, but you might see small glitches when things are changed. We'll also improve the documentation and use case descriptions based on feedback. What we won't do is harm your data. We would not be releasing the service, if we were worried that we have to remove, or move or change the things you store there. For any problems with using the service, please don't hesitate to contact servicedesk@csc.fi. ## New GPGPU flavors in cPouta DevFeed: [New GPGPU flavors in cPouta]() Original publisher: [Read original article]() Author: Unknown (noreply@blogger.com) Published: 2017-09-22T09:38:00Z Content type: release Language: en Sources: [CSC - IT Center For Science - Cloud Team]() Topics: [cloud-infrastructure](), [Hardware](), [Nvidia](), [PyTorch](), [Deep learning](), [Server]() Tags: [compute](), [cpouta](), [deep-learning](), [hardware](), [nvidia](), [servers](), [tensorflow]() ### AI overview CSC is launching GPGPU flavors on the cPouta cloud platform. The instances use servers with four NVIDIA P100 Pascal cards each, substantial memory, and two SSDs in RAID1. They support GPU-accelerated computing, machine and deep learning, and rendering, with limited initial availability and relatively high billing-unit consumption. ### Source excerpt Today we're launching GPGPU (General Purpose Computing on Graphics Processing Units) flavors on cPouta! The servers have 4 NVIDIA P100 Pascal cards - each! They are backed by tons of memory and two SSDs in RAID1. This ensures that you can get the most out of these power-packed cards. This hardware is being shared with the CSC Super Cluster Taito; we can move GPGPUs between these when we see the need to (hint: contact CSC if there's no free GPGPUs and you need more). We're starting off with only a few GPGPU servers in cPouta while we get a feel for the demand. The details about the new flavors are listed in our user guide at research.csc.fi. Please note that the billing units consumed by these instances is quite significant compared to other flavors. The GPGPUs are great for running things like: High Performance Compute applications leveraging GPUs Machine- and deep learning i.a. TensorFlow Rendering ## Tech preview: Get your own Kubernetes container orchestration platform in cPouta DevFeed: [Tech preview: Get your own Kubernetes container orchestration platform in cPouta]() Original publisher: [Read original article]() Author: Unknown (noreply@blogger.com) Published: 2017-08-18T11:26:00Z Content type: release Language: en Sources: [CSC - IT Center For Science - Cloud Team]() Topics: [Kubernetes](), [Orchestration](), [container](), [Docker]() Tags: [commands](), [container](), [cpouta](), [documentation](), [kubernetes](), [new-feature](), [orchestration](), [preview]() ### AI overview This technology preview explains how users with cPouta access can launch a Kubernetes cluster using Magnum. It introduces container orchestration concepts and points readers to documentation describing the feature and its limitations. ### Source excerpt Introduction You can now launch your own Kubernetes cluster in cPouta with just a few simple commands using a new tool called Magnum. If you already have access to cPouta, it should take about 10 minutes to get up and running. You can find documentation for this new feature in the container orchestration chapter of the Pouta user guide. This is a technology preview feature for now, so there are some limitations that you should be aware of. Those are listed at the end of the documentation page. Why use container orchestration? While Docker containers can be useful on their own, if all you have is a bunch of Linux machines with Docker installed you still have to do a lot of work yourself to make an application fault tolerant, to make it discoverable from the outside world, to make sure the containers stay healthy and to enable containers to communicate with each other. You also have to manage the Linux machines themselves by installing and configuring packages and doing other normal administrative tasks. Container orchestration engines do a lot of this work for you by providing common abstractions around replication, routing, storage and other aspects of running a containerized application. A container orchestration engine typically runs as a clustered application on multiple servers. The servers are separated into two categories: master nodes and slave nodes. The master nodes are responsible for receiving commands via an API and acting on these commands to start and manage containerized applications that run on the slave nodes. Fault tolerance can be achieved by running multiple copies of an application on multiple slave nodes and the COE provides abstractions that make this easy. If you are not already familiar with container orchestration platforms, I recommend looking through the excellent Awesome-Kubernetes list of curated links about the topic. There you will find many introductory articles on Kubernetes, links to various related projects and many other things. ## New I/O flavors in ePouta DevFeed: [New I/O flavors in ePouta]() Original publisher: [Read original article]() Author: Jukka Nousiainen (noreply@blogger.com) Published: 2017-07-07T12:43:00Z Content type: release Language: en Sources: [CSC - IT Center For Science - Cloud Team]() Topics: [cloud-infrastructure](), [IO](), [Persistence](), [Apache Cassandra](), [datasets](), [Server]() Tags: [cassandra](), [clusters](), [cpouta](), [epouta](), [persistence](), [ssd](), [storage]() ### AI overview The I/O Virtual Machine flavors previously released in cPouta are now available in ePouta. They use SSD-backed striped RAID0 storage, providing high I/O performance without persistence or VM health guarantees if a node or disk fails. They are suited to clustered software such as Hadoop and Cassandra, with anti-affinity server groups recommended for node separation. ### Source excerpt About a year ago we released the I/O Virtual Machine flavors in cPouta. As of July, similar flavors are now also available in ePouta; you can find an exhaustive list here. The I/O flavors are provided with the same disclaimer as with their cPouta counterparts: both the root disk and the ephemeral disk for data storage are hosted on a striped (RAID0) array of SSD disks. That means you get a lot of I/O, but absolutely no guarantees for the persistence or health of VMs in case a node or a disk breaks. Thus these flavors are most natural to use with software which clusters nicely, such as Hadoop or Cassandra. To further ensure each VM in a cluster ends up on separate nodes, we recommend creating an anti-affinity server group. ## cPouta - Now with Haka! DevFeed: [cPouta - Now with Haka!]() Original publisher: [Read original article]() Author: Kalle Happonen (noreply@blogger.com) Published: 2017-02-17T12:32:00Z Content type: release Language: en Sources: [CSC - IT Center For Science - Cloud Team]() Topics: [Cloud](), [browser](), [API](), [Command-line interface]() Tags: [api](), [browser](), [cloud](), [command-line](), [cpouta](), [web-interface]() ### AI overview The cPouta cloud service now supports logging in with a Haka account through its web interface. Users still need a CSC account and access to a cPouta project, while Haka login is not yet available for API or command-line access. ### Source excerpt Many times we've been asked Can I log in to cPouta using my Haka account? Finally we can answer yes! "How do I log in again?" Not THAT kind of haka. ...but Things are never quite that simple. There are a few restrictions. The most important one is, that you have to have a CSC account and access to a cPouta project to do this. How do you get these? This page should get you started. https://research.csc.fi/accounts-and-projects We still have to keep track of research projects, their users, and their resource usage, which is why you still need a project. But once you have that, point your browser to https://pouta.csc.fi and log in to your heart's content. Please note that Haka logins only work with the web interface for now. We're looking into the option of enabling this for API and command line access in the future. Your CSC Cloud Team ## Storage updates, revisited DevFeed: [Storage updates, revisited]() Original publisher: [Read original article]() Author: Jukka Nousiainen (noreply@blogger.com) Published: 2016-12-13T13:19:00Z Content type: news Language: en Sources: [CSC - IT Center For Science - Cloud Team]() Topics: [cloud-infrastructure](), [migration](), [ceph](), [systems]() Tags: [ceph](), [cpouta](), [migration](), [storage](), [systems](), [updates]() ### AI overview The article revisits cPouta storage changes, including the migration of most detached HPC storage volumes to standard Ceph-based volumes. It also announces a December 28-30, 2016 service break, during which affected virtual machines may be forcefully shut down, and explains that Ceph will become cPouta's only storage system. ### Source excerpt Run of the Mill Back in September we blogged about disabling the possibility to create older cPouta volume types. This was the first step on the path to a more streamlined cPouta storage backend. Continuing on this path, we have now migrated most detached HPC storage volumes to standard volumes, and contacted users about their migration options for HPC storage volumes still attached to VMs. Next up, there will be a service break for the whole HPC storage environment, followed by severing the link between cPouta and the HPC storage backend for good. As pictures are often better than a thousand words, we'd like to illustrate these changes for the pleasure of the astute observer. Here's a (very) simplified diagram of cPouta's connectivity to its storage systems: Figure 1. Current topology of cPouta storage backends. The HPC storage system on the left hosts cPouta volumes that are visible to the user as "hpc-storage" or as the dash sign "-". The Ceph-based storage system on the right hosts cPouta volumes that are visible to the user as "standard". Going forward this Ceph-based system will be the only storage system of cPouta. Let it down The next upcoming change potentially affecting cPouta users is the service break for HPC storage systems between December 28th-30th 2016. Components affected by this maintenance are highlighted in Figure 2. Figure 2. Scope of service break on Dec 28th-30th 2016. Maintenance work on the cPouta specific storage controller will occur on December 29th. On this date, any cPouta VMs which still have hpc-storage volumes attached will be forcefully shut down to allow hypervisors to gracefully terminate their iSCSI connections to the HPC storage backend. Apologies about this inconvenience, which is unavoidable with the current firmware/kernel versions. All things must pass Throughout 2016 there has been aggressive growth in the utilization of CSC clouds' volume storage. This has been largely possible thanks to the elasticity of the Ceph-based st