Merge ~powersj/cloud-init:cii-enable-ec2 into cloud-init:master
| Status: | Merged |
|---|---|
| Approved by: | Scott Moser on 2018-01-06 |
| Approved revision: | 0ccf7852289ff0274feb8c7b9d0920ddfefa7ad2 |
| Merged at revision: | 34595e9b4abacc10ac599aad97c95861af34ea54 |
| Proposed branch: | ~powersj/cloud-init:cii-enable-ec2 |
| Merge into: | cloud-init:master |
| Diff against target: |
1211 lines (+784/-95) 17 files modified
.pylintrc (+1/-1) doc/rtd/topics/tests.rst (+32/-6) tests/cloud_tests/collect.py (+12/-7) tests/cloud_tests/platforms.yaml (+6/-5) tests/cloud_tests/platforms/__init__.py (+2/-0) tests/cloud_tests/platforms/ec2/image.py (+109/-0) tests/cloud_tests/platforms/ec2/instance.py (+126/-0) tests/cloud_tests/platforms/ec2/platform.py (+231/-0) tests/cloud_tests/platforms/ec2/snapshot.py (+66/-0) tests/cloud_tests/platforms/instances.py (+69/-1) tests/cloud_tests/platforms/nocloudkvm/instance.py (+35/-53) tests/cloud_tests/platforms/nocloudkvm/platform.py (+4/-0) tests/cloud_tests/platforms/platforms.py (+69/-0) tests/cloud_tests/releases.yaml (+6/-2) tests/cloud_tests/setup_image.py (+0/-18) tests/cloud_tests/util.py (+15/-2) tox.ini (+1/-0) |
| Related bugs: |
| Reviewer | Review Type | Date Requested | Status |
|---|---|---|---|
| Scott Moser | Approve on 2018-01-06 | ||
| Server Team CI bot | continuous-integration | Approve on 2018-01-05 | |
| Chad Smith | 2017-12-13 | Approve on 2018-01-05 | |
|
Review via email:
|
|||
Commit Message
tests: Enable AWS EC2 Integration Testing
This enables integration tests to utilize AWS EC2 as a testing platform by
utilizing the boto3 Python library.
Usage will create and delete a custom VPC for every run. All resources will
be tagged with the ec2 tag, 'cii', and the date (e.g. cii-20171220-
The VPC is setup with both IPv4 and IPv6 capabilities, but will only hand out
IPv4 addresses by default. Instances will have complete Internet access and
have full ingress and egress access (i.e. no firewall).
SSH keys are generated with each run of the integration tests with the
key getting uploaded to AWS at the start of tests and deleted on exit.
To enable creation when the platform is setup the SSH generation code is
moved to be completed by the platform setup and not during image setup.
The nocloud-kvm platform was updated with this change.
Creating a custom image will utilize the same clean script,
boot_clean_script, that the LXD platform uses as well. The custom AMI
is generated, used, and de-registered after a test run.
The default instance type is set to t2.micro. This is one of the smallest instance types and is free tier eligible.
The default timeout for ec2 was increased to 300 from 120 as many tests
hit up against the 2 minute timeout and depending on region load can
go over.
Documentation for the AWS platform was added with the expected
configuration files for the platform to be used. There are some
additional whitespace changes included as well.
pylint exception was added for paramiko and simplestreams. In the past these
were not already flagged due to no __init__.py in the subdirectories of files
that used these. boto3 was added to the list of dependencies in the tox
ci-test runner.
Description of the Change
All Tests on Bionic + Xenial with image version of cloud-init
---
ec2: https:/
ec2: https:/
lxd: https:/
nocloud-kvm: busted daily image
$ python3 -m tests.cloud_tests run --os-name bionic --os-name xenial --platform ec2 --preserve-data --data-dir results_ec2 --verbose
$ python3 -m tests.cloud_tests run --os-name bionic --os-name xenial --platform lxd --preserve-data --data-dir results_lxd --verbose
$ python3 -m tests.cloud_tests run --os-name bionic --os-name xenial --platform nocloud-kvm --preserve-data --data-dir results_nocloud_kvm --verbose
All Tests on Bionic + Xenial with Bionic deb of cloud-init
---
ec2: https:/
lxd: https:/
nocloud-kvm: https:/
$ python3 -m tests.cloud_tests run --os-name bionic --os-name xenial --platform ec2 --preserve-data --data-dir results_ec2 --verbose --deb cloud-init_
$ python3 -m tests.cloud_tests run --os-name bionic --os-name xenial --platform lxd --preserve-data --data-dir results_lxd --verbose --deb cloud-init_
$ python3 -m tests.cloud_tests run --os-name bionic --os-name xenial --platform nocloud-kvm --preserve-data --data-dir results_nocloud_kvm --verbose --deb cloud-init_
PASSED: Continuous integration, rev:ec97516df65
https:/
Executed test runs:
SUCCESS: Checkout
SUCCESS: Unit & Style Tests
SUCCESS: Ubuntu LTS: Build
SUCCESS: Ubuntu LTS: Integration
SUCCESS: MAAS Compatability Testing
IN_PROGRESS: Declarative: Post Actions
Click here to trigger a rebuild:
https:/
| Scott Moser (smoser) wrote : | # |
i have not gotten all the way thought, but some things in line.
thanks Josh!
| Ryan Harper (raharper) wrote : | # |
"AWS at the start of tests and deleted on exit."
I think the keys will need to always be deleted no matter whether we finish; unless we specifically have some flag the user set to keep keys.
I don't think we want automatic runs of this to fail at any stage after injecting keys and not have it ensure it removes the keys.
Something to the effect of a trap_on_
which removes the keys unless the flag to keep them is present on the command line.
| Ryan Harper (raharper) wrote : | # |
Some in-line comments and questions.
| Ryan Harper (raharper) wrote : | # |
Replaced my pop() with next() in the in-line comments.
PASSED: Continuous integration, rev:3f76bbf7b58
https:/
Executed test runs:
SUCCESS: Checkout
SUCCESS: Unit & Style Tests
SUCCESS: Ubuntu LTS: Build
SUCCESS: Ubuntu LTS: Integration
SUCCESS: MAAS Compatability Testing
IN_PROGRESS: Declarative: Post Actions
Click here to trigger a rebuild:
https:/
| Joshua Powers (powersj) wrote : | # |
Added commit for using stream image data and comments with more questions from intial reviews of Scott and Ryan. Thank you both!
| Scott Moser (smoser) wrote : | # |
Thank you for a good text commit message that makes reading things easier.
* t2.micro for default instance type
the smallest type that will work for both ebs(ssd) and instance-store
from a quick look, m4.large (2 cpu / 8G) at $0.10/hr is the cheapest
you can find something that runs on instance-store that exists
in all regions (many do not have m3.medium).
I guess at least just comment somewhere about ebs affecting instance types.
* boot_clean script: at some point it makes sense to use 'cloud-init clean'
* can you mention in your commmit message that you removed trailing
whitespace? Just looking, its hard to see the difference, and I
assumed that I was just missing it with my eyes. ie:
-The integration testing suite can automatically build a deb based on the
+The integration testing suite can automatically build a deb based on the
* vpc creation. You create a single vpc with 'cloud-
you create ephemeral ssh keys, and properly clean up afterwards.
Is there any reason not to create ephemeral vpc and cleanup?
After typing that I googled. There is a default limit of 5 vpc per region.
http://
* what will happen with vpc (or other) resources multiple instances of the test harness are running at the same time? All be ok? Particularly since we're not re-creating vpc and gateway and such, it could be problematic.
| Scott Moser (smoser) wrote : | # |
wrt apt config here is a tested example that does work
#cloud-config
apt:
primary:
- arches: [default]
uri: http://
security:
- arches: [default]
url: http://
| Chad Smith (chad.smith) wrote : | # |
Looks great Josh thanks. I have some inline comments to resolve regarding using filters to find existing cloud-init resources in ec2 and using waiter methods. I've added a couple of discussion points about the potential of reusing or updating a named/tagged ssh key instead of use creating new ones. But, maybe we need to have that ssh discussion as a squad instead of on this branch.
Also a patch for better informing us about the required aws configuration files:
http://
| Joshua Powers (powersj) wrote : | # |
Added fixes from reviews and updated commit message.
The VPC behavior remains getting created and destroyed for every run. Trying to create one that is always used leads to conflicts and issues with trying to destroy specific components. Creating one VPC and always using that same one, leads to issues when changes in configs are needed and leaves things around between runs.
There are 4 additional merges required:
* I pulled out the testcase change as we can follow up on that in a separate merge
* Update ssh key names: don't use id_rsa
* Add integration-
* Refactor properties function, put in superclass and change family --> os
PASSED: Continuous integration, rev:322b9f9de21
https:/
Executed test runs:
SUCCESS: Checkout
SUCCESS: Unit & Style Tests
SUCCESS: Ubuntu LTS: Build
SUCCESS: Ubuntu LTS: Integration
SUCCESS: MAAS Compatability Testing
IN_PROGRESS: Declarative: Post Actions
Click here to trigger a rebuild:
https:/
- 0b61ef9... by Joshua Powers on 2017-12-20
PASSED: Continuous integration, rev:0b61ef9c235
https:/
Executed test runs:
SUCCESS: Checkout
SUCCESS: Unit & Style Tests
SUCCESS: Ubuntu LTS: Build
SUCCESS: Ubuntu LTS: Integration
SUCCESS: MAAS Compatability Testing
IN_PROGRESS: Declarative: Post Actions
Click here to trigger a rebuild:
https:/
| Scott Moser (smoser) wrote : | # |
* (from the commit message).
"The default instance type is set to t2.micro. This is the smallest type
that will work for both ebs and instance-store."
that is not true. per https:/
t2.* are 'EBS-only'.
* user-data, I think probably you should pass None if there is None.
I expect that boto is not just checking a true-ish value.
I know from experience that running an instance with '' as user-data
differs from None (in the former you do not get a 'user-data' field
in the meta-data service, in the latter you do get one).
it looks like you need to not pass UserData in the kwargs at all.
https:/
* last... i dont need this, but it woudl be nice if you (re)started the EC2Image.
that also tells us passing bytes (rather than string) is ok, and that
boto will always base64 encode for you.
* Lets add a console_log() to the EC2Instance please.
http://
- 677c607... by Joshua Powers on 2017-12-20
| Joshua Powers (powersj) wrote : | # |
I think I've addressed all the required fixes and review comments at this time. The commit message was updated to note why t2.micro was chosen (small + free tier).
Thanks!
PASSED: Continuous integration, rev:677c60738d0
https:/
Executed test runs:
SUCCESS: Checkout
SUCCESS: Unit & Style Tests
SUCCESS: Ubuntu LTS: Build
SUCCESS: Ubuntu LTS: Integration
SUCCESS: MAAS Compatability Testing
IN_PROGRESS: Declarative: Post Actions
Click here to trigger a rebuild:
https:/
| Chad Smith (chad.smith) wrote : | # |
Minor nits from me, otherwise +1 here. Ran a few tests against my own ec2 account to validate behavior. approving assuming the minor changes are made
- 9f0942c... by Joshua Powers on 2018-01-04
FAILED: Continuous integration, rev:f439c1e5600
https:/
Executed test runs:
SUCCESS: Checkout
FAILED: Unit & Style Tests
Click here to trigger a rebuild:
https:/
FAILED: Continuous integration, rev:9780f62550a
https:/
Executed test runs:
SUCCESS: Checkout
FAILED: Unit & Style Tests
Click here to trigger a rebuild:
https:/
PASSED: Continuous integration, rev:9f0942c324a
https:/
Executed test runs:
SUCCESS: Checkout
SUCCESS: Unit & Style Tests
SUCCESS: Ubuntu LTS: Build
SUCCESS: Ubuntu LTS: Integration
SUCCESS: MAAS Compatability Testing
IN_PROGRESS: Declarative: Post Actions
Click here to trigger a rebuild:
https:/
| Scott Moser (smoser) wrote : | # |
I filed upstream boto issue https:/
- aee8c01... by Joshua Powers on 2018-01-04
- 74ffc5e... by Joshua Powers on 2018-01-04
PASSED: Continuous integration, rev:74ffc5e7669
https:/
Executed test runs:
SUCCESS: Checkout
SUCCESS: Unit & Style Tests
SUCCESS: Ubuntu LTS: Build
SUCCESS: Ubuntu LTS: Integration
SUCCESS: MAAS Compatability Testing
IN_PROGRESS: Declarative: Post Actions
Click here to trigger a rebuild:
https:/
| Scott Moser (smoser) wrote : | # |
thanks for the fixes. i think we're down to just the destroy of an image destroying (the last) snapshot that was created from it.
then i think this is good.
Can you put a comment in 'Re-start instance in the case additional customization required'.
just metion there that it'd be better to only re-start on demand in execute.
And on console output... i *think* that generally speaking when an isntance shuts down that signals to ec2 that they should update their console output. i'm interested in seeing how this all works, but if we get consoel output after stop/terminate of an instance, we should get some data.,
- 14beefd... by Joshua Powers on 2018-01-05
PASSED: Continuous integration, rev:3793d3d2450
https:/
Executed test runs:
SUCCESS: Checkout
SUCCESS: Unit & Style Tests
SUCCESS: Ubuntu LTS: Build
SUCCESS: Ubuntu LTS: Integration
SUCCESS: MAAS Compatability Testing
IN_PROGRESS: Declarative: Post Actions
Click here to trigger a rebuild:
https:/
PASSED: Continuous integration, rev:751e31fe8ff
https:/
Executed test runs:
SUCCESS: Checkout
SUCCESS: Unit & Style Tests
SUCCESS: Ubuntu LTS: Build
SUCCESS: Ubuntu LTS: Integration
SUCCESS: MAAS Compatability Testing
IN_PROGRESS: Declarative: Post Actions
Click here to trigger a rebuild:
https:/
PASSED: Continuous integration, rev:44cf1af45fd
https:/
Executed test runs:
SUCCESS: Checkout
SUCCESS: Unit & Style Tests
SUCCESS: Ubuntu LTS: Build
SUCCESS: Ubuntu LTS: Integration
SUCCESS: MAAS Compatability Testing
IN_PROGRESS: Declarative: Post Actions
Click here to trigger a rebuild:
https:/
PASSED: Continuous integration, rev:14beefdcc7d
https:/
Executed test runs:
SUCCESS: Checkout
SUCCESS: Unit & Style Tests
SUCCESS: Ubuntu LTS: Build
SUCCESS: Ubuntu LTS: Integration
SUCCESS: MAAS Compatability Testing
IN_PROGRESS: Declarative: Post Actions
Click here to trigger a rebuild:
https:/
| Joshua Powers (powersj) wrote : | # |
On Fri, Jan 5, 2018 at 11:24 AM, Chad Smith <email address hidden>
wrote:
> > +
> > + def _execute(self, *args, **kwargs):
> > + """Execute command in image, modifying image."""
> > + self._instance.
>
> I think the double _instance.start call path should be find because the
> initial call is called with wait=True as well which will block until
> instance is in running state, which instance.start noops on.
>
agreed and tried it both ways This seemed cleaner.
- 0ccf785... by Joshua Powers on 2018-01-05
PASSED: Continuous integration, rev:0ccf7852289
https:/
Executed test runs:
SUCCESS: Checkout
SUCCESS: Unit & Style Tests
SUCCESS: Ubuntu LTS: Build
SUCCESS: Ubuntu LTS: Integration
SUCCESS: MAAS Compatability Testing
IN_PROGRESS: Declarative: Post Actions
Click here to trigger a rebuild:
https:/
| Scott Moser (smoser) wrote : | # |
I've rebased, squahshed and updated the commit message a bit.
tox && centos check in progess. and hten pushing.


FAILED: Continuous integration, rev:ec97516df65 46c1092eaf89960 942d6064d435e7 /jenkins. ubuntu. com/server/ job/cloud- init-ci/ 627/
https:/
Executed test runs:
SUCCESS: Checkout
SUCCESS: Unit & Style Tests
SUCCESS: Ubuntu LTS: Build
FAILED: Ubuntu LTS: Integration
Click here to trigger a rebuild: /jenkins. ubuntu. com/server/ job/cloud- init-ci/ 627/rebuild
https:/