On 12/05/2013 08:38 AM, James Slagle wrote:
On Wed, Dec 4, 2013 at 5:19 PM, Robert Collins
<robe...@robertcollins.net> wrote:
This is a follow up to https://review.openstack.org/59621 to get
broader discussion..
So at the moment we capture a bunch of details in the image - what
parameters the image was built with and some environment variables.
Last week we were capturing everything, which there is broad consensus
was too much, but it seems to me that that is based on two things:
- the security ramifications of unanticipated details being baked
into the image
- many variables being irrelevant most of the time
I think those are both good points. But... the problem with diagnostic
information is you don't know that you need it until you don't have
it.
I'm particularly worried that things like bad http proxies, and third
party elements that need variables we don't know about will be
undiagnosable. Forcing everything through a DIB_FOO variable thunk
seems like just creating work for ourselves - I'd like to avoid that.
Further, some variables we should capture (like http_proxy) have
passwords embedded in them, so even whitelisting what variables to
capture doesn't solve the general problem.
So - what about us capturing this information outside the image: we
can create a uuid for the build, and write a file in the image with
that uuid, and outside the image we can write:
- all variables (no security ramifications now as this file can be
kept by whomever built the image)
- command line args
- version information for the toolchain etc.
+1. I like this idea a lot.
What about making the uuid file written outside of the image be in
json format so it's easily machine parseable?
Something like:
dib-<uuid>.json would contain:
{
"environment" : {
"DIB_NO_TMPFS": "1",
.......
},
"dib" : {
"command-line" : ....,
"version": .....
}
}
Could keep adding additional things like list of elements used, build time, etc.
+1 to having a machine parsable version. Is that going to be a standard
schema for all images or will there be an open-ended section that
contains key/value pairs that are contingent on the actual type of image
being built?
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
