← Back to team overview

yahoo-eng-team team mailing list archive

  1. yahoo-eng-team team
  2. Mailing list archive
  3. Message #25298

[Bug 1399683] [NEW] 0.7.5, centos7, openstack havana, mounts created for nonexistent devices

  Thread Previous • Date Previous • • Thread Next 
Public bug reported:


cloud-init 0.7.5 on centos 7, running in OpenStack Havana.

/etc/fstab entries are created for devices that do not exist on the
system.

[cbuben@cbc7gr4x1 ~]$ rpm -q cloud-init
cloud-init-0.7.5-10.el7.centos.1.x86_64

[cbuben@cbc7gr4x1 ~]$ blkid
/dev/vda1: UUID="abc9bf42-9fd1-41de-82df-48812c34a876" TYPE="ext4" 
/dev/vdb: LABEL="ephemeral0" UUID="91394da3-4d82-4f80-b466-24efd9f6e146" SEC_TYPE="ext2" TYPE="ext3" 
/dev/vdc: UUID="bc02e445-949e-4703-8c8c-ebfcfaea7d4c" TYPE="swap" 
/dev/vdd: SEC_TYPE="msdos" LABEL="config-2" UUID="F632-BDC3" TYPE="vfat" 

[cbuben@cbc7gr4x1 ~]$ grep -A5 mounts: /etc/cloud/cloud.cfg
mounts:
 - [ ephemeral0, /mnt/ephemeral0 ]
 - [ ephemeral1, /mnt/ephemeral1 ]
 - [ ephemeral2, /mnt/ephemeral2 ]
 - [ ephemeral3, /mnt/ephemeral3 ]

====> ACTUAL RESULTS

[cbuben@cbc7gr4x1 ~]$ cat /etc/fstab
#
# /etc/fstab
# Created by anaconda on Fri Dec  5 01:37:44 2014
#
# Accessible filesystems, by reference, are maintained under '/dev/disk'
# See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more info
#
UUID=abc9bf42-9fd1-41de-82df-48812c34a876 /                       ext4    defaults        1 1
/dev/vdb	/mnt/ephemeral0	auto	defaults,nofail,comment=cloudconfig	0	2
ephemeral1	/mnt/ephemeral1	auto	defaults,nofail,comment=cloudconfig	0	2
ephemeral2	/mnt/ephemeral2	auto	defaults,nofail,comment=cloudconfig	0	2
ephemeral3	/mnt/ephemeral3	auto	defaults,nofail,comment=cloudconfig	0	2
/dev/vdc	none	swap	sw,comment=cloudconfig	0	0


====> EXPECTED RESULTS

[cbuben@cbc7gr4x1 ~]$ cat /etc/fstab
#
# /etc/fstab
# Created by anaconda on Fri Dec  5 01:37:44 2014
#
# Accessible filesystems, by reference, are maintained under '/dev/disk'
# See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more info
#
UUID=abc9bf42-9fd1-41de-82df-48812c34a876 /                       ext4    defaults        1 1
/dev/vdb	/mnt/ephemeral0	auto	defaults,nofail,comment=cloudconfig	0	2
/dev/vdc	none	swap	sw,comment=cloudconfig	0	0


I believe this may be a regression in 0.7.3.

In 0.7.2, it seems like the following logic: https://github.com/cbuben
/cloud-init/blob/0.7.2/cloudinit/config/cc_mounts.py#L79-L81 sets the
mount point to None if the device with the given name does not exist.
Later on, in https://github.com/cbuben/cloud-
init/blob/0.7.2/cloudinit/config/cc_mounts.py#L149-L150 , the None value
in the field is used to skip the device.  On our EL6 systems, we run
this identical cloud.cfg and do NOT have this problem.

In 0.7.3 there was some refactoring to break out the cleanup of the
device name lookup, but otherwise the flow if the logic is the same.
However, if the device does not exist (i.e. sanitize_devname returns
None), the mount point is NOT set to the sentinel value None:
https://github.com/cbuben/cloud-
init/blob/0.7.3/cloudinit/config/cc_mounts.py#L100-L102 .  Then later,
in https://github.com/cbuben/cloud-
init/blob/0.7.3/cloudinit/config/cc_mounts.py#L160-L161 the same check
for "mount point is None" is applied.

If I re-add setting the mountpoint to None if the device with a given
name doesn't exist, correct behavior apperas to be restored:
https://github.com/cbuben/cloud-
init/compare/0.7.5...0_7_5_bad_devs_in_fstab

** Affects: cloud-init
     Importance: Undecided
         Status: New

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to cloud-init.
https://bugs.launchpad.net/bugs/1399683

Title:
  0.7.5, centos7, openstack havana, mounts created for nonexistent
  devices

Status in Init scripts for use on cloud images:
  New

Bug description:
  
  cloud-init 0.7.5 on centos 7, running in OpenStack Havana.

  /etc/fstab entries are created for devices that do not exist on the
  system.

  [cbuben@cbc7gr4x1 ~]$ rpm -q cloud-init
  cloud-init-0.7.5-10.el7.centos.1.x86_64

  [cbuben@cbc7gr4x1 ~]$ blkid
  /dev/vda1: UUID="abc9bf42-9fd1-41de-82df-48812c34a876" TYPE="ext4" 
  /dev/vdb: LABEL="ephemeral0" UUID="91394da3-4d82-4f80-b466-24efd9f6e146" SEC_TYPE="ext2" TYPE="ext3" 
  /dev/vdc: UUID="bc02e445-949e-4703-8c8c-ebfcfaea7d4c" TYPE="swap" 
  /dev/vdd: SEC_TYPE="msdos" LABEL="config-2" UUID="F632-BDC3" TYPE="vfat" 

  [cbuben@cbc7gr4x1 ~]$ grep -A5 mounts: /etc/cloud/cloud.cfg
  mounts:
   - [ ephemeral0, /mnt/ephemeral0 ]
   - [ ephemeral1, /mnt/ephemeral1 ]
   - [ ephemeral2, /mnt/ephemeral2 ]
   - [ ephemeral3, /mnt/ephemeral3 ]

  ====> ACTUAL RESULTS

  [cbuben@cbc7gr4x1 ~]$ cat /etc/fstab
  #
  # /etc/fstab
  # Created by anaconda on Fri Dec  5 01:37:44 2014
  #
  # Accessible filesystems, by reference, are maintained under '/dev/disk'
  # See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more info
  #
  UUID=abc9bf42-9fd1-41de-82df-48812c34a876 /                       ext4    defaults        1 1
  /dev/vdb	/mnt/ephemeral0	auto	defaults,nofail,comment=cloudconfig	0	2
  ephemeral1	/mnt/ephemeral1	auto	defaults,nofail,comment=cloudconfig	0	2
  ephemeral2	/mnt/ephemeral2	auto	defaults,nofail,comment=cloudconfig	0	2
  ephemeral3	/mnt/ephemeral3	auto	defaults,nofail,comment=cloudconfig	0	2
  /dev/vdc	none	swap	sw,comment=cloudconfig	0	0

  
  ====> EXPECTED RESULTS

  [cbuben@cbc7gr4x1 ~]$ cat /etc/fstab
  #
  # /etc/fstab
  # Created by anaconda on Fri Dec  5 01:37:44 2014
  #
  # Accessible filesystems, by reference, are maintained under '/dev/disk'
  # See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more info
  #
  UUID=abc9bf42-9fd1-41de-82df-48812c34a876 /                       ext4    defaults        1 1
  /dev/vdb	/mnt/ephemeral0	auto	defaults,nofail,comment=cloudconfig	0	2
  /dev/vdc	none	swap	sw,comment=cloudconfig	0	0

  
  I believe this may be a regression in 0.7.3.

  In 0.7.2, it seems like the following logic: https://github.com/cbuben
  /cloud-init/blob/0.7.2/cloudinit/config/cc_mounts.py#L79-L81 sets the
  mount point to None if the device with the given name does not exist.
  Later on, in https://github.com/cbuben/cloud-
  init/blob/0.7.2/cloudinit/config/cc_mounts.py#L149-L150 , the None
  value in the field is used to skip the device.  On our EL6 systems, we
  run this identical cloud.cfg and do NOT have this problem.

  In 0.7.3 there was some refactoring to break out the cleanup of the
  device name lookup, but otherwise the flow if the logic is the same.
  However, if the device does not exist (i.e. sanitize_devname returns
  None), the mount point is NOT set to the sentinel value None:
  https://github.com/cbuben/cloud-
  init/blob/0.7.3/cloudinit/config/cc_mounts.py#L100-L102 .  Then later,
  in https://github.com/cbuben/cloud-
  init/blob/0.7.3/cloudinit/config/cc_mounts.py#L160-L161 the same check
  for "mount point is None" is applied.

  If I re-add setting the mountpoint to None if the device with a given
  name doesn't exist, correct behavior apperas to be restored:
  https://github.com/cbuben/cloud-
  init/compare/0.7.5...0_7_5_bad_devs_in_fstab

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1399683/+subscriptions

Follow ups

References

  Thread Previous • Date Previous • • Thread Next