One of the features to consider during our planning sprint was #3106,
investigating moving our Redmine install to OpenShift, Red Hat's PaaS
offering. The Express tier is free, and would free us from having to
maintain the dedicated VM we run right now for Redmine. The real
motivation for this task is that Redmine is sometimes _excruciatingly_
slow, with responses sometimes exceeding ~35 seconds, at which point
Apache times out the connection.
is the wiki page for this feature. (The page might be slow...)
I set up a demo instance of Redmine on OpenShift. After a quick bit
of experimentation, I found a handful of pros, and one con that I think
may be a deal-breaker. I wanted to get some more input from the team.
+ It's much faster. If you hit it after prolonged inactivity, it may
take ~10 seconds; I presume this is the time for Passenger to spin the
app back up. I've only had that happen once; otherwise, it's been quite
responsive, with average page loads taking under a second. For me, this
is the biggest win: it's fast!
+ It's pretty easy to use. To apply updates, you push to the repo on
OpenShift and it restarts the app. This contrasts with the current
setup, where I guess a couple of people have ssh access to some random
VM where it's running.
+ I haven't actually tried it, but it appears that there's an easy way
to do backups/snapshots, so we don't have to worry about a catastrophic
database failure. I don't know if anything is in place now.
- Although HTTPS works out of the box, you cannot currently upload
custom certificates. This means that, although we can easily run the
site on a CNAME (e.g., redmine.aeolusproject.org), we cannot have
SSL work that way. There is an open feature request for this, but it's
not currently available. Therefore, we would either need to (a) not
use SSL at all, or (b) use the default .rhcloud.com domain.
There are some various, unrelated things I'd like to continue exploring,
such as the persistence of file uploads, how database backups work,
etc., but I'm wondering if the current SSL limitations should be
considered a deal-breaker for our needs right now. Please let me know
what you think.
I have a new RHEL 6.2 install with the latest Aeolus install from the
repo. I also have a RHEV 3.0.3 install. I am following the RHEVM
provider setup here -
However, a couple of differences, the
/etc/aeolus-configure/nodes/rhevm_configure is slightly different from
what's in the mailing list and suggested on the wiki. Mine is this:
After setting these, I run 'aeolus-configure -p mock,ec2, rhevm' and
everything appears to be successful. However then I go to
https://localhost/conductor/providers and create a new RHEV provider
and click save, I keep getting an error 'Failed to connect to
What am I missing? Are there some logs or debug output that I can look at?
Copy of wiki page below, actual page here:
== Summary ==
Provide a simpler way for the community/sysadmins to add and test new
== Owner ==
TBD, initial write-up by jayg
== Current status ==
* Targeted release: TBD
* Last update: See wiki history
== Screencast Demo ==
None at this time
== Implementation tasks ==
== Detailed description ==
The first example of this is openstack, which may already be
integrated by the time this feature is done. Deltacloud already has
(theoretical) openstack/rackspace support. Factory can build for
Rackspace, and Openstack will require some tweaks/testing to get it
working correctly (see [[Implementing_OpenStack_support|here]] for
detail). In order for a community member to attempt to contribute
support for Openstack in Aeolus, they currently need to jump through a
number of hoops to even see if deltacloud and factory will 'just work'
for this case. At a minimum, a contributor would need to edit:
In addition, they need to install the proper deltacloud driver and
make any config needed for factory. These latter 2 are not in scope
for this feature, other than as cross-project documentation efforts
== High-level implementation details ==
I propose we add an API for adding provider types. This would entail:
* New controller and/or actions to add provider type CRUD support
* Changes to model to support any dynamic fields needed for a user of
* the conductor to be able to properly add a new provider of this type
* (perhaps this already exists as part of the add provider/account api
* changes to UI to allow a new provider to be added based on any that
* have provider types in the db
** TBD - keep/enhance the current 'enable/disable' concept? If so, we
would need UI at some point to enable any preseeded providers that are
not fully tested/supported. First pass might just allow this to be
done via API.
** X-deltacloud-provider field (and we'll want more customization on
the way -- dropdown for ec2 regions with stuff pulled from deltacloud;
2-step entry for RHEV with "datacenter-free" top level provider URL
provided; then deltacloud ives us a list of provider URLs including
cluster UUID, etc.) -suggested by sseago
== Future plan ==
* Add cli support to call this api
* Add rake task to prepopulate from a list(?). Maybe something like a
* yml file with details, that calls api for all those provider types
* Add/change calls in configure to use this new api
* Query factory to see if a given provider type is supported for
* building. If not, we can still allow importing of existing images
* in conductor. This would depend on v2.x of the factory api
This was a moderately challenging bug to track down, and Imre deserves heaps of credit for tracking it down. The problem is that rack-restful_submit was not rewriting the request on the Edit page, because it was a PUT and restful_submit only works with POSTs.
The fix here is a simple one -- we don't use restful_submit for this form, and instead fall back to the more traditional pattern of submitting the form and checking the button's value. This fixes the issue and avoids any larger changes late in the game.
Imre also reports success by removing "config.middleware.use Rack::RestfulSubmit" in application.rb, and replacing it with "config.middleware.swap Rack::MethodOverride, 'Rack::RestfulSubmit'". I don't fully understand the impact of that change just yet, so I'm reluctant to propose that in a bugfix phase, but it deserves a look longer-term.
Yesterday, Francesco Vollero and yours truly were interviewed by Randal
Schwartz and Aaron Newcomb. We talked Aeolus on a show dedicated to open
If you're interested, you can download the interview (video and
audio-only available) from this page:
or view it on YouTube:
Now, let's all be super nice to the hordes of contributors this brings