BZ860751 - %postun scriptlet fails for aeolus-conductor-daemons

https://bugzilla.redhat.com/show_bug.cgi?id=860751

This implements the condrestart action for the delayed_job sysvinit
script.  The %postun scriptlet for the daemon subpackage is updated to
use the condrestart action on non-systemd systems.

For more info, see:
https://fedoraproject.org/wiki/Packaging:SysVInitScript?rd=Packaging/SysVInitScript#condrestart_and_try-restart
Don't erase %{app_root} during %pre

Here's roughly what is happening here

- RPM is asked to update aeolus-conductor

- As part of the transaction, RPM checks the status of settings.yml.
  RPM finds that (1) settings.yml is marked as %config in the spec
  file, (2) settings.yml as shipped with $new_version contains the
  same content as shipped with $old_version (it ignores the contents
  of the file as it exists on the filesystem), and (3) settings.yml
  has local modifications (via aeolus-configure).

- Because of 1-3 above, RPM marks settings.yml to be skipped during
  the transaction.

- The %pre scriptlet runs, and removes %{app_root}, which in turn
  removes settings.yml.

- Because the transaction has already decided to skip settings.yml, no
  action is taken on it.  At this point, the file is gone.  RPM will
  not lay down the file as it exists in the RPM, nor will it produce
  any sort of .rpmsave or .rpmnew file.

Related bug:
860822 - aeolus-conductor RPM upgrade deletes settings.yml
https://bugzilla.redhat.com/show_bug.cgi?id=860822
Merge pull request #78 from jeckersb/bz860751

Works for me. "BZ860751 - %postun scriptlet fails for aeolus-conductor-daemons"
Don't error if condrestart of delayed_job fails

This will happen when trying to downgrade to an older version of
aeolus-conductor-daemons where the init script doesn't support the
condrestart option.  In this case, the best thing to do is to just do
nothing.
Merge pull request #85 from jeckersb/condrestart-fix

Don't error if condrestart of delayed_job fails
Update to latest converge-ui to include new forms etc.
RM 3879 - consider vanished instances with queued stop request as stopped

For ec2 and openstack an instance disappears after it's stopped.
So marking such instances as stopped may be better than mark them as vanished.

https://www.aeolusproject.org/redmine/issues/3879
Consider 401 code as valid when checking provider connection

dc-core returns 401 if no credentials are passed when doing any openstack request,
but conductor can not send credentials when connecting through provider model.
For provider connection test (valid_framework? method) can be 401
response code considered as valid. Bug is tracked here:
https://issues.apache.org/jira/browse/DTACLOUD-330

The connection test is currently not very usable anyway because for most drivers
it just checks if "deltacloud knows about this driver" but not real end-provider
connection is tested.
This can be improved on Conductor side once the following issue is solved on deltacloud side:
https://issues.apache.org/jira/browse/DTACLOUD-307
Don't destroy openstack instances on provider side

Destroy is done automatically when stop request is sent.
Cucumber features for upcoming Catalogs API

All features are marked as @wip and will be unmarked as the features get
implemented.
Routes and #index for Catalogs API

RM3579

Routes for Catalogs API added.

List catalogs action (#index) implemented, rspec'd and cucumbered.
Catalogs API #show action

RM3580

Implemented, speced, cucumbered.
Catalogs API #create action

RM3578

Implementation, specs, cucumbers.

CatalogsController gets a before filter to transform incoming parameters
for #create and #update from:

    :catalog => {
      :name => '...',
      :pool => {
        :id => '...'
      }
    }

to:

    :catalog => {
      :name => '...',
      :pool_id => '...'
    }

Loading catalogs' deployables was previously used only in #show action,
now it is used in #create as well, because API version of #create
renders the same thing as #show. Therefore, loading deployables has been
extracted into private load_deployables method, similarly to a
load_pools method which is already present in CatalogsController.

One shared RSpec API expample is added to allow testing for `201
Created` response status conveniently.
Catalogs API #update action

RM3581

Implementation, specs, cucumbers.

In #update action of the controller, the permission check for altering the
catalog's pool association was changed. Previously the check was performed
always, this was causing problems when updating with just partial
representation of the catalog (when pool_id was not specified at all).  Now the
check is performed only if pool_id is present in params.
Catalogs API #destroy action

RM3582

Implementation, specs, cucumbers.
Add Catalogs API to entrypoint

RM3796
Add catalogs listing to Pools #show API action

RM3695

Also added a new FactoryGirl factory - :pool_with_catalog
Check permissions when listing pool's catalogs

PoolController #show action listed all pool's catalogs. Now it lists
only catalogs that current user is permitted to see. (Currently, this
should mean no practical difference, as if a user is permitted to see a
given pool, they're also permitted to see all it's catalogs.)
BZ859998 disable certain fields from editing if in ldap mode

Signed-off-by: Matt Wagner <matt.wagner@redhat.com>
Merge pull request #80 from jeckersb/bz860822

Don't erase %{app_root} during %pre