Streams retain properties after a failed deployment and cannot be overwritten without destroying and recreating.

[cribble-uwindsor]

trafficstars

Description: This is similar to https://github.com/spring-cloud/spring-cloud-dataflow/issues/5375 but not exactly like it. They may be related though.

If I create a stream and one or more of my stream components does not deploy properly, the properties from that deploy become "stuck" and I cannot update or clear them without doing a full destroy of the stream and recreating it.

Release versions: Data Flow Server Implementation Name: spring-cloud-dataflow-server Version: 2.11.2-SNAPSHOT Commit: 86b53e0

Steps to reproduce:

1. Using the SCDF UI, add the pre-packaged stream apps
2. Create a jdbc | log stream via the UI (This could be any stream definition really that you can cause to error)
3. Add the following properties in the freeform text editor

app.jdbc.spring.datasource.password=somepass
app.jdbc.spring.datasource.url=jdbc:someurl
app.jdbc.spring.datasource.username=someuser
app.jdbc.query=select 1 from dual

4. These are intentionally bad properties and will cause the jdbc source component to fail on deployment
5. Once you see that it has failed to deploy, undeploy the stream.
6. In the freeform text editor update the jdbc properties from above to valid values
7. As you watch your components spin up you'll notice that the invalid properties are still being used. And the stream will again fail to deploy.

[corneil]

@cribble-uwindsor
This property is not valid, it should be: app.jdbc.supplier.query=select 1 from dual

In my testing the spring.datasource properties are updated with the values passed and provided to pod as arguments.

[cppwfs]

Closing due to inactivity. If closed in error please let us know.

[cribble-uwindsor]

Hi, please re-open. I'm sorry, I totally missed @corneil comment earlier.

The property app.jdbc.query=select 1 from dual is intentionally invalid in order to cause the pod to fail to start. This causes the properties to lock for us and we have to destroy the stream in order to "reset" them.

[corneil]

@cribble-uwindsor What do you expect the stream to do when a pod doesn't deploy correctly?

How long should we wait before deciding to destroy the stream?

[cribble-uwindsor]

@cribble-uwindsor What do you expect the stream to do when a pod doesn't deploy correctly?

How long should we wait before deciding to destroy the stream?

My expectation would be that the stream could be undeployed and then configuration changed and re-deployed. After that, the pod and stream should deploy fine.

In our case, we're seeing the original bad config "stick" despite correcting it after the failure.

Would it help if I made a video or some screenshots of replicating the issue?