Author: Dmitrii Shcherbakov
Revision Date: 2017-08-24 22:04:15 UTC

add a ceph bluestore spec

a basic spec which will test collocated data + wal + db

without pike & artful for now

Author: Dmitrii Shcherbakov
Revision Date: 2017-03-26 23:17:46 UTC

enable TLS for XMPP communication as of contrail 3

TLS is enabled unconditionally for contail 3.0 and above deployments to
make sure communication is secure by default.

XMPP clients are vrouter agents on compute nodes. XMPP servers are
contrail-control nodes.

Certificates are generated automatically from a PKI charm (e.g. easyrsa
with a Subject Alternative Name field containing an IP address on a
control network which is used by both contrail-control and
neutron-contrail to communicate with each other.

Using a Subject Alternative Name (SAN) with an IP address avoids a
dependency on a DNS infrastructure while keeping the communication
secure between endpoints that are related.

Client authentication by XMPP servers was not supported at the time of
writing hence there is no mention of that in the code.

As of Juju 2.x network spaces can be used if an underlying cloud
supports them. In order to facilitate that support one should bind
control-node endpoint to a specific network space. Otherwise, old
mechanisms such as unit private address are going to be used to retrieve
an ip address to be included into a certificate.

Control node address fetching mechanism has changed as well: instead of
just doing a relation-get for a private IP address of a control-node
unit a different value is taken from the relation data called
control_node_ip (available due to modifications on the contrail-control
side) - it is either an address in the network space which control-node
endpoint is bound to or a fall-back address (unit private address).

Author: Dmitrii Shcherbakov
Revision Date: 2017-03-26 17:43:56 UTC

enable TLS for XMPP communication as of contrail 3

TLS is enabled unconditionally for contail 3.0 and above deployments to
make sure communication is secure by default.

Certificates are generated automatically from a PKI charm (e.g. easyrsa
with a subject alternative name field containing an IP address on a
control network which is used by both contrail-control and
neutron-contrail to communicate with each other.

As of Juju 2.x network spaces can be used if an underlying cloud
supports them. In order to facilitate that support one should bind
control-node endpoint to a specific network space. Otherwise, old
mechanisms such as unit private address are going to be used to retrieve
an ip address to be included into a certificate.

Control node address fetching mechanism has changed as well: instead of
just doing a relation-get for a private IP address of a control-node
unit a different value is taken from the relation data called
control_node_ip (available due to modifications on the contrail-control
side) - it is either an address in the network space which control-node
endpoint is bound to or a fall-back address (unit private address).

Author: Dmitrii Shcherbakov
Revision Date: 2017-03-26 17:43:08 UTC

enable TLS for XMPP communication as of contrail 3

TLS is enabled unconditionally for contail 3.0 and above deployments to
make sure communication is secure by default.

XMPP clients are vrouter agents on compute nodes. XMPP servers are
contrail-control nodes.

Certificates are generated automatically from a PKI charm (e.g. easyrsa
with a Subject Alternative Name field containing an IP address on a
control network which is used by both contrail-control and
neutron-contrail to communicate with each other.

Using a Subject Alternative Name (SAN) with an IP address avoids a
dependency on a DNS infrastructure while keeping the communication
secure between endpoints that are related.

Client authentication by XMPP servers was not supported at the time of
writing hence there is no mention of that in the code.

As of Juju 2.x network spaces can be used if an underlying cloud
supports them. In order to facilitate that support one should bind
control-node endpoint to a specific network space. Otherwise, old
mechanisms such as unit private address are going to be used to retrieve
an ip address to be included into a certificate.

Control node address fetching mechanism has changed as well: instead of
just doing a relation-get for a private IP address of a control-node
unit a different value is taken from the relation data called
control_node_ip (available due to modifications on the contrail-control
side) - it is either an address in the network space which control-node
endpoint is bound to or a fall-back address (unit private address).

Author: Dmitrii Shcherbakov
Revision Date: 2017-03-23 15:10:31 UTC

enable rbac configuration support

- add an action to create roles which may then be configured for use by
contrail rbac mechanism
- render the required config file with the additional data provided via
config.yaml
- set relation data for use by other contrail charms

Author: Dmitrii Shcherbakov
Revision Date: 2017-03-15 11:04:51 UTC

add rbac relation data handling

- updated a check for the required contrail-api relation data depending
on whether rbac is present there
- updated the context and template code to ensure proper config file
rendering

Author: Dmitrii Shcherbakov
Revision Date: 2017-03-14 10:39:11 UTC

add rbac relation data handling

The context is already pre-loaded with all relation data, therefore,
the only change required is in the template.

Author: Dmitrii Shcherbakov
Revision Date: 2017-03-16 22:00:10 UTC

enable rbac relation data handling

- add config rendering logic (context, template)
- propagate the required settings to the neutron-api via subordinate
relation

Author: Dmitrii Shcherbakov
Revision Date: 2017-02-16 20:18:50 UTC

Add newton openstack upgrade spec

full_upgrade spec + ocata proposed and staging to full-next.yaml