Skip to content
This repository has been archived by the owner on Jan 13, 2021. It is now read-only.

Support dry-run mode #105

Open
ash2k opened this issue Jul 19, 2017 · 1 comment
Open

Support dry-run mode #105

ash2k opened this issue Jul 19, 2017 · 1 comment
Labels

Comments

@ash2k
Copy link
Contributor

ash2k commented Jul 19, 2017

Perhaps a REST endpoint that accepts POST with a Bundle object and returns detailed explanation of what is going to happen if this object is stored:

  • Which objects are going to be created
  • Which objects are going to be updated
    • A diff for each one?
  • Which object are going to be deleted
  • What status will the Bundle have
    • Not a final status, but the one after the very first pass. This is to catch issues with the Bundle object itself.
  • What else?
@ash2k ash2k added the feature label Jul 19, 2017
@wryun
Copy link
Contributor

wryun commented Jan 2, 2018

AFAIK this can't give us a proper dry-run because we have to assume any object with a reference to a changed object is tainted, whereas on actual execution this might not be true (e.g. if I change my db parameters, and my compute has a dependency on the db, it looks like compute might be changed... but then we run it and we find that the hostname is unaltered).

Hmm, although secrets may obscure this mechanism. Interesting. Don't properly understand how service catalog handles bindings (e.g. when should bindings be regenerated?). Need to discuss.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

2 participants