Mailing-List: contact users-help@cloudstack.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@cloudstack.apache.org
Received-SPF: pass (athena.apache.org: domain of creategui@gmail.com
 designates 209.85.212.169 as permitted sender)
MIME-Version: 1.0
Sender: creategui@gmail.com
In-Reply-To: 
 <CAMbNGRUDTfN_8s4AY-Pbx_BU_JXgrym-=B8zFw+ynDaL_FQVGQ@mail.gmail.com>
References: 
 <CAMbNGRUDTfN_8s4AY-Pbx_BU_JXgrym-=B8zFw+ynDaL_FQVGQ@mail.gmail.com>
Date: Wed, 31 Jul 2013 14:22:39 -0700
Message-ID: 
 <CAMbNGRUbnpLLbEq0esxPyOBrd5zraf=S_-v97H6qO960g0K_xw@mail.gmail.com>
Subject: Re: AWS API setup
From: Carlos Reategui <carlos@reategui.com>
To: users@cloudstack.apache.org
Content-Type: multipart/alternative; boundary=001a11c381ec45a3fe04e2d55382

--001a11c381ec45a3fe04e2d55382
Content-Type: text/plain; charset=ISO-8859-1

Looks like I'm on my own here....

I poked around the cloudstack-setup-databases script and the sql it uses
drops the tables before recreating them so it is not safe for me to run
that or it will kill my current cloud db.

In that script I did find references to the cloud-bridge sql files found
here:
# ls -l /usr/share/cloudstack-bridge/setup/
total 56
-rw-r--r-- 1 root root 1592 Jun  4 11:45 cloudbridge_bucketpolicy.sql
-rw-r--r-- 1 root root 1148 Jun  4 11:45 cloudbridge_db.sql
-rw-r--r-- 1 root root 3711 Jun  4 11:45 cloudbridge_index.sql
-rw-r--r-- 1 root root 1170 Jun  4 11:45 cloudbridge_multipart_alter.sql
-rw-r--r-- 1 root root 2468 Jun  4 11:45 cloudbridge_multipart.sql
-rw-r--r-- 1 root root  896 Jun  4 11:45 cloudbridge_offering_alter.sql
-rw-r--r-- 1 root root 1551 Jun  4 11:45 cloudbridge_offering.sql
-rw-r--r-- 1 root root  897 Jun  4 11:45 cloudbridge_policy_alter.sql
-rw-r--r-- 1 root root 4462 Jun  4 11:45 cloudbridge_schema.sql
-rw-r--r-- 1 root root 2365 Jun  4 11:45 deploy-db-bridge.sh
-rw-r--r-- 1 root root 1377 Jun  4 11:45 init_db.bat

I noticed the deploy-db-bridge.sh, so I ran it and now I have a cloudbridge
db.

Please note that this will set the cloud db user pw to cloud, so if you
used a different pw make sure to:
mysql> set password for 'cloud'@'%' = password('mypw');
mysql> set password for 'cloud'@'localhost' = password('mypw');
or your management server will not start.

I then ran into this bug:
https://issues.apache.org/jira/browse/CLOUDSTACK-3295
but I am on 4.1 not 4.2.

Searching for "xes.keystore" I I found this in the debian install rules:

for i in cloud-bridge.properties commons-logging.properties
crypto.properties xes.keystore ec2-service.properties; do \

  mv $(DESTDIR)/usr/share/$(PACKAGE)-bridge/webapps/awsapi/WEB-INF/classes/
$$i $(DESTDIR)/$(SYSCONFDIR)/$(PACKAGE)/management/; \.

Which is moving the files to /etc/cloudstack/management.  So I moved these
2 back:
# mv /etc/cloudstack/management/xes.keystore
/usr/share/cloudstack-management/webapps7080/awsapi/WEB-INF/classes/.
# mv /etc/cloudstack/management/crypto.properties
/usr/share/cloudstack-management/webapps7080/awsapi/WEB-INF/classes/.

Is this a bug in the debian packager?

Now when I run the cloudstack-aws-api-register script I get:
User registration failed with http error code: 401

The awsapi.log shows:
2013-07-31 12:16:11,245 ERROR [bridge.service.EC2RestServlet]
(catalina-exec-int-1:null) SetUserKeys Entity already exists:
javax.persistence.EntityExistsException: Entity already exists:
        at
com.cloud.utils.db.GenericDaoBase.persist(GenericDaoBase.java:1340)
        at
com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125)
        at
com.cloud.bridge.service.EC2RestServlet.setUserKeys(EC2RestServlet.java:395)
        at
com.cloud.bridge.service.EC2RestServlet.doGetOrPost(EC2RestServlet.java:243)
        at
com.cloud.bridge.service.EC2RestServlet.doGet(EC2RestServlet.java:218)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:617)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
        at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
        at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
        at
org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:646)
        at
org.apache.catalina.core.ApplicationDispatcher.processRequest(ApplicationDispatcher.java:436)
        at
org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:374)
        at
org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:302)
        at
com.cloud.bridge.service.EC2MainServlet.doGetOrPost(EC2MainServlet.java:105)
        at
com.cloud.bridge.service.EC2MainServlet.doGet(EC2MainServlet.java:84)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:617)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
        at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
        at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
        at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
        at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
        at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
        at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
        at
org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:615)
        at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
        at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:293)
        at
org.apache.coyote.http11.Http11NioProcessor.process(Http11NioProcessor.java:889)
        at
org.apache.coyote.http11.Http11NioProtocol$Http11ConnectionHandler.process(Http11NioProtocol.java:744)
        at
org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:2282)
        at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1146)
        at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
        at java.lang.Thread.run(Thread.java:679)

So looks like one of the previous attempts even though they failed, did
something.

I'll give the ec2 apis a try and see if they work.


On Fri, Jul 26, 2013 at 5:39 PM, Carlos Reategui <carlos@reategui.com>wrote:

> I can't seem to find docs to properly install the AWS API.
>
> I started with this:
> http://cloudstack.apache.org/docs/en-US/Apache_CloudStack/4.1.0/html/Installation_Guide/aws-ec2-user-setup.html
> but got nowhere because port 7080 was not available.
>
> I am on ubuntu 12.04 installed from repo -- actually upgraded 4.01 to 4.1
> -- did not have awsapi installed before.
>
> Here is the progress I have made so far:
> a) apt-get install cloudstack-awsapi
> This should probably be explained in the above docs to get the awsapi on
> 7080
> b) chgrp cloud /var/log/cloudstack/awsapi; chmod g+w
> /var/log/cloudstack/awsapi
> Otherwise it was unable to create awsapi.log.  Seems to be an installation
> bug.
>
> Currently stuck trying to "cloudstack-aws-api-register" as it is returning
> "User registration failed with http error code: 500"
>
> From the awsapi logs looks to be a problem with cloudbridge database not
> available.  I found this
> https://issues.apache.org/jira/browse/CLOUDSTACK-1557 which seems to
> imply this was fixed.  In the notes it talks about running
> cloudstack-setup-databases to create this one.  However shouldn't this have
> already been run as part of the cloudstack install?  Is it safe to run
> again?
>
> With regards to cloudstack-aws-api-register, the docs say to download it
> from a location it specifies.  There appears to be one that is already
> installed by cloudstack-awsapi:
> # dpkg -S /usr/bin/cloudstack-aws-api-register
> cloudstack-awsapi: /usr/bin/cloudstack-aws-api-register
> Is the one that is installed no good?
>
> thanks,
> Carlos
>
>
>

--001a11c381ec45a3fe04e2d55382--