<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jun 5, 2015 at 11:50 AM, Henry Nash <span dir="ltr"><<a href="mailto:henry.nash@uk.ibm.com" target="_blank">henry.nash@uk.ibm.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><font size="2" face="sans-serif">So I think that GroupID's are actually
unique and safe....since in the multi LDAP case we provide an indirection
already in Keystone and issue a "Public ID" (this is true for
bother users and groups), that we map to the underlying local ID in the
particular LDAP backend.</font></blockquote><div><br></div><div>Oh, awesome! I didn't realize we did that for groups as well. So then, we're safe exposing X-Group-Ids to services via keystonemiddleware.auth_token but still not X-Group-Names (in any trivial form).</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<br><font size="2" face="sans-serif">Henry</font>
<br>
<br>
<br>
<table width="100%" style="border-collapse:collapse">
<tbody><tr valign="top" height="8">
<td width="96" style="border-style:none none none none;border-color:#000000;border-width:0px 0px 0px 0px;padding:0px 0px"><font size="1" color="#5f5f5f" face="sans-serif">From:</font>
</td><td style="border-style:none none none none;border-color:#000000;border-width:0px 0px 0px 0px;padding:0px 0px"><font size="1" face="sans-serif">Dolph
Mathews <<a href="mailto:dolph.mathews@gmail.com" target="_blank">dolph.mathews@gmail.com</a>></font>
</td></tr><tr valign="top" height="8">
<td width="96" style="border-style:none none none none;border-color:#000000;border-width:0px 0px 0px 0px;padding:0px 0px"><font size="1" color="#5f5f5f" face="sans-serif">To:</font>
</td><td style="border-style:none none none none;border-color:#000000;border-width:0px 0px 0px 0px;padding:0px 0px"><font size="1" face="sans-serif">"OpenStack
Development Mailing List (not for usage questions)" <<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.openstack.org</a>>,
Henry Nash <<a href="mailto:henryn@linux.vnet.ibm.com" target="_blank">henryn@linux.vnet.ibm.com</a>>, Henry Nash/UK/IBM@IBMGB</font>
</td></tr><tr valign="top" height="8">
<td width="96" style="border-style:none none none none;border-color:#000000;border-width:0px 0px 0px 0px;padding:0px 0px"><font size="1" color="#5f5f5f" face="sans-serif">Date:</font>
</td><td style="border-style:none none none none;border-color:#000000;border-width:0px 0px 0px 0px;padding:0px 0px"><font size="1" face="sans-serif">05/06/2015
15:38</font>
</td></tr><tr valign="top" height="8">
<td width="96" style="border-style:none none none none;border-color:#000000;border-width:0px 0px 0px 0px;padding:0px 0px"><font size="1" color="#5f5f5f" face="sans-serif">Subject:</font>
</td><td style="border-style:none none none none;border-color:#000000;border-width:0px 0px 0px 0px;padding:0px 0px"><font size="1" face="sans-serif">Re:
[openstack-dev] [keystone][barbican] Regarding exposing X-Group-xxxx in
token validation</font></td></tr></tbody></table><div><div class="h5">
<br>
<hr noshade>
<br>
<br>
<br>
<br><font size="3">On Thu, Jun 4, 2015 at 10:17 PM, John Wood <</font><a href="mailto:john.wood@rackspace.com" target="_blank"><font size="3" color="blue"><u>john.wood@rackspace.com</u></font></a><font size="3">>
wrote:</font>
<br><font size="2" color="blue" face="Calibri">Hello folks,</font>
<br>
<br><font size="2" color="blue" face="Calibri">Regarding option C, if group
IDs are unique within a given cloud/context, and these are discoverable
by clients that can then set the ACL on a secret in Barbican, then that
seems like a viable option to me. As it is now, the user information provided
to the ACL is the user ID information as found in X-User-Ids now, not user
names. </font>
<br>
<br><font size="2" color="blue" face="Calibri">To Kevin’s point though, are
these group IDs unique across domains now, or in the future? If not the
more complex tuples suggested could be used, but seem more error prone
to configure on an ACL.</font>
<br>
<br><font size="3">Well, that's a good question, because that depends on
the backend, and our backend architecture has recently gotten very complicated
in this area.</font>
<br>
<br><font size="3">If groups are backed by SQL, then they're going to be
globally unique UUIDs, so the answer is always yes.</font>
<br>
<br><font size="3">If they're backed by LDAP, then actually it depends on
LDAP, but the answer should be yes.</font>
<br>
<br><font size="3">But the nightmare scenario we now support is domain-specific
identity drivers, where each domain can actually be configured to talk
to a different LDAP server. In that case, I don't think you can make any
guarantees about group ID uniqueness :( Instead, each domain could provide
whatever IDs it wants, and those might conflict with those of other domains.
We have a workaround for a similar issue with user IDs, but it hasn't been
applied to groups, leaving them quite broken in this scenario. I'd consider
this to be an issue we need to solve in Keystone, though, not something
other projects need to worry about. I'm hoping Henry Nash can chime in
and correct me!</font>
<br><font size="3"> </font>
<br>
<br><font size="2" color="blue" face="Calibri">Thanks,</font>
<br><font size="2" color="blue" face="Calibri">John</font>
<br>
<br><font size="2" face="Calibri"><b>From: </b><Fox>, Kevin M <</font><a href="mailto:Kevin.Fox@pnnl.gov" target="_blank"><font size="2" color="blue" face="Calibri"><u>Kevin.Fox@pnnl.gov</u></font></a><font size="2" face="Calibri">><b><br>
Reply-To: </b>"OpenStack Development Mailing List (not for usage questions)"
<</font><a href="mailto:openstack-dev@lists.openstack.org" target="_blank"><font size="2" color="blue" face="Calibri"><u>openstack-dev@lists.openstack.org</u></font></a><font size="2" face="Calibri">><b><br>
Date: </b>Thursday, June 4, 2015 at 6:01 PM<b><br>
To: </b>"OpenStack Development Mailing List (not for usage questions)"
<</font><a href="mailto:openstack-dev@lists.openstack.org" target="_blank"><font size="2" color="blue" face="Calibri"><u>openstack-dev@lists.openstack.org</u></font></a><font size="2" face="Calibri">></font>
<br><font size="2" face="Calibri"><b><br>
Subject: </b>Re: [openstack-dev] [keystone][barbican] Regarding exposing
X-Group-xxxx in token validation</font>
<br>
<br><font size="2" face="Tahoma">In Juno I tried adding a user in Domain
A to group in Domain B. That currently is not supported. Would be very
handy though.<br>
<br>
We're getting a ways from the original part of the thread, so I may have
lost some context, but I think the original question was, if barbarian
can add group names to their resource acls.<br>
<br>
Since two administrative domains can issue the same group name, its not
safe I believe.<br>
<br>
Simply ensuring the group name is associated with a user and the domain
for the user matches the domain for the group wouldn't work because someone
with control of their own domain can just make a <br>
user and give them the group with the name they want and come take your
credentials.<br>
<br>
What may be safe is for the barbican ACL to contain the group_id if they
are uniqueue across all domains, or take a domain_id & group_name pair
for the acl.<br>
<br>
Thanks,<br>
Kevin<br>
</font>
<br>
<hr>
<br><font size="2" face="Tahoma"><b>From:</b> Dolph Mathews [</font><a href="mailto:dolph.mathews@gmail.com" target="_blank"><font size="2" color="blue" face="Tahoma"><u>dolph.mathews@gmail.com</u></font></a><font size="2" face="Tahoma">]<b><br>
Sent:</b> Thursday, June 04, 2015 1:41 PM<b><br>
To:</b> OpenStack Development Mailing List (not for usage questions)<b><br>
Subject:</b> Re: [openstack-dev] [keystone][barbican] Regarding exposing
X-Group-xxxx in token validation</font><font size="3" face="Times"><br>
</font>
<br><font size="3" face="Times">Problem! In writing a spec for this
( </font><a href="https://review.openstack.org/#/c/188564/" target="_blank"><font size="3" color="blue" face="Times"><u>https://review.openstack.org/#/c/188564/</u></font></a><font size="3" face="Times">
), I remembered that groups are domain-specific entities, which complicates
the problem of providing X-Group-Names via middleware. </font>
<br>
<br><font size="3" face="Times">The problem is that we can't simply expose
X-Group-Names to underlying services without either A) making a well-documented
assumption about the ONE owning domain scope of ALL included groups, B)
passing significantly more data to underlying services than just a list
of names (a domain scope for every group), C) passing only globally-unique
group IDs (services would then have to retrieve additional details about
each from from keystone if they so cared).</font>
<br>
<br><font size="3" face="Times">Option A) More specifically, keystone could
opt to enumerate the groups that belong to the same domain as the user.
In this case, it'd probably make more sense from an API perspective if
the "groups" enumeration were part of the "user" resources
in the token response body (the "user" object already has a containing
domain ID. That means that IF a user were to be assigned a group membership
in another domain (assuming we didn't move to disallowing that behavior
at some point), then it would have to be excluded from this list. If that
were true, then I'd also follow that X-Group-Names become X-User-Group-Names,
so that it might be more clear that they belong to the X-User-Domain-*.</font>
<br>
<br><font size="3" face="Times">Option B) This is probably the most complex
solution, but also the most explicit. I have no idea how this interface
would look in terms of headers using current conventions. If we're going
to break conventions, then I'd want to pass a id+domain_id+name for each
group reference. So, rather than including a list of names AND a list of
IDs, we'd have some terribly encoded list of group objects (I'm not sure
what the HTTP convention is on this sort of use case, and hoping someone
can illustrate a better solution given the representation below):</font>
<br>
<br><font size="3" face="Times"> X-Groups: id%3D123%2Cdomain_id%3D456%2Cname%3Dabc,id%3D789%2Cdomain_id%3D357%2Cname%3Ddef</font>
<br>
<br><font size="3" face="Times">Option C) Federated tokens would actually
require solution (C) today because they only include group IDs, not names.
But the group enumeration in federated tokens was also only intended to
be consumed by keystone, so that's not really an issue for that one use
case. But option (C) would mean there are no X-Group-Names passed to services,
just X-Group-Ids. I'm guessing this won't provide the user experience that
Barbican is looking for?</font>
<br>
<br>
<br><font size="3" face="Times">I'm leaning towards solution (A), but curious
if that'll work for Barbican and/or if anyone has an idea that I'm overlooking.</font>
<br>
<br>
<br><font size="3" face="Times">On Thu, Jun 4, 2015 at 8:18 AM, Dolph Mathews
<</font><a href="mailto:dolph.mathews@gmail.com" target="_blank"><font size="3" color="blue" face="Times"><u>dolph.mathews@gmail.com</u></font></a><font size="3" face="Times">>
wrote:</font>
<br><font size="3" face="Times">To clarify: we already have to include the
groups produced as a result of federation mapping **in the payload** of
Fernet tokens so that scoped tokens can be created later: </font>
<br>
<br><font size="3" face="Times"> </font><a href="https://github.com/openstack/keystone/blob/a637ebcbc4a92687d3e80a50cbe88df3b13c79e6/keystone/token/providers/fernet/token_formatters.py#L523" target="_blank"><font size="3" color="blue" face="Times"><u>https://github.com/openstack/keystone/blob/a637ebcbc4a92687d3e80a50cbe88df3b13c79e6/keystone/token/providers/fernet/token_formatters.py#L523</u></font></a>
<br>
<br><font size="3" face="Times">These are OpenStack group IDs, so it's up
to the deployer to keep those under control to keep Fernet token sizes
down. It's the only place in the current Fernet implementation that's (somewhat
alarmingly) unbounded in the real world.</font>
<br>
<br><font size="3" face="Times">But we do **not** have a use case to add
groups to *all* Fernet payloads: only to token creation & validation
responses. </font>
<br>
<br>
<br><font size="3" face="Times">On Thu, Jun 4, 2015 at 2:36 AM, Morgan Fainberg
<</font><a href="mailto:morgan.fainberg@gmail.com" target="_blank"><font size="3" color="blue" face="Times"><u>morgan.fainberg@gmail.com</u></font></a><font size="3" face="Times">>
wrote:</font>
<br><font size="3" face="Times">For Fernet, the groups would only be populated
on validate as Dolph outlined. They would not be added to the core payload.
We do not want to expand the payload in this manner. </font>
<br>
<br><font size="3" face="Times">--Morgan<br>
<br>
Sent via mobile</font>
<br><font size="3" face="Times"><br>
On Jun 3, 2015, at 21:51, Lance Bragstad <</font><a href="mailto:lbragstad@gmail.com" target="_blank"><font size="3" color="blue" face="Times"><u>lbragstad@gmail.com</u></font></a><font size="3" face="Times">>
wrote:<br>
</font>
<br><font size="3" face="Times">I feel if we allowed group ids to be an attribute
of the Fernet's core payload, we continue to open up the possibility for
tokens to be greater than the initial "acceptable" size limit
for a Fernet token (which I believe was 255 bytes?). With this, I think
we need to provide guidance on the number of group ids allowed within the
token before that size limit is compromised. </font>
<br>
<br><font size="3" face="Times">We've landed patches recently that allow
for id strings to be included in the Fernet payload [0], regardless of
being uuid format (which can be converted to bytes before packing to save
space, this is harder for us to do with non-uuid format id strings). This
can also cause the Fernet token size to grow. If we plan to include more
information in the Fernet token payload I think we should determine if
the original acceptable size limit still applies and regardless of what
that size limit is provide some sort of "best practices" for
helping deployments keep their token size as small as possible.</font>
<br>
<br>
<br><font size="3" face="Times">Keeping the tokens user (and developer) friendly
was a big plus in the design of Fernet, and providing resource for deployments
to maintain that would be helpful.</font>
<br>
<br>
<br><font size="3" face="Times">[0] </font><a href="https://review.openstack.org/#/q/status:merged+project:openstack/keystone+branch:master+topic:bug/1459382,n,z" target="_blank"><font size="3" color="blue" face="Times"><u>https://review.openstack.org/#/q/status:merged+project:openstack/keystone+branch:master+topic:bug/1459382,n,z</u></font></a>
<br>
<br><font size="3" face="Times">On Wed, Jun 3, 2015 at 10:19 PM, Steve Martinelli
<</font><a href="mailto:stevemar@ca.ibm.com" target="_blank"><font size="3" color="blue" face="Times"><u>stevemar@ca.ibm.com</u></font></a><font size="3" face="Times">>
wrote:</font>
<br><font size="2" face="sans-serif">Dozens to hundreds of roles or endpoints
could cause an issue now :)</font><font size="3" face="Times"><br>
</font><font size="2" face="sans-serif"><br>
But yeah, groups are much more likely to number in the dozens than roles
or endpoints. But I think the Fernet token size is so small that it could
probably handle this (since it does so now for the federated workflow).<br>
<br>
Thanks,<br>
<br>
Steve Martinelli<br>
OpenStack Keystone Core</font><font size="3" face="Times"> <br>
<br>
<br>
</font><font size="1" color="#5f5f5f" face="sans-serif"><br>
From: </font><font size="1" face="sans-serif">"Fox,
Kevin M" <</font><a href="mailto:Kevin.Fox@pnnl.gov" target="_blank"><font size="1" color="blue" face="sans-serif"><u>Kevin.Fox@pnnl.gov</u></font></a><font size="1" face="sans-serif">></font><font size="1" color="#5f5f5f" face="sans-serif"><br>
To: </font><font size="1" face="sans-serif">"OpenStack
Development Mailing List (not for usage questions)" <</font><a href="mailto:openstack-dev@lists.openstack.org" target="_blank"><font size="1" color="blue" face="sans-serif"><u>openstack-dev@lists.openstack.org</u></font></a><font size="1" face="sans-serif">></font><font size="1" color="#5f5f5f" face="sans-serif"><br>
Date: </font><font size="1" face="sans-serif">06/03/2015
11:14 PM</font><font size="1" color="#5f5f5f" face="sans-serif"><br>
Subject: </font><font size="1" face="sans-serif">Re:
[openstack-dev] [keystone][barbican] Regarding exposing
X-Group-xxxx in token validation</font><font size="3" face="Times"><br>
</font>
<hr noshade>
<br><font size="3" face="Times"><br>
<br>
<br>
Will dozens to a hundred groups or so on one user cause issues? :)<br>
<br>
Thanks,<br>
Kevin </font><font size="2" face="Tahoma"><b><br>
</b></font><font size="3" face="Times"> <br>
</font>
<hr><font size="2" face="Tahoma"><b>From:</b> Morgan Fainberg<b><br>
Sent:</b> Wednesday, June 03, 2015 7:23:22 PM<b><br>
To:</b> OpenStack Development Mailing List (not for usage questions)<b><br>
Subject:</b> Re: [openstack-dev] [keystone][barbican] Regarding exposing
X-Group-xxxx in token validation</font><font size="3" face="Times"><br>
<br>
In general I am of the opinion with the move to Fernet there is no good
reason we should avoid adding the group information into the token. <br>
<br>
--Morgan<br>
<br>
Sent via mobile <br>
<br>
On Jun 3, 2015, at 18:44, Dolph Mathews <</font><a href="mailto:dolph.mathews@gmail.com" target="_blank"><font size="3" color="blue" face="Times"><u>dolph.mathews@gmail.com</u></font></a><font size="3" face="Times">>
wrote:<br>
<br>
<br>
On Wed, Jun 3, 2015 at 5:58 PM, John Wood <</font><a href="mailto:john.wood@rackspace.com" target="_blank"><font size="3" color="blue" face="Times"><u>john.wood@rackspace.com</u></font></a><font size="3" face="Times">>
wrote:</font><font size="1" color="blue" face="Calibri"><br>
Hello folks,</font><font size="3" face="Times"> <br>
</font><font size="1" color="blue" face="Calibri"><br>
There has been discussion about adding user group support to the per-secret
access control list (ACL) feature in Barbican. Hence secrets could be marked
as accessible by a group on the ACL rather than an individual user as implemented
now.</font><font size="3" face="Times"> <br>
</font><font size="1" color="blue" face="Calibri"><br>
Our understanding is that Keystone does not pass along a user’s group
information during token validation however (such as in the form of X-Group-Ids/X-Group-Names
headers passed along via Keystone middleware).</font><font size="3" face="Times"><br>
<br>
The pre-requisite for including that information in the form of headers
would be adding group information to the token validation response. In
the case of UUID, it would be pre-computed and stored in the DB at token
creation time. In the case of PKI, it would be encoded into the PKI token
and further bloat PKI tokens. And in the case of Fernet, it would be included
at token validation time.<br>
<br>
Including group information, however, would also let us efficient revoke
tokens using token revocation events when group membership is affected
in any way (user being removed from a group, a group being deleted, or
a group-based role assignment being revoked). The OS-FEDERATION extension
is actually already including groups in tokens today, as a required part
of the federated workflow. We'd effectively be introducing that same behavior
into the core Identity API (see the federated token example):<br>
<br>
</font><a href="https://github.com/openstack/keystone-specs/blob/master/api/v3/identity-api-v3-os-federation-ext.rst#request-an-unscoped-os-federation-token" target="_blank"><font size="3" color="blue" face="Times"><u>https://github.com/openstack/keystone-specs/blob/master/api/v3/identity-api-v3-os-federation-ext.rst#request-an-unscoped-os-federation-token</u></font></a><font size="3" face="Times"><br>
<br>
This would allow us to address bugs such as: <br>
<br>
</font><a href="https://bugs.launchpad.net/keystone/+bug/1268751" target="_blank"><font size="3" color="blue" face="Times"><u>https://bugs.launchpad.net/keystone/+bug/1268751</u></font></a><font size="3" face="Times"><br>
<br>
In the past, we shied away from including groups if only to avoid bloating
the size of PKI tokens any further (but now we have Fernet tokens providing
a viable alternative). Are there any other reasons not to add group information
to the token validation response? <br>
<br>
</font><font size="1" color="blue" face="Calibri"><br>
Would the community consider this a useful feature? Would the community
consider adding this support to Liberty?</font><font size="3" face="Times"><br>
</font><font size="1" color="blue" face="Calibri"><br>
Thank you,</font><font size="3" face="Times"> </font><font size="1" color="blue" face="Calibri"><br>
John</font><font size="3" face="Times"> <br>
<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: </font><a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank"><font size="3" color="blue" face="Times"><u>OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</u></font></a><font size="3" color="blue" face="Times"><u><br>
</u></font><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank"><font size="3" color="blue" face="Times"><u>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</u></font></a><font size="3" face="Times"><br>
<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: </font><a href="mailto:OpenStack-dev-request@lists.openstack.org" target="_blank"><font size="3" color="blue" face="Times"><u>OpenStack-dev-request@lists.openstack.org</u></font></a><font size="3" face="Times">?subject:unsubscribe</font>
<br><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank"><font size="3" color="blue" face="Times"><u>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</u></font></a><font size="2" face="Times">__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: </font><a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank"><font size="2" color="blue" face="Times"><u>OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</u></font></a><font size="3" color="blue" face="Times"><u><br>
</u></font><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank"><font size="2" color="blue" face="Times"><u>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</u></font></a><font size="3" face="Times"><br>
<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: </font><a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank"><font size="3" color="blue" face="Times"><u>OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</u></font></a><font size="3" color="blue" face="Times"><u><br>
</u></font><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank"><font size="3" color="blue" face="Times"><u>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</u></font></a><font size="3" face="Times"><br>
</font>
<br>
<br><font size="3" face="Times">__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: </font><a href="mailto:OpenStack-dev-request@lists.openstack.org" target="_blank"><font size="3" color="blue" face="Times"><u>OpenStack-dev-request@lists.openstack.org</u></font></a><font size="3" face="Times">?subject:unsubscribe</font><font size="3" color="blue" face="Times"><u><br>
</u></font><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank"><font size="3" color="blue" face="Times"><u>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</u></font></a>
<br><font size="3" face="Times"><br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: </font><a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank"><font size="3" color="blue" face="Times"><u>OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</u></font></a><font size="3" color="blue" face="Times"><u><br>
</u></font><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank"><font size="3" color="blue" face="Times"><u>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</u></font></a><font size="3" face="Times"><br>
</font>
<br>
<br>
<br><font size="3"><br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: </font><a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank"><font size="3" color="blue"><u>OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</u></font></a><font size="3" color="blue"><u><br>
</u></font><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank"><font size="3" color="blue"><u>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</u></font></a><font size="3"><br>
</font>
<br>
<br>
<br></div></div><font size="2" face="sans-serif"><br>
Unless stated otherwise above:<br>
IBM United Kingdom Limited - Registered in England and Wales with number
741598. <br>
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
3AU<br>
</font>
</blockquote></div><br></div></div>