Skip to content

Conversation

ishasahni2000
Copy link

@jenkins-openbmc-ibm
Copy link

Can one of the admins verify this patch?

@rfrandse
Copy link
Collaborator

add to approvelist

@ishasahni2000 ishasahni2000 force-pushed the provisioingInterfaces branch 7 times, most recently from 3f22d38 to c30a6c1 Compare July 24, 2025 10:08
@raviteja-b raviteja-b requested a review from spinler August 22, 2025 05:15
@raviteja-b
Copy link
Contributor

raviteja-b commented Aug 22, 2025

Hi @spinler
can you please review and share your views on this provisioning interface, if you have any idea on getting this provisioning interface upstream using different naming. will push this interface upstream after we conclude interface in this PR.

Copy link
Contributor

@spinler spinler left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What object path is this going to be on? There's the 'namespace' fields where you can specify them in the yaml so it'll generate constants.

@@ -0,0 +1,30 @@
name: xyz.openbmc_project.Provisioning
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think 'name' is a recognized field at this level?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also, I wonder if this should be under Network. The upstream maintainer would have final say anyway I guess.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

removed name: xyz.openbmc_project.Provisioning

Copy link
Author

@ishasahni2000 ishasahni2000 Aug 28, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also, I wonder if this should be under Network. The upstream maintainer would have final say anyway I guess.

but provisiong is not related to networking right ? should it be with interfaces related to network

property to indicate whether the BMC is provisioned, and methods to initiate
provisioning and check the peer BMC connection.
properties:
- name: ProvisioningState
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

'State' sounds like it should be an enum. If it's just a bool, how just about something like 'Provisioned'?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@spinler this provisioningState is populated as per PIC controller GPIO values which is a boolean.
true represents provisioned state and false represents unprovisioned state

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My suggestion was to rename the property to 'Provisioned'. However, what would prevent what I have below from occurring?

  1. Call startProvisioning
  2. Check this property, it returns false because not done yet
  3. Now it finishes and is set to true

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

sure will rename the property

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

updated

@raviteja-b
Copy link
Contributor

What object path is this going to be on? There's the 'namespace' fields where you can specify them in the yaml so it'll generate constants.

@abhilashraju @ishasahni2000 can you please post D-bus object path and mockup D-bus object details

@ishasahni2000 ishasahni2000 force-pushed the provisioingInterfaces branch 2 times, most recently from fff5a14 to e4a7fe5 Compare August 26, 2025 11:29
True means the BMC is in a provisioned state.

methods:
- name: StartProvisioning
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are there any ways that provisioning can fail (aside from cable issue)? After this method is called, what if it failed? How long should they wait to check the property?

Copy link
Author

@ishasahni2000 ishasahni2000 Aug 28, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

shouls we make the method returntype as bool ?--and return false if it fails

How long should they wait to check the property?
if the method fails it woudn't update the property ProvisioningState right , so there so it should return correct value even if the method fails .

any veiws on this @abhilashraju @raviteja-b ?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@spinler The call should be combined with a matcher that observes the provisioned property to capture the asynchronous response. At present we don’t know whether a deadline can be imposed.

Our current understanding is that provisioning starts with an SPDM handshake. When that handshake completes successfully, the peer‑connection test is launched. If both the handshake and the test succeed, the provisioned state is set to true.

The maximum end‑to‑end duration would simply be the longest possible SPDM handshake time added to the longest possible peer‑connection test time—each operation assumed to time‑out if the peer fails to reply.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don’t think these can be combined, right? StartProvisioning is triggered by bmcweb when the HMC initiates provisioning, whereas the RBMC manager is responsible for peer communication checks as part of redundancy determination. This means the RBMC manager needs to monitor the Provisioned property with a timeout, so that it can fall back to non-redundant mode if provisioning isn’t completed within that timeframe, correct?

Also, are we supporting re-provisioning? If so, the RBMC manager should continuously monitor this property, detect when re-provisioning is triggered, and then perform peer BMC verification again. But how is this indicated? For example, if the system is already provisioned and re-provisioning happens, will a property change signal be emitted?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry for the confusion. By ‘provisioned’ property, I was referring to the peer BMC, not the current one. In that context, you are correct—the provisioned property remains untouched for the current BMC. The property that the RBC manager would be monitoring is actually the ‘peerConnected’ property.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It looks like the name of the provision APIs is a bit misleading—it gives the impression that the current BMC is being provisioned, whereas in reality it initiates the attestation process and the remote BMC ends up being provisioned. My suggestion is that once SPDM reports the remote attestation as successfully completed, the provisioning service should automatically perform the peer connection test. Depending on whether that test succeeds or fails, the ‘peerConnected’ property will be updated accordingly. This way, the RBMC manager doesn’t need to call a separate checkConnection method—it can simply watch for changes to the ‘peerConnected’ property and react based on its value.

Copy link
Contributor

@RameshIyyar RameshIyyar Sep 5, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

By ‘provisioned’ property, I was referring to the peer BMC, not the current one. In that context, you are correct—the provisioned property remains untouched for the current BMC.

Is this correct? My understanding is that if the Provisioned property is set to true, it means this BMC is provisioned and it doesn’t depend on whether the sibling BMC is provisioned. Right? I’m a bit confused about the term “peer BMC”

The property that the RBC manager would be monitoring is actually the ‘peerConnected’ property.
It looks like the name of the provision APIs is a bit misleading—it gives the impression that the current BMC is being provisioned, whereas in reality it initiates the attestation process and the remote BMC ends up being provisioned. My suggestion is that once SPDM reports the remote attestation as successfully completed, the provisioning service should automatically perform the peer connection test. Depending on whether that test succeeds or fails, the ‘peerConnected’ property will be updated accordingly. This way, the RBMC manager doesn’t need to call a separate checkConnection method—it can simply watch for changes to the ‘peerConnected’ property and react based on its value.

If the Provisioned property reflects the peer BMC’s provision state and peerConnected indicates whether the peer is connected, then both depend on the peer. In that case, how could we boot the host in non-redundant mode? If the peer is in a bad state, neither property would allow the host to boot, correct? We should be able to treat either BMC as active and boot the host from it, which requires at least one BMC to be provisioned. But since this always refers to the peer BMC, it turns into a chicken-and-egg problem, right?

My understanding is that the Provisioned property should indicate whether this BMC is provisioned or not. I’m not sure how you plan to represent that. During the provisioning process we perform many steps, not just certificate exchange with the sibling BMC, correct?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I didn’t say that the provisioned property reflects the peer BMC’s provisioned state.

@@ -0,0 +1,28 @@
description: >
Interface to represent the provisioning status of the BMC. Provides a
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we should clarify what we mean by 'provisioning' at a high level, since the interpretation may vary by implementer.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please rephrase this description to explain more generically about the overall intention to add this dbus interface.
"provides a property" - this file is not confined to have only one property.
"check the peer BMC connection" - this interface scope is not only to check the peer BMC connection.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@RameshIyyar A BMC is considered provisioned when it has been successfully added to the BMC network and the certificate exchange is confirmed. The prerequisite for the attestation process is that the pinhole reset has been pressed or the PIC bit 0 is cleared. Are we aligned on this understanding?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A BMC is considered provisioned when it has been successfully added to the BMC network and the certificate exchange is confirmed.

Yes, if you weren’t referring to verifying the exchanged certificate.

The prerequisite for the attestation process is that the pinhole reset has been pressed or the PIC bit 0 is cleared. Are we aligned on this understanding?

If the pinhole reset did not occur, certificate verification would detect that the sibling does not belong to this system, or the system VPD would catch it on this BMC.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I’d like to clarify what you mean by “the certificate exchange is confirmed.” Is this referring to the peer BMC? Does it mean that only after the certificate exchange succeeds you consider this BMC as provisioned? If it fails, then we wouldn’t be able to boot the host, correct?

My understanding is that Provisioned indicates whether this BMC itself is provisioned, not whether the certificate exchange with the peer BMC was successful. I believe the diagram Sunitha referred to reflects the same meaning.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For a BMC to be considered provisioned, it must first be added to the BMC network. A successful SPDM attestation serves as the indicator of this state. This definition originates from Chris, not from me.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

BMC0 (or whichever BMC is attempting to exchange the provisioned certificate) is marked as provisioned before the SPDM step, as noted in the document shared by Sunitha/Isha (Genesis MFG Provisioning Flow – Step 8).

I’m not sure if this has been changed. In any case, since this PR already needs rework (and you also agreed on a few comments), I’ll wait for the next patch set. Thanks.

property to indicate whether the BMC is provisioned, and methods to initiate
provisioning and check the peer BMC connection.
properties:
- name: ProvisioningState
Copy link
Contributor

@RameshIyyar RameshIyyar Sep 2, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is the Provision state persisted? If so, is it stored in the filesystem or in pic-control? I assume it’s in pic-control, either way, we cannot rely on persisted provision states alone. Instead, we should always verify peer BMC communication to enable redundancy, right?

During BMC startup, the Provisioning, SPDM, and RBMC daemons all start together.

  • If already provisioned,
    • Does the Provisioning daemon perform verification on its own during startup and a sibling BMC reboots, or does it expect another component (in our case, the RBMC manager) to handle verification instead?
  • If not provisioned,
    • If the another component (in our case, the RBMC manager) would need to invoke the peer BMC communication verification API in these scenarios.
      • Should the caller monitor the provision property, wait for it to be set, and then verify the peer BMC?
      • How long should the caller wait? Should there be a timeout after which redundancy is disabled and the system falls back to non-redundant mode? I think the Provision daemon will wait for someone to request provisioning, right?
        • Would it be reasonable to reuse the existing 6-minute timeout that we apply for sibling BMC startup?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You’re right: the PIC control bit isn’t the definitive indicator of a trusted channel. As we’ve already noted, we must first establish a clear definition of what “provisioned” actually means. If we were to treat provisioning as synonymous with a trusted channel—an approach that I don’t agree with—then it would become the responsibility of the provisioning daemon to guarantee that the PIC control bit reflects the true status. In that scenario, the daemon would need to perform continuous, live monitoring of the Peer BMC connection to keep the PIC flag accurate.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In the trigger scenario we can either expose a D‑Bus method that the caller invokes to start the Peer BMC connection test, or let the provisioning daemon trigger the test itself. If the daemon handles the trigger, no extra method is required; the provisioning property would simply reflect the test outcome. Because the definition of “provisioning” remains ambiguous, we’ll instead use a dedicated Peer‑Connection‑Status property to indicate whether the channel is trusted.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For connection timeouts the service will perform a configurable number of retries and impose a timeout when checking the peer’s status. Based on whether the connection succeeds or fails, the Peer‑Connection‑Status property will be updated

Copy link
Contributor

@RameshIyyar RameshIyyar Sep 2, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You’re right: the PIC control bit isn’t the definitive indicator of a trusted channel. As we’ve already noted, we must first establish a clear definition of what “provisioned” actually means. If we were to treat provisioning as synonymous with a trusted channel—an approach that I don’t agree with—then it would become the responsibility of the provisioning daemon to guarantee that the PIC control bit reflects the true status. In that scenario, the daemon would need to perform continuous, live monitoring of the Peer BMC connection to keep the PIC flag accurate.

I’m not sure what you mean by “trust channel” I don’t think we can call the Provisioned state stored in PIC control a trust channel, right? Also, we’re not actually creating a trust channel—we’re just verifying whether the exchanged certificate (or the provisioned certificate if the sibling BMC rebooted) is valid through mTLS, using the proposed CheckPeerBMCConnection API. That way, it can be used to enable redundancy.

In the trigger scenario we can either expose a D‑Bus method that the caller invokes to start the Peer BMC connection test, or let the provisioning daemon trigger the test itself. If the daemon handles the trigger, no extra method is required; the provisioning property would simply reflect the test outcome. Because the definition of “provisioning” remains ambiguous, we’ll instead use a dedicated Peer‑Connection‑Status property to indicate whether the channel is trusted.

How do we verify whether the peer BMC is ready to trigger verification of the exchanged/provisioned certificates? I think the RBMC manager could handle this since it already has visibility into the sibling BMC information (via CFAM). The RBMC manager could use that information to confirm readiness before triggering verification. Also, I believe verification only needs to be triggered from the Active BMC, not from both sides. @spinler, could you confirm if this approach works from the RBMC manager’s perspective?

For connection timeouts the service will perform a configurable number of retries and impose a timeout when checking the peer’s status. Based on whether the connection succeeds or fails, the Peer‑Connection‑Status property will be updated

I think this could also be implemented in the RBMC manager, especially since there are already plans to monitor the neighbor interface—but I’ll defer to @spinler for his view on this.

If everything can be handled by the Provision daemon, that would indeed simplify the RBMC manager’s responsibilities :) However, it’s important to ensure that the sibling BMC is actually ready to perform certificate verification. The RBMC manager relies on the Provisioned property to determine redundancy. If redundancy cannot be enabled because certificate verification for internal communication fails, it will still allow one BMC to proceed as Active to boot the host so the Provision property should reflect that this BMC is provisioned, no need to tie certificate verification though otherwise we won't able to boot the system. @spinler any view?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I’m not sure what you mean by “trust channel” I don’t think we can call the Provisioned state stored in PIC control a trust channel, right? Also, we’re not actually creating a trust channel—we’re just verifying whether the exchanged certificate (or the provisioned certificate if the sibling BMC rebooted) is valid through mTLS, using the proposed CheckPeerBMCConnection API. That way, it can be used to enable redundancy.

By ‘trust channel,’ I was referring to the peer connection test. This test attempts to establish an mTLS connection with the peer, and if it succeeds, the peerConnected property is set to true.

Copy link
Contributor

@abhilashraju abhilashraju Sep 4, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also, I believe verification only needs to be triggered from the Active BMC, not from both sides

From the provisioning service’s perspective, it doesn’t matter whether the current BMC is active or passive. If a verification test is triggered, it will attempt to establish an mTLS connection with the peer and update the peerConnected status accordingly.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I couldn’t quite follow you—sorry. It sounds like you’re describing two different flows: one using the two properties and another using the D-Bus API for the RBMC manager use cases. I feel like I might be missing something here.

True means the BMC is in a provisioned state.

methods:
- name: StartProvisioning
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don’t think these can be combined, right? StartProvisioning is triggered by bmcweb when the HMC initiates provisioning, whereas the RBMC manager is responsible for peer communication checks as part of redundancy determination. This means the RBMC manager needs to monitor the Provisioned property with a timeout, so that it can fall back to non-redundant mode if provisioning isn’t completed within that timeframe, correct?

Also, are we supporting re-provisioning? If so, the RBMC manager should continuously monitor this property, detect when re-provisioning is triggered, and then perform peer BMC verification again. But how is this indicated? For example, if the system is already provisioned and re-provisioning happens, will a property change signal be emitted?

Starts the provisioning process and updates the ProvisioningState
accordingly.

- name: CheckPeerBMCConnection
Copy link
Contributor

@RameshIyyar RameshIyyar Sep 2, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

CheckPeerBMCConnection

Suggestion: VerifyPeerBMCCommunication? or You could wait for others to comment on it.

  • How does the Provisioning daemon know that the peer BMC is ready to perform verification? If the peer isn’t ready but we still attempt verification, it would fail, correct?
  • Should we expect peer BMC verification to happen from both BMCs’ perspectives?
  • In the case of a network issue (though rare), verification would also fail. Are we planning to implement retries in such cases, or would we need to disable redundancy?
  • Do we expect the caller to specify which peer BMC needs to be verified? Since you’re proposing this as a generic interface, that question could come up from upstream in a multi-BMC context. You might want to hold off until then :)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The exact meaning of “provisioning status” remains unclear, but we do need to monitor the peer‑connection property continuously. A sibling BMC may disconnect and reconnect—sometimes the same device, sometimes a replacement. If it’s the same BMC, the provisioning daemon should re‑establish a trusted channel and set the status to true. If a new BMC appears, the daemon must initiate a fresh SPDM attestation. Whether this re‑authentication is triggered internally by the daemon or invoked externally is still under discussion.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A simpler approach would be to have the provisioning component detect a sibling BMC via the neighbor‑discovery signal, immediately start the SPDM attestation and peer‑connection checks, and then let all other services simply monitor the peer‑connection status property to drive their own decisions.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is just my view only

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The exact meaning of “provisioning status” remains unclear

I’ve shared my understanding in the above comment. If it doesn’t make sense, please feel free to bring it up in the BMC call or another relevant forum at your convenience.

we do need to monitor the peer‑connection property continuously.

I don’t see any property other than Provisioned. Do you mean this will be addressed in future changes?

A sibling BMC may disconnect and reconnect—sometimes the same device, sometimes a replacement. If it’s the same BMC, the provisioning daemon should re‑establish a trusted channel and set the status to true.

I didn’t quite follow what you meant by disconnect/connect—are you referring to a network loss? You already covered reboot and sibling BMC replacement below.

If a new BMC appears, the daemon must initiate a fresh SPDM attestation. Whether this re‑authentication is triggered internally by the daemon or invoked externally is still under discussion.

Hmm, ok—but I think this needs to be driven externally since replacing a BMC and initiating provisioning from HMC is a user-driven operation. The running Active BMC would then rediscover, recalculate redundancy, and trigger peer BMC certificate verification to decide whether redundancy should be enabled with the replaced BMC. I had some discussion on this here, but we didn’t go into much detail about certificate verification during the CM operation.

A simpler approach would be to have the provisioning component detect a sibling BMC via the neighbor‑discovery signal, immediately start the SPDM attestation and peer‑connection checks, and then let all other services simply monitor the peer‑connection status property to drive their own decisions.

Hmm, please bring this up in a design call (though data sync doesn’t directly depend on it—we only rely on whether redundancy is enabled to decide if syncing should occur). I’m also not sure why SPDM attestation would be needed for a network loss, or maybe I didn’t fully follow your point—sorry.

- name: CheckPeerBMCConnection
description: >
Performs a check to determine if the peer BMC is reachable and and if
already provisioned.
Copy link
Contributor

@RameshIyyar RameshIyyar Sep 2, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if already provisioned.

How do we check the peer BMC’s provision state? Are we able to read the peer BMC’s pic-control, or did you mean something else? My understanding is that Provisioned indicates this BMC is provisioned, but does it also imply verification? By verification, I mean the mTLS handshake performed through this API (by checking the Provisioned property) after certificate exchange.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We still need a precise definition of provisioned. If a peer BMC is provisioned, the CFAM bit can serve as the indicator.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I already tried to reply to this in another comment while responding.

@@ -0,0 +1,28 @@
description: >
Interface to represent the provisioning status of the BMC. Provides a
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please rephrase this description to explain more generically about the overall intention to add this dbus interface.
"provides a property" - this file is not confined to have only one property.
"check the peer BMC connection" - this interface scope is not only to check the peer BMC connection.

True means the BMC is in a provisioned state.

methods:
- name: StartProvisioning
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

StartProvisioning - This should be split into 2 methods.

  1. ProvisionActive - this is expected to act on self
  2. ProvisionPassive - this is expected to act on the passive BMC
    And both methods are expected to perform different steps internally.

Copy link
Author

@ishasahni2000 ishasahni2000 Sep 2, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

but from what i understand is that ProvisionActive not required -- active bmc should come up as provisioned

Copy link
Contributor

@RameshIyyar RameshIyyar Sep 2, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@sunharis Are we provisioning both BMCs independently? I thought BMC0 would drive BMC1’s provisioning as per the discussed flow. Also, I’m not sure what you mean by ProvisionActive/Passive, since roles aren’t available during provisioning, right? (This doesn’t apply to the BMC CM operation—BMC CM provisioning is driven by the CM daemon from the running BMC, correct?)

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@sunharis Are we provisioning both BMCs independently? I thought BMC0 would drive BMC1’s provisioning as per the discussed flow. Also, I’m not sure what you mean by ProvisionActive/Passive, since roles aren’t available during provisioning, right? (This doesn’t apply to the BMC CM operation—BMC CM provisioning is driven by the CM daemon from the running BMC, correct?)

https://github.ibm.com/rbailapu/p11-fw-designs/blob/main/designs/provisioning/ProvisioningFlowDiag.png is the provisioning flow

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@sunharis Are we provisioning both BMCs independently? I thought BMC0 would drive BMC1’s provisioning as per the discussed flow. Also, I’m not sure what you mean by ProvisionActive/Passive, since roles aren’t available during provisioning, right? (This doesn’t apply to the BMC CM operation—BMC CM provisioning is driven by the CM daemon from the running BMC, correct?)

https://github.ibm.com/rbailapu/p11-fw-designs/blob/main/designs/provisioning/ProvisioningFlowDiag.png is the provisioning flow

Hmm, I think I’m missing the responsibilities of this proposed API then, it would be great if we added more details in this PR. My understanding was that the MFG process would continue to rely on the existing commands we used for setting up the p10 BMC (with some commands possibly split or extended for the MFG flow). I assumed the new API StartProvisioning was intended to handle specific provisioning steps initiated from BMC0, and that the same API could also support BMC CM provisioning.

What I’m not sure about is whether the plan is to provide a single API (or two separate ones):

  • One for provisioning BMCs individually, which could be used by MFG and by HMC through curl and bmcweb respectively
  • Another for initiating provisioning from BMC0 to BMC1 (such as certificate exchange), which could be used both by MFG and by HMC through curl and bmcweb respectively

For MFG we can invoke the APIs however we want, but I’m not sure if the plan for HMC/Redfish is to expose two separate URIs or just a single one.

Anyway, that’s more of a design decision, so I’ll leave it to you people. Thanks for sharing the details.

- type: boolean
description: >
True if the peer BMC is reachable and provisioned. false if peer
BMC is not reachable or not-provisioned.
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

false if peer BMC is not reachable or not-provisioned.

Both are different use cases, and scenarios. They can not be indicated by single property.

Copy link
Author

@ishasahni2000 ishasahni2000 Sep 2, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Both are different use cases, and scenarios. They can not be indicated by single property.

but what should be returned in case provisioned property is set true earlier and mtls connection is broken now?

@ishasahni2000 ishasahni2000 force-pushed the provisioingInterfaces branch 6 times, most recently from f08f0aa to 0aff81e Compare September 17, 2025 12:58
Signed-off-by: Isha Sahni <[email protected]>
- type: boolean
description: >
True if provisioning on the peer BMC succeeded, false if it
failed.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What D-Bus object will implement this interface? From a bmcweb perspective I'm wondering what mapper call I will need to find the object to request the ProvisionPeer.

Please add paths: to the YAML definition.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if you are looking for bus name this is the current plan "xyz.openbmc_project.Provisioning".

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You can do something like https://github.com/openbmc/phosphor-dbus-interfaces/blob/master/yaml/xyz/openbmc_project/State/BMC.interface.yaml#L92 to specify the object path. That isn't always appropriate, like if an interface can go on any path, but I think it makes sense here.

Emitted when the ProvisionPeer method completes. The signal carries a
boolean indicating whether provisioning on the peer succeeded or
failed.
args:
Copy link
Contributor

@raviteja-b raviteja-b Sep 19, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@abhilashraju can we use signal with properties instead of args?

signals:
    - name: PeerProvisioned
    
      properties:
          - name: PeerProvisionStatus
            type: boolean
            description: 

description: >
Starts the provisioning process on the peerBmc .

- name: InitiatePeerConnectionTest
Copy link
Contributor

@raviteja-b raviteja-b Sep 19, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can we define signal to notify InitiatePeerConnectionTest completed?
example :
signals:

  • name: PeerConnectionTest
    properties:
    - name: PeerConnectionSuccess
    type: boolean

if we want to return different error enums, we can also add one more property under signal to handle different codes.

if we are good with D-bus signal, we dont need to maintain PeerConnected D-bus property.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

9 participants