Merge lp:~dooferlad/juju-ci-tools/juju-ci-tools-addressable-containers into lp:juju-ci-tools
| Status: | Work in progress |
|---|---|
| Proposed branch: | lp:~dooferlad/juju-ci-tools/juju-ci-tools-addressable-containers |
| Merge into: | lp:juju-ci-tools |
| Diff against target: |
934 lines (+878/-2) 3 files modified
assess_container_networking.py (+427/-0) jujupy.py (+41/-2) test_container_networking.py (+410/-0) |
| To merge this branch: | bzr merge lp:~dooferlad/juju-ci-tools/juju-ci-tools-addressable-containers |
| Related bugs: |
| Reviewer | Review Type | Date Requested | Status |
|---|---|---|---|
| Martin Packman (community) | 2015-08-10 | Needs Fixing on 2015-08-11 | |
|
Review via email:
|
|||
Description of the Change
This adds tests to check container networking as set up by the Juju addressable containers feature.
It contains comprehensive unit tests and passes make lint.
An unusual but I hope useful feature that, if you like it, should end up in a library is the request_machines / clean_environment pair of functions. They allow you to use an existing environment and existing machines to run tests on. This is particularly useful during development of tests because bringing up machines and containers is time consuming and when some of your tests are "ping google.com" then you don't want to wait 10 minutes to see if your fix for a dumb mistake works. Obviously you don't want to use it in production, but it sure speeds up test development!
I realise this is about 1000 lines (about half are tests) and I am happy to go through them with the reviewer.
| Aaron Bentley (abentley) wrote : | # |
This is a follow-on to Martin's review.
Please don't apologize for the length of your diff. Instead, please split your work into separate chunks, as described in https:/
Please merge trunk and fix conflicts.
I haven't reviewed the unit tests, because I think the code being tested will change a lot.
See comments inline.
| James Tunnicliffe (dooferlad) wrote : | # |
Thanks for your comments. I clearly wasn't looking at the right tests for example code and should have asked to pair on this!
| James Tunnicliffe (dooferlad) wrote : | # |
I will be returning to this in a few days after we hit feature freeze - I haven't forgotten it!
| Aaron Bentley (abentley) wrote : | # |
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 2015-08-17 05:19 AM, James Tunnicliffe wrote:
>> + while new_machine_count > 0: +
>> new_machine_count -= 1 + with
>> client.
>
> If memory serves it was because client.juju is blocking and I
> wanted to add multiple machines or containers in parallel. Will
> look for a nicer solution.
The point of the juju_async is that you do something in the 'with'
block while the process is executing. When you exit the block, we
call subprocess.
'with block' is the same as doing a blocking call.
Assuming 2 machines, here's what you've done:
1. For machine 1, client.
called. The process starts.
2. For machine 1, client.
called. This blocks until the process exits.
3. For machine 2, client.
called. The process starts.
4. For machine 2, client.
called. This blocks until the process exits.
What you want is something like:
1. For machine 1, client.
called. The process starts.
2. For machine 2, client.
called. The process starts.
3. For machine 1, client.
called. This blocks until the process exits.
4. For machine 2, client.
called. This blocks until the process exits.
The simplest way of achieving this that I can see is recursion:
def add_many_
if machine_count == 0:
return
with client.
Of course, Python limits recursion. So another option would be
itertools.nested:
machine_contexts = [client.
with itertools.
pass
Unfortunately, itertools.nested is deprecated. There is syntax to
replace it, but AFAICT, it does not support variable-length lists.
Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAEBAgAGBQJ
Bva8Y/8oe5y2uBT
MoxhCz4hn083Wfy
OzChtvoJLO8b2WW
WsxXmCcqTnfwIP0
umKArOJVkQ6vLJ8
=02h5
-----END PGP SIGNATURE-----
| Aaron Bentley (abentley) wrote : | # |
> Unfortunately, itertools.nested is deprecated. There is syntax to
> replace it, but AFAICT, it does not support variable-length lists.
According to StackOverflow, contextlib2.
http://
http://
- 1003. By James Tunnicliffe on 2015-09-15
-
Initial post-review updates.
- 1004. By James Tunnicliffe on 2015-09-21
-
Refactored assess_
networking. py and associated tests. Now far more modular and shorter. - 1005. By James Tunnicliffe on 2015-09-21
-
changed 'lxc' and 'kvm' into constants.
removed extra_env from bootstrap.
Unmerged revisions
- 1005. By James Tunnicliffe on 2015-09-21
-
changed 'lxc' and 'kvm' into constants.
removed extra_env from bootstrap. - 1004. By James Tunnicliffe on 2015-09-21
-
Refactored assess_
networking. py and associated tests. Now far more modular and shorter. - 1003. By James Tunnicliffe on 2015-09-15
-
Initial post-review updates.
- 1002. By James Tunnicliffe on 2015-08-10
-
Some pre-review cleanup
- 1001. By James Tunnicliffe on 2015-08-10
-
Finished testing
- 1000. By James Tunnicliffe on 2015-08-04
-
Added the first few tests
- 999. By James Tunnicliffe on 2015-06-30
-
Fetch logs and configs on failure
- 998. By James Tunnicliffe on 2015-06-29
-
WIP container and VM networking tests

Thanks for the proposal!
I have a number of specific comments in line, but my general concern is this proposal adds a lot of new code just to this assess file where extending existing mechanisms would be preferable.
In particular, you could add methods in jujupy to Status for machine/container handling, and to EnvJujuClient for waiting. Using the existing bootstrap and log collection from deploy_stack would save a lot of code, and don't seem to need much modification for what you want to do here.