It helps code readability if spacing is reasonably
consistent throughout.
Hmm, so I just tried the above. What that is essentially
trying to do is read the entire disk into memory, then
pass it off as a giant string to the sha function. Clearly
this is not a workable solution. This also applies to
the virt-image hash changes as well. Haven't looked into
the correct way to do it though.
This is also a rather large performance drain. So at the
very least it should not be the default. That said, I
don't know the optimal way to expose this option, or
even if we should.
I think this will become important as we look to distribute the
appliances either via RHN or on public sites. Also.. this makes us a
bit more consistent with OVF.
I am fine with making it off by default, and then causing the command
line to turn it on.
-- bk
I'd rather it be right than kill performance and make it unusable at
best, should the imagefile be bigger than the machines memory. If we
outsource it to run a system command is that feasible, since we're
dealing with big files? I know Cole was against that originally. I'll
keep looking for a better way and cleanup the variables as well. Making
it off by default is probably best too.
_______________________________________________
et-mgmt-tools mailing list
et-mgmt-tools@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/et-mgmt-tools
