text:
[![Build Status](https://travis-ci.org/otherskins/puppet-ansible.svg?branch=master)](https://travis-ci.org/otherskins/puppet-ansible)  ![License](https://img.shields.io/badge/license-Apache%202-blue.svg) ![Version](https://img.shields.io/puppetforge/v/otherskins/ansible.svg) ![Downloads](https://img.shields.io/puppetforge/dt/otherskins/ansible.svg)

# Puppet module: Ansible

### Table of Contents

1. [Description](#module-description)
2. [Setup - The basics of getting started with ansible](#setup)
    * [What ansible affects](#what-ansible-affects)
    * [Setup requirements](#setup-requirements)
    * [Beginning with ansible](#beginning-with-ansible)
3. [Usage - Configuration options and additional functionality](#usage)
4. [Reference - An under-the-hood peek at what the module is doing and how](#reference)
5. [Limitations - OS compatibility, etc.](#limitations)

## Description

The ansible module installs and configures the Ansible across a range of operating systems and distributions.

## Setup

### What ansible affects
This module affects the ansible package across multiple distributions, manages all the parameters of the ansible.cfg configuration file, adds and removes entries in the /etc/ansible/hosts inventory file.

### Setup requirements
* Puppet >= 4.10
* Facter >= 2.0
* [Stdlib Module](https://github.com/puppetlabs/puppetlabs-stdlib)
* [Concat Module](https://github.com/puppetlabs/puppetlabs-concat)
* [Apt Module](https://github.com/puppetlabs/puppetlabs-apt)

### Beginning with ansible

`include ::ansible` is enough to get you up and running with default parameters.
You can pass the parameters to ansible's configuration, like this:

```yaml
class { 'ansible':
  ensure           => 'present',
  roles_path       => '/srv/roles',
  timeout          => 30,
  log_path         => '/var/log/ansible.log',
  private_key_file => '/etc/keys',
}
```

Do you want to manage the hosts file? Use the type defined `ansible::hosts` for creating entries.

```puppet
  ansible::hosts { 'webservers':
    entrys  => [
      '<IP_ADDRESS>',
    ]
  }
```

## Usage

To control all the parameters of the configuration file use the main `::ansible` class. See the common usages below for examples.

### Install ansible with default parameters

```puppet
include '::ansible'
```

### Install and specifying hosts

```puppet
include '::ansible'

ansible::hosts { 'databases':
  entrys  => [
    'dbmaster.com',
    'database.com',
  ]
}

ansible::hosts { 'webservers':
  entrys  => [
    '<IP_ADDRESS>',
    'web1.com',
  ]
}

ansible::hosts { 'loadbalancers':
  entrys  => [
    '<IP_ADDRESS>/24',
  ]
}
```

### Specific parameters to manage configuration file ansible.cfg

```puppet
class { 'ansible':
  ensure           => 'present',
  roles_path       => '/srv/roles',
  timeout          => 30,
  log_path         => '/var/log/ansible.log',
  private_key_file => '/etc/keys',
}
```

### Using hiera keys
This module don't use params class. Values of parameters can be used with Hiera v5:

```yaml
ansible::roles_path: '/srv/roles'
ansible::timeout: 30
ansible::log_path: '/var/log/ansible.log'
ansible::private_key_file: '/etc/keys'
```

# Reference

## Defined Types

* `ansible::hosts` - Set hosts entries

## Classes

### Public classes

* ansible: Main class, includes all other classes.

### Private classes

* ansible::install Handles the packages.
* ansible::config Handles the configuration file.
* ansible::repo::apt Handles the repository in the Debian based specific distributions.
* ansible::repo::yum Handles the repository in the RedHat based specific distributions.

## Parameters

The following parameters are available in the `::ansible` class:

#### `gather_timeout`

Optional.

Data type: Integer.

Description: Some hardware related facts are collected with a maximum timeout of 10 seconds. This option lets you increase or decrease that timeout to something more suitable for the environment.

Default value: `undef`.

#### `accelerate_timeout`

Optional.

Data type: Integer.

Description: This setting controls the timeout for receiving data from a client. If no data is received during this time, the socket connection will be closed. A keepalive packet is sent back to the controller every 15 seconds, so this timeout should not be set lower than 15 (by default, the timeout is 30 seconds)

Default value: `undef`.

#### `accelerate_port`

Optional.

Data type: Integer.

Description: This is the port to use for accelerated mode:

Default value: `undef`.

#### `command_timeout`

Optional.

Data type: Integer.

Description: The command timeout value defines the amount of time to wait for a command or RPC call before timing out. The value for the command timeout must be less than the value of the persistent connection idle timeout (connect_timeout).

Default value: `undef`.

#### `connect_retry_timeout`

Optional.

Data type: Integer.

Description: Configures the persistent connection retry timeout. This value configures the retry timeout that ansible-connection will wait to connect to the local domain socket. This value must be larger than the ssh timeout (timeout) and less than persistent connection idle timeout (connect_timeout). The default value is 15 seconds.

Default value: `undef`.

#### `connect_timeout`

Optional.

Data type: Integer.

Description: Configures the persistent connection timeout value in seconds.  This value is how long the persistent connection will remain idle before it is destroyed. If the connection doesn't receive a request before the timeout value expires, the connection is shutdown. The default value is 30 seconds.

Default value: `undef`.

#### `context`

Optional.

Data type: Integer.

Description: Set how many context lines to show in diff

Default value: `undef`.

#### `forks`

Optional.

Data type: Integer.

Description: This is the default number of parallel processes to spawn when communicating with remote hosts. Since Ansible 1.3, the fork number is automatically limited to the number of possible hosts at runtime, so this is really a limit of how much network and CPU load you think you can handle. Many users may set this to 50, some set it to 500 or more. If you have a large number of hosts, higher values will make actions across all of those hosts complete faster.

Default value: `undef`.

#### `poll_interval`

Optional.

Data type: Integer.

Description: For asynchronous tasks in Ansible (covered in Asynchronous Actions and Polling), this is how often to check back on the status of those tasks when an explicit poll interval is not supplied. The default is a reasonably moderate 15 seconds which is a tradeoff between checking in frequently and providing a quick turnaround when something may have completed.

Default value: `undef`.

#### `remote_port`

Optional.

Data type: Integer.

Description: This sets the default SSH port on all of your systems, for systems that didn’t specify an alternative value in inventory. The default is the standard 22.

Default value: `undef`.

#### `timeout`

Optional.

Data type: Integer.

Description: This is the default SSH timeout to use on connection attempts.

Default value: `undef`.

#### `max_diff_size`

Optional.

Data type: Integer.

Description: This controls the cutoff point (in bytes) on --diff for files set to 0 for unlimited (RAM may suffer!).

Default value: `undef`.

#### `nocows`

Optional.

Data type: Integer.

Description: Por padrão, Ansible irá aproveitar o Cowsay se instalado para criar /usr/bin/ansible-playbook é mais excitante. Por quê? Acreditamos que o gerenciamento de sistemas deve ser uma experiência feliz. Se você não gosta das vacas, pode desativá-las definindo 'nocows' para 1.

Default value: `undef`.

#### `nocolor`

Optional.

Data type: Integer.

Description: By default ansible will try to colorize output to give a better indication of failure and status information. If you dislike this behavior you can turn it off by setting ‘nocolor’ to 1.

Default value: `undef`.

#### `var_compression_level`

Optional.

Data type: Integer.

Description: Controls the compression level of variables sent to worker processes. At the default of 0, no compression is used. This value must be an integer from 0 to 9.

Default value: `undef`.

#### `sudo_flags`

Optional.

Data type: String.

Description: Additional flags to pass to sudo when engaging sudo support. The default is ‘-H -S -n’ which sets the HOME environment variable, prompts for passwords via STDIN, and avoids prompting the user for input of any kind. Note that ‘-n’ will conflict with using password-less sudo auth, such as pam_ssh_agent_auth. In some situations you may wish to add or remove flags, but in general most users will not need to change this setting.

Default value: `undef`.

#### `cow_selection`

Optional.

Data type: String.

Description: Set which cowsay stencil you'd like to use by default. When set to 'random', a random stencil will be selected for each task. The selection will be filtered against the `cow_whitelist` option below.

Default value: `undef`.

#### `cow_whitelist`

Optional.

Data type: String.

Description: # when using the 'random' option for cowsay, stencils will be restricted to this list. it should be formatted as a comma-separated list with no spaces between names. NOTE: line continuations here are for formatting purposes only, as the INI parser in python does not support them.

Default value: `undef`.

#### `action_plugins`

Optional.

Data type: String.

Description: Actions are pieces of code in ansible that enable things like module execution, templating, and so forth.

Default value: `undef`.

#### `cache_plugins`

Optional.

Data type: String.

Description: Set plugin path directories here, separate with colons.

Default value: `undef`.

#### `callback_plugins`

Optional.

Data type: String.

Description: Set plugin path directories here, separate with colons.

Default value: `undef`.

#### `diff_add`

Optional.

Data type: String.

Description: Parameter to change output color.

Default value: `undef`.

#### `special_context_filesystems`

Optional.

Data type: String.

Description: File systems that require special treatment when dealing with security context the default behaviour that copies the existing context or uses the user default needs to be changed to use the file system dependent context.

Default value: `undef`.

#### `changed`

Optional.

Data type: String.

Description: Parameter to change output color.

Default value: `undef`.

#### `unreachable`

Optional.

Data type: String.

Description: Parameter to change output color.

Default value: `undef`.

#### `debug`

Optional.

Data type: String.

Description: Parameter to change output color.

Default value: `undef`.

#### `error`

Optional.

Data type: String.

Description: Parameter to change output color.

Default value: `undef`.

#### `warn`

Optional.

Data type: String.

Description: Parameter to change output color.

Default value: `undef`.

#### `verbose`

Optional.

Data type: String.

Description: Parameter to change output color.

Default value: `undef`.

#### `highlight`

Optional.

Data type: String.

Description: Parameter to change output color.

Default value: `undef`.

#### `deprecate`

Optional.

Data type: String.

Description: Parameter to change output color.

Default value: `undef`.

#### `skip`

Optional.

Data type: String.

Description: Parameter to change output color.

Default value: `undef`.

#### `connection_plugins`

Optional.

Data type: String.

Description: Set plugin path directories here, separate with colons.

Default value: `undef`.

#### `lookup_plugins`

Optional.

Data type: String.

Description: Set plugin path directories here, separate with colons.

Default value: `undef`.

#### `inventory_plugins`

Optional.

Data type: String.

Description: Set plugin path directories here, separate with colons.

Default value: `undef`.

#### `vars_plugins`

Optional.

Data type: String.

Description: Set plugin path directories here, separate with colons.

Default value: `undef`.

#### `filter_plugins`

Optional.

Data type: String.

Description: Set plugin path directories here, separate with colons.

Default value: `undef`.

#### `diff_lines`

Optional.

Data type: String.

Description: Parameter to change output color.

Default value: `undef`.

#### `diff_remove`

Optional.

Data type: String.

Description: Parameter to change output color.

Default value: `undef`.

#### `test_plugins`

Optional.

Data type: String.

Description: Set plugin path directories here, separate with colons.

Default value: `undef`.

#### `terminal_plugins`

Optional.

Data type: String.

Description: Set plugin path directories here, separate with colons.

Default value: `undef`.

#### `strategy_plugins`

Optional.

Data type: String.

Description: Set plugin path directories here, separate with colons.

Default value: `undef`.

#### `strategy`

Optional.

Data type: String.

Description: # by default, ansible will use the 'linear' strategy but you may want to try another one

Default value: `undef`.

#### `ask_sudo_pass`

Optional.

Data type: String.

Description: Similar to ask_pass, this controls whether an Ansible playbook should prompt for a sudo password by default when sudoing. The default behavior is also no.

Default value: `undef`.

#### `remote_user`

Optional.

Data type: String.

Description: This is the default username ansible will connect as for /usr/bin/ansible-playbook. Note that /usr/bin/ansible will always default to the current user if this is not defined.

Default value: `undef`.

#### `ok`

Optional.

Data type: String.

Description: Parameter to change output color.

Default value: `undef`.

#### `log_path`

Optional.

Data type: String.

Description: If present and configured in ansible.cfg, Ansible will log information about executions at the designated location. Be sure the user running Ansible has permissions on the logfile.

Default value: `undef`.

#### `name_module`

Optional.

Data type: String.

Description: This is the default module name (-m) value for /usr/bin/ansible. The default is the ‘command’ module. Remember the command module doesn’t support shell variables, pipes, or quotes, so you might wish to change it to ‘shell’.

Default value: `undef`.

#### `jinja2_extensions`

Optional.

Data type: String.

Description: This is a developer-specific feature that allows enabling additional Jinja2 extensions.

Default value: `undef`.

#### `vault_password_file`

Optional.

Data type: String.

Description: Configures the path to the Vault password file as an alternative to specifying --vault-password-file on the command line.

Default value: `undef`.

#### `module_utils`

Optional.

Data type: String.

Description: The module_utils are python modules that Ansible is able to combine with Ansible modules when sending them to the remote machine. Having custom module_utils is useful for extracting common code when developing a set of site-specific modules. Ansible can look in multiple locations if you feed it a colon separated path, and it also will look for modules in the ./module_utils directory alongside a playbook.

Default value: `undef`.

#### `ansible_managed`

Optional.

Data type: String.

Description: This string can be helpful to indicate that a file should not be directly edited because Ansible may overwrite the contents of the file.

Default value: `undef`.

#### `sudo_user`

Optional.

Data type: String.

Description: This is the default user to sudo to if --sudo-user is not specified or ‘sudo_user’ is not specified in an Ansible playbook. The default is the most logical: ‘root’.

Default value: `undef`.

#### `inventory_ignore_extensions`

Optional.

Data type: String.

Description: Coma-separated list of file extension patterns to ignore when Ansible inventory is a directory with multiple sources (static and dynamic).

Default value: `undef`.

#### `transfer_method`

Optional.

Data type: String.

Description: Control the mechanism for transferring files (new). If set, this will override the scp_if_ssh option

Default value: `undef`.

#### `transport`

Optional.

Data type: String.

Description: Some basic default values.

Default value: `undef`.

#### `gather_subset`

Optional.

Data type: String.

Description: This only affects the gathering done by a play's gather_facts directive, by default gathering retrieves all facts subsets, all - gather all subsets, network - gather min and network facts, hardware - gather hardware facts (longest facts to retrieve), virtual - gather min and virtual facts, facter - import facts from facter, ohai - import facts from ohai, you can combine them using comma (ex: network,virtual), you can negate them using ! (ex: !hardware,!facter,!ohai), a minimal set of facts is always gathered.

Default value: `undef`.

#### `module_set_locale`

Optional.

Data type: String.

Description: This boolean value controls whether or not Ansible will prepend locale-specific environment variables (as specified via the module_lang configuration option). If enabled, it results in the LANG, LC_MESSAGES, and LC_ALL being set when the module is executed on the given remote system. By default this is disabled.

Default value: `undef`.

#### `host_key_checking`

Optional.

Data type: String.

Description: As described in Getting Started, host key checking is on by default in Ansible 1.3 and later. If you understand the implications and wish to disable it, you may do so here by setting the value to False.

Default value: `undef`.

#### `stdout_callback`

Optional.

Data type: String.

Description: This setting allows you to override the default stdout callback for ansible-playbook.

Default value: `undef`.

#### `gathering`

Optional.

Data type: String.

Description: The value ‘implicit’ is the default, which means that the fact cache will be ignored and facts will be gathered per play unless ‘gather_facts: False’ is set. The value ‘explicit’ is the inverse, facts will not be gathered unless directly requested in the play. The value ‘smart’ means each new host that has no facts discovered will be scanned, but if the same host is addressed in multiple plays it will not be contacted again in the playbook run. This option can be useful for those wishing to save fact gathering time. Both ‘smart’ and ‘explicit’ will use the fact cache.

Default value: `undef`.

#### `roles_path`

Optional.

Data type: String.

Description: The roles path indicate additional directories beyond the ‘roles/’ subdirectory of a playbook project to search to find Ansible roles. For instance, if there was a source control repository of common roles and a different repository of playbooks, you might choose to establish a convention to checkout roles in /opt/mysite/roles like so.

Default value: `undef`.

#### `ask_pass`

Optional.

Data type: String.

Description: Ask for privilege escalation password, the default is False.

Default value: `undef`.

#### `executable`

Optional.

Data type: String.

Description: This is the location of the ssh binary. It defaults to ssh which will use the first ssh binary available in $PATH. This config can also be overridden with ansible_ssh_executable inventory variable.

Default value: `undef`.

#### `sudo_exe`

Optional.

Data type: String.

Description: If using an alternative sudo implementation on remote machines, the path to sudo can be replaced here provided the sudo implementation is matching CLI flags with the standard sudo.

Default value: `undef`.

#### `control_path`

Optional.

Data type: String.

Description: This is the location to save ControlPath sockets. This defaults to.

Default value: `undef`.

#### `retry_files_save_path`

Optional.

Data type: String.

Description: The retry files save path is where Ansible will save .retry files when a playbook fails and retry_files_enabled is True (the default). The default location is adjacent to the play (~/ in versions older than 2.0) and can be changed to any writeable path.

Default value: `undef`.

#### `squash_actions`

Optional.

Data type: String.

Description: Ansible can optimise actions that call modules that support list parameters when using with_ looping. Instead of calling the module once for each item, the module is called once with the full list.

Default value: `undef`.

#### `become_method`

Optional.

Data type: String.

Description: Set the privilege escalation method. The default is sudo, other options are su, pbrun, pfexec, doas, ksu.

Default value: `undef`.

#### `remote_tmp`

Optional.

Data type: String.

Description: Ansible works by transferring modules to your remote machines, running them, and then cleaning up after itself. In some cases, you may not wish to use the default location and would like to change the path. You can do so by altering this setting.

Default value: `undef`.

#### `control_path_dir`

Optional.

Data type: String.

Description: This is the base directory of the ControlPath sockets. It is the %(directory)s part of the control_path option. This defaults to.

Default value: `undef`.

#### `ssh_args`

Optional.

Data type: String.

Description: If set, this will pass a specific set of options to Ansible rather than Ansible’s usual defaults.

Default value: `undef`.

#### `module_compression`

Optional.

Data type: String.

Description: Controls what compression method is used for new-style ansible modules when they are sent to the remote system.  The compression types depend on having support compiled into both the controller's python and the client's python. The names should match with the python Zipfile compression types: ZIP_STORED (no compression. available everywhere), ZIP_DEFLATED (uses zlib, the default) These values may be set per host via the ansible_module_compression inventory variable

Default value: `undef`.

#### `local_tmp`

Optional.

Data type: String.

Description: When Ansible gets ready to send a module to a remote machine it usually has to add a few things to the module: Some boilerplate code, the module’s parameters, and a few constants from the config file. This combination of things gets stored in a temporary file until ansible exits and cleans up after itself. The default location is a subdirectory of the user’s home directory. If you’d like to change that, you can do so by altering this setting.

Default value: `undef`.

#### `module_lang`

Optional.

Data type: String.

Description: This is to set the default language to communicate between the module and the system. By default, the value is value LANG on the controller or, if unset, en_US.UTF-8 (it used to be C in previous versions).

Default value: `undef`.

#### `inventory`

Optional.

Data type: String.

Description: Enable inventory plugins, default: 'host_list', 'script', 'yaml', 'ini'.

Default value: `undef`.

#### `hash_behaviour`

Optional.

Data type: String.

Description: If inventory variables overlap, does the higher precedence one win or are hash values merged together?  The default is 'replace' but this can also be set to 'merge'.

Default value: `undef`.

#### `library`

Optional.

Data type: String.

Description: Some basic default values.

Default value: `undef`.

#### `private_key_file`

Optional.

Data type: String.

Description: If set, always use this private key file for authentication, same as if passing --private-key to ansible or ansible-playbook

Default value: `undef`.

#### `callback_whitelist`

Optional.

Data type: String.

Description: Enable callback plugins, they can output to stdout but cannot be 'stdout' type.

Default value: `undef`.

#### `become_user`

Optional.

Data type: String.

Description: Ansible can use existing privilege escalation systems to allow a user to execute tasks as another. As of 1.9 ‘become’ supersedes the old sudo/su, while still being backwards compatible. Settings live under the [privilege_escalation] header.

Default value: `undef`.

#### `inventory_enabled`

Optional.

Data type: String.

Description: Enable inventory plugins, default: 'host_list', 'script', 'yaml', 'ini'.

Default value: `undef`.

#### `fact_caching`

Optional.

Data type: String.

Description: If set to a persistent type (not 'memory', for example 'redis') fact values from previous runs in Ansible will be stored.  This may be useful when wanting to use, for example, IP information from one group of servers without having to talk to them in the same playbook run to get their current IP information.

Default value: `undef`.

#### `scp_if_ssh`

Optional.

Data type: String.

Description: Control the mechanism for transferring files (old).

Default value: `undef`.

#### `display_skipped_hosts`

Optional.

Data type: Boolean.

Description: By default, ansible-playbook will display "Skipping [host]" if it determines a task should not be run on a host.  Set this to "False" if you don't want to see these "Skipping" messages. NOTE: the task header will still be shown regardless of whether or not the task is skipped.

Default value: `undef`.

#### `retry_files_enabled`

Optional.

Data type: Boolean.

Description: Retry files. When a playbook fails by default a .retry file will be created in ~/. You can disable this feature by setting retry_files_enabled to False and you can change the location of the files by setting retry_files_save_path.

Default value: `undef`.

#### `command_warnings`

Optional.

Data type: Boolean.

Description: Ansible can optionally warn when usage of the shell and command module appear to be simplified by using a default Ansible module instead.  These warnings can be silenced by adjusting the following setting or adding warn=yes or warn=no to the end of the command line parameter string.  This will for example suggest using the git module instead of shelling out to the git command.

Default value: `undef`.

#### `bin_ansible_callbacks`

Optional.

Data type: Boolean.

Description: By default callbacks are not loaded for /bin/ansible, enable this if you want, for example, a notification or logging callback to also apply to /bin/ansible runs

Default value: `undef`.

#### `become`

Optional.

Data type: Boolean.

Description: The equivalent of adding sudo: or su: to a play or task, set to true/yes to activate privilege escalation. The default behavior is no.

Default value: `undef`.

#### `allow_world_readable_tmpfiles`

Optional.

Data type: Boolean.

Description: This makes the temporary files created on the machine to be world readable and will issue a warning instead of failing the task.

Default value: `undef`.

#### `system_warnings`

Optional.

Data type: Boolean.

Description: Allows disabling of warnings related to potential issues on the system running ansible itself (not on the managed hosts).

Default value: `undef`.

#### `display_args_to_stdout`

Optional.

Data type: Boolean.

Description: By default, ansible-playbook will print a header for each task that is run to stdout. These headers will contain the name: field from the task if you specified one. If you didn’t then ansible-playbook uses the task’s action to help you tell which task is presently running. Sometimes you run many of the same action and so you want more information about the task to differentiate it from others of the same action. If you set this variable to True in the config then ansible-playbook will also include the task’s arguments in the header.

Default value: `undef`.

#### `pipelining`

Optional.

Data type: Boolean.

Description: Enabling pipelining reduces the number of SSH operations required to execute a module on the remote server, by executing many ansible modules without actual file transfer. This can result in a very significant performance improvement when enabled, however when using “sudo:” operations you must first disable ‘requiretty’ in /etc/sudoers on all managed hosts.

Default value: `undef`.

#### `sftp_batch_mode`

Optional.

Data type: Boolean.

Description: If False, sftp will not use batch mode to transfer files. This may cause some types of file transfer failures impossible to catch however, and should only be disabled if your sftp version has problems with batch mode

Default value: `undef`.

#### `allow_unsafe_lookups`

Optional.

Data type: Boolean.

Description: When enabled, this option allows lookups (via variables like {{lookup('foo')}} or when used as a loop with `with_foo`) to return data that is not marked "unsafe". This means the data may contain jinja2 templating language which will be run through the templating engine. ENABLING THIS COULD BE A SECURITY RISK

Default value: `undef`.

#### `accelerate_multi_key`

Optional.

Data type: Boolean.

Description: If set to yes, accelerate_multi_key will allow multiple private keys to be uploaded to it, though each user must have access to the system via SSH to add a new key. The default is "no".

Default value: `undef`.

#### `no_target_syslog`

Optional.

Data type: Boolean.

Description: Prevents logging of tasks, but only on the targets, data is still logged on the master/controller.

Default value: `undef`.

#### `merge_multiple_cli_flags`

Optional.

Data type: Boolean.

Description: This controls how ansible handles multiple --tags and --skip-tags arguments on the CLI.  If this is True then multiple arguments are merged together.  If it is False, then the last specified argument is used and the others are ignored. This option will be removed in 2.8.

Default value: `undef`.

#### `become_ask_pass`

Optional.

Data type: Boolean.

Description: Ask for privilege escalation password, the default is False.

Default value: `undef`.

#### `pty`

Optional.

Data type: Boolean.

Description: By default, Ansible requests a pseudo-terminal for commands executed under sudo. Uncomment this line to disable this behaviour.

Default value: `undef`.

#### `always`

Optional.

Data type: Boolean.

Description: Always print diff when running ( same as always running with -D/--diff )

Default value: `undef`.

#### `record_host_keys`

Optional.

Data type: Boolean.

Description: Uncomment this line to cause the paramiko connection plugin to not record new host keys encountered.  Increases performance on new host additions.  Setting works independently of the host key checking setting above.

Default value: `undef`.

#### `show_custom_stats`

Optional.

Data type: Boolean.

Description: Controls showing custom stats at the end, off by default

Default value: `undef`.

#### `any_errors_fatal`

Optional.

Data type: Boolean.

Description: Set default errors for all plays.

Default value: `undef`.

#### `host_key_auto_add`

Optional.

Data type: Boolean.

Description: When using persistent connections with Paramiko, the connection runs in a background process.  If the host doesn't already have a valid SSH key, by default Ansible will prompt to add the host key.  This will cause connections running in background processes to fail.  Uncomment this line to have Paramiko automatically add host keys.

Default value: `undef`.

#### `libvirt_lxc_noseclabel`

Optional.

Data type: Boolean.

Description: Set this to yes to allow libvirt_lxc connections to work without SELinux.

Default value: `undef`.

#### `look_for_keys`

Optional.

Data type: Boolean.

Description: Paramiko will default to looking for SSH keys initially when trying to authenticate to remote devices.  This is a problem for some network devices that close the connection after a key failure.  Uncomment this line to disable the Paramiko look for keys function

Default value: `undef`.

#### `task_includes_static`

Optional.

Data type: Boolean.

Description: Determine whether includes in tasks and handlers are "static" by default. As of 2.0, includes are dynamic by default. Setting these values to True will make includes behave more like they did in the 1.x versions.

Default value: `undef`.

#### `handler_includes_static`

Optional.

Data type: Boolean.

Description: Determine whether includes in tasks and handlers are "static" by default. As of 2.0, includes are dynamic by default. Setting these values to True will make includes behave more like they did in the 1.x versions.

Default value: `undef`.

#### `private_role_vars`

Optional.

Data type: Boolean.

Description: By default, variables from roles will be visible in the global variable scope. To prevent this, the following option can be enabled, and only tasks and handlers within the role will see the variables there

Default value: `undef`.

#### `error_on_missing_handler`

Optional.

Data type: Boolean.

Description: Controls if a missing handler for a notification event is an error or a warning.

Default value: `undef`.

#### `error_on_undefined_vars`

Optional.

Data type: Boolean.

Description: By default (as of 1.3), Ansible will raise errors when attempting to dereference Jinja2 variables that are not set in templates or action lines. Uncomment this line to revert the behavior to pre-1.3.

Default value: `undef`.

#### `no_log`

Optional.

Data type: Boolean.

Description: Prevents logging of task data, off by default.

Default value: `undef`.

#### `restrict_facts_namespace`

Optional.

Data type: Boolean.

Description: This keeps facts from polluting the main namespace as variables. Setting to True keeps them under the ansible_facts namespace, the default is False.

Default value: `undef`.

#### `deprecation_warnings`

Optional.

Data type: Boolean.

Description: Ansible may display deprecation warnings for language features that should no longer be used and will be removed in future versions.To disable these warnings, set the following value to False.

Default value: `undef`.

#### `network_group_modules`

Optional.

Data type: Tuple.

Description: This family of modules use an alternative execution path optimized for network appliances only update this setting if you know how this works, otherwise it can break module execution.

Default value: `undef`.

#### `accelerate_connect_timeout`

Optional.

Data type: Float.

Description: This setting controls the timeout for the socket connect call, and should be kept relatively low. The connection to the accelerate_port will be attempted 3 times before Ansible will fall back to ssh or paramiko (depending on your default connection setting) to try and start the accelerate daemon remotely. The default setting is 1.0 seconds.

Default value: `undef`.

#### `version`

Data type: String.

Description: Version of the ansible instalation.

Default value: `latest`.

#### `confdir`

Data type: String.

Description: Directory of configuration file.

Default value: `/etc/ansible`.

#### `package_name`

Data type: String.

Description: The name of package.

Default value: `ansible`.

#### `group`

Optional. Default user to ansible.

Data type: String.

Description: Default group of the user.

Default value: `root`.

#### `user`

Data type: String.

Description: Default user to ansible.

Default value: `root`.

#### `ensure`

Data type: String.

Description: Manage or unmanage Ansible.

Default value: `present`.

## Limitations

This module has been tested on:
  * Centos 6
  * Centos 7
  * Ubuntu 16.04
  * Ubuntu 14.04
  * Debian 8
  * Debian 9
  * Fedora 26
  * Oracle Linux
  * RedHat

## Development
Puppet modules on the Puppet Forge are open projects, and community contributions are essential for keeping them great. Please follow our guidelines when contributing changes.

For more information, see our [module contribution guide.](https://github.com/otherskins/puppet-ansible/blob/master/CONTRIBUTING.md)

## Contributors
* Edgar Silva -<EMAIL_ADDRESS>* Vincius Xavier -<EMAIL_ADDRESS>
## Copyright
* Otherskins, Inc.

repository: dgarcia-riq/puppet-ansible

gha_language: Puppet

repo_name: dgarcia-riq/puppet-ansible


text:
# Game of Life in Swift/Metal

```
make
```

### should work on either x86_64 or M1

```
metal-game % ./gameoflife
Metal device: <MTLIGAccelDevice: 0x7fd1791a5000>
    name = Intel(R) Iris(TM) Plus Graphics
```

<img src="screenshot.png" width=512/>

license: MIT

repository: krocki/metal-game

branch_name: refs/heads/main

extension: md

license_type: permissive

repo_name: krocki/metal-game


text:
## Getting Started
1. You'll need a recent version of docker engine and compose. Mine are installed as
part of the Docker Desktop for Mac bundle (v<IP_ADDRESS>, includes engine=18.09.2, compose=1.23.2).

1. If swarm isn't running, `docker swarm init`

1. Add your secrets. If you don't have APM credentials, head over to cloud.elastic.co and spin
up a cluster.
`printf "<your apm secret token>" | docker secret create apm-secret-token -`
`printf "<your apm server url>" | docker secret create apm-server-url -`

1. Get the code: `git clone <this repo>`

1. Build and deploy the stack: `sh deploy.sh`

1. You'll now have four math services running, and a math UI. Each service accepts two URL
parameters, `n1` and `n2`, and the response will contain the sum, difference, product, or quotient.
  - http://localhost:5000
  - http://localhost:5001/add?n1=1&n2=2
  - http://localhost:5002/subtract?n1=3&n2=4
  - http://localhost:5003/multiply?n1=5&n2=6
  - http://localhost:5004/divide?n1=7&n2=8

repository: choobinejad/elastic-apm-lab

branch_name: refs/heads/master

repo_name: choobinejad/elastic-apm-lab


text:
# Example use cases
    - Creating the database
      If you haven't done this, type 'make database' to create the database.
      It is located at postr/schedule/master_schedule.sqlite

    - Seeing jobs in the last 30 seconds
      To see jobs in the last 30 seconds, we can write two jobs, and then immediately scan for jobs.

      To write a job, do 'python -im postr.schedule.writer'
      Then, 'w = Writer()'
      Then, w.example()

      This will write two jobs, 5 seconds apart from each other. It will print 'done!' when finished.

      Next, do 'python -im postr.schedule.reader'
      Then, 'r = Reader()'
      Then, 'r = scan_custom_jobs()'

      This will return a JSON list of all jobs in the last 30 seconds.

      Its default paramater is 30 seconds.


text:
---
layout: default
---

# 1996-01-15 - Re: Phil Z getting through customs

## Header Data

From: attila<EMAIL_ADDRESS>To: Brad Shantz<EMAIL_ADDRESS>Message Hash: 547c3f943cf9ee501abeae28b351d38f402653fa1f2b02c22947b285fb2bc7df

Message ID<EMAIL_ADDRESS>Reply To<EMAIL_ADDRESS>UTC Datetime: 1996-01-15 08:39:32 UTC

Raw Date: Mon, 15 Jan 1996 16:39:32 +0800

## Raw message

```
{% raw  %}From: attila<EMAIL_ADDRESS>Date: Mon, 15 Jan 1996 16:39:32 +0800
To: Brad Shantz<EMAIL_ADDRESS>Subject: Re: Phil Z getting through customs
In-Reply-To<EMAIL_ADDRESS>Message-ID<EMAIL_ADDRESS>MIME-Version: 1.0
Content-Type: text/plain

    answer the questions truthfully and they can not detain you???

	yeah, that's what it says.  BS.  ask any of us who have been
    detained by the zealots.  I was detained 36 hours at LA, 18 at
    Dulles, etc.

	Rule 1:	 smile regardless of the adversity
	Rule 2:	 other than the three questions on the form, say nothing
	Rule 3:  never use LA or Dulles -pick an airport with humans.

	well, I guess I had better admit it; the travelling public got
    their money's worth in LA. after customs had shredded and Xray'd
    everything and I was tired, very tired after the long one from New
    Delhi to LA, I was hostile enough to humiliate them sufficiently to
    close all nearby lines --then I mooned them. TS and the red mask can
    be a wonderful excuse!  I guess I just havent learned --and I was over
    50!  Dulles was previous history....  oh, yeah, they have not bugged
    me for some time.

__________________________________________________________________________
    go not unto usenet for advice, for the inhabitants thereof will say:
      yes, and no, and maybe, and I don't know, and fuck-off.
_________________________________________________________________ attila__

    To be a ruler of men, you need at least 12 inches....

{% endraw %}
```

## Thread

+ Return to [January 1996](/archive/1996/01)

+ Return to "[attila <attila@primenet.com>](/authors/attila_attila_at_primenet_com_)"
+ Return to "["Brad Shantz" <bshantz@nwlink.com>](/authors/brad_shantz_bshantz_at_nwlink_com_)"

+ 1996-01-12 (Sat, 13 Jan 1996 01:06:20 +0800) - [Phil Z getting through customs](/archive/1996/01/7467993e153d0f7c77a8f45b1173bceff2cb426297d95118598751dd82721150) - _"Brad Shantz"<EMAIL_ADDRESS>  + 1996-01-15 (Mon, 15 Jan 1996 16:39:32 +0800) - Re: Phil Z getting through customs - _attila<EMAIL_ADDRESS>

gha_license_id: MIT


text:
# Example server

1. Build

```bash
go build server.go && ./server
```

2. Send requests to localhost:65534.

For example:

```bash
curl -X POST -H "Content-Type: application/json" --data '{"jsonrpc":"2.0","method":"healthStatus","params":{"message":""},"id":"1234"}' http://localhost:65534
```

or

```bash
curl -X POST -H "Content-Type: application/json" --data '{"jsonrpc":"2.0","method":"getHealthStatus","params":{"message":"123"},"id":"1234"}' http://localhost:65534
```

or

```bash
curl -X POST -H "Content-Type: application/json" --data '{"jsonrpc":"2.0","method":"getHealthStatus","id":"1234"}' http://localhost:65534
```

or

```bash
curl -X POST -H "Content-Type: application/json" --data '{"jsonrpc":"2.0","method":"getHealthStatus","params":{},"id":"1234"}' http://localhost:65534
```

repository: lillilli/jsonrpc

repo_name: lillilli/jsonrpc


text:
# Syntax error
Syntax errors prevent code from executing correctly. If a piece of code contains syntax errors, this most likely indicates that it is never run and thus is dead code that should be removed.

## Recommendation
Fix the syntax error. It may also be worth investigating whether the file containing the erroneous code fragment is ever included from anywhere. If it is not, then it is dead code, which should be removed.

## Example
In the following example, function `findBox` contains incomplete code: the string literal and its containing block statement are not properly terminated, leading to a syntax error.

```javascript
function findBox() {
  return $("box.important
```

## References
* Ecma International, *ECMAScript Language Definition*, 5.1 Edition, Section <IP_ADDRESS>. ECMA, 2011.


text:
# Naucoria salicis var. spadicea (D.A. Reid) E. Ludw., 2001 VARIETY

#### Status
SYNONYM

#### According to
The Catalogue of Life, 3rd January 2011

#### Published in
Pilzkompendium (Eching) 1([2]): 407 (2001)

#### Original name
Naucoria spadicea D.A. Reid, 1984

### Remarks
null

repository: mdoering/backbone

path: /life/Fungi/Basidiomycota/Agaricomycetes/Agaricales/Strophariaceae/Naucoria/Naucoria spadicea/ Syn. Naucoria salicis spadicea/README.md

repo_name: mdoering/backbone


text:
## Section 4: Pragmatic Paranoia

1. If DBC is so powerful, why isn't it used more widely?  Is it hard to come up with the contract?  Does it make you think about issues you'd rather ignore for now?  Does it force you to THINK?  Clearly, this is a dangerous tool!
2. What makes a good contract?  Anyone can add preconditions and postconditions, but will do you any good?  Worse yet, will they actually do more harm than good?  Decide if the following examples if the specified contract is good, bad or ugly and explain why.
   * First' let's look at an Eiffel exmaple.  Here we have a routine for adding a STRING to a doubly linked, circular list (remember that preconditions are labeled with require, and postconditions ensure)
```
-- Add a unique item to a doubly linked list,
-- and reutrn the newly created NODE
add_item (item : STRING) : NODE is
    require
       item /= Void                   -- '/=' is 'not equal'.
       find_item(item) = Void         -- Must be unique
    deferred                          -- Abstract base class.
    ensure
        result.next.previous = result -- Check the newly
        result.previous.next = result -- added node's links.
        find_item(item) = result      -- Shoudl find it.
    end
```

* Next let's try an example in Java-somewhat similar to the example above it inserts an integer into an ordered list. Pre-and postconditions are lableled as in iContract

```
private int data[];
/**
  * @post data[index-1] < data[index] &&
  *       data[index] == aValue
  */
public Node insertNumber (final int aValue)
{
    int index = findPlaceToInsert(aValue);
    ...
```
* Here's a fragment from a stack class in Java.  Is this a good contract?

```
/**
  * @pre anItem != null     // Require real data
  * @post pop() == anItem   // Verify that it's
  *                         // on the stack
  */
public void push(final String anItem)
```
3. The classic examlpes of DBC show and implementation of an Abstract Data Type (ADT)-- typically a stack or queue.  But not many people write these kidns of low-level classes.  Design an interface to a kitchen blender.  It will eventually be a web-based, intern-enbaled blender, but for now we just need the interface to control it.  It has ten speed settings (0 means off).  You can't operate it empty, you can change the speed only unit at a time.  Here are the methods.  Add approrpriate pre- and post conditions and an invariant.
```
int getSpeed()
void setSpeed(int x)
boolean isFull()
void fill()
void empty()
```
4. How many numbers are in teh series 0,5, 10, 15... 100?
5. A quick reality check.  Which of these "impossible" things can happen?
    * A month with fewer than 28 days
    * stat(".",&sb) == -1 (taht is, can't access the current directory)
    * In C++: a = 2; b =3; if (a + b != 5) exit (1);
    * A triangle with an interior angle sum ≠ 180°
    * A minute that doesnt have 60 seconds
    * In Java: (a + 1) <= a
6. Develop a simple assertion checking class for Ruby.
7. While desigining a new container class, you idenitify the following possible error conditions:
    * No memory available for a new element in the add routine
    * Requested entry not found in the fetch routine
    * null pointer passed to the add routine
8. How should each be handled?  Should an error be generated, shoudl an exception be raised, or shoud the condition be ignored?
9. Some C and C++ developers make a point of setting a pointer to NULL after they deallocate the memory it references.  Why is this a good idea?
10. Some Java developers make a point of setting an object variable to NULL after they have finished using the object.  Why is this a good idea?

repository: StrongMind/culture

gha_language: Ruby

repo_name: StrongMind/culture


text:
# PIPO
Program for the Investigation of Pursuing Objectives (in different creatures)

## Project for
* Intelligent Systems
* Intelligent Interfaces

## Authors
* Pamela Jiménez Rebenaque<EMAIL_ADDRESS>* Airam Manuel Navas Simón<EMAIL_ADDRESS>* Kevin Díaz Marrero<EMAIL_ADDRESS>* Jorge Sierra Acosta<EMAIL_ADDRESS>
## Records
[APK](https://drive.google.com/open?id=17g7tYbH74dhN2F856hqu6T8tr_TGyBYk)

[UnityNEAT](https://github.com/lordjesus/UnityNEAT)

[Game Unity project](https://drive.google.com/open?id=14U_4lWqVm_CRe3-H6riQn8gs2PSN_TZT)

[Training Unity project](https://drive.google.com/open?id=1qarURAvm1PKqzQ4ALgHL78Q3IwuzzoCy)

## Folders
* Scripts: Scripts used in the project (+ NEAT scripts)
* Slides & Doc: Slides and report used in Intelligent Systems

## Project summary
The project is based on the creation of a controlled virtual reality game with a command, where the player must go through different scenarios (similar to labyrinths), avoiding traps and enemies, and collecting lives and points.

Specifically, we will be chased by different creatures that will have two senses to analyze their environment: sight and hearing and then the possibility of adding the sense of smell has been considered.

They will have several neural networks that will not be created arbitrarily, but through genetic algorithms.

## Questions of use:

The use of this application is simple.

For installation, just download the apk that is in the repository on our mobile and install it. In addition to the glasses, you need a GamePad connected to the mobile device to move around in the game and we can crouch in the game by physically bending over thanks to the mobile accelerometer. In addition, producing sound through the microphone can be detected by the enemies within the game.

When executing, a menu appears with the three scenarios to which we can access. To select one, we must place the pointer of the grid in one of them for a few seconds. After this, a loading screen will appear.

Once the game starts, our objective will be to escape the enemies while we avoid the hidden traps on the ground (which will take away life if we step on them), we collect life containers (that will add life to a total of 100 life points), and we get points.

If an enemy or our HP (life points) catches up to us, we will have died and the Game Over screen will appear that will allow us to exit the game or return to the main menu.

## Milestones achieved and highlights
* Design of three own scenarios (barn, hospital and ship) with menus (start, end of departure and load screen).
  * Ambient sounds (music and characters) and effects.
  * Use of particle systems (fire, points and lives).
* Character design and animations.
  * Different enemies for each scenario.
* Movement of the character for exploration and pursuit through the neural network.
  * Pseudorandom behavior for enemies in each game.
* Sight and hearing sensor.
* Use of Android sensors.
  * Accelerometer: the character we control crouches if the person playing also does so, reducing their speed and sound emitted.
  * Microphone: the sound is detected by microphone and its range on the stage.
* Events implemented by controller.
  * Collection of lives and points (appear again randomly in the possible positions).
  * Activation of traps.
  * Death of the player.
  * Player caught by enemy.
* Virtual Reality in Google Cardboard.
* Option selection by reticle.
* Control of change of lights.
* Control of disparity in perception between the real world and the game.

## Authors and distribution of tasks

* Kevin
  * Search for assets.
  * Animation
  * Decoration of scenarios.
  * Interaction with buttons in VR.
  * Use of sensors (accelerometer).
  * Game Over screen design.
* Airam
  * Search for assets.
  * Modeling
  * Design and decoration of scenarios.
  * Union of scenes.
  * Use of sensors (microphone).
  * Implementation of the ear sensor.
  * Addition of ambient sounds and music.
  * Game Over screen design.
* Pamela
  * Search for assets.
  * Event control.
  * Design of traps, lives and points.
  * Design and decoration of maps.
  * Load screen design.
  * Scene change control.
* Jorge
  * Search for assets.
  * Configuration of neural networks.
  * Training of neural networks.
  * Design of the training map of neural networks.
  * Programming environmental scripts.
  * Implementation of the sight sensor.
  * Search for assets of environmental sounds.

## Algunas imágenes
![Img0](https://rawgit.com/Ediolot/pipo/master/Images/img0.png)
![Img1](https://rawgit.com/Ediolot/pipo/master/Images/img1.png)
![Img2](https://rawgit.com/Ediolot/pipo/master/Images/img2.png)

repository: AiramNavas/pipo

repo_name: AiramNavas/pipo


text:
# tennu-tell

A plugin for the [tennu](https://github.com/Tennu/tennu) irc framework.

MemoServ replacement with extra features. Purpose built specifically for my main IRC channel, time-tested by users.

Compatible with [tennu-cooldown](https://github.com/LordWingZero/tennu-cooldown).

### Usage
```
"tell": [
    "Save a tell for a user(s).",
    "{{!}}tell <nick1[,<nick2>,<nick3>]> <message>",
    "Example:",
    '{{!}}tell JaneDoe,FarmerGuy Hello World'
],
"tellrefresh": [
    "Re-pull down all tells from the DB into cache, delayed tells are cleared and restored into pending.",
    "Alias: !reloadtells"
],
"delaytells <duration>": [
    "This will hold your tells for a duration",
    "durations: 1d 5h 10s ect."
],
"forcetells": [
    "Forces out any delayed tells"
]
```

### Features
- Delay a tell from emitting with the duration of your choice
- Distinguishes between private and public tells depending on if you sent the tell directly to the bot.
- Plays tells back privately or publicly depending on if you pm the bot after recieving tells.
- Hooks into dbcore (We have a web interface where tells can be edited, so database storage is very useful)
- Prevents saving tells for the bot
- Prevents saving one tell to the same person twice ````!tell LordWingZero,LordWingZero hello world```` (filters out uniqe)

### Configuration
- **maxAtOnce** : Prevents people from saving > n tells at once.
```` Javascript
"tell":{
  "limitResults": 1,
  "floodDelay": 1500
}
````

### Installing Into Tennu

See Downloadable Plugins [here](https://tennu.github.io/plugins/).

### Todo:

- Tests

license: ISC

repository: Tennu/tennu-tell

gha_language: JavaScript

gha_license_id: ISC

repo_name: Tennu/tennu-tell


text:
---
layout: default
---

# 1997-02-07 - Re: ANNOUNCEMNT: February 1997 Cypherpunks Bay Area Meeting

## Header Data

From: Rich Graves<EMAIL_ADDRESS>To<EMAIL_ADDRESS>Message Hash: ac137a89609955c8afa95510ecbe23f7fe5c105b5afe95da967b77c26741f894

Message ID<EMAIL_ADDRESS>Reply To<EMAIL_ADDRESS>UTC Datetime: 1997-02-07 09:48:18 UTC

Raw Date: Fri, 7 Feb 1997 01:48:18 -0800 (PST)

## Raw message

```
{% raw  %}From: Rich Graves<EMAIL_ADDRESS>Date: Fri, 7 Feb 1997 01:48:18 -0800 (PST)
To<EMAIL_ADDRESS>Subject: Re: ANNOUNCEMNT: February 1997 Cypherpunks Bay Area Meeting
In-Reply-To<EMAIL_ADDRESS>Message-ID<EMAIL_ADDRESS>MIME-Version: 1.0
Content-Type: text/plain

A couple things need underscoring:

On Wed, 5 Feb 1997, Hugh Daniel wrote:

> Agenda: 11:++	setup, gossip, face feeding etc.
> 	12:00	USG Export 'Laws' of the week, Roz Thomsen, PGP inc.
        ^^^^^
Thomsen needs to leave early, so we will make every effort to "start on
time."

> 	  We have a wonderful space to do demos in this month, Turing
> 	Auditorium has Internet, projections screens, audio amps and
                       ^^^^^^^^
I.e., Ethernet, either 10BaseT or coax, no firewall. Please show up by 11:30
if you want an IP address.  One analog phone, in
case anyone wants one. I suppose we could still do live RealAudio and/or
CU-SeeMe iff someone feels they have something to say of such earth-
shattering importance that the whole net must hear. Otherwise, I'd rather
keep the distracting toys out of the way.

-rich
 www.stanford.edu/~llurch

{% endraw %}
```

## Thread

+ Return to [February 1997](/archive/1997/02)

+ Return to "[Hugh Daniel <hugh@west.toad.com>](/authors/hugh_daniel_hugh_at_west_toad_com_)"
+ Return to "[Rich Graves <llurch@networking.stanford.edu>](/authors/rich_graves_llurch_at_networking_stanford_edu_)"

+ 1997-02-05 (Wed, 5 Feb 1997 13:23:47 -0800 (PST)) - [ANNOUNCEMNT: February 1997 Cypherpunks Bay Area Meeting](/archive/1997/02/f78f51543cda0eb62f5b889ed5535004c0b5bb69d5ebf2f5db0fa4d5e570ddca) - _Hugh Daniel<EMAIL_ADDRESS>  + 1997-02-07 (Fri, 7 Feb 1997 01:48:18 -0800 (PST)) - Re: ANNOUNCEMNT: February 1997 Cypherpunks Bay Area Meeting - _Rich Graves<EMAIL_ADDRESS>


text:
---
layout: default
title: Getting Started with Fabric Composer
category: start
sidebar: sidebars/start.md
excerpt: Getting Started with Fabric Composer
---

# Getting started with Fabric Composer Application Development

To help get started with application development using the Fabric Composer Framework, this guide will talk you through downloading Fabric Composer, starting a Fabric, deploying a simple business network and submitting transactions.

This is all done using a simple business network  **Digital Property Network**

# What is the Digital Property Network?

This network will be expanded for other tutorials, but for this getting started we'll keep it simple. We going to model *Land Titles*, each of which has an owner, description, and a boolean saying if this property/land is up for sale.

```
asset LandTitle identified by titleId {
  o String   titleId
  o Person   owner
  o String   information
  o Boolean  forSale   optional
}
```

We'll also model the *Owner* as a Person (First,Last name).

```
participant Person identified by personId {
  o String personId
  o String firstName
  o String lastName
}
```

We want to be able to mark one of the titles for sale so we'll create a *RegisterPropertyForSale* transaction that will update the for sale flag.

```
transaction RegisterPropertyForSale identified by transactionId{
  o String transactionId
  --> Person seller
  --> LandTitle title
}
```

The applications we're going to look at are going to store a number of (pretend) land titles, and mark them for sale. All this will be using the Fabric Composer backed by a real blockchain in the shape of a locally executing Hyperledger Fabric.

# But what is an asset?
An is a term used to describe things of value both in the physical world and the equally real intangible world. These are stored in Asset Registries. Participants can act on these assets by submitting transactions. With the features of a blockchain provided by the Hyperledger Fabric, an application using Fabric Composer has a single source of truth for the state of these assets and their history.

It's worth reading the [Overview](../overview/overview.md) page to get an idea of how everything fits together. The [Glossary](../reference/glossary.md) provides a detailed description of each term.

# What are we going to do?
All the resources and scripts you'll need are in a git repository that we'll clone, this will have the code for the applications along with the scripts to get the Hyperledger setup and ready to go.

The first thing to do is to ensure that you have a suitable system ready for development.

### Development Prerequisites
First check that you are running on a [supported system](../reference/platforms.md) and install the required development [prerequisites](../tasks/prerequisites.md).  Essentially this means Linux/MacOS & node.js & docker & docker-compose & git

### Install the  Fabric Composer CLI
Installing the  Fabric Composer CLI tools module is the first step. This gives you commands to deploy, update and list business networks.

```bash
npm install -g composer-cli
```

### Clone the Getting Started Repository
Next you need to pull down the code for the Getting Started sample.

```bash
git clone git@github.com:fabric-composer/sample-applications.git
cd sample-applications/packages/getting-started
```

### Install the Dependencies, Start Fabric and Deploy the Business Network
Next you can run the following commands to install all the dependent Node modules for the sample, pull down the Docker images for Hyperledger Fabric, start the Fabric and then deploy a Business Network Definition.

```bash
npm install
```

This is doing quite a bit of work but at the end of it you will have all the dependent modules, together with a running local Hyperledger instance, and the DigitalProperty Network will have been deployed to that Hyperledger. At this point it doesn't contain any assets at all.

### Create Assets and Submit a Transaction
There are some simple applications included that will create some assets, list the current assets and submit a transaction.
First, the assets are created and the newly created assets are listed. Then a transaction is submitted to update one of the assets 'for sale'. A final asset listed is then queried to show the update has taken place. To run this end-end sequence issue...

```bash
npm test
```

### That's it
So to recap

* You installed Fabric Composer command line tools
* The 'Getting Started' repository was cloned
* All the code dependencies where pulled down, and a docker-hosted Hyperledger instance was Started
  * and the Digital Property Business Network was deployed to it
* A sample set of assets were added
* A simple transaction was invoked to update the assets

**All done!** But let's go ahead and make a change to start to show how easy it is to develop with Fabric Composer.

# Updating the Business Network

We are going to make a simple change to the business logic for the business network definition.

### Clone the Repository and Install Dependencies
First clone the repository:

```bash
git clone git@github.com:fabric-composer/sample-networks.git
cd sample-networks/packages/DigitalProperty-Network
npm install
```

### Update the Transaction Processor Function

Open the file `lib/DigitalLandTitle.js` in a text editor and replace the contents with:
{% highlight javascript %}

'use strict';

/** Process a property that is held for sale
 * @param {net.biz.digitalPropertyNetwork.RegisterPropertyForSale} propertyForSale the property to be sold
 * @transaction
 */
function onRegisterPropertyForSale(propertyForSale) {
    console.log('### onRegisterPropertyForSale ' + propertyForSale.toString());
    propertyForSale.title.forSale = true;

    /* new line is here to update the information */
    propertyForSale.title.information = propertyForSale.title.information + ' Updated at: ' + new Date().toDateString();

    return getAssetRegistry('net.biz.digitalPropertyNetwork.LandTitle').then(function(result) {
            return result.update(propertyForSale.title);
        }
    );
}
{% endhighlight %}

### Update the Business Network Definition
In a real-life scenario at this point you would edit `package.json` to increment the version number in the `DigitalProperty-Network` directory and publish this to npm. But please don't publish to the DigitalProperty-Network in npm - otherwise we'll have version numbers in the 1000s :-)

What we'll do therefore is adopt a different approach to create the Business Network Archive that is deployed to the Hyperledger.
From within the DigitalProperty-Network directory..

```bash
$ composer archive create --inputDir .
Creating Business Network Archive
Looking for package.json of Business Network Definition in /home/matthew/git17/DigitalProperty-Network

Description:Digital Property Network
Name:digitalproperty-network
Identifier:digitalproperty-network-0.0.22

Written Business Network Definition Archive file to digitalproperty-network-0.0.22.bna
Command completed successfully.
```

We now have a new file that is the digital business network archive.

### Update the deployed business network

```bash
$ composer network update --archiveFile<EMAIL_ADDRESS>--enrollId WebAppAdmin --enrollSecret DJY27pEnl16d
Deploying business network from archive digitalproperty-network-0.0.22.bna
Business network definition:
	Identifier: digitalproperty-network-0.0.22
	Description: Digital Property Network
Updating business network definition. This may take a few seconds...
Command completed successfully.
```

### Rerun the Test
If you go back to the getting started directory now - and list all the commands that available, you'll see one called `submitTransaction`

```bash
$ npm run
Lifecycle scripts included in composer-gettingstarted:
  test
    mocha --recursive && npm run bootstrapAssets && npm run listAssets && npm run submitTransaction
  install
    scripts/download-hyperledger.sh && scripts/start-hyperledger.sh && npm run deployNetwork

available via `npm run-script`:
  submitTransaction
    node cli.js landregistry submit && node cli.js landregistry list
  listAssets
    node cli.js landregistry list
  bootstrapAssets
    node cli.js landregistry bootstrap
  startHLF
    scripts/start-hyperledger.sh
  stopHLF
    scripts/stop-hyperledger.sh
  teardownHLF
    scripts/teardown.sh
  deployNetwork
    composer archive create -m digitalproperty-network --archiveFile digitalPropertyNetwork.zip && composer network deploy --archiveFile digitalPropertyNetwork.zip  --enrollId WebAppAdmin --enrollSecret DJY27pEnl16d && composer network list -n digitalproperty-network --enrollId WebAppAdmin --enrollSecret DJY27pEnl16d

```

If you issue this command, that will submit a transaction as before - but importantly this is the updated transaction function. You should now see:

```
$ npm run submitTransaction

><EMAIL_ADDRESS>submitTransaction
> node cli.js landregistry submit && node cli.js landregistry list

info: [Composer-GettingStarted] Fabric Composer: Getting Started application
info: [Composer-GettingStarted] LandRegistry:<init> businessNetworkDefinition obtained digitalproperty-network-0.0.11
info: [Composer-GettingStarted] updateForSale Getting assest from the registry.
info: [Composer-GettingStarted] updateForSale Submitting transaction
info: [Composer-GettingStarted] Transaction Submitted
info: [Composer-GettingStarted] Command completed successfully.
info: [Composer-GettingStarted] Fabric Composer: Getting Started application
info: [Composer-GettingStarted] LandRegistry:<init> businessNetworkDefinition obtained digitalproperty-network-0.0.11
=======

# Getting Started with Fabric Composer

First check that your system has the required software (at the required versions) installed:

[Supported Platforms](../reference/platforms.md)

If you need to update or install anything please refer to the install guides:

[Installing Prerequisites](../tasks/prerequisites.md)

# Clone the Sample Applications repository

```
git clone https://github.com/fabric-composer/sample-applications.git
```

# Install the Getting Started Application

```
cd sample-applications/
cd packages
cd getting-started
npm install
```

# Run the Getting Started Application

Run the `npm test` command. You should see output as below.

```
npm test

daniels-mbp:getting-started dselman$ npm test

><EMAIL_ADDRESS>test /Users/dselman/dev/git/sample-applications/packages/getting-started
> mocha --recursive && npm run bootstrapAssets && npm run listAssets && npm run submitTransaction

  Default
    #sample test
      ✓ should pass

  1 passing (8ms)

><EMAIL_ADDRESS>bootstrapAssets /Users/dselman/dev/git/sample-applications/packages/getting-started
> node cli.js landregistry bootstrap

info: [Composer-GettingStarted] Fabric Composer: Getting Started appliation
info: [Composer-GettingStarted] Adding default land titles to the asset registry
info: [Composer-GettingStarted] LandRegistry:<init> businessNetworkDefinition obtained<EMAIL_ADDRESS>info: [Composer-GettingStarted] LandRegistry:_bootstrapTitles getting asset registry for "net.biz.digitalPropertyNetwork.LandTitle"
info: [Composer-GettingStarted] about to get asset registry
info: [Composer-GettingStarted] LandRegistry:_bootstrapTitles got asset registry
info: [Composer-GettingStarted] LandRegistry:_bootstrapTitles getting factory and adding assets
info: [Composer-GettingStarted] LandRegistry:_bootstrapTitles Creating a person
info: [Composer-GettingStarted] LandRegistry:_bootstrapTitles Creating a land title#1
info: [Composer-GettingStarted] LandRegistry:_bootstrapTitles Creating a land title#2
info: [Composer-GettingStarted] LandRegistry:_bootstrapTitles Adding these to the registry
info: [Composer-GettingStarted] Default titles added
info: [Composer-GettingStarted] Command completed successfully.

><EMAIL_ADDRESS>listAssets /Users/dselman/dev/git/sample-applications/packages/getting-started
> node cli.js landregistry list

info: [Composer-GettingStarted] Fabric Composer: Getting Started appliation
info: [Composer-GettingStarted] LandRegistry:<init> businessNetworkDefinition obtained<EMAIL_ADDRESS>info: [Composer-GettingStarted] listTitles Getting the asset registry
info: [Composer-GettingStarted] listTitles Getting all assest from the registry.
info: [Composer-GettingStarted] listTitles Current Land Titles
info: [Composer-GettingStarted] Titles listed
info: [Composer-GettingStarted]
┌──────────┬────────────────┬────────────┬─────────┬─────────────────────────────┬─────────┐
│ TitleID  │ OwnerID        │ First Name │ Surname │ Description                 │ ForSale │
├──────────┼────────────────┼────────────┼─────────┼─────────────────────────────┼─────────┤
│ LID:6789 │ PID:1234567890 │ Fred       │ Bloggs  │ A small flat in the city    │ No      │
├──────────┼────────────────┼────────────┼─────────┼─────────────────────────────┼─────────┤
│ LID:1148 │ PID:1234567890 │ Fred       │ Bloggs  │ A nice house in the country │ No      │
└──────────┴────────────────┴────────────┴─────────┴─────────────────────────────┴─────────┘
info: [Composer-GettingStarted] Command completed successfully.

><EMAIL_ADDRESS>submitTransaction /Users/dselman/dev/git/sample-applications/packages/getting-started
> node cli.js landregistry submit && node cli.js landregistry list

info: [Composer-GettingStarted] Fabric Composer: Getting Started appliation
info: [Composer-GettingStarted] LandRegistry:<init> businessNetworkDefinition obtained<EMAIL_ADDRESS>info: [Composer-GettingStarted] updateForSale Getting assest from the registry.
info: [Composer-GettingStarted] updateForSale Submitting transaction
info: [Composer-GettingStarted] Transaction Submitted
undefined
info: [Composer-GettingStarted] Command completed successfully.
info: [Composer-GettingStarted] Fabric Composer: Getting Started appliation
info: [Composer-GettingStarted] LandRegistry:<init> businessNetworkDefinition obtained<EMAIL_ADDRESS>info: [Composer-GettingStarted] listTitles Getting the asset registry
info: [Composer-GettingStarted] listTitles Getting all assest from the registry.
info: [Composer-GettingStarted] listTitles Current Land Titles
info: [Composer-GettingStarted] Titles listed
info: [Composer-GettingStarted]

┌──────────┬────────────────┬────────────┬─────────┬───────────────────────────────────────────────────────────────────────────────────────┬─────────┐
│ TitleID  │ OwnerID        │ First Name │ Surname │ Description                                                                           │ ForSale │
├──────────┼────────────────┼────────────┼─────────┼───────────────────────────────────────────────────────────────────────────────────────┼─────────┤
│ LID:1148 │ PID:1234567890 │ Fred       │ Bloggs  │ A nice house in the country Updated at: Wed, 11 Jan 2017 Updated at: Wed, 11 Jan 2017 │ Yes     │
├──────────┼────────────────┼────────────┼─────────┼───────────────────────────────────────────────────────────────────────────────────────┼─────────┤
│ LID:6789 │ PID:1234567890 │ Fred       │ Bloggs  │ A small flat in the city                                                              │ No      │
└──────────┴────────────────┴────────────┴─────────┴───────────────────────────────────────────────────────────────────────────────────────┴─────────┘
info: [Composer-GettingStarted] Command completed successfully.
```

## Digging Deeper

Both `npm install` and `npm test` run commands defined in `package.json`. If you open `package.json` you will see that it uses the following utility scripts and commands.

```bash
test
    mocha --recursive && npm run bootstrapAssets && npm run listAssets && npm run submitTransaction
  install
    scripts/download-hyperledger.sh && scripts/start-hyperledger.sh && npm run deployNetwork

available via `npm run-script`:
  submitTransaction
    node cli.js landregistry submit && node cli.js landregistry list
  listAssets
    node cli.js landregistry list
  bootstrapAssets
    node cli.js landregistry bootstrap
  startHLF
    scripts/start-hyperledger.sh
  stopHLF
    scripts/stop-hyperledger.sh
  teardownHLF
    scripts/teardown.sh
  deployNetwork
    composer archive create -m digitalproperty-network --archiveFile digitalPropertyNetwork.zip && composer network deploy --archiveFile digitalPropertyNetwork.zip  --enrollId WebAppAdmin --enrollSecret DJY27pEnl16d && composer network list -n digitalproperty-network --enrollId WebAppAdmin --enrollSecret DJY27pEnl16d
```

* *npm test*  The standard test target runs some mocha based unti tests, then invokes two other npm run commands to store some test assets and submit a simple transaction.
* *npm install* This standard target installs the dependancies and also some some essential setup for the Fabric Composer Framework

Let's look at each of the other scripts and what they do - there are two main shell scripts that we have written that will control Hyperledger, some Fabric Composer commands and then the application.

**Shell scripts to control Hyperledger**

* `scripts/download-hyperledger.sh` This is a shell script that will download and tag the docker images for Hyperledger v0.6. It is important to note that this script will also delete the Fabric Composer Connection Profiles. This is important if you have connected to other Hyperledger Fabrics, or have changed the default ports that Hyperledger uses.

`npm install` uses this script.

* `scripts/start-hyperledger.sh` This is a shell script that starts the Hyperledger Fabric, this will also wait to make sure the Hyperledger fabric has started.
`npm run startHLF` can also be used to call this script.
* `scripts/stop-hyperledger.sh` This is the opposite of the start script, and will stop the Hyperledger Fabric - but it critically does not delete or remove any state. Therefore it canbe restarted with the start script.  `npm run stopHLF` can also be used to call this script.
* `scripts/teardown.sh` This will stop and remove all the docker images related to Hyperledger fabric. This can be used to do an effective clean-up of the Hyperledger Fabric and the Fabric Composer Connection Profiles.

**Composer CLI**

* `composer archive create -m digitalproperty-network --archiveFile digitalPropertyNetwork.zip`
This command is used to create a Business Network Archive. `--archiveFile` is the name of the file. The `-m` is the npm module name of the business network to use. There is also a -d option to specify the directory the business network is in. Useful whilst developing the business network transactions functions.

* `composer network deploy --archiveFile digitalPropertyNetwork.zip  --enrollId WebAppAdmin --enrollSecret DJY27pEnl16d`
This deploys the business network to the HyperLedger runtime; the archive is specified but also the Hyperledger Entrollment Id and Secret (the secret if not included in the command line will be prompted for)
* `composer network list -n digitalproperty-network --enrollId WebAppAdmin --enrollSecret DJY27pEnl16d`
This lists the deployed business network details. `-n` is the name of the business network. With the same options for the Hyperledger Entrollment Id and Secret (the secret if not included in the command line will be prompted for)

**Sample Applications**

There are 3 sample Javascript applications that use the Fabric Composer Client API to perform operations on the business network. These are applications that specific to the business network that has been defined in this Digital Property Network.

* `node cli.js landregistry submit`  This applications connects, and submits a transaction.
* `node cli.js landregistry list`   This lists the contents of the asset registries that have been defined in the business network.
* `node cli.js landregistry bootstrap` This applications puts some pretend assets into the registries to work with.

#Where next?
So we have downloaded the Hyperledger docker containers and stated a fabric. We have used the Fabric Composer Command line to deploy and update the DigitalProperty Network. We have used some Javascript applications in node.js to list assets and submit transactions to work on those assets.  A simple change and update has been made to one of the transaction functions.
=======
┌──────────┬────────────────┬────────────┬─────────┬─────────────────────────────┬─────────┐
│ TitleID  │ OwnerID        │ First Name │ Surname │ Description                 │ ForSale │
├──────────┼────────────────┼────────────┼─────────┼─────────────────────────────┼─────────┤
│ LID:6789 │ PID:1234567890 │ Fred       │ Bloggs  │ A small flat in the city    │ No      │
├──────────┼────────────────┼────────────┼─────────┼─────────────────────────────┼─────────┤
│ LID:1148 │ PID:1234567890 │ Fred       │ Bloggs  │ A nice house in the country │ Yes     │
└──────────┴────────────────┴────────────┴─────────┴─────────────────────────────┴─────────┘
info: [Composer-GettingStarted] Command completed successfully.

```

# Next Steps

[Command Line Usage](./getting-started-cmd-line.md)

[Generate a REST API](./getting-started-rest-api.md)

[Generate a Node.js App](./getting-started-nodejs-app.md)

[Coding a Business Network Definition](./getting-started-coding-bnd.md)

repository: ODOWDAIBM/fabric-composer

branch_name: refs/heads/develop

repo_name: ODOWDAIBM/fabric-composer


text:
ConnectionClose function
======

Closes an existing connection.

# Syntax

```C
typedef
_IRQL_requires_max_(PASSIVE_LEVEL)
void
(QUIC_API * QUIC_CONNECTION_CLOSE_FN)(
    _In_ _Pre_defensive_ __drv_freesMem(Mem)
        HQUIC Connection
    );
```

# Parameters

`Connection`

The valid handle to an open connection object.

# Remarks

`ConnectionClose` cleans up and frees all resources allocated for the connection in `ConnectionOpen`.

A caller should shutdown an active connection via [ConnectionShutdown](ConnectionShutdown.md) before calling `ConnectionClose`; calling `ConnectionClose` without [ConnectionShutdown](ConnectionShutdown.md) will implicitly call [ConnectionShutdown](ConnectionShutdown.md) with the `QUIC_CONNECTION_SHUTDOWN_FLAG_SILENT` flag.

A server application **MUST NOT** call `ConnectionClose` within the `QUIC_LISTENER_EVENT_NEW_CONNECTION` callback when returning failure, to reject a connection. This will result in a double-free in release builds, and an assert in debug builds.  It's acceptable to call `ConnectionClose` within the `QUIC_LISTENER_EVENT_NEW_CONNECTION` callback if returning `QUIC_STATUS_SUCCESS`, or `QUIC_STATUS_PENDING`, since the server application owns the connection object then.

`ConnectionClose` is the **last** API call to use a connection handle. An application **MUST NOT** use a connection handle after calling `ConnectionClose`! Any calls using a connection handle after calling `ConnectionClose` is a use-after-free.

# See Also

[ConnectionOpen](ConnectionOpen.md)

[ConnectionShutdown](ConnectionShutdown.md)

[ConnectionStart](ConnectionStart.md)

repository: microsoft/msquic

gha_language: C

repo_name: microsoft/msquic


text:
**Pre-Creation Checklist**
- [ ] All pre-PR checks have been run and they're passing:
  - The code is linted (running `npm run lint` produces no errors or warnings).  Appending `-- --fix` to the command fixes most JavaScript problems
  - The code passes unit tests (`npm run test`)
  - The code passes e2e tests (`npm start` in one terminal and `npm run e2e` in another)
  - Modifications to the project configuration files (e.g. `package.json`) were tested by executing `rm -rf node_modules && npm i && npm start` prior to executing the above tests.
- [ ] All git commits are tidy and formatted properly:
  - The code was committed using [Commit Message Guidelines](https://github.com/angular/angular/blob/master/CONTRIBUTING.md)
  - Extraneous commits were [squashed](https://github.com/1OneTeam/1OneApp/wiki/How_to-_squash_-commits) from the log via `git rebase -i` (or equivalent)
- [ ] All changes are covered by automated tests (if applicable):
  - Unit tests:
    - The positive or 'happy' path is covered.
    - Negative or 'sad' paths are covered (typically there are multiple sad-paths)
  - E2E tests have been updated (if applicable)

**Provide information that will benefit those doing this review:** _(The actual description of the code changes, including new features or relevant links, should be in the code-commit-messages under the 'long description' section, so that we retain an accurate record of the work in the codebase, not the PRs)_

**Applicable screenshots:**


text:
---
layout: basic
title: Get started with AeroGear.js
---

## Get Started With AeroGear.js

This article is going to show how to get started creating an HTML5 + Rest application using the AeroGear.js Javascript library.  This guide builds upon what you have learned in the [Get Started With HTML5 Mobile Web Development with JBoss](./GetStartedHTML5MobileWeb/) guide.

Topics Covered:

* What is a Pipeline?
* What is a Pipe?
* What is a DataManager?
* What is a Store?

## Prerequisites

* Java 6.0(Java SDK 1.6)+
* Maven 3+
* JBoss Application Server 7.1+
* JBoss Tools 3.3(optional)

An HTML5 compatible browser is required such as Chrome, Safari 5+, Firefox 5+, or IE 9+, and note that some behaviors will vary slightly (ex. validations) based on browser support, especially IE 9. For more details on AeroGear’s target browser support see [AeroGear Browser Support Targets](./AeroGearBrowserTargets/).

Mobile web support is limited to Android and iOS devices for now, however it should run on HP, and BlackBerry devices as well. Windows Phone, and others will work as jQuery Mobile announces support.

### Get The Example Code

To get started, if you are using git, you should clone a copy of the example

    $ git clone git@github.com:aerogear/kitchensink-aerogear-js.git && cd kitchensink-aerogear-js

If you are not using git, you can download the example from [here](https://github.com/aerogear/kitchensink-aerogear-js/archive/master.zip)

### Deploying

To deploy the application, first you will need to start up the JBoss Container.  To do this, run:

On linux/OSX

    $JBOSS_HOME/bin/standalone.sh -b <IP_ADDRESS>

On Windows

    $JBOSS_HOME\bin\standalone.bat -b <IP_ADDRESS>

_Note: Adding -b <IP_ADDRESS> to the above commands will allow external clients (phones, tablets, desktops, etc…) connect through your local network._

Once the JBoss Container is started, you can then run this command to build and deploy the application:

    $ mvn clean package jboss-as:deploy

Assuming the defaults, the application will now be running at [http://localhost:8080/jboss-as-kitchensink-aerogear-js/](http://localhost:8080/jboss-as-kitchensink-aerogear-js/)

If you followed the [Get Started With HTML5 Mobile Web Development with JBoss](./GetStartedHTML5MobileWeb/) guide,  you shouldn't see a difference in the User Interface.  The real difference is under the hood.

Lets dive in!

### Pipeline & Pipes

A Pipeline is a JavaScript library that provides a persistence API that is protocol agnostic and does not depend on any certain data model. Through the use of adapters, both provided and custom, user supplied, this library provides common methods like read, save and delete that will just work.

A Pipe is one server connection.  The default adapter is using the REST protocol.

To expand on this concept, lets look "under the hood" and see how this works.

    var memberPipe  = AeroGear.Pipeline([{
        name: "members",
        settings: {
            baseURL: "rest/"
        }
    }
 ]).pipes.members;

Whats happening here?  We are calling the Pipeline constructor with an array of objects as it's arguments.  In this case, it is just one object.

The object which will become a pipe.  We see that it has a name property and a settings object where we are overriding the baseURL property.  By default Pipes use the name property as the endpoint and baseURL for the REST service.  In this case, we are overriding the baseURL, so our REST call would look something like this:

    http://localhost/application_name/rest/members

### Data Manager & Stores

A Data Manager is a collection of data connections (stores) and their corresponding data models. This object provides a standard way to interact with client side data no matter the data format or storage mechanism used.

    var dm = AeroGear.DataManager( "membersStore" ),
        MemberStore = dm.stores["membersStore"];

Whats happening here?  Similar to the Pipeline and Pipe constructor,  we are creating a DataManager with a default Store( memory ) and then assigning that store to a variable for later use.

### Putting it together

Now that we have a little background on Pipeline and Data Manager, lets see how they work together in our application.

To get the list of members from the server, all we need to do is use the read() method on our pipe.

        memberPipe.read({
            success: function( data ) {
                ...
                $( "#members" ).html( buildMemberRows() );
            }
        });

Since our pipe is using the default REST adapter and we have overridden the baseURL property, the read method will make a request to http://localhost:8080/js-kitchensink/rest/members

We specify a success callback( an error callback should also be added ) and in the callback we add our data from the response to the MemberStore.

    MemberStore.save( data );

To access our data from the store, all we need to do is call the read() method on the store

    return _.template( $( "#member-tmpl" ).html(), {"members": MemberStore.read()});

We are using the default "Memory" adapter for our store, which is just an array.

## Wrapping Up

This tutorial is only a small part of what AeroGear.js can do.  Stay tuned for more Getting started guides.

gha_language: CSS