[openstack-dev] [Savanna] validation error when launching cluster ala quickstart guide
kesten broughton
kesten.broughton at gmail.com
Mon Sep 16 14:24:01 UTC 2013
I'm following the quickstart guide in the docs and see this in the terminal
log for the savanna process:
savanna.utils.api [-] Request aborted with status code 500 and message
'Error occurred during validation'
Note that i can make the other posts successfully with the same AUTH_TOKEN
and TENANT_ID; only the launch step fails.
details of logs and conf file are here
http://paste.openstack.org/show/47101/
it may be related to the bug logged here?
https://bugs.launchpad.net/savanna/+bug/1223934
or the questions asked here:
https://answers.launchpad.net/savanna/+question/227258
http://lists.openstack.org/pipermail/openstack-dev/2013-July/011844.html
I downloaded the tarball about 3 days ago ala
$ savanna-venv/bin/pip install
'http://tarballs.openstack.org/savanna/savanna-master.tar.gz'
The pip freeze is here http://paste.openstack.org/show/47111/
However, i can't check the version
stack at vmware-controller:~$ savanna-venv/bin/python
savanna-venv/bin/savanna-api --version
< No output >
I will lodge a separate bug for savanna-api --version returning nothing.
kesten
On Mon, Sep 16, 2013 at 7:00 AM,
<openstack-dev-request at lists.openstack.org>wrote:
> Send OpenStack-dev mailing list submissions to
> openstack-dev at lists.openstack.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> or, via email, send a message with subject or body 'help' to
> openstack-dev-request at lists.openstack.org
>
> You can reach the person managing the list at
> openstack-dev-owner at lists.openstack.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of OpenStack-dev digest..."
>
>
> Today's Topics:
>
> 1. Re: OpenStack + PyPy: Status and goals (Joshua Harlow)
> 2. Re: OpenStack + PyPy: Status and goals (Alex Gaynor)
> 3. Re: OpenStack + PyPy: Status and goals (Joshua Harlow)
> 4. Re: [Swift] Protecting the access to memcache (John Dickinson)
> 5. Re: When will we stop adding new Python modules to
> requirements (Monty Taylor)
> 6. Re: python-simplejson 2.0.0 errors (Monty Taylor)
> 7. Re: When will we stop adding new Python modules to
> requirements (Matthias Runge)
> 8. Re: How to create vmdk for openstack usage (Vui Chiap Lam)
> 9. Re: Oslo.db possible module? (Roman Podolyaka)
> 10. Re: Oslo.db possible module? (Flavio Percoco)
> 11. Re: Oslo.db possible module? (Boris Pavlovic)
> 12. Re: [Ceilometer][IceHouse] Ceilometer + Kibana +
> ElasticSearch Integration (Julien Danjou)
> 13. Re: [Swift] Protecting the access to memcache (Chmouel Boudjnah)
> 14. [Nova] Quick review from a core please for simple bug fix
> (Day, Phil)
> 15. Re: Backwards incompatible migration changes - Discussion
> (Michael Still)
> 16. Re: [Nova] Quick review from a core please for simple bug fix
> (Michael Still)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Sun, 15 Sep 2013 21:43:16 +0000
> From: Joshua Harlow <harlowja at yahoo-inc.com>
> To: OpenStack Development Mailing List
> <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] OpenStack + PyPy: Status and goals
> Message-ID:
> <
> 5CFD0F75CA728B418032E43337AAAB7B1412AED5 at GQ1-MB04-02.y.corp.yahoo.com>
>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Cool,
>
> Are there any technical docs for how eventlet/greenlet work in PyPy,
>
> >From my knowledge of greenlet its doing some pretty low level stuff that
> would seem hard to mirror in PyPy.
>
> https://github.com/python-greenlet/greenlet/blob/master/greenlet.c#L9
>
> And the very platform specific stack switching functions @
> https://github.com/python-greenlet/greenlet/tree/master/platform
>
> It would seem like greenlet is pretty tightly coupled to the cpython and
> its functionality. I'd like to know how it can operate in pypy without
> major modifications, maybe u know of such a documentation that explains
> this. I'd be interested in reading that at least (maybe others would like
> to also).
>
> :-)
>
> -Josh
> ________________________________
> From: Alex Gaynor [alex.gaynor at gmail.com]
> Sent: Tuesday, September 10, 2013 8:18 AM
> To: OpenStack Development Mailing List
> Subject: Re: [openstack-dev] OpenStack + PyPy: Status and goals
>
> Hi Roman,
>
> Yes eventlet works well on PyPy, both Marconi and Swift use it.
>
> Alex
>
>
> On Mon, Sep 9, 2013 at 10:15 PM, Roman Podolyaka <rpodolyaka at mirantis.com
> <mailto:rpodolyaka at mirantis.com>> wrote:
> Hi Alex,
>
> That's really cool! I believe, performance is not the only benefit we can
> get from running OpenStack projects on PyPy. We can also improve the
> overall "correctness" of our code (as PyPy behaves differently with
> non-closed files, etc), just like compiling of your C/C++ app using
> different compilers can show hidden errors.
>
> And what about eventlet? Does it work well on PyPy? (as it is used in
> Nova, Neutron, etc)
>
> Thanks,
> Roman
>
>
> On Tue, Sep 10, 2013 at 12:28 AM, Alex Gaynor <alex.gaynor at gmail.com
> <mailto:alex.gaynor at gmail.com>> wrote:
> Hi all,
>
> Many of you have probably seen me send review requests in the last few
> weeks
> about adding PyPy support to various OpenStack projects. A few people were
> confused by these, so I wanted to fill everyone in on what I'm up to :)
>
> First, for those who aren't familiar with what PyPy is: PyPy is an
> implementation of the Python language which includes a high performance
> tracing
> just-in-time compiler and which is faster than CPython (the reference, and
> most
> widely deployed, implementation) on almost all workloads.
>
> The current status is:
>
> Two major projects work, both Marconi and Swift, Marconi is gating against
> PyPy
> already, Swift isn't yet since I needed to fix a few small PyPy bugs and
> those
> aren't in a release yet, expect it soon :)
>
> In terms of results, I've observed 30% performance improvements on GET
> workloads for Swift under PyPy vs. CPython (other workloads haven't been
> benchmarked tet). I believe the Marconi folks have also observed some
> performance wins, but I'll let them speak to that, I don't have the full
> details.
>
> Many python-clients projects are also working out of the box and gating:
> including novaclient, swiftclient, marconiclient, ceilometerclient,
> heatclient,
> and ironicclient!
>
> There's a few outstanding reviews to add PyPy gating for cinderclient,
> troveclient, and glanceclient.
>
> In terms of future direction:
>
> I'm going to continue to work on getting more projects running and gating
> against PyPy.
>
> Right now I'm focusing a lot of my attention on improving Swift
> performance,
> particularly under PyPy, but also under CPython.
>
> I'm hoping some day PyPy will be the default way to deploy OpenStack!
>
>
> If you're interested in getting your project running on PyPy, or looking at
> performance under it, please let me know, I'm always interested in helping!
>
> Thanks,
> Alex
>
> --
> "I disapprove of what you say, but I will defend to the death your right
> to say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
> "The people's good is the highest law." -- Cicero
> GPG Key fingerprint: 125F 5C67 DFE9 4084
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org
> >
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org
> >
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
>
> --
> "I disapprove of what you say, but I will defend to the death your right
> to say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
> "The people's good is the highest law." -- Cicero
> GPG Key fingerprint: 125F 5C67 DFE9 4084
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.openstack.org/pipermail/openstack-dev/attachments/20130915/f36ede9e/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 2
> Date: Sun, 15 Sep 2013 14:57:38 -0700
> From: Alex Gaynor <alex.gaynor at gmail.com>
> To: OpenStack Development Mailing List
> <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] OpenStack + PyPy: Status and goals
> Message-ID:
> <CAFRnB2V+ZnQsiiX4EcT_s6L9R=
> JKdW_JamfT_UF--efNkKtY0g at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> The short answer is, PyPy has its own implementation of greenlets,
> https://bitbucket.org/pypy/pypy/src/default/lib_pypy/greenlet.py , this is
> built on top of a module called _continuation,
> http://doc.pypy.org/en/latest/stackless.html contains some of the details
> of how it works.
>
> Alex
>
>
> On Sun, Sep 15, 2013 at 2:43 PM, Joshua Harlow <harlowja at yahoo-inc.com
> >wrote:
>
> > Cool,
> >
> > Are there any technical docs for how eventlet/greenlet work in PyPy,
> >
> > From my knowledge of greenlet its doing some pretty low level stuff that
> > would seem hard to mirror in PyPy.
> >
> > https://github.com/python-greenlet/greenlet/blob/master/greenlet.c#L9
> >
> > And the very platform specific stack switching functions @
> > https://github.com/python-greenlet/greenlet/tree/master/platform
> >
> > It would seem like greenlet is pretty tightly coupled to the cpython and
> > its functionality. I'd like to know how it can operate in pypy without
> > major modifications, maybe u know of such a documentation that explains
> > this. I'd be interested in reading that at least (maybe others would like
> > to also).
> >
> > :-)
> >
> > -Josh
> > ------------------------------
> > *From:* Alex Gaynor [alex.gaynor at gmail.com]
> > *Sent:* Tuesday, September 10, 2013 8:18 AM
> > *To:* OpenStack Development Mailing List
> > *Subject:* Re: [openstack-dev] OpenStack + PyPy: Status and goals
> >
> > Hi Roman,
> >
> > Yes eventlet works well on PyPy, both Marconi and Swift use it.
> >
> > Alex
> >
> >
> > On Mon, Sep 9, 2013 at 10:15 PM, Roman Podolyaka <
> rpodolyaka at mirantis.com>wrote:
> >
> >> Hi Alex,
> >>
> >> That's really cool! I believe, performance is not the only benefit we
> >> can get from running OpenStack projects on PyPy. We can also improve
> the
> >> overall "correctness" of our code (as PyPy behaves differently with
> >> non-closed files, etc), just like compiling of your C/C++ app using
> >> different compilers can show hidden errors.
> >>
> >> And what about eventlet? Does it work well on PyPy? (as it is used in
> >> Nova, Neutron, etc)
> >>
> >> Thanks,
> >> Roman
> >>
> >>
> >> On Tue, Sep 10, 2013 at 12:28 AM, Alex Gaynor <alex.gaynor at gmail.com
> >wrote:
> >>
> >>> Hi all,
> >>>
> >>> Many of you have probably seen me send review requests in the last few
> >>> weeks
> >>> about adding PyPy support to various OpenStack projects. A few people
> >>> were
> >>> confused by these, so I wanted to fill everyone in on what I'm up to :)
> >>>
> >>> First, for those who aren't familiar with what PyPy is: PyPy is an
> >>> implementation of the Python language which includes a high performance
> >>> tracing
> >>> just-in-time compiler and which is faster than CPython (the reference,
> >>> and most
> >>> widely deployed, implementation) on almost all workloads.
> >>>
> >>> The current status is:
> >>>
> >>> Two major projects work, both Marconi and Swift, Marconi is gating
> >>> against PyPy
> >>> already, Swift isn't yet since I needed to fix a few small PyPy bugs
> and
> >>> those
> >>> aren't in a release yet, expect it soon :)
> >>>
> >>> In terms of results, I've observed 30% performance improvements on GET
> >>> workloads for Swift under PyPy vs. CPython (other workloads haven't
> been
> >>> benchmarked tet). I believe the Marconi folks have also observed some
> >>> performance wins, but I'll let them speak to that, I don't have the
> full
> >>> details.
> >>>
> >>> Many python-clients projects are also working out of the box and
> >>> gating:
> >>> including novaclient, swiftclient, marconiclient, ceilometerclient,
> >>> heatclient,
> >>> and ironicclient!
> >>>
> >>> There's a few outstanding reviews to add PyPy gating for cinderclient,
> >>> troveclient, and glanceclient.
> >>>
> >>> In terms of future direction:
> >>>
> >>> I'm going to continue to work on getting more projects running and
> >>> gating
> >>> against PyPy.
> >>>
> >>> Right now I'm focusing a lot of my attention on improving Swift
> >>> performance,
> >>> particularly under PyPy, but also under CPython.
> >>>
> >>> I'm hoping some day PyPy will be the default way to deploy OpenStack!
> >>>
> >>>
> >>> If you're interested in getting your project running on PyPy, or
> >>> looking at
> >>> performance under it, please let me know, I'm always interested in
> >>> helping!
> >>>
> >>> Thanks,
> >>> Alex
> >>>
> >>> --
> >>> "I disapprove of what you say, but I will defend to the death your
> right
> >>> to say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
> >>> "The people's good is the highest law." -- Cicero
> >>> GPG Key fingerprint: 125F 5C67 DFE9 4084
> >>>
> >>> _______________________________________________
> >>> OpenStack-dev mailing list
> >>> OpenStack-dev at lists.openstack.org
> >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>>
> >>>
> >>
> >> _______________________________________________
> >> OpenStack-dev mailing list
> >> OpenStack-dev at lists.openstack.org
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>
> >>
> >
> >
> > --
> > "I disapprove of what you say, but I will defend to the death your right
> > to say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
> > "The people's good is the highest law." -- Cicero
> > GPG Key fingerprint: 125F 5C67 DFE9 4084
> >
> > _______________________________________________
> > OpenStack-dev mailing list
> > OpenStack-dev at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >
>
>
> --
> "I disapprove of what you say, but I will defend to the death your right to
> say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
> "The people's good is the highest law." -- Cicero
> GPG Key fingerprint: 125F 5C67 DFE9 4084
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.openstack.org/pipermail/openstack-dev/attachments/20130915/e98c4802/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 3
> Date: Sun, 15 Sep 2013 22:13:11 +0000
> From: Joshua Harlow <harlowja at yahoo-inc.com>
> To: OpenStack Development Mailing List
> <openstack-dev at lists.openstack.org>
> Cc: OpenStack Development Mailing List
> <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] OpenStack + PyPy: Status and goals
> Message-ID: <EEA04AA6-F16B-4755-832F-54FAEB27C719 at yahoo-inc.com>
> Content-Type: text/plain; charset="us-ascii"
>
> Thanks much! Very interesting.
>
> It's interesting to see the convergence going on here with pypy "greenlet"
> and cpython getting tulip from guido (and all the eventlet/greenlet
> variations that already exist). Will be interesting to see how this all
> works out.
>
> Sent from my really tiny device...
>
> On Sep 15, 2013, at 3:03 PM, "Alex Gaynor" <alex.gaynor at gmail.com<mailto:
> alex.gaynor at gmail.com>> wrote:
>
> The short answer is, PyPy has its own implementation of greenlets,
> https://bitbucket.org/pypy/pypy/src/default/lib_pypy/greenlet.py , this
> is built on top of a module called _continuation,
> http://doc.pypy.org/en/latest/stackless.html contains some of the details
> of how it works.
>
> Alex
>
>
> On Sun, Sep 15, 2013 at 2:43 PM, Joshua Harlow <harlowja at yahoo-inc.com
> <mailto:harlowja at yahoo-inc.com>> wrote:
> Cool,
>
> Are there any technical docs for how eventlet/greenlet work in PyPy,
>
> >From my knowledge of greenlet its doing some pretty low level stuff that
> would seem hard to mirror in PyPy.
>
> https://github.com/python-greenlet/greenlet/blob/master/greenlet.c#L9
>
> And the very platform specific stack switching functions @
> https://github.com/python-greenlet/greenlet/tree/master/platform
>
> It would seem like greenlet is pretty tightly coupled to the cpython and
> its functionality. I'd like to know how it can operate in pypy without
> major modifications, maybe u know of such a documentation that explains
> this. I'd be interested in reading that at least (maybe others would like
> to also).
>
> :-)
>
> -Josh
> ________________________________
> From: Alex Gaynor [alex.gaynor at gmail.com<mailto:alex.gaynor at gmail.com>]
> Sent: Tuesday, September 10, 2013 8:18 AM
> To: OpenStack Development Mailing List
> Subject: Re: [openstack-dev] OpenStack + PyPy: Status and goals
>
> Hi Roman,
>
> Yes eventlet works well on PyPy, both Marconi and Swift use it.
>
> Alex
>
>
> On Mon, Sep 9, 2013 at 10:15 PM, Roman Podolyaka <rpodolyaka at mirantis.com
> <mailto:rpodolyaka at mirantis.com>> wrote:
> Hi Alex,
>
> That's really cool! I believe, performance is not the only benefit we can
> get from running OpenStack projects on PyPy. We can also improve the
> overall "correctness" of our code (as PyPy behaves differently with
> non-closed files, etc), just like compiling of your C/C++ app using
> different compilers can show hidden errors.
>
> And what about eventlet? Does it work well on PyPy? (as it is used in
> Nova, Neutron, etc)
>
> Thanks,
> Roman
>
>
> On Tue, Sep 10, 2013 at 12:28 AM, Alex Gaynor <alex.gaynor at gmail.com
> <mailto:alex.gaynor at gmail.com>> wrote:
> Hi all,
>
> Many of you have probably seen me send review requests in the last few
> weeks
> about adding PyPy support to various OpenStack projects. A few people were
> confused by these, so I wanted to fill everyone in on what I'm up to :)
>
> First, for those who aren't familiar with what PyPy is: PyPy is an
> implementation of the Python language which includes a high performance
> tracing
> just-in-time compiler and which is faster than CPython (the reference, and
> most
> widely deployed, implementation) on almost all workloads.
>
> The current status is:
>
> Two major projects work, both Marconi and Swift, Marconi is gating against
> PyPy
> already, Swift isn't yet since I needed to fix a few small PyPy bugs and
> those
> aren't in a release yet, expect it soon :)
>
> In terms of results, I've observed 30% performance improvements on GET
> workloads for Swift under PyPy vs. CPython (other workloads haven't been
> benchmarked tet). I believe the Marconi folks have also observed some
> performance wins, but I'll let them speak to that, I don't have the full
> details.
>
> Many python-clients projects are also working out of the box and gating:
> including novaclient, swiftclient, marconiclient, ceilometerclient,
> heatclient,
> and ironicclient!
>
> There's a few outstanding reviews to add PyPy gating for cinderclient,
> troveclient, and glanceclient.
>
> In terms of future direction:
>
> I'm going to continue to work on getting more projects running and gating
> against PyPy.
>
> Right now I'm focusing a lot of my attention on improving Swift
> performance,
> particularly under PyPy, but also under CPython.
>
> I'm hoping some day PyPy will be the default way to deploy OpenStack!
>
>
> If you're interested in getting your project running on PyPy, or looking at
> performance under it, please let me know, I'm always interested in helping!
>
> Thanks,
> Alex
>
> --
> "I disapprove of what you say, but I will defend to the death your right
> to say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
> "The people's good is the highest law." -- Cicero
> GPG Key fingerprint: 125F 5C67 DFE9 4084
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org
> >
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org
> >
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
>
> --
> "I disapprove of what you say, but I will defend to the death your right
> to say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
> "The people's good is the highest law." -- Cicero
> GPG Key fingerprint: 125F 5C67 DFE9 4084
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org
> >
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
>
> --
> "I disapprove of what you say, but I will defend to the death your right
> to say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
> "The people's good is the highest law." -- Cicero
> GPG Key fingerprint: 125F 5C67 DFE9 4084
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org
> >
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.openstack.org/pipermail/openstack-dev/attachments/20130915/b2d18ecf/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 4
> Date: Sun, 15 Sep 2013 21:51:43 -0500
> From: John Dickinson <me at not.mn>
> To: OpenStack Development Mailing List
> <openstack-dev at lists.openstack.org>
> Cc: openstack-security at lists.openstack.org, Alessandro Sorniotti1
> <ZRLASO at ch.ibm.com>, Anil Kurmus1 <ZRLKUR at ch.ibm.com>, Henry Nash
> <henry.nash at uk.ibm.com>
> Subject: Re: [openstack-dev] [Swift] Protecting the access to memcache
> Message-ID: <885CC524-57D0-4E34-B620-F5A5FFC75104 at not.mn>
> Content-Type: text/plain; charset="us-ascii"
>
> Alex,
>
> You raise two issues, so let me address them independently.
>
> First, you discuss protecting memcache for unauthorized access. Yes, this
> is something that every deployer of memcache (whether in conjunction with
> Swift or not) needs to consider. Unchecked access to memcache can allow
> information leaks and potentially cache poisoning. Memcache servers should
> be restricted in access to trusted clients. You describe one such way of
> doing so, and deployers will need to evaluate if your proposed method for
> themselves. I'd love to see you release the code around your SLIM
> implementation for Swift, but I do not think it should be in the Swift
> codebase.
>
> As to the code organization question, swift.common.memcached is a
> performant memcache client (note there are a couple of outstanding patches
> to improve this in various ways). swift.common.middleware.memcache is the
> cache middleware loaded by a Swift WSGI app, and it uses the library module
> for accessing the memcache pool. The memcache client is used by other
> middleware (eg ratelimit), so that's why it's in swift/common. The
> swift/common/middleware directory is for the modules that are available for
> a WSGI pipeline. (Note that swift.common.middleware.acl may be misplaced by
> this definition, but it's only used by tempauth.) I think the placement is
> right the way it is, and I don't think anything should move, especially
> since there potentially third party modules using these.
>
> --John
>
>
>
>
> On Sep 15, 2013, at 3:03 PM, Alexandra Shulman-Peleg <SHULMANA at il.ibm.com>
> wrote:
>
> > Hi,
> >
> > Following the declaration regarding the memcache vulnerability below, I
> > would like to raise a discussion regarding its protection. If we could
> > limit/control the access to memcache it would be easier to confine the
> > damage in case of an attack. For example, in the attached paper we added
> a
> > gatekeeper to ensure that the keys/values stored in the memcached of
> > Swift are accessed only by the tenant/domain to which they belong (e.g.,
> a
> > user from domain A can not access the cached data of users belonging to
> > domain B),
> >
> > I suggest to provide a generic mechanism allowing insertion of various
> > memcache protections as dedicated middleware modules. Practically,
> > although in Swift we have a module memcache.py which is part of
> > middleware, the module memcached.py is located under "common". What is
> the
> > motivation for this code organization? Can we move the module
> memcached.py
> > to be under "middleware" in Swift?
> >
> > Thank you very much,
> > Alex.
> >
> >
> >
> > ----------------------------------------------------------
> > Alexandra Shulman-Peleg, PhD
> > Storage Research, Cloud Platforms Dept.
> > IBM Haifa Research Lab
> > Tel: +972-3-7689530 | Fax: +972-3-7689545
> >
> >
> > From: Thierry Carrez <thierry at openstack.org>
> > To: openstack-announce at lists.openstack.org,
> > openstack at lists.openstack.org,
> > Date: 11/09/2013 06:52 PM
> > Subject: [Openstack] [OSSA 2013-025] Token revocation failure
> using
> > Keystone memcache/KVS backends (CVE-2013-4294)
> >
> >
> >
> > Signed PGP part
> > OpenStack Security Advisory: 2013-025
> > CVE: CVE-2013-4294
> > Date: September 11, 2013
> > Title: Token revocation failure using Keystone memcache/KVS backends
> > Reporter: Kieran Spear (University of Melbourne)
> > Products: Keystone
> > Affects: Folsom, Grizzly
> >
> > Description:
> > Kieran Spear from the University of Melbourne reported a vulnerability
> > in Keystone memcache and KVS token backends. The PKI token revocation
> > lists stored the entire token instead of the token ID, triggering
> > comparison failures, ultimately resulting in revoked PKI tokens still
> > being considered valid. Only Folsom and Grizzly Keystone setups making
> > use of PKI tokens with the memcache or KVS token backends are affected.
> > Havana setups, setups using UUID tokens, or setups using PKI tokens with
> > the SQL token backend are all unaffected.
> >
> > Grizzly fix:
> > https://review.openstack.org/#/c/46080/
> >
> > Folsom fix:
> > https://review.openstack.org/#/c/46079/
> >
> > References:
> > http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-4294
> > https://bugs.launchpad.net/keystone/+bug/1202952
> >
> > Regards,
> >
> > - --
> > Thierry Carrez
> > OpenStack Vulnerability Management Team
> >
> >
> > _______________________________________________
> > Mailing list:
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> > Post to : openstack at lists.openstack.org
> > Unsubscribe :
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> >
> >
> <multi-tenant-isolation.pdf>_______________________________________________
> > OpenStack-dev mailing list
> > OpenStack-dev at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: signature.asc
> Type: application/pgp-signature
> Size: 455 bytes
> Desc: Message signed with OpenPGP using GPGMail
> URL: <
> http://lists.openstack.org/pipermail/openstack-dev/attachments/20130915/27969a8b/attachment-0001.pgp
> >
>
> ------------------------------
>
> Message: 5
> Date: Sun, 15 Sep 2013 22:30:04 -0500
> From: Monty Taylor <mordred at inaugust.com>
> To: openstack-dev at lists.openstack.org
> Subject: Re: [openstack-dev] When will we stop adding new Python
> modules to requirements
> Message-ID: <52367B3C.2060108 at inaugust.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
>
>
> On 09/15/2013 01:47 PM, Alex Gaynor wrote:
> > Falcon was included as a result of Marconi moving from stackforge to
> > being incubated. sphinxcontrib-programoutput doesn't appear to have been
> > added at all, it's still under
> > review: https://review.openstack.org/#/c/46325/
>
> I agree with Alex and Morgan. falcon was the marconi thing.
> diskimage-builder and tripleo-image-elements are part of an OpenStack
> program.
>
> sphinxcontrib-programoutput is only a build depend for docs - but I
> think you're made a good point, and we should be in requirements freeze.
> Let's hold off on that one until icehouse opens.
> >
> > On Sun, Sep 15, 2013 at 11:39 AM, Morgan Fainberg <m at metacloud.com
> > <mailto:m at metacloud.com>> wrote:
> >
> > Thomas,
> >
> > A couple if those appear to be managed by the OpenStack community
> > (e.g. diskimage-builder), which likely should be included in either
> > case. I would say if it is covered under the OpenStack proper list
> > of git repos (e.g. https://github.com/openstack ) it should likely
> > be included for packaging ?if it requires packaging). With that
> > being said, I agree that it make sense for other (non-openstack)
> > libraries to be added carefully late in the cycle. Perhaps the best
> > would be to limit additions to prior to the release Feature-Freeze.
> >
> > Cheers,
> > Morgan Fainberg
> >
> > On Sunday, September 15, 2013, Thomas Goirand wrote:
> >
> > Hi,
> >
> > Short version: the global-requirements.txt should be frozen asap
> > because
> > otherwise, packages wont be ready.
> >
> > Longer version:
> >
> > I'm getting worried that, even after Havana b3 is released, we
> > are still
> > getting some new Python modules added to the requirements
> > repository.
> >
> > In Debian, every new package has to go through a review process,
> > called
> > the NEW queue. FTP masters review both the freeness of a
> > package, the
> > exactitude of debian/copyright, and the general packaging
> quality.
> > Unfortunately, this review process can take a lot of time. At
> > best, it
> > is processed within a week (which is what happened for more than
> > a year
> > before November 2012), but in the worse case, it could take up
> to a
> > month or 2 (this was the case up to the end of last summer,
> > thanks to
> > new manpower in the FTP team).
> >
> > So I need to point it out: adding new Python modules at the end
> of a
> > release adds more risk that I will be missing some Python
> > modules within
> > the Debian archive when Havana will be released.
> >
> > I wouldn't have to write this mail if this was only a single
> > module or
> > something. Though that's not the case, we have 4 packages added
> this
> > last week:
> > - falcon
> > - diskimage-builder
> > - tripleo-image-elements
> > - sphinxcontrib-programoutput
> >
> > I do understand that they might be absolutely needed, though it
> > would be
> > nice if additions to the global-requirements.txt file stopped at
> > some
> > point. And as far as I am concerned, the sooner the better, so
> that
> > there's enough time to get the packages packaged, checked and
> > tested,
> > uploaded, approved by the FTP masters, and ready in time in Sid.
> >
> > Cheers,
> >
> > Thomas
> >
> > _______________________________________________
> > OpenStack-dev mailing list
> > OpenStack-dev at lists.openstack.org
> >
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >
> > _______________________________________________
> > OpenStack-dev mailing list
> > OpenStack-dev at lists.openstack.org
> > <mailto:OpenStack-dev at lists.openstack.org>
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >
> >
> >
> > --
> > "I disapprove of what you say, but I will defend to the death your right
> > to say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
> > "The people's good is the highest law." -- Cicero
> > GPG Key fingerprint: 125F 5C67 DFE9 4084
> >
> >
> > _______________________________________________
> > OpenStack-dev mailing list
> > OpenStack-dev at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
>
>
> ------------------------------
>
> Message: 6
> Date: Sun, 15 Sep 2013 22:32:26 -0500
> From: Monty Taylor <mordred at inaugust.com>
> To: openstack-dev at lists.openstack.org
> Subject: Re: [openstack-dev] python-simplejson 2.0.0 errors
> Message-ID: <52367BCA.3050104 at inaugust.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> On 09/15/2013 10:50 AM, Thomas Goirand wrote:
> > Hi,
> >
> > There's jsonschema 2.0.0 in Sid, and when I build some of the OpenStack
> > packages, I get a huge list of requirement parsing errors:
> >
> > 2013-09-12 17:05:55.720 26018 ERROR stevedore.extension [-] Could not
> > load 'file': (jsonschema 2.0.0 (/usr/lib/python2.7/dist-packages),
> > Requirement.parse('jsonschema>=0.7,<2'))
> > 2013-09-12 17:05:55.720 26018 ERROR stevedore.extension [-] (jsonschema
> > 2.0.0 (/usr/lib/python2.7/dist-packages),
> > Requirement.parse('jsonschema>=0.7,<2'))
>
> This is very weird - that requirement is not one that our file has.
>
> I suggest you add SKIP_PIP_INSTALL=1 to the debian/rules files on all of
> the OpenStack things you are packaging - I think it will make things
> like that go away - since you are processing depends at the apt side,
> there is no need to process them at the python level at runtime too.
>
> > Though, when I have a look at the requirements.txt and
> > test-requirements.txt of nova, jsonschema has:
> >
> > requirements.txt: jsonschema>=1.3.0,!=1.4.0
> >
> > This seems to be fine, so I don't understand what is conflicting. Doing
> > a "grep -r jsonschema" on the nova sources gives no result.
> >
> > So my questions are:
> > - what is creating these parse errors, and how to fix them?
> > - could we make it so that OpenStack supports jsonschema 2.0.0, which is
> > now in Sid? Where should I look into then?
> > - why do we have the above error, while global-requirements.txt doesn't
> > ping jsonschema to <2?
> >
> > I would very much like to have this resolved, since that's completely
> > destroying the unit test results of multiple Debian packages for Havana
> > b3, including Nova.
> >
> > Cheers,
> >
> > Thomas Goirand (zigo)
> >
> > _______________________________________________
> > OpenStack-dev mailing list
> > OpenStack-dev at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
>
>
> ------------------------------
>
> Message: 7
> Date: Mon, 16 Sep 2013 09:24:15 +0200
> From: Matthias Runge <mrunge at redhat.com>
> To: openstack-dev at lists.openstack.org
> Subject: Re: [openstack-dev] When will we stop adding new Python
> modules to requirements
> Message-ID: <5236B21F.3030509 at redhat.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> On 16/09/13 05:30, Monty Taylor wrote:
> >
> >
> > On 09/15/2013 01:47 PM, Alex Gaynor wrote:
> >> Falcon was included as a result of Marconi moving from stackforge to
> >> being incubated. sphinxcontrib-programoutput doesn't appear to have been
> >> added at all, it's still under
> >> review: https://review.openstack.org/#/c/46325/
> >
> > I agree with Alex and Morgan. falcon was the marconi thing.
> > diskimage-builder and tripleo-image-elements are part of an OpenStack
> > program.
> >
> > sphinxcontrib-programoutput is only a build depend for docs - but I
> > think you're made a good point, and we should be in requirements freeze.
> > Let's hold off on that one until icehouse opens.
>
>
> Not to forget python-troveclient, which is currently a hard requirement
> for Horizon.
>
> During the review for python-troveclient, it was discovered, troveclient
> still references reddwarfclient (in docs/source).
>
> Matthias
>
>
>
> ------------------------------
>
> Message: 8
> Date: Mon, 16 Sep 2013 01:13:01 -0700 (PDT)
> From: Vui Chiap Lam <vuichiap at vmware.com>
> To: OpenStack Development Mailing List
> <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] How to create vmdk for openstack usage
> Message-ID:
> <961639435.59750241.1379319181061.JavaMail.root at vmware.com>
> Content-Type: text/plain; charset="utf-8"
>
> Hi Jason,
>
> What happens if you forgo the converting to lsilogic, and instead upload
> the disk to glance as an ide disk (using --property vmware_adaptertype=ide)?
>
> Also, just reiterating the docs and Dan's comments,
>
> After obtaining a sparse ide vmdk from "qemu-img convert", due to a bug in
> the VMware nova driver, you need to convert the vmdk to a thin or
> preallocated disk.
> You can do this one of the following tools:
> - vmkfstools.pl referenced in the DeveloperGuide Appendix
> - vmkfstools directly if you can ssh into an ESX machine
> - vmware-vdiskmanager (comes bundled with VMware Fusion or VMware
> Workstation)
> (e.g. '/Applications/VMware
> Fusion.app/Contents/Library/vmware-vdiskmanager' -r our_sparse_ide.vmdk -t
> 4 converted.vmdk
> After this step you should have a converted .vmdk and a converted
> -flat.vmdk.
> At this point converted -flat.vmdk (not the descriptor file converted
> .vmdk) can be uploaded to with --property vmware_adaptertype=ide as an ide
> image
>
> If this works, we can worry about converting the disk to SCSI next.
>
> Regards,
> Vui
>
> ----- Original Message -----
>
> | From: "Jason Zhang" <bearovercloud at gmail.com>
> | To: "OpenStack Development Mailing List" <
> openstack-dev at lists.openstack.org>
> | Sent: Friday, September 13, 2013 4:09:47 PM
> | Subject: Re: [openstack-dev] How to create vmdk for openstack usage
>
> | Hi Dan,
>
> | Thank you very much for your reply.
>
> | We tested again and it still does not work, can you give more information
> | about how the vmdk's were created?
> | I.e the tool used to create the debian and trend vmdk's listed here
> |
> https://wiki.openstack.org/wiki/NovaVMware/DeveloperGuide#Glance_Initial_Setup
>
> | Using qemu-img convert to convert a qcow2 or raw image to vmdk doesn't
> seem
> | to work, for example, by using
> | qemu-img convert -f qcow2 -O vmdk <input-file.qcow2> <output-file.vmdk>
> | The command always converts to a vmdk which is of adapter type 'ide'
> other
> | than lsilogic.
>
> | We modified the adapter type to lsilogic and uploading it to glance by
> using,
>
> | glance image-create --name=<name> --disk-format=vmdk
> --container-format=bare
> | --is-public=true --property vmware_adaptertype=lsiLogic --property
> | vmware_disktype=thin --property vmware_ostype=ubuntu64Guest <
> | output-file.vmdk
> | or
> | glance image-create --name=<name> --disk-format=vmdk
> --container-format=bare
> | --is-public=true --property vmware_adaptertype=lsiLogic --property
> | vmware-disktype="preallocated" --property vmware_disktype=thin --property
> | vmware_ostype=ubuntu64Guest < output-file.vmdk
>
> | doesn't seem to work. Even after tying the steps under
> | https://wiki.openstack.org/wiki/NovaVMware/DeveloperGuide#Appendix
>
> | It seems the patch to convert into a scsi disk, has not been merged yet:
> | https://bugs.launchpad.net/qemu/+bug/545089
>
> | Thanks in advance!
>
> | Best regards,
>
> | Jason
>
> | On 9/12/13 12:48 PM, Dan Wendlandt wrote:
>
> | | Hi Jason,
> |
>
> | | The best place to look is the official openstack compute documentation
> that
> | | covers vSphere in Nova:
> | |
> http://docs.openstack.org/trunk/openstack-compute/admin/content/vmware.html
> |
>
> | | In particular, check out the section titled "Images with VMware
> vSphere"
> | | (pasted below). As that text suggests, the most likely issue with your
> VMDK
> | | not booting is that you may have passed the wrong vmware_adaptertype to
> | | glance when creating the image. Also note the statement indicating
> that all
> | | VMDK images must be "flat" (i.e., single file), otherwise Glance will
> be
> | | confused.
> |
>
> | | Dan
> |
>
> | | Images with VMware vSphere
> |
>
> | | When using either VMware driver, images should be uploaded to the
> OpenStack
> | | Image Service in the VMDK format. Both thick and thin images are
> currently
> | | supported and all images must be flat (i.e. contained within 1 file).
> For
> | | example
> |
>
> | | To load a thick image with a SCSI adaptor:
> |
> | | $ glance image-create name="ubuntu-thick-scsi" disk_format=vmdk
> | | container_format=bare \
> |
> | | is_public=true --property vmware_adaptertype="lsiLogic" \
> |
> | | --property vmware_disktype="preallocated" \
> |
> | | --property vmware_ostype="ubuntu64Guest" < ubuntuLTS-flat.vmdk
> |
>
> | | To load a thin image with an IDE adaptor:
> |
> | | $ glance image-create name="unbuntu-thin-ide" disk_format=vmdk
> | | container_format=bare \
> |
> | | is_public=true --property vmware_adaptertype="ide" \
> |
> | | --property vmware_disktype="thin" \
> |
> | | --property vmware_ostype="ubuntu64Guest" < unbuntuLTS-thin-flat.vmdk
> |
>
> | | The complete list of supported vmware disk properties is documented in
> the
> | | Image Management section. It's critical that the adaptertype is
> correct; In
> | | fact, the image will not boot with the incorrect adaptertype. If you
> have
> | | the meta-data VMDK file the the ddb.adapterType property specifies the
> | | adaptertype. The default adaptertype is "lsilogic" which is SCSI.
> |
>
> | | On Thu, Sep 12, 2013 at 11:29 AM, Jason Zhang <
> bearovercloud at gmail.com >
> | | wrote:
> |
>
> | | | Hi Dears,
> | |
> |
>
> | | | In the document
> https://wiki.openstack.org/wiki/NovaVMware/DeveloperGuide
> | | | under the 'Get an initial VMDK to work with ',
> | |
> |
> | | | its said, 'There are a lot of ?gotchas? around what VMDK disks work
> with
> | | | OpenStack + vSphere,'.
> | |
> |
> | | | The appendix section lists one of the gotchas. Are there any more
> | | | gotchas?
> | |
> |
>
> | | | During our testing, the vmdk instance on boot-up gives a 'Operating
> | | | System
> | | | not found' error,
> | |
> |
> | | | I am not sure whether this is a already known issue or not.
> | |
> |
>
> | | | Thanks in advance!
> | |
> |
>
> | | | Best regards,
> | |
> |
>
> | | | Jason
> | |
> |
>
> | | | _______________________________________________
> | |
> |
> | | | OpenStack-dev mailing list
> | |
> |
> | | | OpenStack-dev at lists.openstack.org
> | |
> |
> | | | http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> | |
> |
>
> | | --
> |
> | | ~~~~~~~~~~~~~~~~~~~~~~~~~~~
> |
> | | Dan Wendlandt
> |
> | | Nicira, Inc: www.nicira.com
> |
> | | twitter: danwendlandt
> |
> | | ~~~~~~~~~~~~~~~~~~~~~~~~~~~
> |
>
> | | _______________________________________________
> |
> | | OpenStack-dev mailing list OpenStack-dev at lists.openstack.org
> | | http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> |
>
> | _______________________________________________
> | OpenStack-dev mailing list
> | OpenStack-dev at lists.openstack.org
> | http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.openstack.org/pipermail/openstack-dev/attachments/20130916/46af009a/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 9
> Date: Mon, 16 Sep 2013 11:26:12 +0300
> From: Roman Podolyaka <rpodolyaka at mirantis.com>
> To: OpenStack Development Mailing List
> <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] Oslo.db possible module?
> Message-ID:
> <
> CAKA_ueDYUdhZAV6FqGrX1TqPPmUib70u917ByZB8VY+Bcppsvg at mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Hi Joshua,
>
> This looks great!
>
> We definitely should consider this to become the base of oslo.db, as
> currently DB code in oslo-incubator depends on oslo-config and has a few
> drawbacks (e. g. global engine and session instances).
>
> We could discuss this in details at the summit (Boris has already proposed
> a session for oslo.db lib - http://summit.openstack.org/cfp/details/13).
>
> Thanks,
> Roman
>
>
> On Fri, Sep 13, 2013 at 9:04 PM, Joshua Harlow <harlowja at yahoo-inc.com
> >wrote:
>
> > Hi guys,
> >
> > In my attempt to not use oslo.cfg in taskflow I ended up re-creating a
> > lot of what oslo-incubator db has but without the strong connection to
> > oslo.cfg,
> >
> > I was thinking that a majority of this code (which is also partially
> > ceilometer influenced) could become oslo.db,
> >
> >
> >
> https://github.com/stackforge/taskflow/blob/master/taskflow/persistence/backends/impl_sqlalchemy.py(search
> > for SQLAlchemyBackend as the main class).
> >
> > It should be generic enough that it could be easily extracted to be the
> > basis for oslo.db if that is desirable,
> >
> > Thoughts/comments/questions welcome :-)
> >
> > -Josh
> >
> > _______________________________________________
> > OpenStack-dev mailing list
> > OpenStack-dev at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.openstack.org/pipermail/openstack-dev/attachments/20130916/a81fc6c1/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 10
> Date: Mon, 16 Sep 2013 10:32:34 +0200
> From: Flavio Percoco <flavio at redhat.com>
> To: OpenStack Development Mailing List
> <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] Oslo.db possible module?
> Message-ID: <20130916083234.GA26106 at redhat.com>
> Content-Type: text/plain; charset=utf-8; format=flowed
>
> On 13/09/13 18:04 +0000, Joshua Harlow wrote:
> >Hi guys,
> >
> >In my attempt to not use oslo.cfg in taskflow I ended up re-creating a
> lot of
> >what oslo-incubator db has but without the strong connection to oslo.cfg,
> >
> >I was thinking that a majority of this code (which is also partially
> ceilometer
> >influenced) could become oslo.db,
> >
> >https://github.com/stackforge/taskflow/blob/master/taskflow/persistence/
> >backends/impl_sqlalchemy.py (search for SQLAlchemyBackend as the main
> class).
> >
> >It should be generic enough that it could be easily extracted to be the
> basis
> >for oslo.db if that is desirable,
> >
> >Thoughts/comments/questions welcome :-)
> >
>
> Not having looked at the code in detail, I'd like to ask what the are
> the differences between this implementation and the one currently in
> Oslo Incubator?
>
> Also, when you say you're not using oslo.cfg, do you mean you're not
> using the global instance or that you're not using it at all? There
> are good examples at how it is possible to avoid using the global
> instance in oslo.messaging.
>
> I'd like to hear boris-42 thoughts about this as well - since he's
> been working on that with other folks - and perhaps bring this up at
> the oslo.db session[0] -assuming it'll get accepted.
>
> Cheers,
> FF
>
> [0] http://summit.openstack.org/cfp/details/13
>
>
> --
> @flaper87
> Flavio Percoco
>
>
>
> ------------------------------
>
> Message: 11
> Date: Mon, 16 Sep 2013 12:36:03 +0400
> From: Boris Pavlovic <boris at pavlovic.me>
> To: OpenStack Development Mailing List
> <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] Oslo.db possible module?
> Message-ID:
> <
> CAD85om1OxJ6hOKTErDV2j5OcXJ1achpeouf22nfgv9iwyZv0bA at mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Hi Joshua,
>
>
> +1 to discuss it on oslo.db session!=)
>
>
> Best regards,
> Boris Pavlovic
> --
> Mirantis Inc.
>
>
> On Mon, Sep 16, 2013 at 12:26 PM, Roman Podolyaka
> <rpodolyaka at mirantis.com>wrote:
>
> > Hi Joshua,
> >
> > This looks great!
> >
> > We definitely should consider this to become the base of oslo.db, as
> > currently DB code in oslo-incubator depends on oslo-config and has a few
> > drawbacks (e. g. global engine and session instances).
> >
> > We could discuss this in details at the summit (Boris has already
> proposed
> > a session for oslo.db lib - http://summit.openstack.org/cfp/details/13).
> >
> > Thanks,
> > Roman
> >
> >
> > On Fri, Sep 13, 2013 at 9:04 PM, Joshua Harlow <harlowja at yahoo-inc.com
> >wrote:
> >
> >> Hi guys,
> >>
> >> In my attempt to not use oslo.cfg in taskflow I ended up re-creating a
> >> lot of what oslo-incubator db has but without the strong connection to
> >> oslo.cfg,
> >>
> >> I was thinking that a majority of this code (which is also partially
> >> ceilometer influenced) could become oslo.db,
> >>
> >>
> >>
> https://github.com/stackforge/taskflow/blob/master/taskflow/persistence/backends/impl_sqlalchemy.py(search
> >> for SQLAlchemyBackend as the main class).
> >>
> >> It should be generic enough that it could be easily extracted to be the
> >> basis for oslo.db if that is desirable,
> >>
> >> Thoughts/comments/questions welcome :-)
> >>
> >> -Josh
> >>
> >> _______________________________________________
> >> OpenStack-dev mailing list
> >> OpenStack-dev at lists.openstack.org
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>
> >>
> >
> > _______________________________________________
> > OpenStack-dev mailing list
> > OpenStack-dev at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.openstack.org/pipermail/openstack-dev/attachments/20130916/10bd8336/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 12
> Date: Mon, 16 Sep 2013 10:36:28 +0200
> From: Julien Danjou <julien at danjou.info>
> To: Nachi Ueno <nachi at ntti3.com>
> Cc: OpenStack Development Mailing List
> <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [Ceilometer][IceHouse] Ceilometer +
> Kibana + ElasticSearch Integration
> Message-ID: <8738p5noxf.fsf at dex.adm.naquadah.org>
> Content-Type: text/plain; charset="us-ascii"
>
> On Fri, Sep 13 2013, Nachi Ueno wrote:
>
> Hi Nachi,
>
> That looks like a good idea, thanks for submitting.
>
> > [1] We should add elastic search query api for ceilometer? or we
> > should let user kick ElasticSearch api directory?
> >
> > Note that ElasticSearch has no tenant based authentication, in that
> > case we need to integrate Keystone and ElasticSearch. (or Horizon)
>
> This should provide data retrieval too, otherwise it has much less
> interest.
>
> > [2] Log (syslog or any application log) should be stored in
> > Ceilometer? (or it should be new OpenStack project? )
>
> Ceilometer already has on the roadmap events/notifications storage, ES
> would really fit here I think. As I've some plan to use the notification
> system as a logging back-end, that would probably cover part of this.
>
> --
> Julien Danjou
> // Free Software hacker / independent consultant
> // http://julien.danjou.info
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: signature.asc
> Type: application/pgp-signature
> Size: 835 bytes
> Desc: not available
> URL: <
> http://lists.openstack.org/pipermail/openstack-dev/attachments/20130916/16918b9e/attachment-0001.pgp
> >
>
> ------------------------------
>
> Message: 13
> Date: Mon, 16 Sep 2013 11:22:50 +0200
> From: Chmouel Boudjnah <chmouel at enovance.com>
> To: OpenStack Development Mailing List
> <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [Swift] Protecting the access to memcache
> Message-ID: <m2pps9azo5.fsf at chmouel.com>
> Content-Type: text/plain
>
> John Dickinson <me at not.mn> writes:
>
> > available for a WSGI pipeline. (Note that swift.common.middleware.acl
> > may be misplaced by this definition, but it's only used by tempauth.)
>
> and keystone_auth FYI.
>
> Chmouel.
>
>
>
> ------------------------------
>
> Message: 14
> Date: Mon, 16 Sep 2013 10:21:29 +0000
> From: "Day, Phil" <philip.day at hp.com>
> To: "OpenStack Development Mailing List
> (openstack-dev at lists.openstack.org)"
> <openstack-dev at lists.openstack.org>
> Subject: [openstack-dev] [Nova] Quick review from a core please for
> simple bug fix
> Message-ID:
> <
> BD26CCD58723F74AA8E6BCB31052A1F006E3E67E at G6W2490.americas.hpqcorp.net>
>
> Content-Type: text/plain; charset="us-ascii"
>
> Hi Folks,
>
> Could one more core look at the following simple bug fix please:
> https://review.openstack.org/#/c/46486/ - which allows the system clean
> up VMs from deleted instances.
>
>
> Its already got one +2 and four +1's
>
> Thanks
> Phil
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.openstack.org/pipermail/openstack-dev/attachments/20130916/ce305a2d/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 15
> Date: Mon, 16 Sep 2013 20:31:35 +1000
> From: Michael Still <mikal at stillhq.com>
> To: OpenStack Development Mailing List
> <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] Backwards incompatible migration changes
> - Discussion
> Message-ID:
> <
> CAEd1pt6WG7J6jQz9KjXu0TNi3O5AX-pixoXJyUG8RgkioFL7rA at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> On Fri, Sep 13, 2013 at 7:51 AM, Dolph Mathews <dolph.mathews at gmail.com>
> wrote:
>
> > ++ Data backups are a solved problem, and no DB admin should trust an
> > application to perform its own backups.
>
> I'm not completely sure I agree. Consider the case where a cloud with
> active users undertakes an upgrade. The migrations run, and they allow
> user traffic to hit the installation. They then discover there is a
> serious problem and now need to rollback. However, they can't just
> restore a database backup, because the database is no longer in a
> consistent state compared with the hypervisors -- users might have
> created or deleted instances for example.
>
> In this scenario if we could downgrade reliably, they could force a
> downgrade with db sync, and then revert the packages they had
> installed to the previous version.
>
> How would they handle this scenario with just database backups?
>
> Michael
>
> --
> Rackspace Australia
>
>
>
> ------------------------------
>
> Message: 16
> Date: Mon, 16 Sep 2013 20:42:36 +1000
> From: Michael Still <mikal at stillhq.com>
> To: OpenStack Development Mailing List
> <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [Nova] Quick review from a core please
> for simple bug fix
> Message-ID:
> <
> CAEd1pt4cLVCPj+NGzFOAT2L8yf+1in9f+-nPN+w_BJGfZw+s-Q at mail.gmail.com>
> Content-Type: text/plain; charset=windows-1252
>
> Done.
>
> Cheers,
> Michael
>
> On Mon, Sep 16, 2013 at 8:21 PM, Day, Phil <philip.day at hp.com> wrote:
> > Hi Folks,
> >
> >
> >
> > Could one more core look at the following simple bug fix please:
> > https://review.openstack.org/#/c/46486/ - which allows the system clean
> up
> > VMs from deleted instances.
> >
> >
> >
> >
> >
> > Its already got one +2 and four +1?s
> >
> >
> >
> > Thanks
> >
> > Phil
> >
> >
> > _______________________________________________
> > OpenStack-dev mailing list
> > OpenStack-dev at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
>
>
> --
> Rackspace Australia
>
>
>
> ------------------------------
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> End of OpenStack-dev Digest, Vol 17, Issue 25
> *********************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130916/3af870db/attachment.html>
More information about the OpenStack-dev
mailing list