<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 08/06/2015 07:09 PM, Dolph Mathews
wrote:<br>
</div>
<blockquote
cite="mid:CAC=h7gVFuNfSpPWTAUd+rnyj4FoVa2E9-qTXpApEeGxsygFTfQ@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra"><br>
<div class="gmail_quote">On Thu, Aug 6, 2015 at 11:25 AM,
Lance Bragstad <span dir="ltr"><<a
moz-do-not-send="true" href="mailto:lbragstad@gmail.com"
target="_blank">lbragstad@gmail.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><br>
<div class="gmail_extra"><br>
<div class="gmail_quote"><span class="">On Thu, Aug 6,
2015 at 10:47 AM, Dolph Mathews <span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:dolph.mathews@gmail.com"
target="_blank">dolph.mathews@gmail.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0
0 .8ex;border-left:1px #ccc
solid;padding-left:1ex">
<div dir="ltr">
<div class="gmail_extra"><br>
<div class="gmail_quote"><span>On Wed, Aug
5, 2015 at 6:54 PM, Jamie Lennox <span
dir="ltr"><<a
moz-do-not-send="true"
href="mailto:jamielennox@redhat.com"
target="_blank">jamielennox@redhat.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote"
style="margin:0 0 0
.8ex;border-left:1px #ccc
solid;padding-left:1ex"><span><br>
<br>
----- Original Message -----<br>
> From: "David Lyle" <<a
moz-do-not-send="true"
href="mailto:dklyle0@gmail.com"
target="_blank">dklyle0@gmail.com</a>><br>
> To: "OpenStack Development
Mailing List (not for usage
questions)" <<a
moz-do-not-send="true"
href="mailto:openstack-dev@lists.openstack.org"
target="_blank">openstack-dev@lists.openstack.org</a>><br>
</span><span>> Sent: Thursday,
August 6, 2015 5:52:40 AM<br>
> Subject: Re: [openstack-dev]
[Keystone] [Horizon] Federated Login<br>
><br>
</span><span>> Forcing Horizon to
duplicate Keystone settings just
makes everything much<br>
> harder to configure and much
more fragile. Exposing whitelisted,
or all,<br>
> IdPs makes much more sense.<br>
><br>
> On Wed, Aug 5, 2015 at 1:33 PM,
Dolph Mathews < <a
moz-do-not-send="true"
href="mailto:dolph.mathews@gmail.com"
target="_blank">dolph.mathews@gmail.com</a>
><br>
> wrote:<br>
><br>
><br>
><br>
> On Wed, Aug 5, 2015 at 1:02 PM,
Steve Martinelli < <a
moz-do-not-send="true"
href="mailto:stevemar@ca.ibm.com"
target="_blank">stevemar@ca.ibm.com</a>
><br>
> wrote:<br>
><br>
><br>
><br>
><br>
><br>
> Some folks said that they'd
prefer not to list all associated
idps, which i<br>
> can understand.<br>
> Why?<br>
<br>
</span>So the case i heard and i think
is fairly reasonable is providing
corporate logins to a public cloud.
Taking the canonical coke/pepsi
example if i'm coke, i get asked to
login to this public cloud i then have
to scroll though all the providers to
find the <a moz-do-not-send="true"
href="http://COKE.COM"
rel="noreferrer" target="_blank">COKE.COM</a>
domain and i can see for example that
<a moz-do-not-send="true"
href="http://PEPSI.COM"
rel="noreferrer" target="_blank">PEPSI.COM</a>
is also providing logins to this
cloud. Ignoring the corporate privacy
implications this list has the
potential to get long. Think about for
example how you can do a corporate
login to gmail, you certainly don't
pick from a list of auth providers for
gmail - there would be thousands.<br>
<br>
My understanding of the usage then
would be that coke would have been
provided a (possibly branded)
dedicated horizon that backed onto a
public cloud and that i could then
from horizon say that it's only
allowed access to the <a
moz-do-not-send="true"
href="http://COKE.COM"
rel="noreferrer" target="_blank">COKE.COM</a>
domain (because the UX for inputting a
domain at login is not great so per
customer dashboards i think make
sense) and that for this instance of
horizon i want to show the 3 or 4
login providers that <a
moz-do-not-send="true"
href="http://COKE.COM"
rel="noreferrer" target="_blank">COKE.COM</a>
is going to allow.<br>
<br>
Anyway you want to list or whitelist
that in keystone is going to involve
some form of IdP tagging system where
we have to say which set of idps we
want in this case and i don't think we
should.<br>
</blockquote>
<div><br>
</div>
</span>
<div>That all makes sense, and I was
admittedly only thinking of the private
cloud use case. So, I'd like to discuss
the public and private use cases
separately:</div>
<div><br>
</div>
<div>In a public cloud, is there a real
use case for revealing *any* IdPs
publicly? If not, the entire list should
be made "private" using policy.json,
which we already support today.</div>
</div>
</div>
</div>
</blockquote>
<div><br>
</div>
</span>
<div>The user would be required to know the id of
the IdP in which they want to federate with,
right? </div>
<div>
<div class="h5">
<div> </div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>As a federated end user in a public cloud, I'd be happy
to have a custom URL / bookmark for my IdP / domain (like
<a moz-do-not-send="true"
href="http://customer-x.cloud.example.com/">http://customer-x.cloud.example.com/</a>
or <a moz-do-not-send="true"
href="http://cloud.example.com/customer-x">http://cloud.example.com/customer-x</a>)
that I need to know to kickoff the correct federated
handshake with my IdP using a single button press
("Login").</div>
</div>
</div>
</div>
</blockquote>
<br>
<br>
Are we going about this backwards? Wouldn't it make more sense to
tell a new customer:<br>
<br>
you get <a class="moz-txt-link-freetext" href="https://coke.cloudprovider.net">https://coke.cloudprovider.net</a><br>
<br>
And have that hard coded to a UI.<br>
<br>
For larger organizations, I suspect it would make more sense that
the UI should be owned by Coke, and run on a server managed by Coke,
and talk to multiple OpenStack instances. <br>
<br>
The UI should not be Provider specific, but consumer specific.<br>
<br>
<br>
<br>
<br>
<blockquote
cite="mid:CAC=h7gVFuNfSpPWTAUd+rnyj4FoVa2E9-qTXpApEeGxsygFTfQ@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div>
<div class="h5">
<blockquote class="gmail_quote" style="margin:0
0 0 .8ex;border-left:1px #ccc
solid;padding-left:1ex">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div><br>
In a private cloud, is there a real
use case for fine-grained
public/private attributes per IdP?
(The stated use case was for a public
cloud.) It seems the default behavior
should be that horizon fetches the
entire list from keystone.</div>
<div>
<div>
<div> </div>
<blockquote class="gmail_quote"
style="margin:0 0 0
.8ex;border-left:1px #ccc
solid;padding-left:1ex">
<br>
@David - when you add a new IdP to
the university network are you
having to provide a new mapping
each time? I know the CERN answer
to this with websso was to
essentially group many IdPs behind
the same keystone idp because they
will all produce the same
assertion values and consume the
same mapping.<br>
<br>
Maybe the answer here is to
provide the option in
django_openstack_auth, a plugin
(again) of fetch from keystone,
fixed list in settings or let it
point at a custom text file/url
that is maintained by the
deployer. Honestly if you're
adding and removing idps this
frequently i don't mind making the
deployer maintain some of this
information out of scope of
keystone.<br>
<br>
<br>
Jamie<br>
<span><br>
><br>
><br>
><br>
><br>
><br>
> Actually, I like jamie's
suggestion of just making
horizon a bit smarter, and<br>
> expecting the values in the
horizon settings (idp+protocol)<br>
> But, it's already in
keystone.<br>
><br>
><br>
><br>
><br>
><br>
><br>
><br>
> Thanks,<br>
><br>
> Steve Martinelli<br>
> OpenStack Keystone Core<br>
><br>
</span><span>> Dolph Mathews
---2015/08/05 01:38:09 PM---On
Wed, Aug 5, 2015 at 5:39 AM,<br>
> David Chadwick < <a
moz-do-not-send="true"
href="mailto:d.w.chadwick@kent.ac.uk"
target="_blank">d.w.chadwick@kent.ac.uk</a>
> wrote:<br>
><br>
> From: Dolph Mathews < <a
moz-do-not-send="true"
href="mailto:dolph.mathews@gmail.com"
target="_blank">dolph.mathews@gmail.com</a>
><br>
> To: "OpenStack Development
Mailing List (not for usage
questions)" <<br>
> <a moz-do-not-send="true"
href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.openstack.org</a>
><br>
> Date: 2015/08/05 01:38 PM<br>
> Subject: Re:
[openstack-dev] [Keystone]
[Horizon] Federated Login<br>
><br>
><br>
><br>
><br>
><br>
</span>
<div>
<div>> On Wed, Aug 5, 2015 at
5:39 AM, David Chadwick < <a
moz-do-not-send="true"
href="mailto:d.w.chadwick@kent.ac.uk"
target="_blank">d.w.chadwick@kent.ac.uk</a>
><br>
> wrote:<br>
><br>
> On 04/08/2015 18:59,
Steve Martinelli wrote: >
Right, but that API is/should<br>
> be protected. If we want
to list IdPs > *before*
authenticating a user, we<br>
> either need: 1) a new API
for listing > public IdPs
or 2) a new policy that<br>
> doesn't protect that API.
Hi Steve yes this was my
understanding of the<br>
> discussion that took
place many months ago. I had
assumed (wrongly) that<br>
> something had been done
about it, but I guess from
your message that we are<br>
> no further forward on
this Actually 2) above might
be better reworded as - a<br>
> new policy/engine that
allows public access to be a
bona fide policy rule<br>
> The existing policy
simply seems wrong. Why
protect the list of IdPs?<br>
><br>
><br>
> regards David > >
Thanks, > > Steve
Martinelli > OpenStack
Keystone Core > ><br>
> Inactive hide details for
Lance Bragstad ---2015/08/04
01:49:29 PM---On ><br>
> Tue, Aug 4, 2015 at 10:52
AM, Douglas Fish
<a class="moz-txt-link-rfc2396E" href="mailto:drfish@us.iLanceBragstad"><drfish@us.iLance Bragstad
></a><br>
> ---2015/08/04 01:49:29
PM---On Tue, Aug 4, 2015 at
10:52 AM, Douglas > Fish<br>
> < <a
moz-do-not-send="true"
href="mailto:drfish@us.ibm.com"
target="_blank">drfish@us.ibm.com</a>
> wrote: > Hi David,
> > From: Lance Bragstad
<<br>
> <a
moz-do-not-send="true"
href="mailto:lbragstad@gmail.com"
target="_blank">lbragstad@gmail.com</a>
> > To: "OpenStack
Development Mailing List (not
for<br>
> usage questions)" >
< <a
moz-do-not-send="true"
href="mailto:openstack-dev@lists.openstack.org"
target="_blank">openstack-dev@lists.openstack.org</a>
> > Date: 2015/08/04<br>
> 01:49 PM > Subject:
Re: [openstack-dev] [Keystone]
[Horizon] Federated Login<br>
> > >
------------------------------------------------------------------------<br>
> > > > > >
> On Tue, Aug 4, 2015 at
10:52 AM, Douglas Fish<br>
> <a class="moz-txt-link-rfc2396E" href="mailto:_drfish@us.ibm.com_"><_drfish@us.ibm.com_
></a> <mailto: <a
moz-do-not-send="true"
href="mailto:drfish@us.ibm.com"
target="_blank">drfish@us.ibm.com</a>
>> wrote: > > Hi
David, ><br>
> > This is a cool
looking UI. I've made a minor
comment on it in InVision.
><br>
> > I'm curious if this
is an implementable idea -
does keystone support ><br>
> large > numbers of 3rd
party idps? is there an API to
retreive the list of ><br>
> idps or > does this
require carefully coordinated
configuration between ><br>
> Horizon and > Keystone
so they both recognize the
same list of idps? > >
><br>
> There is an API call for
getting a list of Identity
Providers from Keystone<br>
> > > _<br>
> <a
moz-do-not-send="true"
href="http://specs.openstack.org/openstack/keystone-specs/api/v3/identity-api-v3-os-federation-ext.html#list-identity-providers_"
rel="noreferrer"
target="_blank">http://specs.openstack.org/openstack/keystone-specs/api/v3/identity-api-v3-os-federation-ext.html#list-identity-providers_</a><br>
> > > > > Doug
Fish > > > David
Chadwick
<a class="moz-txt-link-rfc2396E" href="mailto:_d.w.chadwick@kent.ac.uk_"><_d.w.chadwick@kent.ac.uk_
></a> <mailto:<br>
> <a
moz-do-not-send="true"
href="mailto:d.w.chadwick@kent.ac.uk"
target="_blank">d.w.chadwick@kent.ac.uk</a>
>> wrote on 08/01/2015
06:01:48 AM: > > >
From:<br>
> David Chadwick
<a class="moz-txt-link-rfc2396E" href="mailto:_d.w.chadwick@kent.ac.uk_"><_d.w.chadwick@kent.ac.uk_
></a> <mailto: <a
moz-do-not-send="true"
href="mailto:d.w.chadwick@kent.ac.uk"
target="_blank">d.w.chadwick@kent.ac.uk</a><br>
> >> > > To:
OpenStack Development Mailing
List ><br>
>
<a class="moz-txt-link-rfc2396E" href="mailto:_openstack-dev@lists.openstack.org_"><_openstack-dev@lists.openstack.org_
></a> <mailto:<br>
> <a
moz-do-not-send="true"
href="mailto:openstack-dev@lists.openstack.org"
target="_blank">openstack-dev@lists.openstack.org</a>
>> > > Date:
08/01/2015 06:05 AM > ><br>
> Subject: [openstack-dev]
[Keystone] [Horizon] Federated
Login > > > > Hi<br>
> Everyone > > >
> I have a student building
a GUI for federated login with<br>
> Horizon. The > >
interface supports both a drop
down list of configured<br>
> IDPs, and also > >
Type Ahead for massive
federations with hundreds of
IdPs.<br>
> Screenshots > > are
visible in InVision here >
> > > _<br>
> <a
moz-do-not-send="true"
href="https://invis.io/HQ3QN2123_"
rel="noreferrer"
target="_blank">https://invis.io/HQ3QN2123_</a>
> > > > All
comments on the design are<br>
> appreciated. You can make
them directly > > to the
screens via InVision > ><br>
> > > Regards >
> > > David > >
> > > > > >
><br>
>
__________________________________________________________________________
><br>
> > OpenStack
Development Mailing List (not
for usage questions) > ><br>
> Unsubscribe:_ > __<br>
</div>
</div>
<span>> <a
moz-do-not-send="true"
href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe_"
rel="noreferrer"
target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe_</a>
> <<br>
> <a moz-do-not-send="true"
href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe"
rel="noreferrer"
target="_blank">http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a>
> > > _<br>
> <a moz-do-not-send="true"
href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev_"
rel="noreferrer"
target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev_</a>
> > > > ><br>
>
__________________________________________________________________________
><br>
> OpenStack Development
Mailing List (not for usage
questions) > Unsubscribe:<br>
</span>> > _ <a
moz-do-not-send="true"
href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe_"
rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe_</a>
> <<br>
<div>
<div>> <a
moz-do-not-send="true"
href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe"
rel="noreferrer"
target="_blank">http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a>
>_ > __<br>
> <a
moz-do-not-send="true"
href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev_"
rel="noreferrer"
target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev_</a>
> ><br>
>
__________________________________________________________________________
><br>
> OpenStack Development
Mailing List (not for usage
questions) > Unsubscribe:<br>
> <a
moz-do-not-send="true"
href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe"
rel="noreferrer"
target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a>
><br>
> <a
moz-do-not-send="true"
href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"
rel="noreferrer"
target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
> > > > ><br>
>
__________________________________________________________________________
><br>
> OpenStack Development
Mailing List (not for usage
questions) > Unsubscribe:<br>
> <a
moz-do-not-send="true"
href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe"
rel="noreferrer"
target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a>
><br>
> <a
moz-do-not-send="true"
href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"
rel="noreferrer"
target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
><br>
>
__________________________________________________________________________<br>
> OpenStack Development
Mailing List (not for usage
questions) Unsubscribe:<br>
> <a
moz-do-not-send="true"
href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe"
rel="noreferrer"
target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
> <a
moz-do-not-send="true"
href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"
rel="noreferrer"
target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>
__________________________________________________________________________<br>
> OpenStack Development
Mailing List (not for usage
questions)<br>
> Unsubscribe: <a
moz-do-not-send="true"
href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe"
rel="noreferrer"
target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
> <a
moz-do-not-send="true"
href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"
rel="noreferrer"
target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
><br>
><br>
><br>
><br>
><br>
>
__________________________________________________________________________<br>
> OpenStack Development
Mailing List (not for usage
questions)<br>
> Unsubscribe: <a
moz-do-not-send="true"
href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe"
rel="noreferrer"
target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
> <a
moz-do-not-send="true"
href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"
rel="noreferrer"
target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
><br>
><br>
>
__________________________________________________________________________<br>
> OpenStack Development
Mailing List (not for usage
questions)<br>
> Unsubscribe: <a
moz-do-not-send="true"
href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe"
rel="noreferrer"
target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
> <a
moz-do-not-send="true"
href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"
rel="noreferrer"
target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
><br>
><br>
>
__________________________________________________________________________<br>
> OpenStack Development
Mailing List (not for usage
questions)<br>
> Unsubscribe: <a
moz-do-not-send="true"
href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe"
rel="noreferrer"
target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
> <a
moz-do-not-send="true"
href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"
rel="noreferrer"
target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing
List (not for usage questions)<br>
Unsubscribe: <a
moz-do-not-send="true"
href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe"
rel="noreferrer"
target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a moz-do-not-send="true"
href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"
rel="noreferrer"
target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div>
</div>
</blockquote>
</div>
</div>
</div>
<br>
</div>
</div>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for
usage questions)<br>
Unsubscribe: <a moz-do-not-send="true"
href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe"
rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a moz-do-not-send="true"
href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"
rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
</blockquote>
</div>
</div>
</div>
<br>
</div>
</div>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage
questions)<br>
Unsubscribe: <a moz-do-not-send="true"
href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe"
rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a moz-do-not-send="true"
href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"
rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
</blockquote>
</div>
<br>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: <a class="moz-txt-link-abbreviated" href="mailto:OpenStack-dev-request@lists.openstack.org?subject:unsubscribe">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a>
<a class="moz-txt-link-freetext" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
</pre>
</blockquote>
<br>
</body>
</html>