Open Stack

Hello,

As you know, much discussion has been around the naming and the url pathing for the ip-usages extension.  We also discussed this at the neutron mid-cycle as well.  Since we are the ones the made the extension, we use the extension to help with scheduling in our layer 3 network design.    We have no preference as to the url's but the only thing that we want to maintain is the ability to query for all subnets at once.  We have a nova scheduling filter that makes a call into the  ip-usages extension.  Otherwise every time we provision a vm we would have to make N number of calls to get all the subnets and their usages.
____________________________________________

Kris Lindgren
Senior Linux Systems Engineer
GoDaddy, LLC.

From: Salvatore Orlando <salv.orlando at gmail.com<mailto:salv.orlando at gmail.com>>
Date: Tuesday, August 25, 2015 at 4:33 PM
To: Assaf Muller <amuller at redhat.com<mailto:amuller at redhat.com>>
Cc: "openstack-operators at lists.openstack.org<mailto:openstack-operators at lists.openstack.org>" <openstack-operators at lists.openstack.org<mailto:openstack-operators at lists.openstack.org>>
Subject: Re: [Openstack-operators] IP - availability monitoring

As the specification linked by Assaf has without doubt value for operators, I think the drivers team might consider it for inclusion in the Liberty release.
Unfortunately the specification and the patch have not received many reviews, but can still be sorted, especially considering that the patch's size is manageable and its impact contained.

Nevertheless, Daniel in his post referred to providing information about usage of IPs in resources like subnets, whereas the patch under review proposes the addition of a new read-only resource called 'network_ip_usage'. The only thing I'd change is that I'd make this information available in a different way.
For instance:

- through a sub-url of subnets: GET /v2.0/subnets/<id>/ip_usage
- through a query paramer on subnet GET /v2.0/subnets/<id>?ip_usage=True
- making IPs a read only resource GET /v2.0/ips?subnet_id=<id>&count=True

I think from a user perspective the latter would be the more elegant and simple to use, but it will require additional work for introducing resource counting in Neutron APIs; and for this there's an old spec too [1]. Having operators providing feedback on how they reckon this is information is best consumed would be valuable.

[1] https://review.openstack.org/#/c/102199/

Salvatore






On 24 August 2015 at 03:21, Assaf Muller <amuller at redhat.com<mailto:amuller at redhat.com>> wrote:


On Sun, Aug 23, 2015 at 8:23 PM, Daniel Speichert <daniel at speichert.pl<mailto:daniel at speichert.pl>> wrote:
On 8/22/2015 23:24, Balaji Narayanan (பாலாஜி நாராயணன்) wrote:
> Hello Operators,
>
> In the capacity management discussions at the Ops Summit last week, I
> thought there was a some discussion on monitoring of fixed / floating
> subnets and availability.
>
> At Yahoo, we use nova-network and have an API extension available for
> reporting how much ip subnets are configured on a cluster and how much
> of them are used / remaining. We use this to trigger an alert /
> augment additional subnets to the cluster.
>
> If there is enough interest in this, we can look at pushing this upstrem.
>
> Here is a blue print that vilobh wrote initially for this -
> https://review.openstack.org/#/c/94299/
This sounds like a very useful extension, considering there's really no
quotas for IP addresses and IPs are a scarce resource.
I'm aware of multiple big private cloud operators using custom scripts
to generate reports of available IP addresses.

I'm pretty sure an extension like this would be great for neutron (I'm
not using nova-network). Considering that most networking scenarios
(flat, provider networks, floating IPs with L3) have subnets as a
resource in neutron, with allocation pools, it seems enough to create an
extension that would provide statistics for a subnet or summary
statistics for all subnets within a network if so requested.

I can work on a new blueprint version for neutron.

There already is one.

Code:
https://review.openstack.org/#/c/212955/

RFE bug:
https://bugs.launchpad.net/neutron/+bug/1457986

Blueprint:
https://blueprints.launchpad.net/neutron/+spec/network-ip-usage-api

Spec:
https://review.openstack.org/#/c/180803/5/specs/liberty/network-ip-usage-api.rst


Regards,
Daniel Speichert



_______________________________________________
OpenStack-operators mailing list
OpenStack-operators at lists.openstack.org<mailto:OpenStack-operators at lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators


_______________________________________________
OpenStack-operators mailing list
OpenStack-operators at lists.openstack.org<mailto:OpenStack-operators at lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150826/9976ba9b/attachment.html>