Gagan Juneja

@RS146BIJAY Definitely a good guard rail to protect the system. Just out of curiosity, I want to know if we can evaluate(dry run) the index creation upfront if it is...

Thanks @Bukhtawar for clarifying and it does make sense as well. Optimistic locking is definitely a very costly operation here. We could think of something like resource allocation. Each request...

What is the benefit you see in keeping the whole history at node level? Keeping absolute total count could be an issue because it should always be the same or...

@vzez Thanks for the clarification. We can build it incrementally. It is not coming out well how these PA limitations are going to impact, like if we talk about storage...

@reta, Please take a look. Thanks!

> > @reta, Please take a look. Thanks! > > @Gaganjuneja I honestly doubt that this is what we should be doing: > > * this change will break each...

@zalseryani thanks for opening this issue. 1. For distributed tracing documentation fix, I have created an [issue](https://github.com/opensearch-project/documentation-website/issues/7028) and will address that. 2. To support configuring the exported end point, we...

@ansjcy, thanks for putting this up. Utilizing the OpenSearch telemetry framework for emitting these metrics does seem promising. The PA plugin generators are already well-written, making them easily reusable. Since...

Thank you, @reta and @backslasht, for your prompt responses. My suggestion is to retain these metrics within the "Performance Analyzer" plugin for the time being, given its extensive collection of...

Hi @jzonthemtn, Thank you for initiating this. Indeed, this feature holds significant potential. I firmly believe that implementing the mentioned feature is achievable by utilizing the Request [Tracing](https://github.com/opensearch-project/OpenSearch/issues/6750) and [Metrics](https://github.com/opensearch-project/OpenSearch/issues/10141)...