[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: non-standard TCP tunings in EC2 images


On 20 July 2016 at 03:59, Lucas Nussbaum <lucas@debian.org> 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 all environments. Currently there are some
> undocumented changes made to the EC2 images, that can:
> - result in a different application behaviour (as shown by the FTBFS
>   bugs I pointed to)
> - mislead the user about the exact dependencies of an application

I agree that it can lead to those consequences, but there are many
problems in a "one-size-fits-all" approach, as mentioned by
Charles[1]. Looks like most of those changes (like using
cloud-init/cloud-utils from backports) were needed to get things done,
resulting in an image that works.

> - 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.

In the last time I've checked[2], although "cloudfront.d.n" were
specified in the manifest, it was being overwritten to
"httpredir.d.o". Personally, I wouldn't be comfortable using "deb.d.o"
as it's still an experimental service.

> - there's a customized version of growpart installed in
>   /usr/bin/growpart-workaround

This was needed a while ago, as growpart under Jessie wasn't working
under some circunstancies (and it's quite hard to do a stable update).
This isn't needed when using a newer version of cloud-utils from
backports and we are working on it[3].

> Also, it seems that most of those changes are done in bootstrapvz's ec2
> subdirectory. Shouldn't they be done for all cloud providers?

See, it's really hard to answer questions like this. Unless we
test/benchmark those changes in all cloud providers, we can't say for
sure. For instance, Google have engineers working on persistent disk
issues and even them wouldn't recommend tweaks needed for GCE to other

On 20 July 2016 at 08:31, Sam Hartman <hartmans@debian.org> wrote:
> I agree that bootstrap-vz needs a lot more documentation and that as we
> grow we should get in the practice of documenting any divergences.

I wouldn't say that this is a bootstrap-vz documentation fault, but
related to the documentation of those images itself. GCE have a
section named "Notable differences from standard Debian images"[5],
which I find awesome. That problem is: they have people that are paid
to work full-time on this kind of things. AFAICT, the only other
provider that pays people to work on Debian images is Azure (worth
mentioning that they don't use bootstrap-vz).

In this case James, which is the maintainer of EC2 images since the
beginning, doesn't even works for Amazon anymore. I find it awesome
that he can still working on it when time permits, but as long as he
is doing this mostly alone, we can't ask him somewhat like: "stop
doing those changes that are needed to get those images working, as
you aren't documenting them."

The Debian Cloud Team (which some people argue that it isn't really a
team, just a bunch of people who work separately on similar matters)
is heavily understaffed. I lost count of how many times Charles asked
for help with cloud-init until Bastian stepped in. As long as there
aren't people joining efforts to fix things like this, there will be
countless threads, bug reports and proposals that won't see practical


[1]: https://lists.debian.org/debian-cloud/2016/07/msg00029.html
[2]: https://lists.debian.org/debian-cloud/2016/04/msg00006.html
[3]: https://github.com/andsens/bootstrap-vz/issues/329
[4]: https://github.com/andsens/bootstrap-vz/pull/220#issuecomment-103705511
[5]: https://cloud.google.com/compute/docs/images#os-details

Tiago "Myhro" Ilieve
Blog: https://blog.myhro.info/
GitHub: https://github.com/myhro
LinkedIn: https://br.linkedin.com/in/myhro
Montes Claros - MG, Brasil

Reply to: