Prabu, Yes. You can debug the code. It is a large codebase so that can be a bit of a trick to get started.
I think that one of the most stable approaches is to build a test case that accesses the data you want (this doesn't have to become a public test case, it just makes debugging easier by being very repeatable). I am not up to speed on how to do this, however. Is there somebody else on the list who could advise on this? On Wed, Aug 21, 2019 at 1:08 PM Prabu Mohan <prabu.ora...@gmail.com> wrote: > Thanks Ted. > > This is getting complex now, I thought that I might be missing something > simple while configuring drill, but this seems to be far beyond that. > > I'm not sure whether I can get a proxy and also just in case if any other > issues occur as well, is there a way I can debug the code to understand > what values are being passed ? > > On Tue, Aug 20, 2019 at 12:22 AM Ted Dunning <ted.dunn...@gmail.com> > wrote: > > > On Mon, Aug 19, 2019 at 11:33 AM Prabu Mohan <prabu.ora...@gmail.com> > > wrote: > > > > > but i am able to connect to ECS via python using boto3 libraries > without > > > any issues, I am able to write files to the bucket and read them back > .. > > > > > > not sure why i am facing issues with drill though with the same > > credentials > > > > > > > > > The key here is your assumption that the same credentials are being > passed > > through Drill to AWS and that there isn't some other consideration that > > keeps S3 from believing whatever credentials it is getting. > > > > That assumption has to be attacked by figuring out experiments that can > > prove or disprove aspects of it. For instance, if you can get a proxy in > > the middle of the connection, you should be able to see *exactly* what is > > on the wire. Likewise if you can get better logging out of Drill. > > >