Summary
The user suggests implementing the AgentMetadataService as a gRPC service to simplify configuration details, although they don't recall the specifics of the agent configuration. They inquire about how propeller will discover configmaps and propose using a naming convention or labels for locating custom agent configmap objects through the Kubernetes API. They believe the discovery and merging logic should be managed by the propeller manager, which handles CRUD operations on Kubernetes objects with required authentication and authorization. The user concludes that this method minimizes changes to propeller, which is typically static concerning configurations.
shuliang
yep
honnix
sounds good, and it minimizes the change to propeller. iirc, propeller is pretty static about configs.
shuliang
yeah the propeller is the place to CRUD K8s objects with the right authn/z anyway..
honnix
And putting this discovering and merging logic to propeller manager, I assume?
shuliang
> A quick question, how will propeller discover the configmaps? one possible option is to locate the custom agent configmap objects with some convention (name) or some labels. this should be trivia using k8s API….
eric901201
> the AgentMetadataService is implemented by a gRPC service, most of configuration could be omitted. Is that correct? yes!
honnix
I also think this is a great idea!I don't remember details of the agent configuration, but I think if the AgentMetadataService is implemented by a gRPC service, most of configuration could be omitted. Is that correct.