Disable Swift from the Undercloud¶
The goal of this proposal is to introduce the community to the idea of disabling Swift on the TripleO Undercloud. Within this propose we intend to provide a high-level overview of how we can accomplish this goal.
Problem Description¶
Swift is being used to store objects related to the deployment which are managed entirely on the Undercloud. In the past, there was an API / UI to interact with the deployment tooling; however, with the deprecation of the UI and the removal of Mistral this is no longer the case. The Undercloud is assumed to be a single node which is used to deploy OpenStack clouds, and requires the user to login to the node to run commands. Because we’re no longer attempting to make the Undercloud a distributed system there’s no need for an API’able distributed storage service. Swift, in it’s current state, is under-utilized and carries unnecessary operational and resource overhead.
Proposed Change¶
Overview¶
Decommission Swift from the Undercloud.
To decommission Swift, we’ll start by removing all of the tripleoclient Swift interactions. These interactions are largely storing and retrieving YAML files which provide context to the user for current deployment status. To ensure we’re not breaking deployment expectations, we’ll push everything to the local file system and retain all of the file properties wherever possible. We will need coordinate with tripleo-ansible to ensure we’re making all direct Swift client and module interactions optional.
Once we’re able to remove the tripleoclient Swift interactions, we’ll move to disable Swift interactions from tripleo-common. These interactions are similar to the ones found within the tripleoclient, though tripleo-common has some complexity; we’ll need to ensure we’re not breaking expectations we’ve created with our puppet deployment methodologies which have some Swift assumptions.
Alternatives¶
We keep everything as-is.
Security Impact¶
There should be no significant security implications when disabling Swift. It could be argued that disabling Swift might make the deployment more secure, it will lessen the attack surface; however, given the fact that Swift on the Undercloud is only used by director I would consider any benefit insignificant.
Upgrade Impact¶
There will be no upgrade impact; this change will be transparent to the end-user.
Other End User Impact¶
None.
Performance Impact¶
Disabling Swift could make some client interactions faster; however, the benefit should be negligible. That said, disabling Swift would remove a service on the Undercloud, which would make setup faster and reduce the resources required to run the Undercloud.
Other Deployer Impact¶
Operationally we should see an improvement as it will no longer be required to explore a Swift container, and download files to debug different parts of the deployment. All deployment related file artifacts housed within Swift will exist on the Undercloud using the local file system, and should be easily interacted with.
Developer Impact¶
None, if anything disabling Swift should make the life of a TripleO developer easier.
Implementation¶
Excising Swift client interactions will be handled directly in as few reviews as possible; hopefully allowing us to backport this change, should it be deemed valuable to stable releases.
All of the objects stored within Swift will be stored in /var/lib/tripleo/{named_artifact_directories}. This will allow us to implement all of the same core logic in our various libraries just without the use of the API call to store the object.
In terms of enabling us to eliminate swift without having a significant impact on the internal API we’ll first start by trying to replace the swift object functions within tripleo-common with local file system calls. By using the existing functions and replacing the backend we’ll ensure API compatibility and lessen the likely hood of creating regressions.
Note
We’ll need to collaborate with various groups to ensure we’re porting assumed functionality correctly. While this spec will not go into the specifics implementation details for porting assumed functionality, it should be known that we will be accountable for ensuring existing functionality is ported appropriately.
Assignee(s)¶
- Primary assignee:
cloudnull
Other contributors:
emilien
ekultails
Work Items¶
The work items listed here are high level, and not meant to provide specific implementation details or timelines.
Enumerate all of the Swift interactions
Create a space on the Undercloud to house the files
This location will be on the local file system and will be created into a git archive; git is used for easier debug, rapid rollback, and will provide simple versioning.
Create an option to disable Swift on the Undercloud.
Convert client interactions to using the local file system
Ensure all tripleo-ansible Swift client calls are made optional
Convert tripleo-common Swift interactions to using the local file system
Disable Swift on the Undercloud
Dependencies¶
Before Swift can be disabled on the Undercloud we will need ensure the deployment methodology has been changed to Metalsmith.
Testing¶
The Swift tests will need to be updated to use the local file system, however the existing tests and test structure will be reused.
Documentation Impact¶
There are several references to Swift in our documentation which we will need to update.
