On Sun, 2020-04-05 at 00:26 +0100, Laurence Parry wrote:
[...]
> My initrd (dep, xz) seems to have gone up from 4.66 MB on disk in
> 5.4.0-0.bpo.3-cloud-amd64 to 5.12 MB for bpo.4, but the kernel memory line
> suggests RAM was minimally impacted by 4KB.
[...]
The size of the initramfs has no
On Fri, 2020-04-03 at 09:28 -0700, Ross Vandegrift wrote:
> On Thu, Apr 02, 2020 at 04:52:07PM -0400, Noah Meyerhans wrote:
> > I'm not sure I'd focus too much on the security implications of KSM,
> > though, since it's widely enabled in Debian's generic kernel and kernels
> > distributed by other
> For buster, we generate a cloud kernel for amd64. For sid/bullseye,
> we'll also support a cloud kernel for arm64. At the moment, the cloud
> kernel is the only used in the images we generate for Microsoft Azure
> and Amazon EC2. It's used in the GCE images we generate as well, but
> I'm not
On 4/4/20 5:42 PM, Noah Meyerhans wrote:
>> So, when I'm being asked about it, my answer from an OpenStack operator
>> point of view, is always a big "NO !". I want to be able to service my
>> compute nodes. This means being able to live-migrate the workload away,
>> otherwise, customers may
On Sat, Apr 04, 2020 at 10:17:20AM +0200, Thomas Goirand wrote:
> > The first two bugs are about nested virtualization. I like the idea of
> > deciding to support that or not. I don't know much about nested virt,
> > so I don't have a strong opinion. It seems pretty widely supported on
> > our
On 4/4/20 1:34 AM, Noah Meyerhans wrote:
> On Wed, Apr 01, 2020 at 03:15:37PM -0400, Noah Meyerhans wrote:
>> There are open bugs against the cloud kernel requesting that
>> configuration options be turned on there. [1][2][3]
>
>
>
>> 1. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=952108
On 4/2/20 7:55 PM, Ross Vandegrift wrote:
> On Wed, Apr 01, 2020 at 03:15:37PM -0400, Noah Meyerhans wrote:
>> Should we simply say "yes" to any request to add functionality to the
>> cloud kernel? None of the drivers will add *that* much to the size of
>> the image, and if people are asking for
On Wed, Apr 01, 2020 at 03:15:37PM -0400, Noah Meyerhans wrote:
> There are open bugs against the cloud kernel requesting that
> configuration options be turned on there. [1][2][3]
> 1. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=952108
> 2.
On Thu, Apr 02, 2020 at 04:52:07PM -0400, Noah Meyerhans wrote:
> I'm not sure I'd focus too much on the security implications of KSM,
> though, since it's widely enabled in Debian's generic kernel and kernels
> distributed by other distros. I don't want to cargo-cult it, but
> neither do I want
On Thu, Apr 02, 2020 at 10:55:16AM -0700, Ross Vandegrift wrote:
> I don't think just saying "yes" automatically is the best approach. But
> I'm not sure we can come up with a clear set of rules. Evaluating the
> use cases will involve judgment calls about size vs functionality. I
> guess I
On Wed, Apr 01, 2020 at 03:15:37PM -0400, Noah Meyerhans wrote:
> Should we simply say "yes" to any request to add functionality to the
> cloud kernel? None of the drivers will add *that* much to the size of
> the image, and if people are asking for them, then they've obviously got
> a use case
Hi!
I'd be happy to work on creating documentation for the Debian cloud kernel,
especially for OpenStack.
I"ve worked with Debian as my primary OS for several years now, and have
also been exploring OpenStack.
I'm also honing my Technical Writer skills through on online course.
Writing this
For buster, we generate a cloud kernel for amd64. For sid/bullseye,
we'll also support a cloud kernel for arm64. At the moment, the cloud
kernel is the only used in the images we generate for Microsoft Azure
and Amazon EC2. It's used in the GCE images we generate as well, but
I'm not sure
13 matches
Mail list logo
