Restart libvirtd after config file changed

When a compute node changes to a new virtualization host,
/etc/libvirtd/qemu.conf is changed, and libvirtd needs to get
restarted to make the change effective. To avoid timing problems,
all packages have to be installed on the system, before the libvirtd
restart check happens
Add crowbar-status and crowbar-failed in schema

Otherwise, barclamp_mgmt_lib.rb will edit the schema and add them, which
will make the files differ from the ones in the package.

Part of https://bugzilla.novell.com/show_bug.cgi?id=776583
Set proposal_schema_version to 2 in crowbar.yml

This is needed when we have crowbar-status/crowbar-failed in the schema.
Move quantum_metadata_proxy_shared_secret out of network

The attributes in network are really about nova-network, which is not
the case here.
Port nova.conf to Grizzly

No need to conditionalize rabbit_settings, the recipe won't catch that
either. Config values that we set the same as upstream have been removed.
'logdir' is the deprecated name for 'log_dir'. Explicitly set
glance_host / glance_port. The option
'dhcpbridge_flagfile=/etc/nova/nova.conf' could have never worked, since
dnsmask config files look entirely differnt
(http://www.thekelleys.org.uk/dnsmasq/docs/dnsmasq.conf.example), thus
use the upstream default.

We only set public_interface when using nova-network and if the node has
a public IP, otherwise upstream default. Since this is Eth0, I assume we
rather want None. Similarly, I guess we want api_rate_limit=True
(default).

Dropped outdated config options:

 additional_compute_capabilities=pv,hvm (xen)
 daemonize=True
 root_helper=sudo nova-rootwrap
 enable_zone_routing=true
 allow_admin_api=true
 use_deprecated_auth=false
 connection_type=libirt

SUSE Notes:

A "auto_assign_floating_ip" config value exists for nova-network, don't
know if quantum implements that in Grizzly.
Port nova.conf to Grizzly / rework vnc settings.

As far as I can see it makes no sense to conditionalize novnc / xvpvnc proxy
config values. Defaults are applied anyway and whether these values are
used or not depends on which vnc binary / service is used.
Port nova.conf to Grizzly / Remaining network parts

Dropped outdated config options:

  flat_network_dhcp_start
  image_service (it's always Glance)
  floating_range (but the project recipe still uses it)
  libvirt_vif_type
Incorporate changes from recent merges
rhel initial support
lot of fixes for centos
Set the correct device names for "fixed" and "public"

Since https://github.com/crowbar/barclamp-deployer/pull/147 was merged the
deployer barclamp automatically include the vlan id in the interface attribute.
This should fix linux-bridge support again, which was broke since the above
mentioned pull request.
Resolve issue with objectstore.s3server
Only clean up if the tests are successful.  Otherwise, leave the setup for debugging purposes.

Fixed:

/opt/dell/barclamps/nova/smoketest/00-deploy-nova-vm.test: line 260: [: =: unary operator expected

in the event that the disk probe ssh fails.
Add support for Live migrations with Xen
Added back in execute permissions
Install python-ceilometer not python-ceilometerclient

ceilometer.compute.nova_notifier is packaged in
python-ceilometer, not in python-ceilometerclient.
There is no use for python-ceilometerclient.
Force "use_vlan" to false on nova_fixed when using vlan modes

When ovs is used in vlan-mode quantums sets up an ovs-bridge to do the vlan
tagging. That bridge needs be attached to a none VLAN interface in order to
work correctly.

When linux-bridge is used quantum's linux bridge agent will create the correct
vlan interfaces automatically.
webui: Use sections to group options belonging together
Fix/Cleanup nova.conf for quantum

Do not set network_manager when using quantum.  Addtionally stop creating
config values that are just needed for nova-network.  Support for nova-network
was dropped some time ago for this barclamp.

Set the correct vif Interface driver of when using quantum with linuxbridge.
Notify Ceilometer on Nova Compute state changes

Otherwise there are not really that many events to record..