Your approach seems very sensible and the data you provide is in support of this. I do hope you stick with this, and more importantly, your data drive meta-methodology, and not let an HN post who don't face the use cases etc. drive you to abandon this.
We love to hear feedback from customers because it allows us to refine the product. From our internal metrics we know that providing an automatic snapshot recovery function is essential given the number of times its been implemented but we can also understand this customers issue with data being destroyed.
The data is destroyed securely, but not as immediately as they would have liked since the default behavior is to preserve a snapshot until it automatically expires.
These discussions are great for us because they allow us to refine the user experience and ensure that we can provide a great service. As we've been doing a tremendous amount of work on the backend code this is a great time for this customers concerns to be discussed as we are knee deep in large rewrites at the moment and its the perfect time to address this, rather than deploy to production and then have to go back and retool.
Given that we've been working on the secure destroy all the time having that be an option doesn't make sense and instead we can use that UX/UI real-estate to expose the temporary snapshot issue but again would love to hear more feedback on whether that's necessary.
We would of course love to please every customer but then we would have a platform with 1,000 features so sometimes you have to politely decline a request because it doesn't fit in with the general use cases, but it doesn't mean that we shouldn't engage in a discussion as that is always helpful.
Even if action isn't immediately taken it often leads to us asking numerous questions that are always great that can lead to new product and feature ideas that may not be tied to the original question in mind but still can move the product forward in other areas.
I agree. I also think that the poster could have talked with a DO rep. before making this public. It seems like the intention was to "expose" DO. I could be wrong though.
