Mans, It appears to me that there is a path for this not to be a breaking change for the flow. By creating a controller service to handle the credential provider piece you should be able to just update the processor to support that controller service interface. If the user sets that controller service then you use that and if they don't then you revert to using the older properties. We can mark those properties as no longer the preferred model and deprecate them in the codebase then when we reach a 1.0 milestone we can remove them.
Thanks Joe On Thu, Jan 7, 2016 at 9:07 PM, M Singh <mans2si...@yahoo.com.invalid> wrote: > Hi: > Just wanted to mention that if we go with the creds provider interface it > will be breaking change for nifi aws components as mentioned in > https://issues.apache.org/jira/browse/NIFI-1325. > Also, I am considering creating one aws creds provider controller which will > provide creds provider based on property file, basic, anonymous or assume > role session params. > Please let me know if there is any additional feedback for me. > Thanks again. > Mans > > On Thursday, January 7, 2016 2:56 PM, M Singh > <mans2si...@yahoo.com.INVALID> wrote: > > > Hi Joe: > Based on your feedback I will try to explore the controller interface for aws > creds provider. > Thanks for your advice. > Mans > > On Thursday, January 7, 2016 4:15 AM, Joe Witt <joe.w...@gmail.com> wrote: > > > Mans > > Appreciate you pushing this forward. There is a related idea to better > handle aws credentials for all the aws procs. Will look more and respond. > > Thanks > Joe > On Jan 7, 2016 6:52 AM, "M Singh" <mans2si...@yahoo.com.invalid> wrote: > >> Hi: >> Just wanted to follow-up and see if anyone has any feedback on . >> https://issues.apache.org/jira/browse/NIFI-1325. >> Thanks >> Mans > > > > >
