elek commented on pull request #1149:
URL: https://github.com/apache/hadoop-ozone/pull/1149#issuecomment-671775358
Summary: got +1 from @bharatviswa504 and @arp7 also confirmed offline, that
he is fine with it (if o3fs/ofs are not changed).
Hanisha's suggestion also applied (and I pi
elek commented on pull request #1149:
URL: https://github.com/apache/hadoop-ozone/pull/1149#issuecomment-671515628
@hanishakoneru Sure,
I also thought about separating the test changes and the serviceId changes
(I created a separated jira for the test changes and I considered posting
elek commented on pull request #1149:
URL: https://github.com/apache/hadoop-ozone/pull/1149#issuecomment-670847382
> I think we reach consensus "convenience" should not be priority when
multiple service ids are added even though they may have only one before. User
must specify service id e
elek commented on pull request #1149:
URL: https://github.com/apache/hadoop-ozone/pull/1149#issuecomment-670846255
> @elek I don't see any commits, but the comments are marked as resolved.
> Looks like commit push was missing?
Ups, sorry. I pushed to origin instead of my fork. Fixe
elek commented on pull request #1149:
URL: https://github.com/apache/hadoop-ozone/pull/1149#issuecomment-670532633
Thanks the review @bharatviswa504, I updated the patch. See my question
about the tests, I am open to do anything, just let me know what do you suggest.
@arp7 Do you hav
elek commented on pull request #1149:
URL: https://github.com/apache/hadoop-ozone/pull/1149#issuecomment-668600956
@arp7 @bharatviswa504
Are you OK with this approach?
This is an automated message from the Apache Git
elek commented on pull request #1149:
URL: https://github.com/apache/hadoop-ozone/pull/1149#issuecomment-66619
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub an
elek commented on pull request #1149:
URL: https://github.com/apache/hadoop-ozone/pull/1149#issuecomment-665505093
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub an
elek commented on pull request #1149:
URL: https://github.com/apache/hadoop-ozone/pull/1149#issuecomment-664814018
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub an
elek commented on pull request #1149:
URL: https://github.com/apache/hadoop-ozone/pull/1149#issuecomment-662362144
Based on the discussion from the last Community meeting, I reverted the
modification related to the o3fs:// and ofs://
Now this patch modifies only the behavior of the `
elek commented on pull request #1149:
URL: https://github.com/apache/hadoop-ozone/pull/1149#issuecomment-660937779
> The client specifies different configurations to access two clusters (each
with only one service id), e.g., DR(distcp). If we don't require explicit om
service id in the uri
elek commented on pull request #1149:
URL: https://github.com/apache/hadoop-ozone/pull/1149#issuecomment-657024565
Thanks to explain it. I understand why do you think implicit defaultFs can
be dangerous. On the other hand (as many other dangerous feature) it provides
additional flexibility
elek commented on pull request #1149:
URL: https://github.com/apache/hadoop-ozone/pull/1149#issuecomment-656112630
> We want to support client-less config of HA eventually (using DNS for
example). In that case we cannot look at the client side configs to know how
many clusters/services the
elek commented on pull request #1149:
URL: https://github.com/apache/hadoop-ozone/pull/1149#issuecomment-655684609
> If the user has config of the remote and local cluster, mistakenly he is
using remote cluster config when running commands
If the user has both remote and local it mea
14 matches
Mail list logo
