ASF GitHub Bot commented on BAHIR-122:

Github user ckadner commented on the issue:

    Thanks @ire7715 for your fixes.
    Re: key file ([comment, July 
    > **ckadner:** are there no risks with making this key-file public?
    > **ire7715 :** Yes, it is okay. The key was generated as a dummy IAM 
service account, which now have been removed. And I have interchanged part of 
the private key bytes, which makes it unusable.
    So, the key file is unusable for the unit test runs? If so, then there 
would be no reason to adding it as a test resource, no? 
    Is the idea then to communicate to developers how/where to add a key file 
they would have to generate for themselves? Would it be better then to have the 
unit test display a warning message in the console output if the key file is 
missing and skip the impacted test case(s)?
    For the Jenkins CI server, we would have to install a key file that does 
work (keeps working) and in a pre-build step copy it from somewhere, or use an 
environment variable to point to a local directory that has the key file.

> [PubSub] Make "ServiceAccountCredentials" really broadcastable
> --------------------------------------------------------------
>                 Key: BAHIR-122
>                 URL: https://issues.apache.org/jira/browse/BAHIR-122
>             Project: Bahir
>          Issue Type: Improvement
>          Components: Spark Streaming Connectors
>            Reporter: Ire Sun
> The origin implementation broadcast the key file path to Spark cluster, then 
> the executor read key file with the broadcasted path. Which is absurd, if you 
> are using a shared Spark cluster in a group/company, you certainly not want 
> to (and have no right to) put your key file on each instance of the cluster.
> If you store the key file on driver node and submit your job to a remote 
> cluster. You would get the following warning:
> {{WARN ReceiverTracker: Error reported by receiver for stream 0: Failed to 
> pull messages - java.io.FileNotFoundException}}

This message was sent by Atlassian JIRA

Reply via email to