I believe this is another manifestation of the transaction management issues that we have with jobs. When a step is created from the RESTAPI it is first created using the AddExternalStep command, which should return the identifier of the created step, in this case 26152fe3-9c56-4e38-811c-73306a3420fe. Then the RESTAPI retrieves the details of the step, using the GetStepByStepId query. Is this query that is failing, probably because the insert was done in a different transaction, ans wasn't committed.

I used the following script to reproduce:

---8<---
#!/usr/bin/python

from ovirtsdk.api import API
from ovirtsdk.xml import params

# Connect to the server:
api = API(
    url="https://rhevm36.example.com/ovirt-engine/api",
    username="admin@internal",
    password="redhat123",
    ca_file="/etc/pki/ovirt-engine/ca.pem",
    debug=True
)

# Create a job:
job = api.jobs.add(
    params.Job(
        description="myjob"
    )
)

# Create the first step:
first_step = job.steps.add(
    params.Step(
        description="first",
        type_="executing"
    )
)

# Create the second step:
second_step = job.steps.add(
    params.Step(
        description="second",
        type_="executing",
        parent_step=params.Step(
            id=first_step.get_id()
        )
    )
)

# Close the connection:
api.disconnect()
--->8---

Note that this is probably a duplicate of bug 1253338 or bug 1254230.

After applying the following two patches (the proposed solution for of bug 1253338 and bug 1254230) adding the sub step works correctly:

  core: Make JobRepository a @Singleton
  https://gerrit.ovirt.org/45319

  core: Index entity managers by transaction
  https://gerrit.ovirt.org/45327

So most probably this is a duplicate. However I'd leave it open so that this specific scenario can be verified by QE.