Bug 1077284
| Summary: | [RFE] Allow big ranges in MacPoolManager | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Virtualization Manager | Reporter: | Nir Yechiel <nyechiel> |
| Component: | RFEs | Assignee: | Martin Mucha <mmucha> |
| Status: | CLOSED ERRATA | QA Contact: | Martin Pavlik <mpavlik> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 3.3.0 | CC: | adahms, gklein, iheim, juwu, lpeer, lvernia, masayag, mburman, mkolesni, mmucha, mpavlik, myakove, nyechiel, oblaut, rbalakri, yeylon |
| Target Milestone: | --- | Keywords: | FutureFeature, Improvement |
| Target Release: | 3.5.0 | Flags: | nyechiel:
Triaged+
|
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | network | ||
| Fixed In Version: | Doc Type: | Release Note | |
| Doc Text: |
With this feature, users can now configure a MAC pool with larger address ranges. Red Hat recommends to configure the MAC address pool to contain the majority of MAC addresses to be used. Only MAC addresses defined in the MAC address pool will be stored in memory efficiently.
|
Story Points: | --- |
| Clone Of: | 1063064 | Environment: | |
| Last Closed: | 2015-02-11 17:59:16 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | Network | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | 1063064 | ||
| Bug Blocks: | 1142923, 1156165 | ||
|
Description
Nir Yechiel
2014-03-17 16:06:51 UTC
Verified on - oVirt Engine Version: 3.5.0-0.0.master.20140821064931.gitb794d66.el6 Hi Martin, Could you provide doc text for this bug for release notes ASAP. Cheers, Julie Hi Martin,
Could you check the doc text again and let me know if this is correct?
Kind regards,
Julie
Martin, please respond to Julie's request. Julie, there's also some behavior change in MAC address range configuration following this feature - should this be described as part of the release notes? If so, please use Martin's aid in describing the change (Martin - I'm referring to the new leniency with trimmed addresses, unless the resulting range is completely empty). Adding as Julie is on leave... Hi Lior, Thank you for raising the needinfo request! As far as this release note is concerned, as long as the doc text captures the issue that was raised and how it was resolved for this bug, that is great. I am a little curious about the change in behavior, though. Is this an entirely back-end change, or does it affect the way in which users would configure anything? What is the general impact on users? Kind regards, Andrew Hi Andrew, the change is user-facing. If I'm not mistaken (Martin, feel free to correct me): * Previously if a provided MAC address range contained any invalid MAC addresses (e.g. multicast), the engine-config operation would fail altogether. * In 3.5, invalid addresses are filtered out of the ranges and the operation succeeds; that is, unless after filtering invalid addresses you are left with none, in which case the operation fails. Hi Lior, Thank you for the additional information. One more question from my end - was the change you described implemented in this bug? Or, was it implemented in a separate bug? Kind regards, Andrew Like lior said, previously if any range contained multicast value set through the engine-config was rejected. Now there is some effort made to correct user input if possible. Some changes were made here, but there's also a bug fixed here: https://bugzilla.redhat.com/show_bug.cgi?id=1165025 Hi Andrew, No problem. Yes, it was part of this feature's implementation. And we've just recalled another user-facing behavior change related to this feature: the MaxMacsCountInPool configuration value was deprecated, and only the MacPoolRanges configuration value is considered when allocating MAC addresses. I apologize for being late with this - we didn't remember this specific patch was already merged in time for 3.5. So - these two behavior changes belong in the release notes or somewhere else? Lior. Hi Martin, Lior, I think the best way to document these changes would be as release notes in the bugs where the main changes were made. For example, BZ#1165025 for the validation work. I will check on the current status of the release notes, see if there is something we can do there, and get back to you. Kind regards, Andrew Andrew, please note that the first behavior change existed before Bug 1165025 was fixed. It was just a little different than what I described (the failure in the case of empty ranges after filtering was less elegant). Bug 1165025 didn't exist in 3.4 - it was only opened due to this feature being implemented, so there's no point in documenting anything on it (it never existed in a customer-facing release). So I think all discussed documentation is related to this RFE - just not sure it should be part of the release notes. Hi Lior, Understood - thank you for the clarification. I think the release notes would be the right place to document this. Once again, I will check whether we can make changes at this time, and will provide an update. Kind regards, Andrew Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://rhn.redhat.com/errata/RHSA-2015-0158.html |