Integration count limit is not enforced in TP2

[dsimansk]

It seems that our limits are not applied for TP2 on production cluster. Therefor I'm able to deploy 2 Integrations at once. Fortunately the current quota(after Keycloak removal) is gracious enough to accomodate those deployments.

[dsimansk]

@rhuss @zregvart correct me if I'm wrong, but we set up annotation during creating DC, but then fetch DCs with label. Could this be caused by kubernetes-client upgrade actually? That for some reason older client doesn't distinguish between those two variants.

syndesis-rest/controllers/src/main/java/io/syndesis/controllers/integration/online/ActivateHandler.java

Lines 116 to 120 in bfea32f

	return DeploymentData.builder()
	.addLabel(OpenShiftService.REVISION_ID_ANNOTATION, revision.getVersion().orElse(0).toString())
	.addAnnotation(OpenShiftService.USERNAME_LABEL, username)
	.addSecretEntry("application.properties", propsToString(applicationProperties))
	.build();

syndesis-rest/controllers/src/main/java/io/syndesis/controllers/integration/online/ActivateHandler.java

Lines 194 to 202 in bfea32f

	Map<String, String> labels = new HashMap<>();
	labels.put(OpenShiftService.USERNAME_LABEL, Names.sanitize(username));
	return (int) openShiftService().getDeploymentsByLabel(labels)
	.stream()
	.filter(d -> !Names.sanitize(name).equals(d.getMetadata().getName())) //this is also called on updates (so we need to exclude)
	.filter(d -> d.getSpec().getReplicas() > 0)
	.count();
	}

[rhuss]

Annotations and labels were and still are completely different things so I wonder whether this has changed in the code or never worked as expected.

Let me check that later ....

[dsimansk]

As we discussed on channel, imho the following change is causing the issue. I can confirm that manually adding label USERNAME to first deployment prevents the subsequent one from starting and puts it immediately to Inactive state (without s2i build triggered etc.).