<div dir="ltr"><div><br></div><div>Sean, </div><br style="font-size:12.8000001907349px"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span style="font-size:12.8000001907349px">Adding most features to most projects requires a reasonable conversation<br></span><span style="font-size:12.8000001907349px">about how that impacts other parts of that project, and other projects<br></span><span style="font-size:12.8000001907349px">in OpenStack, and how it impacts existing deploys of OpenStack, and<br></span><span style="font-size:12.8000001907349px">compatibility between OpenStack implementations in the field, especially<br></span><span style="font-size:12.8000001907349px">as we try to get more serious about interoperability.</span></blockquote><div><br></div><div>Agree on this but this work should be done by team NOT end users. </div><div>End users should say: "I like it or not and why" or something is missing</div><div>they don't care how this is going to be implemented. </div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span style="font-size:12.8000001907349px">I get that everyone wants an easy button, and for magical elves to do<br></span><span style="font-size:12.8000001907349px">stuff. However I think Rally is the anomaly here, as it doesn't need to<br></span><span style="font-size:12.8000001907349px">address many of these concerns for where it lives in the tools stack.</span></blockquote><div><br></div><div>Believe me Rally is the same project as others. We have the same problems </div><div>like other OpenStack projects. </div><div><br></div><div>Some of feature request that sound quite easy (Support of benchmarking with existing</div><div>users) required a lot of work and discussion inside the Rally team, and no one from users </div><div>or even developers were able to write proper spec 1 year ago..</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span style="font-size:12.8000001907349px">And easy process for submit, that ends up with too little information or<br></span><span style="font-size:12.8000001907349px">engagement to be useful, is worse than none at all. Because then there<br></span><span style="font-size:12.8000001907349px">is just a black hole in the middle where everything is going to get lost.</span></blockquote><div><br></div><div>Users should have simple as possible way to provide simple feed back. </div><div>That should be analyzed by core team and PTL and transferred to real specs. </div><div>For example: </div><div><br></div><div>- "I need to have automated no downtime upgrades from one version to another.</div><div>   Because otherwise I can't use OpenStack in production" </div><div><br></div><div>- "Tenant deletion should remove, because it's not clear how to delete all resources by hands".</div><div><br></div><div>- "I would like to have restorable resources. Users that deleted by accident resources like VM, should be</div><div>able to restore them during some fixed amount of time like 5 minutes."</div><div><br></div><div>It's impossible hard task to create proper spec but it's super simple to provide such feature request. </div><div><br></div><div><br></div><div>Best regards,</div><div>Boris Pavlovic</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, May 15, 2015 at 2:38 PM, Sean Dague <span dir="ltr"><<a href="mailto:sean@dague.net" target="_blank">sean@dague.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On 05/15/2015 07:20 AM, Boris Pavlovic wrote:<br>
> John,<br>
><br>
><br>
>     So, you can have all details in the spec, or you can have only the<br>
>     problem statement complete. Its up to you as a submitter how much<br>
>     detail you want to provide. I would recommend adding rough ideas into<br>
>     the alternatives section, and leaving everything else blank except the<br>
>     problem statement.<br>
><br>
><br>
>      We are trying to use a single process for "parked" developer ideas and<br>
>     operator ideas, so they are on an equal footing.<br>
>     The reason its not just a "bug" or similar, is so we are able to<br>
>     review the idea with the submitter, to ensure we have a good enough<br>
>     problem description, so a developer can pick up and run with the idea,<br>
>     and turn it into a more complete spec targeted at a specific release.<br>
>     In addition, we are ensuring that the problem description is in scope.<br>
><br>
><br>
> Feature requests are the same process as specs. And I fully agree<br>
> that bug reports are not good idea for this.<br>
><br>
> The only difference is template. I believe you won't find end users<br>
> that would like to spend time to read all this steps:<br>
> <a href="http://specs.openstack.org/openstack/nova-specs/specs/kilo/template.html" target="_blank">http://specs.openstack.org/openstack/nova-specs/specs/kilo/template.html</a><br>
> and provide required info.<br>
><br>
> As an end users I would like to spend maximum 5 minutes to provide info<br>
> about:<br>
> - use case<br>
> - problem description<br>
> - possible solution [optional]<br>
><br>
><br>
> What about making nova template simpler?<br>
> And actually doing this across all projects?<br>
<br>
</div></div>So... "maximum 5 minutes" is where I think that idea goes horribly off<br>
the rails. Because it actually sets up the *wrong* expectations of how<br>
we make progress as a community, and is only going to cause anger and<br>
frustration by all parties.<br>
<br>
Adding most features to most projects requires a reasonable conversation<br>
about how that impacts other parts of that project, and other projects<br>
in OpenStack, and how it impacts existing deploys of OpenStack, and<br>
compatibility between OpenStack implementations in the field, especially<br>
as we try to get more serious about interoperability.<br>
<br>
I get that everyone wants an easy button, and for magical elves to do<br>
stuff. However I think Rally is the anomaly here, as it doesn't need to<br>
address many of these concerns for where it lives in the tools stack.<br>
<br>
And easy process for submit, that ends up with too little information or<br>
engagement to be useful, is worse than none at all. Because then there<br>
is just a black hole in the middle where everything is going to get lost.<br>
<br>
We make progress as a community by building strong communication ties<br>
across different points of views, reaching out across processes, and<br>
being willing, on all parts, to invest time to move things forward<br>
together. It's one of the reasons I think the Ops meetups have been very<br>
successful, as they provide really great forums to do that.<br>
<br>
We don't do it with a max 5 minute submit process.<br>
<span class="HOEnZb"><font color="#888888"><br>
        -Sean<br>
<br>
--<br>
Sean Dague<br>
<a href="http://dague.net" target="_blank">http://dague.net</a><br>
</font></span><div class="HOEnZb"><div class="h5"><br>
_______________________________________________<br>
OpenStack-operators mailing list<br>
<a href="mailto:OpenStack-operators@lists.openstack.org">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><br>
</div></div></blockquote></div><br></div>