Bug 1259539

Summary: [ospd] No Swap Space allocated
Product: Red Hat OpenStack Reporter: Mike Burns <mburns>
Component: openstack-tripleo-heat-templatesAssignee: Marios Andreou <mandreou>
Status: CLOSED CURRENTRELEASE QA Contact: Shai Revivo <srevivo>
Severity: high Docs Contact:
Priority: high    
Version: 7.0 (Kilo)CC: alessandro, anande, augol, fdinitto, hbrock, jcoufal, jschluet, jslagle, jtaleric, kbasil, mandreou, mburns, mori, racedoro, rhel-osp-director-maint, sputhenp
Target Milestone: gaKeywords: Triaged
Target Release: 10.0 (Newton)   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 1245714
: 1425164 (view as bug list) Environment:
Last Closed: 2016-10-05 19:08:47 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 1245714    
Bug Blocks: 1425164    

Comment 2 Marios Andreou 2015-09-14 08:02:37 UTC
To get swap space in an instance you need to use Flavors that have swap space defined. I just confirmed that our current UI Flavours page doesn't have a swap space field so this needs to be added. Similarly the docs that show cli flavor creation should be ammended to add --swap. 

We already have individual flavor allocation per node type with --type-flavor params for each node type like --control-flavor --compute-flavor etc in the cli and these are mapped to tripleo heat template parameters like

./overcloud-without-mergepy.yaml:  OvercloudControlFlavor:
./overcloud-without-mergepy.yaml:  OvercloudComputeFlavor:
./overcloud-without-mergepy.yaml:  OvercloudBlockStorageFlavor:
./overcloud-without-mergepy.yaml:  OvercloudSwiftStorageFlavor:
./overcloud-without-mergepy.yaml:  OvercloudCephStorageFlavor:

To reiterate, we always need to use a flavor with a defined swap space and otherwise cannot launch an instance (an overcloud node in this case) with a swap space.  Thus I think we need two changes to accommodate this, UI and docs.

A slight complication here, is the fact that though the swap space on deployed nodes is created ok with this method, it is not enabled, as discussed at (upstream) https://bugs.launchpad.net/tripleo/+bug/1491335 - the workaround is a simple first boot script to enable it like at https://review.openstack.org/#/c/217796/1/firstboot/enable_swap.yaml - we either make this standard (land into downstream tht) until the bug is fixed, or we just document this workaround - we already have a section in the docs about defining firstboot scripts like https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux_OpenStack_Platform/7/html/Director_Installation_and_Usage/chap-Creating_Custom_Configuration.html#sect-Configuring_on_First_Boot

Comment 8 Marios Andreou 2016-03-17 14:49:05 UTC
The review by slagle at https://review.openstack.org/#/c/273752 "Support adding a swap file to overcloud nodes" uses the AllNodesExtraConfig interface to deliver a SoftwareConfig to run on all nodes before the puppet config is applied. This SoftwareConfig creates a 4096MB swap file at /swap (location and size are parameterized). 

To use this a deployer would have to override the default AllNodesExtraConfig and make it point to the extraconfig/all_nodes/swap.yaml - i.e.

  OS::TripleO::AllNodesExtraConfig: extraconfig/all_nodes/swap.yaml
  
in the resource registry. In the event that the AllNodesExtraConfig is already being used by the deployer (some of the partner integrations have made use of this interface) they can just include the SwapCOnfig and ControllerSwapDeployments for each node type from the swap.yaml into their own extraconfig file. 

The fix is also landed in stable/liberty upstream so should be available (possibly already is) in any new openstack-tripleo-heat-template builds

Comment 9 Mike McCune 2016-03-28 23:00:31 UTC
This bug was accidentally moved from POST to MODIFIED via an error in automation, please see mmccune with any questions

Comment 10 Mike Burns 2016-04-07 20:50:54 UTC
This bug did not make the OSP 8.0 release.  It is being deferred to OSP 10.

Comment 12 Jaromir Coufal 2016-10-05 19:08:47 UTC
Should be already in since OSP 8.