[Openstack-operators] IP - availability monitoring

Salvatore Orlando salv.orlando at gmail.com
Thu Aug 27 09:32:09 UTC 2015

I am not going to be too picky either and play the role of the defender of
the REST principles.

While we can surely think about a solution that fits nicely in current APis
and also gives you the ability of querying all the subnets at once, I also
realise there as a practical matter thinking about an ideal solution likely
implies delays.
I regard this as useful feature for operators, and I am therefore not
opposed to implementing extension as it is. At the end of the day it only
provides information, it does not alter the state of any neutron resource.

At some point in the future we can then converge on an API to determine
resource usage that will also include the functionality exposed by your API.


On 26 August 2015 at 16:09, Kris G. Lindgren <klindgren at godaddy.com> wrote:

> 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>
> Date: Tuesday, August 25, 2015 at 4:33 PM
> To: Assaf Muller <amuller at redhat.com>
> Cc: "openstack-operators at lists.openstack.org" <
> 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> wrote:
>> On Sun, Aug 23, 2015 at 8:23 PM, Daniel Speichert <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
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>> _______________________________________________
>> OpenStack-operators mailing list
>> 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/20150827/e42e1e0a/attachment.html>

More information about the OpenStack-operators mailing list