if it's possible to use a wrapper to ssh, you could try sshpass like we do in our CSIT deployment

Vamsi, AAA does not control karaf's authentication; the two are configured separately. I suggest you engage the upstream Apache Karaf community. HTH. Regards, Ryan Regards, Ryan Goulding

Hi Stephen / Ryan, Can you please help me with the steps to perform ssh passwordless login to Karaf ? Thanks, Vamsi

This sounds more like my second item, what about the first or third? what kind of upstream patch requires downstream project build? or you think by just building the patch, replacing jars in

My thinking is: 1) build patch 2) download current distribution 3) unpack 4) overwrite existing .jars (yeah, utterly ignoring versions) 5) repack 6) run CSIT Dirty, but should be very quick &

Couple of notes here: the "test-<project>-<feature>" framework used to trigger CSIT on a patch only works in Snapshot integrated projects (mdsal, controller, etc…) and it does not build any

This is awesome :) although yangtools would also need a replacement of jars, so I am not sure how useful it is at this time :) Thanks, Robert

All the projects in the to: list have the ability to run genius and netvirt csit on any patch using a gerrit comment. The job is non-voting and only reports back status. If you do run the csit and

Sure Ryan. BTW - we only keep agenda items for the current week. So you should add under the main agenda items - and not add a fresh section for a new TSC meeting (as Michael and you have done for

No one responded, so I took the liberty to add this topic to the proposed agenda here [0]. Please let me know if we do not have time to discuss this. Regards, Ryan [0]

TSC, Can we get some clarification on this? Or at least add it as an agenda item for the meeting tomorrow, as we didn't have time last week? Thanks, Ryan

100% agreed. Again, this was something added long before my time, and there was probably a good reason at the time. However, I agree that it is short-sighted to continue maintaining this in

https://www.keycloak.org can be used to do this sort of thing, AFAIK. Not functionality we we should cover in ODL IMHO, let's focus on SDN - it's hard enough.

Federating with an existing OpenID Connect IdP [0]. OpenID provides an authentication layer on top of the OAuth2 authorization layer. Currently, this would need to be done by fronting ODL with a web

Same here - if none of the current stakeholders in upstream ODL use it and have any objections. It's unlikely anyone uses it. While #1 follows our normal MO, if the dependency might introduce a

Any idea on what could be the alternative to oauth2 API? I guess as long as we understand the API change and document it well, I do not see problem on my side. BR/Luis

Strong +1 for option #3 to simplify AAA and ASAP (Fluorine) remove anything nobody uses and that was perhaps originally overdesigned in it, such as this functionality.

All existing committers have voted +1. I will raise this to the TSC for a vote. Thanks, Ryan

Dear TSC, On behalf of the AAA project, I want to address that Apache OLTU has been moved to Attic as socialized here [0]. This means it is no longer maintained and there will be no new releases.

+1 BR -- Mohamed ElSerngawy +1 438 993 2462