From: "Hugh Brock" <hbrock(a)redhat.com>
Date: Fri, 17 Jun 2011 10:52:57 -0400
I just wanted to make absolutely clear everyone understands that
RHEV-M 2.2 support is super-short-term, will never go to production,
and that therefore we will not spend any time trying to encrypt config
server interactions for rhev-m 2.2. Instead we'll focus on working
with 3.0 which has a much nicer mechanism for moving this kind of
data around.
I think everyone already knows this but I wanted to reiterate it once
more to make sure.
[jrd jumps on bandwagon]
Yes. Repeating and amplifying on what Hugh said; the rather kludgey
way we've scoped for getting rhev-m 2.2 integrated should be viewed
*only* as a prototyping/beta thing. Its mission in life is to
demonstrate that we can use our own virt backend as part of a
conductor/aeolus deployment. 1.0 of the product will be targetted at
rhev-m 3.0, which is quite a bit more capable in the ways that matter
for our integration.
In terms of the security stuff specifically, it matters that we do a
plausible job when deploying to ec2, because it's public. rhev-m
isn't public, so it's not worth spending time on security there for
beta.