In OSP11 (and 10) we need to ensure that these 2 services are together when ironic composable role is used: - OS::TripleO::Services::IronicConductor - OS::TripleO::Services::IronicApi Also, Need to document that ironic role needs access to the storage network. Thanks.
So for OSP10, we have the ironic services included: https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/10/html/advanced_overcloud_customization/roles#Composable_Service_Reference https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/10/html/advanced_overcloud_customization/Roles#Standalone-Ironic The only thing we haven't documented is the need for the storage network.
Is designing the functionality for access to the storage network covered in an OSP 11 RFE? If so, what's the number?
I'm not aware of such RFE. Ramon, do you have an answer?
No, as support for a composable Ironic node starts with Ocata, previously in Newton that was transparent as ironic-conductor was on the controllers which already have storage network. When we QAed this we saw how ironic-conductor was accessing Glance via the storage network, which brings us here.
By the way, enabling a network in a custom role is no different from the standard way with the default roles: https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/10/html-single/advanced_overcloud_customization/#sect-Creating_Custom_Interface_Templates
The docs impact is pretty minimal. We might only just require a short note for the Standalone Ironic role: https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/10/html/advanced_overcloud_customization/Roles#Standalone-Ironic
Details of the role can be found here: https://bugzilla.redhat.com/show_bug.cgi?id=1432560#c6
Dan, we have made all the necessary improvements to allow a composable role with only OS::TripleO::Services::IronicConductor Please, check the details here in this comment: https://bugzilla.redhat.com/show_bug.cgi?id=1432560#c6 So the service IronicApi is not mandatory for the Ironic role. Besides the notes in the documentation, could we ensure we mention in the release notes that the Ironic service now supports being deployed as a composable role? Thanks.
Ramon and Sasha, I might need some clarification here. Initially this bug said that the Conductor and the API services need to be together. However, Roman said in comment #8 that the API doesn't need to be on the same role. Sasha, can you confirm this from a QE perspective? Also, does this mean we can have separate Ironic and IronicApi roles?
Dan, you are right, initially, when this BZ was opened, that was the case (IronicApi and IronicConductor had to be together), then we worked on BZ#1432560 to fix this constraint, with the expectation that the fix might land after GA. The fix made it earlier though, and that's why now adding IronicApi is not mandatory for the Ironic role. We have tested with IronicConductor in mind as the composable role of choice for Ironic . We have tested the composable role with: 1. IronicConductor + IronicApi (this was our initial working test) 2. IronicConductor (verified after the patch in BZ#1432560 landed downstream) A user might desire to have ironic-conductor service on a dedicated node to alleviate the load it produces on the controllers (where it's deployed by default) or to simply isolate the service instead of having it running along with the public APIs for example. That's why the priority is to have IronicConductor working as a composable service.
+1 to comment #10.
Hi Ramon, Thanks for the answer. Just for additional clarification, can IronicApi exist on its own role as well? e.g. have an architecture with: 1 x IronicConductor 1 x IronicApi 1 x Controller n x whatever other nodes
Technically yes, IronicApi can exist on its own, but we haven't done QA on this as testing IronicConductor as a composable role was more critical for the reasons explained in comment #10.
Okay, so for the moment, I'll add a note to say IronicApi can either be placed on the Ironic role or the Controller role depending on the user's decision. If those are the only two scenarios we've tested, we'll stick with those.