On 2023/02/07 18:41:20 Heesung Sohn wrote:
> On Sun, Feb 5, 2023 at 2:26 AM Yan Zhao <horizo...@apache.org> wrote:
>
> > On 2023/02/03 18:14:53 Heesung Sohn wrote:
> > > There are some cases to trigger it.
> > > 1. A cursor be removed.
> > > 2. Close the current ledger and create a new ledger.
> > > 3. Consumer ack the message, the slowest cursor move forward.
> > > 4. User trigger truncateTopic by admin.
> > >
> > > I see that this pip is for the internal ledger deletion cases(1-3 above),
> > > and it appears that such internal deletion operations do not require
> > > pre-validation or status checks(and no additional iops on the metadata
> > > store). I agree that we need a separate pip for async admin operations.
> >
> > This pip is also applied to case 4. All cases will invoke
> > `trimConsumedLedgersInBackground`.
> > This pip acts inside the method.
> >
>
> For the long-running async admin operations such as
> deleteTopic/Namespace/Tenant/*, as I mentioned, I think we better provide
> the describe* APIs to enable the admins to check the status of the async
> operation.
> I believe we can first use this system topic from this pip to support case
> 4, "admin async operations."
> Still, we probably need a separate pip to discuss
> - the expected behavior/experience of async admin operations.
> - if we want to provide describe* APIs for the async operations.
> - target resources
> - architecture/components how to support describe* APIs
Agree, if there are some long-running async, and don't know the expected
end-time operations.
We can add the describe* API to get the progress rate of the operations.
