Bug 1575971 - [RFE][TestOnly] Provision overcloud with only Ironic and Neutron (without Nova and Glance)
Summary: [RFE][TestOnly] Provision overcloud with only Ironic and Neutron (without Nov...
Status: ON_QA
Alias: None
Product: Red Hat OpenStack
Classification: Red Hat
Component: openstack-tripleo-common
Version: 16.0 (Train)
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
: ---
Assignee: Steve Baker
QA Contact: Paras Babbar
URL: https://blueprints.launchpad.net/trip...
Whiteboard: docs-accepted
Depends On:
TreeView+ depends on / blocked
Reported: 2018-05-08 12:38 UTC by Dmitry Tantsur
Modified: 2021-08-19 20:12 UTC (History)
15 users (show)

Fixed In Version: openstack-tripleo-common-11.4.1-1.20200914165651.el8ost
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
: 1894547 (view as bug list)
Last Closed:
Target Upstream Version:

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
OpenStack gerrit 691156 0 'None' MERGED Document baremetal provisioning 2021-02-05 13:57:20 UTC

Description Dmitry Tantsur 2018-05-08 12:38:14 UTC
Making TripleO workflows use Ironic directly to provision nodes has quite a few benefits:
1. First and foremost, getting rid of the horrible "no valid hosts found" exception. The scheduling will be much simpler and the errors will be clearer.
2. Also important for the generic provisioner case, we'll be able to get rid of Nova and Glance, reducing the memory footprint.
3. We'll get rid of pre-deploy validations that currently try to get what nova scheduler will expect.
4. We'll become on charge of building the configdrive, potentially putting more useful things there.
5. In the future we'll be able to integrate things like building RAID on demand much easier.
6. Also in the future we might want to use introspection data in scheduling and provisioning decisions. Particularly, we can automate handling root device hints.
7. We'll probably have easier time combining ironic with pre-deployed services or virtual solutions (e.g. putting controllers on oVirt, which is currently done via an unsupported ironic-staging-driver driver).
8. Hopefully, scale-up will be less error-prone.

The way I see it implemented is probably similar to the config-download work (and based on it). We can have a Heat flag to not provision instances, essentially stop after creating ports and creating ansible input. Then a mistral workflow will pick the required number of nodes, prepare them and provision. Then the usual config-download will proceed.

Comment 1 Bob Fournier 2018-08-29 17:03:26 UTC
From ML discussion, making this TechPreview for OSP-15.

Comment 17 Steve Baker 2019-10-30 19:58:28 UTC
I've attached the upstream docs bug. I think this could still be Tech Preview for 16, and ready to be the default for 16.1

Comment 23 Ramon Acedo 2020-04-22 10:55:40 UTC
Exit TP in 16.1.

Comment 24 Bob Fournier 2020-04-22 12:15:28 UTC
Ramon - this isn't planned for testing in 16.1 so should probably stay in TechPreview.

Comment 26 Lon Hohberger 2020-11-05 11:54:33 UTC
According to our records, this should be resolved by openstack-tripleo-common-11.4.1-1.20200914165651.el8ost.  This build is available now.

Comment 28 Steve Baker 2021-03-30 20:03:08 UTC
Moving to 17.0 since that is where downstream CI is testing it.

Comment 29 pweeks 2021-06-14 20:39:44 UTC
Taking this off the OSP17 planning as we already have a tracking BZ for it targeting 17, 1894547

Note You need to log in before you can comment on or make changes to this bug.