<div dir="ltr">How do I upload the inventory file from the cash register to the web portal * e-coomerce* , for eg a common grocery owner wish to upload its product with price on the web portal. any help would be highly appreciated.<br></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature"><div dir="ltr"><div><div><span style="color:rgb(153,153,153)"><font size="2">Best Regards<br>Ajay Sharma<br><br></font></span></div><span style="color:rgb(153,153,153)"><font size="2"></font></span></div><br></div></div></div>
<br><div class="gmail_quote">On Wed, May 20, 2015 at 8:12 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:0 0 0 .8ex;border-left:1px #ccc 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: [fuel] Enable healthcheck middleware (Swann Croiset)<br>
2. Re: [oslo] needed, driver for oslo.db thursday session<br>
(Roman Podoliaka)<br>
3. Re: [Fuel] python-fuelclient 6.1.0 is released (Oleg Gelbukh)<br>
4. [glance] missing implementation on glance basic quota (Gareth)<br>
5. Re: [oslo] needed, driver for oslo.db thursday session<br>
(Mike Bayer)<br>
6. [nova] libvirt: _do_quality_warnings and the hypervisor<br>
support matrix (Markus Zoeller)<br>
7. Re: [Manila] Question to driver maintainers (Csaba Henk)<br>
8. Re: missing implementation on glance basic quota (Nikhil Komawar)<br>
9. Re: [nova] libvirt: _do_quality_warnings and the hypervisor<br>
support matrix (Daniel P. Berrange)<br>
10. [Security][Glance] Design session for image<br>
signing/encryption (Clark, Robert Graham)<br>
11. Re: [Security][Glance] Design session for image<br>
signing/encryption (Louis Taylor)<br>
12. Re: [nova] libvirt: _do_quality_warnings and the hypervisor<br>
support matrix (Markus Zoeller)<br>
13. Re: [oslo] needed, driver for oslo.db thursday session<br>
(Davanum Srinivas)<br>
14. Re: [oslo] needed, driver for oslo.db thursday session<br>
(Davanum Srinivas)<br>
15. [nova][glance] Format of 'locations' data in image metadata ?<br>
(Daniel P. Berrange)<br>
16. Re: [oslo] needed, driver for oslo.db thursday session<br>
(Jeremy Stanley)<br>
17. Re: [Glance] glance social event at Vancouver summit<br>
(Alexander Tivelkov)<br>
18. Re: [nova][glance] Format of 'locations' data in image<br>
metadata ? (Nikhil Komawar)<br>
19. Re: [nova-docker] Status update (ADAMS, STEVEN E)<br>
20. Re: [nova-docker] Status update (Davanum Srinivas)<br>
21. Re: [Manila] Question to driver maintainers (Ben Swartzlander)<br>
22. [NFV][Tacker] OpenStack based VNF Manager (Sridhar Ramaswamy)<br>
23. Re: [Fuel][Plugin] Contributor license agreement for fuel<br>
plugin code? (Andrew Woodward)<br>
24. Re: [Fuel] Speed Up RabbitMQ Recovering (Andrew Woodward)<br>
25. Re: [surge] Introducing Surge - rapid deploy/scale stream<br>
processing systems on OpenStack (Sergey Lukjanov)<br>
26. Re: [new][cognitive] Announcing Cognitive - a project to<br>
deliver Machine Learning as a Service for OpenStack (Sergey Lukjanov)<br>
27. Re: [surge] Introducing Surge - rapid deploy/scale stream<br>
processing systems on OpenStack (Sergey Lukjanov)<br>
28. Re: [glance] missing implementation on glance basic quota<br>
(Fei Long Wang)<br>
29. [nova] Tempest failure help (Sam Morrison)<br>
30. [sahara] no meetings May 21 and 28 (Sergey Lukjanov)<br>
31. [security] / IDS + openstack meeting in Vancouver 4:10<br>
Wednesday May 20 (Dan Lambright)<br>
32. Re: [all] gate pep8 jobs broken today (Victor Stinner)<br>
33. Re: / IDS + openstack meeting in Vancouver 4:10 Wednesday May<br>
20 (Alan Kavanagh)<br>
34. Re: [nova][glance] Format of 'locations' data in image<br>
metadata ? (Flavio Percoco)<br>
35. Re: [security] / IDS + openstack meeting in Vancouver 4:10<br>
Wednesday May 20 (Clark, Robert Graham)<br>
36. Re: [all] gate pep8 jobs broken today (Robert Collins)<br>
37. Re: [nova] Tempest failure help (Matt Riedemann)<br>
38. [nova] Friday summit meetup etherpad (Matt Riedemann)<br>
39. Re: [all] gate pep8 jobs broken today (Robert Collins)<br>
40. [pbr] 1.0.1 released (Robert Collins)<br>
41. [barbican] Nominating Kaitlin Farr for barbican-core<br>
(Douglas Mendiz?bal)<br>
42. [security] Nominating Mike McCune as Security-Doc Core<br>
(Dillon, Nathaniel)<br>
43. Re: [Fuel] Speed Up RabbitMQ Recovering (Andrew Beekhof)<br>
44. Re: [neutron] How should edge services APIs integrate into<br>
Neutron? (A, Keshava)<br>
<br>
<br>
----------------------------------------------------------------------<br>
<br>
Message: 1<br>
Date: Tue, 19 May 2015 14:28:10 +0200<br>
From: Swann Croiset <<a href="mailto:scroiset@mirantis.com">scroiset@mirantis.com</a>><br>
To: "OpenStack Development Mailing List (not for usage questions)"<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] [fuel] Enable healthcheck middleware<br>
Message-ID:<br>
<CAOmgvhz8BT2ayfCFxsw96Kv749ML2-7uoBYJqY8GRQg=<a href="mailto:a1vAEg@mail.gmail.com">a1vAEg@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
Thanks for your feedback.<br>
I probably start next week and provide links here.<br>
<br>
On Wed, May 13, 2015 at 10:40 PM, Andrew Woodward <<a href="mailto:xarses@gmail.com">xarses@gmail.com</a>> wrote:<br>
<br>
> Sounds good, lets ensure that we create a blue-print in LP and some form<br>
> of initial spec with the expected design<br>
><br>
><br>
> On Wed, May 13, 2015 at 9:38 AM Jay Pipes <<a href="mailto:jaypipes@gmail.com">jaypipes@gmail.com</a>> wrote:<br>
><br>
>> ++<br>
>><br>
>> On 05/13/2015 11:57 AM, Swann Croiset wrote:<br>
>> > Hi Fuelers,<br>
>> ><br>
>> > It would be valuable to configure the healthcheck middleware [0] for all<br>
>> > services deployed by fuel, available since Kilo.<br>
>> ><br>
>> > Several (obvious) benefits:<br>
>> > - Provide a common API for healthcheck across OpenStack services<br>
>> > - HAproxy performs more accurate HTTP checks for its backend status<br>
>> > - Operators can disable a service (maintenance mode, test, ..) by<br>
>> > creating a simple file w/o stopping the service.<br>
>> > - monitoring systems can leverage this API to provide insight<br>
>> > information of service status with a lighten checks w/o authentication<br>
>> > (in opposition to heavily check for specific resources) <-- here my use<br>
>> > case<br>
>> ><br>
>> > Does it sound reasonable to target this for 7.0? any clue? drawback?<br>
>> > I can handle the writing of the spec to bootstrap this effort and maybe<br>
>> > more.<br>
>> ><br>
>> > Implementation details to estimate the workload:<br>
>> > * Configure WSGI pipelines for each project "api-paste.ini"<br>
>> > * For security reason as mentioned in the original spec [1], the<br>
>> > 'healthcheck' URI mustn't be open to the WWW:<br>
>> > * restricted access to local/management network or by auth<br>
>> > * or random/configurable URI at deployment time<br>
>> > * HAproxy "httpchk" option will be "GET /<healthcheck path>" instead of<br>
>> > the default "OPTION /"<br>
>> ><br>
>> > Parallel (future) work on oslo or whatever:<br>
>> > * extend with specific checks (DB unavailable, RabbitMQ stuck, ..) to<br>
>> > provide a detailed status of subsystem dependencies.<br>
>> ><br>
>> > [0]<br>
>> ><br>
>> <a href="http://docs.openstack.org/developer/oslo.middleware/healthcheck_plugins.html" target="_blank">http://docs.openstack.org/developer/oslo.middleware/healthcheck_plugins.html</a><br>
>> > [1]<br>
>> ><br>
>> <a href="http://git.openstack.org/cgit/openstack/oslo-specs/plain/specs/kilo/oslo-middleware-healthcheck.rst" target="_blank">http://git.openstack.org/cgit/openstack/oslo-specs/plain/specs/kilo/oslo-middleware-healthcheck.rst</a><br>
>> ><br>
>> ><br>
>> ><br>
>> __________________________________________________________________________<br>
>> > OpenStack Development Mailing List (not for usage questions)<br>
>> > Unsubscribe:<br>
>> <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</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 Development Mailing List (not for usage questions)<br>
>> Unsubscribe:<br>
>> <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</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 Development Mailing List (not for usage questions)<br>
> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</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/20150519/85a20ad4/attachment-0001.html" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20150519/85a20ad4/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 2<br>
Date: Tue, 19 May 2015 16:08:57 +0300<br>
From: Roman Podoliaka <<a href="mailto:rpodolyaka@mirantis.com">rpodolyaka@mirantis.com</a>><br>
To: "OpenStack Development Mailing List (not for usage questions)"<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] [oslo] needed, driver for oslo.db<br>
thursday session<br>
Message-ID:<br>
<CAKA_ueAPNx9yTbU73Hq_JaqvBW8kU2VC9Tm68RYozAxY=<a href="mailto:CoYRg@mail.gmail.com">CoYRg@mail.gmail.com</a>><br>
Content-Type: text/plain; charset=UTF-8<br>
<br>
Hi all,<br>
<br>
Just FYI, due to problems with obtaining a Canadian visa, neither<br>
Victor Sergeyev, nor I made it to Vancouver.<br>
<br>
I hope someone else from Oslo team can replace Mike as a session driver.<br>
<br>
Thanks,<br>
Roman<br>
<br>
On Tue, May 19, 2015 at 3:53 AM, Mike Bayer <<a href="mailto:mbayer@redhat.com">mbayer@redhat.com</a>> wrote:<br>
> Hello -<br>
><br>
> It is my extreme displeasure and frustration to announce that due to an<br>
> incredibly unfortunate choice of airline, I had to cancel my entire trip to<br>
> the Openstack summit after spending 26 hours in my home airport waiting for<br>
> my airline to produce a working airplane (which they did not).<br>
><br>
> I will not be able to attend in person the Thursday oslo.db session I was to<br>
> drive, so a replacement will be needed. I am also lamenting not being able<br>
> to meet so many of you who I hoped very much to meet.<br>
><br>
> Hope you all enjoy the summit and I hope our paths can cross at future<br>
> events.<br>
><br>
> - mike<br>
><br>
><br>
><br>
> __________________________________________________________________________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</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>
Message: 3<br>
Date: Tue, 19 May 2015 17:01:49 +0300<br>
From: Oleg Gelbukh <<a href="mailto:ogelbukh@mirantis.com">ogelbukh@mirantis.com</a>><br>
To: "OpenStack Development Mailing List (not for usage questions)"<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] [Fuel] python-fuelclient 6.1.0 is<br>
released<br>
Message-ID:<br>
<<a href="mailto:CAFkLEwr1U_1V7p7Uu8yUzbGGf0jkzuzMKKK5QNqeEOoqCGYSJw@mail.gmail.com">CAFkLEwr1U_1V7p7Uu8yUzbGGf0jkzuzMKKK5QNqeEOoqCGYSJw@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
Roman,<br>
<br>
This is awesome news! Thank you for this huge improvement for developers<br>
who consume Fuel API.<br>
<br>
Could you please elaborate on backwards compatibility between the new<br>
client and older versions of Fuel API? For example, is it possible to use<br>
the new client to work with Fuel 4.x? 5.x?<br>
<br>
--<br>
Best regards,<br>
Oleg Gelbukh<br>
<br>
On Fri, May 15, 2015 at 5:39 PM, Roman Prykhodchenko <<a href="mailto:me@romcheg.me">me@romcheg.me</a>> wrote:<br>
<br>
> Hi folks!<br>
><br>
> I?m glad to announce that the first independent release of Fuel Client was<br>
> published to PyPi: <a href="https://pypi.python.org/pypi/python-fuelclient" target="_blank">https://pypi.python.org/pypi/python-fuelclient</a><br>
> You can either download it from the web page or install with pip install<br>
> python-fuelclient.<br>
><br>
> What?s new:<br>
><br>
> - Fuel client is now able to run most of it?s features remotely from<br>
> Fuel?s master node.<br>
> - Old CLI was deprecated, new fuel2 utility is a preview of the new Fuel<br>
> client which will be available in the next major release<br>
> - Versioning scheme of the Fuel Client is not tightly bound to Fuel?s<br>
> version scheme anymore.<br>
> - Other improvements and bug-fixes<br>
><br>
><br>
> __________________________________________________________________________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</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/20150519/8b7590c7/attachment-0001.html" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20150519/8b7590c7/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 4<br>
Date: Tue, 19 May 2015 22:10:53 +0800<br>
From: Gareth <<a href="mailto:academicgareth@gmail.com">academicgareth@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: [openstack-dev] [glance] missing implementation on glance<br>
basic quota<br>
Message-ID:<br>
<<a href="mailto:CAAhuP_9SYvzjzZZoA-Ki9MgmZuW7XSUs0u2i-Ue2_hcXNhANZw@mail.gmail.com">CAAhuP_9SYvzjzZZoA-Ki9MgmZuW7XSUs0u2i-Ue2_hcXNhANZw@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
Hi glance guys<br>
<br>
There is a bp[0] said it would implement two basic quota usage:<br>
<br>
a, the number of image stored<br>
b, the amount of storage in occupied by a set of image<br>
<br>
However, only b is implemented in the patch[1], and a is still missing in<br>
current glance.<br>
<br>
[0] <a href="https://blueprints.launchpad.net/glance/+spec/glance-basic-quotas" target="_blank">https://blueprints.launchpad.net/glance/+spec/glance-basic-quotas</a><br>
[1] <a href="https://review.openstack.org/#/c/37993/18" target="_blank">https://review.openstack.org/#/c/37993/18</a><br>
<br>
--<br>
Gareth<br>
<br>
*Cloud Computing, OpenStack, Distributed Storage, Fitness, Basketball*<br>
*OpenStack contributor, kun_huang@freenode*<br>
*My promise: if you find any spelling or grammar mistakes in my email from<br>
Mar 1 2013, notify me *<br>
*and I'll donate $1 or ?1 to an open organization you specify.*<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20150519/35eaae6f/attachment-0001.html" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20150519/35eaae6f/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 5<br>
Date: Tue, 19 May 2015 10:24:56 -0400<br>
From: Mike Bayer <<a href="mailto:mbayer@redhat.com">mbayer@redhat.com</a>><br>
To: <a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a><br>
Subject: Re: [openstack-dev] [oslo] needed, driver for oslo.db<br>
thursday session<br>
Message-ID: <<a href="mailto:555B47B8.5070608@redhat.com">555B47B8.5070608@redhat.com</a>><br>
Content-Type: text/plain; charset=windows-1252; format=flowed<br>
<br>
ouch !<br>
<br>
<br>
maybe next summit will be on the "Lost" island. another easy place to<br>
get to ! :)<br>
<br>
<br>
<br>
<br>
On 5/19/15 9:08 AM, Roman Podoliaka wrote:<br>
> Hi all,<br>
><br>
> Just FYI, due to problems with obtaining a Canadian visa, neither<br>
> Victor Sergeyev, nor I made it to Vancouver.<br>
><br>
> I hope someone else from Oslo team can replace Mike as a session driver.<br>
><br>
> Thanks,<br>
> Roman<br>
><br>
> On Tue, May 19, 2015 at 3:53 AM, Mike Bayer <<a href="mailto:mbayer@redhat.com">mbayer@redhat.com</a>> wrote:<br>
>> Hello -<br>
>><br>
>> It is my extreme displeasure and frustration to announce that due to an<br>
>> incredibly unfortunate choice of airline, I had to cancel my entire trip to<br>
>> the Openstack summit after spending 26 hours in my home airport waiting for<br>
>> my airline to produce a working airplane (which they did not).<br>
>><br>
>> I will not be able to attend in person the Thursday oslo.db session I was to<br>
>> drive, so a replacement will be needed. I am also lamenting not being able<br>
>> to meet so many of you who I hoped very much to meet.<br>
>><br>
>> Hope you all enjoy the summit and I hope our paths can cross at future<br>
>> events.<br>
>><br>
>> - mike<br>
>><br>
>><br>
>><br>
>> __________________________________________________________________________<br>
>> OpenStack Development Mailing List (not for usage questions)<br>
>> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</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>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</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: Tue, 19 May 2015 16:41:40 +0200<br>
From: Markus Zoeller <<a href="mailto:mzoeller@de.ibm.com">mzoeller@de.ibm.com</a>><br>
To: "OpenStack Development Mailing List (not for usage questions)"<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: [openstack-dev] [nova] libvirt: _do_quality_warnings and the<br>
hypervisor support matrix<br>
Message-ID:<br>
<<a href="mailto:OFB7028464.2C12B897-ONC1257E4A.00506B48-C1257E4A.0050B850@de.ibm.com">OFB7028464.2C12B897-ONC1257E4A.00506B48-C1257E4A.0050B850@de.ibm.com</a>><br>
Content-Type: text/plain; charset="US-ASCII"<br>
<br>
The libvirt driver logs a warning if:<br>
hostarch not in (arch.I686, arch.X86_64))<br>
The warning when I start the libvirt driver on system z (arch.S390X)<br>
will be:<br>
"The libvirt driver is not tested on kvm/s390x by the OpenStack<br>
project and thus its quality can not be ensured. For more<br>
information, see:<br>
<a href="https://wiki.openstack.org/wiki/HypervisorSupportMatrix" target="_blank">https://wiki.openstack.org/wiki/HypervisorSupportMatrix</a>"<br>
<br>
I'm not quite sure if I understand that correctly. Should this be a<br>
hint that "arch.I686, arch.X86_64" is the assumed "default"?<br>
Or am I supposed to add the architecture "S390X" to this method because<br>
this platform is listed in the hypervisor support matrix?<br>
I want to avoid that customers will get a bad feeling because of the<br>
warning after starting the nova libvirt driver on a system z platform.<br>
<br>
Note: We are still working on the CI for nova<br>
<br>
Regards,<br>
Markus Zoeller (markus_z)<br>
<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 7<br>
Date: Tue, 19 May 2015 10:42:57 -0400 (EDT)<br>
From: Csaba Henk <<a href="mailto:chenk@redhat.com">chenk@redhat.com</a>><br>
To: "OpenStack Development Mailing List (not for usage questions)"<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] [Manila] Question to driver maintainers<br>
Message-ID:<br>
<<a href="mailto:1601921203.2012587.1432046577765.JavaMail.zimbra@redhat.com">1601921203.2012587.1432046577765.JavaMail.zimbra@redhat.com</a>><br>
Content-Type: text/plain; charset=utf-8<br>
<br>
Hi Igor,<br>
<br>
> From: "Igor Malinovskiy" <<a href="mailto:imalinovskiy@mirantis.com">imalinovskiy@mirantis.com</a>><br>
> To: "OpenStack Development Mailing List (not for usage questions)"<br>
> <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
> Sent: Monday, May 18, 2015 10:15:25 AM<br>
> Subject: [openstack-dev] [Manila] Question to driver maintainers<br>
...<br>
> So I want to ask driver maintainers here:<br>
> Will your driver be able to do share extending without loss of connectivity?<br>
<br>
Currenty:<br>
<br>
- glusterfs driver can<br>
- glusterfs-native won't support share extension (*)<br>
<br>
in Liberty timeframe, we are to unify the glusterfs* drivers' backend<br>
management logic, so both glusterfs driver style and glusterfs-native<br>
driver style backend management will be available for both drivers<br>
(actual choice made in configuration). So when this will be in place,<br>
the answer modifies as follows:<br>
<br>
- glusterfs and glusterfs-native will either support non-disruptive<br>
share extension, or won't support share resize at all (*) (depending<br>
on configuration)<br>
<br>
(*) There are efforts to remove this limitation in GlusterFS, but too<br>
vague at this point to make a statement on it.<br>
<br>
Csaba<br>
<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 8<br>
Date: Tue, 19 May 2015 10:50:57 -0400<br>
From: Nikhil Komawar <<a href="mailto:nik.komawar@gmail.com">nik.komawar@gmail.com</a>><br>
To: <a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a><br>
Subject: Re: [openstack-dev] missing implementation on glance basic<br>
quota<br>
Message-ID: <<a href="mailto:555B4DD1.1030405@gmail.com">555B4DD1.1030405@gmail.com</a>><br>
Content-Type: text/plain; charset="windows-1252"; Format="flowed"<br>
<br>
Hi,<br>
<br>
The implementer has indicated using a note on the BP that they are going<br>
with only the initial implementation of quota for storage of bytes and<br>
not the number of images. It seems like this should be sufficient.<br>
However, if you feel like we should implement quota for "the number of<br>
images" (also the use case would be slightly different "for number of<br>
images stored"), we would be willing to hear more on a Glance spec (<br>
<a href="https://github.com/openstack/glance-specs" target="_blank">https://github.com/openstack/glance-specs</a> ). Please file one under the<br>
liberty folder and I encourage you to attend one of the Glance weekly<br>
meetings to bring this up and show interest if you (or anyone you know)<br>
wish(es) to implement it.<br>
<br>
Thanks,<br>
Nikhil<br>
<br>
On 5/19/15 3:14 AM, Gareth wrote:<br>
> Hi glance guys<br>
><br>
> There is a bp[0] said it would implement two basic quota usage:<br>
><br>
> a, the number of image stored<br>
> b, the amount of storage in occupied by a set of image<br>
><br>
> However, only b is implemented in the patch[1], and a is still missing<br>
> in current glance.<br>
><br>
> [0] <a href="https://blueprints.launchpad.net/glance/+spec/glance-basic-quotas" target="_blank">https://blueprints.launchpad.net/glance/+spec/glance-basic-quotas</a><br>
> [1] <a href="https://review.openstack.org/#/c/37993/18" target="_blank">https://review.openstack.org/#/c/37993/18</a><br>
><br>
><br>
> __________________________________________________________________________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</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>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20150519/268751a8/attachment-0001.html" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20150519/268751a8/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 9<br>
Date: Tue, 19 May 2015 15:56:17 +0100<br>
From: "Daniel P. Berrange" <<a href="mailto:berrange@redhat.com">berrange@redhat.com</a>><br>
To: "OpenStack Development Mailing List (not for usage questions)"<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] [nova] libvirt: _do_quality_warnings and<br>
the hypervisor support matrix<br>
Message-ID: <<a href="mailto:20150519145617.GC8535@redhat.com">20150519145617.GC8535@redhat.com</a>><br>
Content-Type: text/plain; charset=utf-8<br>
<br>
On Tue, May 19, 2015 at 04:41:40PM +0200, Markus Zoeller wrote:<br>
> The libvirt driver logs a warning if:<br>
> hostarch not in (arch.I686, arch.X86_64))<br>
> The warning when I start the libvirt driver on system z (arch.S390X)<br>
> will be:<br>
> "The libvirt driver is not tested on kvm/s390x by the OpenStack<br>
> project and thus its quality can not be ensured. For more<br>
> information, see:<br>
> <a href="https://wiki.openstack.org/wiki/HypervisorSupportMatrix" target="_blank">https://wiki.openstack.org/wiki/HypervisorSupportMatrix</a>"<br>
><br>
> I'm not quite sure if I understand that correctly. Should this be a<br>
> hint that "arch.I686, arch.X86_64" is the assumed "default"?<br>
> Or am I supposed to add the architecture "S390X" to this method because<br>
> this platform is listed in the hypervisor support matrix?<br>
> I want to avoid that customers will get a bad feeling because of the<br>
> warning after starting the nova libvirt driver on a system z platform.<br>
><br>
> Note: We are still working on the CI for nova<br>
<br>
In the wiki page we describe 3 groups of drives, those with CI run<br>
by the OpenStack project (Group A), those with CI run by 3rd party<br>
vendors (Group B) and those with no CI at all (Group C)<br>
<br>
<a href="https://wiki.openstack.org/wiki/HypervisorSupportMatrix#Driver_Testing_Status" target="_blank">https://wiki.openstack.org/wiki/HypervisorSupportMatrix#Driver_Testing_Status</a><br>
<br>
The _do_quality_warnings method is intended to print a warning for<br>
any libvirt driver combination that is in Group C.<br>
<br>
After S390(x) has a 3rd party CI system running regularly & reasonably<br>
reliably, then you can submit a change to add S390X to the architecture<br>
list in _do_quality_warnings.<br>
<br>
Regards,<br>
Daniel<br>
--<br>
|: <a href="http://berrange.com" target="_blank">http://berrange.com</a> -o- <a href="http://www.flickr.com/photos/dberrange/" target="_blank">http://www.flickr.com/photos/dberrange/</a> :|<br>
|: <a href="http://libvirt.org" target="_blank">http://libvirt.org</a> -o- <a href="http://virt-manager.org" target="_blank">http://virt-manager.org</a> :|<br>
|: <a href="http://autobuild.org" target="_blank">http://autobuild.org</a> -o- <a href="http://search.cpan.org/~danberr/" target="_blank">http://search.cpan.org/~danberr/</a> :|<br>
|: <a href="http://entangle-photo.org" target="_blank">http://entangle-photo.org</a> -o- <a href="http://live.gnome.org/gtk-vnc" target="_blank">http://live.gnome.org/gtk-vnc</a> :|<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 10<br>
Date: Tue, 19 May 2015 15:01:39 +0000<br>
From: "Clark, Robert Graham" <<a href="mailto:robert.clark@hp.com">robert.clark@hp.com</a>><br>
To: OpenStack List <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: [openstack-dev] [Security][Glance] Design session for image<br>
signing/encryption<br>
Message-ID: <<a href="mailto:D1809E63.1CD42%25robert.clark@hp.com">D1809E63.1CD42%robert.clark@hp.com</a>><br>
Content-Type: text/plain; charset="us-ascii"<br>
<br>
All,<br>
<br>
Is there a session to discuss the image security proposal? <a href="https://review.openstack.org/#/c/177948/2/specs/liberty/encrypted-and-authenticated-image-support.rst" target="_blank">https://review.openstack.org/#/c/177948/2/specs/liberty/encrypted-and-authenticated-image-support.rst</a><br>
<br>
Cheers<br>
-Rob<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 11<br>
Date: Tue, 19 May 2015 16:13:34 +0100<br>
From: Louis Taylor <<a href="mailto:louis@kragniz.eu">louis@kragniz.eu</a>><br>
To: "OpenStack Development Mailing List (not for usage questions)"<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] [Security][Glance] Design session for<br>
image signing/encryption<br>
Message-ID: <<a href="mailto:20150519151333.GA14295@gmail.com">20150519151333.GA14295@gmail.com</a>><br>
Content-Type: text/plain; charset="us-ascii"<br>
<br>
On Tue, May 19, 2015 at 03:01:39PM +0000, Clark, Robert Graham wrote:<br>
> Is there a session to discuss the image security proposal?<br>
> <a href="https://review.openstack.org/#/c/177948/2/specs/liberty/encrypted-and-authenticated-image-support.rst" target="_blank">https://review.openstack.org/#/c/177948/2/specs/liberty/encrypted-and-authenticated-image-support.rst</a><br>
<br>
Yes, it's at 4:30 - 5:10pm on Wednesday.<br>
<br>
Cheers,<br>
Louis<br>
<br>
<a href="https://libertydesignsummit.sched.org/event/fc81bd8fb60d71ba4fe1c0cfa0637b2b" target="_blank">https://libertydesignsummit.sched.org/event/fc81bd8fb60d71ba4fe1c0cfa0637b2b</a><br>
<a href="https://etherpad.openstack.org/p/liberty-glance-image-signing-and-encryption" target="_blank">https://etherpad.openstack.org/p/liberty-glance-image-signing-and-encryption</a><br>
-------------- next part --------------<br>
A non-text attachment was scrubbed...<br>
Name: signature.asc<br>
Type: application/pgp-signature<br>
Size: 473 bytes<br>
Desc: Digital signature<br>
URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20150519/f734ceb3/attachment-0001.pgp" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20150519/f734ceb3/attachment-0001.pgp</a>><br>
<br>
------------------------------<br>
<br>
Message: 12<br>
Date: Tue, 19 May 2015 17:39:39 +0200<br>
From: Markus Zoeller <<a href="mailto:mzoeller@de.ibm.com">mzoeller@de.ibm.com</a>><br>
To: "OpenStack Development Mailing List \(not for usage questions\)"<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] [nova] libvirt: _do_quality_warnings and<br>
the hypervisor support matrix<br>
Message-ID:<br>
<<a href="mailto:OF4A923A23.CE73EC16-ONC1257E4A.0055D550-C1257E4A.0056071C@de.ibm.com">OF4A923A23.CE73EC16-ONC1257E4A.0055D550-C1257E4A.0056071C@de.ibm.com</a>><br>
Content-Type: text/plain; charset="US-ASCII"<br>
<br>
"Daniel P. Berrange" <<a href="mailto:berrange@redhat.com">berrange@redhat.com</a>> wrote on 05/19/2015 04:56:17<br>
PM:<br>
<br>
> From: "Daniel P. Berrange" <<a href="mailto:berrange@redhat.com">berrange@redhat.com</a>><br>
> To: "OpenStack Development Mailing List (not for usage questions)"<br>
> <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
> Date: 05/19/2015 05:09 PM<br>
> Subject: Re: [openstack-dev] [nova] libvirt: _do_quality_warnings and<br>
> the hypervisor support matrix<br>
><br>
> On Tue, May 19, 2015 at 04:41:40PM +0200, Markus Zoeller wrote:<br>
> > The libvirt driver logs a warning if:<br>
> > hostarch not in (arch.I686, arch.X86_64))<br>
> > The warning when I start the libvirt driver on system z (arch.S390X)<br>
> > will be:<br>
> > "The libvirt driver is not tested on kvm/s390x by the OpenStack<br>
> > project and thus its quality can not be ensured. For more<br>
> > information, see:<br>
> > <a href="https://wiki.openstack.org/wiki/HypervisorSupportMatrix" target="_blank">https://wiki.openstack.org/wiki/HypervisorSupportMatrix</a>"<br>
> ><br>
> > I'm not quite sure if I understand that correctly. Should this be a<br>
> > hint that "arch.I686, arch.X86_64" is the assumed "default"?<br>
> > Or am I supposed to add the architecture "S390X" to this method<br>
because<br>
> > this platform is listed in the hypervisor support matrix?<br>
> > I want to avoid that customers will get a bad feeling because of the<br>
> > warning after starting the nova libvirt driver on a system z platform.<br>
> ><br>
> > Note: We are still working on the CI for nova<br>
><br>
> In the wiki page we describe 3 groups of drives, those with CI run<br>
> by the OpenStack project (Group A), those with CI run by 3rd party<br>
> vendors (Group B) and those with no CI at all (Group C)<br>
><br>
><br>
<a href="https://wiki.openstack.org/wiki/HypervisorSupportMatrix#Driver_Testing_Status" target="_blank">https://wiki.openstack.org/wiki/HypervisorSupportMatrix#Driver_Testing_Status</a><br>
<br>
><br>
> The _do_quality_warnings method is intended to print a warning for<br>
> any libvirt driver combination that is in Group C.<br>
><br>
> After S390(x) has a 3rd party CI system running regularly & reasonably<br>
> reliably, then you can submit a change to add S390X to the architecture<br>
> list in _do_quality_warnings.<br>
><br>
> Regards,<br>
> Daniel<br>
<br>
Thanks for the clarification Daniel.<br>
<br>
Regards,<br>
Markus Zoeller (markus_z)<br>
<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 13<br>
Date: Tue, 19 May 2015 09:06:39 -0700<br>
From: Davanum Srinivas <<a href="mailto:davanum@gmail.com">davanum@gmail.com</a>><br>
To: "OpenStack Development Mailing List (not for usage questions)"<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] [oslo] needed, driver for oslo.db<br>
thursday session<br>
Message-ID:<br>
<<a href="mailto:CANw6fcHc8JYG_3JRtMvixmweYVJEnpHQY%2B0zP%2BTfbzmypG6gKw@mail.gmail.com">CANw6fcHc8JYG_3JRtMvixmweYVJEnpHQY+0zP+TfbzmypG6gKw@mail.gmail.com</a>><br>
Content-Type: text/plain; charset=UTF-8<br>
<br>
Mike,<br>
<br>
Thanks for the heads up. Wow 26 hours. crazy! No worries. we'll make<br>
something out of the session and report back<br>
<br>
-- dims<br>
<br>
On Tue, May 19, 2015 at 7:24 AM, Mike Bayer <<a href="mailto:mbayer@redhat.com">mbayer@redhat.com</a>> wrote:<br>
> ouch !<br>
><br>
><br>
> maybe next summit will be on the "Lost" island. another easy place to get<br>
> to ! :)<br>
><br>
><br>
><br>
><br>
><br>
> On 5/19/15 9:08 AM, Roman Podoliaka wrote:<br>
>><br>
>> Hi all,<br>
>><br>
>> Just FYI, due to problems with obtaining a Canadian visa, neither<br>
>> Victor Sergeyev, nor I made it to Vancouver.<br>
>><br>
>> I hope someone else from Oslo team can replace Mike as a session driver.<br>
>><br>
>> Thanks,<br>
>> Roman<br>
>><br>
>> On Tue, May 19, 2015 at 3:53 AM, Mike Bayer <<a href="mailto:mbayer@redhat.com">mbayer@redhat.com</a>> wrote:<br>
>>><br>
>>> Hello -<br>
>>><br>
>>> It is my extreme displeasure and frustration to announce that due to an<br>
>>> incredibly unfortunate choice of airline, I had to cancel my entire trip<br>
>>> to<br>
>>> the Openstack summit after spending 26 hours in my home airport waiting<br>
>>> for<br>
>>> my airline to produce a working airplane (which they did not).<br>
>>><br>
>>> I will not be able to attend in person the Thursday oslo.db session I was<br>
>>> to<br>
>>> drive, so a replacement will be needed. I am also lamenting not being<br>
>>> able<br>
>>> to meet so many of you who I hoped very much to meet.<br>
>>><br>
>>> Hope you all enjoy the summit and I hope our paths can cross at future<br>
>>> events.<br>
>>><br>
>>> - mike<br>
>>><br>
>>><br>
>>><br>
>>><br>
>>> __________________________________________________________________________<br>
>>> OpenStack Development Mailing List (not for usage questions)<br>
>>> Unsubscribe:<br>
>>> <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</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>
>> OpenStack Development Mailing List (not for usage questions)<br>
>> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</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 Development Mailing List (not for usage questions)<br>
> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</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>
Davanum Srinivas :: <a href="https://twitter.com/dims" target="_blank">https://twitter.com/dims</a><br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 14<br>
Date: Tue, 19 May 2015 09:06:56 -0700<br>
From: Davanum Srinivas <<a href="mailto:davanum@gmail.com">davanum@gmail.com</a>><br>
To: "OpenStack Development Mailing List (not for usage questions)"<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] [oslo] needed, driver for oslo.db<br>
thursday session<br>
Message-ID:<br>
<CANw6fcGYUYsGaNm=6Rsz=<a href="mailto:zzu8RTHDtoA4ioG1fpV7P0yRtSUPA@mail.gmail.com">zzu8RTHDtoA4ioG1fpV7P0yRtSUPA@mail.gmail.com</a>><br>
Content-Type: text/plain; charset=UTF-8<br>
<br>
Ouch. Thanks for the heads up Roman<br>
<br>
-- dims<br>
<br>
On Tue, May 19, 2015 at 6:08 AM, Roman Podoliaka<br>
<<a href="mailto:rpodolyaka@mirantis.com">rpodolyaka@mirantis.com</a>> wrote:<br>
> Hi all,<br>
><br>
> Just FYI, due to problems with obtaining a Canadian visa, neither<br>
> Victor Sergeyev, nor I made it to Vancouver.<br>
><br>
> I hope someone else from Oslo team can replace Mike as a session driver.<br>
><br>
> Thanks,<br>
> Roman<br>
><br>
> On Tue, May 19, 2015 at 3:53 AM, Mike Bayer <<a href="mailto:mbayer@redhat.com">mbayer@redhat.com</a>> wrote:<br>
>> Hello -<br>
>><br>
>> It is my extreme displeasure and frustration to announce that due to an<br>
>> incredibly unfortunate choice of airline, I had to cancel my entire trip to<br>
>> the Openstack summit after spending 26 hours in my home airport waiting for<br>
>> my airline to produce a working airplane (which they did not).<br>
>><br>
>> I will not be able to attend in person the Thursday oslo.db session I was to<br>
>> drive, so a replacement will be needed. I am also lamenting not being able<br>
>> to meet so many of you who I hoped very much to meet.<br>
>><br>
>> Hope you all enjoy the summit and I hope our paths can cross at future<br>
>> events.<br>
>><br>
>> - mike<br>
>><br>
>><br>
>><br>
>> __________________________________________________________________________<br>
>> OpenStack Development Mailing List (not for usage questions)<br>
>> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</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>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</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>
Davanum Srinivas :: <a href="https://twitter.com/dims" target="_blank">https://twitter.com/dims</a><br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 15<br>
Date: Tue, 19 May 2015 17:19:27 +0100<br>
From: "Daniel P. Berrange" <<a href="mailto:berrange@redhat.com">berrange@redhat.com</a>><br>
To: <a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a><br>
Subject: [openstack-dev] [nova][glance] Format of 'locations' data in<br>
image metadata ?<br>
Message-ID: <<a href="mailto:20150519161927.GH8535@redhat.com">20150519161927.GH8535@redhat.com</a>><br>
Content-Type: text/plain; charset=utf-8<br>
<br>
In Nova we are attempting to model[1] the glance image metadata and<br>
properties using the Nova object model (now oslo.versionedobjects).<br>
<br>
The one item I'm stuck on understanding is the 'locations' field<br>
and more specifically the 'metadata' element in each location<br>
entry<br>
<br>
<br>
In the file glance/api/v2/images.py I can see this description<br>
of the data format:<br>
<br>
'locations': {<br>
'type': 'array',<br>
'items': {<br>
'type': 'object',<br>
'properties': {<br>
'url': {<br>
'type': 'string',<br>
'maxLength': 255,<br>
},<br>
'metadata': {<br>
'type': 'object',<br>
},<br>
},<br>
'required': ['url', 'metadata'],<br>
},<br>
'description': _('A set of URLs to access the image file kept in '<br>
'external store'),<br>
<br>
<br>
As you can see here, 'metadata' is just said to be of type 'object'.<br>
<br>
Is there somewhere that actually describes what is valid contents<br>
for this field ? Is it sufficient to assume the metadata will only<br>
ever be a dict of strings, or can the metadata be a complex type<br>
with arbitrarily nested data structures ?<br>
<br>
Regards,<br>
Daniel<br>
<br>
[1] <a href="https://review.openstack.org/#/c/76234/" target="_blank">https://review.openstack.org/#/c/76234/</a><br>
--<br>
|: <a href="http://berrange.com" target="_blank">http://berrange.com</a> -o- <a href="http://www.flickr.com/photos/dberrange/" target="_blank">http://www.flickr.com/photos/dberrange/</a> :|<br>
|: <a href="http://libvirt.org" target="_blank">http://libvirt.org</a> -o- <a href="http://virt-manager.org" target="_blank">http://virt-manager.org</a> :|<br>
|: <a href="http://autobuild.org" target="_blank">http://autobuild.org</a> -o- <a href="http://search.cpan.org/~danberr/" target="_blank">http://search.cpan.org/~danberr/</a> :|<br>
|: <a href="http://entangle-photo.org" target="_blank">http://entangle-photo.org</a> -o- <a href="http://live.gnome.org/gtk-vnc" target="_blank">http://live.gnome.org/gtk-vnc</a> :|<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 16<br>
Date: Tue, 19 May 2015 17:17:29 +0000<br>
From: Jeremy Stanley <<a href="mailto:fungi@yuggoth.org">fungi@yuggoth.org</a>><br>
To: "OpenStack Development Mailing List (not for usage questions)"<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] [oslo] needed, driver for oslo.db<br>
thursday session<br>
Message-ID: <<a href="mailto:20150519171729.GN2731@yuggoth.org">20150519171729.GN2731@yuggoth.org</a>><br>
Content-Type: text/plain; charset=us-ascii<br>
<br>
On 2015-05-19 09:06:56 -0700 (-0700), Davanum Srinivas wrote:<br>
> Ouch. Thanks for the heads up Roman<br>
<br>
We have <a href="https://wiki.openstack.org/wiki/Infrastructure/Conferencing" target="_blank">https://wiki.openstack.org/wiki/Infrastructure/Conferencing</a><br>
which we used yesterday to successfully bridge Clark B. into an I18n<br>
tooling session via Jitsi over the normal conference wireless<br>
network with the built-in mic/speaker in Jim's laptop. Feel free to<br>
use it in your sessions, just try to pick a random conference number<br>
between 6000 and 7999 so nobody steps on the toes of other sessions<br>
which might be using it (maybe add your conference room number to<br>
6000 or something?). Let me or other Infra people know if you have<br>
any questions about or trouble using it!<br>
--<br>
Jeremy Stanley<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 17<br>
Date: Tue, 19 May 2015 10:21:04 -0700<br>
From: Alexander Tivelkov <<a href="mailto:ativelkov@mirantis.com">ativelkov@mirantis.com</a>><br>
To: "OpenStack Development Mailing List (not for usage questions)"<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] [Glance] glance social event at Vancouver<br>
summit<br>
Message-ID: <-2437030608731294219@unknownmsgid><br>
Content-Type: text/plain; charset=UTF-8<br>
<br>
Hi Brian,<br>
<br>
Seems like it overlaps with the "Core reviewers party" on Wednesday.<br>
<br>
Is there any chance to reschedule on Thursday?<br>
<br>
> 15 ??? 2015 ?., ? 7:19, Brian Rosmaita <<a href="mailto:brian.rosmaita@rackspace.com">brian.rosmaita@rackspace.com</a>> ???????(?):<br>
><br>
> Greetings to all Glance people,<br>
><br>
> kragniz has proposed that we have an informal social event for Glance and<br>
> Glance-related people attending the summit next week. Please keep your<br>
> calendars open for about 2 hours or so starting at 7:30 p.m. on Wednesday,<br>
> May 20. Neither kragniz nor I are familiar with Vancouver, so we'll<br>
> figure out logistics when we get there and announce details during the<br>
> Glance design sessions on Wednesday.<br>
><br>
> Looking forward to seeing everyone and getting some good design work done<br>
> next week ... safe travels!<br>
><br>
> rosmaita<br>
><br>
><br>
><br>
> __________________________________________________________________________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</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>
Message: 18<br>
Date: Tue, 19 May 2015 13:33:19 -0400<br>
From: Nikhil Komawar <<a href="mailto:nik.komawar@gmail.com">nik.komawar@gmail.com</a>><br>
To: <a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a><br>
Subject: Re: [openstack-dev] [nova][glance] Format of 'locations' data<br>
in image metadata ?<br>
Message-ID: <<a href="mailto:555B73DF.9070604@gmail.com">555B73DF.9070604@gmail.com</a>><br>
Content-Type: text/plain; charset="windows-1252"; Format="flowed"<br>
<br>
Hi Daniel,<br>
<br>
It's stored as "JSONEncodedDict" as shown below. This is a DB model and<br>
can accept arbitrarily large and nested data structure.<br>
<br>
Hope this helps.<br>
<br>
class JSONEncodedDict(TypeDecorator):<br>
"""Represents an immutable structure as a json-encoded string"""<br>
<br>
impl = Text<br>
<br>
def process_bind_param(self, value, dialect):<br>
if value is not None:<br>
value = jsonutils.dumps(value)<br>
return value<br>
<br>
def process_result_value(self, value, dialect):<br>
if value is not None:<br>
value = jsonutils.loads(value)<br>
return value<br>
<br>
<br>
Regards,<br>
Nikhil<br>
<br>
On 5/19/15 12:19 PM, Daniel P. Berrange wrote:<br>
> In Nova we are attempting to model[1] the glance image metadata and<br>
> properties using the Nova object model (now oslo.versionedobjects).<br>
><br>
> The one item I'm stuck on understanding is the 'locations' field<br>
> and more specifically the 'metadata' element in each location<br>
> entry<br>
><br>
><br>
> In the file glance/api/v2/images.py I can see this description<br>
> of the data format:<br>
><br>
> 'locations': {<br>
> 'type': 'array',<br>
> 'items': {<br>
> 'type': 'object',<br>
> 'properties': {<br>
> 'url': {<br>
> 'type': 'string',<br>
> 'maxLength': 255,<br>
> },<br>
> 'metadata': {<br>
> 'type': 'object',<br>
> },<br>
> },<br>
> 'required': ['url', 'metadata'],<br>
> },<br>
> 'description': _('A set of URLs to access the image file kept in '<br>
> 'external store'),<br>
><br>
><br>
> As you can see here, 'metadata' is just said to be of type 'object'.<br>
><br>
> Is there somewhere that actually describes what is valid contents<br>
> for this field ? Is it sufficient to assume the metadata will only<br>
> ever be a dict of strings, or can the metadata be a complex type<br>
> with arbitrarily nested data structures ?<br>
><br>
> Regards,<br>
> Daniel<br>
><br>
> [1] <a href="https://review.openstack.org/#/c/76234/" target="_blank">https://review.openstack.org/#/c/76234/</a><br>
<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20150519/3a64a011/attachment-0001.html" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20150519/3a64a011/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 19<br>
Date: Tue, 19 May 2015 17:48:57 +0000<br>
From: "ADAMS, STEVEN E" <<a href="mailto:sa240s@att.com">sa240s@att.com</a>><br>
To: "<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: Re: [openstack-dev] [nova-docker] Status update<br>
Message-ID:<br>
<<a href="mailto:F169453C03E0074D99BA6CCA8C42112714507326@MISOUT7MSGUSRCB.ITServices.sbc.com">F169453C03E0074D99BA6CCA8C42112714507326@MISOUT7MSGUSRCB.ITServices.sbc.com</a>><br>
<br>
Content-Type: text/plain; charset="us-ascii"<br>
<br>
Has there been any decision made on if and when the nova-docker driver will move back to the Nova tree and out of Stackforge?<br>
-Steve Adams<br>
<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20150519/44f3e02e/attachment-0001.html" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20150519/44f3e02e/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 20<br>
Date: Tue, 19 May 2015 11:15:47 -0700<br>
From: Davanum Srinivas <<a href="mailto:davanum@gmail.com">davanum@gmail.com</a>><br>
To: "OpenStack Development Mailing List (not for usage questions)"<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] [nova-docker] Status update<br>
Message-ID:<br>
<CANw6fcEYTLHLknVmoL0Sjn=Y4x=<a href="mailto:6dtMBjqfye_sRyO2sS%2B%2BRTA@mail.gmail.com">6dtMBjqfye_sRyO2sS++RTA@mail.gmail.com</a>><br>
Content-Type: text/plain; charset=UTF-8<br>
<br>
Adam,<br>
<br>
Please follow the discussion on the nova-spec review:<br>
<a href="https://review.openstack.org/#/c/128753/" target="_blank">https://review.openstack.org/#/c/128753/</a><br>
<br>
At the moment, we need folks actively watching the project in terms of<br>
reviews, gate/check job failures, keeping up with Nova trunk etc.<br>
Please let me know if you or anyone else is interested.<br>
<br>
thanks,<br>
dims<br>
<br>
On Tue, May 19, 2015 at 10:48 AM, ADAMS, STEVEN E <<a href="mailto:sa240s@att.com">sa240s@att.com</a>> wrote:<br>
> Has there been any decision made on if and when the nova-docker driver will<br>
> move back to the Nova tree and out of Stackforge?<br>
><br>
> -Steve Adams<br>
><br>
><br>
><br>
><br>
> __________________________________________________________________________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</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>
Davanum Srinivas :: <a href="https://twitter.com/dims" target="_blank">https://twitter.com/dims</a><br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 21<br>
Date: Tue, 19 May 2015 15:41:31 -0400<br>
From: Ben Swartzlander <<a href="mailto:ben@swartzlander.org">ben@swartzlander.org</a>><br>
To: "OpenStack Development Mailing List (not for usage questions)"<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] [Manila] Question to driver maintainers<br>
Message-ID: <<a href="mailto:555B91EB.20203@swartzlander.org">555B91EB.20203@swartzlander.org</a>><br>
Content-Type: text/plain; charset=windows-1252; format=flowed<br>
<br>
On 05/19/2015 10:42 AM, Csaba Henk wrote:<br>
> Hi Igor,<br>
><br>
>> From: "Igor Malinovskiy" <<a href="mailto:imalinovskiy@mirantis.com">imalinovskiy@mirantis.com</a>><br>
>> To: "OpenStack Development Mailing List (not for usage questions)"<br>
>> <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
>> Sent: Monday, May 18, 2015 10:15:25 AM<br>
>> Subject: [openstack-dev] [Manila] Question to driver maintainers<br>
> ...<br>
>> So I want to ask driver maintainers here:<br>
>> Will your driver be able to do share extending without loss of connectivity?<br>
> Currenty:<br>
><br>
> - glusterfs driver can<br>
> - glusterfs-native won't support share extension (*)<br>
><br>
> in Liberty timeframe, we are to unify the glusterfs* drivers' backend<br>
> management logic, so both glusterfs driver style and glusterfs-native<br>
> driver style backend management will be available for both drivers<br>
> (actual choice made in configuration). So when this will be in place,<br>
> the answer modifies as follows:<br>
><br>
> - glusterfs and glusterfs-native will either support non-disruptive<br>
> share extension, or won't support share resize at all (*) (depending<br>
> on configuration)<br>
<br>
Csaba, this is a truly interesting set of limitations! I'm trying to<br>
understand what's going on down in the storage system to prevent the<br>
extension. Is it a case of not having enough free space? Or can you<br>
support creating new (larger) shares on the same backend while<br>
simultaneously not being able to resize an existing share? Is there some<br>
mapping to physical resources that's immutable once configured? What is<br>
your recommendation to customers who run out of space in a glusterfs<br>
share today (independent of Manila)?<br>
<br>
If your system can't support this case then I'm worried others may have<br>
similar problems and we could end up having to choose between making<br>
extend an optional operation (a choice I don't like) or making the<br>
glusterfs-native driver and possibly other drivers unsupported (also an<br>
option I don't like).<br>
<br>
-Ben<br>
<br>
> (*) There are efforts to remove this limitation in GlusterFS, but too<br>
> vague at this point to make a statement on it.<br>
><br>
> Csaba<br>
><br>
><br>
> __________________________________________________________________________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</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: 22<br>
Date: Tue, 19 May 2015 12:49:49 -0700<br>
From: Sridhar Ramaswamy <<a href="mailto:srics.r@gmail.com">srics.r@gmail.com</a>><br>
To: "OpenStack Development Mailing List (not for usage questions)"<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: [openstack-dev] [NFV][Tacker] OpenStack based VNF Manager<br>
Message-ID:<br>
<<a href="mailto:CAK6Sh4DU9z1yG5s9_Q4f_aHr5rF_2Nsvzph0ujHp3TDU6zGXWA@mail.gmail.com">CAK6Sh4DU9z1yG5s9_Q4f_aHr5rF_2Nsvzph0ujHp3TDU6zGXWA@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
In some of the sessions there were questions related to VNF Manager efforts<br>
within OpenStack. There is actually an effort to build an ETSI MANO based<br>
VNF Manager using the stackforge project called Tacker (yes, it used to be<br>
for ServiceVMs). Please look at the wiki below for more details,<br>
<br>
<a href="https://wiki.openstack.org/wiki/Tacker" target="_blank">https://wiki.openstack.org/wiki/Tacker</a><br>
<br>
Also to hear more, and see a demo, there is a speaking session scheduled<br>
for Thursday 11:50am,<br>
<br>
<a href="http://sched.co/2qik" target="_blank">http://sched.co/2qik</a><br>
<br>
- Sridhar<br>
(for Tacker team)<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20150519/167eb325/attachment-0001.html" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20150519/167eb325/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 23<br>
Date: Tue, 19 May 2015 19:53:51 +0000<br>
From: Andrew Woodward <<a href="mailto:xarses@gmail.com">xarses@gmail.com</a>><br>
To: "OpenStack Development Mailing List (not for usage questions)"<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Cc: Joe Marshall <<a href="mailto:Joe.Marshall@metaswitch.com">Joe.Marshall@metaswitch.com</a>><br>
Subject: Re: [openstack-dev] [Fuel][Plugin] Contributor license<br>
agreement for fuel plugin code?<br>
Message-ID:<br>
<CACEfbZhV-KhKpVtQps-61WwRXZT4vsPMyzB0=<a href="mailto:6nmH40cgSWA7Q@mail.gmail.com">6nmH40cgSWA7Q@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
On Wed, May 6, 2015 at 4:06 AM Emma Gordon (<a href="http://projectcalico.org" target="_blank">projectcalico.org</a>) <<br>
<a href="mailto:emma@projectcalico.org">emma@projectcalico.org</a>> wrote:<br>
<br>
> If fuel plugin code is checked into a stackforge repository (as<br>
> suggested in the fuel plugin wiki<br>
> <a href="https://wiki.openstack.org/wiki/Fuel/Plugins#Repo" target="_blank">https://wiki.openstack.org/wiki/Fuel/Plugins#Repo</a>), who owns that code?<br>
><br>
<br>
Disclaimer, I'm not a lawyer this not legal advice.<br>
<br>
The "authors" own the work (code) according local assignment rules and the<br>
Berne convention. This would be treated the same as any other work. The<br>
Authors can decide what rights they may want people with regards to<br>
copy-right (and other intellectual property rights), hence the licenses<br>
that we pass around with opensource projects to clarify the author(s)<br>
intent. Additional "authors" or contributors to the work can further<br>
describe their own license on their part of the work (as they hold their<br>
own copyright) but these are usually not accepted by the maintainers of a<br>
work.<br>
<br>
To that end, you don't have to use the Apache 2.0 License on your plugin if<br>
you don't desire it. It could however cause the plugin to see limited use.<br>
The point of plugins is that this in your control.<br>
<br>
I would also point out that your plugin could easily contain multiple<br>
licenses depending on what you are including. I'm working on a way to<br>
easily identify this with the plugins metadata. This can occur multiple<br>
ways as there are many parts in a plugin.<br>
<br>
a) there is the data describing how the plugin interacts with fuel. All of<br>
this data is highly structured and has little IP (usually the wording you<br>
use for the text fields is it)<br>
<br>
b) any configuration management code you use to apply the plugin and its<br>
settings. This could include your pure code, or even multiple works from<br>
others, for example puppet modules.<br>
<br>
c) Packages that you need to include as part of the plugin package to<br>
ensure they can be found. These could each have their own license and even<br>
carry GPL licensed parts.<br>
<br>
In these cases I'd recommend adding a LICENSES file describing the<br>
locations where items may change license (similar to any other programs<br>
Open Source Notice file.) from what ever is written on in the "license"<br>
string in the plugin metadata.yaml. As I noted above, I'm working to get<br>
this incorporated into the data we present on the plugins repo page.<br>
(Likely by pointing to this file in the metadata, but it's not settled yet)<br>
<br>
<br>
> Is there a contributor license agreement to sign? (For example,<br>
> contributors to OpenStack would sign this<br>
> <a href="https://review.openstack.org/static/cla.html" target="_blank">https://review.openstack.org/static/cla.html</a>)<br>
><br>
The Openstack CLA is not required for Fuel, and is not obligatory. You<br>
again have control here and simply configure your gerrit settings for your<br>
project as you see fit.<br>
<br>
> Thanks,<br>
><br>
> Emma<br>
><br>
> __________________________________________________________________________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</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>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20150519/c1e4cc58/attachment-0001.html" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20150519/c1e4cc58/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 24<br>
Date: Tue, 19 May 2015 20:05:15 +0000<br>
From: Andrew Woodward <<a href="mailto:xarses@gmail.com">xarses@gmail.com</a>><br>
To: "OpenStack Development Mailing List (not for usage questions)"<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>>, Zhou Zheng Sheng / ???<br>
<<a href="mailto:zhengsheng@awcloud.com">zhengsheng@awcloud.com</a>><br>
Subject: Re: [openstack-dev] [Fuel] Speed Up RabbitMQ Recovering<br>
Message-ID:<br>
<<a href="mailto:CACEfbZj7bHJD7ZH9Dv13k3QUN44VNyfTyvztBr6Oj_bq%2BHw-kA@mail.gmail.com">CACEfbZj7bHJD7ZH9Dv13k3QUN44VNyfTyvztBr6Oj_bq+Hw-kA@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
On Thu, May 7, 2015 at 5:01 PM Andrew Beekhof <<a href="mailto:abeekhof@redhat.com">abeekhof@redhat.com</a>> wrote:<br>
<br>
><br>
> > On 5 May 2015, at 1:19 pm, Zhou Zheng Sheng / ??? <<br>
> <a href="mailto:zhengsheng@awcloud.com">zhengsheng@awcloud.com</a>> wrote:<br>
> ><br>
> > Thank you Andrew.<br>
> ><br>
> > on 2015/05/05 08:03, Andrew Beekhof wrote:<br>
> >>> On 28 Apr 2015, at 11:15 pm, Bogdan Dobrelya <<a href="mailto:bdobrelia@mirantis.com">bdobrelia@mirantis.com</a>><br>
> wrote:<br>
> >>><br>
> >>>> Hello,<br>
> >>> Hello, Zhou<br>
> >>><br>
> >>>> I using Fuel 6.0.1 and find that RabbitMQ recover time is long after<br>
> >>>> power failure. I have a running HA environment, then I reset power of<br>
> >>>> all the machines at the same time. I observe that after reboot it<br>
> >>>> usually takes 10 minutes for RabittMQ cluster to appear running<br>
> >>>> master-slave mode in pacemaker. If I power off all the 3 controllers<br>
> and<br>
> >>>> only start 2 of them, the downtime sometimes can be as long as 20<br>
> minutes.<br>
> >>> Yes, this is a known issue [0]. Note, there were many bugfixes, like<br>
> >>> [1],[2],[3], merged for MQ OCF script, so you may want to try to<br>
> >>> backport them as well by the following guide [4]<br>
> >>><br>
> >>> [0] <a href="https://bugs.launchpad.net/fuel/+bug/1432603" target="_blank">https://bugs.launchpad.net/fuel/+bug/1432603</a><br>
> >>> [1] <a href="https://review.openstack.org/#/c/175460/" target="_blank">https://review.openstack.org/#/c/175460/</a><br>
> >>> [2] <a href="https://review.openstack.org/#/c/175457/" target="_blank">https://review.openstack.org/#/c/175457/</a><br>
> >>> [3] <a href="https://review.openstack.org/#/c/175371/" target="_blank">https://review.openstack.org/#/c/175371/</a><br>
> >>> [4] <a href="https://review.openstack.org/#/c/170476/" target="_blank">https://review.openstack.org/#/c/170476/</a><br>
> >> Is there a reason you?re using a custom OCF script instead of the<br>
> upstream[a] one?<br>
> >> Please have a chat with David (the maintainer, in CC) if there is<br>
> something you believe is wrong with it.<br>
> >><br>
> >> [a]<br>
> <a href="https://github.com/ClusterLabs/resource-agents/blob/master/heartbeat/rabbitmq-cluster" target="_blank">https://github.com/ClusterLabs/resource-agents/blob/master/heartbeat/rabbitmq-cluster</a><br>
> ><br>
> > I'm using the OCF script from the Fuel project, specifically from the<br>
> > "6.0" stable branch [alpha].<br>
><br>
> Ah, I?m still learning who is who... i thought you were part of that<br>
> project :-)<br>
><br>
> ><br>
> > Comparing with upstream OCF code, the main difference is that Fuel<br>
> > RabbitMQ OCF is a master-slave resource. Fuel RabbitMQ OCF does more<br>
> > bookkeeping, for example, blocking client access when RabbitMQ cluster<br>
> > is not ready. I beleive the upstream OCF should be OK to use as well<br>
> > after I read the code, but it might not fit into the Fuel project. As<br>
> > far as I test, the Fuel OCF script is good except sometimes the full<br>
> > reassemble time is long, and as I find out, it is mostly because the<br>
> > Fuel MySQL Galera OCF script keeps pacemaker from promoting RabbitMQ<br>
> > resource, as I mentioned in the previous emails.<br>
> ><br>
> > Maybe Vladimir and Sergey can give us more insight on why Fuel needs a<br>
> > master-slave RabbitMQ.<br>
><br>
> That would be good to know.<br>
> Browsing the agent, promote seems to be a no-op if rabbit is already<br>
> running.<br>
><br>
><br>
To the master / slave reason due to how the ocf script is structured to<br>
deal with rabbit's poor ability to handle its self in some scenarios.<br>
Hopefully the state transition diagram [5] is enough to clarify what's<br>
going on.<br>
<br>
[5] <a href="http://goo.gl/PPNrw7" target="_blank">http://goo.gl/PPNrw7</a><br>
<br>
<br>
> > I see Vladimir and Sergey works on the original<br>
> > Fuel blueprint "RabbitMQ cluster" [beta].<br>
> ><br>
> > [alpha]<br>
> ><br>
> <a href="https://github.com/stackforge/fuel-library/blob/stable/6.0/deployment/puppet/nova/files/ocf/rabbitmq" target="_blank">https://github.com/stackforge/fuel-library/blob/stable/6.0/deployment/puppet/nova/files/ocf/rabbitmq</a><br>
> > [beta]<br>
> ><br>
> <a href="https://blueprints.launchpad.net/fuel/+spec/rabbitmq-cluster-controlled-by-pacemaker" target="_blank">https://blueprints.launchpad.net/fuel/+spec/rabbitmq-cluster-controlled-by-pacemaker</a><br>
> ><br>
> >>>> I have a little investigation and find out there are some possible<br>
> causes.<br>
> >>>><br>
> >>>> 1. MySQL Recovery Takes Too Long [1] and Blocking RabbitMQ Clustering<br>
> in<br>
> >>>> Pacemaker<br>
> >>>><br>
> >>>> The pacemaker resource p_mysql start timeout is set to 475s. Sometimes<br>
> >>>> MySQL-wss fails to start after power failure, and pacemaker would wait<br>
> >>>> 475s before retry starting it. The problem is that pacemaker divides<br>
> >>>> resource state transitions into batches. Since RabbitMQ is<br>
> master-slave<br>
> >>>> resource, I assume that starting all the slaves and promoting master<br>
> are<br>
> >>>> put into two different batches. If unfortunately starting all RabbitMQ<br>
> >>>> slaves are put in the same batch as MySQL starting, even if RabbitMQ<br>
> >>>> slaves and all other resources are ready, pacemaker will not continue<br>
> >>>> but just wait for MySQL timeout.<br>
> >>> Could you please elaborate the what is the same/different batches for<br>
> MQ<br>
> >>> and DB? Note, there is a MQ clustering logic flow charts available here<br>
> >>> [5] and we're planning to release a dedicated technical bulletin for<br>
> this.<br>
> >>><br>
> >>> [5] <a href="http://goo.gl/PPNrw7" target="_blank">http://goo.gl/PPNrw7</a><br>
> >>><br>
> >>>> I can re-produce this by hard powering off all the controllers and<br>
> start<br>
> >>>> them again. It's more likely to trigger MySQL failure in this way.<br>
> Then<br>
> >>>> I observe that if there is one cloned mysql instance not starting, the<br>
> >>>> whole pacemaker cluster gets stuck and does not emit any log. On the<br>
> >>>> host of the failed instance, I can see a mysql resource agent process<br>
> >>>> calling the sleep command. If I kill that process, the pacemaker comes<br>
> >>>> back alive and RabbitMQ master gets promoted. In fact this long<br>
> timeout<br>
> >>>> is blocking every resource from state transition in pacemaker.<br>
> >>>><br>
> >>>> This maybe a known problem of pacemaker and there are some discussions<br>
> >>>> in Linux-HA mailing list [2]. It might not be fixed in the near<br>
> future.<br>
> >>>> It seems in generally it's bad to have long timeout in state<br>
> transition<br>
> >>>> actions (start/stop/promote/demote). There maybe another way to<br>
> >>>> implement MySQL-wss resource agent to use a short start timeout and<br>
> >>>> monitor the wss cluster state using monitor action.<br>
> >>> This is very interesting, thank you! I believe all commands for MySQL<br>
> RA<br>
> >>> OCF script should be as well wrapped with timeout -SIGTERM or -SIGKILL<br>
> >>> as we did for MQ RA OCF. And there should no be any sleep calls. I<br>
> >>> created a bug for this [6].<br>
> >>><br>
> >>> [6] <a href="https://bugs.launchpad.net/fuel/+bug/1449542" target="_blank">https://bugs.launchpad.net/fuel/+bug/1449542</a><br>
> >>><br>
> >>>> I also find a fix to improve MySQL start timeout [3]. It shortens the<br>
> >>>> timeout to 300s. At the time I sending this email, I can not find it<br>
> in<br>
> >>>> stable/6.0 branch. Maybe the maintainer needs to cherry-pick it to<br>
> >>>> stable/6.0 ?<br>
> >>>><br>
> >>>> [1] <a href="https://bugs.launchpad.net/fuel/+bug/1441885" target="_blank">https://bugs.launchpad.net/fuel/+bug/1441885</a><br>
> >>>> [2]<br>
> <a href="http://lists.linux-ha.org/pipermail/linux-ha/2014-March/047989.html" target="_blank">http://lists.linux-ha.org/pipermail/linux-ha/2014-March/047989.html</a><br>
> >>>> [3] <a href="https://review.openstack.org/#/c/171333/" target="_blank">https://review.openstack.org/#/c/171333/</a><br>
> >>>><br>
> >>>><br>
> >>>> 2. RabbitMQ Resource Agent Breaks Existing Cluster<br>
> >>>><br>
> >>>> Read the code of the RabbitMQ resource agent, I find it does the<br>
> >>>> following to start RabbitMQ master-slave cluster.<br>
> >>>> On all the controllers:<br>
> >>>> (1) Start Erlang beam process<br>
> >>>> (2) Start RabbitMQ App (If failed, reset mnesia DB and cluster state)<br>
> >>>> (3) Stop RabbitMQ App but do not stop the beam process<br>
> >>>><br>
> >>>> Then in pacemaker, all the RabbitMQ instances are in slave state.<br>
> After<br>
> >>>> pacemaker determines the master, it does the following.<br>
> >>>> On the to-be-master host:<br>
> >>>> (4) Start RabbitMQ App (If failed, reset mnesia DB and cluster state)<br>
> >>>> On the slaves hosts:<br>
> >>>> (5) Start RabbitMQ App (If failed, reset mnesia DB and cluster state)<br>
> >>>> (6) Join RabbitMQ cluster of the master host<br>
> >>>><br>
> >>> Yes, something like that. As I mentioned, there were several bug fixes<br>
> >>> in the 6.1 dev, and you can also check the MQ clustering flow charts.<br>
> >>><br>
> >>>> As far as I can understand, this process is to make sure the master<br>
> >>>> determined by pacemaker is the same as the master determined in<br>
> RabbitMQ<br>
> >>>> cluster. If there is no existing cluster, it's fine. If it is run<br>
> >>> after<br>
> >>><br>
> >>> Not exactly. There is no master in mirrored MQ cluster. We define the<br>
> >>> rabbit_hosts configuration option from Oslo.messaging. What ensures all<br>
> >>> queue masters will be spread around all of MQ nodes in a long run. And<br>
> >>> we use a master abstraction only for the Pacemaker RA clustering layer.<br>
> >>> Here, a "master" is the MQ node what joins the rest of the MQ nodes.<br>
> >>><br>
> >>>> power failure and recovery, it introduces the a new problem.<br>
> >>> We do erase the node master attribute in CIB for such cases. This<br>
> should<br>
> >>> not bring problems into the master election logic.<br>
> >>><br>
> >>>> After power recovery, if some of the RabbitMQ instances reach step (2)<br>
> >>>> roughly at the same time (within 30s which is hard coded in RabbitMQ)<br>
> as<br>
> >>>> the original RabbitMQ master instance, they form the original cluster<br>
> >>>> again and then shutdown. The other instances would have to wait for<br>
> 30s<br>
> >>>> before it reports failure waiting for tables, and be reset to a<br>
> >>>> standalone cluster.<br>
> >>>><br>
> >>>> In RabbitMQ documentation [4], it is also mentioned that if we<br>
> shutdown<br>
> >>>> RabbitMQ master, a new master is elected from the rest of slaves. If<br>
> we<br>
> >>> (Note, the RabbitMQ documentation mentions *queue* masters and slaves,<br>
> >>> which are not the case for the Pacemaker RA clustering abstraction<br>
> layer.)<br>
> >>><br>
> >>>> continue to shutdown nodes in step (3), we reach a point that the last<br>
> >>>> node is the RabbitMQ master, and pacemaker is not aware of it. I can<br>
> see<br>
> >>>> there is code to bookkeeping a "rabbit-start-time" attribute in<br>
> >>>> pacemaker to record the most long lived instance to help pacemaker<br>
> >>>> determine the master, but it does not cover the case mentioned above.<br>
> >>> We made an assumption what the node with the highest MQ uptime should<br>
> >>> know the most about recent cluster state, so other nodes must join it.<br>
> >>> RA OCF does not work with queue masters directly.<br>
> >>><br>
> >>>> A<br>
> >>>> recent patch [5] checks existing "rabbit-master" attribute but it<br>
> >>>> neither cover the above case.<br>
> >>>><br>
> >>>> So in step (4), pacemaker determines a different master which was a<br>
> >>>> RabbitMQ slave last time. It would wait for its original RabbitMQ<br>
> master<br>
> >>>> for 30s and fail, then it gets reset to a standalone cluster. Here we<br>
> >>>> get some different clusters, so in step (5) and (6), it is likely to<br>
> >>>> report error in log saying timeout waiting for tables or fail to merge<br>
> >>>> mnesia database schema, then the those instances get reset. You can<br>
> >>>> easily re-produce the case by hard resetting power of all the<br>
> controllers.<br>
> >>>><br>
> >>>> As you can see, if you are unlucky, there would be several "30s<br>
> timeout<br>
> >>>> and reset" before you finally get a healthy RabbitMQ cluster.<br>
> >>> The full MQ cluster reassemble logic is far from the perfect state,<br>
> >>> indeed. This might erase all mnesia files, hence any custom entities,<br>
> >>> like users or vhosts, would be removed as well. Note, we do not<br>
> >>> configure durable queues for Openstack so there is nothing to care<br>
> about<br>
> >>> here - the full cluster downtime assumes there will be no AMQP messages<br>
> >>> stored at all.<br>
> >>><br>
> >>>> I find three possible solutions.<br>
> >>>> A. Using rabbitmqctl force_boot option [6]<br>
> >>>> It will skips waiting for 30s and resetting cluster, but just assume<br>
> the<br>
> >>>> current node is the master and continue to operate. This is feasible<br>
> >>>> because the original RabbitMQ master would discards the local state<br>
> and<br>
> >>>> sync with the new master after it joins a new cluster [7]. So we can<br>
> be<br>
> >>>> sure that after step (4) and (6), the pacemaker determined master<br>
> >>>> instance is started unconditionally, and it will be the same as<br>
> RabbitMQ<br>
> >>>> master, and all operations run without 30s timeout. I find this option<br>
> >>>> is only available in newer RabbitMQ release, and updating RabbitMQ<br>
> might<br>
> >>>> introduce other compatibility problems.<br>
> >>> Yes, this option is only supported for newest RabbitMQ versions. But we<br>
> >>> definitely should look how this could help.<br>
> >>><br>
> >>>> B. Turn RabbitMQ into cloned instance and use pause_minority instead<br>
> of<br>
> >>>> autoheal [8]<br>
> >>> Indeed, there are cases when MQ's autoheal can do nothing with existing<br>
> >>> partitions and remains partitioned for ever, for example:<br>
> >>><br>
> >>> Masters: [ node-1 ]<br>
> >>> Slaves: [ node-2 node-3 ]<br>
> >>> root@node-1:~# rabbitmqctl cluster_status<br>
> >>> Cluster status of node 'rabbit@node-1' ...<br>
> >>> [{nodes,[{disc,['rabbit@node-1','rabbit@node-2']}]},<br>
> >>> {running_nodes,['rabbit@node-1']},<br>
> >>> {cluster_name,<<"rabbit@node-2">>},<br>
> >>> {partitions,[]}]<br>
> >>> ...done.<br>
> >>> root@node-2:~# rabbitmqctl cluster_status<br>
> >>> Cluster status of node 'rabbit@node-2' ...<br>
> >>> [{nodes,[{disc,['rabbit@node-2']}]}]<br>
> >>> ...done.<br>
> >>> root@node-3:~# rabbitmqctl cluster_status<br>
> >>> Cluster status of node 'rabbit@node-3' ...<br>
> >>> [{nodes,[{disc,['rabbit@node-1','rabbit@node-2','rabbit@node-3']}]},<br>
> >>> {running_nodes,['rabbit@node-3']},<br>
> >>> {cluster_name,<<"rabbit@node-2">>},<br>
> >>> {partitions,[]}]<br>
> >>><br>
> >>> So we should test the pause-minority value as well.<br>
> >>> But I strongly believe we should make MQ multi-state clone to support<br>
> >>> many masters, related bp [7]<br>
> >>><br>
> >>> [7]<br>
> >>><br>
> <a href="https://blueprints.launchpad.net/fuel/+spec/rabbitmq-pacemaker-multimaster-clone" target="_blank">https://blueprints.launchpad.net/fuel/+spec/rabbitmq-pacemaker-multimaster-clone</a><br>
> >>><br>
> >>>> This works like MySQL-wss. It let RabbitMQ cluster itself deal with<br>
> >>>> partition in a manner similar to pacemaker quorum mechanism. When<br>
> there<br>
> >>>> is network partition, instances in the minority partition pauses<br>
> >>>> themselves automatically. Pacemaker does not have to track who is the<br>
> >>>> RabbitMQ master, who lives longest, who to promote... It just starts<br>
> all<br>
> >>>> the clones, done. This leads to huge change in RabbitMQ resource<br>
> agent,<br>
> >>>> and the stability and other impact is to be tested.<br>
> >>> Well, we should not mess the queue masters and multi-clone master for<br>
> MQ<br>
> >>> resource in the pacemaker.<br>
> >>> As I said, pacemaker RA has nothing to do with queue masters. And we<br>
> >>> introduced this "master" mostly in order to support the full cluster<br>
> >>> reassemble case - there must be a node promoted and other nodes should<br>
> join.<br>
> >>><br>
> >>>> C. Creating a "force_load" file<br>
> >>>> After reading RabbitMQ source code, I find that the actual thing it<br>
> does<br>
> >>>> in solution A is just creating an empty file named "force_load" in<br>
> >>>> mnesia database dir, then mnesia thinks it is the last node shut down<br>
> in<br>
> >>>> the last time and boot itself as the master. This implementation keeps<br>
> >>>> the same from v3.1.4 to the latest RabbitMQ master branch. I think we<br>
> >>>> can make use of this little trick. The change is adding just one line<br>
> in<br>
> >>>> "try_to_start_rmq_app()" function.<br>
> >>>><br>
> >>>> touch "${MNESIA_FILES}/force_load" && \<br>
> >>>> chown rabbitmq:rabbitmq "${MNESIA_FILES}/force_load"<br>
> >>> This is a very good point, thank you.<br>
> >>><br>
> >>>> [4] <a href="http://www.rabbitmq.com/ha.html" target="_blank">http://www.rabbitmq.com/ha.html</a><br>
> >>>> [5] <a href="https://review.openstack.org/#/c/169291/" target="_blank">https://review.openstack.org/#/c/169291/</a><br>
> >>>> [6] <a href="https://www.rabbitmq.com/clustering.html" target="_blank">https://www.rabbitmq.com/clustering.html</a><br>
> >>>> [7] <a href="http://www.rabbitmq.com/partitions.html#recovering" target="_blank">http://www.rabbitmq.com/partitions.html#recovering</a><br>
> >>>> [8] <a href="http://www.rabbitmq.com/partitions.html#automatic-handling" target="_blank">http://www.rabbitmq.com/partitions.html#automatic-handling</a><br>
> >>>><br>
> >>>> Maybe you have better ideas on this. Please share your thoughts.<br>
> >>> Thank you for a thorough feedback! This was a really great job.<br>
> >>><br>
> >>>> ----<br>
> >>>> Best wishes!<br>
> >>>> Zhou Zheng Sheng / ??? Software Engineer<br>
> >>>> Beijing AWcloud Software Co., Ltd.<br>
> >>>><br>
> >>><br>
> >>> --<br>
> >>> Best regards,<br>
> >>> Bogdan Dobrelya,<br>
> >>> Skype #<a href="http://bogdando_at_yahoo.com" target="_blank">bogdando_at_yahoo.com</a><br>
> >>> Irc #bogdando<br>
> >>><br>
> >>><br>
> __________________________________________________________________________<br>
> >>> OpenStack Development Mailing List (not for usage questions)<br>
> >>> Unsubscribe:<br>
> <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</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 Development Mailing List (not for usage questions)<br>
> >> Unsubscribe:<br>
> <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</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 Development Mailing List (not for usage questions)<br>
> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</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>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20150519/4175e424/attachment-0001.html" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20150519/4175e424/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 25<br>
Date: Tue, 19 May 2015 14:07:59 -0700<br>
From: Sergey Lukjanov <<a href="mailto:slukjanov@mirantis.com">slukjanov@mirantis.com</a>><br>
To: "OpenStack Development Mailing List (not for usage questions)"<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] [surge] Introducing Surge - rapid<br>
deploy/scale stream processing systems on OpenStack<br>
Message-ID:<br>
<<a href="mailto:CA%2BGZd7_fNwFihgfLCqs-PZnyFRXRBd6hOLd7G7WdZnQVAmdypQ@mail.gmail.com">CA+GZd7_fNwFihgfLCqs-PZnyFRXRBd6hOLd7G7WdZnQVAmdypQ@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
Agreed with notes about the fact that mostly everything is already<br>
supported by Sahara. The question is there any hidden reason to not<br>
contribute it into Sahara?<br>
<br>
On Mon, May 18, 2015 at 4:38 PM, Andrew Lazarev <<a href="mailto:alazarev@mirantis.com">alazarev@mirantis.com</a>><br>
wrote:<br>
<br>
> As I see Surge is pretty much replicating Sahara functionality running in<br>
> "one process per host" mode. Sahara currently supports much more features.<br>
><br>
> Andrew.<br>
><br>
> On Fri, May 15, 2015 at 10:38 AM, Joe Gordon <<a href="mailto:joe.gordon0@gmail.com">joe.gordon0@gmail.com</a>><br>
> wrote:<br>
><br>
>><br>
>><br>
>> On Fri, May 15, 2015 at 10:13 AM, Debojyoti Dutta <<a href="mailto:ddutta@gmail.com">ddutta@gmail.com</a>><br>
>> wrote:<br>
>><br>
>>> Hi,<br>
>>><br>
>>> It gives me a great pleasure to introduce Surge - a system to rapidly<br>
>>> deploy and scale a stream processing system on OpenStack. It leverages<br>
>>> Vagrant and Ansible, and supports both OpenStack as well as the local mode<br>
>>> (with VirtualBox).<br>
>>><br>
>>> <a href="https://github.com/CiscoSystems/surge" target="_blank">https://github.com/CiscoSystems/surge</a><br>
>>><br>
>>><br>
>> I see you support Storm and Kafka,<br>
>><br>
>> How is this different then Sahara's Storm plugin?<br>
>><br>
>><br>
>> <a href="https://github.com/openstack/sahara/blob/45045d918f363fa5763cde700561434345017661/setup.cfg#L47" target="_blank">https://github.com/openstack/sahara/blob/45045d918f363fa5763cde700561434345017661/setup.cfg#L47</a><br>
>><br>
>> And I See Sahara is exploring Kafka support:<br>
>> <a href="https://blueprints.launchpad.net/sahara/+spec/cdh-kafka-service" target="_blank">https://blueprints.launchpad.net/sahara/+spec/cdh-kafka-service</a><br>
>><br>
>><br>
>>> Hope to see a lot of pull requests and comments.<br>
>>><br>
>>> thx<br>
>>> -Debo~<br>
>>><br>
>>><br>
>>> __________________________________________________________________________<br>
>>> OpenStack Development Mailing List (not for usage questions)<br>
>>> Unsubscribe:<br>
>>> <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</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 Development Mailing List (not for usage questions)<br>
>> Unsubscribe:<br>
>> <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</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 Development Mailing List (not for usage questions)<br>
> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</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>
Sincerely yours,<br>
Sergey Lukjanov<br>
Sahara Technical Lead<br>
(OpenStack Data Processing)<br>
Principal Software Engineer<br>
Mirantis Inc.<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20150519/e3fce5b4/attachment-0001.html" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20150519/e3fce5b4/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 26<br>
Date: Tue, 19 May 2015 14:16:09 -0700<br>
From: Sergey Lukjanov <<a href="mailto:slukjanov@mirantis.com">slukjanov@mirantis.com</a>><br>
To: "OpenStack Development Mailing List (not for usage questions)"<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] [new][cognitive] Announcing Cognitive - a<br>
project to deliver Machine Learning as a Service for OpenStack<br>
Message-ID:<br>
<CA+GZd79SK1o=aY-0Uij4THCDakyK-2VWd6jbfBy5DRb23Dy=<a href="mailto:bw@mail.gmail.com">bw@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
Hi,<br>
<br>
as there is no any details on the project yet done, if this project will<br>
deploy ML frameworks it'll be direct duplication of Sahara's functionality<br>
(we already support HDP and CDH deployments and they are provided tons of<br>
tools for ML). So, I think that it could be built on top of Sahara or even<br>
as part of Sahara probably. I'd like to propose you to take a deeper look<br>
on Sahara and avoid duplicating it.<br>
<br>
Thanks.<br>
<br>
On Thu, May 14, 2015 at 8:47 PM, Debojyoti Dutta <<a href="mailto:ddutta@gmail.com">ddutta@gmail.com</a>> wrote:<br>
<br>
> Hi Salvatore<br>
><br>
> Thanks a lot for your comments.<br>
><br>
> Timing: Yes it is time to do this! The nature of applications running on<br>
> clouds is indeed changing.<br>
><br>
> Initial group: We asked around for folks interested and we got a lot more<br>
> people than we expected. The idea is to get something out there in a stack<br>
> forge project and build something good. This group already has people who<br>
> have built things like this already in the past. Hence confident about the<br>
> success.<br>
><br>
> Participation: We want this to be inclusive from scratch independent of<br>
> who is a PTL or a contributor or merely a curious individual to give us<br>
> ideas :) The community will get it right. Maybe I should have clarified<br>
> that these are the members interested in seeing this happen.<br>
><br>
> Wiki page: The wiki page will be ready in 1-2 days. Also we would like to<br>
> have a discussion during the summit to see what we should build in the<br>
> community. Would be delighted to get your thoughts.<br>
><br>
> Services: Some of the services this could provide:<br>
> * create experiments: define data sources, train models, then perform<br>
> classification, clustering, data cleaning etc.<br>
> * have experiment templates that can be reused<br>
> * have an editor (maybe a horizon plugin) to drag and drop the workflow<br>
> and generate an API that when called from an app would provide results<br>
> * ML primitives that could be targeted initially: 1) classification 2)<br>
> clustering 3) Anomaly detection<br>
><br>
> thx<br>
> debo<br>
><br>
> On Thu, May 14, 2015 at 5:02 PM, Salvatore Orlando <<a href="mailto:sorlando@nicira.com">sorlando@nicira.com</a>><br>
> wrote:<br>
><br>
>><br>
>> On 15 May 2015 at 00:19, Debojyoti Dutta <<a href="mailto:ddutta@gmail.com">ddutta@gmail.com</a>> wrote:<br>
>><br>
>>> Hi!<br>
>>><br>
>>> It is a great pleasure to announce the development of a new project<br>
>>> called Cognitive. Cognitive provides Machine Learning [1] as a Service<br>
>>> that enables operators to offer next generation data science based services<br>
>>> on top of their OpenStack Clouds.<br>
>>><br>
>><br>
>> I was indeed wondering when "Machine Learning as a Service" would come<br>
>> up...<br>
>><br>
>><br>
>>> This project will begin as a StackForge project baed upon an empty<br>
>>> cookiecutter [2] repo. The repos to work in are:<br>
>>> Server: <a href="https://github.com/stackforge/cognitive" target="_blank">https://github.com/stackforge/cognitive</a><br>
>>> Client: <a href="https://github.com/stackforge/python-cognitiveclient" target="_blank">https://github.com/stackforge/python-cognitiveclient</a><br>
>>><br>
>>> Please join us via iRC on #openstack-cognitive on freenode.<br>
>>><br>
>>> We will be holding a doodle poll to select times for our first meeting<br>
>>> the week after summit. This doodle poll will close May 24th and meeting<br>
>>> times will be announced on the mailing list at that time. At our first IRC<br>
>>> meeting, we will draft additional core team members. We would like to<br>
>>> invite interested individuals to join this exciting new development effort!<br>
>>><br>
>><br>
>> From my little experience, "drafting" core members before even actually<br>
>> having a code base has drawbacks. Also, it seems the initial starting team<br>
>> is already large enough for ensuring support for 1 or 2 release cycle.<br>
>><br>
>><br>
>>><br>
>>><br>
>><br>
>>> Please commit your schedule in the doodle poll here:<br>
>>> <a href="http://doodle.com/drrka5tgbwpbfbxy" target="_blank">http://doodle.com/drrka5tgbwpbfbxy</a><br>
>>><br>
>>> Initial core team: Steven Dake, Aparupa Das Gupa, Debo~ Dutta, Johnu<br>
>>> George, Kyle Mestery, Sarvesh Ranjan, Ralf Rantzau, Komei Shimamura, Marc<br>
>>> Solanas, Manoj Sharma, Yathi Udupi, Kai Zhang.<br>
>>><br>
>><br>
>> Hey! What's the Neutron PTL doing there? Sorry we need his reviews we<br>
>> can't loan it to you!<br>
>><br>
>><br>
>>><br>
>>> A little bit about Cognitive:<br>
>>> Data driven applications on cloud infrastructure increasingly rely on<br>
>>> Machine Learning. Most data driven applications today use Machine Learning<br>
>>> (ML). This often requires application developers and data scientists to<br>
>>> write their own machine learning stack or deploy other packages to do any<br>
>>> kind of data science based applications. Data scientists also need to have<br>
>>> an easy way to rapidly experiment with data without having to write basic<br>
>>> infrastructure for data manipulations. Cognitive is a Machine Learning<br>
>>> service on top of OpenStack and provides machine learning based services to<br>
>>> tenants (API, workbench, compute service).<br>
>>><br>
>><br>
>> I wonder what kind of services you would offer; also you could have<br>
>> shared something about the architecture of this service. Is it providing a<br>
>> full machine learning stack, or just facilitating the use of existing one?<br>
>><br>
>> But I see that there's a link to a wiki page below. This might have all<br>
>> the answers.<br>
>><br>
>><br>
>>><br>
>>><br>
>>> For information about blueprints check out:<br>
>>> <a href="https://blueprints.launchpad.net/cognitive" target="_blank">https://blueprints.launchpad.net/cognitive</a><br>
>>> <a href="https://blueprints.launchpad.net/python-cognitiveclient" target="_blank">https://blueprints.launchpad.net/python-cognitiveclient</a><br>
>>><br>
>>> For more details, check out our Wiki:<br>
>>> <a href="https://wiki.openstack.org/wiki/Cognitive" target="_blank">https://wiki.openstack.org/wiki/Cognitive</a><br>
>>><br>
>><br>
>> ... and unfortunately the wiki is empty ;)<br>
>><br>
>><br>
>>><br>
>>> Please join the awesome Cognitive team in designing a world class<br>
>>> Machine Learning as a Service solution.<br>
>>><br>
>>> We look forward to seeing you on IRC on #openstack-cognitive.<br>
>>><br>
>>> Regards,<br>
>>> Debo~ Dutta (on behalf of the initial team)<br>
>>><br>
>>> [1] <a href="http://en.wikipedia.org/wiki/Machine_learning" target="_blank">http://en.wikipedia.org/wiki/Machine_learning</a><br>
>>> [2] <a href="https://github.com/openstack-dev/cookiecutter" target="_blank">https://github.com/openstack-dev/cookiecutter</a><br>
>>><br>
>>><br>
>>> __________________________________________________________________________<br>
>>> OpenStack Development Mailing List (not for usage questions)<br>
>>> Unsubscribe:<br>
>>> <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</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 Development Mailing List (not for usage questions)<br>
>> Unsubscribe:<br>
>> <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</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>
> -Debo~<br>
><br>
> __________________________________________________________________________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</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>
Sincerely yours,<br>
Sergey Lukjanov<br>
Sahara Technical Lead<br>
(OpenStack Data Processing)<br>
Principal Software Engineer<br>
Mirantis Inc.<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20150519/7fa6097a/attachment-0001.html" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20150519/7fa6097a/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 27<br>
Date: Tue, 19 May 2015 14:16:55 -0700<br>
From: Sergey Lukjanov <<a href="mailto:slukjanov@mirantis.com">slukjanov@mirantis.com</a>><br>
To: "OpenStack Development Mailing List (not for usage questions)"<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] [surge] Introducing Surge - rapid<br>
deploy/scale stream processing systems on OpenStack<br>
Message-ID:<br>
<<a href="mailto:CA%2BGZd7_5%2BY7Es6YF7fMcOXBJ4fURFM_zJhrVmG28hwS6c-_tPw@mail.gmail.com">CA+GZd7_5+Y7Es6YF7fMcOXBJ4fURFM_zJhrVmG28hwS6c-_tPw@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
Actually the same as for the MLaaS - please, take a deeper look at Sahara<br>
before starting duplicating already existing things.<br>
<br>
On Tue, May 19, 2015 at 2:07 PM, Sergey Lukjanov <<a href="mailto:slukjanov@mirantis.com">slukjanov@mirantis.com</a>><br>
wrote:<br>
<br>
> Agreed with notes about the fact that mostly everything is already<br>
> supported by Sahara. The question is there any hidden reason to not<br>
> contribute it into Sahara?<br>
><br>
> On Mon, May 18, 2015 at 4:38 PM, Andrew Lazarev <<a href="mailto:alazarev@mirantis.com">alazarev@mirantis.com</a>><br>
> wrote:<br>
><br>
>> As I see Surge is pretty much replicating Sahara functionality running<br>
>> in "one process per host" mode. Sahara currently supports much more<br>
>> features.<br>
>><br>
>> Andrew.<br>
>><br>
>> On Fri, May 15, 2015 at 10:38 AM, Joe Gordon <<a href="mailto:joe.gordon0@gmail.com">joe.gordon0@gmail.com</a>><br>
>> wrote:<br>
>><br>
>>><br>
>>><br>
>>> On Fri, May 15, 2015 at 10:13 AM, Debojyoti Dutta <<a href="mailto:ddutta@gmail.com">ddutta@gmail.com</a>><br>
>>> wrote:<br>
>>><br>
>>>> Hi,<br>
>>>><br>
>>>> It gives me a great pleasure to introduce Surge - a system to rapidly<br>
>>>> deploy and scale a stream processing system on OpenStack. It leverages<br>
>>>> Vagrant and Ansible, and supports both OpenStack as well as the local mode<br>
>>>> (with VirtualBox).<br>
>>>><br>
>>>> <a href="https://github.com/CiscoSystems/surge" target="_blank">https://github.com/CiscoSystems/surge</a><br>
>>>><br>
>>>><br>
>>> I see you support Storm and Kafka,<br>
>>><br>
>>> How is this different then Sahara's Storm plugin?<br>
>>><br>
>>><br>
>>> <a href="https://github.com/openstack/sahara/blob/45045d918f363fa5763cde700561434345017661/setup.cfg#L47" target="_blank">https://github.com/openstack/sahara/blob/45045d918f363fa5763cde700561434345017661/setup.cfg#L47</a><br>
>>><br>
>>> And I See Sahara is exploring Kafka support:<br>
>>> <a href="https://blueprints.launchpad.net/sahara/+spec/cdh-kafka-service" target="_blank">https://blueprints.launchpad.net/sahara/+spec/cdh-kafka-service</a><br>
>>><br>
>>><br>
>>>> Hope to see a lot of pull requests and comments.<br>
>>>><br>
>>>> thx<br>
>>>> -Debo~<br>
>>>><br>
>>>><br>
>>>> __________________________________________________________________________<br>
>>>> OpenStack Development Mailing List (not for usage questions)<br>
>>>> Unsubscribe:<br>
>>>> <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</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>
>>> OpenStack Development Mailing List (not for usage questions)<br>
>>> Unsubscribe:<br>
>>> <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</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 Development Mailing List (not for usage questions)<br>
>> Unsubscribe:<br>
>> <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</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>
> Sincerely yours,<br>
> Sergey Lukjanov<br>
> Sahara Technical Lead<br>
> (OpenStack Data Processing)<br>
> Principal Software Engineer<br>
> Mirantis Inc.<br>
><br>
<br>
<br>
<br>
--<br>
Sincerely yours,<br>
Sergey Lukjanov<br>
Sahara Technical Lead<br>
(OpenStack Data Processing)<br>
Principal Software Engineer<br>
Mirantis Inc.<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20150519/d4fba6e7/attachment-0001.html" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20150519/d4fba6e7/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 28<br>
Date: Wed, 20 May 2015 09:04:11 +1200<br>
From: Fei Long Wang <<a href="mailto:feilong@catalyst.net.nz">feilong@catalyst.net.nz</a>><br>
To: <a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a><br>
Subject: Re: [openstack-dev] [glance] missing implementation on glance<br>
basic quota<br>
Message-ID: <<a href="mailto:555BA54B.9060204@catalyst.net.nz">555BA54B.9060204@catalyst.net.nz</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
We're using user_storage_quota to limit the total number of bytes of<br>
each user for now based on the discussion, you can see that from the<br>
blueprint. May I know your user case for number of images? Cheers.<br>
<br>
On 20/05/15 02:10, Gareth wrote:<br>
> Hi glance guys<br>
><br>
> There is a bp[0] said it would implement two basic quota usage:<br>
><br>
> a, the number of image stored<br>
> b, the amount of storage in occupied by a set of image<br>
><br>
> However, only b is implemented in the patch[1], and a is still missing<br>
> in current glance.<br>
><br>
> [0] <a href="https://blueprints.launchpad.net/glance/+spec/glance-basic-quotas" target="_blank">https://blueprints.launchpad.net/glance/+spec/glance-basic-quotas</a><br>
> [1] <a href="https://review.openstack.org/#/c/37993/18" target="_blank">https://review.openstack.org/#/c/37993/18</a><br>
><br>
> --<br>
> Gareth<br>
><br>
> /Cloud Computing, OpenStack, Distributed Storage, Fitness, Basketball/<br>
> /OpenStack contributor, kun_huang@freenode/<br>
> /My promise: if you find any spelling or grammar mistakes in my email<br>
> from Mar 1 2013, notify me /<br>
> /and I'll donate $1 or ?1 to an open organization you specify./<br>
><br>
><br>
> __________________________________________________________________________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</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>
Cheers & Best regards,<br>
Fei Long Wang (???)<br>
--------------------------------------------------------------------------<br>
Senior Cloud Software Engineer<br>
Tel: +64-48032246<br>
Email: <a href="mailto:flwang@catalyst.net.nz">flwang@catalyst.net.nz</a><br>
Catalyst IT Limited<br>
Level 6, Catalyst House, 150 Willis Street, Wellington<br>
--------------------------------------------------------------------------<br>
<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20150520/de494919/attachment-0001.html" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20150520/de494919/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 29<br>
Date: Tue, 19 May 2015 14:18:36 -0700<br>
From: Sam Morrison <<a href="mailto:sorrison@gmail.com">sorrison@gmail.com</a>><br>
To: "OpenStack Development Mailing List (not for usage questions)"<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: [openstack-dev] [nova] Tempest failure help<br>
Message-ID: <<a href="mailto:7712CFBF-68BF-4EC9-A885-626BC283A34F@gmail.com">7712CFBF-68BF-4EC9-A885-626BC283A34F@gmail.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
Hi nova devs,<br>
<br>
I have a patch <a href="https://review.openstack.org/#/c/181776/" target="_blank">https://review.openstack.org/#/c/181776/</a> <<a href="https://review.openstack.org/#/c/181776/" target="_blank">https://review.openstack.org/#/c/181776/</a>> where I have a failing tempest job which I can?t figure out. Can anyone help me?<br>
<br>
Cheers,<br>
Sam<br>
<br>
<br>
<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20150519/cf7d3303/attachment-0001.html" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20150519/cf7d3303/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 30<br>
Date: Tue, 19 May 2015 14:20:48 -0700<br>
From: Sergey Lukjanov <<a href="mailto:slukjanov@mirantis.com">slukjanov@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: [openstack-dev] [sahara] no meetings May 21 and 28<br>
Message-ID:<br>
<<a href="mailto:CA%2BGZd7_KzQTvkgrNW-OphqaR9%2ByQL6xdwHjK0uB52EigG0vmsg@mail.gmail.com">CA+GZd7_KzQTvkgrNW-OphqaR9+yQL6xdwHjK0uB52EigG0vmsg@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
Hey,<br>
<br>
on the meeting last week we agreed to skip IRC meetings on a summer week<br>
and on a week after.<br>
<br>
Thanks.<br>
<br>
--<br>
Sincerely yours,<br>
Sergey Lukjanov<br>
Sahara Technical Lead<br>
(OpenStack Data Processing)<br>
Principal Software Engineer<br>
Mirantis Inc.<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20150519/51e41a9d/attachment-0001.html" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20150519/51e41a9d/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 31<br>
Date: Tue, 19 May 2015 17:29:40 -0400 (EDT)<br>
From: Dan Lambright <<a href="mailto:dlambrig@redhat.com">dlambrig@redhat.com</a>><br>
To: <a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a><br>
Subject: [openstack-dev] [security] / IDS + openstack meeting in<br>
Vancouver 4:10 Wednesday May 20<br>
Message-ID:<br>
<<a href="mailto:155985814.1002516.1432070980605.JavaMail.zimbra@redhat.com">155985814.1002516.1432070980605.JavaMail.zimbra@redhat.com</a>><br>
Content-Type: text/plain; charset=utf-8<br>
<br>
Hello,<br>
<br>
While at the Vancouver summit, it would be good to have an informal meeting on IDS + openstack. My understanding is there has not been a community driven effort in this area to date. It would be good to kick something off. Likely subjects would be neutron plug-ins and scalability (management and monitoring).<br>
<br>
The best time would probably be after the TaaS talk Wednesday. TaaS may influence what direction to take.<br>
<br>
I will be next to the ATM machine on the 1st floor, next to where they give away the windbreaker SWAG. I?ll hang out there between 4:10 and 4:30. Please feel free to find a drink and walk over. I will also post this announcement to the openstack-dev mailing list (<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>). The subject will contain: [security] {IDS}<br>
<br>
Thanks,<br>
<br>
Dan Lambright<br>
Red Hat<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 32<br>
Date: Tue, 19 May 2015 17:30:07 -0400 (EDT)<br>
From: Victor Stinner <<a href="mailto:vstinner@redhat.com">vstinner@redhat.com</a>><br>
To: "OpenStack Development Mailing List (not for usage questions)"<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] [all] gate pep8 jobs broken today<br>
Message-ID:<br>
<<a href="mailto:297176382.2081976.1432071007216.JavaMail.zimbra@redhat.com">297176382.2081976.1432071007216.JavaMail.zimbra@redhat.com</a>><br>
Content-Type: text/plain; charset=utf-8<br>
<br>
Hi,<br>
<br>
I found a related issue in glance.<br>
<br>
"issue with pbr 1.0 release"<br>
<a href="https://bugs.launchpad.net/glance/+bug/1456800" target="_blank">https://bugs.launchpad.net/glance/+bug/1456800</a><br>
<br>
"Modify entry point tests to not require deps"<br>
<a href="https://review.openstack.org/#/c/184326/" target="_blank">https://review.openstack.org/#/c/184326/</a><br>
<br>
Victor<br>
<br>
----- Original Message -----<br>
> From: "Robert Collins" <<a href="mailto:robertc@robertcollins.net">robertc@robertcollins.net</a>><br>
> To: "OpenStack Development Mailing List" <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
> Sent: Monday, May 18, 2015 5:54:43 PM<br>
> Subject: [openstack-dev] [all] gate pep8 jobs broken today<br>
><br>
> Hi, we had a gate outage today for a few hours.<br>
><br>
> <a href="http://pad.lv/1456376" target="_blank">http://pad.lv/1456376</a><br>
><br>
> The issue was an interaction between the existence of pbr 1.0, project<br>
> local requirements, hacking 0.10.1 and flake8 <2.4.1.<br>
><br>
> When flake8< 2.4.1 loads plugins (which hacking is) it uses<br>
> pkg_resources and calls load(), which checks requirements.<br>
><br>
> pbr in the pep8 jobs is installed by the project requirements.txt<br>
> files, which per global-requirements mostly now say ">=0.11, <2.0", so<br>
> pbr 1.0.0 was immediately installed once it was released.<br>
><br>
> hacking is installed from release, so hacking 0.10.1 was installed,<br>
> which has the constraint for pbr of <1.0 that we had prior to bumping<br>
> the releases in global-requirements. And so boom.<br>
><br>
> We've now released hacking 0.10.2, which contains only the updated pbr<br>
> constraint, and we don't expect any additional fallout from it.<br>
><br>
> Thanks Clark, Doug, Ian, Sean, and Joe for helping unwind, analyze and fix<br>
> this.<br>
><br>
> -Rob<br>
><br>
> --<br>
> Robert Collins <<a href="mailto:rbtcollins@hp.com">rbtcollins@hp.com</a>><br>
> Distinguished Technologist<br>
> HP Converged Cloud<br>
><br>
> __________________________________________________________________________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</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: 33<br>
Date: Tue, 19 May 2015 21:44:55 +0000<br>
From: Alan Kavanagh <<a href="mailto:alan.kavanagh@ericsson.com">alan.kavanagh@ericsson.com</a>><br>
To: "OpenStack Development Mailing List (not for usage questions)"<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] / IDS + openstack meeting in Vancouver<br>
4:10 Wednesday May 20<br>
Message-ID:<br>
<<a href="mailto:C977B257ADF8814C8EB4FB66BB9D0C2EA3BA05@eusaamb109.ericsson.se">C977B257ADF8814C8EB4FB66BB9D0C2EA3BA05@eusaamb109.ericsson.se</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
Hi Dan <a href="http://et.al" target="_blank">et.al</a><br>
<br>
Thanks for reaching out, I attended your IDS talk yesterday and we can meet up after our TaaS tech talk where we do a walk through from the why, what and how and a demo with detail explanations on its built.<br>
/Alan<br>
<br>
-----Original Message-----<br>
From: Dan Lambright [mailto:<a href="mailto:dlambrig@redhat.com">dlambrig@redhat.com</a>]<br>
Sent: May-19-15 2:30 PM<br>
To: <a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a><br>
Subject: [openstack-dev] [security] / IDS + openstack meeting in Vancouver 4:10 Wednesday May 20<br>
<br>
Hello,<br>
<br>
While at the Vancouver summit, it would be good to have an informal meeting on IDS + openstack. My understanding is there has not been a community driven effort in this area to date. It would be good to kick something off. Likely subjects would be neutron plug-ins and scalability (management and monitoring).<br>
<br>
The best time would probably be after the TaaS talk Wednesday. TaaS may influence what direction to take.<br>
<br>
I will be next to the ATM machine on the 1st floor, next to where they give away the windbreaker SWAG. I?ll hang out there between 4:10 and 4:30. Please feel free to find a drink and walk over. I will also post this announcement to the openstack-dev mailing list (<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>). The subject will contain: [security] {IDS}<br>
<br>
Thanks,<br>
<br>
Dan Lambright<br>
Red Hat<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</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>
Message: 34<br>
Date: Wed, 20 May 2015 00:01:37 +0200<br>
From: Flavio Percoco <<a href="mailto:flavio@redhat.com">flavio@redhat.com</a>><br>
To: "Daniel P. Berrange" <<a href="mailto:berrange@redhat.com">berrange@redhat.com</a>>, "OpenStack Development<br>
Mailing List (not for usage questions)"<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] [nova][glance] Format of 'locations' data<br>
in image metadata ?<br>
Message-ID: <<a href="mailto:20150519220137.GC18488@redhat.com">20150519220137.GC18488@redhat.com</a>><br>
Content-Type: text/plain; charset="utf-8"; Format="flowed"<br>
<br>
On 19/05/15 17:19 +0100, Daniel P. Berrange wrote:<br>
>In Nova we are attempting to model[1] the glance image metadata and<br>
>properties using the Nova object model (now oslo.versionedobjects).<br>
><br>
>The one item I'm stuck on understanding is the 'locations' field<br>
>and more specifically the 'metadata' element in each location<br>
>entry<br>
><br>
><br>
>In the file glance/api/v2/images.py I can see this description<br>
>of the data format:<br>
><br>
> 'locations': {<br>
> 'type': 'array',<br>
> 'items': {<br>
> 'type': 'object',<br>
> 'properties': {<br>
> 'url': {<br>
> 'type': 'string',<br>
> 'maxLength': 255,<br>
> },<br>
> 'metadata': {<br>
> 'type': 'object',<br>
> },<br>
> },<br>
> 'required': ['url', 'metadata'],<br>
> },<br>
> 'description': _('A set of URLs to access the image file kept in '<br>
> 'external store'),<br>
><br>
><br>
>As you can see here, 'metadata' is just said to be of type 'object'.<br>
><br>
>Is there somewhere that actually describes what is valid contents<br>
>for this field ? Is it sufficient to assume the metadata will only<br>
>ever be a dict of strings, or can the metadata be a complex type<br>
>with arbitrarily nested data structures ?<br>
<br>
It's just arbitrary metadata for now, we don't have a specific format.<br>
I'm curious to know if there are folks using this field. We do (did)<br>
have a use case for it.<br>
<br>
Flavio<br>
><br>
>Regards,<br>
>Daniel<br>
><br>
>[1] <a href="https://review.openstack.org/#/c/76234/" target="_blank">https://review.openstack.org/#/c/76234/</a><br>
>--<br>
>|: <a href="http://berrange.com" target="_blank">http://berrange.com</a> -o- <a href="http://www.flickr.com/photos/dberrange/" target="_blank">http://www.flickr.com/photos/dberrange/</a> :|<br>
>|: <a href="http://libvirt.org" target="_blank">http://libvirt.org</a> -o- <a href="http://virt-manager.org" target="_blank">http://virt-manager.org</a> :|<br>
>|: <a href="http://autobuild.org" target="_blank">http://autobuild.org</a> -o- <a href="http://search.cpan.org/~danberr/" target="_blank">http://search.cpan.org/~danberr/</a> :|<br>
>|: <a href="http://entangle-photo.org" target="_blank">http://entangle-photo.org</a> -o- <a href="http://live.gnome.org/gtk-vnc" target="_blank">http://live.gnome.org/gtk-vnc</a> :|<br>
><br>
>__________________________________________________________________________<br>
>OpenStack Development Mailing List (not for usage questions)<br>
>Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</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>
@flaper87<br>
Flavio Percoco<br>
-------------- next part --------------<br>
A non-text attachment was scrubbed...<br>
Name: not available<br>
Type: application/pgp-signature<br>
Size: 819 bytes<br>
Desc: not available<br>
URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20150520/b5373b24/attachment-0001.pgp" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20150520/b5373b24/attachment-0001.pgp</a>><br>
<br>
------------------------------<br>
<br>
Message: 35<br>
Date: Tue, 19 May 2015 22:12:16 +0000<br>
From: "Clark, Robert Graham" <<a href="mailto:robert.clark@hp.com">robert.clark@hp.com</a>><br>
To: "OpenStack Development Mailing List (not for usage questions)"<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] [security] / IDS + openstack meeting in<br>
Vancouver 4:10 Wednesday May 20<br>
Message-ID: <<a href="mailto:D1810296.1CF6C%25robert.clark@hp.com">D1810296.1CF6C%robert.clark@hp.com</a>><br>
Content-Type: text/plain; charset="iso-8859-1"<br>
<br>
Sounds good, I?m not sure if I?ll be able to make it, or in fact if TaaS<br>
is the way forward, there?s a few different options in this space and<br>
personally I like bump in the wire OVS - something to discuss :)<br>
<br>
I?ll try to make it but I expect this is will be a long running discussion.<br>
<br>
Kind Regard<br>
<br>
On 19/05/2015 14:29, "Dan Lambright" <<a href="mailto:dlambrig@redhat.com">dlambrig@redhat.com</a>> wrote:<br>
<br>
>Hello,<br>
><br>
>While at the Vancouver summit, it would be good to have an informal<br>
>meeting on IDS + openstack. My understanding is there has not been a<br>
>community driven effort in this area to date. It would be good to kick<br>
>something off. Likely subjects would be neutron plug-ins and scalability<br>
>(management and monitoring).<br>
><br>
>The best time would probably be after the TaaS talk Wednesday. TaaS may<br>
>influence what direction to take.<br>
><br>
>I will be next to the ATM machine on the 1st floor, next to where they<br>
>give away the windbreaker SWAG. I?ll hang out there between 4:10 and<br>
>4:30. Please feel free to find a drink and walk over. I will also post<br>
>this announcement to the openstack-dev mailing list<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>). The<br>
>subject will contain: [security] {IDS}<br>
><br>
>Thanks,<br>
><br>
>Dan Lambright<br>
>Red Hat<br>
><br>
>__________________________________________________________________________<br>
>OpenStack Development Mailing List (not for usage questions)<br>
>Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</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: 36<br>
Date: Wed, 20 May 2015 10:16:32 +1200<br>
From: Robert Collins <<a href="mailto:robertc@robertcollins.net">robertc@robertcollins.net</a>><br>
To: "OpenStack Development Mailing List (not for usage questions)"<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] [all] gate pep8 jobs broken today<br>
Message-ID:<br>
<<a href="mailto:CAJ3HoZ2y%2BR8c2CN8JCJBNtWAEkMzhNhGJvxOBXHmovLnsMvo%2Bg@mail.gmail.com">CAJ3HoZ2y+R8c2CN8JCJBNtWAEkMzhNhGJvxOBXHmovLnsMvo+g@mail.gmail.com</a>><br>
Content-Type: text/plain; charset=UTF-8<br>
<br>
On 20 May 2015 at 09:30, Victor Stinner <<a href="mailto:vstinner@redhat.com">vstinner@redhat.com</a>> wrote:<br>
> Hi,<br>
><br>
> I found a related issue in glance.<br>
><br>
> "issue with pbr 1.0 release"<br>
> <a href="https://bugs.launchpad.net/glance/+bug/1456800" target="_blank">https://bugs.launchpad.net/glance/+bug/1456800</a><br>
><br>
> "Modify entry point tests to not require deps"<br>
> <a href="https://review.openstack.org/#/c/184326/" target="_blank">https://review.openstack.org/#/c/184326/</a><br>
<br>
So its the same pattern: pkg_resources is being asked to validate the<br>
dependencies, and they are failing because pip doesn't have a resolver<br>
and we've installed something strictly outside the deps of e.g.<br>
oslo.db.<br>
<br>
I recommended on the bug to use require=False, at least until we've<br>
worked through our management of dependencies to be less fragile.<br>
<br>
-Rob<br>
<br>
--<br>
Robert Collins <<a href="mailto:rbtcollins@hp.com">rbtcollins@hp.com</a>><br>
Distinguished Technologist<br>
HP Converged Cloud<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 37<br>
Date: Tue, 19 May 2015 15:22:28 -0700<br>
From: Matt Riedemann <<a href="mailto:mriedem@linux.vnet.ibm.com">mriedem@linux.vnet.ibm.com</a>><br>
To: <a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a><br>
Subject: Re: [openstack-dev] [nova] Tempest failure help<br>
Message-ID: <<a href="mailto:555BB7A4.80501@linux.vnet.ibm.com">555BB7A4.80501@linux.vnet.ibm.com</a>><br>
Content-Type: text/plain; charset=windows-1252; format=flowed<br>
<br>
<br>
<br>
On 5/19/2015 2:18 PM, Sam Morrison wrote:<br>
> Hi nova devs,<br>
><br>
> I have a patch <a href="https://review.openstack.org/#/c/181776/" target="_blank">https://review.openstack.org/#/c/181776/</a> where I have a<br>
> failing tempest job which I can?t figure out. Can anyone help me?<br>
><br>
> Cheers,<br>
> Sam<br>
><br>
><br>
><br>
><br>
><br>
> __________________________________________________________________________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</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>
I dug a little bit in your change and I think the problem is a random az<br>
getting set as the device_owner. If you look at a change that's passing<br>
the neutron job, you'll see the device_owner on the port is<br>
'compute:None' so instance.availability_zone is None in these test runs.<br>
<br>
In your change, it's a random number for the az which is screwing<br>
something up somewhere. Could be a problem elsewhere in nova, or<br>
neutron, or tempest, or devstack, that's something I don't know right<br>
now. :(<br>
<br>
--<br>
<br>
Thanks,<br>
<br>
Matt Riedemann<br>
<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 38<br>
Date: Tue, 19 May 2015 15:25:14 -0700<br>
From: Matt Riedemann <<a href="mailto:mriedem@linux.vnet.ibm.com">mriedem@linux.vnet.ibm.com</a>><br>
To: "OpenStack Development Mailing List (not for usage questions)"<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: [openstack-dev] [nova] Friday summit meetup etherpad<br>
Message-ID: <<a href="mailto:555BB84A.7010703@linux.vnet.ibm.com">555BB84A.7010703@linux.vnet.ibm.com</a>><br>
Content-Type: text/plain; charset=utf-8; format=flowed<br>
<br>
I was looking for this earlier in IRC and bauzas was nice enough to give<br>
me the link, so here is the Friday summit meetup etherpad for people<br>
that want to drop some notes:<br>
<br>
<a href="https://etherpad.openstack.org/p/YVR-nova-contributor-meetup" target="_blank">https://etherpad.openstack.org/p/YVR-nova-contributor-meetup</a><br>
<br>
I had a couple of smaller issues that I didn't want to forget about so I<br>
added those at the bottom.<br>
<br>
--<br>
<br>
Thanks,<br>
<br>
Matt Riedemann<br>
<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 39<br>
Date: Wed, 20 May 2015 10:47:03 +1200<br>
From: Robert Collins <<a href="mailto:robertc@robertcollins.net">robertc@robertcollins.net</a>><br>
To: "OpenStack Development Mailing List (not for usage questions)"<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] [all] gate pep8 jobs broken today<br>
Message-ID:<br>
<<a href="mailto:CAJ3HoZ06W9Xi7W56Aic8%2BWGctFapuwVCZZ9eZrv3YCC__YVnGg@mail.gmail.com">CAJ3HoZ06W9Xi7W56Aic8+WGctFapuwVCZZ9eZrv3YCC__YVnGg@mail.gmail.com</a>><br>
Content-Type: text/plain; charset=UTF-8<br>
<br>
There was one more issue - <a href="https://bugs.launchpad.net/pbr/+bug/1456663" target="_blank">https://bugs.launchpad.net/pbr/+bug/1456663</a><br>
- which has now been fixed in pbr 1.0.1.<br>
<br>
-Rob<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 40<br>
Date: Wed, 20 May 2015 11:07:36 +1200<br>
From: Robert Collins <<a href="mailto:robertc@robertcollins.net">robertc@robertcollins.net</a>><br>
To: OpenStack Development Mailing List<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: [openstack-dev] [pbr] 1.0.1 released<br>
Message-ID:<br>
<CAJ3HoZ1mHTc=<a href="mailto:ZCqnQVPwjfry-g1mNMJa5PgQvzG%2B2JCpvHEpVQ@mail.gmail.com">ZCqnQVPwjfry-g1mNMJa5PgQvzG+2JCpvHEpVQ@mail.gmail.com</a>><br>
Content-Type: text/plain; charset=UTF-8<br>
<br>
We are super psyched to announce the release of:<br>
<br>
pbr 1.0.1: Python Build Reasonableness<br>
<br>
With source available at:<br>
<br>
<a href="http://git.openstack.org/cgit/openstack-dev/pbr" target="_blank">http://git.openstack.org/cgit/openstack-dev/pbr</a><br>
<br>
For more details, please see the git log history below and:<br>
<br>
<a href="http://launchpad.net/pbr/+milestone/1.0.1" target="_blank">http://launchpad.net/pbr/+milestone/1.0.1</a><br>
<br>
Please report issues through launchpad:<br>
<br>
<a href="http://bugs.launchpad.net/pbr" target="_blank">http://bugs.launchpad.net/pbr</a><br>
<br>
Changes in pbr 1.0.0..1.0.1<br>
---------------------------<br>
<br>
b72e446 Remove self.pre_run calls in packaging.py<br>
8e87679 Update hacking to 0.10.x series<br>
<br>
Diffstat (except docs and test files)<br>
-------------------------------------<br>
<br>
pbr/packaging.py | 2 --<br>
test-requirements.txt | 2 +-<br>
2 files changed, 1 insertion(+), 3 deletions(-)<br>
<br>
<br>
Requirements updates<br>
--------------------<br>
<br>
diff --git a/test-requirements.txt b/test-requirements.txt<br>
index 2b33504..6e4521c 100644<br>
--- a/test-requirements.txt<br>
+++ b/test-requirements.txt<br>
@@ -4 +4 @@ fixtures>=0.3.14<br>
-hacking>=0.9.2,<0.10<br>
+hacking>=0.10.0,<0.11<br>
<br>
<br>
<br>
--<br>
Robert Collins <<a href="mailto:rbtcollins@hp.com">rbtcollins@hp.com</a>><br>
Distinguished Technologist<br>
HP Converged Cloud<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 41<br>
Date: Tue, 19 May 2015 17:09:05 -0700<br>
From: Douglas Mendiz?bal <<a href="mailto:douglas.mendizabal@rackspace.com">douglas.mendizabal@rackspace.com</a>><br>
To: "OpenStack Development Mailing List (not for usage questions)"<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: [openstack-dev] [barbican] Nominating Kaitlin Farr for<br>
barbican-core<br>
Message-ID: <<a href="mailto:555BD0A1.5090206@rackspace.com">555BD0A1.5090206@rackspace.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
-----BEGIN PGP SIGNED MESSAGE-----<br>
Hash: SHA512<br>
<br>
Hi All,<br>
<br>
I would like to nominate Kaitlin Farr for barbican-core.<br>
<br>
Kaitlin has been contributing to the project for a long time, both by<br>
contributing code to Barbican, python-barbicanclient and Castellan,<br>
and also by providing valuable reviews. [1]<br>
<br>
As a reminder to the rest of the core team, we use the process<br>
outlined in <a href="https://wiki.openstack.org/wiki/Barbican/CoreTeam" target="_blank">https://wiki.openstack.org/wiki/Barbican/CoreTeam</a> to add<br>
members to the barbican-core team.<br>
<br>
Thanks,<br>
Douglas Mendiz?bal<br>
<br>
[1] <a href="http://stackalytics.com/report/contribution/barbican-group/90" target="_blank">http://stackalytics.com/report/contribution/barbican-group/90</a><br>
-----BEGIN PGP SIGNATURE-----<br>
Comment: GPGTools - <a href="https://gpgtools.org" target="_blank">https://gpgtools.org</a><br>
<br>
iQIcBAEBCgAGBQJVW9CgAAoJEB7Z2EQgmLX7u6kP/22G3NqsnJmKRsnw065btt8z<br>
/Sb7OqFa2RKuIKk88a9yehwRuunh2YCdfLmXta1+XXpucghG9dbflfFVGU4/VujX<br>
VG/B3yUXTBYT2kn72mtwpKk4S6mYXBPn+fpKGR7iJrifYSg55XO7a2c2m/xIC8pO<br>
R9+d5/8ZztxS1UbmhNuqLwBDpo9FIG+5CoWOfYPTAQ1TxB/SIs2ltk4jzLaU05yb<br>
5LTG3uq5K3CT+LvM3Rl6SCZ7bIiTmaTuPsXMnqqLiqhya90U63VJGGXUE1yjW11G<br>
Kgm7yxUV8DkcESHXEe0aW8hpLMuGKda/f83XetGN27+YpM3/G1z8N656zLX9sF3t<br>
oVU7dWnARn9NsByFP9ASg8BCk8iWr/mCeB/fajwXT95C+OXAicNWn5jXKowXQhQH<br>
v4XaFrjafROLdJocgH0mfcoEbTXZXlsKyHYtnZdwAO+T06RNd21c/lnNiG1rMYeh<br>
2Yl48nzxxx33YprizHDRMEhABIb11HO040+j+EHNCvbsGSJGZIZmzzbxNe2QGXkx<br>
q++JvMBW60pPd6pi7nEVjbjSEZhb6f6xHs13/y+nZ9NCSNkUPx1UoxKz18JRtrLi<br>
/XDZLv6D92Trlaxae9mpVlWTM1elYPWSm3QVMxMrSP9wtAYbUIoq0PN+WwKk/1J7<br>
WaeQpFjA1SdFHj5uPNZk<br>
=1OIW<br>
-----END PGP SIGNATURE-----<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 42<br>
Date: Wed, 20 May 2015 00:20:47 +0000<br>
From: "Dillon, Nathaniel" <<a href="mailto:nathaniel.dillon@hp.com">nathaniel.dillon@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>
Subject: [openstack-dev] [security] Nominating Mike McCune as<br>
Security-Doc Core<br>
Message-ID: <<a href="mailto:9970D613-EDC0-4CC3-92DD-275E3D8FA187@hp.com">9970D613-EDC0-4CC3-92DD-275E3D8FA187@hp.com</a>><br>
Content-Type: text/plain; charset="us-ascii"<br>
<br>
To the Security and Docs groups as well as other interested parties,<br>
<br>
I would like to nominate Mike McCune to the Security Guide core. He has been contributing to the Security Guide for about six months now, and he has been a consistent participant improving content and helping new submittors. In addition, he knows the inner workings of the guide, having created and merged for the security guide the chapter on Sahara.<br>
<br>
Please chime in with your agreement, or concerns.<br>
<br>
Thanks,<br>
<br>
Nathaniel<br>
<br>
<br>
------------------------------<br>
<br>
Message: 43<br>
Date: Wed, 20 May 2015 12:05:01 +1000<br>
From: Andrew Beekhof <<a href="mailto:abeekhof@redhat.com">abeekhof@redhat.com</a>><br>
To: "OpenStack Development Mailing List (not for usage questions)"<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] [Fuel] Speed Up RabbitMQ Recovering<br>
Message-ID: <<a href="mailto:D7FDCAA7-59D2-4CA4-9361-30EF3D1390AB@redhat.com">D7FDCAA7-59D2-4CA4-9361-30EF3D1390AB@redhat.com</a>><br>
Content-Type: text/plain; charset=utf-8<br>
<br>
<br>
> On 20 May 2015, at 6:05 am, Andrew Woodward <<a href="mailto:xarses@gmail.com">xarses@gmail.com</a>> wrote:<br>
><br>
><br>
><br>
> On Thu, May 7, 2015 at 5:01 PM Andrew Beekhof <<a href="mailto:abeekhof@redhat.com">abeekhof@redhat.com</a>> wrote:<br>
><br>
> > On 5 May 2015, at 1:19 pm, Zhou Zheng Sheng / ??? <<a href="mailto:zhengsheng@awcloud.com">zhengsheng@awcloud.com</a>> wrote:<br>
> ><br>
> > Thank you Andrew.<br>
> ><br>
> > on 2015/05/05 08:03, Andrew Beekhof wrote:<br>
> >>> On 28 Apr 2015, at 11:15 pm, Bogdan Dobrelya <<a href="mailto:bdobrelia@mirantis.com">bdobrelia@mirantis.com</a>> wrote:<br>
> >>><br>
> >>>> Hello,<br>
> >>> Hello, Zhou<br>
> >>><br>
> >>>> I using Fuel 6.0.1 and find that RabbitMQ recover time is long after<br>
> >>>> power failure. I have a running HA environment, then I reset power of<br>
> >>>> all the machines at the same time. I observe that after reboot it<br>
> >>>> usually takes 10 minutes for RabittMQ cluster to appear running<br>
> >>>> master-slave mode in pacemaker. If I power off all the 3 controllers and<br>
> >>>> only start 2 of them, the downtime sometimes can be as long as 20 minutes.<br>
> >>> Yes, this is a known issue [0]. Note, there were many bugfixes, like<br>
> >>> [1],[2],[3], merged for MQ OCF script, so you may want to try to<br>
> >>> backport them as well by the following guide [4]<br>
> >>><br>
> >>> [0] <a href="https://bugs.launchpad.net/fuel/+bug/1432603" target="_blank">https://bugs.launchpad.net/fuel/+bug/1432603</a><br>
> >>> [1] <a href="https://review.openstack.org/#/c/175460/" target="_blank">https://review.openstack.org/#/c/175460/</a><br>
> >>> [2] <a href="https://review.openstack.org/#/c/175457/" target="_blank">https://review.openstack.org/#/c/175457/</a><br>
> >>> [3] <a href="https://review.openstack.org/#/c/175371/" target="_blank">https://review.openstack.org/#/c/175371/</a><br>
> >>> [4] <a href="https://review.openstack.org/#/c/170476/" target="_blank">https://review.openstack.org/#/c/170476/</a><br>
> >> Is there a reason you?re using a custom OCF script instead of the upstream[a] one?<br>
> >> Please have a chat with David (the maintainer, in CC) if there is something you believe is wrong with it.<br>
> >><br>
> >> [a] <a href="https://github.com/ClusterLabs/resource-agents/blob/master/heartbeat/rabbitmq-cluster" target="_blank">https://github.com/ClusterLabs/resource-agents/blob/master/heartbeat/rabbitmq-cluster</a><br>
> ><br>
> > I'm using the OCF script from the Fuel project, specifically from the<br>
> > "6.0" stable branch [alpha].<br>
><br>
> Ah, I?m still learning who is who... i thought you were part of that project :-)<br>
><br>
> ><br>
> > Comparing with upstream OCF code, the main difference is that Fuel<br>
> > RabbitMQ OCF is a master-slave resource. Fuel RabbitMQ OCF does more<br>
> > bookkeeping, for example, blocking client access when RabbitMQ cluster<br>
> > is not ready. I beleive the upstream OCF should be OK to use as well<br>
> > after I read the code, but it might not fit into the Fuel project. As<br>
> > far as I test, the Fuel OCF script is good except sometimes the full<br>
> > reassemble time is long, and as I find out, it is mostly because the<br>
> > Fuel MySQL Galera OCF script keeps pacemaker from promoting RabbitMQ<br>
> > resource, as I mentioned in the previous emails.<br>
> ><br>
> > Maybe Vladimir and Sergey can give us more insight on why Fuel needs a<br>
> > master-slave RabbitMQ.<br>
><br>
> That would be good to know.<br>
> Browsing the agent, promote seems to be a no-op if rabbit is already running.<br>
><br>
><br>
> To the master / slave reason due to how the ocf script is structured to deal with rabbit's poor ability to handle its self in some scenarios. Hopefully the state transition diagram [5] is enough to clarify what's going on.<br>
><br>
> [5] <a href="http://goo.gl/PPNrw7" target="_blank">http://goo.gl/PPNrw7</a><br>
<br>
Not really.<br>
It seems to be under the impression you can skip started and go directly from stopped to master.<br>
<br>
<br>
------------------------------<br>
<br>
Message: 44<br>
Date: Wed, 20 May 2015 05:10:46 +0000<br>
From: "A, Keshava" <<a href="mailto:keshava.a@hp.com">keshava.a@hp.com</a>><br>
To: "OpenStack Development Mailing List (not for usage questions)"<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>>, "<a href="mailto:pc@michali.net">pc@michali.net</a>" <<a href="mailto:pc@michali.net">pc@michali.net</a>><br>
Cc: Kalyankumar Asangi <<a href="mailto:kalyana@huawei.com">kalyana@huawei.com</a>><br>
Subject: Re: [openstack-dev] [neutron] How should edge services APIs<br>
integrate into Neutron?<br>
Message-ID:<br>
<<a href="mailto:891761EAFA335D44AD1FFDB9B4A8C063F7B0BD@G9W0762.americas.hpqcorp.net">891761EAFA335D44AD1FFDB9B4A8C063F7B0BD@G9W0762.americas.hpqcorp.net</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
Hi Vikarm<br>
<br>
<br>
<br>
1. What are the use case of ? Dynamic Routing Framework? ?<br>
<br>
<a href="https://blueprints.launchpad.net/neutron/+spec/bgp-dynamic-routing" target="_blank">https://blueprints.launchpad.net/neutron/+spec/bgp-dynamic-routing</a><br>
<br>
You are thinking of running both IGP and BGP in the same neutron ?<br>
<br>
In which kind of scenario we need this ? It is better have more information.<br>
<br>
We also need to think do we really need IGP with in the cloud, or we only need BGP for external connectivity .<br>
<br>
In that scenario, we may not go for Routing Framework, and not to complicate things too much.<br>
<br>
If some things works well with L2 with in the cloud lets not touch those area. We may need to see where there are real problem.<br>
<br>
<br>
<br>
2. What is the use case of ?Prefix Clashing? ? You are thinking of running multiple routing protocol and they will learn ?same prefix + Route? ?<br>
<br>
<a href="https://blueprints.launchpad.net/neutron/+spec/prefix-clashing-issue-with-dynamic-routing-protocol" target="_blank">https://blueprints.launchpad.net/neutron/+spec/prefix-clashing-issue-with-dynamic-routing-protocol</a><br>
<br>
In my opinion, with in the cloud we may not such deployment scenario.<br>
<br>
<br>
Let us not mix underlay network with overlay network . Both will go as different solution provider, so different business domain.<br>
<br>
This is my thoughts .<br>
<br>
keshava<br>
<br>
From: Vikram Choudhary [mailto:<a href="mailto:vikram.choudhary@huawei.com">vikram.choudhary@huawei.com</a>]<br>
Sent: Wednesday, May 06, 2015 10:45 AM<br>
To: <a href="mailto:pc@michali.net">pc@michali.net</a>; <a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a><br>
Cc: Kalyankumar Asangi<br>
Subject: Re: [openstack-dev] [neutron] How should edge services APIs integrate into Neutron?<br>
<br>
Hi Paul,<br>
<br>
Thanks for starting this mail thread. We are also eyeing for supporting MPBGP in neutron and will like to actively participate in this discussion.<br>
Please let me know about the IRC channels which we will be following for this discussion.<br>
<br>
Currently, I am following below BP?s for this work.<br>
<a href="https://blueprints.launchpad.net/neutron/+spec/edge-vpn" target="_blank">https://blueprints.launchpad.net/neutron/+spec/edge-vpn</a><br>
<a href="https://blueprints.launchpad.net/neutron/+spec/bgp-dynamic-routing" target="_blank">https://blueprints.launchpad.net/neutron/+spec/bgp-dynamic-routing</a><br>
<a href="https://blueprints.launchpad.net/neutron/+spec/dynamic-routing-framework" target="_blank">https://blueprints.launchpad.net/neutron/+spec/dynamic-routing-framework</a><br>
<a href="https://blueprints.launchpad.net/neutron/+spec/prefix-clashing-issue-with-dynamic-routing-protocol" target="_blank">https://blueprints.launchpad.net/neutron/+spec/prefix-clashing-issue-with-dynamic-routing-protocol</a><br>
<br>
Moreover, a similar kind of work is being headed by Cathy for defining an intent framework which can extended for various use case. Currently it will be leveraged for SFC but I feel the same can be used for providing intend VPN use case.<br>
<a href="https://blueprints.launchpad.net/neutron/+spec/intent-based-service-chaining" target="_blank">https://blueprints.launchpad.net/neutron/+spec/intent-based-service-chaining</a><br>
<br>
Thanks<br>
Vikram<br>
<br>
From: Paul Michali [mailto:<a href="mailto:pc@michali.net">pc@michali.net</a>]<br>
Sent: 06 May 2015 01:38<br>
To: OpenStack Development Mailing List (not for usage questions)<br>
Subject: [openstack-dev] [neutron] How should edge services APIs integrate into Neutron?<br>
<br>
There's been talk in VPN land about new services, like BGP VPN and DM VPN. I suspect there are similar things in other Advanced Services. I talked to Salvatore today, and he suggested starting a ML thread on this...<br>
<br>
Can someone elaborate on how we should integrate these API extensions into Neutron, both today, and in the future, assuming the proposal that Salvatore has is adopted?<br>
<br>
I could see two cases. The first, and simplest, is when a feature has an entirely new API that doesn't leverage off of an existing API.<br>
<br>
The other case would be when the feature's API would dovetail into the existing service API. For example, one may use the existing vpn_service API to create the service, but then create BGP VPN or DM VPN connections for that service, instead of the IPSec connections we have today.<br>
<br>
If there are examples already of how to extend an existing API extension that would help in understanding how to do this.<br>
<br>
I see that there are RESOURCE_ATTRIBUTE_MAPs with the information on the API, and I see that the plugin has a supported_extension_aliases, but beyond that, I'm not really sure how it all hooks up, and how to extend an existing extension.<br>
<br>
I'm assuming that the python-neutronclient would also need to be updated.<br>
<br>
<br>
So... the intent here is to start some discussion on how we do this, such that we have some things figured out before the summit and can save some time.<br>
<br>
Thanks in advance,<br>
<br>
Paul Michali (pc_m)<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20150520/de4ba3aa/attachment.html" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20150520/de4ba3aa/attachment.html</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>
End of OpenStack-dev Digest, Vol 37, Issue 45<br>
*********************************************<br>
</blockquote></div><br></div>