<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 12 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
        {font-family:"Cambria Math";
        panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
        {font-family:Tahoma;
        panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0in;
        margin-bottom:.0001pt;
        font-size:12.0pt;
        font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
        {mso-style-priority:99;
        color:blue;
        text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
        {mso-style-priority:99;
        color:purple;
        text-decoration:underline;}
span.EmailStyle17
        {mso-style-type:personal-reply;
        font-family:"Calibri","sans-serif";
        color:#1F497D;}
.MsoChpDefault
        {mso-style-type:export-only;}
@page WordSection1
        {size:8.5in 11.0in;
        margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
        {page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Adding the product working group mailing list to this thread [1]<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">I’d like to introduce the Neutron Drivers (and others) to the Product Working Group.  We are a bunch of “influencers” who are focused on adding value through
 some broader outlooks in the OpenStack community.  And yes, many of us are or have been Product/Program/Project managers.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">We’ve just started (first meeting was at the Paris summit) and have been brainstorming on ways our skillsets could be applied to the OpenStack Environment. 
 A number of us have stepped up to provide some drive for cross project efforts and all of us have been reaching out to work with PTLs and developers and Ops and Users on how we can lighten their loads.  One way we are looking at is to provide some tracking
 of development efforts and plans, along with providing Use Cases to projects that will help developers figure out how to address User and Operator functionality or other gaps.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">This discussion is perfect for our mailing list, and IRC scheduled chat and a cross project session at the summit (at a minimum).  I’ll leave others in the
 Product WG to respond in line (even though I have lots of thoughts on this, too), but let’s try to get a working session or two, or even a lunch session on this topic with all interested parties at the Summit.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">And yes, I think that more, different patches in the specs area could allow for mapping use cases and other user requests to individual specs and/or blueprints
 and/or bug reports.  It’s a matter of communicating both what is needed and how and where to do it.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">--Rocky<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">[1]
<a href="http://lists.openstack.org/pipermail/openstack-dev/2015-April/061071.html">
http://lists.openstack.org/pipermail/openstack-dev/2015-April/061071.html</a> <o:p>
</o:p></span></p>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> Salvatore Orlando [mailto:sorlando@nicira.com]
<br>
<b>Sent:</b> Thursday, April 09, 2015 09:19<br>
<b>To:</b> OpenStack Development Mailing List (not for usage questions)<br>
<b>Cc:</b> OpenStack Operators<br>
<b>Subject:</b> Re: [openstack-dev] [Openstack-operators] [Neutron] The specs process, effective operators feedback and product management<o:p></o:p></span></p>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal">On 9 April 2015 at 17:04, Kyle Mestery <<a href="mailto:mestery@mestery.com" target="_blank">mestery@mestery.com</a>> wrote:<o:p></o:p></p>
<div>
<div>
<div>
<p class="MsoNormal">On Thu, Apr 9, 2015 at 9:52 AM, Assaf Muller <<a href="mailto:amuller@redhat.com" target="_blank">amuller@redhat.com</a>> wrote:<o:p></o:p></p>
<p class="MsoNormal" style="margin-bottom:12.0pt">The Neutron specs process was introduced during the Juno timecycle. At the time it<br>
was mostly a bureaucratic bottleneck (The ability to say no) to ease the pain of cores<br>
and manage workloads throughout a cycle. Perhaps this is a somewhat naive outlook,<br>
but I see other positives, such as more upfront design (Some is better than none),<br>
less high level talk during the implementation review process and more focus on the details,<br>
and 'free' documentation for every major change to the project (Some would say this<br>
is kind of a big deal; What better way to write documentation than to force the developers<br>
to do it in order for their features to get merged).<o:p></o:p></p>
<div>
<p class="MsoNormal">Right. Keep in mind that for Liberty we're making changes to this process. For instance, I've already indicated specs which were approved for Kilo but failed were moved to kilo-backlog. To get them into Liberty, you just propose a patch
 which moves the patch in the liberty directory. We already have a bunch that have taken this path. I hope we can merge the patches for these specs in Liberty-1.<o:p></o:p></p>
</div>
</div>
</div>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">It was never meant to be a bureaucratic bottleneck, although the ability of moving out early in the process blueprint that did not fit in the scope of the current release (or in the scope of the project altogether) was a goal.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">However, it became a bureaucratic step - it has been surely been perceived as that. Fast tracking blueprints which were already approved makes sense. I believe the process should be made even slimmer, removing the deadlines for spec proposal
 and approval, and making the approval process simpler - with reviewers being a lot less pedant on one side, and proposer not expecting approval of a spec to be a binding contract on the other side.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<div>
<div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<p class="MsoNormal" style="margin-bottom:12.0pt">That being said, you can only get a feature merged if you propose a spec, and the only<br>
people largely proposing specs are developers. This ingrains the open source culture of<br>
developer focused evolution, that, while empowering and great for developers, is bad<br>
for product managers, users (That are sometimes under-presented, as is the case I'm trying<br>
to make) and generally causes a lack of a cohesive vision. Like it or not, the specs process<br>
and the driver's team approval process form a sort of product management, deciding what<br>
features will ultimately go in to Neutron and in what time frame.<o:p></o:p></p>
</blockquote>
<div>
<p class="MsoNormal">We haven't done anything to limit reviews of specs by these other users, and in fact, I would love for more users to review these specs.<o:p></o:p></p>
</div>
</div>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">I think your analysis is correct. Neutron is a developer-led community, and that's why the "drivers" acting also as "product managers" approve specifications.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">I don't want to discuss here the merits of the drivers team - that probably deserves another discussion thread - but as Kyle says no-one has been discouraged for reviewing specs and influencing the decision process. The neutron-drivers
 meetings were very open in my opinion. However, if this meant - as you say - that users, operators, and product managers (yes, them too ;) ) were left off this process, I'm happy to hear proposals to improve it.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<div>
<div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<p class="MsoNormal">We shouldn't ignore the fact that we clearly have people and product managers pulling the strings<br>
in the background, often deciding where developers will spend their time and what specs to propose,<br>
for the purpose of this discussion. I argue that managers often don't have the tools to understand<br>
what is important to the project, only to their own customers. The Neutron drivers team, on the other hand,<br>
don't have a clear incentive (Or I suspect the will) to spend enormous amounts of time doing 'product management',<br>
as being a driver is essentially your third or fourth job by this point, and are the same people<br>
solving gate issues, merging code, triaging bugs and so on. I'd like to avoid to go in to a discussion of what's<br>
wrong with the current specs process as I'm sure people have heard me complain about this in<br>
#openstack-neutron plenty of times before. <o:p></o:p></p>
</blockquote>
</div>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Yes I have heard you complaining. Ideally I would borrow concepts from anarchism to define an ideal way in which various contributors should take over the different. However, I am afraid this will quickly translate in a sort of extreme
 neo-liberism which will probably lead the project with self destruction. But I'm all up for a change in the process since what we have now is drifting towards Soviet-style bureaucracy.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">Jokes apart, I think you are right, the process as it is just adds responsibilities to a subset of people who are already busy with other duties, increasing frustration in people who depends on them (being one of these people I am fully
 aware of that!)<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<div>
<div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<p class="MsoNormal" style="margin-bottom:12.0pt">Instead, I'd like to suggest a system that would perhaps<br>
get us to implement specs that are currently not being proposed, and give an additional form of<br>
input that would make sure that the development community is spending it's time in the right places.<o:p></o:p></p>
</blockquote>
<div>
<p class="MsoNormal">While these are valid points, the fact that a spec merges isn't an indication that hte code will merge. We have plenty of examples of that in the past two releases. Thus, there are issues beyond the specs process which may prevent your
 code from merging for an approved spec. That said, I admire your guile in proposing some changes. :)<o:p></o:p></p>
</div>
</div>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<div>
<div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<p class="MsoNormal" style="margin-bottom:12.0pt">While 'super users' have been given more exposure, and operators summits give operators<br>
an additional tool to provide feedback, from a developer's point of view, the input is<br>
non-empiric and scattered. I also have a hunch that operators still feel their voice is not being heard.<o:p></o:p></p>
</blockquote>
<div>
<p class="MsoNormal">Agreed.<br>
 <o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<p class="MsoNormal">I propose an upvote/downvote system (Think Reddit), where everyone (Operators especially) would upload<br>
paragraph long explanations of what they think is missing in Neutron. The proposals have to be actionable<br>
(So 'Neutron sucks', while of great humorous value, isn't something I can do anything about),<br>
and I suspect the downvote system will help self-regulate that anyway. The proposals are not specs, but are<br>
like product RFEs, so for example there would not be a 'testing' section, as these proposals will not<br>
replace the specs process anyway but augment it as an additional form of input. <o:p>
</o:p></p>
</blockquote>
</div>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">I personally do not believe in the viability of a system which gives priority to features based on "popular acclamation", mostly for the reasons kyle explains above.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">Also, "additional form of input" leaves an uncomfortable grey area where whoever is authorized to approve spec will need to strike the right balance between what they believe are the right engineering priorities and what are the priorities
 set by the community through the system you propose.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">Also, rather than having a different system, we might just sum the score associated with current neutron specs.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<div>
<div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<p class="MsoNormal">Proposals can range<br>
from new features (Role based access control for Neutron resources, dynamic routing,<br>
Neutron availability zones, QoS, ...) to quality of life improvements (Missing logs, too many<br>
DEBUG level logs, poor trouble shooting areas with an explanation of what could be improved, ...)<br>
to long standing bugs, Nova network parity issues, and whatever else may be irking the operators community.<br>
The proposals would have to be moderated (Closing duplicates, low quality submissions and implemented proposals<br>
for example) and if that is a concern then I volunteer to do so.<o:p></o:p></p>
</blockquote>
</div>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">I think that the answer to a process issue is never more process. But this is just my personal opinion!<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<div>
<div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<p class="MsoNormal"><o:p> </o:p></p>
</blockquote>
<div>
<p class="MsoNormal">Anytime you introduce a voting system you provide incentive to game the system. I am not in favor of a voting system for anything involving specs. If people think things are important, they should be reviewing specs and collaborating to
 write specs. There are examples of people who have written specs and not done the work.
<o:p></o:p></p>
</div>
</div>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Do you mean the plugin perestroika thing? I'll never write a spec I don't intend to implement myself again!!!<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<div>
<div>
<div>
<p class="MsoNormal">Perhaps what we really need is for people to write specs with no assignee initially. Then we could have people looking for things to work on (there are many, I've been approached by many in the last months) to take those specs up.<o:p></o:p></p>
</div>
</div>
</div>
</div>
</blockquote>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<div>
<div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<p class="MsoNormal">This system will also give drivers a 'way out': The last cycle we spent time refactoring this and that,<br>
and developers love doing that so it's easy to get behind. I think that as in the next cycles we move back to features,<br>
friction will rise and the process will reveal its flaws.<o:p></o:p></p>
</blockquote>
</div>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">I think the flaws are already quite clear, or do you reckon that there is something worse looming?<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<div>
<div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<p class="MsoNormal"><o:p> </o:p></p>
</blockquote>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<p class="MsoNormal">Something to consider: Maybe the top proposal takes a day to implement. Maybe some low priority bug is actually<br>
the second highest proposal. Maybe all of the currently marked 'critical' bugs don't even appear on the list.<br>
Maybe we aren't spending our time where we should be.<o:p></o:p></p>
</blockquote>
</div>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Those are all valid concerns. As a member of the drivers team I've personally asked myself these questions. Obviously this does not imply I had the right answers!<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<div>
<div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<p class="MsoNormal" style="margin-bottom:12.0pt"><br>
And now a word from our legal team: In order for this to be viable, the system would have to be a<br>
*non binding*, *additional* form of input. The top proposal *could* be declined for the same reasons<br>
that specs are currently being declined. It would not replace any of our current systems or processes.<o:p></o:p></p>
</blockquote>
<div>
<p class="MsoNormal">I like the intent here, but I'm not sure we need an additional layer of input. What about the current specs process and bugs in LP isn't working that this will address specifically? It seems to me like you're saying people don't know how
 to use these, and this is another avenue for those people to suggest input into the project. I'm pondering the implications of that now.<o:p></o:p></p>
</div>
</div>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Since it seems there a 1:1 mapping between specs and "proposals", your idea might be implemented in gerrit. Rather than submitting a proposal, submit a spec, and then have people give it a +1 or -1. Collect scores, and publish them on a
 web page.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">Even if I do not think it is the right think to have it as a part of the decision process, it is probably a useful thing to have, and requires low maintenance.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">For the specs process, I would rather consider how to delegate decision making around specs - for instance involving SMEs and cross-product team members -  and how to make this process as smooth as possible.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<div>
<div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Thanks,<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">Kyle<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<p class="MsoNormal"><br>
Assaf Muller, Cloud Networking Engineer<br>
Red Hat<br>
<br>
_______________________________________________<br>
OpenStack-operators mailing list<br>
<a href="mailto:OpenStack-operators@lists.openstack.org" target="_blank">OpenStack-operators@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators</a><o:p></o:p></p>
</blockquote>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><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><o:p></o:p></p>
</blockquote>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
</div>
</body>
</html>