You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Should result in both app1 and app2 receiving the same data. However, what happens is that only the first really related app gets the data whereas the second gets an empty "data: {}" field.
Looking into the code, I think we are not watching for new apps being attached (i.e. the -created events). We should essentially call the _on_config_changed logic, but focusing only on the new app at every -created.
The text was updated successfully, but these errors were encountered:
To summarize our internal discussions here, most of the use cases do not need s3-integrator with more than one relation. That also contemplates the cases where we have multi-cluster deployments:
single juju app, single sharded app - single s3-integrator
multi juju apps, async replications (hence, multiple clusters) - different s3-integrators, one per cluster
multi juju apps, sharded app (hence, compose one single big cluster) - (temporary) single s3-integrator related to the main orchestrator of that bigger cluster
Now, there is one use-case raised by @deusebio which is not yet clear if it establishes the need for single s3-integrator / multiple relations:
use-case where a s3 bucket is shared by multiple apps. Spark write logs to an s3 buckets that needs to be read by spark history server. Therefore a s3 integrator (provider) is related to both spark-history-server (requirer) and configuration hub (requirer)
In case @deusebio's case is kept and we will use a single s3-integrator charm for that, then we need to:
remove the limit from metadata.yaml, if it was added by then
The following setup:
Should result in both
app1
andapp2
receiving the same data. However, what happens is that only the first really related app gets the data whereas the second gets an empty "data: {}" field.Looking into the code, I think we are not watching for new apps being attached (i.e. the
-created
events). We should essentially call the_on_config_changed
logic, but focusing only on the new app at every-created
.The text was updated successfully, but these errors were encountered: