<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Apr 3, 2013 at 5:52 PM, Andrew Glen-Young <span dir="ltr"><<a href="mailto:andrew.glen-young@canonical.com" target="_blank">andrew.glen-young@canonical.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello All,<br>
<br>
Apologies, I'm a little late to reply to this thread.<br>
<div class="im"><br>
On Sat 16-03-2013 22:38 ›, Lorin Hochstein wrote:<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<br>
> devs are making about how ops...er...operate? How can the OpenStack project<br>
> take the experiences of operators and feed that back to the developers so<br>
> they know what people are really doing in practice?<br>
<br>
</div>I have added a note about the new behaviour of the image-cache-manager<br>
to the 'Upgrade Notes' section of Grizzly's release notes.<br>
<br>
This is one way developers can communicate these changes to operators.<br>
<div class="im"><br></div></blockquote><div><br></div><div style>Thanks, Andrew. I changed the wording a little bit in the release notes, since the functionality was actually enabled by default in Folsom, not Grizzly. Grizzly has the fix, it just hasn't been extensively tested in production.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
><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>
<br>
</div>IMHO these circumstances are bugs that should be filed. In my experience<br>
the developers are very responsive to address these issues.<br>
<br>
This is one way operators can communicate their needs to developers.<br>
<br></blockquote><div><br></div><div style>Yes, I've submitted "ops" bugs in the past, and gotten good responses, I'm not sure how to encourage people to do this more. Perhaps in one of the ops sessions at the summit, we can encourage folks to submit ops bugs somehow? Maybe I'll try to sneak in a lightning talk or something...</div>
</div><div><br></div>-- <br><div dir="ltr">Lorin Hochstein<br><div>Lead Architect - Cloud Services</div><div>Nimbis Services, Inc.</div><div><a href="http://www.nimbisservices.com" target="_blank">www.nimbisservices.com</a></div>
</div>
</div></div>