Pierre Villard created NIFI-14995:
-------------------------------------
Summary: Improve Flow Differences Filter to account for
renameProperty and createControllerService
Key: NIFI-14995
URL: https://issues.apache.org/jira/browse/NIFI-14995
Project: Apache NiFi
Issue Type: Improvement
Reporter: Pierre Villard
Assignee: Pierre Villard
As we use more and more the migrateProperties capabilities, we see that we have
some corner cases where the automated changes are showing as local changes
which is confusing because a user is upgrading without making any changes and
the UI is showing that some local modifications have been made. Such scenarios
should be better handled to not show local changes.
One scenario has been handled in NIFI-14985 to better deal with removed
properties.
This Jira is to handle two additional scenarios (this is combined in a single
Jira because of the approach taken that is introducing a concept of
environmental context)
h3. Rename property with parameters
Let's consider a processor version N with
{code:java}
public static final PropertyDescriptor ACCESS_KEY_ID = new
PropertyDescriptor.Builder()
.name("Access Key")
.displayName("Access Key ID")
.expressionLanguageSupported(ExpressionLanguageScope.ENVIRONMENT)
.required(false)
.addValidator(StandardValidators.NON_EMPTY_VALIDATOR)
.sensitive(true)
.build(); {code}
And then version N+1 with
{code:java}
public static final PropertyDescriptor ACCESS_KEY_ID = new
PropertyDescriptor.Builder()
.name("Access Key ID")
.expressionLanguageSupported(ExpressionLanguageScope.ENVIRONMENT)
.required(false)
.addValidator(StandardValidators.NON_EMPTY_VALIDATOR)
.sensitive(true)
.build();
...
public void migrateProperties(PropertyConfiguration config) {
config.renameProperty("Access Key", ACCESS_KEY_ID.getName());
}{code}
If the versioned flow is containing:
{code:java}
"groupIdentifier" : "flow-contents-group",
"identifier" : "8de3b31b-0a70-3e01-a01c-4ed2fe3a4cbe",
"name" : "AWS Credentials Provider",
"properties" : {
"Access Key" : "#{AWS Access Key ID}",
"default-credentials" : "false",
"Session Time" : "3600",
"assume-role-sts-signer-override" : "Default Signature",
"assume-role-sts-region" : "us-west-2",
"Secret Key" : "#{AWS Secret Access Key}",
"anonymous-credentials" : "false"
}, {code}
Then we would show two local changes:
* Property Parameterization Removed - Property 'Access Key ID' is no longer a
parameter reference
* Property Parameterized - Property 'Access Key ID' was parameterized
We should not be showing this as local changes.
h3. Create Controller Service
When using something like:
{code:java}
@Override
public void migrateProperties(final PropertyConfiguration config) {
if (!config.isPropertySet(ABC.getName())) {
final String serviceId = config.createControllerService(
"org.apache.nifi.foo",
Map.of());
config.setProperty(ABC, serviceId);
}
super.migrateProperties(config);
} {code}
Then we would be showing two local changes:
* Property Added: the property ABC has been added
* Component Created: a controller service has been created
We should check that if the property being added is not a dynamic property, and
is referencing the UUID of the created controller service, then both changes
should not be showing as local changes.
h3. Approach
Introducing a richer EnvironmentalChangeContext that is reused across all
comparisons. This is how we can link a couple of differences as related to the
same change and decide to filter out the differences or not.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
