Closed zmraul closed 1 year ago
Uhm, could we handle the error and rather put the charm into blocked state (with a sensible message) should the validation for the topic name not pass?
Uhm, could we handle the error and rather put the charm into blocked state (with a sensible message) should the validation for the topic name not pass?
We can do that, but I was letting it fail on purpose as a way of also stopping all events from triggering.
But the relation would be created anyway in the juju model, right? I mean, you would only stop anything from happening at the data-integrator side I suppose. We could always put the charm into a blocked status and then allow the user to change the configuration (topic_name) and if the user then provides sensible values (with juju config and handling config_changed events), then everything solves by itself, since the relations are already in place
But the relation would be created anyway in the juju model, right? I mean, you would only stop anything from happening at the data-integrator side I suppose.
Not exactly, KafkaRequires
is invoked in the init method. Since we don't update relation databag, the config information is not being used on kafka side either.
But I see that this is creating some unexpected outcomes, as I don't think setting status on init is a good option.
Changes look all right, but let's trigger the discussion of handling validation inside and outside DataPlatform to understand the long-term solution. But fine to be merged for the time being.
There are a number of failing integration tests although, that needs to be fixed before merging.
Update with the changes from
data_platform_libs
onKafkaRequires
and add an integration test on wildcard usage.Only the test needs review.