profile
viewpoint
Lance Ball lance Red Hat (@nodeshift) Asheville, NC https://lanceball.dev I write software, cook food, exercise, take pictures, grow things. Red Hat He/him/his

keycloak/keycloak-admin-client 45

Replaced by https://github.com/keycloak/keycloak-nodejs-admin-client

bucharest-gold/genet 9

Node.js profiling tool

keycloak/keycloak-client-registration 9

Node.js client for the Keycloak client registration API

lance/acts_as_keyable 4

Uses Rails routing to make nice URLs so you get /books/oliver_twist instead of /books/1234

lance/admin_data 1

Browse and Manage your data using browser

lance/awestruct.org 1

awestruct.org website

pull request commentcloudevents/sdk-javascript

feat: add emitterFactory and friends

I have incorporated feedback by renaming the function and changing up the parameters.

function emitterFor(fn: TransportFunction, options = { binding: HTTP, mode: Mode.BINARY }): EmitterFunction

PTAL

lance

comment created time in 2 hours

push eventlance/sdk-javascript

Lance Ball

commit sha 03dba6e9078cd4a886b85b2a7e7f49192fa9badb

fixup: incorporate PR feedback on function signature Signed-off-by: Lance Ball <lball@redhat.com>

view details

push time in 2 hours

pull request commentcloudevents/sdk-javascript

feat: add emitterFactory and friends

Definitely not requesting changes. Thanks for the detailed explanations.

No worries. I should have been more explicit in the PR description.

lance

comment created time in 2 hours

pull request commentcloudevents/sdk-javascript

feat: add emitterFactory and friends

I guess why do we have a custom emitter at all?

I'm not sure what you mean by "custom emitter". This PR is about removing opinionated choices like the use of axios to send messages across the wire, and replacing it with something that is less "custom".

We should let users BYO / use your own libraries for emitting using raw primitives of HTTP (headers and body).

That is already possible. Perhaps you don't recall some of the conversations around this, or are not familiar with the codebase. It landed in this PR. Your hypothetical is available today, it just looks a little different.

const axios = require('axios').default;

const ce = { ... }
const message = HTTP.binary(ce); // Or HTTP.structured(ce)

axios({
  method: 'post',
  url: '...',
  data: message.body,
  headers: message.headers,
});

This PR is about providing users a way of encapsulating behavior. Imagine the user is not using axios, but instead their application has chosen superagent. Sending a Message looks a little different, and it's just clunkier.

import request from "superagent";

const ce = { ... }
const message = HTTP.binary(ce); // Or HTTP.structured(ce)

const post = request.post('...');
for (const key of Object.getOwnPropertyNames(message.headers)) {
  post.set(key, message.headers[key]);
}
post.send(message.body);

This PR would make that look a little different.

// Same code as above but wrapped in a function
// User code - a transport function
function sendViaSuperagent(message) {
  const post = request.post('...');
  for (const key of Object.getOwnPropertyNames(message.headers)) {
    post.set(key, message.headers[key]);
  }
  post.send(message.body);
}

// The returned EmitterFunction handles converting from CloudEvent to Message and invokes 'sendViaSuperagent`
const emit = emitterFor(sendViaSuperagent);

const ce = { ... }
emit(ce);

This encourages encapsulation. For example, HTTP.binary(ce) is only called in one place in the code. Any specific properties or other attributes that a user may need to provide to axios, superagent or got or whatever is being used are all encapsulated in this one function.

Additionally, and probably more important, we have talked about adding multiple additional transport support soon. This would mean that, for example, MQTT would look similar.

// This is user code - a TransportFunction
function sendMQTT(message) {
  // do whatever you need to do with message.body and message.headers to send it over MQTT
}

// Create an EmitterFunction
const emit = emitterFor(sendMQTT, { mode: Mode.BINARY });

const ce = { ... };
emit(ce);

Note that this looks exactly the same as sending an event over HTTP. That's by design. In fact, I can use the EmitterFunction interface in my shiny new TypeScript application for CloudEvents. Imagine that you want to build an app that allows devs to provide a EmitterFunction so that it can emit events on their behalf. This makes that possible, and it won't matter what they are doing to actually send the event across the wire - HTTP/MQTT/ProtoBuff/whatever.

Sure, it's a small benefit to the user to provide this. But I don't understand your hostility towards it, especially given that we can already do what you were asking for in the very trivial case of just sending an event with axios.

lance

comment created time in 16 hours

push eventnodeshift/opossum

snyk-bot

commit sha b255f8cdaf9f1759f7601769f9eea85d19ff8715

fix: upgrade @babel/core from 7.11.5 to 7.11.6 Snyk has created this PR to upgrade @babel/core from 7.11.5 to 7.11.6. See this package in npm: https://www.npmjs.com/package/@babel/core See this project in Snyk: https://app.snyk.io/org/nodeshift-agg/project/0569fa2f-39b2-4a6a-9bdc-8ac878d28a88?utm_source=github&utm_medium=upgrade-pr

view details

push time in 17 hours

create barnchnodeshift/opossum

branch : snyk-upgrade-bf7d8850ed1ccf7535f4aada48085fba

created branch time in 17 hours

pull request commentcloudevents/sdk-javascript

feat: add emitterFactory and friends

I'd rather expose just 1 interface for users to emit CloudEvents

I'm not proposing more than 1 interface. As I have said multiple times, Emitter is meant to be removed in v4.0.0. I am proposing a replacement that does not have a dependency on a 3rd party transport library such as axios.

Emitter.send(ce, "https://cloudevents.io/example");

This means that we would not be removing the dependency on axios. Is that what you are suggesting? I understood that removing this dependency is a goal for the v4.0.0 release.

lance

comment created time in 19 hours

pull request commentcloudevents/sdk-javascript

feat: add emitterFactory and friends

@grant the purpose of this PR is to provide a mechanism in 4.x for users to send events across the wire without this module having an explicit dependency on axios (or any other transport module). The Emitter capabilities as they are now with an explicit dependency on axios will go away. But it would still be nice to provide a simple mechanism for users to easily send events.

I can appreciate some of the usefulness for this utility, but I don't think a stateful emitter factory should be part of the SDK.

The factory is not stateful. But maybe you mean the emitter itself. As I see it, if we want the user to not have to provide the transport binding and serialization mode with every call there must be some state. Otherwise, with each function call that sends an event, the user would be required pass HTTP and Mode.BINARY (or Mode.STRUCTURED) in addition to the event.

It's really hard to discuss design decisions in the abstract, so in the PR description, can you write up the before and after with these changes?

Done.

I think I can suggest a different way to achieve the same result without a factory.

OK - let's hear it.

I can imagine a developer writing their own factory pattern that is even more flexible than the interface here. For example, a user could just write a wrapper for the emitter function and add extra params.

The whole point is that the Emitter as it is today is going away.

In terms of interface design, Factories are more common in Java and less so in Node.

Ahh but using closures to maintain state is quite a popular JavaScript style. I thought you'd like it. How about I rename it to emitterFor( fn: TransportFunction, options: Options ) : EmitterFunction? Then we won't think of it as a factory.

lance

comment created time in 20 hours

PR opened boson-project/faas

chore(ci): fix release binary uploads project/chore type/bug

There was a typo in the upload part of the CI. Also, there was a section that (thankfully) did not run, which would have created a second release. Moved the release-please action later in CI so less time elapses between the creation of the release, and the upload of the binaries.

Signed-off-by: Lance Ball lball@redhat.com

+12 -20

0 comment

1 changed file

pr created time in 21 hours

create barnchlance/faas

branch : fix-release-ci

created branch time in 21 hours

push eventboson-project/faas

github-actions[bot]

commit sha 40962fc6454672924bbc7e26ddb9885e59ab7984

chore: release 0.7.0 (#116) Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>

view details

push time in a day

PR merged boson-project/faas

chore: release 0.7.0 autorelease: pending

:robot: I have created a release *beep* *boop*

0.7.0 (2020-09-24)

Features

  • add local debugging to node.js templates (#132) (1b0bb15)
  • decouple function name from function domain (#127) (0258626)
  • default to no confirmation prompts for CLI commands (566d8f9)
  • set builder images in templates and .faas.yaml (#136) (d6e131f)
  • ci/cd: add release-please for automated release management (8a60c5e)

Bug Fixes


This PR was generated with Release Please.

+20 -1

0 comment

2 changed files

github-actions[bot]

pr closed time in a day

pull request commentcloudevents/sdk-javascript

feat: add emitterFactory and friends

@lance Does it make sense to only have 1 parameter(an option object) passed to the emitterFactory? Then we could easily default values.

@lholmquist I could make that change. Something like this?

const emit = emitterFactory({ binding: HTTP, mode: Mode.BINARY, transport: axiosEmitter });

With binding and mode defaulting to HTTP and Mode.BINARY respectively, the above is equivalent to:

const emit = emitterFactory( { transport: axiosEmitter } );

Personally, I think I'd prefer two parameters: the function and an options object. E.g.

const emit = emitterFactory( axiosEmitter, { binding: HTTP, mode: Mode.BINARY });

Which makes the default call a little cleaner.

const emit = emitterFactory( axiosEmitter );
lance

comment created time in a day

Pull request review commentcloudevents/sdk-javascript

feat: add emitterFactory and friends

 interface EmitterFunction {  *  * @see https://github.com/cloudevents/spec/blob/v1.0/http-protocol-binding.md  * @see https://github.com/cloudevents/spec/blob/v1.0/http-protocol-binding.md#13-content-modes+ * @deprecated Will be removed in 4.0.0. Consider using the emitterFactory+ *  */ export class Emitter {   url?: string;   protocol: Protocol;-  emitter: EmitterFunction;+  binaryEmitter: EmitterFunction;

This is specifically to support the existing behavior as it is today with Emitter. Since a user can specify the serialization mode (BINARY or STRUCTURED), with the current Emitter.send(), we need to have one of each kind of emitter.

This code should all be removed with 4.0.0 given that it's currently deprecated.

lance

comment created time in a day

PullRequestReviewEvent

delete branch lance/faas

delete branch : configurable-builders

delete time in a day

push eventboson-project/faas

Lance Ball

commit sha d6e131f9153c20bd3edbf1441060610987fa5693

feat: set builder images in templates and .faas.yaml (#136) This commit adds a .builder.yaml file to each template directory. In the file there is at the moment a single key/value pair, "default: <image>", where the actual builder image name is <image>. Using a mapping allows the future possibility that a user may specify a builder image by name via a flag on the command line. For example, ```console faas build --builder native ``` When a project is initialized, the .builder.yaml file is read, and the default builder is saved in the project's .faas.yaml file. The .faas.yaml file is then consulted when building an image with `faas build`. If the builder image is specified, then the builder will use it. Otherwise, it will fallback to the defaults. This allows developers to create custom builders, and specify them in the configuration file. After extracting the builder image from .builder.yaml in the project directory, this file is deleted. This commit also adds Verbose to the init command.

view details

push time in a day

PR merged boson-project/faas

feat: set builder images in templates and .faas.yaml source/configuration templates/go templates/node templates/quarkus type/enhancement

This commit adds a .builder.yaml file to each template directory. In the file there is at the moment a single key/value pair, "default: <image>", where the actual builder image name is <image>. Using a mapping allows the future possibility that a user may specify a builder image by name via a flag on the command line.

When a project is initialized, the .builder.yaml file is read, and the default builder is saved in the project's .faas.yaml file. The .faas.yaml file is then consulted when building an image with faas build. If the builder image is specified, then the builder will use it. Otherwise, it will fallback to the defaults. This allows developers to create custom builders, and specify them in the configuration file.

An open question is whether the .builder.yaml file should be deleted after it is read during project initialization. The init command is the only time the file is consulted, and it may be confusing for the user if they discover a second configuration-y file in the project directory.

Fixes: https://github.com/boson-project/faas/issues/120

+70 -20

3 comments

13 changed files

lance

pr closed time in a day

issue closedboson-project/faas

Do not hard code builder image locations

The buildpack Runtimes are all currently hard coded.

https://github.com/boson-project/faas/blob/566d8f9255d532e88e72d5bce122bebaee88bc81/buildpacks/builder.go#L25-L29

It would be nice for this to be configurable.

closed time in a day

lance

issue closedboson-project/faas

default function domain to .cluster.local

We should probably implement the default domain as .cluster.local suffix for users initializing a Function without an explicitly provided name nor name derivable from directory structure, rather than generate an error or force the input. For example

$ cd /home/alice/projects/test
$ faas create
OK test.cluster.local

(Currently this use case generates an error later in the process, on deploy)

For a little background: when creating a new Function, the primary use case is creating services with fully qualified domain names which are routable from localhost (i.e. ending in a TLD+1 public suffix)

For example, to create the following Functions:

www.example.com
my.example.com
cdn1.us-west2.example.co.uk

Is accomplished by either using the suggested project directory structure:

projects
├── example.co.uk
│   └── cdn1.us-west2
└── example.com
    ├── my
    └── www

or by explicitly providing the names

faas create www.example.com
faas create my.example.com
faas create cdn1.us-west2.example.co.uk

However, we do not yet support:

faas create test
OK test.cluster.local 

closed time in a day

lkingland

pull request commentboson-project/faas

feat: set builder images in templates and .faas.yaml

I've incorporated all of the feedback @zroubalik @matejvasek - ty!

lance

comment created time in a day

push eventlance/faas

Matej Vasek

commit sha 02309a24a1d8779fb69e4f67fa4f7faea705b2ba

fix: sync package-lock.json (#137)

view details

Zbynek Roubalik

commit sha 025862689ec8dc460a1ef6f4402151c18a072ba3

feat: decouple function name from function domain (#127) * decouple function name from function domain Signed-off-by: Zbynek Roubalik <zroubali@redhat.com>

view details

Lance Ball

commit sha 05efee8c839408aa6136c55e782f692413ca8785

src: add Long command descriptions for each of the CLI commands (#133) Uses the Cobra "Long" configuration for each command to provide more descriptive text. Example: ```console faas help create 1.3m  Mon 21 Sep 2020 09:55:40 PM EDT Create a new Function, including initialization of local files and deployment Creates a new Function project at 'path'. If 'path' does not exist, it is created. The function name is the name of the leaf directory at path. After creating the project, a container image is created and is deployed. This command wraps 'init', 'build' and 'deploy' all up into one command. The runtime, trigger, image name, image repository, and namespace may all be specified as flags on the command line, and will subsequently be the default values when an image is built or a Function is deployed. If the image name and image repository are both unspecified, the user will be prompted for a repository name, and the image name can be inferred from that plus the function name. The function name, namespace, image name and repository name are all persisted in the project configuration file .faas.yaml. Usage: faas create <path> [options] [flags] Flags: -c, --confirm Prompt to confirm all configuration options - $FAAS_CONFIRM -h, --help help for create -i, --image string Optional full image name, in form [registry]/[namespace]/[name]:[tag] for example quay.io/myrepo/project.name:latest (overrides --repository) - $FAAS_IMAGE -n, --namespace string Override namespace into which the Function is deployed (on supported platforms). Default is to use currently active underlying platform setting - $FAAS_NAMESPACE -r, --repository string Repository for built images, ex 'docker.io/myuser' or just 'myuser'. Optional if --image provided. - $FAAS_REPOSITORY -l, --runtime string Function runtime language/framework. - $FAAS_RUNTIME (default "go") --templates string Extensible templates path. - $FAAS_TEMPLATES (default "/home/lanceball/.config/faas/templates") -t, --trigger string Function trigger (ex: 'http','events') - $FAAS_TRIGGER (default "http") Global Flags: --config string config file path (default "~/.faas/config") -v, --verbose print verbose logs ```

view details

Lance Ball

commit sha f90036b0f0420875845a92d8f5e112f623c16993

feat: set builder images in templates and .faas.yaml This commit adds a .builder.yaml file to each template directory. In the file there is at the moment a single key/value pair, "default: <image>", where the actual builder image name is <image>. Using a mapping allows the future possibility that a user may specify a builder image by name via a flag on the command line. For example, ```console faas build --builder native ``` When a project is initialized, the .builder.yaml file is read, and the default builder is saved in the project's .faas.yaml file. The .faas.yaml file is then consulted when building an image with `faas build`. If the builder image is specified, then the builder will use it. Otherwise, it will fallback to the defaults. This allows developers to create custom builders, and specify them in the configuration file. After extracting the builder image from .builder.yaml in the project directory, this file is deleted. This commit also adds Verbose to the init command.

view details

push time in a day

delete branch lance/faas

delete branch : improve-cli-text

delete time in a day

push eventboson-project/faas

Lance Ball

commit sha 05efee8c839408aa6136c55e782f692413ca8785

src: add Long command descriptions for each of the CLI commands (#133) Uses the Cobra "Long" configuration for each command to provide more descriptive text. Example: ```console faas help create 1.3m  Mon 21 Sep 2020 09:55:40 PM EDT Create a new Function, including initialization of local files and deployment Creates a new Function project at 'path'. If 'path' does not exist, it is created. The function name is the name of the leaf directory at path. After creating the project, a container image is created and is deployed. This command wraps 'init', 'build' and 'deploy' all up into one command. The runtime, trigger, image name, image repository, and namespace may all be specified as flags on the command line, and will subsequently be the default values when an image is built or a Function is deployed. If the image name and image repository are both unspecified, the user will be prompted for a repository name, and the image name can be inferred from that plus the function name. The function name, namespace, image name and repository name are all persisted in the project configuration file .faas.yaml. Usage: faas create <path> [options] [flags] Flags: -c, --confirm Prompt to confirm all configuration options - $FAAS_CONFIRM -h, --help help for create -i, --image string Optional full image name, in form [registry]/[namespace]/[name]:[tag] for example quay.io/myrepo/project.name:latest (overrides --repository) - $FAAS_IMAGE -n, --namespace string Override namespace into which the Function is deployed (on supported platforms). Default is to use currently active underlying platform setting - $FAAS_NAMESPACE -r, --repository string Repository for built images, ex 'docker.io/myuser' or just 'myuser'. Optional if --image provided. - $FAAS_REPOSITORY -l, --runtime string Function runtime language/framework. - $FAAS_RUNTIME (default "go") --templates string Extensible templates path. - $FAAS_TEMPLATES (default "/home/lanceball/.config/faas/templates") -t, --trigger string Function trigger (ex: 'http','events') - $FAAS_TRIGGER (default "http") Global Flags: --config string config file path (default "~/.faas/config") -v, --verbose print verbose logs ```

view details

push time in a day

PR merged boson-project/faas

src: add Long command descriptions for each of the CLI commands project/documentation source/commands

Uses the Cobra "Long" configuration for each command to provide more descriptive text.

Example:

faas help create                                                                                                      1.3m  Mon 21 Sep 2020 09:55:40 PM EDT
Create a new Function, including initialization of local files and deployment

Creates a new Function project at 'path'. If 'path' does not exist, it is
created. The function name is the name of the leaf directory at path. After
creating the project, a container image is created and is deployed. This
command wraps 'init', 'build' and 'deploy' all up into one command.

The runtime, trigger, image name, image repository, and namespace may all be
specified as flags on the command line, and will subsequently be the default
values when an image is built or a Function is deployed. If the image name and
image repository are both unspecified, the user will be prompted for a
repository name, and the image name can be inferred from that plus the function
name. The function name, namespace, image name and repository name are all
persisted in the project configuration file .faas.yaml.

Usage:
  faas create <name> [options] [flags]

Flags:
  -c, --confirm             Prompt to confirm all configuration options - $FAAS_CONFIRM
  -h, --help                help for create
  -i, --image string        Optional full image name, in form [registry]/[namespace]/[name]:[tag] for example quay.io/myrepo/project.name:latest (overrides --repository) - $FAAS_IMAGE
  -n, --namespace string    Override namespace into which the Function is deployed (on supported platforms).  Default is to use currently active underlying platform setting - $FAAS_NAMESPACE
  -p, --path string         Path to the new project directory - $FAAS_PATH (default "/home/lanceball/src/go/src/github.com/boson-project/faas")
  -r, --repository string   Repository for built images, ex 'docker.io/myuser' or just 'myuser'.  Optional if --image provided. - $FAAS_REPOSITORY
  -l, --runtime string      Function runtime language/framework. - $FAAS_RUNTIME (default "go")
      --templates string    Extensible templates path. - $FAAS_TEMPLATES (default "/home/lanceball/.config/faas/templates")
  -t, --trigger string      Function trigger (ex: 'http','events') - $FAAS_TRIGGER (default "http")

Global Flags:
      --config string   config file path (default "~/.faas/config")
  -v, --verbose         print verbose logs
+128 -29

2 comments

11 changed files

lance

pr closed time in a day

push eventlance/faas

Lance Ball

commit sha 1b0bb15147889bb55ff33de1dc132cb0370d1da6

feat: add local debugging to node.js templates (#132) This commit adds nodemon and an `npm run debug` command to the Node.js templates to support debugging on localhost.

view details

Zbynek Roubalik

commit sha 7e298fd7d7f2f76bc8e5288fd0ef94d54347ab0a

use go 1.14 (#134) Signed-off-by: Zbynek Roubalik <zroubali@redhat.com>

view details

Matej Vasek

commit sha 02309a24a1d8779fb69e4f67fa4f7faea705b2ba

fix: sync package-lock.json (#137)

view details

Zbynek Roubalik

commit sha 025862689ec8dc460a1ef6f4402151c18a072ba3

feat: decouple function name from function domain (#127) * decouple function name from function domain Signed-off-by: Zbynek Roubalik <zroubali@redhat.com>

view details

Lance Ball

commit sha 39d392e1fba2c765884237129f722640ce7ec8be

src: add Long command descriptions for each of the CLI commands Uses the Cobra "Long" configuration for each command to provide more descriptive text. Example: ```console faas help create 1.3m  Mon 21 Sep 2020 09:55:40 PM EDT Create a new Function, including initialization of local files and deployment Creates a new Function project at 'path'. If 'path' does not exist, it is created. The function name is the name of the leaf directory at path. After creating the project, a container image is created and is deployed. This command wraps 'init', 'build' and 'deploy' all up into one command. The runtime, trigger, image name, image repository, and namespace may all be specified as flags on the command line, and will subsequently be the default values when an image is built or a Function is deployed. If the image name and image repository are both unspecified, the user will be prompted for a repository name, and the image name can be inferred from that plus the function name. The function name, namespace, image name and repository name are all persisted in the project configuration file .faas.yaml. Usage: faas create <name> [options] [flags] Flags: -c, --confirm Prompt to confirm all configuration options - $FAAS_CONFIRM -h, --help help for create -i, --image string Optional full image name, in form [registry]/[namespace]/[name]:[tag] for example quay.io/myrepo/project.name:latest (overrides --repository) - $FAAS_IMAGE -n, --namespace string Override namespace into which the Function is deployed (on supported platforms). Default is to use currently active underlying platform setting - $FAAS_NAMESPACE -p, --path string Path to the new project directory - $FAAS_PATH (default "/home/lanceball/src/go/src/github.com/boson-project/faas") -r, --repository string Repository for built images, ex 'docker.io/myuser' or just 'myuser'. Optional if --image provided. - $FAAS_REPOSITORY -l, --runtime string Function runtime language/framework. - $FAAS_RUNTIME (default "go") --templates string Extensible templates path. - $FAAS_TEMPLATES (default "/home/lanceball/.config/faas/templates") -t, --trigger string Function trigger (ex: 'http','events') - $FAAS_TRIGGER (default "http") Global Flags: --config string config file path (default "~/.faas/config") -v, --verbose print verbose logs ```

view details

push time in a day

push eventboson-project/faas

Zbynek Roubalik

commit sha 025862689ec8dc460a1ef6f4402151c18a072ba3

feat: decouple function name from function domain (#127) * decouple function name from function domain Signed-off-by: Zbynek Roubalik <zroubali@redhat.com>

view details

push time in a day

PR merged boson-project/faas

feat: decouple function name from function domain

Signed-off-by: Zbynek Roubalik zroubali@redhat.com

Fixes: #123

faas create foo -l node

Creates a new directory foo and initialize/create the function inside.

A directory structure is created according to the specified name, eg. relative/path/to/foo, /absolute/path/to/foo, foo or empty value (in this case it uses current directory).

The 'last' directory name is used as function name.

+126 -312

2 comments

15 changed files

zroubalik

pr closed time in a day

issue closedboson-project/faas

Proposal to decouple function name from function domain

Currently, the CLI has been written to conflate the function name with the function domain. For example, creating a project in a directory, foo, produces the following:

❯ ../faas init -l node                                                                                                         Wed 16 Sep 2020 09:49:18 AM EDT
Project path: /home/lanceball/src/go/src/github.com/boson-project/faas/foo
Project name: foo.faas.boson-project.github.com
Runtime: node
Trigger: http

Where the project name has been derived from the local directory. It is possible to provide a name to the init and create commands. For example,

❯ faas init foo -l node                                                                                                541ms  Wed 16 Sep 2020 09:51:01 AM EDT
Project path: /home/lanceball/src/go/src/github.com/boson-project/faas/foo
Project name: foo
Runtime: node
Trigger: http

However, this produces problems during deployment.

❯ faas build                                                                                                           545ms  Wed 16 Sep 2020 09:52:07 AM EDT
A repository for Function images is required. For example, 'docker.io/tigerteam'.

Repository for Function images: docker.io/lanceball
Building image: docker.io/lanceball/foo:latest

faas/foo on  main [$!?] is 📦 v0.1.0 via ⬢ v12.16.3 took 35s 
❯ faas deploy                                                                                                          35.8s  Wed 16 Sep 2020 09:52:48 AM EDT
Error: : Invalid value: "foo": should be a domain with at least two segments separated by dots

This is, of course, going to be confusing to the end user. "I just wanted to name my function something. Why is it failing?".

In fact, if I manually edit ./.faas.yaml to attempt to comply with the error message suggestion, I then get the following.

❯ cat .faas.yaml                                                                                                        5.1s  Wed 16 Sep 2020 09:54:25 AM EDT
───────┬──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
       │ File: .faas.yaml
───────┼──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
   1   │ name: foo.bar
   2   │ namespace: ""
   3   │ runtime: node
   4   │ image: docker.io/lanceball/foo:latest
   5   │ trigger: http
───────┴──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────

faas/foo on  main [$!?] is 📦 v0.1.0 via ⬢ v12.16.3 
❯ faas deploy                                                                                                          147ms  Wed 16 Sep 2020 09:54:30 AM EDT
Error: invalid service name 'foo.bar', must be at least three parts.

Not only is it unintuitive to conflate domain and name, it can cause real usability issues, and complicates our code base. It also ignores the fact that a function may move from domain to domain as it goes through a development/test/stage/prod pipeline. Additionally, domain management is really the baliwick of cluster configuration, and in the vast majority of cases, these two personas (developer / cluster admin) are going to be different people.

While it is true that a function's name ultimately does become a part of the route, this should not be a concern of the function developer. For example, using the kn CLI, it's easy to create a function named foo. The route to the function ultimately does contain that name, but as a developer, I don't really care as long as the route is available.

❯ kn service create foo --image docker.io/lanceball/foo:latest                                                         152ms  Wed 16 Sep 2020 10:00:20 AM EDT
Creating service 'foo' in namespace 'faas':

  0.037s The Configuration is still working to reflect the latest desired specification.
  0.286s The Route is still working to reflect the latest desired specification.
  0.587s Configuration "foo" is waiting for a Revision to become ready.
 12.846s ...
 12.883s Ingress has not yet been reconciled.
 12.937s unsuccessfully observed a new generation
 13.139s Ready to serve.

Service 'foo' created to latest revision 'foo-jfcdt-1' is available at URL:
http://foo.faas.127.0.0.1.nip.io

I recommend a change to effect the following.

  • Derive the function name from the directory path if not provided (exists already), but limit it to the directory name instead of the full path
  • Allow user to provide a name for init and create commands (exists already)
  • Since kn names cannot have a . in them, continue to munge the name so that we prevent the user from experiencing an error if they name the function foo.bar for example. In that case, we can munge it to foo-bar and kn will be happy.

See: https://github.com/boson-project/faas/issues/47 See: https://github.com/boson-project/faas/issues/107 See: https://github.com/boson-project/faas/issues/94 See: https://github.com/boson-project/faas/issues/95 See: https://github.com/boson-project/faas/issues/86 See: https://github.com/boson-project/faas/issues/85

Note all of these issues are directly related to naming and DNS of functions. If we simply assume that the cluster is configured correctly, and ensure that any name provided or derived does not have a . in it, all of these issues essentially go away.

@boson-project/core we discussed this earlier in the week, please feel free to include your thoughts here.

closed time in a day

lance

push eventboson-project/faas

Matej Vasek

commit sha 02309a24a1d8779fb69e4f67fa4f7faea705b2ba

fix: sync package-lock.json (#137)

view details

push time in a day

PullRequestReviewEvent

PR opened boson-project/faas

feat: set builder images in templates and .faas.yaml source/configuration templates/go templates/node templates/quarkus type/enhancement

This commit adds a .builder.yaml file to each template directory. In the file there is at the moment a single key/value pair, "default: <image>", where the actual builder image name is <image>. Using a mapping allows the future possibility that a user may specify a builder image by name via a flag on the command line.

When a project is initialized, the .builder.yaml file is read, and the default builder is saved in the project's .faas.yaml file. The .faas.yaml file is then consulted when building an image with faas build. If the builder image is specified, then the builder will use it. Otherwise, it will fallback to the defaults. This allows developers to create custom builders, and specify them in the configuration file.

An open question is whether the .builder.yaml file should be deleted after it is read during project initialization. The init command is the only time the file is consulted, and it may be confusing for the user if they discover a second configuration-y file in the project directory.

Fixes: https://github.com/boson-project/faas/issues/120

+38 -5

0 comment

11 changed files

pr created time in 2 days

create barnchlance/faas

branch : configurable-builders

created branch time in 2 days

Pull request review commentboson-project/faas

src: add Long command descriptions for each of the CLI commands

 func init() { }  var deleteCmd = &cobra.Command{-	Use:               "delete <name>",-	Short:             "Delete a Function deployment",-	Long:              `Removes the deployed Function by name, by explicit path, or by default for the current directory.  No local files are deleted.`,+	Use:   "delete <name>",+	Short: "Delete a Function deployment",+	Long: `Delete a Function deployment++Removes a deployed function from the cluster. The user may specify a function+by name, path using the --path or -p flag, or if neither of those are provided,+the current directory will be searched for a .faas.yaml configuration file to+determine the function to be removed.+

If you have some time to read the history, I recently introduced a PR that removed --path altogether from almost all commands, leaving it only for init and create as a required argument. But that PR was closed as seeming less scriptable.

I am happy to reconsider this. My thinking was that if all commands are executed from within the context of a project directory, there is no need for a --path argument except when creating a project. Given that the PR was reverted, all commands now have --path as a flag, and init and create have <path> as a required argument. I wouldn't mind seeing --path go away, but I'd prefer not to make <path> in create and init a required flag. Maybe it's irrational, but I just don't like required flags. :smiley:

lance

comment created time in 2 days

PullRequestReviewEvent

Pull request review commentboson-project/faas

src: add Long command descriptions for each of the CLI commands

 func init() { }  var createCmd = &cobra.Command{-	Use:        "create <name>",-	Short:      "Create a new Function, including initialization of local files and deployment.",+	Use:   "create <path>",+	Short: "Create a new Function, including initialization of local files and deployment",+	Long: `Create a new Function, including initialization of local files and deployment++Creates a new Function project at <path>. If <path> does not exist, it is+created. The Function name is the name of the leaf directory at <path>. After+creating the project, a container image is created and is deployed. This+command wraps "init", "build" and "deploy" all up into one command.++The runtime, trigger, image name, image repository, and namespace may all be+specified as flags on the command line, and will subsequently be the default+values when an image is built or a Function is deployed. If the image name and+image repository are both unspecified, the user will be prompted for a+repository name, and the image name can be inferred from that plus the function

I know! It's super frustrating. At one point, early on in this project, I was using --tag similar to Docker, which considers the entire string of registry/user/repository:tag to be the --tag. But we reverted.

As it stands now, "image name" specified by --image is the full string registry/user/repository:tag, and repository is registry/user. I would love to normalize this usage based on existing tooling in the wild, but it's not really clear how to best go about that given that each registry may have different URLs. For example, Docker supports docker.io/node:latest (no user in this case).

lance

comment created time in 2 days

PullRequestReviewEvent

Pull request review commentboson-project/faas

src: add Long command descriptions for each of the CLI commands

 func init() { }  var createCmd = &cobra.Command{-	Use:        "create <name>",-	Short:      "Create a new Function, including initialization of local files and deployment.",+	Use:   "create <path>",+	Short: "Create a new Function, including initialization of local files and deployment",+	Long: `Create a new Function, including initialization of local files and deployment++Creates a new Function project at <path>. If <path> does not exist, it is+created. The Function name is the name of the leaf directory at <path>. After+creating the project, a container image is created and is deployed. This+command wraps "init", "build" and "deploy" all up into one command.+

tbh, I question the usefulness of a faas create that does scaffolding and then an intermediate build afterwards

I am with you on this. I believe @zroubalik and @matejvasek are as well. But we'll have to convince @lkingland and @nainaz.

Instead I would love to see non-overlapping commands, that do:

  • Scaffolding (init or maybe create but only for creating the repo)
  • Building (build)
  • Deploy (deploy)
  • Run locally (run)

This already exists in what we have today. It's just that there is an additional create command.

lance

comment created time in 2 days

PullRequestReviewEvent

Pull request review commentboson-project/faas

src: add Long command descriptions for each of the CLI commands

 func init() { }  var createCmd = &cobra.Command{-	Use:        "create <name>",-	Short:      "Create a new Function, including initialization of local files and deployment.",+	Use:   "create <path>",+	Short: "Create a new Function, including initialization of local files and deployment",+	Long: `Create a new Function, including initialization of local files and deployment++Creates a new Function project at <path>. If <path> does not exist, it is+created. The Function name is the name of the leaf directory at <path>. After+creating the project, a container image is created and is deployed. This

Yes, <path> is mandatory here and may be . - at least when this lands.

lance

comment created time in 2 days

PullRequestReviewEvent

Pull request review commentboson-project/faas

src: add Long command descriptions for each of the CLI commands

 func init() { }  var buildCmd = &cobra.Command{-	Use:        "build",-	Short:      "Build an existing Function project as an OCI image",+	Use:   "build",+	Short: "Build an existing Function project as an OCI image",+	Long: `Build an existing Function project as an OCI image++Builds the Function project in the current directory or in the directory+specified by the --path flag. The .faas.yaml file is read to determine the

You make a good point here.

lance

comment created time in 2 days

PullRequestReviewEvent

pull request commentcloudevents/sdk-javascript

feat: add emitterFactory and friends

Note: added tests include testing for Axios, SuperAgent and Got as HTTP transport libraries.

lance

comment created time in 2 days

PR opened cloudevents/sdk-javascript

feat: add emitterFactory and friends module/lib module/transport/http type/enhancement version/4.x

This commit adds an emitterFactory function that returns an EmitterFunction object. The EmitterFunction may be used to emit events over a supported network transport layer. Currently, only HTTP is supported.

Parameters provided to the emitterFactory are the transport Binding (only HTTP supported), the encoding mode (Mode.BINARY or Mode.STRUCTURED), and a TransportFunction.

The implementation for emitBinary and emitStructured has been replaced with this simple pattern and those two functions have been removed.

Example:

// The endpoint URL that will receive the event
const sink = 'https://my-event-sink';

// A function that uses Axios to send a message over HTTP
function axiosEmitter(message: Message, options?: Options): Promise<unknown> {
  return axios.post(sink, message.body, { headers: message.headers, ...options });
}

// Create an event emitter
const emit = emitterFactory(HTTP, Mode.BINARY, axiosEmitter);

// Emit an event, sending it to the endpoint URL
emit(new CloudEvent{ source: '/example', type: 'example' });

Related: https://github.com/cloudevents/sdk-javascript/issues/314

+797 -688

0 comment

13 changed files

pr created time in 2 days

create barnchlance/sdk-javascript

branch : add-emitter-factory

created branch time in 2 days

issue commentcloudevents/spec

Are null values for attributes permitted?

For all of the REQUIRED context attributes in the spec, it's pretty clear that their values cannot be null, based on wording that @duglin pointed out.

  • Constraints:
    • REQUIRED
    • MUST be a non-empty URI-reference
    • An absolute URI is RECOMMENDED

For OPTIONAL context attributes, the wording admittedly is a little less clear.

  • Constraints:
    • OPTIONAL
    • If present, MUST adhere to the format specified in RFC 2046

What does it mean to be "present"? For the typed representation of a CloudEvent in an SDK, this depends on the language and idiomatic style. It is an SDK question and may differ across the various languages. In JavaScript, for example, this is totally valid.

const event = new CloudEvent({ source: '/example', type: 'example' });
console.log( event.datacontenttype ); // has not been set, will print 'undefined'

The datacontent type attribute is present on the event object. Heck it's JS, so event.foobar is also "present" in a certain sense, as it will also return undefined. (We could get into Object.hasOwnProperty(), but that's a digression).

Where this question of being present matters is in the representation on the wire - e.g. in JSON or Avro format. Now, when we ask if an attribute is "present", it seems a bit clearer. I read it as, "does the context attribute exist at all in the JSON representation?" If so, then it must be in RFC 2064 format - - which null is not.

To continue with the JS example, if I convert the event into JSON format, we don't see the datacontenttype attribute.

event.toString()
> '{"id":"2985acb6-d7b9-49b6-aad7-b5b4dae8a2dd","type":"example","source":"/example","specversion":"1.0","time":"2020-09-23T14:25:46.583Z"}'

If the datacontenttype attribute were printed and it had an empty value, I would consider that an error based on my reading of the event and JSON format specs.

jskeet

comment created time in 2 days

issue commentcloudevents/sdk-javascript

Emitter Should Optionally Be Static

@grant the proposal was that Emitter is being deprecated because of the work that was done with the Message and Binding interfaces, etc. But, I've been thinking about this. I think before we drop 4.x, we should have a good, easy to use replacement, because it really does make life easy. Here is a prime example in the Knative docs (using the 2.x API).

@lholmquist are you good with holding off a bit on 4.x? I'm noodling something like an EmitterFactory that takes a Binding, SinkUrl, Mode and a function and does the right thing. I'm a little stalled on it at the moment. Will try to get a WIP PR submitted soonish.

grant

comment created time in 3 days

Pull request review commentboson-project/faas

feat: decouple function name from function domain

 func functionWithOverrides(root, namespace, image string) (f faas.Function, err  // deriveName returns the explicit value (if provided) or attempts to derive // from the given path.  Path is defaulted to current working directory, where-// a function configuration, if it exists and contains a name, is used.  Lastly-// derivation using the path us used.+// a Function configuration, if it exists and contains a name, is used.  func deriveName(explicitName string, path string) string {

Any suggestion?

I've been sitting here for 5 minutes trying to come up with a good name. I see why you asked. The best I've come up with is providedOrConfiguredName(string) string. But meh.

zroubalik

comment created time in 3 days

PullRequestReviewEvent

pull request commentboson-project/faas

src: use go 1.14

@zroubalik is it just habit that you used --signoff? Do you think having something like the DCO bot here is useful?

zroubalik

comment created time in 3 days

push eventboson-project/faas

Zbynek Roubalik

commit sha 7e298fd7d7f2f76bc8e5288fd0ef94d54347ab0a

use go 1.14 (#134) Signed-off-by: Zbynek Roubalik <zroubali@redhat.com>

view details

push time in 3 days

PR merged boson-project/faas

src: use go 1.14

Signed-off-by: Zbynek Roubalik zroubali@redhat.com

Is there a specific reason for us to stay on go 1.13? go 1.15 is already out. So updating to 1.14 for now.

+1 -1

0 comment

1 changed file

zroubalik

pr closed time in 3 days

Pull request review commentboson-project/faas

src: add Long command descriptions for each of the CLI commands

 func init() { 	root.AddCommand(initCmd) 	initCmd.Flags().BoolP("confirm", "c", false, "Prompt to confirm all configuration options - $FAAS_CONFIRM") 	initCmd.Flags().StringP("path", "p", cwd(), "Path to the new project directory - $FAAS_PATH")-	initCmd.Flags().StringP("runtime", "l", faas.DefaultRuntime, "Function runtime language/framework. - $FAAS_RUNTIME")+	initCmd.Flags().StringP("runtime", "l", faas.DefaultRuntime, "Function runtime language/framework. Default runtime is 'go'. Available runtimes: 'node', 'quarkus' and 'go'. - $FAAS_RUNTIME") 	initCmd.Flags().StringP("templates", "", filepath.Join(configPath(), "templates"), "Extensible templates path. - $FAAS_TEMPLATES")-	initCmd.Flags().StringP("trigger", "t", faas.DefaultTrigger, "Function trigger (ex: 'http','events') - $FAAS_TRIGGER")+	initCmd.Flags().StringP("trigger", "t", faas.DefaultTrigger, "Function trigger. Default trigger is 'http'. Available triggers: 'http' and 'events' - $FAAS_TRIGGER")  	if err := initCmd.RegisterFlagCompletionFunc("runtime", CompleteRuntimeList); err != nil { 		fmt.Println("Error while calling RegisterFlagCompletionFunc: ", err) 	} }  var initCmd = &cobra.Command{-	Use:        "init <name>",-	Short:      "Initialize a new Function project",+	Use:   "init <name>",

Oops!

lance

comment created time in 3 days

PullRequestReviewEvent

push eventlance/faas

Lance Ball

commit sha f2a8832ae50afac5a659c415366936cc76b8170f

squash: fix init parameter name

view details

push time in 3 days

push eventlance/faas

Lance Ball

commit sha c1a8ca620736ba7a417221a53004db47ececeaaf

squash: consistent spacing and indentation

view details

push time in 3 days

push eventlance/faas

Lance Ball

commit sha ce48b5acac2523f47f5ec0fa935bf526a189fe4c

squash: use double quotes when referring to commands or options

view details

push time in 3 days

pull request commentboson-project/faas

src: add Long command descriptions for each of the CLI commands

@zroubalik thanks for your feedback. I've incorporated it.

lance

comment created time in 3 days

push eventlance/faas

Lance Ball

commit sha 7237d4f54d1d47ec7a43e22dd2479599775ec945

squash: incorporate PR feedback

view details

push time in 3 days

PR closed nodejs/node

Reviewers
repl: commands allowed only when not multiline repl semver-major stalled

Allow commands such as .help only when the repl is not in multiline mode, preventing erroneous evaluation of commands which could in fact be valid JS code.

For example the following should output 'received' and not be evaluated on line 4 as the .help command.

> (_ => {
  const x = { help: 'received' };
  return x
  .help ;
})()

Since the .break command is only used to get out of a bind in multiline input, and CTL-C does the exact same thing, it has been removed.

Refs: https://github.com/nodejs/node/pull/20625

<!-- Thank you for your pull request. Please provide a description above and review the requirements below.

Bug fixes and new features should include tests and possibly benchmarks.

Contributors guide: https://github.com/nodejs/node/blob/master/CONTRIBUTING.md -->

Checklist

<!-- Remove items that do not apply. For completed items, change [ ] to [x]. -->

  • [x] make -j4 test (UNIX), or vcbuild test (Windows) passes
  • [x] tests and/or benchmarks are included
  • [x] documentation is changed or added
  • [x] commit message follows commit guidelines
+188 -77

31 comments

7 changed files

lance

pr closed time in 3 days

pull request commentnodejs/node

repl: commands allowed only when not multiline

Closing as outdated

lance

comment created time in 3 days

PR closed boson-attic/kfn

feat: support a user package.json file enhancement runtime/js

This commit modifies the JS language implementation so that it will look for a user provided package.json in the same directory as the function file. If one exists, it uses this instead of the generated one.

NB: This does mean that if a user has provided function dependency information in the function file in the form:

// kfn:dependency primal 0.2.3

These dependencies will be superceded by what is found in package.json

This commit includes the changes in https://github.com/openshift-cloud-functions/kfn/pull/25

+43 -33

1 comment

4 changed files

lance

pr closed time in 3 days

PullRequestReviewEvent

Pull request review commentboson-project/faas

feat: decouple function name from function domain

 func newCreateConfig(args []string) createConfig { // Skipped if not in an interactive terminal (non-TTY), or if --confirm (agree to // all prompts) was not explicitly set. func (c createConfig) Prompt() createConfig {-	name := deriveName(c.Name, c.initConfig.Path) 	if !interactiveTerminal() || !c.initConfig.Confirm { 		// Just print the basics if not confirming 		fmt.Printf("Project path: %v\n", c.initConfig.Path)-		fmt.Printf("Project name: %v\n", name)+		fmt.Printf("Project name: %v\n", c.initConfig.Name) 		fmt.Printf("Runtime: %v\n", c.Runtime) 		fmt.Printf("Trigger: %v\n", c.Trigger) 		return c 	}++	derivedName, derivedPath := deriveNameAndPath(prompt.ForString("Project name", "", prompt.WithRequired(true))) 	return createConfig{ 		initConfig: initConfig{-			Path:    prompt.ForString("Project path", c.initConfig.Path),-			Name:    prompt.ForString("Project name", name, prompt.WithRequired(true)),+			Name:    derivedName,+			Path:    derivedPath,

It appears to me that perhaps this omits the prompting of name and path entirely, right?

@lkingland I may be misreading your comment, so disregard if so (or correct me). The prompt occurs on line 121.

derivedName, derivedPath := deriveNameAndAbsolutePathFromPath(prompt.ForString("Project path", c.initConfig.Path, prompt.WithRequired(true)))
zroubalik

comment created time in 3 days

Pull request review commentboson-project/faas

feat: decouple function name from function domain

 func ToSubdomain(in string) (string, error) { 			out = append(out, c) 		} 	}-	return string(out), nil++	result := string(out)++	if errs := validation.IsDNS1035Label(result); len(errs) > 0 {

What kinds of characters in in will cause this to fail?

zroubalik

comment created time in 3 days

Pull request review commentboson-project/faas

feat: decouple function name from function domain

 func functionWithOverrides(root, namespace, image string) (f faas.Function, err  // deriveName returns the explicit value (if provided) or attempts to derive // from the given path.  Path is defaulted to current working directory, where-// a function configuration, if it exists and contains a name, is used.  Lastly-// derivation using the path us used.+// a Function configuration, if it exists and contains a name, is used.  func deriveName(explicitName string, path string) string { 	// If the name was explicitly provided, use it. 	if explicitName != "" { 		return explicitName 	}+ 	// If the directory at path contains an initialized Function, use the name therein 	f, err := faas.NewFunction(path) 	if err == nil && f.Name != "" { 		return f.Name 	}-	maxRecursion := faas.DefaultMaxRecursion-	derivedName, _ := faas.DerivedName(path, maxRecursion)-	return derivedName++	return ""+}++// deriveNameAndPath returns resolved Function name and absolute path

Nit:

// deriveNameAndAbsolutePath returns resolved Function name and absolute path
zroubalik

comment created time in 3 days

Pull request review commentboson-project/faas

feat: decouple function name from function domain

 func functionWithOverrides(root, namespace, image string) (f faas.Function, err  // deriveName returns the explicit value (if provided) or attempts to derive // from the given path.  Path is defaulted to current working directory, where-// a function configuration, if it exists and contains a name, is used.  Lastly-// derivation using the path us used.+// a Function configuration, if it exists and contains a name, is used.  func deriveName(explicitName string, path string) string {

I wonder if this function could be better named as it no longer really derives the name, but instead just pulls it from the configuration file or returns the passed value.

zroubalik

comment created time in 3 days

Pull request review commentboson-project/faas

feat: decouple function name from function domain

 func (c *Client) Initialize(cfg Function) (err error) {  	// Set the name to that provided, defaulting to path derivation if empty.

Nit: the comment is no longer valid

zroubalik

comment created time in 3 days

Pull request review commentboson-project/faas

feat: decouple function name from function domain

 func newCreateConfig(args []string) createConfig { 	} } -// Prompt the user with value of config members, allowing for interaractive changes.+// Prompt the user with value of config members, allowing for interactive changes. // Skipped if not in an interactive terminal (non-TTY), or if --confirm (agree to // all prompts) was not explicitly set. func (c createConfig) Prompt() createConfig {-	name := deriveName(c.Name, c.initConfig.Path) 	if !interactiveTerminal() || !c.initConfig.Confirm { 		// Just print the basics if not confirming 		fmt.Printf("Project path: %v\n", c.initConfig.Path)-		fmt.Printf("Project name: %v\n", name)+		fmt.Printf("Function name: %v\n", c.initConfig.Name) 		fmt.Printf("Runtime: %v\n", c.Runtime) 		fmt.Printf("Trigger: %v\n", c.Trigger) 		return c 	}++	derivedName, derivedPath := deriveNameAndAbsolutePathFromPath(prompt.ForString("Project path", c.initConfig.Path, prompt.WithRequired(true)))

This deriveNameAndAbsolutePathFromPath() function is called in newInitConfig() which is called by newCreateConfig(), so it seems redundant to call it again here. The values for c.initConfig.Path and c.initConfig.Name should already be set, shouldn't they?

zroubalik

comment created time in 3 days

PullRequestReviewEvent
PullRequestReviewEvent

delete branch lance/faas

delete branch : add-node-debug

delete time in 3 days

push eventboson-project/faas

Lance Ball

commit sha 1b0bb15147889bb55ff33de1dc132cb0370d1da6

feat: add local debugging to node.js templates (#132) This commit adds nodemon and an `npm run debug` command to the Node.js templates to support debugging on localhost.

view details

push time in 3 days

PR merged boson-project/faas

feat: add local debugging to node.js templates templates/node type/enhancement

This commit adds nodemon and an npm run debug command to the Node.js templates to support debugging on localhost.

+7 -3

0 comment

3 changed files

lance

pr closed time in 3 days

PR opened boson-project/faas

src: add Long command descriptions for each of the CLI commands project/documentation source/commands

Uses the Cobra "Long" configuration for each command to provide more descriptive text.

Example:

faas help create                                                                                                      1.3m  Mon 21 Sep 2020 09:55:40 PM EDT
Create a new Function, including initialization of local files and deployment

Creates a new Function project at 'path'. If 'path' does not exist, it is
created. The function name is the name of the leaf directory at path. After
creating the project, a container image is created and is deployed. This
command wraps 'init', 'build' and 'deploy' all up into one command.

The runtime, trigger, image name, image repository, and namespace may all be
specified as flags on the command line, and will subsequently be the default
values when an image is built or a Function is deployed. If the image name and
image repository are both unspecified, the user will be prompted for a
repository name, and the image name can be inferred from that plus the function
name. The function name, namespace, image name and repository name are all
persisted in the project configuration file .faas.yaml.

Usage:
  faas create <name> [options] [flags]

Flags:
  -c, --confirm             Prompt to confirm all configuration options - $FAAS_CONFIRM
  -h, --help                help for create
  -i, --image string        Optional full image name, in form [registry]/[namespace]/[name]:[tag] for example quay.io/myrepo/project.name:latest (overrides --repository) - $FAAS_IMAGE
  -n, --namespace string    Override namespace into which the Function is deployed (on supported platforms).  Default is to use currently active underlying platform setting - $FAAS_NAMESPACE
  -p, --path string         Path to the new project directory - $FAAS_PATH (default "/home/lanceball/src/go/src/github.com/boson-project/faas")
  -r, --repository string   Repository for built images, ex 'docker.io/myuser' or just 'myuser'.  Optional if --image provided. - $FAAS_REPOSITORY
  -l, --runtime string      Function runtime language/framework. - $FAAS_RUNTIME (default "go")
      --templates string    Extensible templates path. - $FAAS_TEMPLATES (default "/home/lanceball/.config/faas/templates")
  -t, --trigger string      Function trigger (ex: 'http','events') - $FAAS_TRIGGER (default "http")

Global Flags:
      --config string   config file path (default "~/.faas/config")
  -v, --verbose         print verbose logs
+127 -27

0 comment

9 changed files

pr created time in 4 days

create barnchlance/faas

branch : improve-cli-text

created branch time in 4 days

push eventlance/faas

Lance Ball

commit sha 3868ef344108c3fe2d8f8506363f9ec773708165

chore: remove [options] from usage string The cobra package, magically appends "[flags]" to the usage string if a command has flags. By adding "[options]" to the usage string, we end up with help text that looks like this. ``` faas init <name> [options] [flags] ``` This commit fixes that.

view details

Matej Vasek

commit sha 279e9908437f1ef04e69c3710f22738cddaea3bc

chore: update Quarkus version to 1.8.1.Final

view details

Lance Ball

commit sha 341d3d2064af65a7e11fc7cc610e459922e07db8

docs: add documentation for CLI commands (#128) Adds a document outlining each of the CLI commands

view details

Lance Ball

commit sha fae27dabc97c78cd98be400d296da6fc2fbeba65

fix: correct value for config path and robustify (#130) * fix: correct value for config path and robustify The hardcoded, initial value for the configuration path was set to `.faas/config`. But `configPath()` immediately sets this to the correct value of ~/.config. Both the create and init commands use `configPath()` to search for additional templates, if they exist, and were each doing `filepath.Join(configPath(), "faas", "templates")`. This commit also changes `configPath()` so that it is `~/.config/faas` and does so in a cross platform friendly way. If the `$HOME` directory cannot be determined, the config is assumed to be at `./.config/faas`. * squash: remove config variable entirely

view details

Lance Ball

commit sha 340ec71caa0466c386a033530a35dcf2b810a689

Merge branch 'main' into add-node-debug

view details

push time in 4 days

PR opened boson-project/faas

feat: add local debugging to node.js templates templates/node type/enhancement

This commit adds nodemon and an npm run debug command to the Node.js templates to support debugging on localhost.

+7 -3

0 comment

3 changed files

pr created time in 4 days

create barnchlance/faas

branch : add-node-debug

created branch time in 4 days

delete branch lance/faas

delete branch : tweak-config-path

delete time in 4 days

push eventboson-project/faas

Lance Ball

commit sha fae27dabc97c78cd98be400d296da6fc2fbeba65

fix: correct value for config path and robustify (#130) * fix: correct value for config path and robustify The hardcoded, initial value for the configuration path was set to `.faas/config`. But `configPath()` immediately sets this to the correct value of ~/.config. Both the create and init commands use `configPath()` to search for additional templates, if they exist, and were each doing `filepath.Join(configPath(), "faas", "templates")`. This commit also changes `configPath()` so that it is `~/.config/faas` and does so in a cross platform friendly way. If the `$HOME` directory cannot be determined, the config is assumed to be at `./.config/faas`. * squash: remove config variable entirely

view details

push time in 4 days

PR merged boson-project/faas

fix: correct value for config path and robustify project/chore source/configuration

The hardcoded, initial value for the configuration path was set to .faas/config. But configPath() immediately sets this to the correct value of ~/.config. Both the create and init commands use configPath() to search for additional templates, if they exist, and were each doing filepath.Join(configPath(), "faas", "templates"). This commit also changes configPath() so that it is ~/.config/faas and does so in a cross platform friendly way. If the $HOME directory cannot be determined, the config is assumed to be at ./.config/faas.

+8 -8

0 comment

3 changed files

lance

pr closed time in 4 days

delete branch lance/faas

delete branch : add-commands-doc

delete time in 4 days

push eventboson-project/faas

Lance Ball

commit sha 341d3d2064af65a7e11fc7cc610e459922e07db8

docs: add documentation for CLI commands (#128) Adds a document outlining each of the CLI commands

view details

push time in 4 days

PR merged boson-project/faas

docs: add documentation for CLI commands info/discussion project/documentation

I've added some documentation for the CLI commands here and called out some odd behavior with the options in a couple of places. I wrote this as I was trying to sort out how I felt about https://github.com/boson-project/faas/pull/125 and https://github.com/boson-project/faas/issues/126 and thought that it would be a good document to use when trying to rationalize any usability changes. For the most part, I have changed my mind about #125 and #126. I'm still on the fence about faas delete, but as I wrote in the doc here, there are valid reasons to have the commands that we do and I'll just eat crow. :bird:

Also - note that for all commands except init and create, I have documented them as they are today. For the init and create commands, I documented them as intended for https://github.com/boson-project/faas/pull/127.

+155 -0

1 comment

1 changed file

lance

pr closed time in 4 days

PR closed boson-project/faas

src(commands): remove --path flag from most commands info/discussion source/commands type/enhancement

This commit removes the --path -p flag for the build, delete, deploy, describe, run and update commands. The init and create commands have been left alone for now, pending the outcome of https://github.com/boson-project/faas/issues/123. The list command doesn't need to know a path, because it's about seeing all deployed Functions.

Adds a faas.LoadFunction(path string) function to load an existing Function project from disk and return an error if one does not already exist.

Note: I realize this might be controversial. Speak up if you disagree with this proposal!

Edit: The idea here is to enforce the notion that all commands (other than init and create) are run from within a Function project directory where the configuration file .faas.yaml defines the context. Some of the comments from @matejvasek identified areas where functionality has been reduced - e.g. you can't describe or delete a function by name. I think we should actually consider removing these, and possibly even consider removing faas deploy and faas update.

BREAKING CHANGE

+94 -76

4 comments

8 changed files

lance

pr closed time in 4 days

push eventlance/faas

Lance Ball

commit sha b9766268be3d53dc41ff91688de83e1122921ba9

squash: remove config variable entirely

view details

push time in 4 days

pull request commentboson-project/faas

docs: add documentation for CLI commands

Landing this. @boson-project/contributors, let's be sure to keep it updated as the commands change.

lance

comment created time in 4 days

push eventlance/faas

Lance Ball

commit sha c678e114a4850de5537999266e7d84b0304f0cca

squash: incorporate pr review comments

view details

push time in 4 days

push eventlance/docs

Lance Ball

commit sha 194647d4d2c1dfc396eda8bbd57248bd0b5b8ade

squash: fix copy paste problems Signed-off-by: Lance Ball <lball@redhat.com>

view details

push time in 4 days

issue commentboson-project/buildpacks

Enable JVM mode for Quarkus

OK, so for Quarkus there would be jvm and native. For Node.js debug and production. What about Golang?

matejvasek

comment created time in 4 days

push eventnodeshift/opossum

snyk-bot

commit sha 71a7303993b27e3c7abfdded861a51c6a572ad16

fix: upgrade opener from 1.5.1 to 1.5.2 Snyk has created this PR to upgrade opener from 1.5.1 to 1.5.2. See this package in npm: https://www.npmjs.com/package/opener See this project in Snyk: https://app.snyk.io/org/nodeshift-agg/project/0569fa2f-39b2-4a6a-9bdc-8ac878d28a88?utm_source=github&utm_medium=upgrade-pr

view details

push time in 6 days

delete branch lance/faas

delete branch : fix-usage-strings

delete time in 6 days

push eventboson-project/faas

Lance Ball

commit sha 3868ef344108c3fe2d8f8506363f9ec773708165

chore: remove [options] from usage string The cobra package, magically appends "[flags]" to the usage string if a command has flags. By adding "[options]" to the usage string, we end up with help text that looks like this. ``` faas init <name> [options] [flags] ``` This commit fixes that.

view details

push time in 6 days

PR merged boson-project/faas

chore: remove [options] from usage string project/chore source/commands

The cobra package, magically appends "[flags]" to the usage string if a command has flags. By adding "[options]" to the usage string, we end up with help text that looks like this.

  faas init <name> [options] [flags]

This commit fixes that.

+6 -6

0 comment

6 changed files

lance

pr closed time in 6 days

issue commentboson-project/faas

Do not hard code builder image locations

What if, instead of configuring builders explicitly, we simply add metadata to the templates. For example:

❯ cat templates/node/http/.builder     147ms  Fri 18 Sep 2020 03:49:45 PM EDT
───────┬──────────────────────────────────────────────────────────────────────
       │ File: templates/node/http/.builder
───────┼──────────────────────────────────────────────────────────────────────
   1   │ quay.io/boson/faas-nodejs-builder
───────┴──────────────────────────────────────────────────────────────────────
lance

comment created time in 7 days

PR opened boson-project/faas

fix: correct value for config path and robustify project/chore source/configuration

The hardcoded, initial value for the configuration path was set to .faas/config. But configPath() immediately sets this to the correct value of ~/.config. Both the create and init commands use configPath() to search for additional templates, if they exist, and were each doing filepath.Join(configPath(), "faas", "templates"). This commit also changes configPath() so that it is ~/.config/faas and does so in a cross platform friendly way. If the $HOME directory cannot be determined, the config is assumed to be at ./.config/faas.

+9 -4

0 comment

3 changed files

pr created time in 7 days

more