Hi Bastian,
I was writing a long reply to this, but I've decided not to bother,
because it boils down to this:
Can you please accept that there are a number, possibly a large, number
of clouds out there which can not, and will not, consume qcow2 images
natively.
We, and I expect all, are not
On 6/6/20 1:16 PM, Thomas Lange wrote:
>> On Sat, 6 Jun 2020 12:28:00 +0200, Bastian Blank said:
>
> > Also we don't want to specify the size a priori, because it can break to
> > easily. So we need to deduct the size during the build process.
> I could improve fai-diskimage using
On 6/6/20 12:11 PM, Bastian Blank wrote:
> On Wed, May 27, 2020 at 09:43:01AM +0200, Thomas Goirand wrote:
>> On 5/26/20 9:26 PM, Bastian Blank wrote:
>>> Please show me this existing 512MB image you are talking about. At
>>> least right now it does not exist. The build log currently even
On 6/6/20 3:13 PM, Bastian Blank wrote:
> On Sat, Jun 06, 2020 at 11:16:42PM +1200, Andrew Ruthven wrote:
>> Those are examples, and it notes that the formats available are
>> configurable and none of them are specified as "must be available". The
>> CLI docs also have a similar note.
>> "Disk and
> On Sat, 6 Jun 2020 19:35:45 +0200, Bastian Blank said:
> Now the remaining question is: GNU or BSD style checksum files?
Let's use the same as our installer images use. This is GNU style.
We should keep a common style on our Debian ISO images both for
install and cloud images.
--
On Sat, Jun 06, 2020 at 07:16:59PM +0200, Bastian Blank wrote:
> That's exactly what this change does:
> https://salsa.debian.org/cloud-team/debian-cloud-images/-/merge_requests/203
Now the remaining question is: GNU or BSD style checksum files?
GNU: "checksum filename"
- No information which
On Mon, May 18, 2020 at 11:56:15AM +0200, Thomas Lange wrote:
> I've checked some other distributions in may 2020. They all use hex.
Well, they ship a single file for consumption by "sha512sum", which we
currently don't.
> Maybe provide base64 and hex in our manifest but also sha{265,512}sum
>
> 1. Security, not from cloud providers themselves, but from other cloud
> customers via sidechannel attacks such as meltdown. The risk is small,
> but IMO greater than the risk of the cloud provider itself doing
> anything nefarious. (Keep in mind that all major cloud providers have
> taken
On Sat, Jun 06, 2020 at 08:28:30PM +0900, Charles Plessy wrote:
> > AFAIK there is general consensus amongst us that we want the cloud
> > images to be built on the Debian infrastructure, not on the cloud
> > provider infrastructure.
>
> just for the record, here is what you added:
>
> * '''E.
On Sat, Jun 06, 2020 at 11:16:42PM +1200, Andrew Ruthven wrote:
> Those are examples, and it notes that the formats available are
> configurable and none of them are specified as "must be available". The
> CLI docs also have a similar note.
> "Disk and container formats are configurable on a
> On Sat, 6 Jun 2020 12:28:00 +0200, Bastian Blank said:
> Also we don't want to specify the size a priori, because it can break to
> easily. So we need to deduct the size during the build process.
I could improve fai-diskimage using what zigo is using in his
Le Sat, Jun 06, 2020 at 11:37:17AM +0200, Emmanuel Kasper a écrit :
>
> AFAIK there is general consensus amongst us that we want the cloud
> images to be built on the Debian infrastructure, not on the cloud
> provider infrastructure.
Hi Emmanuel,
just for the record, here is what you added:
*
On Sat, 2020-06-06 at 12:06 +0200, Bastian Blank wrote:
> On Wed, May 27, 2020 at 10:13:43AM +1200, Andrew Ruthven wrote:
> > That may be the case, but not all *backends* can use qcow2 images.
>
> Can you please show OpenStack documentation detailing this all? I
> fail
> to find anything. And
On Wed, May 27, 2020 at 12:16:32PM +0100, kuLa wrote:
> Are you thinking about doing it within FAI or outside of it using new
> tool set for this?
Outside. FAI would in any case only create the directory tree, not the
filesystem is lives in or the image. So what it does would look the
same in
On Thu, Jun 04, 2020 at 01:06:29PM +0200, Thomas Lange wrote:
> > On Wed, 27 May 2020 12:01:53 +0200, Bastian Blank
> > said:
> >> Sadly it is not that easy. A whole bunch of temporary data is deleted
> >> in the final stages of the build process.
>
> > You mean those
Hi Marcin
On Sun, Apr 26, 2020 at 06:37:38PM +0100, Marcin Kulisz wrote:
> On 2020-04-22 16:35:25, Bastian Blank wrote:
> > What do you mean with "formating"? "GNU/Linux" is now irrelevant.
> But IMO a nice gesture to non Linux parts of our community and costs us
> nothing.
> > "Debian Linux",
Hi Thomas
I clearly does not help that you ignore one my questions several times.
Maybe you want to stop that.
On Wed, May 27, 2020 at 09:43:01AM +0200, Thomas Goirand wrote:
> On 5/26/20 9:26 PM, Bastian Blank wrote:
> > Please show me this existing 512MB image you are talking about. At
> >
On Wed, May 27, 2020 at 10:13:43AM +1200, Andrew Ruthven wrote:
> That may be the case, but not all *backends* can use qcow2 images.
Can you please show OpenStack documentation detailing this all? I fail
to find anything. And if the documentation does not tell clearly, I
have to assume that
On Sat, Jun 06, 2020 at 11:00:36AM +0200, Emmanuel Kasper wrote:
> Unfortunately the 250MB limit of artifacts prevent building a pipeline
> with multiple stages like
> create .box from raw -> test -> upload
> as I hit the artifact limit size between each of these stages.
Please take a deeper look
Hi
AFAIK there is general consensus amongst us that we want the cloud
images to be built on the Debian infrastructure, not on the cloud
provider infrastructure.
Since this was not explicitely listed in
https://wiki.debian.org/Teams/DPL/OfficialImages
I added it there a new point, the text coming
On 6/2/20 10:49 PM, Emmanuel Kasper wrote:
Hi
Now that I have working vagrant boxes with FAI, I'm starting to look at
nightly builds and continuous delivery of boxes to the vagrant cloud
(remember the "vagrant cloud" is just a disk image registry. The VMs are
run locally on your infrastructure)
21 matches
Mail list logo
