So the people that do not want AAA have the burden to know how to disable it ? How about the people that want AAA learn how to enable it? Are we doing that for every feature? 

From: "Nguyen, Liem Manh" <liem_m_nguyen@...>
Date: Thursday, October 9, 2014 at 5:23 PM
To: Devin Avery <davery@...>, Reinaldo Penno <rapenno@...>, Colin Dixon <colin@...>
Cc: "tsc@..." <tsc@...>, Keith Burns <alagalah@...>, "controller-dev@..." <controller-dev@...>
Subject: Re: [controller-dev] circular dependency with controller and aaa

I know HP has some use-cases that require securing the north-bound API (e.g., RestConf), beyond HTTP basic auth.  That said, we also recognize that AAA may not be required nor needed in all environments, so AAA can also be easily disabled as described in the Dev Guide.

Regards,

Liem

From: Devin Avery <davery@...>
Date: Thursday, October 9, 2014 at 8:39 AM
To: Reinaldo Penno <rapenno@...>, Colin Dixon <colin@...>
Cc: "tsc@..." <tsc@...>, Keith Burns <alagalah@...>, "controller-dev@..." <controller-dev@...>
Subject: Re: [controller-dev] circular dependency with controller and aaa

Great question/point Reinaldo - 

I assumed the community was consulted before the changed was merged. I know I was asked and commented on the gerrit with my support – not sure how wide that ask went though – so there is likely a take-away-here and something we can learn from that. Even if the community wasn’t consulted properly before we need to start somewhere – and now is as good a time as any. And perhaps we should step back and not ask if we should “get rid of this since it is in there” but instead ask – "what does our target market, service providers etc, want here?” and then use that as our guidance. I think this is where the TSC needs to step in and provide some guidance. My understanding of the TSC is that they have a feel for our target users and thus can provide some insight in this case of disagreement. 

As for the 80%: it comes from the 80/20 rule. I made the assumption that our target audience would want it, and without hard data, I used the 80/20 rule to define a percentage. So you are right to question that number :) Regardless of the actual number, my claim in general is that most organizations are going to want SOME user security on the application that is controlling their network, even if the apps are completely isolated. Especially when accounting is added. That said, I think bringing this discussion to the TSC is the proper course of action to make sure we we get cross organization representation (my 2 cents) - no time to start changing our ways then like the present. :)

Devin

From: Reinaldo Penno <rapenno@...>
Date: Thursday, October 9, 2014 at 11:11 AM
To: Colin Dixon <colin@...>, Devin Avery <davery@...>
Cc: "tsc@..." <tsc@...>, Keith Burns <alagalah@...>, "controller-dev@..." <controller-dev@...>
Subject: Re: [controller-dev] circular dependency with controller and aaa

Hi,

Reading this discussion I can not help but ask: 

Why the community matters now and not before?  The question is why feature this was merged, changed RESTconf client behavior (certainly broke my regression) and the “entire community” was not consulted before?  Was there any announcement email saying “project committers. Please vote +1/-1 is you agree that AAA should be merged to controller and the default RESTconf client behavior should be changed across the board?”.  

You said

"That is, AAA was brought into restconf in the controller because 80% of the population is going to want it"

Please back that number with some real data. If RESTconf clients are already in a physically secure (or otherwise authenticated) network this will never be used.  Point in case are enterprises and ISP networks.  

As far as build issues when decoupling AAA from controller, those a generic Opendaylight problems because our build and release system is extremely problematic and projects are joined on the hip through snapshot releases.  

Thanks,

From: Colin Dixon <colin@...>
Date: Thursday, October 9, 2014 at 7:12 AM
To: Devin Avery <davery@...>
Cc: "tsc@..." <tsc@...>, Keith Burns <alagalah@...>, "controller-dev@..." <controller-dev@...>
Subject: Re: [controller-dev] circular dependency with controller and aaa

On Thu, Oct 9, 2014 at 8:49 AM, Devin Avery <davery@...> wrote:

I agree that this will solve the immediate problem of circular dependencies on AAA, but I think it breaks the main purpose that AAA was merged into the controller. So before we make this change I want to make sure everyone is onboard with the change in functionality.

That is, AAA was brought into restconf in the controller because 80% of the population is going to want it.

If it is in the controller people can just inherit the controller (which is generally “core”) and get AAA for free. If we move the feature out of the controller and into integration then that means that 80% of the population will need to either 1) import integration, and thus pull down every other project (since integration depends on everything) in order to get the restconf_with_AAA feature, OR 2) redefine the restconf_with_AAA feature on their own which means that need to monitor that feature definition and hope that they catch any changes made to it.

In either case we are explicitly reversing the functionality that was intentionally added so I want to make sure that is the direction we want to take and that we understand the burdens this may be placing on downstream consumers of ODL.

=== Question – how should we go about considering a decision like this that affects the entire community, downstream consumers etc and reverses functionality that was intentionally added into the product? Discuss on the TSC?

======== Two other possible solutions ===

1) (Credit to Colin Dixon for thinking this one up)

The other option would be to have controller define the restconf-without-aaa feature and the netconf-connector-without-aaa feature and have AAA define the restconf-with-aaa and netconf-connector-with-aaa feature. We just need to make sure the arrows only flow one direction. [Devin – and since AAA already depends on controller, we should be OK…]

2) 

The only other possibility that I just thought of this morning is that we define a feature in a new bundle in the controller, but we do NOT test that feature, or depend on AAA. That is the feature definition can exist with the dependency on AAA in the feature, but NOT in the pom.xml. This breaks the best practice of always having our features tested, but if we document it well that this is a very specific exception and ONLY put the restconfwithaaa feature in this special feature bundle, then we could break the build dependency and clearly document how someone who wants to use that feature needs to add their own dependency on the AAA project… we could even have a distro in the controller which DOES have the dependency, but is disabled unless you build with a special profile. Merge jobs could run that profile if we want to validate the feature still works, but unless you want the controller only distro with AAA it wouldn’t have to be built by default. 

======= TSC – if there is time can we discuss this on today’s call so we can pick a direction while answering the removal functionality question ? ===

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