Synnefo

Add unique names to all NICs of all Ganeti instances

----------------------------------------------------

Since Ganeti 2.8, it is supported to give a name to a NIC of a Ganeti instance

and then refer to the NIC by that name (and not only by its index). Synnefo

v0.15 assigns a unique name to each NIC and refers to it by that unique name.

Before upgrading to v0.15, Synnefo must assign names to all existing NICs. This

can be easily performed with a helper script that is already shipped with

Synnefo v0.14.10:

addresses across VMs, each public network must exist in all Ganeti backends.

must ensure that the network configuration of all Ganeti backends is identical

Before v0.15, all Cyclades VMs were forced to be connected to the public

network. Synnefo v0.15 supports more flexible configurations and dynamic

addition/removal of public IPv4 addresses, which can result in a VMs with no

NICs at all. However, Ganeti's default allocation policy will not allow

instances without NICs. You will have to override Ganeti's default allocation

policy to set the minimum number of NICs to zero. To do this, first get the

current allocation policy:

`max:nic-count=32` to avoid reaching the default limit of 8.

In v0.15, the ``ARCHIPELAGO_BACKENDS`` setting, that was used to separate

Ganeti backend (see section in :ref:`admin guide <alloc_disk_templates>`). You

can see the enabled/allowed disk templates by inspecting the corresponding

fields in the `gnt-cluster info` output. For example, to have a backend holding

only instances with archipelago disk templates, you can set the

`--ipolicy-disk-templates` to include only the `ext` disk template.

4. Re-register services and resources.

2.3 Register Pithos view as an OAuth 2.0 client in Astakos

Starting from Synnefo version 0.15, the Pithos view, in order to get access to

the data of a protected Pithos resource, has to be granted authorization for

the specific resource by Astakos.

Astakos, since the latter has to prevent serving requests by

unknown/unauthorized clients.

To register the Pithos view as an OAuth 2.0 client in Astakos, use the

following command (with the corresponding URL to reflect your deployment)::

The ``ASTAKOS_BASE_URL`` setting has been replaced (both in Cyclades and Pithos

services) with the ``ASTAKOS_AUTH_URL`` setting.

``ASTAKOS_AUTH_URL``. Typically it is sufficient to add ``/identity/v2.0`` at

the end of base URL to get the auth URL. For example, if base URL had the value

of 'https://accounts.example.synnefo.org/' then the ``ASTAKOS_AUTH_URL``

For the Pithos service we have to change the ``20-snf-pithos-app-settings.conf``

In case you are upgrading from an older snf-vncauthproxy version or if it's the

restart the vncauthproxy daemon.

To manage the authentication file, you can use the ``vncauthproxy-passwd`` tool,

``synnefo`` in the vncauthproxy authentication file and enable SSL support if

includes a ``DAEMON_OPTS`` variable which is used to pass any necessary/extra

Django (snf-webproject) app that serves the VM stats graphs by reading the VM

stats (from RRD files).

To enable/deploy the VM stats collecting and snf-stats-app, see the relevant

If you were using collectd to collect VM stats on Debian Squeeze and you are

You will probably just need to run the `migration script

value/string and make sure that it's the same as the ``STATS_SECRET_KEY``

  Skip this step unless you have ``shibboleth`` enabled in Astakos

As of v0.15 Astakos uses the ``REMOTE_USER`` header provided by Apache's

``mod_shib2`` service in order to resolve the unique identifier which is used

to associate a shibboleth account to a local Astakos user. Prior to this

version, Astakos adhered to the presence of the ``MOD_SHIB_EPPN`` header which

although safe enough on most of the ``SP`` deployment scenarios, it may cause

issues in certain cases, such as global wide IdP support or inability of

supported IdPs to release the ``eduPersonPrincipalName`` attribute. The

``REMOTE_USER`` header can be set by administrators to match any of the

available shibboleth attributes.

**Note** that every time you alter the ``REMOTE_USER`` attribute, all existing

shibboleth enabled Astakos users will be invalidated and no longer be able to

login to their existing account using shibboleth. Specifically, for the case of

switching from *eppn* to another attribute, Astakos is able to prevent

existing *eppn* user logs in using shibboleth, Astakos will update the

associated *eppn* identifier to the contents of the ``REMOTE_USER`` header.

be dynamically added/removed to/from VMs and are quotable via the

``cyclades.floating_ip`` resource. Connecting a VM to a public network is only

allowed if the user has first allocated a floating IP from this network.

automatically released when these VMs get destroyed. If the admin wants to

convert existing public IPs to floating IPs, he/she can do so by running the

following provided tool:

or just for one network:

service and resource definitions. On the Astakos node, run::

The meaning of resources ``cyclades.cpu`` and ``cyclades.ram`` has changed in

v0.15: they now denote the number of CPUs/RAM of *active* VMs (VMs that are not

shutdown) rather than all VMs as happened until now. To represent total CPUs

and total RAM, as previously, two new resources ``cyclades.total_cpu`` and

``cyclades.total_ram`` are introduced. We now also control the usage of

floating IPs through the resource ``cyclades.floating_ip``.

The new resources (``cyclades.total_cpu``, ``cyclades.total_ram``, and

``cyclades.floating_ip``) are registered with infinite default base quota

(meaning that they are not restricted at all). You will probably need to

restrict them, especially ``cyclades.floating_ip``. In order to change the

default limit of a resource for all *future* users, for instance restricting

floating IPs to 2, run::

    astakos-host$ snf-manage user-modify --all --base-quota cyclades.floating_ip 2 --exclude userid1,userid2

   You can inspect base quota with ``snf-manage quota-list``, before applying

Furthermore in v0.15, it is possible to control whether a resource is visible

to the users via the API or the Web UI. The default value for these options is

denoted inside the default resource definitions. Note that the system always

checks and enforces resource quota, regardless of their visibility. By default,

the new resources ``cyclades.total_cpu``, ``cyclades.total_ram`` and

``astakos.pending_app`` are not visible neither via the API nor via the Web UI.

You can change this behavior with::