CMR scenario #1

This page refers to Cross model relations. See that page for background information.

In this example, we build a simple CMR infrastructure in step by step fashion, explaining each step along the way. A method of verifying the deployment is provided at the end.

This scenario describes a MediaWiki deployment, based within the same controller; used by the admin user, and consumed by multiple models.

The controller is called ‘aws-cmr’ and the model name is ‘cmr-model’.

Deploy the application

Deploy the application in the usual way. Extra resources have been requested via constraints, since this shared MySQL should be capable of servicing several remote applications.

juju deploy mysql --constraints "cores=4 mem=16G root-disk=1T"

The output to juju status --relations will eventually look similar to:

Model      Controller  Cloud/Region   Version    SLA          Timestamp
cmr-model  aws-cmr     aws/us-east-1  2.4-beta4  unsupported  21:38:59Z

App    Version  Status  Scale  Charm  Store       Rev  OS      Notes
mysql  5.7.22   active      1  mysql  jujucharms   58  ubuntu  

Unit      Workload  Agent  Machine  Public address  Ports     Message
mysql/0*  active    idle   0        107.22.17.48    3306/tcp  Ready

Machine  State    DNS           Inst id              Series  AZ          Message
0        started  107.22.17.48  i-05dc6ef01fd41735b  xenial  us-east-1a  running

Relation provider  Requirer       Interface  Type  Message
mysql:cluster      mysql:cluster  mysql-ha   peer

Now make the mysql application, and only that application, available to other models by referring to interface ‘mysql:db’ with the juju offer command:

juju offer mysql:db

See Managing relations for how to determine the interface used in the juju offer command.

The output will include the shared application’s endpoint:

Application "mysql" endpoints [db] available at "admin/cmr-model.mysql"

Where the offer URL is admin/cmr-model.mysql.

All available offer endpoints (per model) can be listed like so:

juju find-offers

In this example, the output is:

Store    URL                    Access  Interfaces
aws-cmr  admin/cmr-model.mysql  admin   mysql:db

Add a first consumer model and application

Add a consumer model and application. The application in this example will require a MySQL database and the objective is that it will use the one in the shared (CMR) model. The application we’ve chosen here is WordPress and we’ll refer to the MySQL offer URL in the juju add-relation command:

juju add-model wordpress-model
juju deploy wordpress
juju expose wordpress
juju add-relation wordpress:db admin/cmr-model.mysql

The last command has made use of a cross model relation.

The output to juju status --relations for this model will eventually settle down to look very much like:

Model            Controller  Cloud/Region   Version    SLA          Timestamp
wordpress-model  aws-cmr     aws/us-east-1  2.4-beta4  unsupported  17:55:45Z

SAAS   Status  Store    URL
mysql  active  aws-cmr  admin/cmr-model.mysql

App        Version  Status  Scale  Charm      Store       Rev  OS      Notes
wordpress           active      1  wordpress  jujucharms    5  ubuntu  exposed

Unit          Workload  Agent  Machine  Public address  Ports   Message
wordpress/0*  active    idle   0        54.166.154.178  80/tcp  

Machine  State    DNS             Inst id              Series  AZ          Message
0        started  54.166.154.178  i-0f73b697d5aaef377  trusty  us-east-1a  running

Relation provider       Requirer                Interface     Type     Message
mysql:db                wordpress:db            mysql         regular  
wordpress:loadbalancer  wordpress:loadbalancer  reversenginx  peer

Notice how the remote MySQL application shows up as a SAAS object. Its corresponding relation is also described:

Relation provider       Requirer                Interface     Type     Message
mysql:db                wordpress:db            mysql         regular

Applying the juju status command to the CMR model we see that the offer is now connected:

juju status -m cmr-model

Output:

.
.
.
Offer  Application  Charm  Rev  Connected  Endpoint  Interface  Role
mysql  mysql        mysql  58   1/1        db        mysql      provider

Add a second consumer model and application

Add a second consumer model and MySQL-based application. The application we’ve chosen now is MediaWiki.

juju add-model mediawiki-model
juju deploy mediawiki
juju expose mediawiki
juju add-relation mediawiki:db admin/cmr-model.mysql

The output to juju status --relations for this model will eventually become:

Model            Controller  Cloud/Region   Version    SLA          Timestamp
mediawiki-model  aws-cmr     aws/us-east-1  2.4-beta4  unsupported  18:07:38Z

SAAS   Status  Store    URL
mysql  active  aws-cmr  admin/cmr-model.mysql

App        Version  Status  Scale  Charm      Store       Rev  OS      Notes
mediawiki  1.19.14  active      1  mediawiki  jujucharms   19  ubuntu  exposed

Unit          Workload  Agent  Machine  Public address  Ports   Message
mediawiki/0*  active    idle   0        54.224.9.240    80/tcp  Ready

Machine  State    DNS           Inst id              Series  AZ          Message
0        started  54.224.9.240  i-0905beabb62c21ee9  trusty  us-east-1a  running

Relation provider  Requirer      Interface  Type     Message
mysql:db           mediawiki:db  mysql      regular

The new juju status output for model ‘cmr-model’ is not surprising. There are now two connections to the original offer:

.
.
.
Offer  Application  Charm  Rev  Connected  Endpoint  Interface  Role
mysql  mysql        mysql  58   2/2        db        mysql      provider

We can also inquire into currently shared endpoints within the ‘cmr-model’:

juju offers -m cmr-model
Offer  User   Relation id  Status  Endpoint  Interface  Role      Ingress subnets
mysql  admin  1            joined  db        mysql      provider  54.166.154.178/32
       admin  2            joined  db        mysql      provider  54.224.9.240/32

Verification

Verify that the remote application has responded to the two cross model relations by creating/preparing the necessary resources. In this example, we log in to the mysql unit via SSH, connect to MySQL, and list its databases:

juju ssh -m cmr-model mysql/0
mysql -u root --password=$(sudo cat /var/lib/mysql/mysql.passwd)
mysql> show databases;

The output should look similar to:

+-----------------------------------------+
| Database                                |
+-----------------------------------------+
| information_schema                      |
| mysql                                   |
| performance_schema                      |
| remote-9414c94f21db456d822045bb216c3b33 |
| remote-9cc8d09e87674e3487442a64751eb386 |
| sys                                     |
+-----------------------------------------+
6 rows in set (0.00 sec)

From the output we can see evidence of two databases that got created, one for each consumer application. Cool.

The juju status output for the wordpress model in 2.8 no longer contains the relation table any longer after adding the relation juju add-relation wordpress:db admin/default.mysql