On the latest centos 7 release, we are unable to resize our instances filesystems

[ubuntu-server-builder]

This bug was originally filed in Launchpad as LP: #1722992

Launchpad details

affected_projects = ['cloud-init (CentOS)']
assignee = None
assignee_name = None
date_closed = None
date_created = 2017-10-12T04:45:57.589762+00:00
date_fix_committed = None
date_fix_released = None
id = 1722992
importance = medium
is_complete = False
lp_url = https://bugs.launchpad.net/cloud-init/+bug/1722992
milestone = None
owner = jphilippemethot
owner_name = J-P methot
private = False
status = confirmed
submitter = jphilippemethot
submitter_name = J-P methot
tags = []
duplicates = [1723213]

Launchpad user J-P methot(jphilippemethot) wrote on 2017-10-12T04:45:57.589762+00:00

Since the CentOS 7 update to cloud-init 0.7.9, we've been unable to resize our instance's root drives. Of course, since root volume resize is not officially supported in openstack, what we do is a bit of hack. We basically shutdown the vm -> cinder reset-state --state available volume id -> cinder extend volume id size -> cinder reset-state --state in-use volume-id -> migrate the VM (to remake the iscsi mount) -> startup the VM. This increases the volume size and still works. The issue is when cloud-init needs to execute the growpart module.

See https://bugs.centos.org/view.php?id=13931

The only error we get is related to vendordata, which may be preventing the resize process to happen :
2017-09-28 02:01:43,641 - util.py[WARNING]: failed stage init
2017-09-28 02:01:43,641 - util.py[DEBUG]: failed stage init
Traceback (most recent call last):
File "/usr/lib/python2.7/site-packages/cloudinit/cmd/main.py", line 513, in status_wrapper
ret = functor(name, args)
File "/usr/lib/python2.7/site-packages/cloudinit/cmd/main.py", line 281, in main_init
init.update()
File "/usr/lib/python2.7/site-packages/cloudinit/stages.py", line 357, in update
self._store_vendordata()
File "/usr/lib/python2.7/site-packages/cloudinit/stages.py", line 381, in _store_vendordata
util.write_file(self._get_ipath('vendordata_raw'), raw_vd, 0o600)
File "/usr/lib/python2.7/site-packages/cloudinit/util.py", line 1755, in write_file
content = encode_text(content)
File "/usr/lib/python2.7/site-packages/cloudinit/util.py", line 154, in encode_text
return text.encode(encoding)
AttributeError: 'dict' object has no attribute 'encode'

This is on openstack Ocata though, and the vendordata has always been empty, as we use the default settings for it.

Cloud provider: we are the cloud provider, PlanetHoster, using Openstack Ocata.
version: Cloud-init 0.7.9-9.el7.centos.2

relevant cloud-init config:

cloud_init_modules:

• migrator
• bootcmd
• write-files
• growpart
• resizefs
• update_etc_hosts
• rsyslog
• users-groups
• ssh

[ubuntu-server-builder]

Launchpad user J-P methot(jphilippemethot) wrote on 2017-10-12T04:45:57.589762+00:00

Launchpad attachments: cloud-init.tar

[ubuntu-server-builder]

Launchpad user Scott Moser(smoser) wrote on 2017-10-12T18:50:46.092737+00:00

Any datasource that uses convert_vendordata is possibly affected.

This is bad in that it fails, but not as bad as it could be. Cloud-init
itself never re-constitutes the blob on disk. Its only a convenience for
the user.

What we should do:
a.) always have vendordata_raw be bytes
b.) write them as bytes to the file

We can still allow the datasource to use something like 'convert_vendordata'
intelligently to get types other than bytes. We just have to have
the 'get_vendordata' function access a different attribute in the datasource.

ie:

• DataSource.vendordata_raw should always be the raw bytes as found.
• get_vendordata would then use some other attribuate 'vendordata_converted' (?) to take advantage of the datasource specific knowlege.

[ubuntu-server-builder]

Launchpad user J-P methot(jphilippemethot) wrote on 2017-10-13T00:26:53.150876+00:00

After reading this comment, I still have a few question:

Regarding the vendordata error, is it confirmed that it's really the issue preventing growpart from running, or are the two problems unrelated?

Additionally, for the time being, is there a way I could circumvent that bug? Like setting some random, inconsequential vendor data in openstack so that it's not empty, for example?

[ubuntu-server-builder]

Launchpad user J-P methot(jphilippemethot) wrote on 2017-10-13T03:51:46.047221+00:00

Added cloud.cfg for reference
Launchpad attachments: cloud.cfg.txt

[TheRealFalcon]

The specific traceback referenced no longer exists. If there's still an issue to be addressed, feel free to reopen.