Reed Allman c0aed2fbb0 mask errors in api response, log real error
we had this _almost_ right, in that we were trying, but we weren't masking the
error from the user response for any error we don't intend to show. this also
adds a stack trace from any internal server errors, so that we might be able
to track them down in the future (looking at you, 'context deadline
exceeded'). in addition, this adds a new `models.APIError` interface which all
of the errors in `models` now implement, and can be caught easily / added to
easily.

the front end now does no status rewriting based on api errors, now when we
get a non-nil error we can call `handleResponse(c, err)` with it and if it's a
proper error, return it to the user with the right status code, otherwise log
a stack trace and return `internal server error`. this cleans up a lot of the
front end code.

also rewrites start task ctx deadline exceeded as timeout. with iw we had
async tasks so we could start the clock later and it didn't matter, but now
with sync tasks time out sometimes just making docker calls, and we want the
task status to show up as timed out. we may want to just catch all this above
in addition to this, but this seems like the right thing to do.

remove squishing together errors. this was weird, now we return the first
error for the purposes of using the new err interface.

removed a lot of 5xx errors that really should have been 4xx errors. changed
some of the 400 errors to 409 errors, since they are from sending in
conflicting info and not a malformed request.

removed unused errors / useless errors (many were used for logging, and didn't
provide any context. now with stack traces we don't need context as much in
the logs).
2017-07-14 03:44:16 -07:00
2017-07-07 01:30:02 -07:00
2017-07-13 14:40:36 -07:00
2017-07-13 14:40:36 -07:00
2017-07-07 07:45:17 -07:00
2017-07-07 10:14:08 -07:00
2017-07-12 14:18:01 -07:00
2017-06-11 02:06:54 -07:00
2017-07-07 10:14:08 -07:00
2017-07-07 23:05:17 +03:00
2017-07-07 01:30:02 -07:00
2017-05-18 18:59:34 +00:00
2017-05-15 12:00:43 -07:00
2017-07-12 14:18:01 -07:00
2017-07-07 10:14:08 -07:00
2017-05-18 18:59:34 +00:00
2017-05-29 17:10:47 -07:00
2017-07-07 01:30:02 -07:00
2017-06-09 13:42:59 -07:00
2017-07-07 01:30:02 -07:00

Oracle Functions build status

Oracle Functions is an event-driven, open source, functions-as-a-service compute platform that you can run anywhere. Some of it's key features:

Prequisites

  • Docker 17.05 or later installed and running
  • Logged into Docker Hub (docker login)

Usage

Installation (if running locally)

NOTE: The following instructions apply while the project is a private repo. This will build the Functions server and the CLI tool directly from the repo instead of using pre-built containers. Once the project is public, these steps will be unnecessary.

# Build and Install CLI tool
cd fn
make dep # just once
make install

# Build and Run Functions Server
cd ..
make dep # just once
make run # will build as well

Installation (if using internal alpha service)

Set your system to point to the internal service on BMC:

export API_URL=http://129.146.10.253:80

Download the pre-built CLI binary:

  1. Visit: https://gitlab-odx.oracle.com/odx/functions/tree/master/fn/releases/download/0.3.2
  2. Download the CLI for your platform
  3. Put in /usr/local/bin
  4. chmod +x

Your First Function

Functions are small but powerful blocks of code that generally do one simple thing. Forget about monoliths when using functions, just focus on the task that you want the function to perform.

The following is a simple Go program that outputs a string to STDOUT. Copy and paste the code below into a file called func.go. Currently the function must be named func.your_language_extention (ie func.go, func.js, etc.)

package main

import (
	"fmt"
)

func main() {
	fmt.Println("Hello from Oracle Functions!")
}

Now run the following CLI commands:

# Initialize your function
# This detects your runtime from the code above and creates a func.yaml
fn init <DOCKERHUB_USERNAME>/hello

# Test your function
# This will run inside a container exactly how it will on the server
fn run

# Deploy your functions to the Oracle Functions server (default localhost:8080)
# This will create a route to your function as well
fn deploy myapp

Now you can call your function:

curl http://localhost:8080/r/myapp/hello

Or in a browser: http://localhost:8080/r/myapp/hello

That's it! You just deployed your first function and called it. Now to update your function you can update your code and run fn deploy myapp again.

To Learn More

Get Involved

User Interface

This is the graphical user interface for Oracle Functions. It is currently not buildable.

docker run --rm -it --link functions:api -p 4000:4000 -e "API_URL=http://api:8080" treeder/functions-ui

For more information, see: https://github.com/treeder/functions-ui

Next up

Check out the Tutorial Series.

It will demonstrate some of Oracle Functions capabilities through a series of exmaples. We'll try to show examples in most major languages. This is a great place to start!

Description
The container native, cloud agnostic serverless platform.
Readme Apache-2.0 170 MiB
Languages
Go 97.4%
Shell 1.2%
Ruby 0.5%
Makefile 0.4%
Dockerfile 0.4%
Other 0.1%