How to access InitManager during grpc initialisation

[nbaws]

As part of removing AWS request signing dependency on curl, I have run into an issue which surfaces due to grpc credentials extension being instantiated with a CommonFactoryContext.

AWS request signing credential retrieval has now been refactored to use Http::AsyncClient. This creates a dependency on ServerFactoryContext->initManager(), as we need to wait for clusters to come online before attempting to retrieve credentials.

envoy/source/extensions/common/aws/credentials_provider_impl.cc

Line 155 in ee61634

context_->initManager().add(*init_target_);

This is fine for normal extension initialization case (upstream and downstream filter). However initmanager is not available in CommonFactoryContext.

Is this even possible? I'm not entirely clear on the rationale behind the two different factory contexts, why grpc credentials uses Common rather than Server or whether an init manager is reasonable for this part of the startup process.

envoy/source/extensions/grpc_credentials/aws_iam/config.cc

Line 26 in ee61634

Server::Configuration::CommonFactoryContext& context) {

@wbpcode

[mattklein123]

cc @kyessenov who probably has more recent knowledge on this than I do.

[nbaws]

best I've been able to work out is that the grpc credentials extension kicks in very early, before ThreadLocalClusterManager is available. So even with Init Manager access, I won't be able to add these clusters.
It seems like a catch-22, if the grpc credentials extension depends on us, which depends on ThreadLocalClusterManager to be initialized, I have to find a way to wait for initialization to complete first. I'll keep kicking the tyres on this to see what I can work out.