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

network-ng add interfaces renaming support #921

Merged
merged 15 commits into from Aug 22, 2019

Conversation

imobachgs
Copy link
Contributor

@imobachgs imobachgs commented Aug 20, 2019

This PR implements support to rename an interface using a udev rule.

  • Handle udev rules
  • Add an API to rename interfaces
  • Adapt UI
  • Rename routes
  • Support for hotplug devices
  • Do not overwrite custom rules

@imobachgs imobachgs changed the base branch from master to network-ng August 20, 2019 15:46
@@ -45,6 +45,8 @@ class Interface
attr_reader :configured
# @return [HwInfo]
attr_reader :hardware
# @return [Symbol] Mechanism to rename the interface (nil -no rename-, :bus_id or :mac)
attr_accessor :renaming_mechanism
Copy link
Member

Choose a reason for hiding this comment

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

this looks quite limiting for me as I would hope that in future we can allow to rename interface more flexible, e.g. by user provided bus_id or by different udev value, which is currently not supported ( and means that for e.g. usb attached wifi you cannot set udev name, as udev rules are empty in dialog ).

Copy link
Contributor Author

Choose a reason for hiding this comment

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

You are right, I did not though about hotplug devices. Maybe we could add a renaming_value (provided by the user). But I would keep the renaming_mechanism so we know against which attribute we should match.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Or we could even take those renaming_mechanism/renaming_value to a separate class.

Copy link
Member

Choose a reason for hiding this comment

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

maybe it will be more flexible to have it in own class.

:mac
elsif rule.parts.any? { |p| p.key == "KERNELS" }
:bus_id
end
Copy link
Member

Choose a reason for hiding this comment

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

don't we kill some complex udev rules there? E.g. if customer has his nice handcrafted udev rule for network card, if it survive run of yast2-network?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

The current implementations kills them anyway.

Copy link
Member

Choose a reason for hiding this comment

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

yep, but we should aim to behave better as I see many customers use fine tuned udev rules.

UdevRulePart.new("SUBSYSTEM", "==", "net"),
UdevRulePart.new("ACTION", "==", "add"),
UdevRulePart.new("DRIVERS", "==", "?*"),
UdevRulePart.new("ATTR{type}", "==", "1")
Copy link
Member

Choose a reason for hiding this comment

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

some explanation here would be nice.

# @param udev_rules [Array<UdevRule>] List of udev rules
def write(udev_rules)
Yast::SCR.Write(Yast::Path.new(".udev_persistent.rules"), udev_rules.map(&:to_s))
Yast::SCR.Write(Yast::Path.new(".udev_persistent.nil"), [])
Copy link
Member

Choose a reason for hiding this comment

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

explanation for this tricky call?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Write changes to the file. We do something similar for sysconfig. I will add a note.

Copy link
Member

Choose a reason for hiding this comment

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

I thought it looks differently with value nil and ".udev_persistent" as path, but I can be wrong.

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 expected that too, but I learn from the old code that, in this case, it is different. I tried it manually and the "expected" version does not work.

end
# @return [String] Key name
attr_accessor :key
# @return [String] Operator ("==", "!=", "=", "+=", "-=", ":=")
Copy link
Member

Choose a reason for hiding this comment

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

important part is that first two are matching operators and rest are assign operator.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yes, that's it.

@jreidinger
Copy link
Member

what I am missing here is actual renaming in internal structures. So what I mean? That if interface A is renamed to interface B, that it will correctly use name interface B everywhere and also mark properly all objects that uses modified interface as modified, so it is written down.

@imobachgs
Copy link
Contributor Author

what I am missing here is actual renaming in internal structures. So what I mean? That if interface A is renamed to interface B, that it will correctly use name interface B everywhere and also mark properly all objects that uses modified interface as modified, so it is written down.

The PR is not finished yet :) I am writing a method in Y2Network::Config to handle such renames and keep consistency between connections and interfaces.

@coveralls
Copy link

coveralls commented Aug 21, 2019

Coverage Status

Coverage increased (+0.4%) to 65.375% when pulling df2c83f on network-ng-add_udev_support into 7c017ff on network-ng.

@imobachgs imobachgs marked this pull request as ready for review August 21, 2019 22:50
@imobachgs imobachgs merged commit c800825 into network-ng Aug 22, 2019
@imobachgs imobachgs deleted the network-ng-add_udev_support branch August 22, 2019 09:41
@imobachgs imobachgs mentioned this pull request Aug 27, 2019
2 tasks
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.

None yet

3 participants