New Runtime

[refs]

The runtime itself lives here, and comments on its design can, and should, be appended to this pull request.

Rationale: micro/go-micro is based on running from sources, and we do not want that for the time being. We should also be in control of How We Run What We Run™, and therefore this approach fits better than using a third party process manager.

[update-docs]

Thanks for opening this pull request! The maintainers of this repository would appreciate it if you would create a changelog item based on your changes.

[kulmann]

Left some minor comments for improvement. But essentially everything you did works great. 😍

Biggest question and chance for improvement I see is: would be even more awesome to spawn the extensions with pman, but still like this: ocis <extension>. Right now this starts the extension without using pman. Goal should be to have all extensions spawned and managable through pman, for both ocis server and ocis <extension>. Problem is, that the way pman spawns the process would cause a recursion... ideas?

[kulmann]

Could be renamed to args to be in line with the callee's signature.

[kulmann]

Could be renamed to reply to be in line with the callee's signature.

[kulmann]

Return the (possible) error from here, instead of nil two lines below.

[kulmann]

server_simple seems to be broken... but looks like it already was before.

[kulmann]

Oh and of course: changelog. ;-D

[refs]

Left some minor comments for improvement. But essentially everything you did works great. 😍

Biggest question and chance for improvement I see is: would be even more awesome to spawn the extensions with pman, but still like this: ocis <extension>. Right now this starts the extension without using pman. Goal should be to have all extensions spawned and managable through pman, for both ocis server and ocis <extension>. Problem is, that the way pman spawns the process would cause a recursion... ideas?

the process manager will be included into the ocis toolchain indeed, resulting in, i.e when running ocis run phoenix, invoking the pman lib. It is in the pipeline :D

[dpakach]

@refs looks like UI tests CI is broken right now in master. Please Merge and rebase on top of #288 for green CI.

[refs]

@refs looks like UI tests CI is broken right now in master. Please Merge and rebase on top of #288 for green CI.

Thanks! I already rebased a while back, but encounter a race condition on reva. It finds out that reva-sharing depends on /var/tmp/reva dir to be present, as it attempts to read /var/tmp/reva/shares.json but the folder is not present, so it panics. You can see it in the logs of the ocis-server step.

Solved it for the new runtime on a hacky way, will have to tackle it on reva upstream.

[kulmann]

🐙 ❤️

[refs]

This has some implications. Since micro/micro 2.4.0 with the addition of an Auth service, calls to either web (:8082) or api (:8080) are authenticated.

There is however a noop default implementation, but token Inspection returns the following

// Inspect a token
func (n *noop) Inspect(token string) (*Account, error) {
	return &Account{ID: uuid.New().String(), Issuer: n.Options().Namespace}, nil
}

Where Issuer, for whatever reason, is empty. By the time this field is checked, len(acc.Issuer) == 0 // true.

I submitted a PR upstream that, if merged, would allow to, again, call the micro api and web services.

[refs]

cc @butonic , I believe this impacts the way you're currently testing the accounts queries through the micro/web