#151: Need owner to define basic container smoke testing requirements
---------------------+--------------------------
Reporter: acarter | Owner: maxamillion
Type: task | Status: accepted
Priority: normal | Milestone: Future
Component: --- | Resolution:
Keywords: meeting |
---------------------+--------------------------
Comment (by jberkus):
So, there's testing *docker*, and there's testing *containers*. Per
yesterday's discussion, we need a standard framework for testing container
images, which is going to be hard, given the variety. This will require
each container builder to enable these tests. Here's what I'm thinking:
1. Pull works (we can pull down the container)
2. Run works (with potential optional parameters supplied by the image
owner)
3. Some operational test works defined by the image owner (for example, on
an nginx webserver container you can get a response on port 80).
For sanity, we'd require that (3) be defined in bash or python.
HOWEVER, the problem we're going to run into is that every container image
isn't necessarily a standalone thing. For example, I build an image for
clustered PostgreSQL, and without having an etcd container available it
just errors out. Or in the Kube 1.2 demo, the ghost container there is
set up to require an nginx container to run.
Now, it would be nice to reach inside the container and say it should have
a test mode which runs standalone, but (a) that would be requiring the
image author to make changes to upstream software and (b) what's the point
in smoke-testing a standalone mode which is radically different from the
container's normal operation? So I think we're going to need to look at
smoke-testing combinations of containers ... this seems like a good role
for atomic app, really.
--
Ticket URL: <https://fedorahosted.org/cloud/ticket/151#comment:5>
cloud <https://fedorahosted.org/cloud>
Fedora Cloud Working Group Ticketing System
_______________________________________________
cloud mailing list
cloud@xxxxxxxxxxxxxxxxxxxxxxx
http://lists.fedoraproject.org/admin/lists/cloud@xxxxxxxxxxxxxxxxxxxxxxx
