On 08/02/2011 03:34 PM, Chris Lalancette wrote:
On 07/28/11 - 06:51:16PM, Mo Morsi wrote:
> Some of these have been discussed, while some of these have been sitting
> on my backlog for ages.
>
> -------------------
>
> Encryption:
>
> Currently configure allows us to generate ssl certificates for
> conductor, we need to expand this to generate ssl certs for
> imagefactory, iwhd, condor and deltacloud,
>
> Furthermore, AFAIK a cert creation resource type and provider is lacking
> in the upstream puppet project. We can split these bits into its own
> puppet resource type and provider and send that upstream for inclusion
> into there.
Even more, we need the ability to import certs, since all of the ones that we
would generate would be "self-signed". I'm not quite sure how we do this
(whether it comes from IPA, via configure, etc), but we should look at what we
need to do this.
This should be more easily accomplishable w/ the configuration profiles
patches on list. The interactive installer can prompt the user to enter
the location of their certificates and/or generate them if need be.
>
> -------------------
>
> IPv6 support:
>
> No work has been done to make Aeolus IPv6 compliant and this should be
> done at some point.
>
This could take a long time if a single person does it themselves, but
if we parallelize this a bit (eg have seperate people making sure ipv6
is supported for iwhd, imagefactory, deltacloud, and conductor and have
some QA resources to test this) this could be done in no time and would
be a strong selling point.
> -------------------
>
> Code audit and improvements
>
> There are alot of things that can be cleaned up, optimized and improved
> in general in the aeolus codebase. Particularly conductor can be
> optimized and should be improved to make use of ActiveResource,
> ActiveModel, and other Rails 3 features
As part of this, I would love to see us examine the current dependencies and
see which ones are redundant or could be replaced by something simpler.
Agreed.
>
>
> -------------------
>
> Condor REST frontend
>
> If we can accomplish this, we can remove alot of the needless
> replication from our conductor db, replacing the ActiveRecord models w/
> ActiveResource derived ones. Furthermore, we can get rid of condormatic
> all together
I'm not sure about this one. In particular, condor already has a QMF frontend,
so it would seem to me that we would want an ActiveRecord model for the condor
QMF. However, we aren't quite there yet with determining what to do in terms
of controlling condor, so I would put this off for now.
Well activerecord is meant to interface w/ a db only. The problem is
this is that we are now replicating data, eg instances now are both
stored in condor and in the db and have to be kept in sync (eg dbomatic).
Rather if we added a REST frontend to condor (essentially pulling
condormatic into its own seperate service) and/or use the generic REST
<-> QMF adapter (replacing condormatic all together), we can drop the
notion of instances from our db, and simple derive instance from
activeresource, removing any data replication.
Alternatively since we are on rails 3 we could drop condormatic and the
instances table and simply derive Instance from ActiveModel [1], tying
the instance lifecycle to QMF.
As you mentioned though, since the fate of Condor in Aeolus is up in the
air, will let this one be fore the moment.
>
>
> Thoughts?
One thing I don't see mentioned here which will be immensely important is
getting the whole system running end-to-end with SELinux. That is going to be
a requirement to get this into any sort of product, so we should add tasks for
it.
Didn't we define selinux policies for aeolus? What happend to those? Do
they need updating?
-Mo
[1]
http://www.rubyinside.com/rails-3-0s-activemodel-how-to-give-ruby-classes...