Bug 1300405

Summary:	[RFE] Ability to partition /dev/sda on overcloud nodes
Product:	Red Hat OpenStack	Reporter:	David Hill <dhill>
Component:	rhosp-director	Assignee:	Steven Hardy <shardy>
Status:	CLOSED DUPLICATE	QA Contact:	Arik Chernetsky <achernet>
Severity:	high	Docs Contact:
Priority:	high
Version:	7.0 (Kilo)	CC:	bschmaus, cpaquin, csuleski, dhill, dtantsur, ebarrera, flg, jcoufal, jwoods, lmartins, mburns, mcornea, pkovacs, racedoro, rhel-osp-director-maint, shardy, sknauss, smulholland
Target Milestone:	---	Keywords:	FutureFeature
Target Release:	10.0 (Newton)
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Enhancement
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2016-11-25 14:23:28 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:

Description David Hill 2016-01-20 17:05:49 UTC

Description of problem:
We would like to be able to customize the partitioning of /dev/sda when imaging an overcloud node in such a way that we can do the following:

10% of /dev/sda for /var/log
40% of /dev/sda for /home
50% of /dev/sda for /


Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
1. Image a node and see 100% allocated for /dev/sda2 on /
2.
3.

Actual results:
Image a node and see 100% allocated for /dev/sda2 on /

Expected results:
Able to customize it

Additional info:
Some company policies requires /var/log to be on a different filesystem.  This might as well be the case for /var/lib/mysql

Comment 2 Mike Burns 2016-04-07 21:03:37 UTC

This bug did not make the OSP 8.0 release.  It is being deferred to OSP 10.

Comment 5 Lucas Alvares Gomes 2016-05-03 16:45:54 UTC

Hi @David,

Thanks for the RFE, Ironic is the software creates the basic partition layout and it's very opinionated about it, mostly because Ironic just writes to the disk a ready-to-deploy image and also does not touch any files inside the tenant's image (such as /etc/mtab). This is how image based deployed is envisioned which is different than an OS install deployment (such as anaconda) which gives you more flexibility about how to create the partition layout at deployment time.

Now, there are ways of doing it. If you want it at deploy time Ironic is able to deploy "whole disk images", which are an image that contains a partition table[0] already.

Or, this can be achieved in the post-deployment phase, at the first time the node boots the post-deploy scripts are responsible for creating such partitions and configuring the OS to use them (such as modifying /etc/mtab).

[0] http://docs.openstack.org/developer/ironic/deploy/install-guide.html#image-requirements

Hope that helps,
Lucas

Comment 6 Mike Burns 2016-05-03 17:06:40 UTC

I had a discussion at summit about this and the thought was that we could approach this with a post-config script, but it would require changing some of how we're doing deployments.

Currently, we're auto-resizing the image when we deploy from is default size of 4GB (I think that's its size) to fill the disk and mount it at /.  

We would need to deploy it without that resize, then have postconfig setup the partitioning layout and resize / appropriately.

Comment 14 Francisco Javier Lopez Y Grueber 2016-11-14 20:21:31 UTC

Do we have progress on this topic? 

A customized partitioning layout is one of the important requirements we have at customers for security reasons. 

This emphasizes the need for this feature.

Comment 15 Dmitry Tantsur 2016-11-25 14:23:28 UTC

Hi! The only way out right now is to use whole disk images, see http://docs.openstack.org/project-install-guide/baremetal/newton/configure-integration.html#create-and-add-images-to-the-image-service for how to create them. Otherwise advanced partitioning is planned (RFE 1381111), but is targeted to Pike (OSP 12).

*** This bug has been marked as a duplicate of bug 1381111 ***