[jira] [Comment Edited] (HDFS-13522) RBF: Support observer node from Router-Based Federation
[
https://issues.apache.org/jira/browse/HDFS-13522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17573704#comment-17573704
]
zhengchenyu edited comment on HDFS-13522 at 8/1/22 11:34 AM:
-
[~xuzq_zander]
Hi, the use case about design A is very rare indeed. But Design A also have
advantage.
(1) More flexible
Client could set their msync period time by itself.
Example: In our cluster, one name service, some special user detect hdfs file
is created periodically, may need high time precision, means more frequent
msync.(Though I am oppose to this way).
(2) Save msync
I think there is no need to call msync periodically for most HIVE, MR
application. Design A will save more msync than Design B。
I agree [~xuzq_zander] 's suggestion that focus on Design B first, add Design A
as a bonus item. It is no easy to review both Design A and Design B.
Could we only complete Design B in this issue? [~omalley] [~elgoiri]
[~simbadzina]
was (Author: zhengchenyu):
[~xuzq_zander]
Hi, the use case about design A is very rare indeed. But Design A also have
advantage.
(1) More flexible
Client could set their msync period time by itself.
Example: In our cluster, one name service, some special user detect hdfs file
is created periodically, may need high time precision, means more frequent
msync.(Though I am oppose to this way).
(2) Save msync
I think there is no need to call msync periodically for most HIVE, MR
application. Design A will save more msync than Design B。
I agree [~xuzq_zander] 's suggestion that focus on Design B first, add Design A
as a bonus item. It is no easy to review both Design A and Design B.
Could we only complete Design B in this issue? [~omalley] [~elgoiri]
> RBF: Support observer node from Router-Based Federation
> ---
>
> Key: HDFS-13522
> URL: https://issues.apache.org/jira/browse/HDFS-13522
> Project: Hadoop HDFS
> Issue Type: Sub-task
> Components: federation, namenode
>Reporter: Erik Krogen
>Assignee: Simbarashe Dzinamarira
>Priority: Major
> Labels: pull-request-available
> Attachments: HDFS-13522.001.patch, HDFS-13522.002.patch,
> HDFS-13522_WIP.patch, RBF_ Observer support.pdf, Router+Observer RPC
> clogging.png, ShortTerm-Routers+Observer.png,
> observer_reads_in_rbf_proposal_simbadzina_v1.pdf,
> observer_reads_in_rbf_proposal_simbadzina_v2.pdf
>
> Time Spent: 20h 50m
> Remaining Estimate: 0h
>
> Changes will need to occur to the router to support the new observer node.
> One such change will be to make the router understand the observer state,
> e.g. {{FederationNamenodeServiceState}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org
[jira] [Comment Edited] (HDFS-13522) RBF: Support observer node from Router-Based Federation
[
https://issues.apache.org/jira/browse/HDFS-13522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17573707#comment-17573707
]
zhengchenyu edited comment on HDFS-13522 at 8/1/22 11:32 AM:
-
[~xkrogen] [~xuzq_zander] [~simbadzina] For I know, Design A is not implemented
in all PR.
For Design A, there is no need to propagate all namespace's state ids. We can
propagate by client's demand. I think we need a whole implement and document,
then continue to discuss. I have a draft which is combination of Design A and
B. If someone are interested in Design A, can you help review this draft
[https://github.com/zhengchenyu/hadoop/commit/a47ae882943f090836a801cf758761c5b970d813.]
was (Author: zhengchenyu):
[~xkrogen] [~xuzq_zander] [~simbadzina] For I know, Design A is not implemented
in all PR.
For Design A, there is no need to propagate all namespace's state ids. We can
propagate by client's demand. I think we need a whole implement and document,
then continue to discuss. I have a draft which is combination of Design A and
B. If someone are interested in Design A, can you help review this draft
[https://github.com/zhengchenyu/hadoop/commit/a47ae882943f090836a801cf758761c5b970d813.]
> RBF: Support observer node from Router-Based Federation
> ---
>
> Key: HDFS-13522
> URL: https://issues.apache.org/jira/browse/HDFS-13522
> Project: Hadoop HDFS
> Issue Type: Sub-task
> Components: federation, namenode
>Reporter: Erik Krogen
>Assignee: Simbarashe Dzinamarira
>Priority: Major
> Labels: pull-request-available
> Attachments: HDFS-13522.001.patch, HDFS-13522.002.patch,
> HDFS-13522_WIP.patch, RBF_ Observer support.pdf, Router+Observer RPC
> clogging.png, ShortTerm-Routers+Observer.png,
> observer_reads_in_rbf_proposal_simbadzina_v1.pdf,
> observer_reads_in_rbf_proposal_simbadzina_v2.pdf
>
> Time Spent: 20h 50m
> Remaining Estimate: 0h
>
> Changes will need to occur to the router to support the new observer node.
> One such change will be to make the router understand the observer state,
> e.g. {{FederationNamenodeServiceState}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org
[jira] [Comment Edited] (HDFS-13522) RBF: Support observer node from Router-Based Federation
[
https://issues.apache.org/jira/browse/HDFS-13522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17573704#comment-17573704
]
zhengchenyu edited comment on HDFS-13522 at 8/1/22 11:26 AM:
-
[~xuzq_zander]
Hi, the use case about design A is very rare indeed. But Design A also have
advantage.
(1) More flexible
Client could set their msync period time by itself.
Example: In our cluster, one name service, some special user detect hdfs file
is created periodically, may need high time precision, means more frequent
msync.(Though I am oppose to this way).
(2) Save msync
I think there is no need to call msync periodically for most HIVE, MR
application. Design A will save more msync than Design B。
I agree [~xuzq_zander] 's suggestion that focus on Design B first, add Design A
as a bonus item. It is no easy to review both Design A and Design B.
Could we only complete Design B in this issue? [~omalley] [~elgoiri]
was (Author: zhengchenyu):
[~xuzq_zander]
Hi, the use case about design A is very rare indeed. But Design A also have
advantage.
(1) More flexible
Client could set their msync period time by itself.
Example: In our cluster, one name service, some special user detect hdfs file
is created periodically, may need high time precision, means more frequent
msync.(Though I am oppose to this way).
(2) Save msync
I think there is no need to call msync periodically for most HIVE, MR
application. Design A will save more msync than Design B。
I agree [~xuzq_zander] 's suggestion that focus on Design B first, add Design A
as a bonus item. It is no easy to review both Design A and Design B.
Could we only complete Design B in this issue?
> RBF: Support observer node from Router-Based Federation
> ---
>
> Key: HDFS-13522
> URL: https://issues.apache.org/jira/browse/HDFS-13522
> Project: Hadoop HDFS
> Issue Type: Sub-task
> Components: federation, namenode
>Reporter: Erik Krogen
>Assignee: Simbarashe Dzinamarira
>Priority: Major
> Labels: pull-request-available
> Attachments: HDFS-13522.001.patch, HDFS-13522.002.patch,
> HDFS-13522_WIP.patch, HDFS-13522_proposal_zhengchenyu_v1.pdf, RBF_ Observer
> support.pdf, Router+Observer RPC clogging.png,
> ShortTerm-Routers+Observer.png,
> observer_reads_in_rbf_proposal_simbadzina_v1.pdf,
> observer_reads_in_rbf_proposal_simbadzina_v2.pdf
>
> Time Spent: 20h 50m
> Remaining Estimate: 0h
>
> Changes will need to occur to the router to support the new observer node.
> One such change will be to make the router understand the observer state,
> e.g. {{FederationNamenodeServiceState}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org
[jira] [Comment Edited] (HDFS-13522) RBF: Support observer node from Router-Based Federation
[
https://issues.apache.org/jira/browse/HDFS-13522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17573704#comment-17573704
]
zhengchenyu edited comment on HDFS-13522 at 8/1/22 11:24 AM:
-
[~xuzq_zander]
Hi, the use case about design A is very rare indeed. But Design A also have
advantage.
(1) More flexible
Client could set their msync period time by itself.
Example: In our cluster, one name service, some special user detect hdfs file
is created periodically, may need high time precision, means more frequent
msync.(Though I am oppose to this way).
(2) Save msync
I think there is no need to call msync periodically for most HIVE, MR
application. Design A will save more msync than Design B。
I agree [~xuzq_zander] 's suggestion that focus on Design B first, add Design A
as a bonus item. It is no easy to review both Design A and Design B.
Could we only complete Design B in this issue?
was (Author: zhengchenyu):
[~xuzq_zander]
Hi, the use case about design A is very rare indeed. But Design A also have
advantage.
(1) More flexible
Client could set their msync period time by itself.
Example: In our cluster, one name service, some special user detect hdfs file
is created periodically, may need high time precision, means more frequent
msync.(Though I am oppose to this way).
(2) Save msync
I think there is no need to call msync periodically for most HIVE, MR
application. Design A will save more msync than Design B。
I agree your suggestion that focus on Design B first, add Design A as a bonus
item. It is no easy to review both Design A and Design B.
> RBF: Support observer node from Router-Based Federation
> ---
>
> Key: HDFS-13522
> URL: https://issues.apache.org/jira/browse/HDFS-13522
> Project: Hadoop HDFS
> Issue Type: Sub-task
> Components: federation, namenode
>Reporter: Erik Krogen
>Assignee: Simbarashe Dzinamarira
>Priority: Major
> Labels: pull-request-available
> Attachments: HDFS-13522.001.patch, HDFS-13522.002.patch,
> HDFS-13522_WIP.patch, HDFS-13522_proposal_zhengchenyu_v1.pdf, RBF_ Observer
> support.pdf, Router+Observer RPC clogging.png,
> ShortTerm-Routers+Observer.png,
> observer_reads_in_rbf_proposal_simbadzina_v1.pdf,
> observer_reads_in_rbf_proposal_simbadzina_v2.pdf
>
> Time Spent: 20h 50m
> Remaining Estimate: 0h
>
> Changes will need to occur to the router to support the new observer node.
> One such change will be to make the router understand the observer state,
> e.g. {{FederationNamenodeServiceState}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org
[jira] [Comment Edited] (HDFS-13522) RBF: Support observer node from Router-Based Federation
[
https://issues.apache.org/jira/browse/HDFS-13522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17572562#comment-17572562
]
Erik Krogen edited comment on HDFS-13522 at 7/28/22 5:01 PM:
-
Thanks for sharing [~xuzq_zander], very interesting!
{quote}
I just feel that Design A will caused Client carries a lot of useless NS TxIds
to RBF, because at most scenarios, RBF just proxy request from one client to
one downstream NS. And as the underlying NS increases, client will carries more
and more useless NS TxIds to RBF.
{quote}
[~simbadzina] -- I haven't looked carefully at the design but are we currently
including all downstream NS in the header regardless of whether or not a client
accesses it? It's a good point that ideally we would only include the state for
NS which are actually accessed (even if there are only single-digit NS, still
there's no point carrying the extra state if it is not used).
was (Author: xkrogen):
Thanks for sharing [~xuzq_zander], very interesting!
{quote}
I just feel that Design A will caused Client carries a lot of useless NS TxIds
to RBF, because at most scenarios, RBF just proxy request from one client to
one downstream NS. And as the underlying NS increases, client will carries more
and more useless NS TxIds to RBF.
{quote}
[~simbadzina] -- I haven't looked carefully at the design but are we currently
including all downstream NS in the header regardless of whether or not a client
accesses it? It's a good point that ideally we would only include the state for
NS which are actually accessed.
> RBF: Support observer node from Router-Based Federation
> ---
>
> Key: HDFS-13522
> URL: https://issues.apache.org/jira/browse/HDFS-13522
> Project: Hadoop HDFS
> Issue Type: Sub-task
> Components: federation, namenode
>Reporter: Erik Krogen
>Assignee: Simbarashe Dzinamarira
>Priority: Major
> Labels: pull-request-available
> Attachments: HDFS-13522.001.patch, HDFS-13522.002.patch,
> HDFS-13522_WIP.patch, HDFS-13522_proposal_zhengchenyu_v1.pdf, RBF_ Observer
> support.pdf, Router+Observer RPC clogging.png,
> ShortTerm-Routers+Observer.png,
> observer_reads_in_rbf_proposal_simbadzina_v1.pdf,
> observer_reads_in_rbf_proposal_simbadzina_v2.pdf
>
> Time Spent: 20h 50m
> Remaining Estimate: 0h
>
> Changes will need to occur to the router to support the new observer node.
> One such change will be to make the router understand the observer state,
> e.g. {{FederationNamenodeServiceState}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org
[jira] [Comment Edited] (HDFS-13522) RBF: Support observer node from Router-Based Federation
[
https://issues.apache.org/jira/browse/HDFS-13522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17572017#comment-17572017
]
Erik Krogen edited comment on HDFS-13522 at 7/27/22 4:27 PM:
-
[~xuzq_zander] I'm curious to learn more about your use case. I would assume
that if your namespaces are so finely segmented that you have 100+, then each
one would be small enough so as to not require the use of CRS. Are you really
running 100+ namespaces, each of which includes Observer Nodes?
I am still in support of a hybrid Design A + B in the interest of supporting
both old and new clients, but I am curious about the situation that would lead
to the issue of very large RPC headers as discussed above.
was (Author: xkrogen):
[~xuzq_zander] I'm curious to learn more about your use case. I would assume
that if your namespaces are so finely segmented that you have 100+, then each
one would be small enough so as to not require the use of CRS. Are you really
running 100+ namespaces, each of which includes Observer Nodes?
> RBF: Support observer node from Router-Based Federation
> ---
>
> Key: HDFS-13522
> URL: https://issues.apache.org/jira/browse/HDFS-13522
> Project: Hadoop HDFS
> Issue Type: Sub-task
> Components: federation, namenode
>Reporter: Erik Krogen
>Assignee: Simbarashe Dzinamarira
>Priority: Major
> Labels: pull-request-available
> Attachments: HDFS-13522.001.patch, HDFS-13522.002.patch,
> HDFS-13522_WIP.patch, HDFS-13522_proposal_zhengchenyu_v1.pdf, RBF_ Observer
> support.pdf, Router+Observer RPC clogging.png,
> ShortTerm-Routers+Observer.png,
> observer_reads_in_rbf_proposal_simbadzina_v1.pdf,
> observer_reads_in_rbf_proposal_simbadzina_v2.pdf
>
> Time Spent: 20h
> Remaining Estimate: 0h
>
> Changes will need to occur to the router to support the new observer node.
> One such change will be to make the router understand the observer state,
> e.g. {{FederationNamenodeServiceState}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org
[jira] [Comment Edited] (HDFS-13522) RBF: Support observer node from Router-Based Federation
[
https://issues.apache.org/jira/browse/HDFS-13522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17571703#comment-17571703
]
zhengchenyu edited comment on HDFS-13522 at 7/27/22 2:45 AM:
-
[~simbadzina] I also agree the *combination of both Design A and B.* Most user
use plan B, some special user could choose plan A by their demand.
[~simbadzina] [~xuzq_zander] what's your email of slack? Or we can gather in
hdfs channel firstly.
was (Author: zhengchenyu):
[~simbadzina] I also agree the *combination of both Design A and B.* Most user
use plan B, some special user could choose plan A by their demand. **
[~simbadzina] [~xuzq_zander] what's your email of slack? Or we can gather in
hdfs channel fisrtly.
> RBF: Support observer node from Router-Based Federation
> ---
>
> Key: HDFS-13522
> URL: https://issues.apache.org/jira/browse/HDFS-13522
> Project: Hadoop HDFS
> Issue Type: Sub-task
> Components: federation, namenode
>Reporter: Erik Krogen
>Assignee: Simbarashe Dzinamarira
>Priority: Major
> Labels: pull-request-available
> Attachments: HDFS-13522.001.patch, HDFS-13522.002.patch,
> HDFS-13522_WIP.patch, HDFS-13522_proposal_zhengchenyu_v1.pdf, RBF_ Observer
> support.pdf, Router+Observer RPC clogging.png,
> ShortTerm-Routers+Observer.png,
> observer_reads_in_rbf_proposal_simbadzina_v1.pdf,
> observer_reads_in_rbf_proposal_simbadzina_v2.pdf
>
> Time Spent: 20h
> Remaining Estimate: 0h
>
> Changes will need to occur to the router to support the new observer node.
> One such change will be to make the router understand the observer state,
> e.g. {{FederationNamenodeServiceState}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org
[jira] [Comment Edited] (HDFS-13522) RBF: Support observer node from Router-Based Federation
[
https://issues.apache.org/jira/browse/HDFS-13522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17571564#comment-17571564
]
Simbarashe Dzinamarira edited comment on HDFS-13522 at 7/26/22 6:01 PM:
Thanks [~xuzq_zander] for listing the considerations.
When there are 100+ nameservices then the large RPC header would indeed be a
problem. However, for a few nameservices, I've assumed the larger RPC header is
a better tradeoff that the extra msync call for strong consistency.
*We can do a combination of both Design A and B.*
So Design B (always msync) would be the baseline which doesn't requirement any
client changes. Then if the number of nameservices is under a certain
threshold, the router can send extra information in the header. An old client
ignores this information, which results in Design B behavior, but a new client
transparently forwards this back to the router allowing the router to avoid the
msync (Design A).
My implementation already does follow Design B to support old clients, and a
threshold can be easily added so that Design A is only used in situations where
there aren't too many namespaces.
[~zhengchenyu] can you share how I can access the slack channel. Is there a
slack instance of Apache?
was (Author: simbadzina):
Thanks [~xuzq_zander] for listing the considerations.
When there are 100+ nameservices then the large RPC header would indeed be a
problem. However, for a few nameservices, I've assumed the larger RPC header is
a better tradeoff that the extra msync call for strong consistency.
We can do a combination of both Design A and B.
So Design B (always msync) would be the baseline which doesn't requirement any
client changes. Then if the number of nameservices is under a certain
threshold, the router can send extra information in the header. An old client
ignores this information, which results in Design B behavior, but a new client
transparently forwards this back to the router allowing the router to avoid the
msync (Design A).
My implementation already does follow Design B to support old clients, and a
threshold can be easily added so that Design A is only used in situations where
there aren't too many namespaces.
[~zhengchenyu] can you share how I can access the slack channel. Is there a
slack instance of Apache?
> RBF: Support observer node from Router-Based Federation
> ---
>
> Key: HDFS-13522
> URL: https://issues.apache.org/jira/browse/HDFS-13522
> Project: Hadoop HDFS
> Issue Type: Sub-task
> Components: federation, namenode
>Reporter: Erik Krogen
>Assignee: Simbarashe Dzinamarira
>Priority: Major
> Labels: pull-request-available
> Attachments: HDFS-13522.001.patch, HDFS-13522.002.patch,
> HDFS-13522_WIP.patch, HDFS-13522_proposal_zhengchenyu_v1.pdf, RBF_ Observer
> support.pdf, Router+Observer RPC clogging.png,
> ShortTerm-Routers+Observer.png,
> observer_reads_in_rbf_proposal_simbadzina_v1.pdf,
> observer_reads_in_rbf_proposal_simbadzina_v2.pdf
>
> Time Spent: 20h
> Remaining Estimate: 0h
>
> Changes will need to occur to the router to support the new observer node.
> One such change will be to make the router understand the observer state,
> e.g. {{FederationNamenodeServiceState}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org
[jira] [Comment Edited] (HDFS-13522) RBF: Support observer node from Router-Based Federation
[
https://issues.apache.org/jira/browse/HDFS-13522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17571186#comment-17571186
]
zhengchenyu edited comment on HDFS-13522 at 7/26/22 4:16 AM:
-
[~simbadzina]
In your v2 document, maybe no detailed implement and structure. I still don't
know how to implement in your design. What's you choice about design A and
design B? (Note: The last picture is not clear in google document.)
In my design, key is nameserviceId in router mode, key is clientid+callid in
cilent mode. In my proposal, mainly describe client mode. About switches
between routers, there is no problem in my proposal in client mode. because
client carry real state id.
I think we need more discuss about this. I create a channel named ''hdfs-13522"
on slack. Let us discuss on this channel for more efficient communication, and
continue to meeting. [~simbadzina] [~xuzq_zander]
was (Author: zhengchenyu):
[~simbadzina]
In your v2 document, maybe no detailed implement and structure. I still don't
know how to implement in your design. (Note: The last picture is not clear in
google document.)
In my design, key is nameserviceId in router mode, key is clientid+callid in
cilent mode. In my proposal, mainly describe client mode. About switches
between routers, there is no problem in my proposal in client mode. because
client carry real state id.
I think we need more discuss about this. I create a channel named ''hdfs-13522"
on slack. Let us discuss on this channel for more efficient communication, and
continue to meeting. [~simbadzina] [~xuzq_zander]
> RBF: Support observer node from Router-Based Federation
> ---
>
> Key: HDFS-13522
> URL: https://issues.apache.org/jira/browse/HDFS-13522
> Project: Hadoop HDFS
> Issue Type: Sub-task
> Components: federation, namenode
>Reporter: Erik Krogen
>Assignee: Simbarashe Dzinamarira
>Priority: Major
> Labels: pull-request-available
> Attachments: HDFS-13522.001.patch, HDFS-13522.002.patch,
> HDFS-13522_WIP.patch, HDFS-13522_proposal_zhengchenyu_v1.pdf, RBF_ Observer
> support.pdf, Router+Observer RPC clogging.png,
> ShortTerm-Routers+Observer.png,
> observer_reads_in_rbf_proposal_simbadzina_v1.pdf,
> observer_reads_in_rbf_proposal_simbadzina_v2.pdf
>
> Time Spent: 20h
> Remaining Estimate: 0h
>
> Changes will need to occur to the router to support the new observer node.
> One such change will be to make the router understand the observer state,
> e.g. {{FederationNamenodeServiceState}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org
[jira] [Comment Edited] (HDFS-13522) RBF: Support observer node from Router-Based Federation
[
https://issues.apache.org/jira/browse/HDFS-13522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17571186#comment-17571186
]
zhengchenyu edited comment on HDFS-13522 at 7/26/22 4:15 AM:
-
[~simbadzina]
In your v2 document, maybe no detailed implement and structure. I still don't
know how to implement in your design. (Note: The last picture is not clear in
google document.)
In my design, key is nameserviceId in router mode, key is clientid+callid in
cilent mode. In my proposal, mainly describe client mode. About switches
between routers, there is no problem in my proposal in client mode. because
client carry real state id.
I think we need more discuss about this. I create a channel named ''hdfs-13522"
on slack. Let us discuss on this channel for more efficient communication, and
continue to meeting. [~simbadzina] [~xuzq_zander]
was (Author: zhengchenyu):
[~simbadzina]
In your v2 document, maybe no implement and structure.
In my design, key is nameserviceId in router mode, key is clientid+callid in
cilent mode. In my proposal, mainly describe client mode. About switches
between routers, there is no problem in my proposal in client mode. because
client carry real state id.
I think we need more discuss about this. I create a channel named ''hdfs-13522"
on slack. Let us discuss on this channel for more efficient communication, and
continue to meeting. [~simbadzina] [~xuzq_zander]
> RBF: Support observer node from Router-Based Federation
> ---
>
> Key: HDFS-13522
> URL: https://issues.apache.org/jira/browse/HDFS-13522
> Project: Hadoop HDFS
> Issue Type: Sub-task
> Components: federation, namenode
>Reporter: Erik Krogen
>Assignee: Simbarashe Dzinamarira
>Priority: Major
> Labels: pull-request-available
> Attachments: HDFS-13522.001.patch, HDFS-13522.002.patch,
> HDFS-13522_WIP.patch, HDFS-13522_proposal_zhengchenyu_v1.pdf, RBF_ Observer
> support.pdf, Router+Observer RPC clogging.png,
> ShortTerm-Routers+Observer.png,
> observer_reads_in_rbf_proposal_simbadzina_v1.pdf,
> observer_reads_in_rbf_proposal_simbadzina_v2.pdf
>
> Time Spent: 20h
> Remaining Estimate: 0h
>
> Changes will need to occur to the router to support the new observer node.
> One such change will be to make the router understand the observer state,
> e.g. {{FederationNamenodeServiceState}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org
[jira] [Comment Edited] (HDFS-13522) RBF: Support observer node from Router-Based Federation
[
https://issues.apache.org/jira/browse/HDFS-13522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17571186#comment-17571186
]
zhengchenyu edited comment on HDFS-13522 at 7/26/22 4:11 AM:
-
[~simbadzina]
In your v2 document, maybe no implement and structure.
In my design, key is nameserviceId in router mode, key is clientid+callid in
cilent mode. In my proposal, mainly describe client mode. About switches
between routers, there is no problem in my proposal in client mode. because
client carry real state id.
I think we need more discuss about this. I create a channel named ''hdfs-13522"
on slack. Let us discuss on this channel for more efficient communication, and
continue to meeting. [~simbadzina] [~xuzq_zander]
was (Author: zhengchenyu):
[~simbadzina]
In your v2 document, maybe no implement and structure.
In my design, key is nameserviceId in router mode, key is clientid+callid in
cilent mode. In my proposal, mainly describe client mode. About switches
between routers, there is no problem in my proposal in client mode. because
client carry real state id.
I think we need more discuss about this. I create a channel named ''hdfs-13522"
in slack. Let us discuss on this channel for more efficient communication, and
continue to meeting. [~simbadzina] [~xuzq_zander]
> RBF: Support observer node from Router-Based Federation
> ---
>
> Key: HDFS-13522
> URL: https://issues.apache.org/jira/browse/HDFS-13522
> Project: Hadoop HDFS
> Issue Type: Sub-task
> Components: federation, namenode
>Reporter: Erik Krogen
>Assignee: Simbarashe Dzinamarira
>Priority: Major
> Labels: pull-request-available
> Attachments: HDFS-13522.001.patch, HDFS-13522.002.patch,
> HDFS-13522_WIP.patch, HDFS-13522_proposal_zhengchenyu_v1.pdf, RBF_ Observer
> support.pdf, Router+Observer RPC clogging.png,
> ShortTerm-Routers+Observer.png,
> observer_reads_in_rbf_proposal_simbadzina_v1.pdf,
> observer_reads_in_rbf_proposal_simbadzina_v2.pdf
>
> Time Spent: 20h
> Remaining Estimate: 0h
>
> Changes will need to occur to the router to support the new observer node.
> One such change will be to make the router understand the observer state,
> e.g. {{FederationNamenodeServiceState}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org
[jira] [Comment Edited] (HDFS-13522) RBF: Support observer node from Router-Based Federation
[
https://issues.apache.org/jira/browse/HDFS-13522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17571186#comment-17571186
]
zhengchenyu edited comment on HDFS-13522 at 7/26/22 4:10 AM:
-
[~simbadzina]
In your v2 document, maybe no implement and structure.
In my design, key is nameserviceId in router mode, key is clientid+callid in
cilent mode. In my proposal, mainly describe client mode. About switches
between routers, there is no problem in my proposal in client mode. because
client carry real state id.
I think we need more discuss about this. I create a channel named ''hdfs-13522"
in slack. Let us discuss on this channel for more efficient communication, and
continue to meeting. [~simbadzina] [~xuzq_zander]
was (Author: zhengchenyu):
[~simbadzina]
In your v2 document, maybe no implement and structure.
In my design, key is nameserviceId in router mode, key is clientid+callid in
cilent mode. In my proposal, mainly describe client mode. About switches
between routers, there is no problem in my proposal in client mode. because
client carry real state id.
I think we need more discuss about this. I create a channel named
''hdfs-13522". Let us discuss on this channel for more efficient communication,
and continue to meeting. [~simbadzina] [~xuzq_zander]
> RBF: Support observer node from Router-Based Federation
> ---
>
> Key: HDFS-13522
> URL: https://issues.apache.org/jira/browse/HDFS-13522
> Project: Hadoop HDFS
> Issue Type: Sub-task
> Components: federation, namenode
>Reporter: Erik Krogen
>Assignee: Simbarashe Dzinamarira
>Priority: Major
> Labels: pull-request-available
> Attachments: HDFS-13522.001.patch, HDFS-13522.002.patch,
> HDFS-13522_WIP.patch, HDFS-13522_proposal_zhengchenyu_v1.pdf, RBF_ Observer
> support.pdf, Router+Observer RPC clogging.png,
> ShortTerm-Routers+Observer.png,
> observer_reads_in_rbf_proposal_simbadzina_v1.pdf,
> observer_reads_in_rbf_proposal_simbadzina_v2.pdf
>
> Time Spent: 20h
> Remaining Estimate: 0h
>
> Changes will need to occur to the router to support the new observer node.
> One such change will be to make the router understand the observer state,
> e.g. {{FederationNamenodeServiceState}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org
[jira] [Comment Edited] (HDFS-13522) RBF: Support observer node from Router-Based Federation
[
https://issues.apache.org/jira/browse/HDFS-13522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17571138#comment-17571138
]
Simbarashe Dzinamarira edited comment on HDFS-13522 at 7/25/22 11:58 PM:
-
[~zhengchenyu] I've scanned through your proposal.
# When using RBF, clients do not need to know about all nameservices behind
the routers. The NameserviceStateIdContextProto is a good idea (similar to the
map in my proposal) but the information in it should originate in the router
versus the client.
# Maintaining the StateIdCache for each "client+callId" key builds up a lot of
state in the router and a lot of it is very similar. In my proposal the keys
for the extra map I add are the nameserviceIDs.
# It is not clear to me how you handle the case in which a client switches
between routers.
was (Author: simbadzina):
[~zhengchenyu] I've scanned through your proposal.
# When using RBF, clients do not need to know about all nameservices behind
the routers. The NameserviceStateIdContextProto is a good idea (similar to the
map in my proposal) but the information in it should originate in the router
versus the client.
# Maintaining the StateIdCache for each "client+callId" key builds up a lot of
state in the router and a lot of it is very similar. In my proposal the keys
for the extra map I add are the nameserviceIDs.
# It is not clear to me how you handle the case where a client switches
between routers.
> RBF: Support observer node from Router-Based Federation
> ---
>
> Key: HDFS-13522
> URL: https://issues.apache.org/jira/browse/HDFS-13522
> Project: Hadoop HDFS
> Issue Type: Sub-task
> Components: federation, namenode
>Reporter: Erik Krogen
>Assignee: Simbarashe Dzinamarira
>Priority: Major
> Labels: pull-request-available
> Attachments: HDFS-13522.001.patch, HDFS-13522.002.patch,
> HDFS-13522_WIP.patch, HDFS-13522_proposal_zhengchenyu_v1.pdf, RBF_ Observer
> support.pdf, Router+Observer RPC clogging.png,
> ShortTerm-Routers+Observer.png,
> observer_reads_in_rbf_proposal_simbadzina_v1.pdf,
> observer_reads_in_rbf_proposal_simbadzina_v2.pdf
>
> Time Spent: 20h
> Remaining Estimate: 0h
>
> Changes will need to occur to the router to support the new observer node.
> One such change will be to make the router understand the observer state,
> e.g. {{FederationNamenodeServiceState}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org
[jira] [Comment Edited] (HDFS-13522) RBF: Support observer node from Router-Based Federation
[
https://issues.apache.org/jira/browse/HDFS-13522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17569802#comment-17569802
]
zhengchenyu edited comment on HDFS-13522 at 7/22/22 5:11 AM:
-
[~simbadzina]
Thanks for involving me. HDFS-13522_proposal_zhengchenyu_v1.pdf is my proposal
document. Chapter 2.1 is just solution C, and describe how to carry state id in
my demo implement. Can you please review my proposal.
was (Author: zhengchenyu):
[~simbadzina]
Thanks for involving me. HDFS-13522_proposal_zhengchenyu_v1.pdf is my proposal
document. Chapter 2.1 describe how to carry state id in my demo implement. Can
you please review my proposal.
> RBF: Support observer node from Router-Based Federation
> ---
>
> Key: HDFS-13522
> URL: https://issues.apache.org/jira/browse/HDFS-13522
> Project: Hadoop HDFS
> Issue Type: Sub-task
> Components: federation, namenode
>Reporter: Erik Krogen
>Assignee: Simbarashe Dzinamarira
>Priority: Major
> Labels: pull-request-available
> Attachments: HDFS-13522.001.patch, HDFS-13522.002.patch,
> HDFS-13522_WIP.patch, HDFS-13522_proposal_zhengchenyu_v1.pdf, RBF_ Observer
> support.pdf, Router+Observer RPC clogging.png,
> ShortTerm-Routers+Observer.png,
> observer_reads_in_rbf_proposal_simbadzina_v1.pdf
>
> Time Spent: 20h
> Remaining Estimate: 0h
>
> Changes will need to occur to the router to support the new observer node.
> One such change will be to make the router understand the observer state,
> e.g. {{FederationNamenodeServiceState}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org
[jira] [Comment Edited] (HDFS-13522) RBF: Support observer node from Router-Based Federation
[
https://issues.apache.org/jira/browse/HDFS-13522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17551940#comment-17551940
]
zhengchenyu edited comment on HDFS-13522 at 6/9/22 3:52 AM:
[~simbadzina] Router does not use client's AlignmentContext, So I think
dfs.federation.router.observer.auto-msync-period must set to 0, there will be
no problem.
If this value is too big, router may not catch the latest modification. Because
Router does not use client's AlignmentContext, there is no way to make sure the
current router stat id is newer than client state id.
Maybe we need to set dfs.federation.router.observer.auto-msync-period to fixed
value '0', or note in document.
was (Author: zhengchenyu):
[~simbadzina] Router does not use client's AlignmentContext, So I think
dfs.federation.router.observer.auto-msync-period must set to 0, then there will
be no problem.
If this value is too big, router may not catch the latest modification. Because
Router does not use client's AlignmentContext, there is no way to make sure the
current router stat id is newer than client state id.
Maybe we need to set dfs.federation.router.observer.auto-msync-period to fixed
value '0', or note in document.
> RBF: Support observer node from Router-Based Federation
> ---
>
> Key: HDFS-13522
> URL: https://issues.apache.org/jira/browse/HDFS-13522
> Project: Hadoop HDFS
> Issue Type: Sub-task
> Components: federation, namenode
>Reporter: Erik Krogen
>Assignee: Simbarashe Dzinamarira
>Priority: Major
> Labels: pull-request-available
> Attachments: HDFS-13522.001.patch, HDFS-13522.002.patch,
> HDFS-13522_WIP.patch, RBF_ Observer support.pdf, Router+Observer RPC
> clogging.png, ShortTerm-Routers+Observer.png
>
> Time Spent: 10h 20m
> Remaining Estimate: 0h
>
> Changes will need to occur to the router to support the new observer node.
> One such change will be to make the router understand the observer state,
> e.g. {{FederationNamenodeServiceState}}.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org
[jira] [Comment Edited] (HDFS-13522) RBF: Support observer node from Router-Based Federation
[
https://issues.apache.org/jira/browse/HDFS-13522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17543008#comment-17543008
]
Simbarashe Dzinamarira edited comment on HDFS-13522 at 5/27/22 4:55 PM:
You are right [~zhengchenyu] , the Router does use it's own AlignmentContext.
So each client cannot configure its own requirements like the msync period.
But a client can completely opt out from performing observer reads.
was (Author: simbadzina):
You are right [~zhengchenyu] , the Router does use it's own AlignmentContext.
So each client cannot configure its own requirements like the msync period.
But a client can totally opt out from performing observer reads.
> RBF: Support observer node from Router-Based Federation
> ---
>
> Key: HDFS-13522
> URL: https://issues.apache.org/jira/browse/HDFS-13522
> Project: Hadoop HDFS
> Issue Type: Sub-task
> Components: federation, namenode
>Reporter: Erik Krogen
>Assignee: Simbarashe Dzinamarira
>Priority: Major
> Labels: pull-request-available
> Attachments: HDFS-13522.001.patch, HDFS-13522.002.patch,
> HDFS-13522_WIP.patch, RBF_ Observer support.pdf, Router+Observer RPC
> clogging.png, ShortTerm-Routers+Observer.png
>
> Time Spent: 8.5h
> Remaining Estimate: 0h
>
> Changes will need to occur to the router to support the new observer node.
> One such change will be to make the router understand the observer state,
> e.g. {{FederationNamenodeServiceState}}.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org
[jira] [Comment Edited] (HDFS-13522) RBF: Support observer node from Router-Based Federation
[
https://issues.apache.org/jira/browse/HDFS-13522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17542565#comment-17542565
]
Simbarashe Dzinamarira edited comment on HDFS-13522 at 5/26/22 4:45 PM:
Hi [~zhengchenyu]. The feature can be disabled, either at the client or in the
routers themselves.
Clients can use the property *dfs.observer.read.enable.*
Routers can use disable this using the property
*dfs.federation.router.observer.read.enable.*
In RouterStateIdContext.java, the routers pass through the client's state ID to
the namenodes.
There is a config to set the auto-msync period:
*dfs.federation.router.observer.auto-msync-period*
The patch supports multiple nameservices. In the router, the conf above can be
overridden per nameservice with
*dfs.federation.router.observer.read.enable.EXAMPLENAMESERVICE.*
was (Author: simbadzina):
Hi [~zhengchenyu]. The feature can be disabled, either at the client or in the
routers themselves.
Clients can use the property *dfs.observer.read.enable.*
Routers can use disable this using the property
*dfs.federation.router.observer.read.enable.*
In RouterStateIdContext.java, the routers pass through the client's state ID to
the namenodes.
There is a config to set the auto-msync period:
*dfs.federation.router.observer.auto-msync-period*
The patch supports multiple nameservices. In the router, the conf above can be
overridden per nameservice with
*dfs.federation.router.observer.read.enable.EXAMPLENAMESERVICE.*
> RBF: Support observer node from Router-Based Federation
> ---
>
> Key: HDFS-13522
> URL: https://issues.apache.org/jira/browse/HDFS-13522
> Project: Hadoop HDFS
> Issue Type: Sub-task
> Components: federation, namenode
>Reporter: Erik Krogen
>Assignee: Simbarashe Dzinamarira
>Priority: Major
> Labels: pull-request-available
> Attachments: HDFS-13522.001.patch, HDFS-13522.002.patch,
> HDFS-13522_WIP.patch, RBF_ Observer support.pdf, Router+Observer RPC
> clogging.png, ShortTerm-Routers+Observer.png
>
> Time Spent: 8h 10m
> Remaining Estimate: 0h
>
> Changes will need to occur to the router to support the new observer node.
> One such change will be to make the router understand the observer state,
> e.g. {{FederationNamenodeServiceState}}.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org
[jira] [Comment Edited] (HDFS-13522) RBF: Support observer node from Router-Based Federation
[
https://issues.apache.org/jira/browse/HDFS-13522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17515681#comment-17515681
]
Song Jiacheng edited comment on HDFS-13522 at 4/2/22 8:28 AM:
--
Thx,[~simbadzina]:)
How about I do not upgrade client at all, cause router manages the states to
guarantee consistency, the clients don't need to do any change.
Actually our clients are still at version 2.6. It may cost a lot to upgrade to
3.x.
was (Author: song jiacheng):
Thx,[~simbadzina]:)
How about I do not upgrade client at all, cause router manages the states to
guarantee consistency, so the clients don't need to do any change.
Actually our clients are still at version 2.6. It may cost a lot to upgrade to
3.x.
> RBF: Support observer node from Router-Based Federation
> ---
>
> Key: HDFS-13522
> URL: https://issues.apache.org/jira/browse/HDFS-13522
> Project: Hadoop HDFS
> Issue Type: Sub-task
> Components: federation, namenode
>Reporter: Erik Krogen
>Assignee: Simbarashe Dzinamarira
>Priority: Major
> Labels: pull-request-available
> Attachments: HDFS-13522.001.patch, HDFS-13522.002.patch,
> HDFS-13522_WIP.patch, RBF_ Observer support.pdf, Router+Observer RPC
> clogging.png, ShortTerm-Routers+Observer.png
>
> Time Spent: 4h 10m
> Remaining Estimate: 0h
>
> Changes will need to occur to the router to support the new observer node.
> One such change will be to make the router understand the observer state,
> e.g. {{FederationNamenodeServiceState}}.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org
[jira] [Comment Edited] (HDFS-13522) RBF: Support observer node from Router-Based Federation
[
https://issues.apache.org/jira/browse/HDFS-13522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17515681#comment-17515681
]
Song Jiacheng edited comment on HDFS-13522 at 4/1/22 7:26 AM:
--
Thx,[~simbadzina]:)
How about I do not upgrade client at all, cause router manages the states to
guarantee consistency, so the clients don't need to do any change.
Actually our clients are still at version 2.6. It may cost a lot to upgrade to
3.x.
was (Author: song jiacheng):
Thx,[~simbadzina]:)
How about I do not upgrade client at all, cause router manage the states to
guarantee consistency, so the client don't need to do any change.
Actually our clients are still at version 2.6. It may cost a lot to upgrade to
3.x.
> RBF: Support observer node from Router-Based Federation
> ---
>
> Key: HDFS-13522
> URL: https://issues.apache.org/jira/browse/HDFS-13522
> Project: Hadoop HDFS
> Issue Type: Sub-task
> Components: federation, namenode
>Reporter: Erik Krogen
>Assignee: Simbarashe Dzinamarira
>Priority: Major
> Labels: pull-request-available
> Attachments: HDFS-13522.001.patch, HDFS-13522.002.patch,
> HDFS-13522_WIP.patch, RBF_ Observer support.pdf, Router+Observer RPC
> clogging.png, ShortTerm-Routers+Observer.png
>
> Time Spent: 4h
> Remaining Estimate: 0h
>
> Changes will need to occur to the router to support the new observer node.
> One such change will be to make the router understand the observer state,
> e.g. {{FederationNamenodeServiceState}}.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org
[jira] [Comment Edited] (HDFS-13522) RBF: Support observer node from Router-Based Federation
[
https://issues.apache.org/jira/browse/HDFS-13522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17514481#comment-17514481
]
Song Jiacheng edited comment on HDFS-13522 at 3/30/22, 7:18 AM:
Hi, [~hemanthboyina] [~zhengzhuobinzzb], thx for these patches.
Is this latest patch 002 developed as the design doc? It seems that it's not
the same as the design doc, so how should I configure the client side if I use
this patch?
was (Author: song jiacheng):
Hi, [~hemanthboyina] [~zhengzhuobinzzb], thx for these patches.
Is this lastest patch 002 developed as the design doc? It seems that it's not
the same as the design doc, so how should I configure the client side if I use
this patch?
> RBF: Support observer node from Router-Based Federation
> ---
>
> Key: HDFS-13522
> URL: https://issues.apache.org/jira/browse/HDFS-13522
> Project: Hadoop HDFS
> Issue Type: Sub-task
> Components: federation, namenode
>Reporter: Erik Krogen
>Priority: Major
> Labels: pull-request-available
> Attachments: HDFS-13522.001.patch, HDFS-13522.002.patch,
> HDFS-13522_WIP.patch, RBF_ Observer support.pdf, Router+Observer RPC
> clogging.png, ShortTerm-Routers+Observer.png
>
> Time Spent: 3h 40m
> Remaining Estimate: 0h
>
> Changes will need to occur to the router to support the new observer node.
> One such change will be to make the router understand the observer state,
> e.g. {{FederationNamenodeServiceState}}.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org
