Files
openstacksdk/doc/source/users/guides/clustering/profile.rst
Monty Taylor 4bad718783 Rework config and rest layers
This is a large and invasive change to the underlying guts. Most casual
use should not notice a difference, but advanced users, especially those
using the Profile or Authenticator interfaces or making use of pluggable
providers will be broken.

The overall intent is to align directly on top of the mechanisms that
came from os-client-config for config and to use keystoneauth1's Adapter
interface to make use of the canonical implementations of such things as
service and version discovery. The end goal is that openstacksdk
provides the REST interaction layer for python-openstackclient, shade,
Ansible and nodepool.

Replace profile with openstack.config

os-client-config is used by shade and python-openstackclient to read
and process configuration. openstacksdk also can use the
os-client-config interface, but translates it internally into the
Profile object. As os-client-config has been injested into
openstack.config, remove Profile and just use the config classes.

Make proxy subclass of adapter

This gives every service a generic passthrough for REST calls, which
means we can map unknown service-type values to a generic proxy.

Strip endpoint_filter

We're passing Adapters around, not sessions. Doing so means that
self.service and endpoint_filter have become unnecessary.

Rename _Request.uri to _Request.url

This is a stepping-stone to replacing _Request with requests.Request and
using requests.Session.prepare_request inside of _prepare_request.

Rename service proxy instances to match their official service-type.

Aliases are kept for the old versions, but make the canonical versions
match the official name.

Rename bare_metal to baremetal
Rename cluster to clustering
Rename block_store to block_storage
Rename telemetry to meter

Create generic proxies for all services in STA

Every service listed in service types authority is an OpenStack service.
Even if we don't know about it in SDK, we should at the very least have
a low-level Adapter for it so that people can use REST calls while
waiting on the SDK to add higher-level constructs.

The pypy jobs are happily green. Run them as voting rather than
non-voting.

Add syntatic sugar alias for making connections

Typing:

  import openstack.connection
  conn = openstack.connection.Connection(cloud='example')

is annoying. This allows:

  import openstack
  conn = openstack.connect(cloud='example')

Use task_manager and Adapter from shade

As a stepping-stone towards shade and sdk codepaths being rationalized,
we need to get SDK using the Adapter from shade that submits requests
into the TaskManager. For normal operation this is a passthrough/no-op
sort of thing, but it's essential for high-volume consumers such as
nodepool.

This exposes a bunch of places in tests where we're mocking a bit too
deeply. We should go back through and fix all of those via
requests_mock, but that's WAY too much for today.

This was a 'for later' task, but it turns out that the move to Adapter
was causing exceptions to be thrown that were not the exceptions that
were intended to be caught in the SDK layer, which was causing
functional tests of things like GET operations to fail. So it became a
today task.

Change-Id: I7b46e263a76d84573bdfbbece57b1048764ed939
2017-11-15 11:46:50 -06:00

2.9 KiB

Managing Profiles

A profile type can be treated as the meta-type of a Profile object. A registry of profile types is built when the Cluster service starts. When creating a Profile object, you will indicate the profile type used in its spec property.

List Profiles

To examine the list of profiles:

../../examples/clustering/profile.py

When listing profiles, you can specify the sorting option using the sort parameter and you can do pagination using the limit and marker parameters.

Full example: manage profile

Create Profile

When creating a profile, you will provide a dictionary with keys and values specified according to the profile type referenced.

../../examples/clustering/profile.py

Optionally, you can specify a metadata keyword argument that contains some key-value pairs to be associated with the profile.

Full example: manage profile

Find Profile

To find a profile based on its name or ID:

../../examples/clustering/profile.py

The Cluster service doesn't allow updating the spec of a profile. The only way to achieve that is to create a new profile.

Full example: manage profile

Get Profile

To get a profile based on its name or ID:

../../examples/clustering/profile.py

Full example: manage profile

Update Profile

After a profile is created, most of its properties are immutable. Still, you can update a profile's name and/or metadata.

../../examples/clustering/profile.py

The Cluster service doesn't allow updating the spec of a profile. The only way to achieve that is to create a new profile.

Full example: manage profile

Delete Profile

A profile can be deleted after creation, provided that it is not referenced by any active clusters or nodes. If you attempt to delete a profile that is still in use, you will get an error message.

../../examples/clustering/profile.py