<p>What I have done?</p>
<pre class="lang-bash prettyprint-override"><code>$ kops edit ig nodes  ## added some nodes by modifying min/max nodes parameters
$ ...                 ## did some other modifications
$ kops update cluster ## saw the pending changes before applying them to the cluster
</code></pre>
<p>In <code>kops update cluster</code> I saw some not desired changes and wanted to revert all of them and start over.
But given that the pending changes live in a state file in S3, I was not able to revert such changes easily.</p>
<p>I realized I should have had an S3 versioning enabled to revert the changes quickly and easily, but I didn't have that, and needed another way of cancelling pending changes.</p>
<p>Do you know how to achieve that?</p>
<p>PS. I googled for &quot;kops drop pending changes&quot; and similar; I browsed kops manual page; I tried accessing kops from multiple accounts before I realized that the changes are shared via S3... Nothing helped.</p>
<p>UPDATE:
See the <a href="https://kops.sigs.k8s.io/tutorial/working-with-instancegroups/" rel="nofollow noreferrer">https://kops.sigs.k8s.io/tutorial/working-with-instancegroups/</a>, it says</p>
<blockquote>
<p>To preview the change:</p>
<p>kops update cluster </p>
<pre><code>...
Will modify resources:
 *awstasks.LaunchTemplate LaunchTemplate/mycluster.mydomain.com
   InstanceType t2.medium -&gt; t2.large
</code></pre>
<p>Presuming you're happy with the change, go ahead and apply it: kops update cluster  --yes</p>
</blockquote>
<p>So - what I want to do is to revert the not-yet-applied changes if i'm not happy with them. Is there any way other than <code>kops edit ig nodes</code> and manually changing <code>t2.large</code> back to <code>t2.medium</code>, repeating that for all changes I want to revert?</p>

Serge Vin
<p>As <a href="https://kops.sigs.k8s.io/getting_started/production/" rel="nofollow noreferrer">the production cluster recommendations</a> states, storing the configuration in version control is recommended to avoid these scenarios.</p>
<p>But given that you are already facing a challenge now ...
It depends on what is introducing the change. If it is a change in your cluster config alone, reverting those changes would be the way to go.</p>
<p>If the changes comes from a kOps upgrade, there is no real way of reverting. kOps should never be downgraded, and the changes it tries to do are there for good reasons.</p>
<p>If you can share what the unwanted changes are, I may be able to determine how to revert them.</p>
