diff --git a/ops-sunbeam/doc/concepts.rst b/ops-sunbeam/doc/concepts.rst index 19fe2361..99dfa76c 100644 --- a/ops-sunbeam/doc/concepts.rst +++ b/ops-sunbeam/doc/concepts.rst @@ -10,7 +10,7 @@ Sunbeam OpenStack is designed to help with writing charms that use the deployed on Kubernetes. For the rest of this document when a charm is referred to it is implied that it is a Charmed Operator framework charm on Kubernetes. -It general a charm interacts with relations, renders configuration files and +In general a charm interacts with relations, renders configuration files and manages services. Sunbeam Ops gives a charm a consistent way of doing this by implementing Container handlers and Relation handlers. @@ -28,7 +28,7 @@ and any additional derived settings. The relation handlers also setup event observers allowing them execute any common procedures when events are raised by the interface. When the charm initialises the interface it provides a callback function. The handler method -set be the observer first processes the event and then calls the charms +set by the observer first processes the event and then calls the charms callback method passing the event as an argument. Required Side Relation Handlers @@ -58,7 +58,7 @@ Apache. The Container handler manages writing configuration files to the container and restarting services. The charm can also query the handler to find the state of the container, configuration within the container and the status -of services within the container.a +of services within the container. When a Container handler is initialised the charm passes it a list of `ContainerConfigFile`. These objects instruct the handler which containers @@ -95,7 +95,7 @@ a third setting which is needed in a configuration file. Interfaces ---------- -An interface should live directly in a charm and be share via `charmcraft` +An interface should live directly in a charm and be shared via `charmcraft` the only exception to this is the peer relation. ASO provides a base peer interface and peer interface handler. This exposes methods which allow the lead unit of an application to share data with its peers. It also allows a leader to @@ -105,7 +105,7 @@ Templating ---------- Currently templates should be placed in `src/templates/`. If the charm is an -OpenStack charm the template file can be places in the subdirectory relating to +OpenStack charm the template file can be placed in the subdirectory relating to the relevant OpenStack release and the correct template will be selected. Charms diff --git a/ops-sunbeam/doc/howto-config-context.rst b/ops-sunbeam/doc/howto-config-context.rst index 151c218f..37c8df96 100644 --- a/ops-sunbeam/doc/howto-config-context.rst +++ b/ops-sunbeam/doc/howto-config-context.rst @@ -12,7 +12,6 @@ collecting the application name to construct the context. .. code:: python - class CinderCephConfigurationContext(ConfigContext): """Cinder Ceph configuration context.""" diff --git a/ops-sunbeam/doc/howto-expose-services.rst b/ops-sunbeam/doc/howto-expose-services.rst index 3f1ea62a..f7f3ab20 100644 --- a/ops-sunbeam/doc/howto-expose-services.rst +++ b/ops-sunbeam/doc/howto-expose-services.rst @@ -47,7 +47,7 @@ Charmed Kubernetes ++++++++++++++++++ For a Charmed Kubernetes deployment on bare metal MetalLB can also be -use for creation of LoadBalancer access to services. +used for creation of LoadBalancer access to services. `Operator Charms for MetalLB`_ exist but don't yet support BGP mode for ECMP (Equal Cost Multi Path) based load balancing by integrating directly @@ -94,7 +94,7 @@ Service Access ++++++++++++++ Once MetalLB has created a LoadBalancer configuration for a service its -external IP address will be populated in the service entry. Juju will +external IP address will be populated in the service entry. Juju will automatically pick this address for use as the ingress address for the service on relations (which is not ideal for service communication within the Kubernetes deployment) diff --git a/ops-sunbeam/doc/howto-pebble-handler.rst b/ops-sunbeam/doc/howto-pebble-handler.rst index ef26bb1f..fb11e9a6 100644 --- a/ops-sunbeam/doc/howto-pebble-handler.rst +++ b/ops-sunbeam/doc/howto-pebble-handler.rst @@ -15,8 +15,8 @@ Common Pebble handler changes ASO provides a pebble handler base classes which provide the starting point for writing a new handler. If the container runs a service then the `ServicePebbleHandler` should be used. If the container does not provide a -service (perhaps its just an environment for executing commands that effect -other container) then `PebbleHandler` should be used. +service (perhaps it's just an environment for executing commands that affect +other containers) then `PebbleHandler` should be used. .. code:: python @@ -37,7 +37,7 @@ available. sunbeam_chandlers.ContainerDir( '/var/log/my-service', 'root', - 'root'), + 'root')] In addition to directories the handler can list configuration files which need to be rendered into the container. These will be rendered as templates using @@ -97,7 +97,7 @@ with the event can be overridden. def _on_service_pebble_ready( self, event: ops.charm.PebbleReadyEvent - ) -> None: + ) -> None: """Handle pebble ready event.""" container = event.workload container.add_layer(self.service_name, self.get_layer(), combine=True) @@ -128,4 +128,3 @@ The charms `get_pebble_handlers` method dictates which pebble handlers are used. self.configure_charm, ) ] - diff --git a/ops-sunbeam/doc/howto-relation-handler.rst b/ops-sunbeam/doc/howto-relation-handler.rst index 1e5ca475..68b057ef 100644 --- a/ops-sunbeam/doc/howto-relation-handler.rst +++ b/ops-sunbeam/doc/howto-relation-handler.rst @@ -11,11 +11,10 @@ for the requires side. In this database interface the database charm expects the client to provide the name of the database(s) to be created. To model this the relation handler will require -the charm to specify the database name(s) when the class is instantiated +the charm to specify the database name(s) when the class is instantiated. .. code:: python - class DBHandler(RelationHandler): """Handler for DB relations.""" @@ -51,9 +50,9 @@ an observer for relation changed events. self.framework.observe(db_relation_event, self._on_database_changed) return db -The method runs when the changed event is seen checks whether all required data -has been provided. If it is then it calls back to the charm, if not then no -action is taken. +The method runs when the changed event is seen and checks whether all required +data has been provided. If it is then it calls back to the charm, if not then +no action is taken. .. code:: python @@ -138,5 +137,3 @@ see a handler already exists for database and not add the default one. handlers.append(self.db) handlers = super().get_relation_handlers(handlers) return handlers - -