Merge ~smoser/cloud-init:fix/cii-kvmimage-preserve-original into cloud-init:master
| Status: | Merged |
|---|---|
| Approved by: | Scott Moser on 2017-11-29 |
| Approved revision: | 27ff24127c0bd5074817a199eb373cae5ab83d29 |
| Merged at revision: | 88368f9851b29dddb5a12e4b21868cbdef906c5c |
| Proposed branch: | ~smoser/cloud-init:fix/cii-kvmimage-preserve-original |
| Merge into: | cloud-init:master |
| Diff against target: |
200 lines (+42/-26) 4 files modified
tests/cloud_tests/images/nocloudkvm.py (+15/-7) tests/cloud_tests/instances/nocloudkvm.py (+5/-3) tests/cloud_tests/platforms/nocloudkvm.py (+11/-10) tests/cloud_tests/snapshots/nocloudkvm.py (+11/-6) |
| Related bugs: |
| Reviewer | Review Type | Date Requested | Status |
|---|---|---|---|
| Ryan Harper | 2017-11-22 | Approve on 2017-11-29 | |
| Server Team CI bot | continuous-integration | Approve on 2017-11-27 | |
| Joshua Powers (community) | Approve on 2017-11-22 | ||
|
Review via email:
|
|||
Commit Message
tests: NoCloudKVMImage do not modify the original local cache image.
The NoCloudKVMImage
that meant that after the first time you ran a test, the image was
dirty.
The change here is to make the image operate on a qcow backed image.
Also modify Snapshot to then copy the qcow rather
than creating another chained qcow. The reason being that the image
might go away but the snapshot stick around.
Also
* drop use of 'override_
* NoCloudKVM.
now it has create_instance which creates an instance.
* NoCloudKVMInstance has a 'disk' attribute separate from 'name'
| Joshua Powers (powersj) wrote : | # |
+1 This also makes sure we are able to properly use --preserve-data now with qcow2 files that are ready to boot in the event triage is needed, even if the original file is deleted.
Test with:
python3 -m tests.cloud_tests run --platform nocloud-kvm \
--verbose --preserve-data --data-dir out --os-name xenial \
-t modules/write_files -t modules/
--deb cloud-init_
I appreciate the cleanup of the variable names to be more specific as to what each is.
PASSED: Continuous integration, rev:86255ca411f
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:/
| Ryan Harper (raharper) wrote : | # |
What's the use case for the "destroy an image without breaking a snapshot" that introduces the copy of the image.
Some more comments inline as well.
| Scott Moser (smoser) wrote : | # |
An image is a mutable thing.
General flow of tests is:
- get an image
- update the image (install a new deb)
- create a snapshot
- launch a snapshot multiple times
After creating a snapshot of the image the image can reasonably be destroyed.
Just like in a "real cloud".
- get an image (download a cloud image or boot an instance we can update/modify)
- update the image
- create a snapshot (publish to a new ami id)
At the point where we've created a new snapshot we no longer need the image.
As it was previously, if we deleted the Image that the snapshot was created from, then the snapshot (a qcow image) was broken.
| Ryan Harper (raharper) wrote : | # |
> An image is a mutable thing.
> General flow of tests is:
> - get an image
> - update the image (install a new deb)
> - create a snapshot
> - launch a snapshot multiple times
>
> After creating a snapshot of the image the image can reasonably be destroyed.
> Just like in a "real cloud".
> - get an image (download a cloud image or boot an instance we can
> update/modify)
> - update the image
> - create a snapshot (publish to a new ami id)
>
> At the point where we've created a new snapshot we no longer need the image.
Sure, but where in the workflow of our nightly tests will the images be purged,
or where in a developer workflow would the images actually get removed.
Does part of the make cloud-tests or whatever remove images?
>
> As it was previously, if we deleted the Image that the snapshot was created
> from, then the snapshot (a qcow image) was broken.
I'm not terribly concerned about manual deletion of images; Is there some
automatic removal of images that would let a tree rot such that invoking
a cloud-test at a later time would break without the copy?
- 27ff241... by Scott Moser on 2017-11-27
| Scott Moser (smoser) wrote : | # |
the Image object has a destroy() method which is valid to call, and should be called whne you're "done" with the object.
i = Image(foo)
i.execute(
s = i.snapshot()
i.destroy()
s.launch()
...
the result of snapshot needs to be stand-alone, and before this change it was not.
As used above, s.launch() would have failed as it was qcow backed by i.
FAILED: Continuous integration, rev:cc9905002cd
https:/
Executed test runs:
SUCCESS: Checkout
FAILED: Unit & Style Tests
Click here to trigger a rebuild:
https:/
PASSED: Continuous integration, rev:27ff24127c0
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:/
| Ryan Harper (raharper) wrote : | # |
> the Image object has a destroy() method which is valid to call, and should be
> called whne you're "done" with the object.
> i = Image(foo)
> i.execute(
> s = i.snapshot()
> i.destroy()
> s.launch()
> ...
>
> the result of snapshot needs to be stand-alone, and before this change it was
> not.
> As used above, s.launch() would have failed as it was qcow backed by i.
But is this called in this way via how users and CI interact with the test-suite?
I suspect it's not; and nothing is doing the above or the test-suite would have broken.
| Scott Moser (smoser) wrote : | # |
It looks like as it is right now we do not call destroy on an image before using a snapshot.
But having NoCloud work like other clouds makes sense.
As it is right now we only ever call snapshot wrapped in a context handler of an image.
| Ryan Harper (raharper) wrote : | # |
On Mon, Nov 27, 2017 at 4:31 PM, Scott Moser <email address hidden>
wrote:
>
> It looks like as it is right now we do not call destroy on an image before
> using a snapshot.
> But having NoCloud work like other clouds makes sense.
>
I don't disagree with the goal; however; just as I don't want to upload a
new snapshot
each time I launch a VM, I don't want to copy over the image each time I
launch one in
NoCloud.
Can we model the image manipulation like we would the clouds?
i = Image(foo)
i.execute(
s = i.snapshot()
new_image = cloud.upload(s)
new_image.launch()
I think that makes it clear that one *could* delete the original image
second the upload allows for NoCloud to do a copy and return a new path to
the image
which hopefully we could re-use on subsequent runs
i = cloud.get_
i.launch()
After the upload, I think it'd be fair for cloud.get_image() to return a
qcow2 image backed against the "uploaded" snapshot which would
avoid the copy and allow the original image to be deleted (not that we have
a use-case for that).
>
> As it is right now we only ever call snapshot wrapped in a context handler
> of an image.
>
> --
> https:/
> init/+merge/334147
> Your team cloud-init commiters is requested to review the proposed merge
> of ~smoser/
> cloud-init:master.
>
> _______
> Mailing list: https:/
> Post to : <email address hidden>
> Unsubscribe : https:/
> More help : https:/
>


PASSED: Continuous integration, rev:b82bed1db43 0c94df690261f72 0cceda2e58a235 /jenkins. ubuntu. com/server/ job/cloud- init-ci/ 539/
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: /jenkins. ubuntu. com/server/ job/cloud- init-ci/ 539/rebuild
https:/