Re: Improving the Apache Ozone Website and Documentation

+1. I am one of the developers who worked on the ozone website. This is long overdue, thanks for the suggestion— I think the biggest issue is content, but hopefully it will be addressed along with this upgrade. —Anu Get Outlook for iOS Fro

Re: [DISCUSS] Proposal to merge Ozone feature branch HDDS-7733-Symmetric-Tokens to master

I had a slightly orthogonal question: Do we need any special authentication mechanism today to join a Ratis ring ? It is probably not a significant question -- and the answer is that we are secure -- it was not obvious for me from reading code. Hence the question. Here is a possible attack vector

Re: [RFC] Proposal: Reserve Space for Allocated Blocks

s risk we can get abnormally > large containers. What do you think? > > I have also tested the simple delay proposal. It sometimes works well. > But sometimes still produces fragmented blocks. This is expected. > > Kaijie > > On Wed, 28 Sep 2022 08:00:38 +0800 anu engineer

Re: [RFC] Proposal: Reserve Space for Allocated Blocks

Thank you for the POC, and the numbers from your POC. It looks very good. I know this is a private POCproposal, yet I have two minor questions. 1. Should we maintain the client ID in "private final Map containerLeases" map ? so instead of a long we maintain a Long + Client ID is what I was thin

Re: [RFC] Proposal: Reserve Space for Allocated Blocks

e complicated than introducing a lease into the > protocol, though it is more complex than an arbitrary delay which, as Anu > stated correctly, is not easy to reason about, hard to test, and leads to > more uncertainty and harder to understand later on. > > Pifta > > > anu engin

Re: [RFC] Proposal: Reserve Space for Allocated Blocks

it a bit more due to delays in container closure, the second one seems to > solve the problem as it closes the container when all writes have been > finished, or abandoned, while limiting the number of writes that can go > into a container, at the price of having more open containers (fo

Re: [RFC] Proposal: Reserve Space for Allocated Blocks

and > haven't checked what is actually in the code at the moment, just wanted to > share my idea quickly to validate with folks who know more about the actual > code out there in the codebase, to see if it is a feasible alternative. > > Pifta > > > anu engineer ezt írta

Re: [RFC] Proposal: Reserve Space for Allocated Blocks

ggestion. Granting a lease to client > > sounds like a more controllable way. > > > > However, if I understand correctly, clients don't talk to SCM directly. > > Does it mean OM has to relay the renew lease request to SCM? > > Is there a better way to implement it? >

Re: [RFC] Proposal: Reserve Space for Allocated Blocks

Extending the same thought from Steven. If you are going to do a small delay, it is better to do it via a Lease. So SCM could offer a lease for 60 seconds, with a provision to reacquire the lease one more time. This does mean that a single container inside the data node technically could become la

Fwd: Conscious Language Checker at the ASF

Folks, I looked at this tool and the Ozone's list of offending words. They fall into 1. Master 2. Slave 3. he/she/his/her 4. Sanity Check https://clc.diversity.apache.org/analysis.html?project=ozone.git Does anyone feel strongly one way or another? that is, we should fix it or don't fix it? M

Re: Secrets committed as part of Ozone Commits

Completely agree with Marton's proposal, force pushing really does not work with Git. Invalidation of the secrets is the best defence and it would be nice to get back to a consistent tree. Thanks Anu On Thu, Mar 25, 2021 at 1:47 AM Attila Doroszlai wrote: > On Thu, Mar 25, 2021 at 7:32 AM El

Re: [PROPOSAL] Go client for ozone

+1 , I think it is a great idea —Anu > On Mar 1, 2021, at 2:53 AM, Elek, Marton wrote: > >  > Hi, > > Earlier I had some experiments with creating a native go-lang client for > Ozone. > > Go has good integration with native libraries, for example there are easy > ways to create native fuse

Re: [DISCUSS] Github issues vs Jira issues

This is Anecdotal data -- However I thought it might be useful to share. In my current project(Unfortunately not open source, so I will not be able share the data or screen shots) we use Github issues exclusively to track all the issues. Some things work very well -- So the pros are: 1. Very easy