Nguyen, Liem Manh <liem_m_nguyen@...>
Coincidentally, AAA (Lithium) can use Keystone as an IdP (and not the other way around). That is, a token obtained from Keystone can be used to authenticate/authorize
with the ODL controller.
Regards,
Liem
toggle quoted message
Show quoted text
From: controller-dev-bounces@... [mailto:controller-dev-bounces@...]
On Behalf Of Wojciech Dec
Sent: Tuesday, January 27, 2015 1:38 AM
To: Ed Warnicke
Cc: discuss@...; Kyle Mestery; groupbasedpolicy-dev@...; ovsdb-dev@...; aaa-dev@...; controller-dev@...; vtn-dev@...
Subject: Re: [controller-dev] [Aaa-dev] [groupbasedpolicy-dev] [OpenDaylight Discuss] Port 8080 and the adsal stuff
On 27 January 2015 at 03:45, Ed Warnicke <hagbard@...> wrote:
Aaa authn can integrate with a wide variety of systems, of which keystone is but one. This move doesn't force the issue, and I expect the existing http basic auth admin:admin to remain the default.
Liem (from the Aaa project) is probably the right guy to reach out to the keystone guts to understand their objection to that (one among many) aaa integration option(s).
On Jan 26, 2015, at 7:32 PM, Kyle Mestery <mestery@...> wrote:
On Mon, Jan 26, 2015 at 3:08 PM, Edward Warnicke <hagbard@...> wrote:
I have a patch here:
a) Takes option #2 (moves adsal to port 8282, adds the stock jetty to port 8080)
b) Makes sure that neutron works correctly with jetty.
I've tested it as noted in the commit comments, and would welcome others testing it as well.
If there are no issues, I'd like to merge it on 2/1/2015.
1) It makes neutron use our aaa project authn, so we should (Liem will have to chime in to explain) get the ability to interface our neutron service with Keystone.
I was in some meetings with (among others) the PTL of Keystone, and this is NOT something the keystone folks want. Before you go down this path, I suggest talking to the keystone folks.
2) Since there *wasn't* a neutron feature before you could load on its own, there is now a neutron feature, you can see how to use it in the patch for integration here:
Since the previous way to pick up neutron was to pull in odl-nsf-all, you will need to change to using the old-neutron-northbound feature if you provide an existing provider.
On Mon, Jan 19, 2015 at 7:40 AM, Mathieu Lemay <mlemay@...> wrote:
Anil,
This is indeed a great point. It would be nice to outline a Community Roadmap that would tackle the critical decisions such as:
or any other long term decision. Moreover, I hope some projects will graduate to Core or another lifecycle.. Wouldn't it be a good idea to have perks/incentives that will make the projects want to graduate? Such as be listed in a different
feature repository or be added as default to the distribution.?
Anyhow , I'll leave this discussion to the TSC.
On Mon, Jan 19, 2015 at 5:23 AM, Anil Vishnoi <vishnoianil@...> wrote:
IMO, #2 is an ideal solution, but given that in community we think going forward AD-SAL will be deprecated so probably it make sense to defer to #1.
The only concern I see with #1 is that it will invite lot of questions like "it was working with hydrogen/helium but not working with current master" :) ( which i believe we can't avoid anyways) AND also updating the relevant documentation.
If we can take care of documentation as well, I vote for #1.
Was there any discussion on when are we deprecating AD-SAL? AFAIK there were couple of discussions over mailing list but those never reached to any conclusion as such. IMHO having a time frame helps a lot to take decision about these kind
of problems. e.g If we decide that AD-SAL deprecation will be announce in this release and it will be removed in beryllium, then IMO it probably make sense to defer the port change till next release.
On Wed, Jan 14, 2015 at 6:10 AM, Mathieu Lemay <mlemay@...> wrote:
Hi Ed,
Indeed that has been problematic. AD-SAL is using the Valves for security and is wielded from a user management perspective.However, I would like to see the community's opinion on the two options.
#1 Leave everything as-is and simply move that to port 8282 to avoid confusion from people. Bringing AD-SAL would bring Tomcat. It also create a variety of 'Errors' in the logs as Jetty will also try to start the webapps and fail to do
so because of the Tomcat-specific addons.
#2 Remove the Valves and Tomcat dependency and run AD-SAL alongside the current 8181 applications (on Jetty). This means that many northbound services will have to be revisited. While the task is not enormous it is more work than #1.. If
people no longer use AD-SAL I'd vote for #1.. if there is a need for it I can look in #2.
Please let me know what you guys think!
On Wed, Jan 14, 2015 at 7:55 AM, Edward Warnicke <hagbard@...> wrote:
Guys,
The old AD-SAL stuff is currently running a completely separate (and antiquated) Tomcat based stack on port 8080. Unfortunately there are pieces of the AD-SAL that are quite thoroughly welded to Tomcat, and cannot easily be extracted
from it.
All of the newer stuff is using the karaf build in jetty web stack, which is currently running on port 8181.
Port 8080 is traditionally the port used for web stuff in the java world.
As the AD-SAL is being deprecated, I'd like to move the AD-SAL stuff to using port 8282, and have the karaf built in jetty running on port 8080 and 8181. (please note I already have a patch out for making the neutron service run with
jetty, on which every ports it is running, so this change should *not* impact the neutron service stuff).
Before pushing patches to do this, I wanted to open up a discussion to see what other folks think about it. So please see this less as a notification and more as a conversation starter ;)
_______________________________________________
controller-dev mailing list
controller-dev@...
https://lists.opendaylight.org/mailman/listinfo/controller-dev
--
Mathieu Lemay
_______________________________________________
Discuss mailing list
Discuss@...
https://lists.opendaylight.org/mailman/listinfo/discuss
--
--
Mathieu Lemay
_______________________________________________
groupbasedpolicy-dev mailing list
groupbasedpolicy-dev@...
https://lists.opendaylight.org/mailman/listinfo/groupbasedpolicy-dev
_______________________________________________
aaa-dev mailing list
aaa-dev@...
https://lists.opendaylight.org/mailman/listinfo/aaa-dev
|
Edward Warnicke <hagbard@...>
toggle quoted message
Show quoted text
On Tue, Jan 27, 2015 at 12:41 PM, Nguyen, Liem Manh <liem_m_nguyen@...> wrote:
Coincidentally, AAA (Lithium) can use Keystone as an IdP (and not the other way around). That is, a token obtained from Keystone can be used to authenticate/authorize
with the ODL controller.
Regards,
Liem
From: controller-dev-bounces@... [mailto:controller-dev-bounces@...]
On Behalf Of Wojciech Dec
Sent: Tuesday, January 27, 2015 1:38 AM
To: Ed Warnicke
Cc: discuss@...; Kyle Mestery; groupbasedpolicy-dev@...; ovsdb-dev@...; aaa-dev@...; controller-dev@...; vtn-dev@...
Subject: Re: [controller-dev] [Aaa-dev] [groupbasedpolicy-dev] [OpenDaylight Discuss] Port 8080 and the adsal stuff
On 27 January 2015 at 03:45, Ed Warnicke <hagbard@...> wrote:
Aaa authn can integrate with a wide variety of systems, of which keystone is but one. This move doesn't force the issue, and I expect the existing http basic auth admin:admin to remain the default.
Liem (from the Aaa project) is probably the right guy to reach out to the keystone guts to understand their objection to that (one among many) aaa integration option(s).
On Jan 26, 2015, at 7:32 PM, Kyle Mestery <mestery@...> wrote:
On Mon, Jan 26, 2015 at 3:08 PM, Edward Warnicke <hagbard@...> wrote:
I have a patch here:
a) Takes option #2 (moves adsal to port 8282, adds the stock jetty to port 8080)
b) Makes sure that neutron works correctly with jetty.
I've tested it as noted in the commit comments, and would welcome others testing it as well.
If there are no issues, I'd like to merge it on 2/1/2015.
1) It makes neutron use our aaa project authn, so we should (Liem will have to chime in to explain) get the ability to interface our neutron service with Keystone.
I was in some meetings with (among others) the PTL of Keystone, and this is NOT something the keystone folks want. Before you go down this path, I suggest talking to the keystone folks.
2) Since there *wasn't* a neutron feature before you could load on its own, there is now a neutron feature, you can see how to use it in the patch for integration here:
Since the previous way to pick up neutron was to pull in odl-nsf-all, you will need to change to using the old-neutron-northbound feature if you provide an existing provider.
On Mon, Jan 19, 2015 at 7:40 AM, Mathieu Lemay <mlemay@...> wrote:
Anil,
This is indeed a great point. It would be nice to outline a Community Roadmap that would tackle the critical decisions such as:
or any other long term decision. Moreover, I hope some projects will graduate to Core or another lifecycle.. Wouldn't it be a good idea to have perks/incentives that will make the projects want to graduate? Such as be listed in a different
feature repository or be added as default to the distribution.?
Anyhow , I'll leave this discussion to the TSC.
On Mon, Jan 19, 2015 at 5:23 AM, Anil Vishnoi <vishnoianil@...> wrote:
IMO, #2 is an ideal solution, but given that in community we think going forward AD-SAL will be deprecated so probably it make sense to defer to #1.
The only concern I see with #1 is that it will invite lot of questions like "it was working with hydrogen/helium but not working with current master" :) ( which i believe we can't avoid anyways) AND also updating the relevant documentation.
If we can take care of documentation as well, I vote for #1.
Was there any discussion on when are we deprecating AD-SAL? AFAIK there were couple of discussions over mailing list but those never reached to any conclusion as such. IMHO having a time frame helps a lot to take decision about these kind
of problems. e.g If we decide that AD-SAL deprecation will be announce in this release and it will be removed in beryllium, then IMO it probably make sense to defer the port change till next release.
On Wed, Jan 14, 2015 at 6:10 AM, Mathieu Lemay <mlemay@...> wrote:
Hi Ed,
Indeed that has been problematic. AD-SAL is using the Valves for security and is wielded from a user management perspective.However, I would like to see the community's opinion on the two options.
#1 Leave everything as-is and simply move that to port 8282 to avoid confusion from people. Bringing AD-SAL would bring Tomcat. It also create a variety of 'Errors' in the logs as Jetty will also try to start the webapps and fail to do
so because of the Tomcat-specific addons.
#2 Remove the Valves and Tomcat dependency and run AD-SAL alongside the current 8181 applications (on Jetty). This means that many northbound services will have to be revisited. While the task is not enormous it is more work than #1.. If
people no longer use AD-SAL I'd vote for #1.. if there is a need for it I can look in #2.
Please let me know what you guys think!
On Wed, Jan 14, 2015 at 7:55 AM, Edward Warnicke <hagbard@...> wrote:
Guys,
The old AD-SAL stuff is currently running a completely separate (and antiquated) Tomcat based stack on port 8080. Unfortunately there are pieces of the AD-SAL that are quite thoroughly welded to Tomcat, and cannot easily be extracted
from it.
All of the newer stuff is using the karaf build in jetty web stack, which is currently running on port 8181.
Port 8080 is traditionally the port used for web stuff in the java world.
As the AD-SAL is being deprecated, I'd like to move the AD-SAL stuff to using port 8282, and have the karaf built in jetty running on port 8080 and 8181. (please note I already have a patch out for making the neutron service run with
jetty, on which every ports it is running, so this change should *not* impact the neutron service stuff).
Before pushing patches to do this, I wanted to open up a discussion to see what other folks think about it. So please see this less as a notification and more as a conversation starter ;)
_______________________________________________
controller-dev mailing list
controller-dev@...
https://lists.opendaylight.org/mailman/listinfo/controller-dev
--
Mathieu Lemay
_______________________________________________
Discuss mailing list
Discuss@...
https://lists.opendaylight.org/mailman/listinfo/discuss
--
--
Mathieu Lemay
_______________________________________________
groupbasedpolicy-dev mailing list
groupbasedpolicy-dev@...
https://lists.opendaylight.org/mailman/listinfo/groupbasedpolicy-dev
_______________________________________________
aaa-dev mailing list
aaa-dev@...
https://lists.opendaylight.org/mailman/listinfo/aaa-dev
|
