0.5.12 • Published 4 years ago

@iseatz.com/oneview v0.5.12

Weekly downloads
-
License
-
Repository
bitbucket
Last release
4 years ago

Behold!

Oneview.js

Oneview.js is a (Node-based) javacript service that provides shared ovs modules for iSeatz node.js apps. It is not run as a standalone app, but instead is a common import for other applications. It handles redis integration, logging, slogging, downstream communication, and per-server configuration, among other tasks.

Development and usage

Dependencies: Node ≥ 0.8.21

  • All heavy runtime processing and I/O calls in Oneview.js are asynchronous. To ease the burden this places on program complexity, Oneview.js relies heavily on promises as implemented by Q, and many calls to Oneview.js will return promises.

  • Oneview.js runs an autoloader in lib/main.js. All files and directories in lib/oneview are treated as modules on oneview. Thus if you create lib/oneview/silly.js, it will be registered to oneview.silly. All Oneview.js modules are by default lazy, and will only be executed when they are first accessed in an application.

  • To use Oneview.js in a new node.js service, include it in your package.json like so:

{
  "dependencies": {
    "@iseatz.com/oneview": "0.5.2",
  }
}

This pulls the Oneview.js npm package from the private @iseatz npm repo. The next time you run npm install in your application, Oneview.js will be pulled into your node_modules.

  • Initialize your Oneview.js import in your application's main.js file like so:
var oneview = require('@iseatz/oneview').init({ name: 'ovsomething' });
  • All properties passed to oneview.init will be applied to oneview.conf's app: namespace as default values. Thus:
oneview.conf.get('app:name'); // => 'ovsomething'
  • Any other static configuration data is pulled by the conf module from /etc/oneview.d/(name).yml

Project Conventions

  • Name branches after their ticket number i.e. ONEVIEW-123. This ensures the original ticket can always be found in the branch's merge commit. It also helps other automated tools link code changes to a ticket.

  • Try to follow existing code style rather than introducing a new one -- even if it passes the linter. Code clarity is paramount.

  • If you do alter the code style, do it consistently across the entire repo in an easily identifiable commit.

Updating

Because Oneview.js is an imported npm package, when making a new version it is necessary to cut tags for both git and npm. The easiest way to do this is with the cut-release package. Push your changes (without bumping any version numbers) to the master branch of Oneview.js, npm install cut-release to your Oneview.js repo, and then just run node_modules/cut-release/bin/cut-release.js. It will ask you specific the type of version number bump you want, then will edit the version number on package.json, and then git push origin, git push origin --tags, and npm publish --tag latest. Make sure before you do so that you are logged in to npm with the iseatz.com account, or else the last step will fail.

Position in whole VM stack

+---------+      /------------\
| partner |<---->|   Node     |
+---------+      |  service   |
                 +------------+      /-------\ 
                 | Oneview.js |<---->|  OVN  |
                 \------------/      \-------/
                          /\                   /---------------\
                           \------------------>| Config/Redis/ |
                                               | Slog, etc.    |
                                               \---------------/

Modules

Broker

oneview.broker handles service calls to and from oneview services.

Gateway

oneview.gateway handles service calls to and from oneview services with promises and up-to-date error parsing

Conf

oneview.conf is an instance of nconf, loading config directives in the following order: argv, env, yaml file, oneview.init param object (from highest to lowest priority).

By convention, configuration should only be stored in an application's /etc/oneview.d/x.yml file. All other options are simply nice to have for out-of-band config directives and testing.

Learn more nconf documentation.

Logger

oneview.logger is an instance of winston with a custom zmq transport attached, which is enabled by default.

Learn more winston documentation.

Metrics

oneview.logger pushes metrics information out for transactions

Querulous

oneview.querulous interacts with iseatz' querulous data store. Beneath the cover is a redis cluster of master and replicas. In order to use querulous, you must have a valid configuration at /etc/oneview.d/querulous.yml

Schemas

The oneview.schema loader finds protobuffer FileDescriptorSets in pbr. This module relies on an accurate config value for oneview:pbrLocation.

Locator

oneview.locator tracks service types and locations in a oneview hive. It will discover service locations stored in querulous, and register the service you are running

Adding a service

oneview.locator.services holds references to service types. Simply add an entry and locator will do the rest.

Slog

Just a whole bunch of sloggin'

Net REPL

A network-accessible REPL is enabled by adding a port value to your application's 'oneview:replPort' config.

You can then attach to said REPL in your running application like so:

$ telnet 127.0.0.1 <oneview:replPort>

If your application is being run as a cluster, you will be placed in the scope of the master process. You may then access child processes using the cluster interface:

 ovapi > require('cluster').workers[0..];

Cluster

oneview.cluster provides a simple interface to run your appliction as a process cluster. Implementation is as simple as this:

new oneview.cluster();

The initial process becomes the master, and workers are spawned as subprocesses. If a worker dies, it will be immediately respawned regardless of exit code. Terminating the master will send a hangup to all workers.

oneview.cluster exposes an API to execute code exclusively within master and child processes. master and worker are available:

new oneview.cluster()
    .master(function () {
      oneview.locator.register();
    })
    .shared(function () { oneview.locator.bindDeregisterOnHalt(); });

cluster
  .workers(conf.get('oneview:numWorkers'))
  .worker(function () {
    server.listen(conf.get('server:port'));
  });

By default, the number of workers spawned will equal the number of CPUs on the machine. You may specify the number of workers using the workers method

The cluster will intialize itself after all chaining on the new oneview.cluster() is complete. If you feel like being explicit, you may call the start method:

new oneview.cluster()
  .master(function () {
    logger.info('I do not like convenience.');
  })
  .start();

Process clustering with oneview.cluster is highly recommended, as it frees the event loop of the master process to spin as quickly as it can, distributing work to eager workers as they become available. This produces highly responsive and reliable services.

Learn more cluster documentation

Clients

Oneview.js is currently used by two node-based applications:

  • OVAPI
  • OVLinks.
0.5.12

4 years ago

0.5.11

6 years ago

0.5.10

6 years ago

0.5.9

6 years ago

0.5.8

6 years ago

0.5.7

6 years ago

0.5.6

6 years ago

0.5.5

7 years ago

0.5.4

7 years ago

0.5.3

7 years ago

0.5.2

7 years ago

0.5.1

7 years ago

0.5.0

7 years ago

0.4.6

7 years ago

0.4.5

7 years ago

0.4.4

7 years ago

0.4.3

8 years ago

0.4.2

8 years ago

0.4.1

8 years ago

0.4.0

8 years ago

0.3.4

8 years ago

0.3.3

8 years ago

0.3.2

8 years ago

0.3.1

8 years ago

0.3.0

8 years ago

0.2.3

8 years ago

0.2.2

8 years ago

0.2.1

8 years ago

0.2.0

8 years ago

0.1.4

8 years ago

0.1.3

9 years ago