On 08/02/2011 09: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.
I asked Mike about this recently and he told me this was possible
already. When the admin puts their certs to a proper location,
aeolus-configure will use them instead of generating new ones.
So this may be as simple as verifying and properly documenting the case.
>
> -------------------
>
> Identity:
>
> Currently we use a users table in the db to store user identity. We need
> to be able to integrate a user store from LDAP, whether it be a server
> we setup ourselves via configure or an external one we integrate in
> (both need to be supported)
Yep, that seems reasonable to me.
>
>
> -------------------
>
> Configuration profiles / interactive installer:
>
> The start of this was sent to list, but essentially a mechanism to
> install different aeolus components on different machines, configuring
> them to be interoperable with each other and existing infrastructure
> resources (qmf, ldap, or postgres servers for example).
>
> Furthermore a user friendly interactive installer should be provided so
> that an admin can setup / configure only the specific components and
> seed data that they are looking for
>
> -------------------
>
> IPv6 support:
>
> No work has been done to make Aeolus IPv6 compliant and this should be
> done at some point.
>
> -------------------
>
> Single click deployments:
>
> The simpler the Aeolus experience the better, there should be a small
> widget on the first conductor page after logging in allowing the user to
> select a template and select a provider to deploy to before clicking to
> actually launch it. The rest of the nitty-gritty details should be taken
> care of by the app itself.
>
> This would be a patentable feature for a 'one-click cloud deployment'
>
> -------------------
>
> Improved rubygem/rpm and ruby/fedora integration:
>
> The gem2rpm and ruby-rpm bindings can be improved significantly to
> assist in our bundling of project dependencies and the ruby -> Fedora
> release process. Specifically we should be able to do alot more in terms
> of dependency analysis and making sure any given gem stack will work as
> intended on our infrastructure.
>
> Furthermore our existing tooling, such as the rpm/yum rake tasks, can be
> improved and made available to the greater ruby community.
>
> -------------------
>
> 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.
>
>
> -------------------
>
> 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.
>
>
> 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.