You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@nifi.apache.org by baank <gi...@git.apache.org> on 2016/09/13 03:31:04 UTC
[GitHub] nifi pull request #1008: NIFI-2763 S3 processors do not work with older S3-c...
GitHub user baank opened a pull request:
https://github.com/apache/nifi/pull/1008
NIFI-2763 S3 processors do not work with older S3-compatible object s\u2026
\u2026tores
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/baank/nifi master
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/nifi/pull/1008.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #1008
----
commit d62123a3285bdb5d7566799e737a95e7c1b29995
Author: d810146 <na...@team.telstra.com>
Date: 2016-09-13T03:30:12Z
NIFI-2763 S3 processors do not work with older S3-compatible object stores
----
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastructure@apache.org or file a JIRA ticket
with INFRA.
---
[GitHub] nifi pull request #1008: NIFI-2763 S3 processors do not work with older S3-c...
Posted by baank <gi...@git.apache.org>.
Github user baank closed the pull request at:
https://github.com/apache/nifi/pull/1008
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastructure@apache.org or file a JIRA ticket
with INFRA.
---
[GitHub] nifi issue #1008: NIFI-2763 S3 processors do not work with older S3-compatib...
Posted by baank <gi...@git.apache.org>.
Github user baank commented on the issue:
https://github.com/apache/nifi/pull/1008
Entirely up to you James.
The signer is applied AWS wide so potentially could be useful for other non-AWS implementations of say SQS/SNS. That said the bug is only directly affecting S3.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastructure@apache.org or file a JIRA ticket
with INFRA.
---
[GitHub] nifi issue #1008: NIFI-2763 S3 processors do not work with older S3-compatib...
Posted by jvwing <gi...@git.apache.org>.
Github user jvwing commented on the issue:
https://github.com/apache/nifi/pull/1008
@baank , what would you think about moving the PropertyDescriptor and the configuration code to the AbstractS3Processor class rather than AWSAbstractProcessor?
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastructure@apache.org or file a JIRA ticket
with INFRA.
---
[GitHub] nifi issue #1008: NIFI-2763 S3 processors do not work with older S3-compatib...
Posted by jvwing <gi...@git.apache.org>.
Github user jvwing commented on the issue:
https://github.com/apache/nifi/pull/1008
Our current intentions are specific to S3, as are the implementation and tests, so I would prefer starting with S3 alone and refactoring later if/when there is demand for a wider option. Also, I think we can provide a stronger user experience as an S3-specific field, helping users either ignore the field or pick an appropriate Signer class without Googling for it. Specifically,
* Provide the currently supported class names as examples in the description text, or
* Present the options in a drop-down list of the S3 signers. Something similar came up in another PR with respect to server-side encryption and enforcing signature v4, and I think a list like "Default Signature", "Signature v4", "Signature v2", would be nice. No, this isn't required, but it seems like a nice extra for usability (via extra work for you, I admit it's feature creep).
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastructure@apache.org or file a JIRA ticket
with INFRA.
---