openstack/puppet-openstacklib
Code Issues Proposed changes

Remove notes about aviator puppet module from README

Browse Source 
The aviator module was abandoned in favor of python-openstackclient

Change-Id: I0c32ad4900b1b4bc561a28bb15e3a26db47dbe7c
This commit is contained in:
Lukas Bezdicka 2016-02-01 12:03:58 +01:00
parent 8d374c39a2
commit 4ccb828137
1 changed files with 0 additions and 55 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

55
README.md
View File

@ -215,61 +215,6 @@ string; optional; default to '10'
Number of seconds between validation attempts;
string; optional; default to '2'
### Types and Providers
#### Aviator
#####`Puppet::add_aviator_params`
The aviator type is not a real type, but it serves to simulate a mixin model,
whereby other types can call out to the Puppet::add\_aviator\_params method in
order to add aviator-specific parameters to themselves. Currently this adds the
auth parameter to the given type. The method must be called after the type is
declared, e.g.:
```puppet
require 'puppet/type/aviator'
Puppet::Type.newtype(:my_type) do
# ...
end
Puppet::add_aviator_params(:my_type)
```
#####`Puppet::Provider::Aviator`
The aviator provider is a parent provider intended to serve as a base for other
providers that need to authenticate against keystone in order to accomplish a
task.
**`Puppet::Provider::Aviator#authenticate`**
Either creates an authenticated session or sets up an unauthenticated session
with instance variables initialized with a token to inject into the next request.
It takes as arguments a set of authentication parameters as a hash and a path
to a log file. Puppet::Provider::Aviator#authencate looks for five different
possible methods of authenticating, in the following order:
1) Username and password credentials in the auth parameters
2) The path to an openrc file containing credentials to read in the auth
parameters
3) A service token in the auth parameters
4) Environment variables set for the environment in which Puppet is running
5) A service token in /etc/keystone/keystone.conf. This option provides
backwards compatibility with earlier keystone providers.
If the provider has password credentials, it can create an authenticated
session. If it only has a service token, it initializes an unauthenciated
session and a hash of session data that can be injected into a future request.
**`Puppet::Provider::Aviator#make_request`**
After creating a session, the make\_request method provides an interface that
providers can use to make requests without worrying about whether they have an
authenticated or unauthenticated session. It takes as arguments the
Aviator::Service it is making a request at (for example, keystone), a symbol for
the request (for example, :list\_tenants), and optionally a block to execute
that will set parameters for an update request.
Implementation
--------------