Add Provisioning YAML File #180

ishasahni2000 · 2025-07-23T06:39:00Z

doc referred : https://github.ibm.com/p11-fw-design/p11-fw-designs/blob/f729f6a52c0212e364e02fff8d1d003ebabd8e3e/designs/provisioning/README.md

jenkins-openbmc-ibm · 2025-07-23T06:39:05Z

Can one of the admins verify this patch?

rfrandse · 2025-07-23T13:28:15Z

add to approvelist

raviteja-b · 2025-08-22T05:20:35Z

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.

spinler

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.

spinler · 2025-08-22T13:20:57Z

yaml/xyz/openbmc_project/Provisioning/Provisioning.interface.yaml

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


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

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

removed name: xyz.openbmc_project.Provisioning

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

yaml/xyz/openbmc_project/Provisioning/Provisioning.interface.yaml

spinler · 2025-08-22T13:25:38Z

yaml/xyz/openbmc_project/Provisioning/Provisioning.interface.yaml

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


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

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

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

Call startProvisioning

Check this property, it returns false because not done yet

Now it finishes and is set to true

sure will rename the property

raviteja-b · 2025-08-25T17:56:48Z

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

spinler · 2025-08-26T13:59:46Z

yaml/xyz/openbmc_project/Provisioning/Provisioning.interface.yaml

+          True means the BMC is in a provisioned state.
+
+methods:
+    - name: StartProvisioning


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?

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 ?

@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.

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?

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.

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.

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?

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

RameshIyyar · 2025-09-02T04:06:06Z

yaml/xyz/openbmc_project/Provisioning/Provisioning.interface.yaml

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


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

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.

@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?

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.

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.

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.

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.

RameshIyyar · 2025-09-02T05:55:23Z

yaml/xyz/openbmc_project/Provisioning/Provisioning.interface.yaml

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


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?

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.

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.

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

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?

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.

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.

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.

RameshIyyar · 2025-09-02T06:02:39Z

yaml/xyz/openbmc_project/Provisioning/Provisioning.interface.yaml

+          True means the BMC is in a provisioned state.
+
+methods:
+    - name: StartProvisioning


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?

RameshIyyar · 2025-09-02T06:05:51Z

yaml/xyz/openbmc_project/Provisioning/Provisioning.interface.yaml

+          Starts the provisioning process and updates the ProvisioningState
+          accordingly.
+
+    - name: CheckPeerBMCConnection


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 :)

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.

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.

This is just my view only

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.

RameshIyyar · 2025-09-02T06:28:35Z

yaml/xyz/openbmc_project/Provisioning/Provisioning.interface.yaml

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


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.

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

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

sunharis · 2025-09-02T08:40:03Z

yaml/xyz/openbmc_project/Provisioning/Provisioning.interface.yaml

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


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.

sunharis · 2025-09-02T08:49:27Z

yaml/xyz/openbmc_project/Provisioning/Provisioning.interface.yaml

+          True means the BMC is in a provisioned state.
+
+methods:
+    - name: StartProvisioning


StartProvisioning - This should be split into 2 methods.

ProvisionActive - this is expected to act on self

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

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

@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?)

@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

@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.

sunharis · 2025-09-02T08:51:53Z

yaml/xyz/openbmc_project/Provisioning/Provisioning.interface.yaml

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


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.

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?

Signed-off-by: Isha Sahni <[email protected]>

jeaaustx · 2025-09-18T20:53:31Z

yaml/xyz/openbmc_project/Provisioning/Provisioning.interface.yaml

+          - type: boolean
+            description: >
+                True if provisioning on the peer BMC succeeded, false if it
+                failed.


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.

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

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.

raviteja-b · 2025-09-19T14:32:51Z

yaml/xyz/openbmc_project/Provisioning/Provisioning.interface.yaml

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


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

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

raviteja-b · 2025-09-19T14:45:45Z

yaml/xyz/openbmc_project/Provisioning/Provisioning.interface.yaml

+      description: >
+          Starts the provisioning process on the peerBmc .
+
+    - name: InitiatePeerConnectionTest


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.

ishasahni2000 force-pushed the provisioingInterfaces branch 7 times, most recently from 3f22d38 to c30a6c1 Compare July 24, 2025 10:08

isha309 requested review from abhilashraju, raviteja-b and cmjishnu July 24, 2025 10:24

abhilashraju approved these changes Jul 25, 2025

View reviewed changes

raviteja-b requested a review from spinler August 22, 2025 05:15

spinler reviewed Aug 22, 2025

View reviewed changes

ishasahni2000 force-pushed the provisioingInterfaces branch 2 times, most recently from fff5a14 to e4a7fe5 Compare August 26, 2025 11:29

spinler reviewed Aug 26, 2025

View reviewed changes

RameshIyyar reviewed Sep 2, 2025

View reviewed changes

ishasahni2000 force-pushed the provisioingInterfaces branch from e4a7fe5 to 3398f4c Compare September 2, 2025 08:52

sunharis reviewed Sep 2, 2025

View reviewed changes

ishasahni2000 force-pushed the provisioingInterfaces branch 6 times, most recently from f08f0aa to 0aff81e Compare September 17, 2025 12:58

Add Provisioning YAML File

48f1a32

Signed-off-by: Isha Sahni <[email protected]>

ishasahni2000 force-pushed the provisioingInterfaces branch from 0aff81e to 48f1a32 Compare September 17, 2025 13:07

ishasahni2000 requested review from abhilashraju and spinler September 17, 2025 13:22

jeaaustx reviewed Sep 18, 2025

View reviewed changes

raviteja-b reviewed Sep 19, 2025

View reviewed changes

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

Add Provisioning YAML File #180

Are you sure you want to change the base?

Add Provisioning YAML File #180

Uh oh!

Conversation

ishasahni2000 commented Jul 23, 2025

Uh oh!

jenkins-openbmc-ibm commented Jul 23, 2025

Uh oh!

rfrandse commented Jul 23, 2025

Uh oh!

raviteja-b commented Aug 22, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

spinler left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ishasahni2000 Aug 28, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

raviteja-b commented Aug 25, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ishasahni2000 Aug 28, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

RameshIyyar Sep 5, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

RameshIyyar Sep 2, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

raviteja-b commented Aug 22, 2025 •

edited

Loading

ishasahni2000 Aug 28, 2025 •

edited

Loading

ishasahni2000 Aug 28, 2025 •

edited

Loading

RameshIyyar Sep 5, 2025 •

edited

Loading

RameshIyyar Sep 2, 2025 •

edited

Loading

RameshIyyar Sep 2, 2025 •

edited

Loading

abhilashraju Sep 4, 2025 •

edited

Loading

RameshIyyar Sep 2, 2025 •

edited

Loading

RameshIyyar Sep 2, 2025 •

edited

Loading