cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daan Hoogland <daan.hoogl...@shapeblue.com>
Subject Re: [DISCUSS] API versioning
Date Mon, 05 Jun 2017 17:58:05 GMT
The wiki page exists for changes to be introduced at 5.0. It has been there for more than a
year so it needs tlc.
As for the API I sugest to start with a v2Beta api that we then migrate to v2 once we feel
it can be maintained for a while without breaking backwards compatibility. (and move to ACS
5.0 at that point)
Alternatively we can just upgrade quickly (v2, v3, v4, …)

In short +1 for Rene’s idea but with caveats.

On 05/06/2017, 17:57, "Syed Ahmed" <sahmed@cloudops.com> wrote:

    +1 for the API versioning. If you could create a wiki page Rene, we can
    start documenting the changes.
    
    Thanks,
    -Syed
    
    On Mon, Jun 5, 2017 at 10:14 AM, Rafael Weingärtner <
    rafaelweingartner@gmail.com> wrote:
    
    > This might be a good excuse for an ACS 5.0! Maybe with some other additions
    > such as the support for OASIS CAMP or TOSCA?
    >
    > It would be interesting to have a ROADMAP with these desires/wishes.
    >
    > On Mon, Jun 5, 2017 at 8:52 AM, Simon Weller <sweller@ena.com.invalid>
    > wrote:
    >
    > >
    > > +1. Echoing what Rohit pointed out, we have a lot of cleanup to do :-) It
    > > certainly makes it a lot easier though when you're not breaking
    > > compatibility with existing code.
    > >
    > > ________________________________
    > > From: Rohit Yadav <rohit.yadav@shapeblue.com>
    > > Sent: Monday, June 5, 2017 4:04 AM
    > > To: dev@cloudstack.apache.org
    > > Subject: Re: [DISCUSS] API versioning
    > >
    > > +1 Good idea, though bear in mind there are 500+ APIs with no
    > > modern-RESTful-standardization, a lot of work.
    > >
    > >
    > > Regards.
    > >
    > > ________________________________
    > > From: Nitin Kumar Maharana <nitinkumar.maharana@accelerite.com>
    > > Sent: 05 June 2017 12:37:24
    > > To: dev@cloudstack.apache.org
    > > Subject: Re: [DISCUSS] API versioning
    > >
    > > This looks good. +1
    > >
    > > rohit.yadav@shapeblue.com
    > > www.shapeblue.com<http://www.shapeblue.com>
    > > [http://shapeblue.com/wp-content/uploads/2014/03/sungardonline1.jpg]<
    > > http://www.shapeblue.com/>
    > >
    > > Shapeblue - The CloudStack Company<http://www.shapeblue.com/>
    > > www.shapeblue.com
    > > The city of Prague was the venue for the spring meeting of the Cloudstack
    > > European user group. There was
    > >
    > >
    > >
    > > 53 Chandos Place, Covent Garden, London  WC2N 4HSUK
    > > @shapeblue
    > >
    > >
    > >
    > > 
daan.hoogland@shapeblue.com 
www.shapeblue.com
53 Chandos Place, Covent Garden, London  WC2N 4HSUK
@shapeblue
  
 

> On 04-Jun-2017, at 2:34 PM, Rene Moser <mail@renemoser.net> wrote:
    > > >
    > > > Hi
    > > >
    > > > I recently developed ansible modules for the ACL API and ... found this
    > > > has a really inconsistent API naming. E.g.
    > > >
    > > > createNetworkACL <<-- this creates an ACL rule
    > > > createNetworkACLList <<-- this create the ACL
    > > >
    > > > updateNetworkACLItem <<-- this updates an ACL rule
    > > > updateNetworkACLList <<-- this updates the ACL
    > > >
    > > > My first thoughs was, someone has to fix this, like
    > > >
    > > > createNetworkAclRule <<-- this create the ACL rule
    > > > createNetworkAcl <<-- this creates an ACL
    > > >
    > > > updateNetworkAclRule <<-- this updates the ACL rule
    > > > updateNetworkAcl <<-- this updates an ACL
    > > >
    > > > But how without breaking the API for backwards compatibility? I know a
    > > > few other places where the API has inconsistent namings. Fixing the API
    > > > but in a controlled way? What about by adding a version to the API?
    > > >
    > > > I would like to introduce a API versioning to cloudstack: The current
    > > > API would be frozen into verison v1. The new API will have v2. The
    > > > versioned API has the URL scheme:
    > > >
    > > > /client/api/<version>
    > > >
    > > > The current API would be /client/api/v1 and the /client/api would be an
    > > > alias for v1. This ensures backwards compatibility.
    > > >
    > > > This would allow us to deprecate and change APIs.
    > > >
    > > > Any thoughts?
    > > >
    > > >
    > > >
    > >
    > >
    > >
    > >
    > > DISCLAIMER
    > > ==========
    > > This e-mail may contain privileged and confidential information which is
    > > the property of Accelerite, a Persistent Systems business. It is intended
    > > only for the use of the individual or entity to which it is addressed. If
    > > you are not the intended recipient, you are not authorized to read,
    > retain,
    > > copy, print, distribute or use this message. If you have received this
    > > communication in error, please notify the sender and delete all copies of
    > > this message. Accelerite, a Persistent Systems business does not accept
    > any
    > > liability for virus infected mails.
    > >
    >
    >
    >
    > --
    > Rafael Weingärtner
    >
    

Mime
View raw message