Add support to new bareon-ironic communication "protocol" - extension
for vendor passthru API. This protocol allow to receive generic
tasks(steps) from bareon-ironic driver, process them on bareon "side"
and send back results.
Right now only one step is implemented - step to inject SSH key.
Change-Id: I9ea828b24085fa72df470eef41ad32d9096f6b40
Make a single point responsible for config option registration to
increase control over config initialization and avoid conflicts.
Usually such conflicts become visible when sharing code with externa
callers. In our case it was the deployment config validator (part of
data drivers), exported as part of the ironic data driver via the
setuptools entry point.
Change-Id: Ibba18db61c222d910d8dca8866ea74b14ce011c8
Simple command line tool to check data intended to bareon. It uses data
validation API provided by data-drivers in same manner as data-drivers
do during "regular" call of bareon.
Change-Id: I2a8950178839c13d8ebcc72cacba203b4bfe37c5
Validate all data feeded into bareon by jsonschema, not only data
related to disk partitioning.
It allows ironic-driver to make early data validation
(https://review.openstack.org/410841).
Change-Id: Ic1acf6b162ada83950ad4a890d32ca2a80152302
ramdisk-func-test bring mixin for base test class. Also it provides more
comfort way to address template folders.
Change-Id: Iea8c92491b9d7a58a8ec806f9da7bf204c3f974e
Version of bareon has to be changed from 0.0.1.dev1
to 0.0.1.a1 since .dev1 does not match to regexp
in publishing gate.
Change-Id: Id9be97f91ddf430a90ead8b396dea53ea14b1905
Closes-bug: #1565862
This is a contribution of features made in the scope of Cray
Bareon adoption. Even though changes affect a lot of code,
they are not breaking. To proove that we have created a functional
test that covers existing nailgun deployment flow
(see /tests_functional/test_nailgun.py)
We have made Manager a deploy_driver. Current nailgun's manager
has been moved to nailgun deploy driver, which is default. Most of
the changes made in the scope of the project are enclosed within
Ironic data driver and Ironic (swift & rsync) deploy drivers.
To make this review easier I propose the following order:
Review changes to existing code:
- review changes to object model
- review changes related to splitting deploy driver / base drivers
- review changes to common utils
Review the new code:
- review Ironic data driver
- review Ironic deploy drivers
Change-Id: Id2d32a7574e6fcafee09490c39fb114c80407db7
Implements: blueprint size-unit-conversion-and-relative-sizing
Implements: blueprint policy-based-partitioning
Implements: blueprint multi-image-deployment
Implements: blueprint rsync-image-deployment
This basic structure is basically gets generated
by cookie-cutter.
Add dependencies from openstack global requirements.
Change-Id: I8391720f183555bcac6a26c1a55276c775d5d369
Closes-bug: #1524896
* New entry point, which adds possibility to create console_script
with native setup.py
Change-Id: I4c2004b355339a1b601fa9120faf547e181decc4
Implements: blueprint dynamically-build-bootstrap
A new executable 'fa_ironic_callback' added. This script does
call back to Ironic API with IP address of boot interface.
Implements blueprint: baremetal-deploy-ironic
Change-Id: I10fadd34f3c0c0979a5fcb9bcb487ef99e720523
This new "simple" data driver takes serialized partitioning info
that is provided before provisioning from external tool.
It does not make any calculations for that data and expect it to have
all required informations about partitioning.
Other changes:
* added unittest2 to use some of it features
* added requests_mock to mock http requests
* added objects conversion to/from dictionary to make serialization
easier
* added a common "interface" for data drivers
* fixed test for "do_build_image" - now a correct data driver is used
Change-Id: I673cde6f0ead9945919a87cd1cfce7ed09c6e593
Implements: blueprint volume-manager-refactoring
As far as building of OS images is nothing more than
just a stage of the whole OS installing procedure
it is sounds rational to implement this in terms
of fuel-agent. Besides, we already have plenty of utilities
which could be useful during building of images.
And some tasks are the same like pre-configuring
some files inside target OS.
Related-bug: #1433193
Implements: blueprint ibp-build-ubuntu-images
Change-Id: I3fadfb16e06e4ee16926da29b7b83ca005500698
Should be merged at once with relevant patches to:
* fuel-ostf
* fuel-astute
* fuel-main
Change-Id: Ic68983a8fb91c32d73408cd1f54439062175ee75
Closes-Bug: #1395279
Fuel agent is a bunch of tools which are
supposed to be placed on bootstrap image and
used for node discovering and image based
provisioning.
Implements: blueprint image-based-provisioning
Change-Id: I946decd50c51e6db767401682d9effbe3cf42bed