Closed afeld closed 8 years ago
Hi there!
We use Pivotal Tracker to provide visibility into what our team is working on. A story for this issue has been automatically created.
The current status is as follows:
This comment, as well as the labels on the issue, will be automatically updated as the status in Tracker changes.
@afeld what does it mean for a manifest to be "complete"? How can I verify this on my own manifests?
@adelevie I mean that deploying with the same codebase+manifest to a new application (in the Cloud Foundry sense) will yield the same results. For example, if an API secret is set as a user-provided environment variable (rather than, say, a user-provided service instance and bound within the manifest), deploying to a new application would not have access to that secret. In other words, the principle of least surprise would suggest that deploying an application with Autopilot to yield the same results as deploying with cf push
, regardless of what is stated in the manifest vs. previously set through the command line.
Not sure that I'm explaining it well...?
I have come around in deciding that, while this might be convenient for switching to autopilot, it's actually an antipattern.
Hey! Pleased to have come across this project. I had written something similar, which I had been planning to port over to a CLI plugin.
Wanted to raise an idea: while I totally understand the reasoning for (and simplicity of) requiring the user to have a complete manifest to deploy with, my guess is that in reality, there are lots of applications that don't (mine included). For
cf-blue-green
, I was starting to play around with having the local manifest merged with the remote one (basicallylocal -> inherit: -> remote
); in other words, any local manifest changes will be included in the new deploy, but any configuration not reflected in the manifest would be included as well.Not sure how well I explained it... Thoughts? Also, sorry if there's a better forum for feature ideas.
/cc @mogul @dhcole