From cd539bb52c3ca39fb48bdf4dc963a090f83c29e6 Mon Sep 17 00:00:00 2001 From: Paul Goins Date: Wed, 1 Sep 2021 15:59:05 -0700 Subject: [PATCH] Adding ncc-migration-ssh-auth-sharing spec Partial-bug: #1468871 Change-Id: If1c8a8754b8fa6429e6b5c13c9d3c1a5d140236b --- .../ncc-migration-ssh-auth-sharing.rst | 151 ++++++++++++++++++ 1 file changed, 151 insertions(+) create mode 100644 specs/xena/approved/ncc-migration-ssh-auth-sharing.rst diff --git a/specs/xena/approved/ncc-migration-ssh-auth-sharing.rst b/specs/xena/approved/ncc-migration-ssh-auth-sharing.rst new file mode 100644 index 0000000..9901996 --- /dev/null +++ b/specs/xena/approved/ncc-migration-ssh-auth-sharing.rst @@ -0,0 +1,151 @@ +.. + Copyright 2021 Canonical Ltd. + + This work is licensed under a Creative Commons Attribution 3.0 + Unported License. + http://creativecommons.org/licenses/by/3.0/legalcode + +.. + This template should be in ReSTructured text. Please do not delete + any of the sections in this template. If you have nothing to say + for a whole section, just write: "None". For help with syntax, see + http://sphinx-doc.org/rest.html To test out your formatting, see + http://www.tele3.cz/jbar/rest/rest.html + +================================================================================ +Sharing SSH authentication credentials across cloud-compute-related applications +================================================================================ + +Some cloud environments require different configuration settings +(e.g. allocation ratios) for different hosts, yet still need to allow +SSH-based migration between hosts. The proposed change in this spec +would allow sharing of credentials across multiple applications +related to the cloud-compute relation. + +Problem Description +=================== + +At present, the nova-cloud-controller charm gathers SSH public keys +for all cloud-compute-related applications. These SSH keys are then +shared as needed, but only to peers within the same related +application. + +While this is likely a sane default, especially considering that +different applications may represent different classes of compute +hosts which don't allow migration between them (e.g. SRIOV +vs. non-SRIOV), there are cases where there is no fundamental reason +to disallow migration. + +In cases like this, at present it's necessary to manually modify +configuration files, perhaps setting them immutable, to provide the +different configuration values needed for the different types of +hosts, yet still allow them to perform migrations between each other. + +Thus, it is believed it would be beneficial to allow for sharing all +SSH keys across all nova-compute applications to overcome those +limitations. + +This specification is meant to address an implementation for the +following feature request on Launchpad: +https://bugs.launchpad.net/charms/+source/nova-cloud-controller/+bug/1468871 + +Proposed Change +=============== + +Share SSH keys across all nova-compute applications through the +cloud-compute relation with the nova-cloud-controller charm. + +The code will now also have to go through each cloud-compute +relation whenever there is an update to a node or SSH key, in +order to keep the SSH keys on all compute nodes of all relations +consistent. + +Upgrade Impact +-------------- + +Upon upgrading the nova-cloud-controller charm version, the +upgrade-charm hook code will cycle through all cloud-compute +relations and set the relation data with all SSH authorized +keys and known hosts to all compute nodes in the relations. + +Performance Impact +------------------ + +Performance is slightly impacted as the hooks will take longer both +on the nova-cloud-controller charm to set a now higher number of +SSH keys and on each the nova-compute charms to process that higher +number of SSH keys received on the relation. The number of hooks +executed remains the same. + +On cloud-compute-relation-changed hooks, when a change on SSH keys +is triggered by the compute node, or if a new compute node is added, +the code will also take slightly longer due to cycling through all +the relations to make all SSH keys on all compute nodes consistent, +where before it only needed to update the relation pertaining to the +compute node that triggered the change. + +Alternatives +------------ + +One alternative may be to write a subordinate charm simply for the +purpose of sharing SSH keys and known hosts entries. While this could +in theory be done, it is less than ideal because that effectively +would create two sources of truth regarding which hosts should share +credentials with which hosts, and it would effectively replicate a +non-trivial amount of logic already handled by +charm-nova-cloud-controller. + +Implementation +============== + +Assignee(s) +----------- + +Primary assignee: + Rodrigo Barbieri + Paul Goins + +Gerrit Topic +------------ + +Use Gerrit topic "migration-ssh-auth-sharing" for all patches related to this spec. + +.. code-block:: bash + + git-review -t migration-ssh-auth-sharing + +Work Items +---------- + +* Allow for sharing across all cloud-compute-related applications + +Repositories +------------ + +The changes would be isolated to the charm-nova-cloud-controller +repository. + +Documentation +------------- + +The release notes for the new charm release that includes this change +should mention the new behavior. + +Security +-------- + +No security concerns are raised given that all the nova-compute charm +applications are part of the same environment and connected to the +same nova-cloud-controller nodes. + +Testing +------- + +This functionality can be tested via unit tests. Functional tests may +be overly cumbersome for this particular feature, although direct +testing in a lab environment should also be done as a sanity check. + +Dependencies +============ + +N/A