[RFE] Introduce Network QoS policy "is_default" behaviour

[Dr. Jens Harbott]

Introduce a new parameter in Network QoS policy: "is_default".

If a new Network QoS policy is created/set with the parameter "is_default" equal to True, any new network created for that project will have this default QoS policy assigned.

E.g.:
- Create a new QoS policy
    openstack network qos policy create --is-default qos_1
- Create a new network
    openstack network create net_1
This new network, "net_1", will have "qos_1" as QoS policy.

The parameter "is-default" can be set in the creation and the update commands.

If a new Network QoS policy is created or updated with this flag and another Network QoS policy in the same project is set as the default policy, the new one won't be created or updated (see subnet-pool behaviour).

[Miguel Angel Ajo (mangelajo)]

I discussed that with kevin, and it seems like RBAC doesn't fit with "default",
RBAC is role based access control, which has nothing to do with default settings
I guess this comes from the presentation I prepared with slaweq , but that part was wrong, sorry. We need to find another way to do it

[Miguel Angel Ajo (mangelajo)]

Does it make sense to have, from the openstack-cli interface point of view, something like:

openstack network qos policy default (create/set/delete) ?

and again, if it's the admin who created that default, for a policy the specific tenant has no access to, he won't be able to delete it or change it, because we assume it's admin enforced.

[Reedip (reedip-banerjee-deactivatedaccount)]

IMHO openstack network qos policy create/set/delete --default would be a way to go.
This means this policy would be set by default for any network based resource linked to that QoS policy ( and I am taking this in as this sort of implementation may be a tad bit similar to how subnets are linked to a default-subnetpool in neutron )

[Miguel Angel Ajo (mangelajo)]

This makes sense, but let's refactor the explanation and title on the RFE to not talk about RBAC at all, this is not RBAC.

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/430363

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/432260

[Miguel Angel Ajo (mangelajo)]

As per meeting discussion, it would be more beneficial to have something like:

$ neutron qos-default-policy bandwidth-limit-10M
or, as admin
$ neutron qos-default-policy bandwidth-limit-10M --to-project <uuid_of_project>

So admins would be able to enforce policies to projects, as well as projects to themselves.

[YAMAMOTO Takashi (yamamoto)]

Miguel,

if you change the default, it would affect all existing ports which doesn't have explicit setting?
in other words, to figure out which policy to use for a port, an implementation need to look at the port, its network, and then the tenant?
i'm wondering how it will be propagated to backends.

[Rodolfo Alonso (rodolfo-alonso-hernandez)]

Hello:

@Miguel:
The behaviour you are asking for is currently present in the patch. A QoS policy belongs to a project and the "is_default" flags only affects to policies belonging to this project. That means you can have as many default QoS policies as projects you have in the deployment.

Take a look at QoSPolicy create function:
    def create(self):
        with db_api.autonested_transaction(self.obj_context.session):
            default_policy = obj_db_api.get_object(self.obj_context,
                                                   self.db_model,
                                                   project_id=self.project_id,
                                                   is_default=True)
            if default_policy and self.is_default:
                raise exceptions.QosDefaultPolicyFound(
                    policy_id=default_policy.id)
            super(QosPolicy, self).create()
            self.reload_rules()

The "default_policy" is filtered by "self.project_id".

A made some manual tests using the following patches:
- Neutron: https://review.openstack.org/#/c/428304/
- SDK: https://review.openstack.org/#/c/430363/
- OSclient: https://review.openstack.org/#/c/432260/

I created several QoS policies in several projects:
$ network qos policy create qos_demo_1 --default --project demo
$ network qos policy create qos_demo_2 --project demo
$ network qos policy create qos_alt_demo_1 --default --project alt_demo
$ network qos policy create qos_alt_demo_2 --project alt_demo

These commands are executed correctly. As you can see you have two default QoS policies. Then, I tried to set a second default rule in "demo" project:
$ network qos policy set qos_demo_2 --default
HttpException: Conflict, QoS policy 7ae20620-28c9-4fe7-b0f8-8015be4969ee is the default policy.
                                                 ^^ is qos_demo_1

Is this the behaviour you are expecting?

BTW, taking a look at the QoS policies, only admin can create/update/delete policies and rules. IMO we need to change this.

@Yamamoto:
This implementation doesn't provide this feature. If the default QoS policy is changed, it won't affect the existing ports. When a new port is created and a default QoS policy exists, the server will asign explicitly this QoS policy to this port.

In a nutshell: there is no propagation. This feature was meant to assign a QoS policy to new ports.

[Miguel Angel Ajo (mangelajo)]

Yes, but the model you're proposing doesn't let the admin own a policy, and attach that policy by default to a tenant.

The model you proposed in patch only works for self-created policies (by tenants).

I believe it would be more flexible if we have another api call / db table to let us assign existing policies to tenants.

That way, the admin can have a set of default policies, and attach those to tenants by default, even if the tenant has no access to such policy (and hence he can't shake the policies off)

[Miguel Angel Ajo (mangelajo)]

> BTW, taking a look at the QoS policies, only admin can
> create/update/delete policies and rules. IMO we need to change this.

That's controlled by the policy.json file, and it's something the admins
can configure in their cloud, depending on the cloud model (if the tenant
is trusted to create it's own policies or not).

[Rodolfo Alonso (rodolfo-alonso-hernandez)]

Hello Miguel Angel:

Ok, now I understand the requirement: to have admin policies, only accesible by the admin and attachable to other projects. Is that correct? That means the admin will be able to set default policies to other projects and users beloging to them won't be able to modify those rules.

Let me think about how can we address this.

Questions:
- If qos policies are only admin accesible, the new model is not necessary: only admin can manage those rules.

- If qos policies are project user accesible, even though the admin sets a default qos policy to a network or a port, the user can override this assigning manually a qos policy to this element. I know that, by default, those elements (project net/port) will have always an inmutable (not user accesible) qos policy, but if the user has granted qos privileges, I don't think this is very useful.

- When you say "...to let us assign existing policies to tenants", you mean to project networks/ports?

Regards.

[Ihar Hrachyshka (ihar-hrachyshka)]

I don't think we should restrict changing default policy to admins. We don't restrict users from creating a port without a policy right now, and I don't think we should since it's UX feature, not a permission restriction RFE (at least the way it's described right now).

We would need to allow project owners (or whoever is allowed in policy.json) to mark a policy as default. On port/network creation, the value of the default policy will be copied into resource. (I believe we should not track later changes to the default policy since it's potentially disruptive.)

There is a question on what to do if a default policy is removed. I believe then we should unset the default value for all affected projects.

If there is interest in introducing a mechanism to ENFORCE a policy for a project, then it's a different discussion that would require a separate RFE.

[Rodolfo Alonso (rodolfo-alonso-hernandez)]

Hello Ihar:

> There is a question on what to do if a default policy is removed. I believe then we should unset
> the default value for all affected projects.

You mean to unset the default QoS, but not to remove the QoS policy already assigned to port/networks, isn't it?

I agree with your opinion: this RFE is not about enforcing a policy for a project.

This is what I implemented: https://review.openstack.org/#/c/428304/

[Ihar Hrachyshka (ihar-hrachyshka)]

> You mean to unset the default QoS, but not to remove the QoS policy already assigned to port/networks, isn't it?

Yes, just unset the policy that would be applied for new ports/networks; but don't change policy for existing networks/ports.

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/428304
Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=9d69822e4391edcfb659538f18069a61037d3f12
Submitter: Jenkins
Branch: master

commit 9d69822e4391edcfb659538f18069a61037d3f12
Author: Rodolfo Alonso Hernandez <email address hidden>
Date: Wed Feb 1 15:15:16 2017 +0000

    Add "default" behaviour to QoS policies

    This patch implements the "default" behaviour for QoS policies.
    If this flag is enabled for a QoS policy in a project, all
    new networks created will have this QoS policy assigned by default.

    If a new QoS policy is created or updated with this flag and another
    QoS policy in the same project is set as the default policy, the new
    one won't be created or updated. To set another QoS policy as default,
    the current one must be unset.

    DocImpact: A "default" flag is introduced for QoS policies. If this flag
               is enabled in a QoS policy (attached to a project), then all
               networks created in this project would have this QoS policy
               assigned, unless an explicit policy is specified.
    APIImpact

    Closes-Bug: #1639220
    Change-Id: If5ff2b00fa828f93aa089e275ddbd1ff542b79d4

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/430363
Committed: https://git.openstack.org/cgit/openstack/python-openstacksdk/commit/?id=7d851893951a8c0932d9e5efc179b39ee6e1b8c5
Submitter: Jenkins
Branch: master

commit 7d851893951a8c0932d9e5efc179b39ee6e1b8c5
Author: Rodolfo Alonso Hernandez <email address hidden>
Date: Fri Feb 3 16:51:10 2017 +0000

    Add new parameter "is_default" to Network QoS policy.

    Closes-Bug: #1639220
    Depends-On: If5ff2b00fa828f93aa089e275ddbd1ff542b79d4
    Change-Id: Ibe7b7881cb190bfd5582f35b6de51a8bc21135de

[OpenStack Infra (hudson-openstack)]

This issue was fixed in the openstack/neutron 11.0.0.0b2 development milestone.

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/432260
Committed: https://git.openstack.org/cgit/openstack/python-openstackclient/commit/?id=c17819ab58db7ded30644d63575d47ee3c963ada
Submitter: Jenkins
Branch: master

commit c17819ab58db7ded30644d63575d47ee3c963ada
Author: Rodolfo Alonso Hernandez <email address hidden>
Date: Thu Feb 16 18:55:02 2017 +0000

    Add new parameter "is_default" to Network QoS policy.

    Add a set of exclusive parameters to the Network QoS policy:
      --default: makes this policy the default policy for
                 the project to which the qos policy belongs.
      --no-default: unset the property.

    Closes-Bug: #1639220
    Depends-On: If5ff2b00fa828f93aa089e275ddbd1ff542b79d4
    Depends-On: Ibe7b7881cb190bfd5582f35b6de51a8bc21135de
    Change-Id: I0269b837dc29bbd8ee2089d847cadb72d800fa30

[OpenStack Infra (hudson-openstack)]

This issue was fixed in the openstack/python-openstackclient 3.12.0 release.