Fixes #38888 - Add Cloud Provider Details card to Host Details page

[jeremylenz]

Summary

This PR adds a new Cloud Billing Details card to the Host Details page that displays cloud provider billing information for AWS, Azure, and GCP hosts.

Features

• Conditional display: Card only appears for hosts with cloud providers (AWS, Azure, or GCP)
• Dynamic filtering: Automatically filters and displays only cloud billing facts that are present
• Multi-cloud support:
  • AWS: Displays billing product codes, product type, marketplace information
  • Azure: Shows pay-as-you-go and marketplace billing details
  • GCP: Displays license information
• Data sources: Pulls billing information from host facts reported data
• Clean UI: Uses PatternFly components for consistent styling

Testing Instructions

Manual Testing

1. Test with an AWS host:

   • Navigate to a host with AWS cloud provider
   • Verify the Cloud Billing Details card appears on the Details tab
   • Confirm AWS billing information displays correctly (product codes, types, marketplace data)

2. Test with an Azure host:

   • Navigate to a host with Azure cloud provider
   • Verify the card shows Azure billing details (pay-as-you-go, marketplace)

3. Test with a GCP host:

   • Navigate to a host with GCP cloud provider
   • Verify the card shows GCP license information

4. Test with a non-cloud host:

   • Navigate to a host without a cloud provider
   • Verify the Cloud Billing Details card does NOT appear

5. Test with missing billing data:

   • Navigate to a cloud host that lacks billing facts
   • Verify the card does NOT appear or shows appropriate empty state

🤖 Generated with Claude Code

[chris1984]

Tested and works great. Left a few comments but overall looks really good:

Azure:

AWS:

GCP:

Non cloud host showing the card is not present:

Azure cloud host without billing facts showing card is not present:

[jeremylenz]

@chris1984 updated 👍

[ekohl]

Normally we only show parsed facts that are then stored as normalized data. Looking up raw facts should IMHO be avoided. Both for compatibility (if we need to somehow modify them or parse them from multiple fact sources that present them in different ways) and performance (fact table can be large and needs joins).

It also makes it easier for others to retrieve the same info in an API call

I'd prefer to stick to that pattern.

[jeremylenz]

Normally we only show parsed facts that are then stored as normalized data.

@ekohl Does this mean you require that we persist these on some facet? Or is there some in-between state I don't know about?

I thought this particular lookup was okay because the facts are already part of the API response, and it's only for a single host.

[ekohl]

IMHO that it retrieves facts now is a bug already, not something to expand on.

[ekohl]

And on persistence, yes we have a facet. But linking that on my phone is awkward

[jeremylenz]

I think you probably mean the reported data facet, right?

Will update this PR, but probably not before next week.

[ekohl]

Yes, that is exactly what I was thinking about

[chris1984]

@jeremylenz here is a PR I made a while back for the host OS UI card adding facts into the reported_data facet if you want an example: #9460

[jeremylenz]

@chris1984 Updated to use reported data facet.

[chris1984]

Thanks for switching to the reported data facet, tested again on my box and I can see card coming up for hosts and in the debug console I can see it's using the reported facts. Code looks good too and the migration works properly up and down, thanks for all the test coverage :)

AWS:

Azure:

GCP:

Non cloud host:

Cloud host with facts not being reported and card not showing up as intended:

[jeremylenz]

Addressed comments (see commit messages.)

[jeremylenz]

@jnagare-redhat When automation is complete and you are happy, please comment here to ack my PR :) thanks!

[jnagare-redhat]

Ack
Automation is ready and will raise PR tomorrow. Was waiting for satellite-jenkin PR to have configuration available.

[chris1984]

Tested with the latest changes and still works. Screenshots from the last test are still valid so keeping them out of the PR to reduce noise.

[jeremylenz]

squashed

[ekohl]

On my phone so a partial review. Apologies for that.

I'm starting to think how it looks. In my head I'm wondering how to tackle this (without coming to an answer). Do you want a block that had a generic header "cloud provider" (or similar) or specific (like "AWS details" or Azure details")?

The other interaction I'm wondering about is compute resources. If you have it linked up, do you combine it? Might be confusing to have a block with partially data you can set and partially data that us reported. Again, on my phone so hard to check but some might even overlap.

Sorry to throw this all at you but it took me a while to wrap my head around it.

[jeremylenz]

Updated:

• Renamed from CloudBilling to CloudProvider with CloudProvider prefix on all components
• Case statement for provider detection (instead of if-trees)
• Dynamic provider-specific headers ("AWS details", "Azure details", "GCP details") with "Cloud provider details" as fallback

@ekohl I didn't quite understand your comment about compute resources and combining editable data with read-only data. Did you mean the Virtualization card vs. this Cloud Billing Provider Details card? In any case, this information on the new card is what was requested thru PM in the feature. I guess it would be a bigger conversation if we were to combine that with something else.

[jeremylenz]

Updated the card display logic so the absence of cloud_provider and compute_resource_provider won't prevent display of the card. We now have a three-level fallback: cloud_provider → compute_resource_provider → auto-detect from data.

[ekohl]

@ekohl I didn't quite understand your comment about compute resources and combining editable data with read-only data. Did you mean the Virtualization card vs. this Cloud Billing Provider Details card? In any case, this information on the new card is what was requested thru PM in the feature. I guess it would be a bigger conversation if we were to combine that with something else.

The point I tried to make: we have compute resources, which is displayed as the Virtualization card (and I disagree with that name it's inconsistent with how we call it everywhere else). Then this information very closely correlates with that. We may even be able to extract similar information directly from the compute resource.

Now as a user it may be confusing to have it in 2 cards, each with their own data source. We've already seen the feedback in the community that the host details page is becoming messy because it's too many cards. Quoting https://community.theforeman.org/t/new-hosts-page-ui-is-getting-bad-reviews/44394/6#p-144324-host-details-page-3

Information too scattered across multiple boxes/tabs

And later in the summary:

Host details = too scattered, old UI still more efficient

So just because it came via PM doesn't mean we can't push back or thing about the implementation. Technically PM can't even force anything in the upstream community.

In short, I'd like to think about the bigger picture: does adding this information actually make the overall user experience worse?

[jeremylenz]

does adding this information actually make the overall user experience worse?

I think it makes it better, since it gathers relevant account data into one place and focuses on the cloud provider rather than the host. Also I think it's possible to have this card and not have a Virtualization card, since that card relies on compute_resource_provider. Cards will only display if they are relevant, so this shouldn't add any extraneous data to the screen. And the overlap with the Virtualization card is at most one or two fields.

[jeremylenz]

Also, IMO the time for debate about basic design should be much sooner than the final PR review stages. I'm happy to talk about it but I wish it had been earlier. (preferably before the PR is even opened.)

[ColeHiggins2]

Since this has been tested twice, im happy to ack it. @ekohl you are the final approval :)

[jeremylenz]

Also I'd like @jnagare-redhat 's final ack when automation is complete, thanks tho Cole :)

[jnagare-redhat]

Ack Automation running and raised PR

[ekohl]

Thanks for addressing my many comments. I know I sort of steered the design quite late, but I think it's better now.

I still think we should think more about how we organize the various cards on the detail page, but this PR is not the place for that.

Edit: not pressing the merge button since it's not clear to me if @jnagare-redhat's message means this is ready to be merged or not.

[jnagare-redhat]

Yes its ready to merge.

[ekohl]

Thanks! Merged.

@jnagare-redhat FYI: everyone can leave a review on PRs and approve, even if they don't have merge permissions. I'd encourage you to use that. Also request changes when something is failing.