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" <sah...@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 <
rafaelweingart...@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 <swel...@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.ya...@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.mahar...@accelerite.com>
> > Sent: 05 June 2017 12:37:24
> > To: dev@cloudstack.apache.org
> > Subject: Re: [DISCUSS] API versioning
> >
> > This looks good. +1
> >
> > rohit.ya...@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.hoogl...@shapeblue.com
www.shapeblue.com
53 Chandos Place, Covent Garden, London WC2N 4HSUK
@shapeblue
> On 04-Jun-2017, at 2:34 PM, Rene Moser <m...@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
>
