Re: [openstack-dev] [all][tc][swift][designate] New language addition process has been approved
> -Original Message- > From: Flavio Percoco [mailto:fla...@redhat.com] > Sent: 08 February 2017 13:49 > To: openstack-dev@lists.openstack.org > Subject: Re: [openstack-dev] [all][tc][swift][designate] New language addition > process has been approved > > On 19/01/17 11:59 +0100, Flavio Percoco wrote: > >Greetings, > > > >The Technical Committe recently approved a new reference document > which > >describes how new programming languages can be proposed for inclusion > >as supported languages by OpenStack. The new reference document can be > >found here[0]. > > > >I'd like to take this chance not only to share this new process - which > >in my opinion is a good step forward for the entire community - but to > >invite other teams to take a stab at it and move forward the inclusion > >of Go, which is the last language that was discussed for inclusion in the > community. > > > >I hope folks will find this process useful and that it'll help > >innovating OpenStack. I'm sure the process is not perfect and that > >we'll have to refine it as we go so, let's get going. > > > >Thanks everyone, > >Flavio > > > >[0] > >https://governance.openstack.org/tc/reference/new-language-requirements > >.html > > > Hey folks, > > Sorry for pressing so much on this but, would it be safe to assume that no > one from the swift and/or designate team are intereted in proposing golang > through this process? > > That's what I'm assuming at least given the silence on this thread. > I can only speak for myself, but I anticipate that this is something we would discuss at the PTG. Alistair > Thanks, > Flavio > > > -- > @flaper87 > Flavio Percoco __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all][infra] Proposed changes to unit-test setup
On 22 November 2016 18:56, John Dickinson wrote:
>
> On 22 Nov 2016, at 10:47, Andreas Jaeger wrote:
>
> > When we (infra) changed the unit test jobs to not set up databases by
> > default, we created special python-db and tox-db jobs that set up both
> > MySQL and PostgreSQL databases. And that complicated the setup of
> > those projects and lead to problems like setting projects up via
> > bindep for both databases even if one was used.
> >
> > We had last week an IRC discussion [1] and came up with the following
> > approach:
> >
> > Projects can use a tools/test-setup.sh script that is called from
> > our unit test (tox, python27, python34, python35) targets. The
> > script is executed as root and should set up the needed databases -
> > or whatever is needed. The script needs to reside in the repository -
> > and thus might need to get backported to older branches.
> >
> > This setup should be used for any kind of repo specific unit test
> > setup.
> >
> > Projects are suggested to add to their developer documents, e.g. the
> > README or CONTRIBUTING or TESTING file, the usage of
> > tools/testsetup.sh. Developers should be able to use the script to
> > set up prerequisites for unit tests locally.
> >
> > Long term goal is for projects to not use the -db jobs anymore, new
> > changes for them should not be accepted.
> >
> > This is implemented in project-config [2], an example usage in
> > nodepool [3,4], which leads to a cleanup [5].
> >
> > Further investigation shows that the special searchlight setup can be
> > solved with the same approach (searchlight change [6], project-config
> > [7]). Here it's interesting to note that moving the setup in the
> > repository, found a problem: The repo needs elasticsearch 1 for
> > liberty and 2 for newer branches, this can now be done inside the
> > repository.
> >
> > The xfs TMPDIR setup of swift [2] could been done in general this way
> > as well but that change needs to set TMPDIR for the unittests, passing
> > information from the set up builder to the tox builder. This is
> > currently not possible using only the proposed solution, and so would
> > still require a custom tox job. Alternative, this could be changed
> > with some other way of passing the value of TMPDIR between these
> > different invocations.
>
> (actually link [10])
>
> This sounds like a great idea that I would have loved to have in place a few
> weeks ago!
>
> One question: is there a limit to which tox environments will call this
> in-repo
> script? Above you list a few, but Swift and other projects have repo-specific
> environments that would need the setup as well. How will that work?
>
+1 this is a really useful feature.
Further to John's question, would it be possible for the test-setup.sh script
to be passed the job template name as an arg? That would allow customized setup
for specific test jobs. Right now I don’t have a specific use case in Swift but
I'm curious as to whether it is a possibility.
>
> >
> > Today, a change was proposed [8,9] that would setup docker for kolla
> > and kolla-ansible. I suggest to not merge it and instead use the same
> > approach here.
> >
> > Credits for the proposal go to Jeremy - and this got triggered by
> > comments by Jim. Thanks!
> >
> > Andreas
> >
> > [1]
> > http://eavesdrop.openstack.org/irclogs/%23openstack-infra/%23openstack
> > -infra.2016-11-17.log.html#t2016-11-17T15:07:38
> >
> > [2] https://review.openstack.org/399105
> > [3] https://review.openstack.org/399079
> > [4] https://review.openstack.org/399177
> > [5] https://review.openstack.org/399180
> > [6] https://review.openstack.org/399159
> > [7] https://review.openstack.org/399169
> > [8] https://review.openstack.org/400128
> > [9] https://review.openstack.org/400474
> > [10] https://review.openstack.org/394600
> > --
> > Andreas Jaeger aj@{suse.com,opensuse.org} Twitter: jaegerandi
> > SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
> >GF: Felix Imendörffer, Jane Smithard, Graham Norton,
> >HRB 21284 (AG Nürnberg)
> > GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272
> > A126
> >
> >
>
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [swift][keystone] Using JSON as future ACL format
Thai,
(repeating some of what we have discussed in private for others' benefit)
The Swift docs state "Be sure to use Keystone UUIDs rather than names in
container ACLs" [1]. The guidance is re-iterated here [2] "...names must no
longer be used in cross-tenant ACLs...". They then go on to explain that for
backwards compatibility (i.e. to not break ACLS that have already been
persisted in Swift) names in ACLs are supported in the default domain only.
The intent was not to encourage the continued use of names in the default
domain (or while using keystone v2), nor to suggest that was "safe", but to
recognize that names had previously been used in contexts where names were
unique and the ':' separator was safe. In fact, Swift provides an option to
disallow name matching in *all* contexts when no such backwards compatibility
is required.
At the time we made those changes (c. Atlanta summit) the input I had from
Keystone devs was that names were not globally unique (with keystone v3), were
mutable and should not be persisted. Hence the swift docs guidance. We actually
considered preventing any new ACL being set with names, but to do so requires
distinguishing a name string from a UUID string, which we didn't find a
solution for.
So in response to your argument "If we are allowing V2 to store names [{
project, name }], I do not see why we should not allow the same for V3 [{
domain, project, name }]" : yes, we are allowing names in ACLs in some
circumstances, but only for backwards compatibility, and we are not encouraging
it. Having gone through the pain of dealing with names in existing persisted
ACLs, I am reluctant to encourage their continued/renewed use.
Are their examples of any other projects requiring names rather than UUIDs in
ACLs, or for other purposes, that we can learn from?
The idea discussed here [3] (not implemented) was that names could be supported
in a JSON ACL format but should be resolved to UUIDs before persisting in
Swift. That way a user's name can change but since their request token is
resolved to UUID then any persisted ACL would still match. As has already been
mentioned in another reply on this thread, Swift has a JSON ACL format for
"v1"/TempAuth account level ACLs [4] that could perhaps be implemented for
keystoneauth and then extended to containers.
Alistair
[1]
http://docs.openstack.org/developer/swift/overview_auth.html#access-control-using-keystoneauth
[2] http://docs.openstack.org/developer/swift/middleware.html#keystoneauth
[3] https://wiki.openstack.org/wiki/Swift/ContainerACLWithKeystoneV3
[4] http://docs.openstack.org/developer/swift/overview_auth.html#tempauth
From: Thai Q Tran [mailto:tqt...@us.ibm.com]
Sent: 06 June 2016 21:06
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [swift][keystone] Using JSON as future ACL format
Hello all,
Hope everyone had a good weekend, and hope this email does not ruin your next.
We had a small internal discussion at IBM and here are some of the findings
that I will present to the wider community.
1. The ":" separator that swift currently uses is not entirely safe since LDAP
can be configured to allow special characters in user IDs. It essentially means
no special characters are safe to use as separators. I am not sure how
practical this is, but its something to consider.
2. Since names are not guaranteed to be immutable, we should store everything
via IDs. Currently, for backward compatibility reasons, Swift continues to
support names for for V2. Keep in mind that V2 does not guarantee that names
are immutable either. Given this fact and what we know from #1, we can say that
names are mutable for both V2 and V3, and that any separators we use are
fallible. In other words, using a separator for names or ids will not work 100%
of the time.
3. Keystone recently enabled URL safe naming of project and domains for their
hierarchal work. As a by product of that, if the option is enabled, Swift can
essentially use the reserved characters as separators. The list of reserved
characters are listed below. The only question remaining, how does Keystone
inform Swift that this option is enabled? or Swift can add an separator option
that is a subset of the characters below and leave it to the deployer to
configure it.
";" | "/" | "?" | ":" | "@" | "&" | "=" | "+" |"$" | ","
https://github.com/openstack/keystone/commit/60b52c1248ddd5e682838d9e8ba853789940c284
http://www.ietf.org/rfc/rfc2396.txt
3. As mentioned in the KeystoneAuthACL write up in Atlanta, JSON format is one
of the option going forward. The article goes on to mention that we should
store only user IDs (avoiding the mutable names issue). It outlined a process
and reverse-process that would allow names to be use but mentioned an overhead
cost to Keystone. I personally think is the right approach going forward since
it negate the use of a separator
Re: [openstack-dev] [swift] Account ACL with keystone auth
Account ACL in Swift is not supported with keystoneauth. It is not described in
the keystone auth section of [1]. You can probably achieve similar by assigning
the appropriate roles to users in keystone.
[1] http://docs.openstack.org/developer/swift/overview_auth.html
Alistair
From: Sampath, Lakshmi
Sent: 19 February 2016 18:29
To: OpenStack Development Mailing List
Subject: [openstack-dev] [swift] Account ACL with keystone auth
Account ACL for allowing other accounts administration access to create
containers looks to be accepting the request but doesn't seem to be persisting
the information with keystone auth.
For example if admin:admin user allows demo:demo "admin" access on its account,
the following request succeeds but later when I try creating a container, using
demo account in admin account it fails.
As admin:admin user
curl -X POST -i -H "X-Auth-Token: 57eb097f3b8e4c9e8a927a71c7f18e9c" -H
'X-Account-Access-Control: {"admin":["AUTH_demo"]}'
http://127.0.0.1:8080/v1/AUTH_admin
HTTP/1.1 204 No Content
Content-Length: 0
Content-Type: text/html; charset=UTF-8
X-Trans-Id: txefcd03a9b0ea4c2ab28a3-0056c75dae
Date: Fri, 19 Feb 2016 18:23:42 GMT
As demo:demo user
curl -XPUT -i -H "X-Auth-Token: 9173236daaa3470886410934c467fd7e"
http://127.0.0.1:8080/v1/AUTH_admin/container1
HTTP/1.1 403 Forbidden
Content-Length: 73
Content-Type: text/html; charset=UTF-8
X-Trans-Id: txbd54e9b8f5c64419bf689-0056c75c25
Date: Fri, 19 Feb 2016 18:17:09 GMT
Is Account ACL supported using keystone auth?
Thanks
Lakshmi.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] V3 Authentication for swift store
Jamie - thanks for the link to your blog. I remember the Paris discussion :) And also noted the Vancouver discussion re. SDK not necessarily being targeted at service-service interactions. I sense there is renewed desire to maintain improve swiftclient, and a few of us are interested in looking into the session support (but lacking free cycles right now :/). We need to figure out a nice way to maintain the v1 auth mode as and when sessions comes into the Connection - there was a very brief conversation in Vancouver around maybe encapsulating the v1 auth in a keystone-session-like object. Alistair -Original Message- From: Jamie Lennox [mailto:jamielen...@redhat.com] Sent: 19 June 2015 02:27 To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] V3 Authentication for swift store - Original Message - From: Alistair Coles alistair.co...@hp.com To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Sent: Thursday, 18 June, 2015 4:39:52 PM Subject: Re: [openstack-dev] V3 Authentication for swift store -Original Message- From: Jamie Lennox [mailto:jamielen...@redhat.com] Sent: 18 June 2015 07:02 To: OpenStack Development Mailing List (not for usage questions) Subject: [openstack-dev] [glance] V3 Authentication for swift store Hey everyone, TL;DR: glance_store requires a way to do v3 authentication to the swift backend. snip However in future we are trying to open up authentication so it's not limited to only user/password authentication. Immediate goals for service to service communications are to enable SSL client certificates and kerberos authentication. This would be handled by keystoneclient sessions but they are not supported by swift and it would require a significant rewrite of swiftclient to do, and the swift team has indicated they do not which to invest more time into their client. If we consider specifically the swiftclient Connection class, I wonder how significant a rewrite would be to support session objects? I'm not too familiar with sessions - is a session an object with an interface to fetch a token and service endpoint url? If so maybe Connection could accept a session in lieu of auth options and call the session rather than its get_auth methods. If we can move towards sessions in swiftclient then that would be good IMHO, since we have also have requirement to support fetching a service token [1], which I guess would (now or in future) also be handled by the session? [1] https://review.openstack.org/182640 Alistair So the sessions work is built on, and is modelled after requests.Session. It consists of two parts, the session which is your transport object involving things like CA certs, verify flags etc and an auth plugin which is how we can handle new auth mechanisms. Once coupled the interface looks very similar to a requests.Session with get(), post(), request() etc methods, with the addition that requests are automatically authenticated and things like the service catalog are handled for you. I wrote a blog post a while back which explains many of the concepts[2]. The fastest way I could see including Sessions into swiftclient would be to create new Connection and HttpConnection objects. Would this be something swift is interested in? I didn't mean to offend when saying that you didn't want to put any more time into the client, there was a whole session in Paris about how the client had problems but it was just going to limp along until SDK was ready. Side note, i don't know how this decision will be affected based on Vancouver conversations about how SDK may not be suitable for service-service communications. Regarding service tokens, we have an auth plugin that is passed down from auth_token middleware that will include X-Service-Token in requests which I think swiftclient would benefit from. Jamie [2] http://www.jamielennox.net/blog/2014/09/15/how-to-use-keystoneclient- sessions/ _ _ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] V3 Authentication for swift store
-Original Message- From: Jamie Lennox [mailto:jamielen...@redhat.com] Sent: 18 June 2015 07:02 To: OpenStack Development Mailing List (not for usage questions) Subject: [openstack-dev] [glance] V3 Authentication for swift store Hey everyone, TL;DR: glance_store requires a way to do v3 authentication to the swift backend. snip However in future we are trying to open up authentication so it's not limited to only user/password authentication. Immediate goals for service to service communications are to enable SSL client certificates and kerberos authentication. This would be handled by keystoneclient sessions but they are not supported by swift and it would require a significant rewrite of swiftclient to do, and the swift team has indicated they do not which to invest more time into their client. If we consider specifically the swiftclient Connection class, I wonder how significant a rewrite would be to support session objects? I'm not too familiar with sessions - is a session an object with an interface to fetch a token and service endpoint url? If so maybe Connection could accept a session in lieu of auth options and call the session rather than its get_auth methods. If we can move towards sessions in swiftclient then that would be good IMHO, since we have also have requirement to support fetching a service token [1], which I guess would (now or in future) also be handled by the session? [1] https://review.openstack.org/182640 Alistair snip __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [oslo] usage patterns for oslo.config
I've been looking at the implications of applying oslo.config in Swift, and I have a question about the best pattern for registering options. Looking at how keystone uses oslo.config, the pattern seems to be to have all options declared and registered 'up-front' in a single place (keystone/common/config.py) before loading wsgi pipeline/starting the service. Is there another usage pattern where each middleware registers its options independently 'on-demand' rather than maintaining them all in a single place? I read about a pattern [1] whereby modules register opts during import, but does that require there to be some point in the lifecycle where all required modules are imported *before* parsing config files? Seems like that would mean parsing the wsgi pipeline to 'discover' the middleware modules being used, importing all those modules, then parsing config files, then loading the wsgi pipeline? OR - is it acceptable for each middleware module to register its own options if/when it is imported during wsgi pipeline loading (CONF.register_options()) and then call CONF.reload_config_files() ? Thanks, Alistair [1] http://docs.openstack.org/developer/oslo.config/cfg.html#global-configopts ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Keystone] [Swift] Question re. keystone domains
Thanks Dolph, that’s helpful. For backwards compatibility reasons we need to preserve legacy access control list behavior for projects/users in the default domain only. To achieve that, we need to persist the project’s domain id in Swift. If a project subsequently moved to/from the default domain then Swift wouldn’t ‘break’ but would potentially (dis)allow legacy ACLs based on stale domain information. If the backwards compatibility feature in Swift were configurable (on/off) then, as you suggest, some text alongside the Keystone config option (and corresponding in Swift) can act as a warning not to enable both options. Alistair From: Dolph Mathews [mailto:dolph.math...@gmail.com] Sent: 01 July 2014 20:15 To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Keystone] [Swift] Question re. keystone domains On Tue, Jul 1, 2014 at 11:20 AM, Coles, Alistair alistair.co...@hp.commailto:alistair.co...@hp.com wrote: We have a change [1] under review in Swift to make access control lists compatible with migration to keystone v3 domains. The change makes two assumptions that I’d like to double-check with keystone folks: 1. That a project can never move from one domain to another. We're moving in this direction, at least. In Grizzly and Havana, we made no such restriction. In Icehouse, we introduced such a restriction by default, but it can be disabled. So far, we haven't gotten any complaints about adding the restriction, so maybe we should just add additional help text to the option in our config about why you would never want to disable the restriction, citing how it would break swift? 2. That the underscore character cannot appear in a valid domain id – more specifically, that the string ‘_unknown’ cannot be confused with a domain id. That's fairly sound. All of our domain ID's are system-assigned as UUIDs, except for the default domain which has an explicit id='default'. We don't do anything to validate the assumption, though. Are those safe assumptions? Thanks, Alistair [1] https://review.openstack.org/86430 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Keystone] [Swift] Question re. keystone domains
We have a change [1] under review in Swift to make access control lists compatible with migration to keystone v3 domains. The change makes two assumptions that I'd like to double-check with keystone folks: 1. That a project can never move from one domain to another. 2. That the underscore character cannot appear in a valid domain id - more specifically, that the string '_unknown' cannot be confused with a domain id. Are those safe assumptions? Thanks, Alistair [1] https://review.openstack.org/86430 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Facing an issue in swift
In my experience 'Endpoint for object-store not found - have you specified a region?' can be returned by swift client if: (a) You have specified a region that isn't found among the service endpoints e.g. % swift --os-auth-url http://example:5000/v2.0 --os-password=testing stat --os-username=tester --os-tenant-name=test --os-region-name=foo Endpoint for object-store not found - have you specified a region? Or (b) you did not specify a tenant-name or tenant-id e.g. % swift --os-auth-url http://example:5000/v2.0 --os-password=testing stat --os-username=tester Endpoint for object-store not found - have you specified a region? From: Sowmya Nethi [mailto:sowmya_ne...@persistent.co.in] Sent: 02 April 2014 07:43 To: openstack-dev@lists.openstack.org Subject: [openstack-dev] Facing an issue in swift Hi all, Question: Endpoint for object-store not found - have you specified a region? I am facing this issue while integrating swift with keystone in havana: I changed proxy-server.conf file with the below contents [pipeline:main] pipeline = authtoken keystoneauth proxy-logging proxy-server [filter:authtoken] paste.filter_factory = keystoneclient.middleware.auth_token:filter_factory auth_host = controller auth_port = 35357 auth_protocol = http auth_uri = http://10.233.52.110:35357/v2.0 admin_tenant_name = admin admin_user = admin admin_password = ADMIN_PASS cache = swift.cache include_service_catalog = False [filter:keystoneauth] use = egg:swift#keystoneauth operator_roles = admin, swiftoperator and restarted all the swift services, while executing swift commands output is Endpoint for object-store not found - have you specified a region? Can anyone help me on this issue ? And I referred the below link: http://docs.openstack.org/developer/swift/overview_auth.html Thanks and Regards, Sowmya Nethi sowmya_ne...@persistent.co.inmailto:sowmya_ne...@persistent.co.in | Tel: +91(40)674 42026 Persistent Systems Ltd. | Partners in Innovation | www.persistentsys.comhttp://www.persistentsys.com/ DISCLAIMER == This e-mail may contain privileged and confidential information which is the property of Persistent Systems Ltd. It is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you are not authorized to read, retain, copy, print, distribute or use this message. If you have received this communication in error, please notify the sender and delete all copies of this message. Persistent Systems Ltd. does not accept any liability for virus infected mails. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Swift] container forwarding/cluster federation blueprint
We've just committed a first set of patches to gerrit that address this blueprint: https://blueprints.launchpad.net/swift/+spec/cluster-federation Quoting from that page: The goal of this work is to enable account contents to be dispersed across multiple clusters, motivated by (a) accounts that might grow beyond the remaining capacity of a single cluster and (b) clusters offering differentiated service levels such as different levels of redundancy or different storage tiers. Following feedback at the Portland summit, the work is initially limited to dispersal at the container level, i.e. each container within an account may be stored on a different cluster, whereas every object within a container will be stored on the same cluster. It is work in progress, but we'd welcome feedback on this thread, or in person for anyone who might be at the hackathon in Austin next week. The bulk of the new features are in this patch: https://review.openstack.org/51236 (Middleware module for container forwarding.) There's a couple of patches refactoring/adding support to existing modules: https://review.openstack.org/51242 (Refactor proxy/controllers obj base http code) https://review.openstack.org/51228 (Store x-container-attr-* headers in container db.) And some tests... https://review.openstack.org/51245 (Container-forwarding unit and functional tests) Regards, Alistair Coles, Eric Deliot, Aled Edwards HP Labs, Bristol, UK - Hewlett-Packard Limited registered Office: Cain Road, Bracknell, Berks RG12 1HN . Registered No: 690597 England The contents of this message and any attachments to it are confidential and may be legally privileged. If you have received this message in error, you should delete it from your system immediately and advise the sender. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
