Open Stack

On 12/05/2013 08:38 AM, James Slagle wrote:
> On Wed, Dec 4, 2013 at 5:19 PM, Robert Collins
> <robertc at 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?