This group is locked. No changes can be made to the group while it is locked.
|
Re: ssh passwordless login to Karaf
Jamo Luhrsen <jluhrsen@...>
if it's possible to use a wrapper to ssh, you could try sshpass like
toggle quoted messageShow quoted text
we do in our CSIT deployment logic: https://git.opendaylight.org/gerrit/gitweb?p=releng/builder.git;a=blob;f=jjb/integration/integration-deploy-controller-run-test.sh;h=021161e61d6a10646aaf01618dba9d0eae810bc1;hb=fb567a578ef3dcad21d85b0e471f745fcbe9aed6#l143 JamO
On 6/13/18 6:56 AM, Ryan Goulding wrote:
Vamsi,
|
|
|
|
Re: ssh passwordless login to Karaf
Ryan Goulding <ryandgoulding@...>
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
On Wed, Jun 13, 2018 at 5:27 AM, A Vamsikrishna <a.vamsikrishna@...> wrote:
|
|
|
|
ssh passwordless login to Karaf
A Vamsikrishna
Hi Stephen / Ryan,
Can you please help me with the steps to perform ssh passwordless login to Karaf ?
Thanks, Vamsi
|
|
|
|
Re: [controller-dev] [yangtools-dev] patch-test triggers to run csit on patches
Luis Gomez
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 distribution and running some CSIT we would catch any issue we would see when you build a downstream project?
toggle quoted messageShow quoted text
On Jun 6, 2018, at 8:28 AM, Robert Varga <nite@...> wrote:
|
|
|
|
Re: [controller-dev] [yangtools-dev] patch-test triggers to run csit on patches
Robert Varga
On 06/06/18 17:15, Luis Gomez wrote:
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 downstream project apart from distribution.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 & effective -- MRIs are supposed to be ABI-backwards-compatible after all :) This will not work with packaging changes (i.e. different set of .jars), but that should be very very rare. Regards, Robert
|
|
|
|
Re: [controller-dev] [yangtools-dev] patch-test triggers to run csit on patches
Luis Gomez
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 downstream project apart from distribution.
toggle quoted messageShow quoted text
So this makes me wonder for this and also MRI project like odlparent, yangtools, what kind of patch verification is more useful: - Build all downstream projects - Build patch + distribution + run CSIT - Build all downstream projects + run CSIT (expensive but possible) BR/Luis
On Jun 6, 2018, at 5:16 AM, Robert Varga <nite@...> wrote:
|
|
|
|
Re: [yangtools-dev] patch-test triggers to run csit on patches
Robert Varga
On 05/06/18 16:28, Sam Hague wrote:
All the projects in the to: list have the ability to run genius andThis 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
|
|
|
|
patch-test triggers to run csit on patches
Sam Hague <shague@...>
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 notice a non-success, please ping the genius and netvirt lists to look at the job so the team can fix any issues found. The format of the comment is: test-<project>-<genius|netvirt|cluster-netvirt>. For example, on a controller patch, you would add this comment to run genius csit: test-controller-genius. This is shown in controller patch: https://git.opendaylight.org/gerrit/#/c/72650/. For aaa to run netvirt csit, test-aaa-netvirt. Thanks, Sam
|
|
|
|
Re: [OpenDaylight TSC] Available Approaches For Eliminating Apache OLTU Dependencies
Abhijit Kumbhare <abhijitkoss@...>
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 your topics). I just corrected yours - but before that it looked very strange: The next TSC meeting is scheduled May 31st with the following proposed agenda:
The next TSC meeting is scheduled May 24th with the following proposed agenda:
Above yours and Michael's edits are shown above in red - but they should have been under the section shown above in blue.
On Wed, May 30, 2018 at 12:51 PM, Ryan Goulding <ryandgoulding@...> wrote:
|
|
|
|
Re: [OpenDaylight TSC] Available Approaches For Eliminating Apache OLTU Dependencies
Ryan Goulding <ryandgoulding@...>
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.
On Wed, May 30, 2018 at 10:27 AM, Ryan Goulding <ryandgoulding@...> wrote:
|
|
|
|
Re: [OpenDaylight TSC] Available Approaches For Eliminating Apache OLTU Dependencies
Ryan Goulding <ryandgoulding@...>
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
On Tue, May 29, 2018 at 9:25 AM, Ryan Goulding <ryandgoulding@...> wrote:
|
|
|
|
Re: [OpenDaylight TSC] Available Approaches For Eliminating Apache OLTU Dependencies
Ryan Goulding <ryandgoulding@...>
Not functionality we we should cover in ODL IMHO, let's focus on SDN - it's hard enough. 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 ODL. TSC, do we need a vote on removing this functionality this release? Or a #agreed? Thanks, Ryan On Fri, May 25, 2018 at 10:51 AM, Michael Vorburger <vorburger@...> wrote:
|
|
|
|
Re: [OpenDaylight TSC] Available Approaches For Eliminating Apache OLTU Dependencies
Michael Vorburger <vorburger@...>
On Fri, May 25, 2018 at 4:44 PM, Ryan Goulding <ryandgoulding@...> wrote:
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.
|
|
|
|
Re: [OpenDaylight TSC] Available Approaches For Eliminating Apache OLTU Dependencies
Ryan Goulding <ryandgoulding@...>
Any idea on what could be the alternative to oauth2 API? 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 server supporting these capabilities and locking down the jetty server to localhost only. A similar setup is shown through [1] and is possible with other IdPs/use cases. Regards, Ryan On Thu, May 24, 2018 at 7:23 PM, Luis Gomez <ecelgp@...> wrote:
|
|
|
|
Re: [OpenDaylight TSC] Available Approaches For Eliminating Apache OLTU Dependencies
Tom Pantelis
On Thu, May 24, 2018 at 6:31 PM, Michael Vorburger <vorburger@...> wrote:
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 security non-compliance and the fact that it's dead, I think that should trump the our normal MO.
|
|
|
|
Re: [OpenDaylight TSC] Available Approaches For Eliminating Apache OLTU Dependencies
Luis Gomez
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
|
|
|
|
Re: [OpenDaylight TSC] Available Approaches For Eliminating Apache OLTU Dependencies
Michael Vorburger <vorburger@...>
On Thu, 24 May 2018, 18:01 Ryan Goulding, <ryandgoulding@...> wrote:
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.
|
|
|
|
Re: Committers Please Vote
Ryan Goulding <ryandgoulding@...>
All existing committers have voted +1. I will raise this to the TSC for a vote. Thanks, Ryan
On Thu, May 24, 2018 at 11:01 AM, Mohamed El-Serngawy <m.elserngawy@...> wrote:
|
|
|
|
Available Approaches For Eliminating Apache OLTU Dependencies
Ryan Goulding <ryandgoulding@...>
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. The AAA oauth2 implementation depends on the now defunct OLTU project as reported here [1]. Use of healthy upstream dependencies is important for the ability to pick up security and maintenance fixes. As such, we should move away from utilizing OLTU. Upon investigating solutions, the bigger question was posed whether AAA should maintain an OAuth2 Provider at all. I am not entirely sure of the original motivation, since it happened long before I was involved in the project. However, there are many existing IdP solutions that provide proven and secure token implementations, and I suggest we utilize federation over providing our own version. I suggest we remove the existing aaa token implementation, and the corresponding HTTP APIs. The only question then becomes execution. There are a few options we can take: 1) Release Fluorine with Deprecated oauth2 API(s) and the existing latest oltu dependency. We released with non-Deprecated oauth2 APIs coupled to the latest released OLTU in Nitrogen, since OLTU committers had still not announced that the project was dead. For Fluorine release, it leaves us knowingly dependent on a dead upstream, and with an associated increase to vulnerability. 2) Release Fluorine with Deprecated oauth2 API(s) with a forked OLTU dependency [2]. This is important since it has the side benefit of eliminating org.json in AAA and alleviating [3]. However, we would then need to agree to maintain this code ourselves for the release. It would allow us to adhere to our rule to deprecate in one release and remove in the following. 3) Release Fluorine without the token HTTP service [4]. This would violate our rule to deprecate in one release and remove in the following. It provides the benefit of removing a possibly insecure upstream dependency that we may not be able to mitigate. I have limited insight into how it is used by consumers. I prefer option #3, but am open to discussion. Thanks, Ryan [1] https://jira.opendaylight.org/projects/AAA/issues/AAA-173 [2] https://git.opendaylight.org/gerrit/#/c/72038/ [3] https://jira.opendaylight.org/browse/ODLPARENT-36 [4] https://git.opendaylight.org/gerrit/#/c/72022/
|
|
|
|
Re: Committers Please Vote
Mohamed ElSerngawy
+1 BR
On Thu, May 24, 2018 at 8:30 AM, Ryan Goulding <ryandgoulding@...> wrote:
--
Mohamed ElSerngawy +1 438 993 2462
|
|
|