<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; color: rgb(0, 0, 0); font-size: 14px; font-family: Calibri, sans-serif; ">
<div>A few that I have been working on in the last hour/day.</div>
<div>
<div><br>
</div>
<div><a href="https://review.openstack.org/#/c/26291">https://review.openstack.org/#/c/26291</a></div>
<div><br>
</div>
<div>Instead of always running at the same periodic interval, this one dynamically expands/contracts the interval depending on previous runs. For nodes that have no instances, this means that they won't repeat the same 'null' calls at the same interval (since
whats the point in making the repeated call to get nothing again). This is done by a simple exponential backoff of the interval at which periodic actions happen. I didn't full adjust the tests, but it should be something useful, might require a teenie bit
more work. The side-effects though might be a little bit of a concern, as now bandwidth/volume usage will be at a interval which changes… If that matters for people.</div>
</div>
<div><br>
</div>
<div><a href="https://review.openstack.org/#/c/26272">https://review.openstack.org/#/c/26272</a></div>
<div><br>
</div>
<div>That allows turning off the resource tracking db traffic.</div>
<div><br>
</div>
<span id="OLK_SRC_BODY_SECTION">
<div style="font-family:Calibri; font-size:11pt; text-align:left; color:black; BORDER-BOTTOM: medium none; BORDER-LEFT: medium none; PADDING-BOTTOM: 0in; PADDING-LEFT: 0in; PADDING-RIGHT: 0in; BORDER-TOP: #b5c4df 1pt solid; BORDER-RIGHT: medium none; PADDING-TOP: 3pt">
<span style="font-weight:bold">From: </span>Matt Van Winkle <<a href="mailto:mvanwink@rackspace.com">mvanwink@rackspace.com</a>><br>
<span style="font-weight:bold">Reply-To: </span>OpenStack Development Mailing List <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
<span style="font-weight:bold">Date: </span>Friday, April 5, 2013 3:31 PM<br>
<span style="font-weight:bold">To: </span>"<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>" <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
<span style="font-weight:bold">Subject: </span>[openstack-dev] DB issues with Grizzly<br>
</div>
<div><br>
</div>
<div>
<div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; color: rgb(0, 0, 0); font-size: 14px; font-family: Calibri, sans-serif; ">
<div>Greetings folks,</div>
<span id="OLK_SRC_BODY_SECTION">
<div>
<div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; color: rgb(0, 0, 0); font-size: 14px; font-family: Calibri, sans-serif; ">
<div>I sent the message below to the user committee this morning. They recommend I go ahead and bounce it this direction to start good conversation around some of the things we are seeing in Grizzly. </div>
<div><br>
</div>
<div>TLDR – we have hit a couple of database related walls with our deployment of an early version of Grizzly code at scale. The two main areas were the migrations themselves and overall network load from DB queries once it was deployed.</div>
<div><br>
</div>
<div>The email wasn't originally intended to be super technical, but it was suggested by several to forward as-is. We can definitely rope some of the folks that did the heavy lifting on this into the conversation and dig deeper. Many of them are probably
already on this list. Please let me know what questions you have.</div>
<div><br>
</div>
<div>As it stands right now, we are actually testing some patches like the one below in our staging environments. It's too early to know the results, but we are hoping they bring the overall traffic load down for the most common queries so we can continue
to deploy code in our other (and larger) regions.</div>
<div><br>
</div>
<div>Thanks!</div>
<div>Matt</div>
<div><br>
</div>
<span id="OLK_SRC_BODY_SECTION">
<div style="font-family:Calibri; font-size:11pt; text-align:left; color:black; BORDER-BOTTOM: medium none; BORDER-LEFT: medium none; PADDING-BOTTOM: 0in; PADDING-LEFT: 0in; PADDING-RIGHT: 0in; BORDER-TOP: #b5c4df 1pt solid; BORDER-RIGHT: medium none; PADDING-TOP: 3pt">
<span style="font-weight:bold">From: </span>Matt Van Winkle <<a href="mailto:mvanwink@rackspace.com">mvanwink@rackspace.com</a>><br>
<span style="font-weight:bold">Date: </span>Friday, April 5, 2013 9:01 AM<br>
<span style="font-weight:bold">To: </span>"<a href="mailto:user-committee@lists.openstack.org">user-committee@lists.openstack.org</a>" <<a href="mailto:user-committee@lists.openstack.org">user-committee@lists.openstack.org</a>><b><br>
</b><span style="font-weight:bold">Subject: </span>Feedback on Grizzly<br>
</div>
<div><br>
</div>
<div>
<div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; color: rgb(0, 0, 0); font-size: 14px; font-family: Calibri, sans-serif; ">
<div>Hello again, folks!</div>
<div><br>
</div>
<div>When I reached out a couple weeks ago, I mentioned that I was hoping that, along with being a large developer of OpenStack, Rackspace, could also contribute the committee's work as one of it's largest users via our public cloud. We just found our first
opportunity. This week we deployed an early release of Grizzly code to one of our data centers. </div>
<div><br>
</div>
<div>Going in, we knew there were quite a few database migrations. As we studied them, however, they presented some challenges in the manner that they were executed. Using them as they were would have meant extended downtime for the databases given the size
of our production data (row counts, etc). That downtime is problematic since it translates to the Public APIs being unavailable – something we aim to impact as minimally as possible during code deploys. Ultimately, we had to rewrite them ourselves to achieve
the same out comes with less DB unavailability. There is plenty of work the community can do, and the committee can help guide, around better ways to change database structure while maintaining as much uptime as possible. If you need more details, I'm happy
to bring the folks that worked on the rewrite into the conversation. Both will actually be at the summit.</div>
<div><br>
</div>
<div>The bigger surprise - and full disclosure, we learned a lot about the things we aren't testing in our deployment pipeline - was the dramatic increase in network traffic following the deploy. The new table structures, increased meta data and new queries
in this version translated to about 10X in the amount of data being returned for some queries. Add to that, the fact that compute nodes are regularly querying for certain information or often performing a "check in", and we saw a 3X (or more) increase in
network traffic on the management network we have for this particular DC (and it's a smaller one as our various deployments go). For now we have improved things slightly by turning off the following periodic tasks:</div>
<div><br>
</div>
<div>reboot_timeout</div>
<div>rescue_timeout</div>
<div>resize_confirm_window</div>
<div><br>
</div>
<div>These not running has the potential to create some other issues (zombies and such), but that can be managed.</div>
<div><br>
</div>
<div>It does look like the developers are already working on getting some of the queries updated:</div>
<div><br>
</div>
<div><a href="https://review.openstack.org/#/c/26136">https://review.openstack.org/#/c/26136</a>/</div>
<div><a href="https://review.openstack.org/#/c/26109">https://review.openstack.org/#/c/26109</a>/</div>
<div><br>
</div>
<div>All in all, I wanted to reach back out to you to follow up from before, because I think this particular experience is an excellent highlight that there is often a disconnect between some of the changes that come through to trunk and use of the code at
scale. Almost everyone who was dealt with the above will be in Oregon week after next, so I'm happy to drag any and all into the mix to discuss further.</div>
<div><br>
</div>
<div>Thanks so much!</div>
<div>Matt</div>
</div>
</div>
</span>
<div><br>
</div>
<div>
<div>
<div>--------------- </div>
<div>Matt Van Winkle</div>
</div>
<div>Manager, Cloud Engineering</div>
<div>Rackspace</div>
<div><br>
</div>
<div>210-312-4442(w)</div>
<div><a href="mailto:mvanwink@racksapce.com">mvanwink@racksapce.com</a></div>
</div>
</div>
</div>
</span></div>
</div>
</span>
</body>
</html>