<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Jul 1, 2014 at 5:45 PM, John Meinel <span dir="ltr"><<a href="mailto:john@arbash-meinel.com" target="_blank">john@arbash-meinel.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">I would just caution that we'd really prefer behavior to be consistent across platforms and clouds, and if we can work with Microsoft to make 'apt-get update' faster in their cloud everyone wins who uses Ubuntu there, not just us.</div>
</blockquote><div><br></div><div>I was meaning to disable it across all providers. It would be ideal to improve upgrades for all Ubuntu users, but from what I can tell it's a case of Azure's OS disks being a tad slow. If you start going up the instance-type scale, then you do get more IOPS. I haven't measured how much of a difference it makes.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Have we looked into why Upgrade is taking 3m+? Is it the time to download things, is it the time to install things? I've certainly heard things like "disk ops is a bit poor" on Azure (vs CPU is actually better than average). Given the variance of 6m+ to 3m20s with Eat my data, it would seem disk sync performance is at least a factor here.</div>
</div></blockquote><div><br></div><div>I just looked, and it is mostly not network related (I assume mostly I/O bound). On ec2 an upgrade fetches all the bits in 0s; on Azure it's taking 5s.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><div>Given I believe apt-get update is also disabled for local (it is run on the initial template, and then not run for the other instances copied from that), there is certainly precedence. I think a big concern is that we would probably still want to do apt-get update for security related updates. Though perhaps that is all of the updates we are applying anyway...</div>
<div><br></div><div>If I read the "aws.json" file correctly, I see only 8 releases of the 'precise' image. 6 of 'trusty' and 32 total dates of released items. And some of the trusty releases are 2014-01-22.1 which means it is likely to be beta releases.</div>
<div><br></div><div>Anyway, that means that they are actually averaging an update only 1/month, which is a fairly big window of updates to apply by the end of month (I would imagine). And while that does mean it takes longer to boot, it also means you would be open to more security holes without it.</div>
</div></blockquote><div><br></div><div>My contention is that if we don't *keep* it updated, we may as well just leave it to the user. When you create an instance in ec2 or Azure or whatever, it doesn't come fully up-to-date. You get the released image, and then you can update it if you want to.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>John</div><div>=:-><br></div><div><br></div><div><br></div></div><div class="gmail_extra">
<br><br><div class="gmail_quote"><div><div class="h5">On Mon, Jun 30, 2014 at 5:05 PM, Andrew Wilkins <span dir="ltr"><<a href="mailto:andrew.wilkins@canonical.com" target="_blank">andrew.wilkins@canonical.com</a>></span> wrote:<br>
</div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5"><div dir="ltr">Hi folks,<div><br></div><div>I've been debugging a bootstrap bug [0] that was caused by ssh timing out (and the client not noticing), which was caused by "apt-get upgrade" taking an awfully long time (6 minutes on Azure).</div>
<div> [0] <a href="https://bugs.launchpad.net/juju-core/+bug/1316185" target="_blank">https://bugs.launchpad.net/juju-core/+bug/1316185</a></div>
<div><br></div><div>I just filed <a href="https://bugs.launchpad.net/juju-core/+bug/1335822" target="_blank">https://bugs.launchpad.net/juju-core/+bug/1335822</a>, and did a quick and dirty hack that brought the upgrade down to 3 minutes on Azure. I don't know the variance, so I can't be sure that it's all due to eatmydata, but smoser's results are similar.</div>
<div><br></div><div>Even with eatmydata, a full bootstrap on Azure just took me 10 minutes. That's roughly broken down into:</div><div> - apt-get update: 20s</div><div> - apt-get upgrade: 3m20s</div><div> - apt-get install <various>: 10s</div>
<div> - Download tools (from shared Azure storage account): 5s</div><div> - jujud bootstrap: 1m50s</div><div><br></div><div>We could bring the 10m down to 6m40s. Still not brilliant, but considerably better IMO.<br></div>
<div><br></div><div>I propose that we remove the "apt-get upgrade" altogether. Cloud images are regularly updated and tested, and I think we should be able to rely on that alone. If users want something more up-to-date, they can use the daily images which are not tested as a whole, but are composed of SRUs, which is effectively what users get today.</div>
<div><br></div><div>Cheers,</div><div>Andrew</div></div>
<br></div></div><span class="HOEnZb"><font color="#888888">--<br>
Juju-dev mailing list<br>
<a href="mailto:Juju-dev@lists.ubuntu.com" target="_blank">Juju-dev@lists.ubuntu.com</a><br>
Modify settings or unsubscribe at: <a href="https://lists.ubuntu.com/mailman/listinfo/juju-dev" target="_blank">https://lists.ubuntu.com/mailman/listinfo/juju-dev</a><br>
<br></font></span></blockquote></div><br></div>
</blockquote></div><br></div></div>