Left: | ||
Right: |
OLD | NEW |
---|---|
(Empty) | |
1 Subordinate Services | |
2 ==================== | |
3 | |
4 Services are composed of one or more service units. A service unit | |
5 runs the service's software and is the smallest entity managed by | |
6 juju. Service units are typically run in an isolated container on a | |
7 machine with no knowledge or access to other services deployed onto | |
8 the same machine. Subordinate services allows for units of different | |
9 services to be deployed into the same container and to have knowledge | |
10 of each other. | |
11 | |
12 | |
13 Motivations | |
14 ----------- | |
15 | |
16 Services such as logging, monitoring, backups and some types of | |
17 storage often require some access to the runtime of the service they | |
18 wish to operate on. Under the current modeling of services it is only | |
19 possible to relate services to other services with an explicit | |
20 interface pairing. Requiring a specified relation implies that every | |
21 charm author need be aware of any and all services a deployment might | |
22 wish to depend on, even if the other service can operate without any | |
23 explicit cooperation. For example a logging service may only require | |
24 access to the container level logging directory to function. | |
25 | |
26 The following changes are designed to address these issues and allow a | |
27 class of charm that can execute in the context of an existing | |
28 container while still taking advantage of the existing relationship | |
29 machinery. | |
30 | |
31 | |
32 Terms | |
33 ----- | |
34 | |
35 Principal service | |
36 A traditional service or charm in whose container subordinate | |
37 services will execute. | |
38 | |
39 Subordinate service/charm | |
40 A service designed for and deployed to the running container of | |
41 another service unit. | |
42 | |
43 Subordinate relation | |
44 A qualified relation type between principal services and their | |
45 subordinate service units. While modeled identically to | |
46 traditional relationships, juju only implements the relationship | |
47 between the unit of the principal and the subordinate service in | |
48 the same container. | |
49 | |
50 | |
51 Relations | |
52 --------- | |
53 | |
54 When a traditional relation is added between two services, all the | |
55 service units for the first service will receive relation events about | |
56 all service units for the second service. Subordinate services have a | |
57 very tight relationship with their principal service, so it makes | |
58 sense to be able to restrict that communication in some cases so that | |
59 they only receive events about each other. That's precisely what | |
60 happens when a relation is tagged as being a scoped to the | |
61 container. See :doc:`scoped relations<relation-scope>`. | |
62 | |
63 Container relations exist because they simplify responsibilities for | |
64 the subordinate service charm author who would otherwise always have | |
65 to filter units of their relation before finding the unit they can | |
66 operate on. | |
67 | |
68 If a subordinate service needs to communicate with all units of the | |
69 principal service, it can still establish a traditional | |
70 (non-container) relationship to it. | |
71 | |
72 In order to deploy a subordinate service a `scope: container` | |
73 relationship is required. Even when the principal services' charm | |
74 author doesn't provide an explicit relationship for the subordinate to | |
75 join, using an :doc:`implicit relation<implicit-relations>` with | |
76 `scope: container` will satisfy this constraint. | |
77 | |
78 | |
79 Addressability | |
80 -------------- | |
81 | |
82 No special changes are made for the purpose of naming or addressing | |
83 subordinate units. If a subordinate logging service is deployed with a | |
84 single unit of wordpress we would expect the logging unit to be | |
85 addressable as logging/0, if this service were then related to a mysql | |
86 service with a single unit we'd expect logging/1 to be deployed in its | |
87 container. Subordinate units inherit the public/private address of the | |
88 principal service. The container of the principal defines the network | |
89 setup. | |
90 | |
91 | |
92 Declaring Subordinate Charms | |
93 ---------------------------- | |
94 | |
95 When a charm author wishes to indicate their charm should operate as a | |
96 subordinate service only a small changes to the subordinate charms | |
97 metadata is required. Declaring a required interface with `scope: | |
98 container` in the interface definition of the charms metadata will | |
99 result in a subordinate deployment. Subordinate services may still | |
100 declare traditional relations to any service. The deployment is | |
101 delayed until a container relation is added. | |
102 | |
103 The example below shows adding a container relation to a charm. :: | |
104 | |
105 requires: | |
106 logging-directory: | |
107 interface: logging | |
108 scope: container | |
109 | |
110 | |
111 | |
112 Status of Subordinates | |
113 ---------------------- | |
114 | |
115 The status output contains details about subordinate units under the | |
116 status of the principal service unit that it is sharing the container | |
117 with. The subordinate unit's output matches the formatting of existing | |
118 unit entries but omits `machine`, `public-address` and `subordinates` | |
119 (which are all the same as the principal unit). | |
120 | |
121 The subordinate service is listed in the top level `services` | |
122 dictionary in an abbreviated form. The `subordinate-to: []` list is | |
123 added to the service which contains the names of all services this | |
124 service is subordinate to. `units` is displayed as a list of principal | |
125 unit names under which instances of this service are found. :: | |
126 | |
127 services: | |
128 logging: | |
129 charm: local:series/logging-1 | |
130 subordinate-to: [wordpress] | |
131 relations: {} | |
niemeyer
2012/01/23 14:49:41
This looks bogus. There's a relation in the exampl
bcsaller
2012/01/26 21:01:20
Indeed. Good catch
| |
132 wordpress: | |
133 machine: 0 | |
134 public-address: wordpress-0.example.com | |
135 charm: local:series/wordpress-3 | |
136 relations: {loggin: logging} | |
137 units: | |
138 wordpress/0: | |
139 relations: | |
140 logging: {state: up} | |
141 state: started | |
142 subordinates: | |
143 logging/0: | |
144 relations: | |
145 logging: {state: up} | |
146 | |
147 | |
148 | |
149 Usage | |
150 ----- | |
151 | |
152 Assume the following deployment:: | |
153 | |
154 juju deploy mysql | |
155 juju deploy wordpress | |
156 juju add-relation mysql wordpress | |
157 | |
158 Now we'll create a subordinate logging service:: | |
159 | |
160 juju deploy logging | |
161 juju add-relation logging mysql | |
162 juju add-relation logging wordpress | |
163 | |
164 This will create a logging service unit inside each of the containers | |
165 holding the mysql and wordpress units. The logging service has a | |
166 standard client-server relation to both wordpress and mysql but these | |
167 new relationships are implemented only between the principal unit and | |
168 the subordinate unit . A subordinate unit may still have standard | |
169 relations established with any unit in its environment as usual. | |
OLD | NEW |