Add revert_previous_change_set method to the Stack class

[PiotrKozlowski]

for: https://app.zenhub.com/workspaces/openstax-unified-5b71aabe3815ff014b102258/issues/openstax/unified/972

Used in https://github.com/openstax/unified-deployment/pull/97

I don't know why the test is failing, so I still need to fix it, but please let me know what do you think of this approach

I've based my test on the previous test. Just added 3 lines for reverting and checking if changes were applied.

[PiotrKozlowski]

Can someone look into this test case error?
It seems that calling two times apply_change_set in the same test case is breaking something
After first apply_change_set

create_change_set_output = client.create_change_set(options)

from def create(options:) in ChangeSet class will output:

{"id":"arn:aws:cloudformation:us-east-2:373045849756:changeSet/spec-aws-ruby-stack-update-new-parameters-20191108-193456/8efb6f18-f783-47c4-b492-087246b36d21","stack_id":"arn:aws:cloudformation:us-east-2:373045849756:stack/spec-aws-ruby-stack-update-new-parameters/c70f9510-025e-11ea-ab6c-0af659736e02"}

but then, for the second call, create_change_set_output will become #<Class:0x0000559a770d0838> and then it breaks on the next line because it can't obtain an id from this object.

It seems to be some kind of cached pointer, but I can't find a way this behaves that way and how to solve this.

[janKozie1]

Re recording the requests seems to fix it @PiotrKozlowski

[jpslav]

The previous change set could also have had a different stack template. So we'd need to use that too? (the change set we are trying to revert could be using both new parameter values and a new template). Code like https://github.com/openstax/aws-ruby/blob/master/lib/openstax/aws/stack.rb#L59-L60 is maybe helpful.

[PiotrKozlowski]

Is this something which may happen only when we code this directly, like in the test: it "can be updated with a new template" where we create a new stack and then create new stack class and instead of calling create we just call apply_change_set?

In this case, it seems like it would be not possible to retrieve the first template data using cached @previous_template because it would be a new class.

It seems like this case for creating a new stack class and calling apply_change_set instead of create is something which would be outside of the current concept of reverting changes using @previous_parameters to store the previous values.

I was thinking about passing template_s3_url to the revert_to_previous_change_set and apply_change_set methods which would work but it would not update response for stack.template method

What do you think would be the best option to allow reverting templates?

[jpslav]

What about this? #69

[PiotrKozlowski]

Looks good, I've added some fixes and updated cassettes: #71

[jpslav]

"Reverting to previous change set..." is probably more appropriate given the comment below about templates changing too

[jpslav]

Should this be an error? logger.error? And if an error should we exit or raise?

[PiotrKozlowski]

I would not call an error here and just let the user know that he called a method on a stack which does not have a previous version
If you want me to change that, please let me know what should happen in that case

[jpslav]

Do we need to persist the previous parameters or template somewhere? If the process dies, these instance variables will be lost and we will no longer be able to revert.

[PiotrKozlowski]

Hmm, that's a good question. I'm not sure if this should be done in this or a in a separate issue. I also don't know what would be the best way to achive this - some temp file?
cc @TomWoodward