Open Stack

Sorry, pulling this from the archives [1] because I seem to have lost the
original in my mailbox...

> 1) (this is more for neutron people) Is there a real use case for
> requesting specific gateway IPs and allocation pools when allocating from
a
> pool? If not, maybe we should let the pool set a default gateway IP and
> allocation pools. The user can then update them with another call.
Another
> option would be to provide "subnet templates" from which a user can
choose.
> For instance one template could have the gateway as first IP, and then a
> single pool for the rest of the CIDR.

The use case that always comes to mind when questions like this are asked
is "green-field" vs
"brown-field" - if I am deploying something new, then no, I don't need the
ability to specify gateway IPs.  However, if I am dealing with an existing
deployment migration,
then I will want to be able to represent what is already out there.

> 2) Is the action of creating a subnet from a pool better realized as a
> different way of creating a subnet, or should there be some sort of "pool
> action"? Eg.:
>
> POST /subnet_pools/my_pool_id/subnet
> {'prefix_len': 24}
>
> which would return a subnet response like this (note prefix_len might not
> be needed in this case)
>
> {'id': 'meh',
>  'cidr': '192.168.0.0/24',
>  'gateway_ip': '192.168.0.1',
>  'pool_id': 'my_pool_id'}
>
> I am generally not a big fan of RESTful actions. But in this case the
> semantics of the API operation are that of a subnet creation from within
a
> pool, so that might be ok.

This would be my preferred approach of the two given.

Ryan Moats

[1]
http://lists.openstack.org/pipermail/openstack-dev/2015-March/058538.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150309/46259a07/attachment.html>