Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fixes #35248 - Show mac address in VmWare info #9957

Merged
merged 1 commit into from
Dec 18, 2023

Conversation

girijaasoni
Copy link
Contributor

@girijaasoni girijaasoni commented Dec 15, 2023

Hammer changes that rely on this PR are: theforeman/hammer-cli-foreman#624

@theforeman-bot
Copy link
Member

Can one of the admins verify this patch?

2 similar comments
@theforeman-bot
Copy link
Member

Can one of the admins verify this patch?

@theforeman-bot
Copy link
Member

Can one of the admins verify this patch?

@girijaasoni girijaasoni marked this pull request as draft December 15, 2023 09:03
@girijaasoni girijaasoni marked this pull request as ready for review December 15, 2023 09:19
@@ -268,6 +268,10 @@ def show_vm
end
attributes = @vm.attributes.deep_symbolize_keys
attributes[:provider] = @compute_resource.provider
if attributes[:provider] == "Vmware"
attributes[:mac_addresses] = @vm.mac_addresses
Copy link
Member

Choose a reason for hiding this comment

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

why do we need both? which one is the method that has the right value?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I'm using attributes[:mac] = @vm.mac, for displaying the mac address in hammer output, the same method is used for UI as well.

With attributes[:mac_addresses] = @vm.mac_addresses , I'm overriding the "mac_addresses" param of attributes for the API response which otherwise would be '{}'. I explained why here.

also mac returns the value in the string format eg: "00:50:56:88:11:9e"
and mac_addresses returns it as a hash eg:{"Network Adapter 1"=> "00:50:56:88:11:9e"}
I suppose its better that I update only one value (mac_addresses) but that would need me to format the hash value to a string somewhere in the hammer_cli_foreman plugin

Copy link
Member

Choose a reason for hiding this comment

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

after the discussion, I looked at other compute resources and there's no good abstraction. Libvirt reports macs for all nics under key "nics" in a hash.

I start leaning towards "get what's available" approach.

FTR, the mac is not among attributes, since it's implemented as a method https://github.com/fog/fog-vsphere/blob/ddc5f494e72b15de375900d0c87afd9fdcde8b9c/lib/fog/vsphere/models/compute/server.rb#L218-L220

I think this is good to go and the additional mac_addresses field can be only useful (today it was empty)

Copy link
Member

@ares ares left a comment

Choose a reason for hiding this comment

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

Thanks @girijaasoni, works well, merging!

@@ -268,6 +268,10 @@ def show_vm
end
attributes = @vm.attributes.deep_symbolize_keys
attributes[:provider] = @compute_resource.provider
if attributes[:provider] == "Vmware"
attributes[:mac_addresses] = @vm.mac_addresses
Copy link
Member

Choose a reason for hiding this comment

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

after the discussion, I looked at other compute resources and there's no good abstraction. Libvirt reports macs for all nics under key "nics" in a hash.

I start leaning towards "get what's available" approach.

FTR, the mac is not among attributes, since it's implemented as a method https://github.com/fog/fog-vsphere/blob/ddc5f494e72b15de375900d0c87afd9fdcde8b9c/lib/fog/vsphere/models/compute/server.rb#L218-L220

I think this is good to go and the additional mac_addresses field can be only useful (today it was empty)

@ares
Copy link
Member

ares commented Dec 18, 2023

Btw I don't think this PR is blocked, it's the other way around. API can be extended first, hammer can then rely on the change.

@ares ares merged commit ac9fff0 into theforeman:develop Dec 18, 2023
13 of 14 checks passed
@girijaasoni
Copy link
Contributor Author

Btw I don't think this PR is blocked, it's the other way around. API can be extended first, hammer can then rely on the change.

Yes it's not. Thank you so much @ares , updated the description

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