openstack: add support for neutron networks where port security is disabled

[James Page]

During our latest rebuild of serverstack, we've switch to using the neutron feature that allows port security to be disabled at a tenant network level; this has the side effect that we can't bootstrap/deploy juju controllers or models onto networks with this configuration, as security groups are not supported, so the scheduling request fails with:

'Exceeded maximum number of retries. Exceeded max scheduling attempts 3 for instance 7e066ea0-8e34-4226-9599-68536b270019. Last exception: Network requires port_security_enabled and subnet associated in order to apply security groups.'

Said networks would have 'port_security_enabled: False' attribute; This key may or may not be present depending on whether the cloud deployer has elected to use this feature of neutron. It would be great if juju could detect this and drop use of security groups in this type of deployment.

[John A Meinel (jameinel)]

Heather, do you have the bandwidth to pick this up? I think you have the
most context.

John
=:->

On Fri, Apr 7, 2017 at 2:27 PM, James Page <email address hidden> wrote:

> Public bug reported:
>
> During our latest rebuild of serverstack, we've switch to using the
> neutron feature that allows port security to be disabled at a tenant
> network level; this has the side effect that we can't bootstrap/deploy
> juju controllers or models onto networks with this configuration, as
> security groups are not supported, so the scheduling request fails with:
>
> 'Exceeded maximum number of retries. Exceeded max scheduling attempts 3
> for instance 7e066ea0-8e34-4226-9599-68536b270019. Last exception:
> Network requires port_security_enabled and subnet associated in order to
> apply security groups.'
>
> Said networks would have 'port_security_enabled: False' attribute; This
> key may or may not be present depending on whether the cloud deployer
> has elected to use this feature of neutron. It would be great if juju
> could detect this and drop use of security groups in this type of
> deployment.
>
> ** Affects: charm-test-infra
> Importance: High
> Status: Triaged
>
> ** Affects: juju
> Importance: Undecided
> Status: New
>
>
> ** Tags: serverstack
>
> ** Tags added: serverstack
>
> ** Description changed:
>
> During our latest rebuild of serverstack, we've switch to using the
> neutron feature that allows port security to be disabled at a tenant
> network level; this has the side effect that we can't bootstrap/deploy
> juju controllers or models onto networks with this configuration, as
> security groups are not supported, so the scheduling request fails with:
>
> - Exceeded maximum number of retries. Exceeded max scheduling attempts 3
> + 'Exceeded maximum number of retries. Exceeded max scheduling attempts 3
> for instance 7e066ea0-8e34-4226-9599-68536b270019. Last exception:
> Network requires port_security_enabled and subnet associated in order to
> apply security groups.'
>
> Said networks would have 'port_security_enabled: False' attribute; This
> key may or may not be present depending on whether the cloud deployer
> has elected to use this feature of neutron. It would be great if juju
> could detect this and drop use of security groups in this type of
> deployment.
>
> ** Also affects: charm-test-infra
> Importance: Undecided
> Status: New
>
> ** Changed in: charm-test-infra
> Status: New => Triaged
>
> ** Changed in: charm-test-infra
> Importance: Undecided => High
>
> --
> You received this bug notification because you are subscribed to juju.
> Matching subscriptions: juju bugs
> https://bugs.launchpad.net/bugs/1680787
>
> Title:
> openstack: add support for neutron networks where port security is
> disabled
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/charm-test-infra/+bug/1680787/+subscriptions
>

[Heather Lanigan (hmlanigan)]

Adding a note...

Different errors occur with different virt-types:
** with kvm:

| fault | {"code": 500, "message": "Exceeded maximum number of retries. Exceeded max scheduling attempts 3 for instance 92567de3-47fd-4e27-8935-297a6fb82fdc. Last exception: Network requires port_security_enabled and subnet associated in order to apply security groups.", "created": "2017-04-14T14:42:40Z"} |

** with lxd:

| fault | {"created": "2017-04-14T14:29:42Z", "code": 500, "message": "No valid host was found. There are not enough hosts available."}

[Heather Lanigan (hmlanigan)]

https://github.com/juju/juju/pull/7289

[Edward Hope-Morley (hopem)]

I have just upgraded to Juju 2.2.5 and am still seeing this problem when using the Openstack provider with an Ocata cloud. More specifically, what I see is that the problem only happens for models subsequent to the first used for any particular controller i.e. if I bootstrap a new controller, create a model and deploy some applications all is good. If i then destroy that model (but not the controller) and create a new model and repeat the deployment I hit this issue described in this bug - i.e. juju fails to allocate any instances to deploy applications to and I see that error message described in this bug. If I delete the controller and start again I get the same behaviour (i.e. its 100% repeatable).

[Mario Splivalo (mariosplivalo)]

I am seeing this behavior on latest 1.25 (1.25.13) at the time of this writing, against the same Ocata cloud Edward is mentioning above.

Adding juju-core here too, with the hope that the fix is easy and that it will not be hard to merge it to 1.25 :)

[Edward Hope-Morley (hopem)]

ok turns out that my model config was not persisting across model creates because I had not correctly updated model-defaults. Now that I have it works just fine (for Juju 2.x).