[
https://issues.apache.org/jira/browse/STORM-876?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14988183#comment-14988183
]
ASF GitHub Bot commented on STORM-876:
--------------------------------------
Github user ptgoetz commented on the pull request:
https://github.com/apache/storm/pull/845#issuecomment-153497694
@revans2
>I know you want to be careful about what gets merged in, and if you insist
we will go through the IP clearance process, but if we can avoid it I really
would prefer to do so. We have not had any issues in the past with large
commits, like when we contributed the security code to storm which followed
essentially the same process as this code. On my end it is probably going to
take longer than the 72 hour waiting period to track down the right people to
get signatures and they will all ask me why we have to do this when my team has
blanket approval to contribute to storm.
>Like I said if you insist on getting IP clearance we will do it, but all
it is just going to do is add more pain for me which I really would like to
avoid if I can.
My apologies for seeming to come out of the blue on this, it’s not my
intention to put up roadblocks or delay anything. Rather, I’m trying to make
sure _**we, the PMC**_ do a better job of complying with ASF policy. It’s
become clear to me that there were a number of cases in the past where we did
not properly adhere to the IP Clearance policy. A lot of that stems from a lack
of knowledge on my part and others’ as to when IP Clearance is required. I’m
trying to correct that going forward.
Admittedly, the paragraph regarding IP Clearance is vague. Here are a few
points about the pull request that triggered the “IP Clearance flag” in my head
(please correct me if I’m wrong about anything):
* Was the code developed in the open, using ASF infrastructure? (No, it was
developed internally at Yahoo, even though the intent was to eventually
contribute it to the community).
* Was the Apache community aware of its existence from inception, or early
on, such that it could contribute to it’s development? (No, see previous point.
Also, the initial JIRA stated that it was under development internally at
Yahoo.)
* Is the commit history intact such that all contributors can be
identified? (No, all commits are by one individual, and the initial commit
appears to be an import of an existing codebase that might have involved other
contributors.)
Please don’t take any of the above as criticisms, I’m just pointing out
what triggered IP clearance consideration in my head.
If all the contributors involved are covered either by a CCLA or an ICLA, I
think all we would need is a software grant. I can do the rest of the work, and
the code review can certainly continue.
> Dist Cache: Basic Functionality
> -------------------------------
>
> Key: STORM-876
> URL: https://issues.apache.org/jira/browse/STORM-876
> Project: Apache Storm
> Issue Type: Improvement
> Components: storm-core
> Reporter: Robert Joseph Evans
> Assignee: Robert Joseph Evans
> Attachments: DISTCACHE.md, DistributedCacheDesignDocument.pdf
>
>
> Basic functionality for the Dist Cache feature.
> As part of this a new API should be added to support uploading and
> downloading dist cache items. storm-core.ser, storm-conf.ser and storm.jar
> should be written into the blob store instead of residing locally. We need a
> default implementation of the blob store that does essentially what nimbus
> currently does and does not need anything extra. But having an HDFS backend
> too would be great for scalability and HA.
> The supervisor should provide a way to download and manage these blobs and
> provide a working directory for the worker process with symlinks to the
> blobs. It should also allow the blobs to be updated and switch the symlink
> atomically to point to the new blob once it is downloaded.
> All of this is already done by code internal to Yahoo! we are in the process
> of getting it ready to push back to open source shortly.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
