Fixed lp:1483879: Use MAAS 1.8+ devices for containers by default #3730
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
|
|
Status: merge request accepted. Url: http://juju-ci.vapour.ws:8080/job/github-merge-juju |
|
Build failed: Tests failed |
|
|
|
Status: merge request accepted. Url: http://juju-ci.vapour.ws:8080/job/github-merge-juju |
jujubot
added a commit
that referenced
this pull request
Nov 16, 2015
Fixed lp:1483879: Use MAAS 1.8+ devices for containers by default This PR changes the default behavior around starting and stopping both LXC containers and KVM instances, regardless whether the feature flag "address-allocation" is enabled or not. It aims to resolve a few corner cases where container resources (IP addresses or DHCP leases) can leak over time, especially if the same underlying MAAS substrate is being reused over and over again (i.e. CI/CD automated tests, OIL, etc.). The cases are: $ juju destroy-environment --force $ juju destroy-machine # --force $ juju destroy-machine # See the related LP bug http://pad.lv/1483879 With this patch, before any container is started, Juju will now make a best effort to register the container as a MAAS 1.8+ device with a pre- generated MAC address, and then explicitly claim a sticky IP address for it. In case older MAAS version is used or a non-MAAS provider in general, the process goes on as expected. Also, if using the experimental, feature-flagged addressable containers, the existing behavior is preserved (allocating a static IP, tracking its lifecycle, releasing it by the addresser worker). Manually tested on MAAS 1.9.0rc1 in the following combinations: 1. precise/trusty/vivid/wily MAAS node hosting one or more LXC/KVM containers with matching series (without the feature flag enabled). 2. same as 1., but with the address-allocation feature flag on. 3. same as 1., but with MAAS 1.8.3 (stable). 4. same as 3., but with the feature flag on. In all cases tested so far, it was verified all containers get addresses as expected, and without the feature flag, there are matching devices created on MAAS, and the latter are removed as the containers are stopped. (Review request: http://reviews.vapour.ws/r/3136/)
jujubot
added a commit
that referenced
this pull request
Nov 18, 2015
Fixed lp:1483879: Use MAAS 1.8+ devices for containers by default Forward port of #3730 from 1.25 to master. The following is the original PR's description. This PR changes the default behavior around starting and stopping both LXC containers and KVM instances, regardless whether the feature flag "address-allocation" is enabled or not. It aims to resolve a few corner cases where container resources (IP addresses or DHCP leases) can leak over time, especially if the same underlying MAAS substrate is being reused over and over again (i.e. CI/CD automated tests, OIL, etc.). The cases are: $ juju destroy-environment --force $ juju destroy-machine # --force $ juju destroy-machine # See the related LP bug http://pad.lv/1483879 With this patch, before any container is started, Juju will now make a best effort to register the container as a MAAS 1.8+ device with a pre- generated MAC address, and then explicitly claim a sticky IP address for it. In case older MAAS version is used or a non-MAAS provider in general, the process goes on as expected. Also, if using the experimental, feature-flagged addressable containers, the existing behavior is preserved (allocating a static IP, tracking its lifecycle, releasing it by the addresser worker). Manually tested on MAAS 1.9.0rc1 in the following combinations: 1. precise/trusty/vivid/wily MAAS node hosting one or more LXC/KVM containers with matching series (without the feature flag enabled). 2. same as 1., but with the address-allocation feature flag on. 3. same as 1., but with MAAS 1.8.3 (stable). 4. same as 3., but with the feature flag on. In all cases tested so far, it was verified all containers get addresses as expected, and without the feature flag, there are matching devices created on MAAS, and the latter are removed as the containers are stopped. (Review request: http://reviews.vapour.ws/r/3153/)
jujubot
added a commit
that referenced
this pull request
Jan 12, 2016
Revert PRs #3730 #3866 #3877 #3966 (which switched to using devices for containers) Using devices by default for containers as a behavior is being backed out as it turns out MAAS 1.8 (latest stable in trusty) doesn't do a full cleanup of the devices IPs, so in fact using devices makes things worse. It was decided to back out the original #3730 and the follow-ups to it like #3966 and #3866 (they fix issues introduced by the first PR, e.g. http://pad.lv/1520199 and http://pad.lv/1525280). Tested on 1.7, 1.8, and 1.9 to confirm devices are not created unless the address-allocation feature flag is on (and then on 1.8+ only, as 1.7 doesn't support devices). (Review request: http://reviews.vapour.ws/r/3474/)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR changes the default behavior around starting and stopping both
LXC containers and KVM instances, regardless whether the feature flag
"address-allocation" is enabled or not. It aims to resolve a few corner
cases where container resources (IP addresses or DHCP leases) can leak
over time, especially if the same underlying MAAS substrate is being
reused over and over again (i.e. CI/CD automated tests, OIL, etc.).
The cases are:
$ juju destroy-environment --force
$ juju destroy-machine # --force
$ juju destroy-machine #
See the related LP bug http://pad.lv/1483879
With this patch, before any container is started, Juju will now make a
best effort to register the container as a MAAS 1.8+ device with a pre-
generated MAC address, and then explicitly claim a sticky IP address
for it. In case older MAAS version is used or a non-MAAS provider in
general, the process goes on as expected. Also, if using the experimental,
feature-flagged addressable containers, the existing behavior is preserved
(allocating a static IP, tracking its lifecycle, releasing it by the
addresser worker).
Manually tested on MAAS 1.9.0rc1 in the following combinations:
containers with matching series (without the feature flag enabled).
In all cases tested so far, it was verified all containers get addresses
as expected, and without the feature flag, there are matching devices
created on MAAS, and the latter are removed as the containers are stopped.
(Review request: http://reviews.vapour.ws/r/3136/)