[openstack-dev] [Savanna] validation error when launching cluster ala quickstart guide
Dmitry Mescheryakov
dmescheryakov at mirantis.com
Mon Sep 16 15:13:22 UTC 2013
Kesten,
The exception you see is definitely caused by the bug you've pointed out:
https://bugs.launchpad.net/savanna/+bug/1223934
I think that stacktraces are different because you use a different version
of novaclient: rackspace-novaclient==1.3.
So far only some folks experienced that problem and as you see we don't
have a solution for it yet.
Dmitry
2013/9/16 kesten broughton <kesten.broughton at gmail.com>
> 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
>> *********************************************
>>
>
>
> _______________________________________________
> 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/e7b7c55e/attachment-0001.html>
More information about the OpenStack-dev
mailing list