Bug#698477: Do we really need mirror in AWS?

2016-07-20 Thread Charles Plessy
Le Wed, Jul 20, 2016 at 03:48:23PM +0100, Marcin Kulisz a écrit : > > do you think that there is still need for mirror on AWS once we have > CloudFront > CDN which is working quite nicely from within AWS? Hi Marcin, I think that http(s)://cloudfront.debian.net/ is exactly what we need. And I a

Re: Debian presence on AWS (maybe other clouds as well) and costs handling

2016-07-20 Thread David Duncan
Hi everyone, I work with AWS as a Linux Ecosystem Solutions Architect. Please let me know how I can assist with any goals or infrastructure requirements. > On Jul 20, 2016, at 11:15, Marcin Kulisz wrote: > > Hi all, > > I skimmed over cloud.d.o bug reports and it looks like some of them could

Re: non-standard TCP tunings in EC2 images

2016-07-20 Thread Charles Plessy
Le Wed, Jul 20, 2016 at 12:09:55PM -0300, Tiago Ilieve a écrit : > > > - backports use cloudfront.debian.net. It would be great to work with > > DSA to make cloudfront.debian.net official (part of deb.debian.org). > > In the meantime, I would be more comfortable with using deb.debian.org. > >

Re: non-standard TCP tunings in EC2 images

2016-07-20 Thread Jeremy Drake
On Wed, 20 Jul 2016, Lucas Nussbaum wrote: net.ipv4.ip_local_port_range = 10240 65535 This one bit me: because AWS network ACLs are stateless, I had to add inbound ALLOW rules for return packets from outbound traffic. I did so with the official Wheezy images by specifying ports 32768-6100

Bug#698477: Do we really need mirror in AWS?

2016-07-20 Thread Marcin Kulisz
Hi Charles, do you think that there is still need for mirror on AWS once we have CloudFront CDN which is working quite nicely from within AWS? I don't think we can gain much more speed wise and as to lowering transfer costs for our users I don't think that it'll change much in this case either as

Re: non-standard TCP tunings in EC2 images

2016-07-20 Thread Tiago Ilieve
Lucas, On 20 July 2016 at 03:59, Lucas Nussbaum wrote: > However, I think that, unless justified, we should strive to make Debian > images for cloud environments as similar as possible as what one > would get from a standard debian installation, to provide a consistent > behaviour to users over a

Re: non-standard TCP tunings in EC2 images

2016-07-20 Thread Lucas Nussbaum
On 20/07/16 at 22:29 +0800, James Bromberger wrote: > Hi Lucas (and list), > > Most of this was from this work: > > http://www.brendangregg.com/blog/2015-03-03/performance-tuning-linux-instances-on-ec2.html > > > This was to ensure that the Debian images were as optimal as possible > within the

Debian presence on AWS (maybe other clouds as well) and costs handling

2016-07-20 Thread Marcin Kulisz
Hi all, I skimmed over cloud.d.o bug reports and it looks like some of them could be solved but may create additional costs on our (Debian) AWS account. Therefore I have some questions I'm not sure who is capable to answer (that's why DPL in 'to' field as well). 1. Do we have a cap on spending we

Re: non-standard TCP tunings in EC2 images

2016-07-20 Thread Sam Hartman
> "Lucas" == Lucas Nussbaum writes: Lucas> On 20/07/16 at 19:12 +0900, Charles Plessy wrote: >> I would rather propose the reverse approach, that if a change is >> successful for cloud images, then it is a good idea to propose to >> extend it to more use cases. Lucas> Not

Re: non-standard TCP tunings in EC2 images

2016-07-20 Thread Marcin Kulisz
On 2016-07-20 12:38:47, Lucas Nussbaum wrote: > On 20/07/16 at 19:12 +0900, Charles Plessy wrote: > > I would rather propose the reverse approach, that if a change is successful > > for cloud images, then it is a good idea to propose to extend it to more > > use cases. > > Note that to judge if a

Re: non-standard TCP tunings in EC2 images

2016-07-20 Thread Lucas Nussbaum
On 20/07/16 at 19:12 +0900, Charles Plessy wrote: > I would rather propose the reverse approach, that if a change is successful > for cloud images, then it is a good idea to propose to extend it to more > use cases. Note that to judge if a change is successful, its rationale should be documented,

Re: non-standard TCP tunings in EC2 images

2016-07-20 Thread Marcin Kulisz
On 2016-07-20 11:45:27, Lucas Nussbaum wrote: > On 20/07/16 at 11:26 +0200, Thomas Lange wrote: > > > > Using tasksel we already have different flavours of Debian > > installations. Why not see the cloud images as another flavour, which > > besides having some additional packages installed also tu

Re: non-standard TCP tunings in EC2 images

2016-07-20 Thread Charles Plessy
Le Wed, Jul 20, 2016 at 11:45:27AM +0200, Lucas Nussbaum a écrit : > > I'm not against having a discussion about Debian providing different > kernel settings profiles for different environments. This is something > that could probably be useful (those settings can be configured for a > reason, aft

Re: non-standard TCP tunings in EC2 images

2016-07-20 Thread gustavo panizzo (gfa)
On Wed, Jul 20, 2016 at 11:26:55AM +0200, Thomas Lange wrote: > > On Tue, 19 Jul 2016 23:17:15 +0200, Lucas Nussbaum > > said: > > > I noticed because #830353, #830452 and #831249 are triggered by this. > > One could argue that those test suites are a bit fragile, but on the >

Re: non-standard TCP tunings in EC2 images

2016-07-20 Thread Lucas Nussbaum
On 20/07/16 at 11:26 +0200, Thomas Lange wrote: > > On Tue, 19 Jul 2016 23:17:15 +0200, Lucas Nussbaum > > said: > > > I noticed because #830353, #830452 and #831249 are triggered by this. > > One could argue that those test suites are a bit fragile, but on the > > other hand

Re: non-standard TCP tunings in EC2 images

2016-07-20 Thread Thomas Lange
> On Tue, 19 Jul 2016 23:17:15 +0200, Lucas Nussbaum > said: > I noticed because #830353, #830452 and #831249 are triggered by this. > One could argue that those test suites are a bit fragile, but on the > other hand, I would expect an image labelled as "Official Debian" on

Re: non-standard TCP tunings in EC2 images

2016-07-20 Thread Ian Campbell
On Wed, 2016-07-20 at 08:59 +0200, Lucas Nussbaum wrote: > - dkms, which also pulls linux-headers-amd64, gcc 4.8 and 4.9, make, >   patch, sudo: Apparently, this is required to build Intel's ixgbevf >   driver, which is built and shipped inside the image. This driver is already present in our kern