<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Feb 7, 2017 at 7:34 AM, Andrea Frittoli <span dir="ltr"><<a href="mailto:andrea.frittoli@gmail.com" target="_blank">andrea.frittoli@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_quote"><span class=""><div dir="ltr">On Tue, Feb 7, 2017 at 1:55 AM Ghanshyam Mann <<a href="mailto:ghanshyammann@gmail.com" target="_blank">ghanshyammann@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class="m_1772413463648850811gmail_msg"><div style="font-family:arial,helvetica,sans-serif;color:rgb(0,0,0)">Hi Jordan,</div><div style="font-family:arial,helvetica,sans-serif;color:rgb(0,0,0)"><br class="m_1772413463648850811gmail_msg"></div><div style="font-family:arial,helvetica,sans-serif;color:rgb(0,0,0)">Thanks for bring it up. I know we had both side of argument on those changes.</div><div style="font-family:arial,helvetica,sans-serif;color:rgb(0,0,0)"><br class="m_1772413463648850811gmail_msg"></div><div style="font-family:arial,helvetica,sans-serif;color:rgb(0,0,0)">IMO in general, its all QA team responsibility to verify the requirement very strictly and make sure no changes break existing released version and so users. Many times QA team does not agree to development team :).</div><div style="font-family:arial,helvetica,sans-serif;color:rgb(0,0,0)"><br class="m_1772413463648850811gmail_msg"></div><div style="font-family:arial,helvetica,sans-serif;color:rgb(0,0,0)">But as we are working as community and one of our key goal is to smooth development also. But as of now, strong rejection or formal approval from QA team is something missing in formal guidelines or formal written.  </div><div style="font-family:arial,helvetica,sans-serif;color:rgb(0,0,0)"><br class="m_1772413463648850811gmail_msg"></div><div style="font-family:arial,helvetica,sans-serif;color:rgb(0,0,0)">We have api-wg and its guidelines which are a great things in OpenStack and helped a lot to improve the APIs. But those are just guidelines and no hard restriction. </div><div style="font-family:arial,helvetica,sans-serif;color:rgb(0,0,0)"><br class="m_1772413463648850811gmail_msg"></div><div style="font-family:arial,helvetica,sans-serif;color:rgb(0,0,0)">Many of us can say if we are changing the APIs in backward incompatible way, then api-wg and QA agreements are great to consider and then only proceed but many of us can say if project team want then even disagreement from QA or api-wg does not matter much.</div><div style="font-family:arial,helvetica,sans-serif;color:rgb(0,0,0)"><br class="m_1772413463648850811gmail_msg"></div><div style="font-family:arial,helvetica,sans-serif;color:rgb(0,0,0)">As we do not have any official statement anywhere about mandatory agreement of QA team, i do not think we can stop any projects for such changes but we can always put our strong opinion and try to make project team understand that how harmful that changes can be.</div><div style="font-family:arial,helvetica,sans-serif;color:rgb(0,0,0)"><br class="m_1772413463648850811gmail_msg"></div><div style="font-family:arial,helvetica,sans-serif;color:rgb(0,0,0)">To make it in more smooth way in future, there is proposal in TC for new tag "supports-api-compatibility" [1] (thanks matt for that) and cdent is refactoring the api-wg guidelines accordingly [2]. </div><div style="font-family:arial,helvetica,sans-serif;color:rgb(0,0,0)"><br class="m_1772413463648850811gmail_msg"></div><div style="font-family:arial,helvetica,sans-serif;color:rgb(0,0,0)">This is really nice direction and if any projects adopt to have that new tag, then they have to honor the API compatibility and honor the api-wg, QA and TC decision. </div></div></blockquote><div><br></div></span><div>+1. </div><div>I think the discussion around the referenced API changes has been quite positive, it has lead to a review of api-wg guidelines as well as the proposal for a new tag.<br></div><div>As a QA team we have the responsibility - at least for the projects whose tests are hosted in Tempest - to identity changes that may break API compatibility and trigger such discussions in the community and help building consensus. Ideally in future the process will be much smoother as we keep improving guidelines and processes around API stability.</div></div></div></blockquote><div><br></div><div>Changes that break APIs stability are not uncommon, in keystone, for example, we already had to deal with some of them. Hopefully, we are creating a culture where tempest-like tests are being more present and with this, we can quickly spot such kind of changes.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div><div class="h5"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class="m_1772413463648850811gmail_msg"><div style="font-family:arial,helvetica,sans-serif;color:rgb(0,0,0)"><br class="m_1772413463648850811gmail_msg"></div><div style="font-family:arial,helvetica,sans-serif;color:rgb(0,0,0)">My opinion on that to have a clear responsibility of QA, api-wg to make projects considering new tag strictly honor the compatibility guidelines. So that we as QA team have formal rights to stop any incompatible changes. <span style="font-family:sans-serif"> </span></div></div></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class="m_1772413463648850811gmail_msg"><div style="font-family:arial,helvetica,sans-serif;color:rgb(0,0,0)"><br class="m_1772413463648850811gmail_msg"></div><div style="font-family:arial,helvetica,sans-serif;color:rgb(0,0,0)">I personally feel we have to have a very clear responsibility of QA team over API incompatible changes which will be helped by TC and all of us to have consensus on that and keep/make OpenStack APIs as one of the best APIs for users. </div><div style="font-family:arial,helvetica,sans-serif;color:rgb(0,0,0)"><br class="m_1772413463648850811gmail_msg"></div><div style="font-family:arial,helvetica,sans-serif;color:rgb(0,0,0)">..1 <a href="https://review.openstack.org/#/c/418010/3" class="m_1772413463648850811gmail_msg" target="_blank">https://review.openstack.<wbr>org/#/c/418010/3</a> </div><div style="font-family:arial,helvetica,sans-serif;color:rgb(0,0,0)">..2 <a href="https://review.openstack.org/#/c/421846/" class="m_1772413463648850811gmail_msg" target="_blank">https://review.openstack.<wbr>org/#/c/421846/</a> </div><div style="font-family:arial,helvetica,sans-serif;color:rgb(0,0,0)"><br class="m_1772413463648850811gmail_msg"></div><div style="font-family:arial,helvetica,sans-serif;color:rgb(0,0,0)"><br class="m_1772413463648850811gmail_msg"></div><div class="gmail_extra m_1772413463648850811gmail_msg"><div class="m_1772413463648850811gmail_msg"><div class="m_1772413463648850811m_8491923578576276530gmail_signature m_1772413463648850811gmail_msg" data-smartmail="gmail_signature"><div dir="ltr" class="m_1772413463648850811gmail_msg"><div class="m_1772413463648850811gmail_msg">-gmann</div></div></div></div></div></div><div dir="ltr" class="m_1772413463648850811gmail_msg"><div class="gmail_extra m_1772413463648850811gmail_msg">
<br class="m_1772413463648850811gmail_msg"><div class="gmail_quote m_1772413463648850811gmail_msg">On Mon, Feb 6, 2017 at 8:14 PM, Jordan Pittier <span dir="ltr" class="m_1772413463648850811gmail_msg"><<a href="mailto:jordan.pittier@scality.com" class="m_1772413463648850811gmail_msg" target="_blank">jordan.pittier@scality.com</a>></span> wrote:<br class="m_1772413463648850811gmail_msg"><blockquote class="gmail_quote m_1772413463648850811gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi gmann,<br class="m_1772413463648850811gmail_msg">
Thanks for your candidacy. Let me ask one question if it's not too<br class="m_1772413463648850811gmail_msg">
late. What's the role of the QA team when it comes to API change ? I<br class="m_1772413463648850811gmail_msg">
have in mind the recent Glance change related to private vs shared<br class="m_1772413463648850811gmail_msg">
image status.<br class="m_1772413463648850811gmail_msg">
<br class="m_1772413463648850811gmail_msg">
Someone in our community asked :<br class="m_1772413463648850811gmail_msg">
* "I need to get an official decision from the QA team on whether<br class="m_1772413463648850811gmail_msg">
[such a] patch is acceptable or not"<br class="m_1772413463648850811gmail_msg">
* "what's needed is an "official" response from the QA team concerning<br class="m_1772413463648850811gmail_msg">
the acceptability of the patch"<br class="m_1772413463648850811gmail_msg">
<br class="m_1772413463648850811gmail_msg">
But we didn't provide such an answer. There could be a feeling that<br class="m_1772413463648850811gmail_msg">
the QA team is acting as a self-appointed activist judiciary.<br class="m_1772413463648850811gmail_msg">
<br class="m_1772413463648850811gmail_msg">
Now we have another occurrence of a disagreement between the QA team<br class="m_1772413463648850811gmail_msg">
and a project team: <a href="https://bugs.launchpad.net/glance/+bug/1656183" rel="noreferrer" class="m_1772413463648850811gmail_msg" target="_blank">https://bugs.launchpad.net/<wbr>glance/+bug/1656183</a>,<br class="m_1772413463648850811gmail_msg">
<a href="https://review.openstack.org/#/c/420038/" rel="noreferrer" class="m_1772413463648850811gmail_msg" target="_blank">https://review.openstack.org/#<wbr>/c/420038/</a>,<br class="m_1772413463648850811gmail_msg">
<a href="https://review.openstack.org/#/c/425487/" rel="noreferrer" class="m_1772413463648850811gmail_msg" target="_blank">https://review.openstack.org/#<wbr>/c/425487/</a><br class="m_1772413463648850811gmail_msg">
<br class="m_1772413463648850811gmail_msg">
I have myself no strong opinion on the matter, that why I need a leader here :)<br class="m_1772413463648850811gmail_msg">
<br class="m_1772413463648850811gmail_msg">
Note, there *is* a question in this email :D<br class="m_1772413463648850811gmail_msg">
<br class="m_1772413463648850811gmail_msg">
Jordan<br class="m_1772413463648850811gmail_msg">
<br class="m_1772413463648850811gmail_msg">
On Thu, Jan 19, 2017 at 12:05 PM, Ghanshyam Mann<br class="m_1772413463648850811gmail_msg">
<<a href="mailto:ghanshyam.mann@nectechnologies.in" class="m_1772413463648850811gmail_msg" target="_blank">ghanshyam.mann@<wbr>nectechnologies.in</a>> wrote:<br class="m_1772413463648850811gmail_msg">
> Hi All,<br class="m_1772413463648850811gmail_msg">
><br class="m_1772413463648850811gmail_msg">
><br class="m_1772413463648850811gmail_msg">
><br class="m_1772413463648850811gmail_msg">
> First and foremost would like to wish you all a successful 2017 ahead and<br class="m_1772413463648850811gmail_msg">
> with this I'm announcing my PTL candidacy of the Quality Assurance team for<br class="m_1772413463648850811gmail_msg">
> the Pike release cycle.<br class="m_1772413463648850811gmail_msg">
><br class="m_1772413463648850811gmail_msg">
><br class="m_1772413463648850811gmail_msg">
><br class="m_1772413463648850811gmail_msg">
> I am glad to work in OpenStack community and would like to thank all the<br class="m_1772413463648850811gmail_msg">
> contributors who supported me to explore new things which brings out my best<br class="m_1772413463648850811gmail_msg">
> for the community.<br class="m_1772413463648850811gmail_msg">
><br class="m_1772413463648850811gmail_msg">
><br class="m_1772413463648850811gmail_msg">
><br class="m_1772413463648850811gmail_msg">
> Let me introduce myself, briefly. I have joined the OpenStack community<br class="m_1772413463648850811gmail_msg">
> development in 2014 during mid of Ice-House release. Currently, I'm<br class="m_1772413463648850811gmail_msg">
> contributing in QA projects and Nova as well as a core member in Tempest.<br class="m_1772413463648850811gmail_msg">
> Since Barcelona Summit, I volunteered  as mentor in the upstream training.<br class="m_1772413463648850811gmail_msg">
> It‘s always a great experience to introduce OpenStack upstream workflow to<br class="m_1772413463648850811gmail_msg">
> new contributors and encourage them.<br class="m_1772413463648850811gmail_msg">
><br class="m_1772413463648850811gmail_msg">
><br class="m_1772413463648850811gmail_msg">
><br class="m_1772413463648850811gmail_msg">
> Following are my contribution activities:<br class="m_1772413463648850811gmail_msg">
><br class="m_1772413463648850811gmail_msg">
> * Review:<br class="m_1772413463648850811gmail_msg">
> <a href="http://stackalytics.com/?release=all&metric=marks&user_id=ghanshyammann" rel="noreferrer" class="m_1772413463648850811gmail_msg" target="_blank">http://stackalytics.com/?<wbr>release=all&metric=marks&user_<wbr>id=ghanshyammann</a><br class="m_1772413463648850811gmail_msg">
><br class="m_1772413463648850811gmail_msg">
> * Commit:<br class="m_1772413463648850811gmail_msg">
> <a href="http://stackalytics.com/?release=all&metric=commits&user_id=ghanshyammann" rel="noreferrer" class="m_1772413463648850811gmail_msg" target="_blank">http://stackalytics.com/?<wbr>release=all&metric=commits&<wbr>user_id=ghanshyammann</a><br class="m_1772413463648850811gmail_msg">
><br class="m_1772413463648850811gmail_msg">
><br class="m_1772413463648850811gmail_msg">
><br class="m_1772413463648850811gmail_msg">
> I have worked on some key areas on QA like Interfaces migration to lib, JSON<br class="m_1772413463648850811gmail_msg">
> schema response validation(for compute), API Microversion testing framework<br class="m_1772413463648850811gmail_msg">
> in Tempest, Improve test coverage and Bug Triage etc.<br class="m_1772413463648850811gmail_msg">
><br class="m_1772413463648850811gmail_msg">
><br class="m_1772413463648850811gmail_msg">
><br class="m_1772413463648850811gmail_msg">
> QA program has been immensely improved since it was introduced which<br class="m_1772413463648850811gmail_msg">
> increased upstream development quality as well as helping production Cloud<br class="m_1772413463648850811gmail_msg">
> for their testing and stability. We have a lot of ideas from many different<br class="m_1772413463648850811gmail_msg">
> contributors to keep improving the QA which is phenomenal and I truly<br class="m_1772413463648850811gmail_msg">
> appreciate.<br class="m_1772413463648850811gmail_msg">
><br class="m_1772413463648850811gmail_msg">
><br class="m_1772413463648850811gmail_msg">
><br class="m_1772413463648850811gmail_msg">
> Moving forwards, following are my focus areas for Pike Cycle:<br class="m_1772413463648850811gmail_msg">
><br class="m_1772413463648850811gmail_msg">
><br class="m_1772413463648850811gmail_msg">
><br class="m_1772413463648850811gmail_msg">
> * Help the other Projects' developments and Plugin Improvement:<br class="m_1772413463648850811gmail_msg">
><br class="m_1772413463648850811gmail_msg">
> OpenStack projects consider the quality is important and QA team needs to<br class="m_1772413463648850811gmail_msg">
> provide useful testing framework for them. Projects who all needs to<br class="m_1772413463648850811gmail_msg">
> implement their tempest tests in plugin, focus will be to help plugin tests<br class="m_1772413463648850811gmail_msg">
> improvement and so projects quality. Lot of Tempest  interfaces are moving<br class="m_1772413463648850811gmail_msg">
> towards stable interfaces, existing plugin tests needs to be fixed multiple<br class="m_1772413463648850811gmail_msg">
> times. We are taking care of those and helping them to migrate smoothly. But<br class="m_1772413463648850811gmail_msg">
> there are still many  interfaces going to migrate to lib and further to be<br class="m_1772413463648850811gmail_msg">
> adopted on plugin side. I’d like to have some mechanism/automation to<br class="m_1772413463648850811gmail_msg">
> trigger plugins to know about change interfaces before it breaks them. Also<br class="m_1772413463648850811gmail_msg">
> help them to use the framework correctly. This helps the other non-core<br class="m_1772413463648850811gmail_msg">
> projects’ tests.<br class="m_1772413463648850811gmail_msg">
><br class="m_1772413463648850811gmail_msg">
><br class="m_1772413463648850811gmail_msg">
><br class="m_1772413463648850811gmail_msg">
> * Improve QA projects for Production Cloud:<br class="m_1772413463648850811gmail_msg">
><br class="m_1772413463648850811gmail_msg">
> This will be the main focus area. Having QA projects more useful for<br class="m_1772413463648850811gmail_msg">
> Production Cloud testing is/will be great achievement for QA team. This area<br class="m_1772413463648850811gmail_msg">
> has been improved a lot since last couple of cycles and still a lot to do.<br class="m_1772413463648850811gmail_msg">
> We have to improve Production scenario testing coverage and make all QA<br class="m_1772413463648850811gmail_msg">
> projects easy to configure and use. During Barcelona summit, 2 new projects<br class="m_1772413463648850811gmail_msg">
> are initiated which will definitely help to achieve this goal.<br class="m_1772413463648850811gmail_msg">
><br class="m_1772413463648850811gmail_msg">
>   *        RBAC Policy -  <a href="https://github.com/openstack/patrole" rel="noreferrer" class="m_1772413463648850811gmail_msg" target="_blank">https://github.com/openstack/<wbr>patrole</a><br class="m_1772413463648850811gmail_msg">
><br class="m_1772413463648850811gmail_msg">
>   *        HA testing  -  <a href="https://review.openstack.org/#/c/374667/" rel="noreferrer" class="m_1772413463648850811gmail_msg" target="_blank">https://review.openstack.org/#<wbr>/c/374667/</a><br class="m_1772413463648850811gmail_msg">
><br class="m_1772413463648850811gmail_msg">
>                           <a href="https://review.openstack.org/#/c/399618/" rel="noreferrer" class="m_1772413463648850811gmail_msg" target="_blank">https://review.openstack.org/<wbr>#/c/399618/</a><br class="m_1772413463648850811gmail_msg">
><br class="m_1772413463648850811gmail_msg">
>   *        Hoping for more in future<br class="m_1772413463648850811gmail_msg">
><br class="m_1772413463648850811gmail_msg">
> There will be more focus on those projects and new ideas which will help<br class="m_1772413463648850811gmail_msg">
> production Cloud testing in more powerful way.<br class="m_1772413463648850811gmail_msg">
><br class="m_1772413463648850811gmail_msg">
><br class="m_1772413463648850811gmail_msg">
><br class="m_1772413463648850811gmail_msg">
> * JSON Schema *response* validation for projects:<br class="m_1772413463648850811gmail_msg">
><br class="m_1772413463648850811gmail_msg">
> JSON schema response validation for compute APIs has been very helpful to<br class="m_1772413463648850811gmail_msg">
> keep the APIs quality and compatibility. Currently many projects support<br class="m_1772413463648850811gmail_msg">
> microversion which provides a way to introduce the APIs changes in Backward<br class="m_1772413463648850811gmail_msg">
> compatible way. I'd like to concentrate on response schema validation for<br class="m_1772413463648850811gmail_msg">
> those projects also. This helps the OpenStack interoperability and the APIs<br class="m_1772413463648850811gmail_msg">
> compatibility.<br class="m_1772413463648850811gmail_msg">
><br class="m_1772413463648850811gmail_msg">
><br class="m_1772413463648850811gmail_msg">
><br class="m_1772413463648850811gmail_msg">
> * Improve Documentation and UX:<br class="m_1772413463648850811gmail_msg">
><br class="m_1772413463648850811gmail_msg">
> Documentation and UX are the key part for any software. There have been huge<br class="m_1772413463648850811gmail_msg">
> improvement in UX , documentation side and new Tempest workflow is<br class="m_1772413463648850811gmail_msg">
> available.  Still configuration and usage is the pain point for Users.<br class="m_1772413463648850811gmail_msg">
> During summit/ptg or other platforms I’d like us to have more feedbacks from<br class="m_1772413463648850811gmail_msg">
> users and improve accordingly. Making configuration easy for people is one<br class="m_1772413463648850811gmail_msg">
> of the area we will be focusing on.<br class="m_1772413463648850811gmail_msg">
><br class="m_1772413463648850811gmail_msg">
><br class="m_1772413463648850811gmail_msg">
><br class="m_1772413463648850811gmail_msg">
> * Bring on more contributor and core reviewers:<br class="m_1772413463648850811gmail_msg">
><br class="m_1772413463648850811gmail_msg">
> QA projects have been one of the active projects during last couple of years<br class="m_1772413463648850811gmail_msg">
> and I'd like the team to mentor new contributors to help QA projects in<br class="m_1772413463648850811gmail_msg">
> planned goal and get them to a place where they will be ready for core<br class="m_1772413463648850811gmail_msg">
> reviewers.<br class="m_1772413463648850811gmail_msg">
><br class="m_1772413463648850811gmail_msg">
><br class="m_1772413463648850811gmail_msg">
><br class="m_1772413463648850811gmail_msg">
> * Migrate required Tempest Interfaces as stable to lib:<br class="m_1772413463648850811gmail_msg">
><br class="m_1772413463648850811gmail_msg">
> We together have done great job in this area which helped plugin tests. In<br class="m_1772413463648850811gmail_msg">
> Service clients migration, Object Storage service client are left and all<br class="m_1772413463648850811gmail_msg">
> others have been moved as stable interfaces. Lot of others<br class="m_1772413463648850811gmail_msg">
> framework/interface also available in lib. But still lot of unstable<br class="m_1772413463648850811gmail_msg">
> interfaces are being used in Plugins which should be migrated to lib soon.<br class="m_1772413463648850811gmail_msg">
> In Pike cycle, we will wind up all remaining service client migration and<br class="m_1772413463648850811gmail_msg">
> other required interfaces.<br class="m_1772413463648850811gmail_msg">
><br class="m_1772413463648850811gmail_msg">
><br class="m_1772413463648850811gmail_msg">
><br class="m_1772413463648850811gmail_msg">
> * Last but not the least, Openness is great power of Open Source and so does<br class="m_1772413463648850811gmail_msg">
> OpenStack. All new ideas from anyone will be most welcome.<br class="m_1772413463648850811gmail_msg">
><br class="m_1772413463648850811gmail_msg">
><br class="m_1772413463648850811gmail_msg">
><br class="m_1772413463648850811gmail_msg">
> Thanks to previous QA PTL, Sean, Matthew, Kenichi who have shown great<br class="m_1772413463648850811gmail_msg">
> leadership quality and taken QA projects to a new height. I have learnt a<br class="m_1772413463648850811gmail_msg">
> lot from them which motivates me.<br class="m_1772413463648850811gmail_msg">
><br class="m_1772413463648850811gmail_msg">
><br class="m_1772413463648850811gmail_msg">
><br class="m_1772413463648850811gmail_msg">
> I look forward to contributing to all of these areas and more during the<br class="m_1772413463648850811gmail_msg">
> Pike cycle.<br class="m_1772413463648850811gmail_msg">
><br class="m_1772413463648850811gmail_msg">
><br class="m_1772413463648850811gmail_msg">
><br class="m_1772413463648850811gmail_msg">
> -gmann<br class="m_1772413463648850811gmail_msg">
><br class="m_1772413463648850811gmail_msg">
><br class="m_1772413463648850811gmail_msg">
><br class="m_1772413463648850811gmail_msg">
><br class="m_1772413463648850811gmail_msg">
> ______________________________<wbr>______________________________<wbr>______________<br class="m_1772413463648850811gmail_msg">
> OpenStack Development Mailing List (not for usage questions)<br class="m_1772413463648850811gmail_msg">
> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" class="m_1772413463648850811gmail_msg" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br class="m_1772413463648850811gmail_msg">
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" class="m_1772413463648850811gmail_msg" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br class="m_1772413463648850811gmail_msg">
><br class="m_1772413463648850811gmail_msg">
<span class="m_1772413463648850811m_8491923578576276530HOEnZb m_1772413463648850811gmail_msg"><font color="#888888" class="m_1772413463648850811gmail_msg"><br class="m_1772413463648850811gmail_msg">
--<br class="m_1772413463648850811gmail_msg">
<br class="m_1772413463648850811gmail_msg">
<<a href="http://go.scality.com/acton/media/18585/gartner-magic-quadrant-object-storage?utm_campaign=MQ&utm_medium=Email&utm_source=signatures" rel="noreferrer" class="m_1772413463648850811gmail_msg" target="_blank">http://go.scality.com/acton/<wbr>media/18585/gartner-magic-<wbr>quadrant-object-storage?utm_<wbr>campaign=MQ&utm_medium=Email&<wbr>utm_source=signatures</a>><br class="m_1772413463648850811gmail_msg">
<br class="m_1772413463648850811gmail_msg">
______________________________<wbr>______________________________<wbr>______________<br class="m_1772413463648850811gmail_msg">
OpenStack Development Mailing List (not for usage questions)<br class="m_1772413463648850811gmail_msg">
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" class="m_1772413463648850811gmail_msg" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br class="m_1772413463648850811gmail_msg">
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" class="m_1772413463648850811gmail_msg" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br class="m_1772413463648850811gmail_msg">
</font></span></blockquote></div><br class="m_1772413463648850811gmail_msg"></div></div>
______________________________<wbr>______________________________<wbr>______________<br class="m_1772413463648850811gmail_msg">
OpenStack Development Mailing List (not for usage questions)<br class="m_1772413463648850811gmail_msg">
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" class="m_1772413463648850811gmail_msg" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br class="m_1772413463648850811gmail_msg">
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" class="m_1772413463648850811gmail_msg" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br class="m_1772413463648850811gmail_msg">
</blockquote></div></div></div></div>
<br>______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><font color="#666666">Rodrigo Duarte Sousa<br></font></div><div><font color="#666666">Senior Quality Engineer @ Red Hat<br></font></div><div dir="ltr"><div><div><span style="color:rgb(102,102,102)">MSc</span><span style="color:rgb(102,102,102)"></span><span style="color:rgb(102,102,102)"> in Computer Science</span><br><font color="#3333ff"><a href="http://rodrigods.com" target="_blank">http://<font color="#3333ff">rodrigods.com</font></a></font></div></div></div></div></div></div></div></div></div></div></div></div>
</div></div>