Open Stack

It seems to me that there are two aspects being discussed in this thread:
style and practicality.

>From a style perspective, it is important to give a "uniform" experience to
Neutron API users.
Obviously this does not mean the Load Balancing API must adhere to some
strict criteria.
For instance, 2nd level resources might be ok even if they're usually
avoided in Neutron, provided that their lifecycle is completely contained
within that of the first level resource.
On the other hand things like calling identifiers 'uuid' rather than 'id',
or inserting the tenant id in the URI would be rather awkward and result in
usability issues. But I think nobody is proposing anything like that.

>From a practicality perspective I think the discussion is around whether
this "single call" approach should be supported or not.
The problem, as pointed out somewhere in this thread is probably more about
how to handle "container" and "contained" resources.
One of Neutron's API tenets is to be as atomic as possible, ie: each API
operation should operate only on the resource it refers to.
This is why, to the best of my knowledge there is no API operation in
Neutron which operates on different resource types (*).

Now keep in mind this is a tenet, not a dogma - so everything can be
changed, provided there is a compelling reason for the change.
In my opinion, allowing REST APIs to manipulate container and contained
objects in the same call makes sense when the lifecycle of the contained
object depends on the lifecycle of the container. With reference to the
current API, this may be true for network and ports (a port can hardly
exist without a network!), but it would be hardly true for VIPs and pools,
as a pool can exist independently of a VIP (**).
Another thing to consider are bulk operations. For instance, even if the
security group API requires another call for creating security group rules,
all the rules can be created in bulk with a single operation which
guarantees atomicity and isolation.

Salvatore

(*) This statement is wilfully incorrect. There are actually operations
that operate on several types. For instance POST /FloatingIPs creates a
Floating and a Port. In cases like this however the 'accessory' resource
created is hidden to the tenant and is therefore not part of the resource
it manages.
(**) This statement is based on the current resource model exposed from the
API. Whether that model is right or not it's outside the scope of my post.






On 1 May 2014 14:27, Eugene Nikanorov <enikanorov at mirantis.com> wrote:

> Hi,
>
> My opinion is that keeping neutron API style is very important but it
> doesn't prevent single call API from being implemented.
> Flat fine-grained API is obviously the most flexible, but that doesn't
> mean we can't support single call API as well.
>
> By the way, looking at the implementation I see that such API (single
> call) should be also supported in the drivers, so it is not just something
> 'on top' of fine-grained API. Such requirement comes from the fact that
> fine-grained API is asynchronous.
>
> Thanks,
> Eugene.
>
>
> On Thu, May 1, 2014 at 5:18 AM, Kyle Mestery <mestery at noironetworks.com>wrote:
>
>> I am fully onboard with the single-call approach as well, per this thread.
>>
>> On Wed, Apr 30, 2014 at 6:54 PM, Stephen Balukoff <sbalukoff at bluebox.net>
>> wrote:
>> > It's also worth stating that coding a web UI to deploy a new service is
>> > often easier done when single-call is an option. (ie. only one failure
>> > scenario to deal with.) I don't see a strong reason we shouldn't allow
>> both
>> > single-call creation of whole bunch of related objects, as well as a
>> > workflow involving the creation of these objects individually.
>> >
>> >
>> > On Wed, Apr 30, 2014 at 3:50 PM, Jorge Miramontes
>> > <jorge.miramontes at rackspace.com> wrote:
>> >>
>> >> I agree it may be odd, but is that a strong argument? To me, following
>> >> RESTful style/constructs is the main thing to consider. If people can
>> >> specify everything in the parent resource then let them (i.e. single
>> call).
>> >> If they want to specify at a more granular level then let them do that
>> too
>> >> (i.e. multiple calls). At the end of the day the API user can choose
>> the
>> >> style they want.
>> >>
>> >> Cheers,
>> >> --Jorge
>> >>
>> >> From: Youcef Laribi <Youcef.Laribi at citrix.com>
>> >> Reply-To: "OpenStack Development Mailing List (not for usage
>> questions)"
>> >> <openstack-dev at lists.openstack.org>
>> >> Date: Wednesday, April 30, 2014 1:35 PM
>> >> To: "OpenStack Development Mailing List (not for usage questions)"
>> >> <openstack-dev at lists.openstack.org>
>> >> Subject: Re: [openstack-dev] [Neutron][LBaaS]Conforming to Open Stack
>> API
>> >> style in LBaaS
>> >>
>> >> Sam,
>> >>
>> >>
>> >>
>> >> I think it’s important to keep the Neutron API style consistent. It
>> would
>> >> be odd if LBaaS uses a different style than the rest of the Neutron
>> APIs.
>> >>
>> >>
>> >>
>> >> Youcef
>> >>
>> >>
>> >>
>> >> From: Samuel Bercovici [mailto:SamuelB at Radware.com]
>> >> Sent: Wednesday, April 30, 2014 10:59 AM
>> >> To: openstack-dev at lists.openstack.org
>> >> Subject: [openstack-dev] [Neutron][LBaaS]Conforming to Open Stack API
>> >> style in LBaaS
>> >>
>> >>
>> >>
>> >> Hi Everyone,
>> >>
>> >>
>> >>
>> >> During the last few days I have looked into the different LBaaS API
>> >> proposals.
>> >>
>> >> I have also looked on the API style used in Neutron. I wanted to see
>> how
>> >> Neutron APIs addressed “tree” like object models.
>> >>
>> >> Follows my observation:
>> >>
>> >> 1.       Security groups -
>> >>
>> http://docs.openstack.org/api/openstack-network/2.0/content/security-groups-ext.html
>> )
>> >> –
>> >>
>> >> a.       security-group-rules are children of security-groups, the
>> >> capability to create a security group with its children in a single
>> call is
>> >> not possible.
>> >>
>> >> b.       The capability to create security-group-rules using the
>> following
>> >> URI path v2.0/security-groups/{SG-ID}/security-group-rules is not
>> supported
>> >>
>> >> c.        The capability to update security-group-rules using the
>> >> following URI path
>> >> v2.0/security-groups/{SG-ID}/security-group-rules/{SGR-ID} is not
>> supported
>> >>
>> >> d.       The notion of creating security-group-rules (child object)
>> >> without providing the parent {SG-ID} is not supported
>> >>
>> >> 2.       Firewall as a service -
>> >>
>> http://docs.openstack.org/api/openstack-network/2.0/content/fwaas_ext.html-
>> >> the API to manage firewall_policy and firewall_rule which have parent
>> child
>> >> relationships behaves the same way as Security groups
>> >>
>> >> 3.       Group Policy – this is work in progress -
>> >> https://wiki.openstack.org/wiki/Neutron/GroupPolicy - If I understand
>> >> correctly, this API has a complex object model while the API adheres
>> to the
>> >> way other neutron APIs are done (ex: flat model, granular api, etc.)
>> >>
>> >>
>> >>
>> >> How critical is it to preserve a consistent API style for LBaaS?
>> >>
>> >> Should this be a consideration when evaluating API proposals?
>> >>
>> >>
>> >>
>> >> Regards,
>> >>
>> >>             -Sam.
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >> _______________________________________________
>> >> OpenStack-dev mailing list
>> >> OpenStack-dev at lists.openstack.org
>> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >>
>> >
>> >
>> >
>> > --
>> > Stephen Balukoff
>> > Blue Box Group, LLC
>> > (800)613-4305 x807
>> >
>> > _______________________________________________
>> > OpenStack-dev mailing list
>> > OpenStack-dev at lists.openstack.org
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> _______________________________________________
> 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/20140502/9f71cba6/attachment.html>