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
Note: 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 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.