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