On Tue, Oct 21, 2014 at 8:34 AM, Jamie Lennox
wrote:
> The only reason is that I didn't want to introduce a global variable cache
> in a library. The session should be a fairly long running object and i'm
> looking at ways we could serialize it to allow horizon/CLIs to manage it
> themselves.
>
>
- Original Message -
> From: "Dolph Mathews"
> To: "OpenStack Development Mailing List (not for usage questions)"
>
> Sent: Monday, October 20, 2014 4:38:25 PM
> Subject: Re: [openstack-dev] Horizon and Keystone: API Versions and Discovery
>
ent: Tuesday, October 7, 2014 6:56:15 PM
> > Subject: Re: [openstack-dev] Horizon and Keystone: API Versions and
> Discovery
> >
> >
> >
> > On Tuesday, October 7, 2014, Adam Young < ayo...@redhat.com > wrote:
> >
> >
> > Horizon has a config options wh
- Original Message -
> From: "Dolph Mathews"
> To: "OpenStack Development Mailing List (not for usage questions)"
>
> Sent: Tuesday, October 7, 2014 6:56:15 PM
> Subject: Re: [openstack-dev] Horizon and Keystone: API Versions and Discovery
>
>
On Tuesday, October 7, 2014, Adam Young wrote:
> Horizon has a config options which says which version of the Keystone API
> it should work against: V2 or V3. I am not certain that there is still
> any reason for Horizon to go against V2. However, If we defer the decision
> to Keystone, we come
Horizon has a config options which says which version of the Keystone
API it should work against: V2 or V3. I am not certain that there is
still any reason for Horizon to go against V2. However, If we defer the
decision to Keystone, we come up against the problem of discovery.
On the surface
