[openstack-dev] [horizon][keystone]

Dear All One of my students, Anton Brida, has developed an Attribute Mapping GUI for Horizon as part of his MSc project. Attribute mappings are an essential, though complex, part of federated Keystone. Currently they can only be created as JSON objects in the config file. The Horizon code allows t

[openstack-dev] [horizon][keystone]

Hi all,I have been helping with the websso effort and wanted to get some feedback.Basically, users are presented with a login screen where they can select: credentials, default protocol, or discovery service.If user selects credentials, it works exactly the same way it works today.If user selects d

Re: [openstack-dev] [horizon][keystone]

lanning further work on this, so the patch is available for adoption. That way somebody else may be able to pick this up and work on it in the future, but Anton could get credit for the work he has done. Doug Fish     - Original message -From: David Chadwick To: OpenStack Development Mail

Re: [openstack-dev] [horizon][keystone]

----- > From: David Chadwick > To: OpenStack Development Mailing List > > Cc: > Subject: [openstack-dev] [horizon][keystone] > Date: Tue, Oct 6, 2015 2:13 PM > > Dear All > > One of my students, Anton Brida, has developed an Attr

Re: [openstack-dev] [horizon][keystone]

and work on it in the future, but Anton could get credit for the work he has done. Doug Fish - Original message - From: David Chadwick To: OpenStack Development Mailing List Cc: Subject: [openstack-dev] [horizon][keystone] Date: Tue, Oct 6,

Re: [openstack-dev] [horizon][keystone]

e that you >>> aren't planning further work on this, so the patch is available for >>> adoption. That way somebody else may be able to pick this up and work on >>> it in the future, but Anton could get credit for the work he has done. >>> >>> Doug Fish >>>

Re: [openstack-dev] [horizon][keystone]

rk he has done. Doug Fish - Original message - From: David Chadwick To: OpenStack Development Mailing List Cc: Subject: [openstack-dev] [horizon][keystone] Date: Tue, Oct 6, 2015 2:13 PM Dear All One of my students, Anton Brida, has develo

Re: [openstack-dev] [horizon][keystone]

cleaned up or anything like that. You could mark it as a >>>> "Work in progress", and make it clear in the commit message that you >>>> aren't planning further work on this, so the patch is available for >>>> adoption. That way somebody else may

Re: [openstack-dev] [horizon][keystone]

e and > >>>> documentation > >>>> you have to Horizon? It doesn't have to be complete; it doesn't need > to > >>>> have grammar cleaned up or anything like that. You could mark it as a > >>>> "Work in progress", and mak

Re: [openstack-dev] [horizon][keystone]

ld you or Anton be willing to propose whatever code and > >>>> documentation > >>>> you have to Horizon? It doesn't have to be complete; it doesn't > need to > >>>> have grammar cleaned up or anything like that. You could mark >

Re: [openstack-dev] [horizon][keystone]

se code written by somebody else) and I can't > > spend > > >>>> significant time on it right now. > > >>>> Would you or Anton be willing to propose whatever code and > > >>>> documentation > > >>>> y

Re: [openstack-dev] [horizon][keystone]

Hi, I guess "Credentials" is login and password. I have no idea what is "Default Protocol" or "Discovery Service". The proposed UI is rather embarrassing. Anton On Thu, Feb 5, 2015 at 12:54 AM, Thai Q Tran wrote: > Hi all, > > I have been helping with the websso effort and wanted to get some f

Re: [openstack-dev] [horizon][keystone]

Hi Thai, I agree with Anton that the names are not intuitive for users. I would use something like: - Local authentication (for local credentials) - ?? (I also have no idea of what is a Default protocol) - Authenticate using (something which is easy to the user understand that he could use or no

Re: [openstack-dev] [horizon][keystone]

5/2015 06:04:36 AM: > From: Ioram Schechtman Sette > To: "OpenStack Development Mailing List (not for usage questions)" > > Date: 02/05/2015 06:14 AM > Subject: Re: [openstack-dev] [horizon][keystone] > > Hi Thai, > > I agree with Anton that the names are

Re: [openstack-dev] [horizon][keystone]

questions)" > > Date: 02/05/2015 06:14 AM > Subject: Re: [openstack-dev] [horizon][keystone] > > Hi Thai, > > I agree with Anton that the names are not intuitive for users. > I would use something like: > - Local authentication (for local credentials)

Re: [openstack-dev] [horizon][keystone]

r idea, I would love to see it.-Ioram Schechtman Sette wrote: -To: "OpenStack Development Mailing List (not for usage questions)" From: Ioram Schechtman Sette Date: 02/05/2015 03:15AMSubject: Re: [openstack-dev] [horizon][keystone]Hi Thai,I agree with Anton that the names are n

Re: [openstack-dev] [horizon][keystone]

To: "OpenStack Development Mailing List (not for usage questions)" From: Ioram Schechtman Sette Date: 02/05/2015 03:15AM Subject: Re: [openstack-dev] [horizon][keystone] Hi Thai, I agree with Anton that the names are not intuitive for users. I would use something like: - Local authen

Re: [openstack-dev] [horizon][keystone]

Marek,Yep, that makes a lot of sense. Can definitely add that.-Marek Denis wrote: -To: From: Marek Denis Date: 02/05/2015 01:35PMSubject: Re: [openstack-dev] [horizon][keystone] Thai, We could also add an option in the Horizon's settings

Re: [openstack-dev] [horizon][keystone]

they can select something different. Thanks, Kevin From: Thai Q Tran [tqt...@us.ibm.com] Sent: Thursday, February 05, 2015 11:15 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [horizon][keystone] Hi Ioram, Thanks for

Re: [openstack-dev] [horizon][keystone]

On 02/04/2015 03:54 PM, Thai Q Tran wrote: Hi all, I have been helping with the websso effort and wanted to get some feedback. Basically, users are presented with a login screen where they can select: credentials, default protocol, or discovery service. If user selects credentials, it works e

Re: [openstack-dev] [horizon][keystone]

On 02/05/2015 04:20 AM, Anton Zemlyanov wrote: Hi, I guess "Credentials" is login and password. I have no idea what is "Default Protocol" or "Discovery Service". The proposed UI is rather embarrassing. No it is not. It is a rapid prototyping technique to get things to fail fast, and to get f

Re: [openstack-dev] [horizon][keystone]

On Fri, Feb 6, 2015 at 12:47 PM, Adam Young wrote: > On 02/04/2015 03:54 PM, Thai Q Tran wrote: > > Hi all, > > I have been helping with the websso effort and wanted to get some feedback. > Basically, users are presented with a login screen where they can select: > credentials, default protocol,

Re: [openstack-dev] [horizon][keystone]

I think this GUI is not intuitive to users and therefore should not be encouraged or supported. If you ask a user "what does authenticate via a Discovery Service mean?" I think you will get some very strange answers. The same goes for "Authenticate using Default Protocol". Users will have no idea

Re: [openstack-dev] [horizon][keystone]

On 02/18/2015 12:02 PM, David Chadwick wrote: I think this GUI is not intuitive to users and therefore should not be encouraged or supported. It is a fist hack. I think you don't mean "any gui" just that there are some warning flags raised by this design? If you ask a user "what does authe

Re: [openstack-dev] [horizon][keystone]

Hi Adam there is some work being done on this by HP, Intel and IBM, and they have some designs at http://invis.io pieter.c.kruithof...@hp.com can send you the details as he invited me to comment on the designs, which I have done. As you know, we already have our own federated Horizon login scr

Re: [openstack-dev] [horizon][keystone] SSO

ent: 06 February 2015 19:48 To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [horizon][keystone] On 02/04/2015 03:54 PM, Thai Q Tran wrote: Hi all, I have been helping with the websso effort and wanted to get some feedback. Basically, users are presented with a login screen

Re: [openstack-dev] [horizon][keystone] SSO

cognise that. > > > > Tim > > > > > > *From:* Adam Young [mailto:ayo...@redhat.com] > *Sent:* 06 February 2015 19:48 > *To:* openstack-dev@lists.openstack.org > *Subject:* Re: [openstack-dev] [horizon][keystone] > > > > On 02/04/2015 03:54 PM, Thai Q Tr

Re: [openstack-dev] [horizon][keystone] SSO)

On Mon, 2015-02-09 at 13:32 +0400, Anton Zemlyanov wrote: > 2) There is no such a thing as OpenStack ID. Should we use Launchpad? > Facebook login? Twitter? > Actually, there is: https://openstackid.org :) It supports OpenID and OAuth, the code is on http://git.openstack.org/cgit/openstack-infra/o

[openstack-dev] Horizon, Keystone, Kerberos, and Federation

I've been looking in to enabling Kerberos for Horizon. Since Horizon passes the Users credentials on to Keystone to get a token, Kerberos requires an additional delegation mechanism. This leads to some questions about how to handle delegation in the case of Federated Identity. In Kerberos,

[openstack-dev] [horizon] [keystone] Cross-Project Meeting

Hey everyone, Quick reminder about the Keystone-Horizon meeting at 2000 UTC (about 1h45 from this email being sent). You can see the details and add it to your calendar via http://eavesdrop.openstack.org/#Keystone/Horizon_Collaboration_Meeting I'd like to keep up these meetings for the foreseea

[openstack-dev] [horizon][keystone] retiring python-keystoneclient-kerberos

Hi there, I would like to retire the python-keystoneclient-kerberos repo [1]. The repo was pretty basic, it had a single auth plugin. The logic has since been copied over to keystoneauth1 and provided you have kerberos libraries installed the plugin will be available to you. The last release of py

[openstack-dev] [Horizon][Keystone] Steps toward Kerberos and Federation

While the Keystone team has made pretty good strides toward Federation for getting a Keystone token, we do not yet have a complete story for Horizon. The same is true about Kerberos. I've been working on this, and I want to inform the people that are interested in the approach, as well as get

[openstack-dev] [horizon / keystone] Marker could not be found?

Hello Folks. I have a problem after grizzly->havana migration where i’m unable to rescue myself. When I open the "Admin -> Resource-Usage View i get no results – only a red error box with the message "Error: Unable to retrieve tenant list.“. Horizon log: [Thu Oct 31 11:39:44 2013] [error] Cre

Re: [openstack-dev] [Horizon][Keystone] Steps toward Kerberos and Federation

On Thu, 2014-09-04 at 17:37 -0400, Adam Young wrote: > While the Keystone team has made pretty good strides toward Federation > for getting a Keystone token, we do not yet have a complete story for > Horizon. The same is true about Kerberos. I've been working on this, > and I want to inform th

Re: [openstack-dev] [Horizon][Keystone] Steps toward Kerberos and Federation

Hi, I am wondering if the solution I was trying to sketch with the spec "https://review.openstack.org/#/c/96867/13"; is not easier to implement and manage then the steps highlated till n.2. Maybe, the spec is not yet there and should be improved (I will abandon or move to Kilo as Marek suggest) bu

Re: [openstack-dev] [Horizon][Keystone] Steps toward Kerberos and Federation

On 09/05/2014 04:49 AM, Marco Fargetta wrote: Hi, I am wondering if the solution I was trying to sketch with the spec "https://review.openstack.org/#/c/96867/13"; is not easier to implement and manage then the steps highlated till n.2. Maybe, the spec is not yet there and should be improved (I w

Re: [openstack-dev] [Horizon][Keystone] Steps toward Kerberos and Federation

I understand the general idea and the motivations but I am not sure about the implementation. Even with a SPA you still need to provide credentials and manage tokens for the authentication/authorisation in a way not too much different from the current implementation. Additionally, this might have

Re: [openstack-dev] [Horizon][Keystone] Steps toward Kerberos and Federation

On 09/05/2014 11:28 AM, Marco Fargetta wrote: I understand the general idea and the motivations but I am not sure about the implementation. Even with a SPA you still need to provide credentials and manage tokens for the authentication/authorisation in a way not too much different from the current

Re: [openstack-dev] [horizon / keystone] Marker could not be found?

On Thu, Oct 31, 2013 at 8:38 AM, Sebastian Porombka < porom...@uni-paderborn.de> wrote: > Hello Folks. > > I have a problem after grizzly->havana migration where i’m unable to > rescue myself. > When I open the "Admin -> Resource-Usage View i get no results – only a > red error box with the mes

Re: [openstack-dev] [horizon / keystone] Marker could not be found?

vironment before printing this email. Von: Dolph Mathews Antworten an: "OpenStack Development Mailing List (not for usage questions)" Datum: Donnerstag, 31. Oktober 2013 17:19 An: "OpenStack Development Mailing List (not for usage questions)" Betreff: Re: [openstack-dev] [horiz

Re: [openstack-dev] [horizon / keystone] Marker could not be found?

o: OpenStack Development Mailing List (not for usage questions) > Subject: Re: [openstack-dev] [horizon / keystone] Marker could not be > found? > > Hi > > I filed this under > https://bugs.launchpad.net/horizon/+bug/1247752 > > and commented out the the 'else&

[openstack-dev] [Horizon] [Keystone] Inaugural weekly cross-project meeting summary

Hi folks, Today we had the first of what will be a regular cross-project meeting series for Horizon and Keystone developers[1]. It was a very productive meeting, and we resolved to continue to keep our ongoing notes and status summaries in the etherpad[2] while still ensuring that BPs or bugs cov

[openstack-dev] [Horizon][Keystone] Weekly meeting log (2016/12/1)

Hi folks, The meeting bot disappeared during the meeting so the record is incomplete. The last 20 minutes are still in the channel log here: http://eavesdrop.openstack.org/irclogs/%23openstack-meeting-cp/%23openstack-meeting-cp.2016-12-01.log.html#t2016-12-01T20:42:08 Richard _

[openstack-dev] [horizon] [keystone] No Keystone-Horizon cross project meeting today

Hey everyone, Sorry for the late notice, but there will be no Horizon-Keystone cross project meeting this week, as we've little to discuss with the PTG so recent. The meeting will resume as normal next week. For those interested in joining, see http://eavesdrop.openstack.org/#Keystone/Horizon_

[openstack-dev] [Horizon] [Keystone] cross-project meeting Thursday 1st December 2000UTC

Hi folks, The next Keystone/Horizon cross-project meeting is this Thursday, 1st December at 2000UTC in #openstack-meeting-cp The agenda is https://etherpad.openstack.org/p/ocata-keystone-horizon Please update that document if you're working on one of the items. Richard __

[openstack-dev] [horizon][keystone] Getting Auth Token from Horizon when using Federation

Hi, we're deploying Liberty (soon Mitaka) with heavy reliance on the SAML2 Federation system by Keystone where we're a Service Provider (SP). The problem in this situation is getting a token for direct API access.(*) There are conceptually two methods to use the CLI: 1) Modify ones (each custom

[openstack-dev] [horizon] Keystone token expiration causes user to be logged out

Hi all, When a user is logged into Horizon and the Keystone token expires, I'm seeing that the user gets logged out, even though the web session hasn't expired. After some searching around and finding [1], it looks like this is expected, as the implementation of Session Extendable Tokens would

[openstack-dev] [Horizon][Keystone] No Horizon/Keystone cross-project meeting this week

Hi folks, Since so many key people are away on vacation, we'll skip this week's meeting (November 24th). Richard __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.

Re: [openstack-dev] [horizon][keystone] Getting Auth Token from Horizon when using Federation

On Mon, Apr 18, 2016 at 11:34 AM, Martin Millnert wrote: > Hi, > > we're deploying Liberty (soon Mitaka) with heavy reliance on the SAML2 > Federation system by Keystone where we're a Service Provider (SP). > > The problem in this situation is getting a token for direct API > access.(*) > > There

Re: [openstack-dev] [horizon][keystone] Getting Auth Token from Horizon when using Federation

On 04/18/2016 12:34 PM, Martin Millnert wrote: Hi, we're deploying Liberty (soon Mitaka) with heavy reliance on the SAML2 Federation system by Keystone where we're a Service Provider (SP). The problem in this situation is getting a token for direct API access.(*) There are conceptually two met

Re: [openstack-dev] [horizon][keystone] Getting Auth Token from Horizon when using Federation

On 04/18/2016 12:34 PM, Martin Millnert wrote: (** ECP is a new feature, not supported by all IdP's, that at (second) best requires reconfiguration of core authentication services at each customer, and at worst requires customers to change IdP software completely. This is a varying degree of show

Re: [openstack-dev] [horizon][keystone] Getting Auth Token from Horizon when using Federation

On Thu, Apr 21, 2016 at 10:22:46AM -0400, John Dennis wrote: > On 04/18/2016 12:34 PM, Martin Millnert wrote: > >(** ECP is a new feature, not supported by all IdP's, that at (second) > >best requires reconfiguration of core authentication services at each > >customer, and at worst requires custome

Re: [openstack-dev] [horizon][keystone] Getting Auth Token from Horizon when using Federation

Hi Dolph, On Mon, 2016-04-18 at 17:50 -0500, Dolph Mathews wrote: > > On Mon, Apr 18, 2016 at 11:34 AM, Martin Millnert > wrote: > Hi, > > we're deploying Liberty (soon Mitaka) with heavy reliance on > the SAML2 > Federation system by Keystone where we're

Re: [openstack-dev] [horizon][keystone] Getting Auth Token from Horizon when using Federation

27;s EC2 API to talk to a private cloud is strange to people not steeped in cloudy things.) From: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [horizon][keystone] Getting Auth Token from Horizon when using Federation Hi Dolph, On Mon, 2016-04-18 at 17:50 -0500, Dolph Mathew

Re: [openstack-dev] [horizon][keystone] Getting Auth Token from Horizon when using Federation

IO!). From: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [horizon][keystone] Getting Auth Token from Horizon when using Federation Hi Dolph, On Mon, 2016-04-18 at 17:50 -0500, Dolph Mathews wrote: > > On Mon, Apr 18, 2016 at 11:34 AM, Martin Millnert mail

Re: [openstack-dev] [horizon][keystone] Getting Auth Token from Horizon when using Federation

On Thu, May 12, 2016 at 8:10 AM Edmund Rhudy (BLOOMBERG/ 120 PARK) < erh...@bloomberg.net> wrote: > +1 on desiring OAuth-style tokens in Keystone. > OAuth 1.0a has been supported by keystone since the havana release, you just have to turn it on and use it: http://docs.openstack.org/developer/ke

Re: [openstack-dev] [horizon][keystone] Getting Auth Token from Horizon when using Federation

I flubbed my description of what I had in mind - I was thinking of GitHub personal access tokens as a model, _not_ OAuth tokens. I believe the normal excuse is "inadequate caffeine". From: dolph.math...@gmail.com Subject: Re: [openstack-dev] [horizon][keystone] Getting Auth Token fro

[openstack-dev] [Horizon][Keystone] Failed to set up keystone v3 api for horizon

is there anyone tryed this and successfully? On Mon, Mar 9, 2015 at 4:25 PM, Lei Zhang wrote: > Hi guys, > > I am setting up the keytone v3 api. Now I meet a issue about the > `cloud_admin` policy. > > Base on the > http://www.florentflament.com/blog/setting-keystone-v3-domains.html > article, I

Re: [openstack-dev] [horizon] Keystone token expiration causes user to be logged out

That is the expected behavior. Horizon does not support extendable session token. >From my understanding on that spec, it would require Horizon to store only the unscoped token and request for extension of that from keystone. Horizon is currently dependent on the project scoped token and store th

Re: [openstack-dev] [horizon] Keystone token expiration causes user to be logged out

On Tue, Apr 14, 2015 at 5:25 PM, Lin Hua Cheng wrote: > > That is the expected behavior. Horizon does not support extendable session > token. > > From my understanding on that spec, it would require Horizon to store only > the unscoped token and request for extension of that from keystone. > > Ho

Re: [openstack-dev] [Horizon][Keystone] Failed to set up keystone v3 api for horizon

Hi, The 'cloud_admin' policy file requires domain-scoped to work to work. Horizon does not currently support domain scope token yet. So yes, it is a gap in horizon at the moment. There are on-going patches to address this in horizon: - https://review.openstack.org/#/c/141153/ - https://review.op

Re: [openstack-dev] [Horizon][Keystone] Failed to set up keystone v3 api for horizon

Hi Lin, This two PS is what I wanted. Thx a lot. btw, is it possible that these PS finished in Kilo? On Thu, Mar 12, 2015 at 5:41 PM, Lin Hua Cheng wrote: > Hi, > > The 'cloud_admin' policy file requires domain-scoped to work to work. > > Horizon does not currently support domain scope token y

Re: [openstack-dev] [Horizon][Keystone] Failed to set up keystone v3 api for horizon

; OpenStack Development Mailing List Subject: [openstack-dev] [Horizon][Keystone] Failed to set up keystone v3 api for horizon is there anyone tryed this and successfully? On Mon, Mar 9, 2015 at 4:25 PM, Lei Zhang mailto:zhang.lei@gmail.com>> wrote: Hi guys, I am setting up the keyt

Re: [openstack-dev] [Horizon][Keystone] Failed to set up keystone v3 api for horizon

I'm sure additional feedback on those patches would be welcome and helpful toward getting them merged in Kilo > On Mar 12, 2015, at 9:14 AM, Lei Zhang wrote: > > Hi Lin, > > This two PS is what I wanted. Thx a lot. > > btw, is it possible that these PS finished in Kilo? > >> On Thu, Mar 12,

[openstack-dev] [horizon][keystone][heat] Are "AVAILABLE_REGIONS" and multi-region service catalog mutually exclusive?

I’m looking at implementing dynamically-configured multi-region support for service federation, and the prior art on multi-region support in Horizon is pretty sketchy. This thread: http://lists.openstack.org/pipermail/openstack/2014-January/004372.html is the only real discussion I’ve found, and

[openstack-dev] [horizon] [keystone] [docs] Two kinds of 'region' entity: finding better names for them

Hello, folks! Somehow it happened that we have 2 different kinds of regions: the service regions inside Keystone catalog and AVAILABLE_REGIONS setting inside Horizon, yet use the same name 'regions' for both of them. That creates a lot of confusion when solving some region-related issues at the Ho

Re: [openstack-dev] [horizon][keystone][heat] Are "AVAILABLE_REGIONS" and multi-region service catalog mutually exclusive?

Further digging suggests that we might consider deprecating AVAILABLE_REGIONS in Horizon and enhancing the multi-region support in Keystone. It wouldn’t take a lot; the main points: Implement the Regions API discussed back in the Havana time period - https://etherpad.openstack.org/p/havana-avail

Re: [openstack-dev] [horizon][keystone][heat] Are "AVAILABLE_REGIONS" and multi-region service catalog mutually exclusive?

When using AVAILABLE_REGIONS, you get a dropdown at login time to choose your "region" which is in fact "your keystone endpoint". Once logged in, you get a new dropdown at the top right to switch between the "keystone endpoints". This means you can configure an Horizon installation to login to mul

Re: [openstack-dev] [horizon][keystone][heat] Are "AVAILABLE_REGIONS" and multi-region service catalog mutually exclusive?

On Wed, May 13, 2015 at 3:24 PM, Mathieu Gagné wrote: > When using AVAILABLE_REGIONS, you get a dropdown at login time to choose > your "region" which is in fact "your keystone endpoint". > > Once logged in, you get a new dropdown at the top right to switch > between the "keystone endpoints". Thi

Re: [openstack-dev] [horizon][keystone][heat] Are "AVAILABLE_REGIONS" and multi-region service catalog mutually exclusive?

> On May 13, 2015, at 21:34, David Lyle wrote: > > >> On Wed, May 13, 2015 at 3:24 PM, Mathieu Gagné wrote: >> When using AVAILABLE_REGIONS, you get a dropdown at login time to choose >> your "region" which is in fact "your keystone endpoint". >> >> Once logged in, you get a new dropdown at

Re: [openstack-dev] [horizon][keystone][heat] Are "AVAILABLE_REGIONS" and multi-region service catalog mutually exclusive?

+1 There seems to be a significant disconnect between Heat, Horizon and Keystone on the subject of multi-region configurations, and the documentation isn’t helpful. At the very least, it would be useful if discussions at the summit could result in a decent Wiki page on the subject. Geoff > On

Re: [openstack-dev] [horizon][keystone][heat] Are "AVAILABLE_REGIONS" and multi-region service catalog mutually exclusive?

On Thu, May 14, 2015 at 9:39 AM, Geoff Arnold wrote: > +1 > > There seems to be a significant disconnect between Heat, Horizon and > Keystone on the subject of multi-region configurations, and the > documentation isn’t helpful. At the very least, it would be useful if > discussions at the summit

Re: [openstack-dev] [horizon][keystone][heat] Are "AVAILABLE_REGIONS" and multi-region service catalog mutually exclusive?

On 14/05/15 10:39, Geoff Arnold wrote: +1 There seems to be a significant disconnect between Heat, Horizon and Keystone on the subject of multi-region configurations, and the documentation isn’t helpful. At the very least, it would be useful if discussions at the summit could result in a decent

Re: [openstack-dev] [horizon][keystone][heat] Are "AVAILABLE_REGIONS" and multi-region service catalog mutually exclusive?

On Thursday, May 14, 2015, Anne Gentle wrote: > > > On Thu, May 14, 2015 at 9:39 AM, Geoff Arnold > wrote: > >> +1 >> >> There seems to be a significant disconnect between Heat, Horizon and >> Keystone on the subject of multi-region configurations, and the >> documentation isn’t helpful. At the

Re: [openstack-dev] [horizon][keystone][heat] Are "AVAILABLE_REGIONS" and multi-region service catalog mutually exclusive?

That’s interesting, because I wasn’t aware that “cloud” was part of the formal OpenStack taxonomy. Historically, we defined a region as a set of endpoints, supplied by an instance of Keystone. You seem to be saying that a cloud is a collection of regions configured in the same Keystone. [citati

Re: [openstack-dev] [horizon][keystone][heat] Are "AVAILABLE_REGIONS" and multi-region service catalog mutually exclusive?

+1 A wiki page laying out a mutually agreeable taxonomy seems like a good starting point. Geoff > On May 14, 2015, at 7:47 AM, Anne Gentle > wrote: > > > > On Thu, May 14, 2015 at 9:39 AM, Geoff Arnold > wrote: > +1 > > There seems to be a significant discon

Re: [openstack-dev] [horizon][keystone][heat] Are "AVAILABLE_REGIONS" and multi-region service catalog mutually exclusive?

OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [horizon][keystone][heat] Are "AVAILABLE_REGIONS" and multi-region service catalog mutually exclusive? That’s interesting, because I wasn’t aware that “cloud” was part of the formal

Re: [openstack-dev] [horizon][keystone][heat] Are "AVAILABLE_REGIONS" and multi-region service catalog mutually exclusive?

On 2015-05-14 12:34 AM, David Lyle wrote: > > Horizon only supports authenticating to one keystone endpoint at a time, > specifically to one of the entries in AVAILABLE_REGIONS as defined in > settings.py. Once you have an authenticated session in Horizon, the > region selection support is merely

Re: [openstack-dev] [horizon][keystone][heat] Are "AVAILABLE_REGIONS" and multi-region service catalog mutually exclusive?

If we don’t want to deprecate AVAILABLE_REGIONS, we certainly need to clean up the ambiguity. And to be honest, the existing documentation for both "multi-region” schemes (AVAILABLE_REGIONS and Keystone based) is completely inadequate. Geoff > On May 14, 2015, at 1:13 PM, Mathieu Gagné wrote

Re: [openstack-dev] [horizon][keystone][heat] Are "AVAILABLE_REGIONS" and multi-region service catalog mutually exclusive?

On 14/05/15 14:41, Geoff Arnold wrote: That’s interesting, because I wasn’t aware that “cloud” was part of the formal OpenStack taxonomy. Um, OK. AWS, Rackspace and Helion are all different clouds, even though the last two both run OpenStack. Do we really need a formal taxonomy for that? L

Re: [openstack-dev] [horizon][keystone][heat] Are "AVAILABLE_REGIONS" and multi-region service catalog mutually exclusive?

Anne Gentle wrote on 05/14/2015 09:47:25 AM: > From: Anne Gentle > To: "OpenStack Development Mailing List (not for usage questions)" > > Date: 05/14/2015 10:08 AM > Subject: Re: [openstack-dev] [horizon][keystone][heat] Are > "AVAILABLE_REGIONS" and

[openstack-dev] [horizon] [keystone] [requirements] [rpm-packaging] [deb-packaging] Merging Django OpenStack Auth with Horizon

Apologies in advance for so many tags, hoping this is seen by the appropriate people. I've put up a patch to merge Django OpenStack Auth (DOA) into the Horizon tree: https://review.openstack.org/#/c/482561/ There is a blueprint to track any further changes / issues here: https://blueprints.lau

Re: [openstack-dev] [horizon] [keystone] [docs] Two kinds of 'region' entity: finding better names for them

age questions\)" > > > > Date: 07/09/2015 01:17 PM > > Subject: Re: [openstack-dev] [horizon] [keystone] [docs] Two kinds > > of 'region' entity: finding better names for them > > > > Had the same issue when I worked on the context selection menu f

[openstack-dev] [Horizon][Keystone]Re: Keystone 'adminURL' option to fallback to 'internalURL' within Horizon api/keystone.py?

Hi Brian, Copying to the general list, as this is something I've wondered about, and others probably are as well. Please see below. I'm not an expert on this topic, but I've looked at it a little bit. On 4/7/16, 11:02 AM, "Tully, Brian" wrote: >Hi there - > >I'm reaching out to ask for some cl

Re: [openstack-dev] [horizon] [keystone] [docs] Two kinds of 'region' entity: finding better names for them

Timur Sufiev wrote on 07/08/2015 07:50:49 AM: > From: Timur Sufiev > To: "OpenStack Development Mailing List (not for usage questions)" > > Date: 07/08/2015 07:53 AM > Subject: [openstack-dev] [horizon] [keystone] [docs] Two kinds of > 'region' entity: f

Re: [openstack-dev] [horizon] [keystone] [docs] Two kinds of 'region' entity: finding better names for them

On 07/08/2015 08:50 AM, Timur Sufiev wrote: Hello, folks! Somehow it happened that we have 2 different kinds of regions: the service regions inside Keystone catalog and AVAILABLE_REGIONS setting inside Horizon, yet use the same name 'regions' for both of them. That creates a lot of confusion whe

Re: [openstack-dev] [horizon] [keystone] [docs] Two kinds of 'region' entity: finding better names for them

: From: Timur Sufiev To: "OpenStack Development Mailing List (not for usage questions)" Date: 07/08/2015 07:53 AM Subject: [openstack-dev] [horizon] [keystone] [docs] Two kinds of 'region' entity: finding better names for them Hello, folks! Somehow it happened that we have

Re: [openstack-dev] [horizon] [keystone] [docs] Two kinds of 'region' entity: finding better names for them

: [openstack-dev] [horizon] [keystone] [docs] Two kinds of 'region' entity: finding better names for them On 07/08/2015 08:50 AM, Timur Sufiev wrote: > Hello, folks! > > Somehow it happened that we have 2 different kinds of regions: the > service regions inside Keystone catalog and AVA

Re: [openstack-dev] [horizon] [keystone] [docs] Two kinds of 'region' entity: finding better names for them

Hi, Jay! As Doug said, Horizon regions are just different Keystone endpoints that Horizon could use to authorize against (and retrieve the whole catalog from any of them afterwards). Another example of how complicated things could be: imagine that Horizon config has two Keystone endpoints inside

Re: [openstack-dev] [horizon] [keystone] [docs] Two kinds of 'region' entity: finding better names for them

Got it, thanks for the excellent explanation, Timur! Yeah, I think renaming to AVAILABLE_KEYSTONE_ENDPOINTS would be a good solution. Best, -jay On 07/08/2015 09:53 AM, Timur Sufiev wrote: Hi, Jay! As Doug said, Horizon regions are just different Keystone endpoints that Horizon could use to a

Re: [openstack-dev] [horizon] [keystone] [docs] Two kinds of 'region' entity: finding better names for them

I have no issue changing the name of AVAILABLE_REGIONS to AVAILABLE_KEYSTONE_ENDPOINTS, however, the old setting will need to go through a deprecation cycle as this is a fundamental setting in Horizon. David On Wed, Jul 8, 2015 at 8:07 AM, Jay Pipes wrote: > Got it, thanks for the excellent exp

Re: [openstack-dev] [horizon] [keystone] [docs] Two kinds of 'region' entity: finding better names for them

Is it really worth it to change the name? I agree the old name is somewhat confusing but the new name is not perfectly clear either and will still require a several line comment to explain what it's trying to do. What could simply be done now is to improve the existing comment in the conf file as w

Re: [openstack-dev] [horizon] [keystone] [docs] Two kinds of 'region' entity: finding better names for them

Matt, I don't think it's a bike-shedding. The problem is not the existing name being a bit obscure - until I hit some issues with Keystone native regions I didn't have any troubles with it. The problem is that we have the _same_ name for different things, and no additional comments will remedy the

Re: [openstack-dev] [horizon] [keystone] [docs] Two kinds of 'region' entity: finding better names for them

would have to be done manually.-Jay Pipes wrote: -To: openstack-dev@lists.openstack.orgFrom: Jay Pipes Date: 07/08/2015 07:14AMSubject: Re: [openstack-dev] [horizon] [keystone] [docs] Two kinds of 'region' entity: finding better names for themGot it, thanks for the excellent e

Re: [openstack-dev] [horizon] [keystone] [docs] Two kinds of 'region' entity: finding better names for them

> Date: 07/09/2015 01:17 PM > Subject: Re: [openstack-dev] [horizon] [keystone] [docs] Two kinds > of 'region' entity: finding better names for them > > Had the same issue when I worked on the context selection menu for > switching domain and project. I think it make sense

Re: [openstack-dev] [Horizon][Keystone]Re: Keystone 'adminURL' option to fallback to 'internalURL' within Horizon api/keystone.py?

Hi, I think Brad's spot on. See inline, but short version - the special case is only required if the KS catalog returns v2.0 endpoints. On 4/7/16, 1:39 PM, "Brad Pokorny" wrote: >Hi Brian, > >Copying to the general list, as this is something I've wondered about, and >others probably are as well

Re: [openstack-dev] [Horizon][Keystone]Re: Keystone 'adminURL' option to fallback to 'internalURL' within Horizon api/keystone.py?

You can use the public URL as a fallback to the internal URL; however, the admin URL is assumed to be the only privileged API endpoint. The details are buried in API documentation (and perhaps history), but I tried to summarize the intended design here as I understand it: http://dolphm.com/open

[openstack-dev] [horizon] [keystone] [federated auth] [ocata] federated users with "admin" role not authorized for nova, cinder, neutron admin panels

I am on Ocata with Shibboleth auth enabled. I noticed that Federated users with the admin role no longer have authorization to use the Admin** panels in Horizon related to Nova, Cinder and Neutron. All regular Identity and Project tabs function, and there are no problems with authorization for loca

Re: [openstack-dev] [horizon] [keystone] [federated auth] [ocata] federated users with "admin" role not authorized for nova, cinder, neutron admin panels

Hi, Please paste your mapping to paste.openstack.org On 03/09/2017 02:07 AM, Evan Bollig PhD wrote: > I am on Ocata with Shibboleth auth enabled. I noticed that Federated > users with the admin role no longer have authorization to use the > Admin** panels in Horizon related to Nova, Cinder and Ne

Re: [openstack-dev] [horizon] [keystone] [federated auth] [ocata] federated users with "admin" role not authorized for nova, cinder, neutron admin panels

Hey Boris, Which mapping? Hope you were looking for the shibboleth user mapping. Also, hope this is the right way to share the paste (first time using this): http://paste.openstack.org/show/3snCb31GRZfAuQxdRouy/ Cheers, -E -- Evan F. Bollig, PhD Scientific Computing Consultant, Application Develo

  1   2   >