-
Dimitris Aragiorgis authored
Up until now components were simple objects decoupled from fabric execution. Their methods were just returning a list of bash commands which utils module was executing in the correct context. This patch changes this rational. Specifically: A Component() gets initialized with an execution context that is a configuration snapshot of the target setup, cluster and node. A component implements the following helper methods: check, install, prepare, configure, restart, initialize, and test. All those methods will be executed on the target node with this order during setup. Additionally each Component class implements admin_pre, and admin_post methods which invoke actions on different components on the same execution context before and after installation. For example before a backend gets installed, its FQDN must resolve to the master floating IP, so we have to run some actions on the ns node and after installation we must add it to cyclades (snf-manage backend-add on the cyclades node). Component() inherits ComponentRunner() which practically exports the setup() method. This will first check if the required components are installed, will install them if not and update the status of target node. ComponentRunner() inherits FabricRunner() which practically wraps basic fabric commands (put, get, run) with the correct execution environment. The fabfile practically gets the target nodes for each role from the configuration and uses the roles module which knows the role-component mapping to get the target component with the proper execution context. Then it just invokes the setup() method. Each component gets initialized with an execution context and uses the config module for accessing global wide options. The context provides node, cluster, and setup related info. We introduce some helper decorators that wrap methods of Component class and update its execution context (self, self.ctx): - parse_* executes the wrapped method and parses the output. The desired vars (user_id, backend_id, user_uuid, etc.) are stored in the execution context and made available to other methods. - update_admin initializes the admin roles (NS, Astakos, Cyclades, etc.) of the current context and make them available under self.NS, self.ASTAKOS, etc. These have the same execution context of the current components besides the target node which gets derived from the corresponding config. - update_cluster_admin initializes the cluster's admin role and make it available under self.MASTER. - run_cmds runs the list of returned commands in the target node The update_ns() method of NS component gets the self.ctx.admin_fqdn and invokes nsupdate accordingly. Signed-off-by: Dimitris Aragiorgis <dimara@grnet.gr>
3699d1fe