<p>Why there is restriction while expanding and reducing the storage config size in cassandra operator- Datastax</p>
<p><a href="https://github.com/datastax/cass-operator/issues/390" rel="nofollow noreferrer">https://github.com/datastax/cass-operator/issues/390</a></p>
<p>Why there is a validation/restriction in statefulset for expanding storage config?</p>

<p>The exact same question was asked on <a href="https://community.datastax.com/questions/12269/" rel="nofollow noreferrer">https://community.datastax.com/questions/12269/</a> so I'm reposting my answer here.</p>
<p>Jim Dickinson already answered this question in <a href="https://github.com/datastax/cass-operator/issues/390" rel="nofollow noreferrer">issue #390</a> you referenced.</p>
<p>Attempts to change <code>StorageConfig</code> is blocked because the <code>StatefulSet</code> also doesn't allow changes to the <code>PersistentVolumeClaim</code>.</p>
<p>If a pod has run out of disk space, it is possible to workaround it by resizing the underlying volume provided it is supported in your environment. For example, public cloud providers allow volumes to be resized in certain configurations. You will need to consult the documentation of the relevant cloud provider for details.</p>
<p>Be aware that this workaround can be risky since it means that the underlying volume will be out of sync with the <code>CassandraDatacenter</code>, <code>StatefulSet</code> and/or <code>PersistentVolumeClaim</code> definitions. When you scale up the DC at a later date, the volume will be the originally defined size.</p>
<p>Note that we aim to document a workaround for the cass-operator in <a href="https://dtsx.io/3znMa05" rel="nofollow noreferrer">K8ssandra.io</a>. Cheers!</p>
