hadoop-common-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Konstantin Shvachko <shv.had...@gmail.com>
Subject Re: [VOTE] Merging branch HDFS-7240 to trunk
Date Sun, 18 Mar 2018 20:45:57 GMT
The proposal to add it as a subproject of Hadoop makes sense to me. Thank
you Owen.
I am glad to have a path for scaling HDFS further, especially as it enters
areas like IoT and self-driving cars, where storage requirements are huge.

I am not very fond of the name HDSL, though. "Storage Layer" sounds too
generic.
May be something more descriptive, like HDDS / HDSS (Hadoop Dynamically
Distributed/Scaling Storage).
We can discuss this in the jira HDFS-10419.

Thanks,
--Konstantin

On Fri, Mar 16, 2018 at 3:17 PM, Sanjay Radia <sanjay@hortonworks.com>
wrote:

> Owen,
> Thanks for your proposal.
> While I would have prefered to have HDSL in HDFS and also to be part
> of Hadoop releases  for the reasons stated earlier in this thread,
> I am willing to accept your proposal as a compromise to move this forward.
>
> Jitendra, Anu, Daryn, Andrew, Konstantine your thoughts?
>
> Thanks
>
> Sanjay
>
>
> On Mar 14, 2018, at 1:50 PM, Owen O'Malley <owen.omalley@gmail.com<mailto:
> owen.omalley@gmail.com>> wrote:
>
> This discussion seems to have died down coming closer consensus without a
> resolution.
>
> I'd like to propose the following compromise:
>
> * HDSL become a subproject of Hadoop.
> * HDSL will release separately from Hadoop. Hadoop releases will not
> contain HDSL and vice versa.
> * HDSL will get its own jira instance so that the release tags stay
> separate.
> * On trunk (as opposed to release branches) HDSL will be a separate module
> in Hadoop's source tree. This will enable the HDSL to work on their trunk
> and the Hadoop trunk without making releases for every change.
> * Hadoop's trunk will only build HDSL if a non-default profile is enabled.
> * When Hadoop creates a release branch, the RM will delete the HDSL module
> from the branch.
> * HDSL will have their own Yetus checks and won't cause failures in the
> Hadoop patch check.
>
> I think this accomplishes most of the goals of encouraging HDSL development
> while minimizing the potential for disruption of HDFS development.
>
> Thoughts? Andrew, Jitendra, & Sanjay?
>
> Thanks,
>   Owen
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message