Yes, don't delete ec2 until we have a replacement. That is an important feature.
Darren > On Oct 22, 2013, at 11:58 AM, Sebastien Goasguen <run...@gmail.com> wrote: > > Darren, i am +1 on yanking the S3 stuff in awsapi. > > I am going to work on a new query ec2, once thats done we can discuss > removing the awsapi entirely or putting it in a separate repo. > > -Sebastien > >> On 22 Oct 2013, at 19:23, Darren Shepherd <darren.s.sheph...@gmail.com> >> wrote: >> >> That's fine. That is what I thought and why I started off by asking >> should I expect it to work. I really don't understand why we would >> even have that feature. I'd really prefer to delete it and just defer >> to rados gateway, raik cs, etc. >> >> Honestly, it seems we should gut all the AWS API stuff. Drop S3 API >> and drop SOAP support completely, reimplement the Query API in a >> simpler fashion. I keep getting mixed answers from people on whether >> the query API really works well or not. >> >> Darren >> >>> On Tue, Oct 22, 2013 at 11:17 AM, Prachi Damle <prachi.da...@citrix.com> >>> wrote: >>> Yes, either moving the line to constructor or using a local SearchBuilder >>> will fix it - however the S3 APIs part in awsapi project is not supported >>> or updated for a long time and may have many other issues to get it >>> working. >>> >>> Prachi >>> >>> -----Original Message----- >>> From: Darren Shepherd [mailto:darren.s.sheph...@gmail.com] >>> Sent: Tuesday, October 22, 2013 11:06 AM >>> To: dev@cloudstack.apache.org >>> Subject: Re: S3 API broken in 4.2 >>> >>> The S3 servlet never initializes. A NPE is thrown in the init() method. >>> Basically there is a silly bug in >>> CloudStackConfigurationDaoImpl.getConfigValue() that makes it so that the >>> first call to the method will work, the second call will get a NPE. Since >>> EC2 API servlet is set to load-on-startup, the EC2 servlet always calls >>> CloudStackConfigurationDaoImpl.getConfigValue() first and it works. The >>> when you call S3, the init() method calls >>> getConfigValue() and a NPE is thrown. The below line needs to be moved >>> from getConfigValue() to the constructor. >>> >>> NameSearch.and("name", NameSearch.entity().getName(), >>> SearchCriteria.Op.EQ); >>> >>> Darren >>> >>>> On Tue, Oct 22, 2013 at 9:22 AM, Min Chen <min.c...@citrix.com> wrote: >>>> Darren, can you be specific what exact s3 API is not working in 4.2? >>>> >>>> Thanks >>>> -min >>>> >>>> On 10/22/13 5:14 AM, "Sanjeev Neelarapu" >>>> <sanjeev.neelar...@citrix.com> >>>> wrote: >>>> >>>>> Hi Darren, >>>>> >>>>> From 4.2 onwards we are using addImageStore API with provider >>>>> parameter >>>>> for adding any secondary storage provider. >>>>> >>>>> -Sanjeev >>>>> >>>>> -----Original Message----- >>>>> From: Sebastien Goasguen [mailto:run...@gmail.com] >>>>> Sent: Tuesday, October 22, 2013 2:44 PM >>>>> To: dev@cloudstack.apache.org >>>>> Subject: Re: S3 API broken in 4.2 >>>>> >>>>> >>>>> On Oct 22, 2013, at 1:22 AM, Chiradeep Vittal >>>>> <chiradeep.vit...@citrix.com> wrote: >>>>> >>>>>> Yeah, it was always a tech preview kind of thing. The basic >>>>>> operations used to work, but since most of the available client >>>>>> tools >>>>>> (s3cmd/boto/etc) had special workarounds for odd AWS behaviors (in >>>>>> the return behavior), they would have a hard time working with the >>>>>> S3 implementation in CloudStack which was based entirely on the WSDL. >>>>> >>>>> Shall we remove it ? to clean up the code >>>>> >>>>> Especially that it is easy to get an S3 store with riakCS, gluster or >>>>> ceph radosgw. >>>>> >>>>> >>>>>> >>>>>>> On 10/21/13 10:16 PM, "Darren S" <darren.s.sheph...@gmail.com> wrote: >>>>>>> >>>>>>> I didn't even know this feature existed until yesterday, so I >>>>>>> thought I'd try it out, but it seems that the S3 API in CloudStack >>>>>>> completely doesn't work in 4.2. Is it supposed to? Is this an >>>>>>> official feature or some tech preview type thing? >>>>>>> >>>>>>> Darren >>>>
