Hi Devs,
I have another approach without have much impact to system keeping some
restrictions as usages and minimize the impact.
I have attached the proposal, please have a look.
Regards
Sumit
On Wed, Nov 2, 2022 at 3:49 PM Nandakumar Vadivelu
wrote:
> + Sumit Agrawal
> (He is also w
ed)
> >
> > Question 2,
> > In openKey request, OM may pre-allocate some blocks for the client,
> > How do we set the expiration time for the pre-allocated blocks?
> >
> > Question 3,
> > When it's safe to close the container?
> > (I as
tting (30+ seconds).
- During this time, client can add a lot of block data during that time
- Exploitation is easy, but client should be authorized to get block
write permission
--
*Sumit Agrawal* | Senior Staff Engineer
cloudera.com <https://www.cloudera.com>
[image: Cloudera] <https:
is messing
> up the container space and the OM metadata, and that is done with the
> proposed check in ICR and with the check at committing the write from the
> client to OM.
>
> Regards,
> Pifta
>
> Sumit Agrawal ezt írta (időpont: 2022.
> nov. 29., K, 7:20):
>
> &g
can
> > > > > give a 3-7days time window for the old reviewer to check as a
> final
> > > > > friendly reminder. If still no responses, then we can just move
> > ahead
> > > for
> > > > > commit based new committer reviewer's
ed to the symmetric secret keys life-cycle, as per HDDS-8003
> <https://issues.apache.org/jira/browse/HDDS-8003>.
>
> More information can be found on the wiki page:
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=255070328
>
> If there are no objectio
t is not trivial
> and
> > > has
> > > > to
> > > > > > be
> > > > > > > split into smaller tasks that cannot be shipped individually.
> > That
> > > is
> > > > > > > the reason why the implementation
he wiki page:
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=255070328
>
> Thanks,
> Duong
>
--
*Sumit Agrawal* | Senior Staff Engineer
cloudera.com <https://www.cloudera.com>
[image: Cloudera] <https://www.cloudera.com/>
[image: Cloudera on Twitt
Hi Ashish,
I have a different opinion for this (extension of solution 5 with defining
behaviour of "ozone fs”),
Recursive listing using fs:
OBS bucket are special bucket which will list at top level, but not recursive
- Compare like a directory having no permission
- can give an error l
y, and we want to do it right, then releasing
> > 1.3.1
> > > in the next 1-2 weeks seems to be the proper approach.
> > >
> > > I am +1 for all these 3 approaches and I am not against the approach
> > listed
> > > in point 1., however I do not supp
gt; one
> > > that’s using asf-site as the default. They are all using the
> development
> > > branch (equivalent to our master branch) as the default branch. See
> > >
> > >- https://github.com/apache/yunikorn-site
> > >- https://github.com/apache
gt; > > in the Ozone API.
> > > > >
> > > > > Checklist for feature branch merge:
> > > > >
> > > > >
> > > >
> > >
> >
> https://cwiki.apache.org/confluence/display/OZONE/Atomic+Key+Overwrite+and+Key+Replacem
I assume it's due to GitHub environment changes: tests are failing
> > > with runner version 20250427.1.0, passing with 20250504.1.0.
> > >
> > > Which is strange, since 20250427.1.0 is supposed to be a rollback.
> > > The same tests were passing with that vers
uite prominently in
> Google searches from anecdotal experience unless one adds the term jira to
> the search.
>
> We should eventually move all the core design docs into the website which
> will show up in searches.
>
--
*Sumit Agrawal* | Senior Staff Engineer
cloudera.com <
14 matches
Mail list logo
