Updated openstack/openstack
Project: openstack/oslo.messaging  60b6a9fe9d713ea4e2cd8b5fd61ecb852ca3cfc7
null
python3: Switch to mox3 instead of mox

In order to transition to a python 3.x compatible world,
lets switch to mox3 which is python 3.x compatible drop-in
replacement of mox.

Change-Id: Iaa22779cd516f842c9f70828f863f90ddae0bab5
Updated openstack/openstack
Project: openstack/oslo.messaging  258299d3767c15cc3a7819e21c5c5461189d4076
null
Add release notes for 1.3.0a3

Change-Id: If97e1d695e498aac41aabbc1cea7cb9336b3b725
Updated openstack/openstack
Project: openstack/oslo.config  e6bcb78a70ddde28b4b26156546e680077d8cee5
null
Implemented support for custom opt types

Motivation:

Currently oslo.config supports only basic set of types:
strings, integers, floats, booleans, lists of strings and
dictionaries of strings. The reason of existence of types
other than string is to provide some kind of value
validation (e.g. that integer contains only digits).
There is a demand in community to have more complex value
checks, e.g. that a port configuration option contains
integer value that fits in certain range, host ip address
conforms to ip address format, etc.

Solution:

This patch introduces support for custom Opt types that
will allow a better control of value conversion and
validation. Custom types are presented as type
constructors - callable objects that take a string and
either return converted value or raise ValueError in
case value can't be converted. This concept is similar to
argument types in 'argparse' library.
Type constructor can be a class which instances are
callable, a function or any callable object (which allows
usage of parametriezed type class instances).

Details:

Oslo.config has Opt subclasses that control value
conversion and validation: StrOpt, IntOpt, FloatOpt, etc.
The type information is added to the base class - Opt -
cause otherwise it would introduce confusion on what class
to use when introducing e.g. NetworkPort: StrOpt or IntOpt.
For each existing Opt subclass a corresponding type was
implemented (see oslo.config.types).  StrOpt, IntOpt, etc.
classes are left for backward compatibility and present an
Opt class parametrized with particular type.

There are two exceptions of this rule: BoolOpt and
MultiStrOpt. Those classes define a special logic for
parsing values. BoolOpt was left unchanged and should be
used when someone wants a Boolean option that is available
through CLI.
MultiStrOpt has logic to accumulate values. As it was bound
to String type only, it's logic was extracted into a
MultiOpt class and MultiStrOpt was left as a subclass
parametrized with String type.

Opt values allow value substitution. Previously it worked
only for string types but now this feature only makes sense
if it would work on any type. _substitute() and _do_get()
methods of ConfigOpts class were updated to cover that.
Also, TemplateSubstitution tests were updated to ensure
that substitution is done before type conversion kicks in
or otherwise type conversion will fail (e.g. if Integer
type converted will get something like '$listen_port').

Advised review steps:

1. New type classes (oslo/config/types.py) and their tests
   (tests/test_types.py);
2. Changes to Str/Bool/Int/etc-Opt classes
   (those are pretty straight forward);
3. Other changes that add support for new types into
   existing infrastructure;
4. New cfg test cases added (mostly related to changes in
   substitution mechanics).

blueprint oslo-config-options-validation

Change-Id: I6910f1efa540cfe757b2be6da0aec072f8ed28fa