Open Stack

Hello,

It seems to me that this call just mimics the behavior of nova-manage
utility which allows to create multiple networks for single project/tenant
with single CLI command.

--
Best regards,
Oleg

On Wed, Aug 15, 2012 at 12:22 PM, Mark McLoughlin <markmc at redhat.com> wrote:

> On Thu, 2012-07-19 at 14:20 +0100, Mark McLoughlin wrote:
> > Hi,
> >
> > I was just reviewing the code for this:
> >
> >   https://blueprints.launchpad.net/nova/+spec/os-api-network-create
> >
> > You POST to /networks:
> >
> >   {"network": {"vlan_start": 234, "cidr": "10.70.105.0/24", "label":
> "net234"}}
> >
> > and get back e.g.
> >
> >   {"networks": [{..., "id": 66085e78-8f6-4a26-b16c-4b1f55901fbd", ...,
> "label": "net234", ..., "vlan": 234, ..., "cidr": "10.70.105.0/24", ...}]}
> >
> > Notice the plural "networks" in the response. A single POST may create
> > multiple networks (where e.g. FLAGS.num_networks > 1), but it's not
> > clear to me what the use case for this is.
> >
> > The issue with this is that (at least IMHO) POST requests should only
> > create a single resource - e.g. we want to be able to return a 201
> > Created response with a Location header and it would seem bizarre to
> > include multiple location headers.
>
> For anyone interested, this debate is still rumbling on here:
>
>   https://review.openstack.org/#/c/9847/
>
> I've tried to be pretty clear about my objection to the proposed
> modelling:
>
>   REST stands for Representational State Transfer
>
>   When you POST to /networks, you are sending a representation of the
>   network resource you want to create
>
>   The sensible thing for a client to expect is that a network resource
>   will be created and for a 201 Created response to include a
>   representation the resource and a Location header with a URI for the
>   resource
>
>   What doesn't seem at all sensible is for the server to return a
>   collection of resources, based on "num_networks" and "network_size"
>   properties in the network representation and also based on the server
>   configuration
>
> Other opinions are most welcome, though.
>
> Cheers,
> Mark.
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20120815/fffe6ae3/attachment-0001.html>