Support setting quota defaults in charm

[David Ames]

We have run into neutron quotas on a couple of occasions both secgroups and ports in production environments

{"overLimit": {"message": "409-{u''NeutronError'': {u''message'': u\"Quota exceeded for resources: [''security_group'']\", u''type'': u''OverQuota'', u''detail'': u''''}}", "code": 413}}'

PortLimitExceeded: Maximum number of ports exceeded

We are able to set per tenant qutoas with the neutron cli but ultimately we would like to set sane defaults. Seems a few simple settings in neutron.conf will let us do just that [1]. However, the charm currently does not support this and will overwrite neutron.conf. Please add support for setting default quotas.

[1] http://docs.openstack.org/user-guide-admin/content/cli_set_quotas.html#cfg_quotas_common

[Syed Mohammad Adnan Karim (karimsye)]

Nova quota options as of rocky can be found here: https://docs.openstack.org/nova/rocky/configuration/config.html

It may seem that neutron-api charm's config options are not fully in sync with the neutron configuration docs but the additional options in the charm config are for older releases going back to Mikata.

+----------------------------+---------------------------+
| Neutron Configuration Docs | Neutron-API config.yaml |
+----------------------------+---------------------------+
| quota_router | quota-router |
| quota_floatingip | quota-floatingip |
| quota_security_group | quota-security-group |
| quota_security_group_rule | quota-security-group-rule |
| quota_network | quota-network |
| quota_subnet | quota-subnet |
| quota_port | quota-port |
| Exists in Mitaka | quota-vip |
| Exists in Ocata | quota-pool |
| Exists in Ocata | quota-member |
| Exists in Ocata | quota-health-monitors |
| default_quota | |
| quota_driver | |
| track_quota_usage | |
+----------------------------+---------------------------+

[Ryan Beisner (1chb1n)]

I'm concerned that the initial work on this may invite confusion and unintended or unknown results.

Please discuss and determine the reality of the following scenarios of that original work, and as it relates to the potential follow-on work in nova-cloud-controller.

Based on those findings, we should clearly document the expected behavior of the existing work, and the new work.

Questions and suggestions:

 * Operators typically set quotas post-deployment via the CLI. What happens that custom tuning when the quota configs are changed on the charm, post-deployment?

 * Does that conflict with, or potentially revert any post-deployment quota settings which have been set by an operator through the CLI?

 * How does changing the quota charm config impact existing projects/tenants?

 * What happens in a charm upgrade scenario where the older charm did not have these values set, and they were not rendered into the config via a template, and the newer charm does declare these values, and does render the config template? Could new quotas be imposed unexpectedly? Or could an operators' tuned quota configs change unexpectedly?

 * The original work contains no unit or functional tests. I think that needs to be addressed for sure on the new work, and ideally on both sets of work.

[David Ames (thedac)]

@Ryan,

Those are all very good questions. My 2c, my understanding is these are purely defaults and would have zero impact on existing project quotas. Quotas get set at project creation. Only new projects that are created would get these new defaults.

Having said that the upgrade scenarios you suggest should be tested as a part of the implementation.

I also don't think we would do all possible quota values but rather the more important ones: cores, ram, instances etc.

[Syed Mohammad Adnan Karim (karimsye)]

@Ryan

* Operators typically set quotas post-deployment via the CLI. What happens to that custom tuning when the quota configs are changed on the charm, post-deployment?

Answer: Custom quotas set through CLI are unchanged

* Does that conflict with, or potentially revert any post-deployment quota settings which have been set by an operator through the CLI?

Answer: Post deployment quota settings are not changed

* How does changing the quota charm config impact existing projects/tenants?

Answer: New projects will have the new changed settings from the charm config.
        Existing projects that that had their quotas modified will retain their values.
        Projects whose quotas were not modified will update to the new settings.

* What happens in a charm upgrade scenario where the older charm did not have these values set, and they were not rendered into the config via a template, and the newer charm does declare these values, and does render the config template? Could new quotas be imposed unexpectedly? Or could an operators' tuned quota configs change unexpectedly?

Answer: New projects will have the new changed settings from the charm config.
        Existing projects that that had their quotas modified will retain their values.
        Projects whose quotas were not modified will update to the new settings.

[OpenStack Infra (hudson-openstack)]

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

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/624796
Committed: https://git.openstack.org/cgit/openstack/charm-nova-cloud-controller/commit/?id=95cd9bfd106d596704c6855428d322f5a02a8e0c
Submitter: Zuul
Branch: master

commit 95cd9bfd106d596704c6855428d322f5a02a8e0c
Author: Syed Mohammad Adnan Karim <email address hidden>
Date: Wed Dec 12 18:39:32 2018 +0000

    Add default project quota configuration for compute

    Prior to this, the charm config did not support default quota
    configurations for compute (ie. instances, compute, ram, etc.).
    Default quota configuration changes will not impact existing
    projects with modified quotas. Only new projects and projects with
    unmodified quotas will adopt the defaults in the configuration file.

    The following default quota settings were added:
    instances
    cores
    ram
    metadata_items
    injected_files
    injected_file_content_bytes
    injected_file_path_length
    key_pairs
    server_groups
    server_group_members

    The functional test added checks that nova.conf quotas are set in
    the correct section of the file.

    Change-Id: Iae8c84dbfec97e1879d51963125f7674ea20ba22
    Closes-Bug: 1386911