Yaml.load() return Python object may be dangerous if you receive
a YAML document from an untrusted source such as the Internet.
The function yaml.safe_load() limits this ability to simple Python
objects like integers or lists.
Reference:
https://security.openstack.org/guidelines/dg_avoid-dangerous-input-parsing-libraries.html
Change-Id: I5fb95063402e5adffeee0c2ead7adfd44eb76179
In our usecases the separate partition is not needed. It is enough just
to put cloudinit configuration into the root filesystem.
This also allows to avoid a race condition which sometimes happens: some
process deletes the folder in tmp where the configuration partition is
mounted resulting in cloudinit failure to read its configuration.
Change-Id: Ib3efb4f517a5cf86dbf91ee53ac00108d4624dcd
Closes-Bug: #1652002
As a part of handing over control over mcollective from nailgun agent to
startup scripts lets get rid of of nodiscover file flag and perform
mcollective configuration and start
Change-Id: Ia2f984570b38642b1090f6483ed3fa78958550c5
Partial-Bug: #1585671
As we known, Exceptions are raised by the sys.exit() function.
When they are not handled, no stack traceback is printed in the Python interpreter.
In this patch we have known main() got return values(eg:0, 1), but it can't
specifies exit status when terminate the main thread by unusing sys.exit().
So when using sys.exit(main()) instead of main() may be more readable and
reasonable.
Change-Id: I6b472e0eb2fceb49bb506785f5188e023e1d3968
Such services as Swift-storage require partition with file
system without mountpoints, currently fuel-agent prevents
to do that.
Change-Id: Id9e90f81098de3736e0d9b1ca82e434122efd4e8
Closes-bug: #1650622
Refer to:http://docs.openstack.org/developer/hacking/#unit-tests-and-assertraises
[H203] Use assertIs(Not)None to check for None (off by default) Unit
test assertions tend to give better messages for more specific assertions.
As a result, assertIsNone(...) is preferred over assertEqual(None, ...)
and assertIs(None, ...)
Change-Id: I9246fac952c59d3ddc1458c16c53fc988ac095d3
The previos implementation doesn't fix the problem. Cloud-init
creates /etc/network/interfaces.d/50-cloud-init.cfg which prevents
to set static IP.
Change-Id: I49d09dd37403a843adfe34be156e5e265b0f3e08
Signed-off-by: Sergii Golovatiuk <sgolovatiuk@mirantis.com>
The directory /etc/cloud/cloud.cfg.d/ doesn't exist. Thus fuel-bootstrap fails as it cannot create file that should be inside of that directory.
Closes-Bug: 1643139
This reverts commit b2be687081.
Change-Id: Ie2bef3a83fb02bf7fe9634ede66998c5cf217f20
This fix doesn't fix the problem. I still see 50-cloud-init.cfg in /etc/network/interfaces.d/
This reverts commit faa9de1780.
Change-Id: I93a7fa29ae932b0020a4dad17e580808ee3fb117
Signed-off-by: Sergii Golovatiuk <sgolovatiuk@mirantis.com>
In fuel-agent.log, mountpoint -q /tmp/target/sys/fs/fuse/connections
execute failed.
Fuse is a kernel mechanism, it has a fixed pseudo filesystem
location (/sys/fs/fuse/connection) for user. We do not
need to umount it manually, let kernel take care of that.
In our case, nobody cares about fuse in kernel by
/sys/fs/fuse/connection. So we don't need to mount and umount
in chroot.
https://www.kernel.org/doc/Documentation/filesystems/fuse.txt
Change-Id: I0a9af904b2b65af1af96340c0579dedf979464fc
also make the callback script more resilent by retrying attempts
to contact Ironic API (hardcoded 50 times).
Change-Id: I269c1b95ee5702ed435df30834e239bd6f6f0582
This patch set modifies lines which are importing objects
instead of modules. As per openstack import guide lines, user should
import modules in a file not objects.
http://docs.openstack.org/developer/hacking/#imports
Change-Id: Icfd86bfff12889e76316da6788db4f7f0c352275
by default, Ironic's API routing now exposes only 'lookup' and 'heartbeat'
vendor passthru methods of drivers as public routes [0].
Rename the vendor passtru method 'pass_deploy_info' of fuel-agent driver
to 'heartbeat' to make it accessable w/o authentication by callback
script.
In the Ocata cycle, this also will be removed and fuel-agent driver
must switch to the root 'heartbeat' API (/v1/heartbeat/node-uuid>).
[0]
https://github.com/openstack/ironic/blob/master/ironic/api/config.py#L37
Change-Id: Ie1dbd8a8aac62034beba88ecd206a8e7712514e2
The origin message format is simply a coding mistake. Users will get
useless error message since we didn't really passing correct `url` in
error message. This patch fix HttpUrlConnectionError error message
format.
Closes-Bug: #1614048
Change-Id: I5b9b5dcfca053097622ea6b701aa758ee1a5aa8e
Having admin NIC confugured in the middle of system booting
is very fragile and error-prone approach.
It's better to configure it ahead of first booting time.
Also, there's no need for freaky networking restarting inside of
cloud-init boothooks anymore.
Change-Id: I4c278341e8b40eb8d9b100bed1d9a650f27b5c5b
Related-Bug: #1583815
Xenial-based IBP kernel boot parameters contain 'root=UUID=XXX'
record where 'XXX' points to UID of lvm volume,but in this moment
lvm groups is not activated and root partition cannot be mounted.
This occurs because script, which should activate lvm, does not handle
'UUID' option. Lvm2 Xenial package relying on presence of systemd to
activate its volumes.
In early releases this works by specific udev rules
(/lib/udev/rules.d/85-lvm2.rules)
Change-Id: I8ebe209e4de479a30c70222a35cabcfacbfd2e6c
blueprint: mos-xenial
Closes-Bug: 1552346
Mcollective should be disabled in IBP.
This always true for upstart job, but we
missed that for systemd.
Change-Id: I779ecd39c4646f2432c1f43a46971fea8205010f
blueprint: mos-xenial
A typo in manager.py was fixed. This typo doesn't break
anything when old enough oslo.log module is used, but it
breaks deployment process when newer OS is used to build
bootstrap image.
A minor issue with path build process was also fixed.
Change-Id: I97616ef0bfbe0f7ffc6e625e4bf7c7ffde1a1919
Closes-Bug: #1597697
oslo_* imports belong to 3rd party libraries and should be imported
before local imports.
Change-Id: I5773343ef53741c28414fa738b90717f5eacab53
Partial-Bug: #1594850
Apparently, the disks which're bigger than 2T were excluded from list
of bootable disks if possible. Just because in the past, those disks
were unrecognized by BIOS (or UEFI under CSM).
In fact, it was just misconfiguration of RAID controller or BIOS
itself.
GRUB uses BIOS INT13h in order to find all available disks.
Therefore, unless particular disk is not configured as 'bootable',
there's no change for GRUB to find it.
One should configure hardware in the following way assuming that
the first disk (hd0) is bootable and is used for operating system
purposes.
In case of hardware RAID, FC multipath or any other HBA, the disk
(or lun, or whatever) which was configured as 'bootable' will be
reported as hd0 via INT13h. So, GRUB will be able to boot from it.
DocImpact
Closes-Bug: #1588260
Change-Id: I7bc729ffafa3b9d6bfe8521fa38599d36d02f7e1
Under certain circumstances due to that alignment, the end of
particular partition could cross 1M boundary. And due to actual
partition' bounderies being rounded up, fuel-agent mistakenly
assumes that partition couldn't fit within provided boundaries
and raises errors.WrongPartitionSchemeError.
However, some h/w data storages are well known for reporting
relatively huge optimal IO sizes (16M or even bigger), so the 1M
room can't be enough. Thus, optimal aligning is not an option.
In such cases, it's better to proceed with minimal mode.
It's the minimum aligment needed to align the partition properly
to physical blocks which avoids performance degradation.
Partial-Bug: #1543233
DocImpact
Change-Id: I1dd94731f497f3deb47cec9a23957e3706c2fb3b
Due to fact that mirrors are not always up, there is very rare possibility
that client will waste time of full bootstrap image building due to 2-3
second downtime of a mirror. Also, due specific work-flow of fuel mirrors
that may introduces instability to CI jobs.
Change-Id: Icecc1f4e355713ee95ac5e8d0d13ea326630c056
Closes-bug: #1563366
The thing is that sometimes we have file system images and mount
point hierachies which are not aligned. Let's say, we have root
file system image, while partition scheme says that two file
systems should be created on the node: / and /var. In this case
root image has /var directory with a set of files. Obviously, we
need to move all these files from /var directory on the root
file system to /var file system because /var directory will be
used as mount point.
In order to achieve this we mount all existent file systems into
a flat set of temporary directories. We then try to find
specific paths which correspond to mount points and move all
files from these paths to corresponding file systems.
Co-Authored-By: Alexey Stupnikov <astupnikov@mirantis.com>
Change-Id: I1aa7523055ac4bcf6f8a93e9740ccf652ed35cc1
Closes-Bug: #1537699
If nailgun will send as bootable flag for disk we have to use this
disk and place '/boot' on it
Change-Id: I881d9fd4bb378dec78fd86aff0c314c910525110
Closes-bug: 1567450
That switching is way too intrusive.
It's better to give a user an ability to control which alignment mode
will be used by adding an option to fuel-agent config file.
This reverts commit 4c74eaa187.
Change-Id: Ia492d1479da170a9c76633c9b87c165c47f8d34b
We put configdrive with is9660 filesystem to a
partition on a hard disk. New hard disks may have
4K sectors, but blocksize of iso9660 fs is 2K so
it will not work.
To fix this bug we should use another filesystem (ext2)
and another config drive format (files, directory
structure), because NoCloud format, which is currently
used support only vfat and iso9660 filesystems.
Change-Id: Ia0f244f19bab3dfaceef8a092ad03667675a5557
Closes-Bug: #1544818