I am now working on preparing API for Provider and ProviderAccount resources
so I want to ask some questions regarding controllers for API.
At this moment there are some controllers in API namespace and so there is duplicated functionality between UI and API parts.
In the future we will be adding features to API and CLI tool too.
I think that we need to decide wheter keep UI and API controllers separated or merge them together.
I think that best will be to merge them together.
Controller should be as skinny as possible with minimum logic (parameters sanitizing, model call, render results - view or whatever).
Controller should respond to html, js, json, xml, etc...
All the logic now present in controllers should be moved to models or some other classes which will work with models (delegators, decorators, name it...)
Please, write your thoughts and/or experience with this kind of problem.
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
While enjoying a donut K-cup and reading about Kodak's revolutionary new printer this morning, I got to thinking about how some of the names we use in Conductor are confusing to end-users. I hope that this patch will clarify matters.
I took the previously-proposed "clump" name for a group of images and expanded on it in a manner consistent with previous discussions (and Dr. Seuss books). I also tried to avoid the phrase "Cloud" as it is somewhat overloaded. Of course these are just suggestions, in the event that anyone has suggestions for improvement.