Open Stack

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140501/ea9d1faa/attachment.html>