Rendering for Director Operator docs variant #753
Conversation
| @@ -149,6 +149,11 @@ ifeval::["{build}" == "downstream"] | |||
| :telemetry: Telemetry service | |||
| endif::[] | |||
|
|
|||
| ifeval::["{build}-{build_variant}" == "downstream-ospdo"] | |||
| :OpenStackPreviousInstaller: director_operator | |||
There was a problem hiding this comment.
We need this so that the ifevals from Pini's patches that say
ifeval::["{OpenStackPreviousInstaller}" == "director_operator"]
take effect. However, the OpenStackPreviousInstaller variable is not just used for the conditional, but also in the text. So it actually renders the "director_operator" value into the docs in several places like that, including the underscore.
We should probably replace all the
ifeval::["{OpenStackPreviousInstaller}" == "director_operator"]
with
ifeval::["{build_variant}" == "ospdo"]
and then set the OpenStackPreviousInstaller variable to something that looks nice in the rendered docs? @klgill @pinikomarov
There was a problem hiding this comment.
Yeah, OpenStackPreviousInstaller = director in the rendered downstream docs, and "TripleO" in the upstream rendered docs. This was done because downstream and upstream refer to the installer differently.
TBH I'm not sure why OpenStackPreviousInstaller was being used for the ifeval statement for OSPdO docs. Does the OSPdO content need its own value for the OpenStackPreviousInstaller variable in the text itself? Currently, we've just written the terms "director Operator" and "OSPdO" as is because the content is conditionalized for OSPdO anyway. I could be misunderstanding though.
There was a problem hiding this comment.
I used OpenStackPreviousInstaller as a method to differentiate ospdo from regular director , that method could be any thing actually , as long as it preserves the logic
|
Build failed (check pipeline). Post https://softwarefactory-project.io/zuul/t/rdoproject.org/buildset/991072895ebe4d53a4b1b931ae3dd45e ✔️ noop SUCCESS in 0s |
No description provided.