<div dir="ltr"><div>Davanum:<br></div><div><br></div><div style>I don't think the problem is necessarily the existing mechanism for reporting bugs or feature requests (I do think that ops aren't reporting usability issues as bugs, even though they should, but put that aside for a moment).</div>
<div style><br></div><div style>My worry is about the disconnect between how developers believe operators use OpenStack, and how operators actually use OpenStack, and the problems caused by that disconnect. What initially prompted this was the assumption that devs could introduce a new feature that was disabled by default, and then after a couple of releases they could enable it by default, the assumption being that operators would have tested this experimental feature in the initial releases. But operators don't test against features like that, so this was an incorrect assumption: introducing a new feature that is disabled by default doesn't necessarily lead to operators testing it. </div>
<div style><br></div><div style>Another example is how operators write scripts that do things like poke directly at the database in order to work around missing features in the tools. Here is a case that they should be reporting usability issues. But they don't. And so these scripts use the equivalent of an undocumented, internal interface that could break in a future release. I worry that the ops are not communicating back to the devs when they have to poke at internals to workaround problems. And, honestly, I don't have a good suggestion here (unless we could "embed" some OpenStack devs into environments with production deployments and have them watch what happens, which would be great, but probably not a viable solution).</div>
<div style><br></div><div style>Lorin</div><div><br></div>On Sat, 16 Mar 2013 at 10:45PM,  Davanum Srinivas <<a href="mailto:davanum@gmail.com">davanum@gmail.com</a>> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<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">Lorin,<br>
<br>
Dumb question - are the existing mechanisms to raise feature requests<br>
lacking? (Can devs assume that ops folks will open a new bug in<br>
launchpad?)<br>
<br>
-- dims<br>
<br>
On Sat, Mar 16, 2013 at 10:38 PM, Lorin Hochstein<br>
<<a href="mailto:lorin@nimbisservices.com">lorin@nimbisservices.com</a>> wrote:<br>
><br>
> On Thu, Mar 14, 2013 at 9:13 PM, Michael Still <<a href="mailto:mikal@stillhq.com">mikal@stillhq.com</a>> wrote:<br>
>><br>
>> On Thu, Mar 14, 2013 at 8:50 PM, Blair Bethwaite<br>
>> <<a href="mailto:blair.bethwaite@gmail.com">blair.bethwaite@gmail.com</a>> wrote:<br>
>><br>
>> I think my overall learning from this thread is that there's no point<br>
>> disabling features for a few releases so that operators can test in a<br>
>> staged manner -- the reality is that testing doesn't occur.<br>
><br>
><br>
><br>
> Here's a broader question: what are the other implicit assumptions that devs<br>
> are making about how ops...er...operate? How can the OpenStack project take<br>
> the experiences of operators and feed that back to the developers so they<br>
> know what people are really doing in practice?<br>
><br>
> For example: do the devs know the circumstances for which operators have to<br>
> poke directly at the database to perform tasks because they can't do what<br>
> they want with the existing tools?<br>
><br>
>  Lorin<br><br></blockquote></div><div dir="ltr"></div>
</div></div>