[controller-dev] RestConf API Operations


Colin Dixon <colin@...>
 

Yeah. I agree 100%. Right now, the only way I know to do this is to undo the operations that you didn't want to happen.

I know that AAA was looking into better access control to the MD-SAL at a finer grain than all or nothing to the whole data store. That combined with RPCs to allow for certain known access paths is probably the eventually correct answer.

--Colin


On Tue, Jan 20, 2015 at 6:26 AM, Khaldoon Al Zoubi <khaldoon.alzoubi@...> wrote:

Thanks Colin. Yes, you right operational state is read-only. But still some cases where application needs to take some control of accepting an operation before it is being committed.

 

Thanks

Khal

 

From: Colin Dixon [mailto:colin@...]
Sent: Monday, January 19, 2015 11:58 PM
To: Khaldoon Al Zoubi
Cc: controller-dev@...
Subject: Re: [controller-dev] RestConf API Operations

 

The short version is no although many people are asking for this feature. We should come up with some simple way to "vote up" such feature requests.

 

In the meantime, I think it might be the case that operational state is read-only via RESTCONF, but I might be wrong.

 

--Colin

On Monday, January 19, 2015, Khaldoon Al Zoubi <khaldoon.alzoubi@...> wrote:

Hi,

 

When an application listens to data changes notifications,  the application then reacts to what the user is doing via RestConf API. Now, is there a way for an application for instance to disable some operations like PUT or a DELETE in RestConf, or to avoid committing a client update until some checks are performed.

 

Regards,

Khal



Reinaldo Penno <rapenno@...>
 

AAA will not solve this.  The issue is business logic. Applications need to apply specific constraints that is very specific to its business logic.  

The “RPC + AAA” might become the answer if it is the only answer, i.e., nobody fixes the bug.  Having RPCs is major hindrance and bring lots of baggage to any Yang model that could certainly live without them.  Having simple RESTconf URIs is infinitely easier to understand and manage. 



From: Colin Dixon <colin@...>
Date: Tuesday, January 20, 2015 at 11:33 AM
To: Khaldoon Al Zoubi <khaldoon.alzoubi@...>
Cc: "controller-dev@..." <controller-dev@...>, "aaa-dev@..." <aaa-dev@...>
Subject: Re: [controller-dev] RestConf API Operations

Yeah. I agree 100%. Right now, the only way I know to do this is to undo the operations that you didn't want to happen.

I know that AAA was looking into better access control to the MD-SAL at a finer grain than all or nothing to the whole data store. That combined with RPCs to allow for certain known access paths is probably the eventually correct answer.

--Colin


On Tue, Jan 20, 2015 at 6:26 AM, Khaldoon Al Zoubi <khaldoon.alzoubi@...> wrote:

Thanks Colin. Yes, you right operational state is read-only. But still some cases where application needs to take some control of accepting an operation before it is being committed.

 

Thanks

Khal

 

From: Colin Dixon [mailto:colin@...]
Sent: Monday, January 19, 2015 11:58 PM
To: Khaldoon Al Zoubi
Cc: controller-dev@...
Subject: Re: [controller-dev] RestConf API Operations

 

The short version is no although many people are asking for this feature. We should come up with some simple way to "vote up" such feature requests.

 

In the meantime, I think it might be the case that operational state is read-only via RESTCONF, but I might be wrong.

 

--Colin

On Monday, January 19, 2015, Khaldoon Al Zoubi <khaldoon.alzoubi@...> wrote:

Hi,

 

When an application listens to data changes notifications,  the application then reacts to what the user is doing via RestConf API. Now, is there a way for an application for instance to disable some operations like PUT or a DELETE in RestConf, or to avoid committing a client update until some checks are performed.

 

Regards,

Khal


_______________________________________________ controller-dev mailing list controller-dev@... https://lists.opendaylight.org/mailman/listinfo/controller-dev


Colin Dixon <colin@...>
 

So, having a commit handler would really be the ideal solution, but I've hard very little from anyone about implementing this.

Tony, Robert, TomP, any ideas on when/if we could expect a way for applications to take part in the commit handling so that we can implement these features. A *lot* of people are asking.

--Colin


On Tue, Jan 20, 2015 at 11:46 AM, Reinaldo Penno <rapenno@...> wrote:
AAA will not solve this.  The issue is business logic. Applications need to apply specific constraints that is very specific to its business logic.  

The “RPC + AAA” might become the answer if it is the only answer, i.e., nobody fixes the bug.  Having RPCs is major hindrance and bring lots of baggage to any Yang model that could certainly live without them.  Having simple RESTconf URIs is infinitely easier to understand and manage. 



From: Colin Dixon <colin@...>
Date: Tuesday, January 20, 2015 at 11:33 AM
To: Khaldoon Al Zoubi <khaldoon.alzoubi@...>
Cc: "controller-dev@..." <controller-dev@...>, "aaa-dev@..." <aaa-dev@...>
Subject: Re: [controller-dev] RestConf API Operations

Yeah. I agree 100%. Right now, the only way I know to do this is to undo the operations that you didn't want to happen.

I know that AAA was looking into better access control to the MD-SAL at a finer grain than all or nothing to the whole data store. That combined with RPCs to allow for certain known access paths is probably the eventually correct answer.

--Colin


On Tue, Jan 20, 2015 at 6:26 AM, Khaldoon Al Zoubi <khaldoon.alzoubi@...> wrote:

Thanks Colin. Yes, you right operational state is read-only. But still some cases where application needs to take some control of accepting an operation before it is being committed.

 

Thanks

Khal

 

From: Colin Dixon [mailto:colin@...]
Sent: Monday, January 19, 2015 11:58 PM
To: Khaldoon Al Zoubi
Cc: controller-dev@...
Subject: Re: [controller-dev] RestConf API Operations

 

The short version is no although many people are asking for this feature. We should come up with some simple way to "vote up" such feature requests.

 

In the meantime, I think it might be the case that operational state is read-only via RESTCONF, but I might be wrong.

 

--Colin

On Monday, January 19, 2015, Khaldoon Al Zoubi <khaldoon.alzoubi@...> wrote:

Hi,

 

When an application listens to data changes notifications,  the application then reacts to what the user is doing via RestConf API. Now, is there a way for an application for instance to disable some operations like PUT or a DELETE in RestConf, or to avoid committing a client update until some checks are performed.

 

Regards,

Khal


_______________________________________________ controller-dev mailing list controller-dev@... https://lists.opendaylight.org/mailman/listinfo/controller-dev


Robert Varga
 

https://bugs.opendaylight.org/show_bug.cgi?id=1435

It is targeted for Lithium. While it will be immediately useful for applications, we also need a configurable generic AAA component, as hand-coding these handlers for each application will be prone to errors. One very specific concern is that the commit cohorts must refrain from leaking state outside the datastore domain -- we have seen this in the Hydrogen release, where applications hooking onto this mechanism (which is very similar to DCL) brought the system down simply because they violated API contracts.

Bye,
Robert

On 01/20/2015 08:51 PM, Colin Dixon wrote:

So, having a commit handler would really be the ideal solution, but I've hard very little from anyone about implementing this.

Tony, Robert, TomP, any ideas on when/if we could expect a way for applications to take part in the commit handling so that we can implement these features. A *lot* of people are asking.

--Colin


On Tue, Jan 20, 2015 at 11:46 AM, Reinaldo Penno <rapenno@...> wrote:
AAA will not solve this.  The issue is business logic. Applications need to apply specific constraints that is very specific to its business logic.  

The “RPC + AAA” might become the answer if it is the only answer, i.e., nobody fixes the bug.  Having RPCs is major hindrance and bring lots of baggage to any Yang model that could certainly live without them.  Having simple RESTconf URIs is infinitely easier to understand and manage. 



From: Colin Dixon <colin@...>
Date: Tuesday, January 20, 2015 at 11:33 AM
To: Khaldoon Al Zoubi <khaldoon.alzoubi@...>
Cc: "controller-dev@..." <controller-dev@...>, "aaa-dev@..." <aaa-dev@...>
Subject: Re: [controller-dev] RestConf API Operations

Yeah. I agree 100%. Right now, the only way I know to do this is to undo the operations that you didn't want to happen.

I know that AAA was looking into better access control to the MD-SAL at a finer grain than all or nothing to the whole data store. That combined with RPCs to allow for certain known access paths is probably the eventually correct answer.

--Colin


On Tue, Jan 20, 2015 at 6:26 AM, Khaldoon Al Zoubi <khaldoon.alzoubi@...> wrote:

Thanks Colin. Yes, you right operational state is read-only. But still some cases where application needs to take some control of accepting an operation before it is being committed.

 

Thanks

Khal

 

From: Colin Dixon [mailto:colin@...]
Sent: Monday, January 19, 2015 11:58 PM
To: Khaldoon Al Zoubi
Cc: controller-dev@...
Subject: Re: [controller-dev] RestConf API Operations

 

The short version is no although many people are asking for this feature. We should come up with some simple way to "vote up" such feature requests.

 

In the meantime, I think it might be the case that operational state is read-only via RESTCONF, but I might be wrong.

 

--Colin

On Monday, January 19, 2015, Khaldoon Al Zoubi <khaldoon.alzoubi@...> wrote:

Hi,

 

When an application listens to data changes notifications,  the application then reacts to what the user is doing via RestConf API. Now, is there a way for an application for instance to disable some operations like PUT or a DELETE in RestConf, or to avoid committing a client update until some checks are performed.

 

Regards,

Khal


_______________________________________________ controller-dev mailing list controller-dev@... https://lists.opendaylight.org/mailman/listinfo/controller-dev



_______________________________________________
controller-dev mailing list
controller-dev@...
https://lists.opendaylight.org/mailman/listinfo/controller-dev