Hi

I don’t know if someone already filed a bug for this or not, when I tried to do a maven build from head, I got the following error.

It looks like something related to karaf.

[INFO] Reactor Summary:

[INFO]

[INFO] commons.aaa ....................................... SUCCESS [6.320s]

[INFO] aaa.project ....................................... SUCCESS [0.236s]

[INFO] aaa-authn-api ..................................... SUCCESS [6.825s]

[INFO] aaa-authn ......................................... SUCCESS [4.338s]

[INFO] aaa-authn-sts ..................................... SUCCESS [11.565s]

[INFO] aaa-authn-store ................................... SUCCESS [7.415s]

[INFO] aaa-authn-sssd .................................... SUCCESS [0.793s]

[INFO] aaa-authn-keystone ................................ SUCCESS [1.109s]

[INFO] aaa-idmlight ...................................... SUCCESS [0.946s]

[INFO] aaa-authz ......................................... SUCCESS [0.101s]

[INFO] aaa-authz-model ................................... SUCCESS [14.978s]

[INFO] features-aaa ...................................... FAILURE [2.203s]

[INFO] ------------------------------------------------------------------------

[INFO] BUILD FAILURE

[INFO] ------------------------------------------------------------------------

[INFO] Total time: 1:02.122s

[INFO] Finished at: Sat Aug 09 22:37:47 PDT 2014

[INFO] Final Memory: 52M/124M

[INFO] ------------------------------------------------------------------------

[ERROR] Failed to execute goal org.apache.karaf.tooling:karaf-maven-plugin:3.0.1:features-create-kar (features-create-kar) on project features-aaa: Failed to create archive: Could not find artifact org.opendaylight.aaa:features-aaa:cfg:clients:0.1.0-SNAPSHOT in opendaylight-release (http://nexus.opendaylight.org/content/repositories/opendaylight.release/)

[ERROR]

[ERROR] Try downloading the file manually from the project website.

[ERROR]

[ERROR] Then, install it using the command:

[ERROR] mvn install:install-file -DgroupId=org.opendaylight.aaa -DartifactId=features-aaa -Dversion=0.1.0-SNAPSHOT -Dclassifier=clients -Dpackaging=cfg -Dfile=/path/to/file

[ERROR]

[ERROR] Alternatively, if you host your own repository you can deploy the file there:

[ERROR] mvn deploy:deploy-file -DgroupId=org.opendaylight.aaa -DartifactId=features-aaa -Dversion=0.1.0-SNAPSHOT -Dclassifier=clients -Dpackaging=cfg -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id]

[ERROR]

[ERROR]

[ERROR] org.opendaylight.aaa:features-aaa:cfg:0.1.0-SNAPSHOT

[ERROR]

Hi Luis,

I have worked with some other members of the community to map a proposal that would define the relationships in ODL among AAA, tenants, virtual networks, and group based policy. It has generally been well received when socialized, but we’ve not yet figured out how to translate this concept into cooperation and code within all the projects that would need to participate.

Clearly not happening for Helium and possibly a great thing to work on when broad community membership is face-to-face at September developer event.

In todays GBP requirements call we will discuss plans to align GBP and AAA with this proposed approach.

Below are links to some documents from the discussion to date. They may help you understand the direction we’re proposing, however they may require some narration by the authors. We’ve presented some of this on TWS previously and could do an update to TWS if that is of interest.

https://wiki.opendaylight.org/images/e/e3/OS-ODL_Mapping.pdf

https://wiki.opendaylight.org/images/a/a0/TWS-ODL-tenancy-preso-2014-06-02.pdf

It’s not yet  clear to me  how we staff the developers to implement long term architectural vision across projects in ODL. Folks with interest/availability to participate should raise their hands as we begin to think about long term improvements outside of the helium timeline.

Since the first ODL Hackfest, we’ve been trying to figure out how to get on the same page about terminology and how we can use it to talk about what we’re building.

This spring, Colin Dixon, Liem Nguyen, and I took an action to propose a way to map AAA tools to some well defined entities and in the process to resolve ongoing confusion around what we mean by tenants, users, and virtual networks, in particular.

We presented this and got some good feedback from the TWS call on June 2.

What we proposed was a model with an entity called a domain (chosen by poll) that works as follows:

The “root” domain is created when the GBP system starts and it inherits access to  all of the physical and virtual network resources discovered by the startup process.

The root domain can include various users and roles with AAA support. Within the root domain an admin can be created and can then subsequently define which resources and actions the various root domain users are allowed to access.

The root domain can create one or more children, and for each can specify what resources and actions are available in the childrens “view” of the overall resource and policy world.

The parent child relationship can be extended recursively to an arbitrary depth.

Each child  domain also has a set of users and roles supported by AAA that are local to that domain. These define what various users are allowed to do withing the resource/policy view they inherit.

Email included below describes the vision of how this would work in general.

The OpenStack project, which will often sit atop ODL (and GBP) does not support arbitrarily deep recursion of “tenant like” entities. It is basically a one-deep hierarchy. Enclosed slides show how multiple instances of OpenStack provider/tenants could map onto a single instance of the recursive ODL network infrastructure model.

Within Group Based Policy it would be fantastic if we could figure out how to make GBP the policy language for describing the concentric circles of  ever-more restrictive “parental controls” as one marches down the ODL domain stack.  

Suggest we discuss this in a GBP arch meeting at a minimum. May touch enough areas that we want to discuss on TWS again?

I’ve uploaded some slides that help explain the thinking on the GBP Wiki

https://wiki.opendaylight.org/images/e/e3/OS-ODL_Mapping.pdf

https://wiki.opendaylight.org/images/a/a0/TWS-ODL-tenancy-preso-2014-06-02.pdf

Bring it on!

-drl

From: Lenrow, Dave
Sent: Friday, May 23, 2014 9:20 AM
To: discuss@...; controller-dev@...
Subject: Expanding on N-deep tenant hierarchy

Some folks have asked me to restate my vision for how/why we need a flexible tenant concept. Please note that

One could imagine a strict hierarchy of control as follows in which each subsequent tenant entity has authority/scope/role defined and limited by it’s parent/child relationship through which it inherits a constrained view of the total resource pool.

Facitlities Based Provider – Owns switches, servers, fibre, etc.

    Virtual Cloud Provider – Sells access to a subset of the resources offered by FBP parent

        Corporate Customer – provides corporate wide access to subset of  resources offered by VCP parent

            Business unit of Corporation – provides on-demand self-service access to subset of resources offered by CC parent

                Admin in business Unit – provides on-demand, self-service access to subset of BU resources

                    BU developer – consumes on-demand, self-service subset of BU resources

                        BU production application – consumes resources as defined by developer with elastics scaleout-based on load.

                            Application module – can do stuff within envelope of BUA parent.

                                Etc.

In this case N=8, but the instant we decide that is the right constant, somebody will come up with a good reason for 9. If we decide N=25 to have lot’s of headroom we will feel dumb some day.

I claim we need an architecture that allows for a hierarchy that is arbitrarily deep.

FBP can decide that VCP 1 gets 80 of the bandwidth in the physical fabric and VCP 2 gets 20%, but with special express links between metro hubs.

VCP one can sell  LargeCo access to some dedicated resources and an ability to burst on-demand up to a limit X in a shared pool.

LargeCo can define which virtual networks are accessible to the Finance BU

FinBU can allow admin to choose developers who are allowed to request Gold QoS on their diffserv vnet

BU dev can contain the number of instances of paystubprinter allowed on-demand.

PayStubPrinter FinBU app can decide how/when to load balance across multi-link border interface

App module can stream log data within storage contstraints from FinBU (great-grand-parent)

Etc.

Above is kind of goofy contrived example, so please send nit picking to /dev/null.

Point is Tenancy cannot be flat, or shallow, but must be supported for potential complex hierarchy of control.

Within the hierarchy, the limits of what a child can do are always defined buy inheritance from their parent.

Authentication at any level of the hierarchy could be to a common, multi-tenant aware auth server or to an instance of auth-server with constrained/local context (e.g. FinBU auth server for FinBU and children).

Do others feel that this vision is sensible and needs to get reflected in our requirements?

It won’t surprise anyone that I think we need to build the enforcement of the rules of such a hierarchy into a controller based declarative intent NBI. I would suggest that the single writer of policy be the only trusted client of a completely trusted NBI and that the entire hierarchy of control and enforcement be built above that trusted interface.  As others have recommended, the controller would have no native sense of tenancy in the management/control plane (there are clearly requirements, e.g. overlapping tenant IP address spaces that need to be handled in tenant context in the data plane). The intent NBI would become the single-sign-on interface for AAA for non-infrastructure entities (e.g. securing controller-native bunldles and interfaces needs it’s own secure plumbing solution).

If folks want to talk me out of a single policy writer completely trusted, I won’t be surprised (and I’m sure the reasons will be compelling), but  the top of the plumbing AAA/policy stack needs to connect to the bottom of the intent based NBI stack cleanly with no AAA ambiguity.

I’m donning my flame retardant suit as I hit send and await our communities diverse views on my wacky vision of the future. Be gentle friends.

-drl

Dave Lenrow

Distinguished Architect

Advanced Technology Group - HP Networking

Hewlett-Packard, Littleton MA

+1 (617)-329-1861 (mobile)

david.lenrow@...

@dlenrow

From: Rob Adams [mailto:readams@...]
Sent: Monday, August 04, 2014 1:06 AM
To: Colin Dixon
Cc: Luis Gomez; <discuss@...>; Lenrow, Dave; groupbasedpolicy-dev@...; aaa-dev@...
Subject: Re: [OpenDaylight Discuss] On multi-tenancy support

Just completed adding the IDM APIs.

https://docs.google.com/spreadsheets/d/1YYMmK_V5LMAjLGZOEjfKSX0x4Gwb-K5Xuk1wZskwWwY/edit?usp=sharing

Peter.

Hi everyone,

As our M4 milestone (API freeze) is approaching next week (8/4), I have put together a list of NB APIs that we plan to expose for Helium:

https://docs.google.com/spreadsheets/d/1YYMmK_V5LMAjLGZOEjfKSX0x4Gwb-K5Xuk1wZskwWwY/edit?usp=sharing

Please update any API that you see missing or inaccurate…  Peter, if you can help me fill out the section on IdM, that would be great.  I have modified the IdM APIs a little bit from the original ones, primarily on removing “user_id” from the URL, since it is a PII item and should be encrypted appropriately.  So, we will use a header (ODL_USER_ID?) for that purpose.

Thanks,

Liem

Hi everyone,

As our M4 milestone (API freeze) is approaching next week (8/4), I have put together a list of NB APIs that we plan to expose for Helium:

https://docs.google.com/spreadsheets/d/1YYMmK_V5LMAjLGZOEjfKSX0x4Gwb-K5Xuk1wZskwWwY/edit?usp=sharing

Please update any API that you see missing or inaccurate…  Peter, if you can help me fill out the section on IdM, that would be great.  I have modified the IdM APIs a little bit from the original ones, primarily on removing “user_id” from the URL, since it is a PII item and should be encrypted appropriately.  So, we will use a header (ODL_USER_ID?) for that purpose.

Thanks,

Liem

Hi John,

Thanks for putting this together.  I like both approaches!  I think both have merits, strengths and weaknesses.

I like the template/rule-based approach for its simplicity; however, I think that we should limit its functionality to just sed/awk type transformation, because going beyond that (like embedding control/flow logics) makes it more complicated and diminishes the promised simplicity benefit of this approach...  Kinda reminds me of assembly language and microcode <shiver/> :)

However, I do recognize that for some "real-world" use-cases, we may have a need for control logics.  In these cases, my preference would be to use a scripting language that I am familiar with to express control logics rather than using JSON (which is intended to be a data exchange format, after all), for all the reasons you mentioned, including debuggability.

So, I think we can start out with just a set of awk/sed type rules to do simple transformations but also allow additional (pluggable) rules to be defined and evaluated elsewhere in an external script.  Not sure if you have looked into it, but Java does have a built-in Javascript engine that you can use to execute Javascript from within the JVM.  Java 6/7 uses the Rhino engine, while Java 8 uses the Nashorn engine which is supposed to be faster than Rhino:

http://ariya.ofilabs.com/2014/03/nashorn-the-new-rhino-on-the-block.html

As for security, we should be able to leverage Karaf security to gate access to the bundle that loads the script, assuming the embedded script engine is used.

Regards,

Liem

Hi everyone,

As we ramped up on documentation, one thing (among others J) I notice lacking from our documentation is the interaction of different actors/external systems with the AAA system.  So, I took the liberty to document it here:

https://drive.google.com/file/d/0B1KtwIIbDsZXSS04UVJLQ1hqbVk/edit?usp=sharing

I think this would nicely compliment our design blueprint, which deals more with the inner workings of the AAA system.

Comments/questions are welcome.

Thanks,

Liem