Bug 1057494
| Summary: | nmcli: Allow to use connection name of master connection when creating slave | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Jiri Pirko <jpirko> |
| Component: | NetworkManager | Assignee: | Jirka Klimes <jklimes> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Desktop QE <desktop-qa-list> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 7.0 | CC: | dcbw, jklimes, jpirko, rkhan, thaller, vbenes |
| Target Milestone: | rc | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | NetworkManager-0.9.9.1-3.git20140313.el7 | Doc Type: | Bug Fix |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2014-06-13 12:19:45 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | |||
| Bug Blocks: | 1110708 | ||
|
Description
Jiri Pirko
2014-01-24 09:01:34 UTC
So the reason we don't allow usage of the connection id/name is that it is intended to be solely a human readable description, and not a permanent identifier. Connection names are not guaranteed to be unique (partially by design, since they are human readable) and might change if you rename files. There is also no character restriction (because they are supposed to be human readable) and thus you can put Chinese characters in them or other non-ASCII characters. The UUID or parent interface name *are* intended to be stable and used for referring to links between connections. They are restricted to ASCII characters too. So while I don't believe it's a good idea to allow connection id/name to be used for links between connections, I would certainly entertain ideas on how to make the case you encountered less confusing. Yeah, I think connection name is not a good choice for identifying master. On the other hand we could make nmcli to accept connection name and translate it to UUID. But there are problems when the name is not unique, or it simply doesn't exist yet (you even wouldn't know if the string user typed should be a connection name or an interface name). (In reply to Jirka Klimes from comment #2) > Yeah, I think connection name is not a good choice for identifying master. > On the other hand we could make nmcli to accept connection name and > translate it to UUID. But there are problems when the name is not unique, or > it simply doesn't exist yet (you even wouldn't know if the string user typed > should be a connection name or an interface name). Yes, this is a great idea. (In reply to Jirka Klimes from comment #2) > Yeah, I think connection name is not a good choice for identifying master. > On the other hand we could make nmcli to accept connection name and > translate it to UUID. But there are problems when the name is not unique, or > it simply doesn't exist yet (you even wouldn't know if the string user typed > should be a connection name or an interface name). That's what I was thinking of. Looking forward to it. Any news here? I just hit this again forgetting that I should not use connection name :( Seems very natural to me to do so. I'm pretty certain that other users would hit this. Requesting blocker flag. Thanks! The code has been pushed to upstream branch jk/rh1057494-nmcli-master-id In the code doc for verify_master_for_slave(): "Check whether master is a valid ineterface name, UUID or" -> interface The rest looks good. Pushed to upstream master: 5bfaf00 Merge nmcli code accepting 'master' for slaves as connection ID (rh #1057494) d7e1ec9 cli: accept prefix "ifname/", "uuid/" or "id/" for 'master' argument 90c02ca cli: allow specifying 'master' for slaves as connection ID (rh #1057494) This request was resolved in Red Hat Enterprise Linux 7.0. Contact your manager or support representative in case you have further questions about the request. *** Bug 1029541 has been marked as a duplicate of this bug. *** |