appscale / hawkeye Goto Github PK

2.0 2.0 6.0 1.2 MB

API fidelity test suite for AppScale

Shell 0.17% Java 41.25% Python 57.46% PHP 0.26% Go 0.45% HTML 0.06% JavaScript 0.35%

hawkeye's Introduction

AppScale GTS

AppScale GTS is an open source serverless platform for building and running scalable web and mobile applications on any infrastructure.

The platform enables developers to focus solely on business logic in order to rapidly build scalable apps, cleanly separating it from deployment and scaling logic. It allows operations to provide a consistent, tunable environment that can simplify running and maintaining apps on multiple infrastructures. The business will benefit from faster time-to-market, reduced operational costs, maximized application lifetime, and the flexibility to integrate with new or existing technologies.

AppScale GTS is open source and modeled on Google App Engine APIs, allowing developers to automatically deploy and scale unmodified Google App Engine applications over public and private cloud systems and on-premise clusters. It currently supports Python, Go, PHP and Java applications. The software was developed by AppScale Systems, Inc., based in Santa Barbara, California, and Google. In 2019, the company ended commercial support AppScale GTS, however the source code remains available in this GitHub Repo.

Why Use AppScale GTS?

The goal of AppScale GTS is to provide developers with a rapid, API-driven development platform that can run applications on any cloud infrastructure. AppScale GTS decouples application logic from its service ecosystem to give developers and cloud administrators control over application deployment, data storage, resource use, backup, and migration.

I Want ...

to contribute
to learn more

Documentation

Users
Developers
- Datastore Topics
- Advanced Topics
Architecture
- AppScale's core components
FAQs and Troubleshooting

Community and Support

Join the Community Google Group for announcements, help, and to discuss cloud research.

hawkeye's People

Contributors

Stargazers

Watchers

Forkers

scragraham sjones4 jeanleonov cdonati isabella232 kerbymart

hawkeye's Issues

Push tasks that require admin should be tested

All of the task worker endpoints are unauthenticated. Tasks that require admin authentication should be tested.

URLFetch bad certificate tests need updated.

Related to #164

We made our jenkins instance private and the self signed certificate is no longer accessible. Because of this the "bad" certificate tests for our hawkeye URLfetch tests will fail. Long term we need to probably have a small free instance launch in each cloud such that it will service requests for this test (and possibly others?).

Add timeout for PushQueueTest

Right now when I run Python Hawkeye, it hangs at the PushQueue test:

Task Queue Test Suite
=====================
runTest (tests.taskqueue_tests.PushQueueTest) ...

I can see in the App Engine logs that getting the task is stuck in an infinite loop:

INFO     2013-01-02 16:03:06,314 dev_appserver.py:3105] "GET /python/taskqueue/counter?key=e63bfeb0-54f5-11e2-b160-14109fe78e68 HTTP/1.0" 404 -
INFO     2013-01-02 16:03:08,333 dev_appserver.py:3105] "GET /python/taskqueue/counter?key=e63bfeb0-54f5-11e2-b160-14109fe78e68 HTTP/1.0" 404 -
INFO     2013-01-02 16:03:10,352 dev_appserver.py:3105] "GET /python/taskqueue/counter?key=e63bfeb0-54f5-11e2-b160-14109fe78e68 HTTP/1.0" 404 -

Yet there doesn't appear to be a timeout here - it just waits forever. Can we change this so that we wait no longer than 30 seconds and fail if this timeout is exceeded? Also, can we talk about maybe doing this for all the tests (albeit with timeouts specific to their individual tests)?

Requests with the wrong host header should be tested

Now that we reject requests with the wrong host header, we should ensure that that behavior remains.

Test for Channel API on Python and Java

xmpp_tests.SendAndReceiveTest fails intermittently with AssertionError 'message_recieved' != 'non-existent'

Near the end of the test we have code that looks like this:

    # Ensure the XMPP message has been received by the application.
    message_received = False
    for _ in range(5):
      response = self.http_get('/xmpp')
      xmpp_info = json.loads(response.payload)
      self.assertEquals(response.status, 200)
      self.assertTrue(xmpp_info['status'])
      if xmpp_info['state'] == 'message received!':
        message_received = True
        break
      time.sleep(1)

    self.assertTrue(message_received)

    # finally, clean up the mess we made for this test
    response = self.http_delete('/xmpp')
    self.assertEquals(response.status, 200)

    # and we should see no metadata
    response = self.http_get('/xmpp')
    xmpp_info = json.loads(response.payload)
    self.assertEquals(response.status, 200)
    self.assertTrue(xmpp_info['status'])
    self.assertEquals(xmpp_info['state'], 'non-existent')

Looking at the java application logs:

INFO hawkeye Response: 200 http://40.121.41.66:8080/java/xmpp
Server: nginx/1.10.3 (Ubuntu)
Date: Thu, 01 Aug 2019 21:42:28 GMT
Content-Type: application/json
Content-Length: 45
Connection: keep-alive
Cache-Control: no-cache
Expires: Fri, 01 Jan 1990 00:00:00 GMT

{"state":"message received!","status":true}

INFO hawkeye Request: DELETE http://40.121.41.66:8080/java/xmpp
Connection: keep-alive
Accept-Encoding: gzip, deflate
Accept: */*
User-Agent: python-requests/2.22.0
Content-Length: 0


INFO hawkeye Response: 200 http://40.121.41.66:8080/java/xmpp
Server: nginx/1.10.3 (Ubuntu)
Date: Thu, 01 Aug 2019 21:42:29 GMT
Content-Length: 0
Connection: keep-alive
Cache-Control: no-cache
Expires: Fri, 01 Jan 1990 00:00:00 GMT


INFO hawkeye Request: GET http://40.121.41.66:8080/java/xmpp
Connection: keep-alive
Accept-Encoding: gzip, deflate
Accept: */*
User-Agent: python-requests/2.22.0


INFO hawkeye Response: 200 http://40.121.41.66:8080/java/xmpp
Server: nginx/1.10.3 (Ubuntu)
Date: Thu, 01 Aug 2019 21:42:29 GMT
Content-Type: application/json
Content-Length: 45
Connection: keep-alive
Cache-Control: no-cache
Expires: Fri, 01 Jan 1990 00:00:00 GMT

{"state":"message received!","status":true}

ERROR hawkeye tests.xmpp_tests.SendAndReceiveTest.runTest - failed with error:
Traceback (most recent call last):
  File "/home/jenkins/jobs/Hawkeye-Test-Azure-Image/workspace/hawkeye/test-suite/hawkeye_test_runner.py", line 410, in runTest
    self.run_hawkeye_test()
  File "/home/jenkins/jobs/Hawkeye-Test-Azure-Image/workspace/hawkeye/test-suite/tests/xmpp_tests.py", line 63, in run_hawkeye_test
    self.assertEquals(xmpp_info['state'], 'non-existent')
AssertionError: u'message received!' != 'non-existent'

For some reason the key doesn't look like it is getting removed from the datastore:

INFO hawkeye Request: DELETE http://40.121.41.66:8080/java/xmpp
INFO hawkeye Response: 200 http://40.121.41.66:8080/java/xmpp
INFO hawkeye Request: GET http://40.121.41.66:8080/java/xmpp
INFO hawkeye Response: 200 http://40.121.41.66:8080/java/xmpp
{"state":"message received!","status":true}

This might be a timing issue.

Unable to run Java Hawkeye with dev_appserver

I'm trying to run Java Hawkeye with the SDK, but when I do, I get this:

java.lang.ClassNotFoundException: com.appscale.hawkeye.datastore.ProjectBrowserHandlerServlet
        at java.net.URLClassLoader$1.run(URLClassLoader.java:202)
        at java.security.AccessController.doPrivileged(Native Method)
        at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
        at com.google.appengine.tools.development.IsolatedAppClassLoader.loadClass(IsolatedAppClassLoader.java:213)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
        at org.mortbay.util.Loader.loadClass(Loader.java:91)
        at org.mortbay.util.Loader.loadClass(Loader.java:71)
        at org.mortbay.jetty.servlet.Holder.doStart(Holder.java:73)
        at org.mortbay.jetty.servlet.ServletHolder.doStart(ServletHolder.java:242)
        at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
        at org.mortbay.jetty.servlet.ServletHandler.initialize(ServletHandler.java:685)
        at org.mortbay.jetty.servlet.Context.startContext(Context.java:140)
        at org.mortbay.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1250)
        at org.mortbay.jetty.handler.ContextHandler.doStart(ContextHandler.java:517)
        at org.mortbay.jetty.webapp.WebAppContext.doStart(WebAppContext.java:467)
        at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
        at org.mortbay.jetty.handler.HandlerWrapper.doStart(HandlerWrapper.java:130)
        at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
        at org.mortbay.jetty.handler.HandlerWrapper.doStart(HandlerWrapper.java:130)
        at org.mortbay.jetty.Server.doStart(Server.java:224)
        at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
        at com.google.appengine.tools.development.JettyContainerService.startContainer(JettyContainerService.java:205)
        at com.google.appengine.tools.development.AbstractContainerService.startup(AbstractContainerService.java:232)
        at com.google.appengine.tools.development.DevAppServerImpl.start(DevAppServerImpl.java:157)
        at com.google.appengine.tools.development.DevAppServerMain$StartAction.apply(DevAppServerMain.java:333)
        at com.google.appengine.tools.util.Parser$ParseResult.applyArgs(Parser.java:48)
        at com.google.appengine.tools.development.DevAppServerMain.<init>(DevAppServerMain.java:269)
        at com.google.appengine.tools.development.DevAppServerMain.main(DevAppServerMain.java:245)

I notice there are quite a lot of these that show up when I try to start the DevAppServer. Also, I noticed my lib folder doesn't have any of the App Engine SDKs in it - is this normal? All I have is this:

outer-haven:java-app cgb$ ls web/WEB-INF/lib/
commons-fileupload-1.2.2.jar