yahoo-eng-team team mailing list archive

[Launchpad Bug Tracker <1399683@xxxxxxxxxxxxxxxxxx>]

[Expired for cloud-init because there has been no activity for 60 days.]

** Changed in: cloud-init
       Status: Incomplete => Expired

-- 
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 cloud-init:
  Expired

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