Weekly update on GSoC project - Adding new noVNC console

2017-06-05 Thread sachin patil 
Hello All,

 I have started integrating the noVNC console to cloudstack. As my
mentor Syed suggested, it will be available along side the existing console
and can be accessed by passing a new parameter ( webscoket = true ) to the
existing console access url.

I have created a new context "/novnc" to handle the noVNC request and a
noVNC handler for the same.

I am  unable to push my local commits to my fork due to slow internet but
will try to push them soon.


Regards,
Sachin Patil

Re: [DISCUSS] API versioning

2017-06-05 Thread Ron Wheeler 

Are you thinking of using OpenAPI(Swagger) to do the documentation?

Ron

On 05/06/2017 10:14 AM, Rafael Weingärtner 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 
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 
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 
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://shapeblue.com/wp-content/uploads/2014/03/sungardonline1.jpg]<
http://www.shapeblue.com/>

Shapeblue - The CloudStack Company
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




On 04-Jun-2017, at 2:34 PM, Rene Moser  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/

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.






--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

Re: [DISCUSS] API versioning

2017-06-05 Thread Ron Wheeler 

Please do not make any more roadmaps!
There are more than enough already and many include old promises about 
updates that will be done on the page.


https://cwiki.apache.org/confluence/display/CLOUDSTACK/Roadmap
https://cwiki.apache.org/confluence/display/CLOUDSTACK/2015+Plan
https://cwiki.apache.org/confluence/display/CLOUDSTACK/Releases
https://cwiki.apache.org/confluence/display/CLOUDSTACK/%5BPROPOSAL%5D+2016-2017+Release+Cycle+and+Calendar
https://cwiki.apache.org/confluence/display/CLOUDSTACK/Releases+in+Progress
There may be more. I only spent 2 minutes to find these.

Can we get rid of all of these that are not going to be kept up to date?
I know that one can not permanently delete any wiki page but at least 
get them off the menu and not visible to people wanting to gauge the 
state of the project.



Would it be helpful to have a vote about which one to keep and bring up 
to date?


Ron



On 05/06/2017 10:14 AM, Rafael Weingärtner 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 
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 
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 
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://shapeblue.com/wp-content/uploads/2014/03/sungardonline1.jpg]<
http://www.shapeblue.com/>

Shapeblue - The CloudStack Company
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




On 04-Jun-2017, at 2:34 PM, Rene Moser  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/

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.






--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

Re: [DISCUSS] API versioning

2017-06-05 Thread Daan Hoogland 
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"  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 
> 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 
> > 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 
> > 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://shapeblue.com/wp-content/uploads/2014/03/sungardonline1.jpg]<
> > http://www.shapeblue.com/>
> >
> > Shapeblue - The CloudStack Company
> > 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  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/
> > >
> > > 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
>

Re: [DISCUSS] API versioning

2017-06-05 Thread Syed Ahmed 
+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 
> 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 
> > 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 
> > 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://shapeblue.com/wp-content/uploads/2014/03/sungardonline1.jpg]<
> > http://www.shapeblue.com/>
> >
> > Shapeblue - The CloudStack Company
> > 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
> >
> >
> >
> > > On 04-Jun-2017, at 2:34 PM, Rene Moser  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/
> > >
> > > 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
>

Re: [DISCUSS] API versioning

2017-06-05 Thread Rafael Weingärtner 
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 
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 
> 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 
> 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://shapeblue.com/wp-content/uploads/2014/03/sungardonline1.jpg]<
> http://www.shapeblue.com/>
>
> Shapeblue - The CloudStack Company
> 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
>
>
>
> > On 04-Jun-2017, at 2:34 PM, Rene Moser  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/
> >
> > 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

Re: [DISCUSS] API versioning

2017-06-05 Thread Simon Weller 

+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 
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 
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://shapeblue.com/wp-content/uploads/2014/03/sungardonline1.jpg]

Shapeblue - The CloudStack Company
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



> On 04-Jun-2017, at 2:34 PM, Rene Moser  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/
>
> 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.

Re: [DISCUSS] API versioning

2017-06-05 Thread Rohit Yadav 
+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 
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
53 Chandos Place, Covent Garden, London  WC2N 4HSUK
@shapeblue
  
 

> On 04-Jun-2017, at 2:34 PM, Rene Moser  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/
>
> 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.

Re: [DISCUSS] API versioning

2017-06-05 Thread Nitin Kumar Maharana 
This looks good. +1
> On 04-Jun-2017, at 2:34 PM, Rene Moser  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/
>
> 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.

Re: [DISCUSS] API versioning

2017-06-05 Thread Boris Stoyanov 
+1 


boris.stoya...@shapeblue.com 
www.shapeblue.com
53 Chandos Place, Covent Garden, London  WC2N 4HSUK
@shapeblue
  
 

> On Jun 4, 2017, at 7:15 PM, Tutkowski, Mike  wrote:
> 
> This sounds like a good idea to me.
> 
>> On Jun 4, 2017, at 8:24 AM, Will Stevens  wrote:
>> 
>> +1. I like it.
>> 
>>> On Jun 4, 2017 5:04 AM, "Rene Moser"  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/
>>> 
>>> 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?
>>> 
>>> 
>>> 
>>>