On Wed, 2013-07-31 at 14:18 -0400, Matthew Miller wrote:
> On Wed, Jul 17, 2013 at 06:08:42PM -0400, Matthew Miller wrote:
> > On Wed, Jul 17, 2013 at 02:12:03PM -0700, Adam Williamson wrote:
> > > > So, to put a number on it, does that mean _at_ the change freeze and
> > > > branch
> > > > which
On Wed, Jul 17, 2013 at 06:08:42PM -0400, Matthew Miller wrote:
> On Wed, Jul 17, 2013 at 02:12:03PM -0700, Adam Williamson wrote:
> > > So, to put a number on it, does that mean _at_ the change freeze and
> > > branch
> > > which is "no earlier than 2013-08-06"?
> > As things stand, yeah. I think
On Wed, 2013-07-17 at 18:08 -0400, Matthew Miller wrote:
> On Wed, Jul 17, 2013 at 02:12:03PM -0700, Adam Williamson wrote:
> > > So, to put a number on it, does that mean _at_ the change freeze and
> > > branch
> > > which is "no earlier than 2013-08-06"?
> > As things stand, yeah. I think for F1
On 07/16/2013 06:09 PM, Kevin Fenzi wrote:
On Tue, 16 Jul 2013 10:55:40 +0200
Florian Weimer wrote:
On 07/15/2013 12:34 PM, Daniel P. Berrange wrote:
I'm not suggesting we need to rebuild images for every update, but
at a minimum, when we issue CVE / security errata that affects an
image, I'
On Wed, Jul 17, 2013 at 02:12:03PM -0700, Adam Williamson wrote:
> > So, to put a number on it, does that mean _at_ the change freeze and branch
> > which is "no earlier than 2013-08-06"?
> As things stand, yeah. I think for F19 we actually started doing TCs
> earlier, but certainly by then.
Okay,
On Wed, 2013-07-17 at 16:43 -0400, Matthew Miller wrote:
> On Wed, Jul 17, 2013 at 01:24:52PM -0700, Adam Williamson wrote:
> > I mean the timeframe for getting the criteria changes proposed and
> > applied. We generally want to have major criteria changes in place prior
> > to Alpha TC1.
>
> So,
On Wed, Jul 17, 2013 at 01:24:52PM -0700, Adam Williamson wrote:
> I mean the timeframe for getting the criteria changes proposed and
> applied. We generally want to have major criteria changes in place prior
> to Alpha TC1.
So, to put a number on it, does that mean _at_ the change freeze and bran
On Tue, 2013-07-16 at 19:07 -0400, Matthew Miller wrote:
> On Tue, Jul 16, 2013 at 03:14:24PM -0700, Adam Williamson wrote:
> > > But yes, adding potentially-release-blocking criteria is part of the plan.
> > Who will be working on this, what is the time frame, and what will they
> > be?
>
> Me, a
On Tue, Jul 16, 2013 at 03:14:24PM -0700, Adam Williamson wrote:
> > But yes, adding potentially-release-blocking criteria is part of the plan.
> Who will be working on this, what is the time frame, and what will they
> be?
Me, as change proposal owner, working with the QA team, I hope including
y
On Mon, 2013-07-15 at 13:35 -0400, Matthew Miller wrote:
> On Mon, Jul 15, 2013 at 11:55:09AM -0500, Bruno Wolff III wrote:
> > >With Fedora 19's First Class Cloud Images feature [1], we have Amazon EC2
> > >and
> > >downloadable cloud images (in qcow2 and raw.xz format) produced and
> > >release
On Tue, 16 Jul 2013 10:55:40 +0200
Florian Weimer wrote:
> On 07/15/2013 12:34 PM, Daniel P. Berrange wrote:
>
> > I'm not suggesting we need to rebuild images for every update, but
> > at a minimum, when we issue CVE / security errata that affects an
> > image, I'd expect us to also rebuild and
On Tue, Jul 16, 2013 at 10:22:30AM -0400, Matthew Miller wrote:
> On Tue, Jul 16, 2013 at 10:58:52AM +0100, Richard W.M. Jones wrote:
> > Cloud-init is reasonably careful about where it gets the data from.
> > By default it looks first for a config drive (a specially formatted
> > block device whic
On Tue, Jul 16, 2013 at 10:58:52AM +0100, Richard W.M. Jones wrote:
> Cloud-init is reasonably careful about where it gets the data from.
> By default it looks first for a config drive (a specially formatted
> block device which has to be explicitly added to the VM), and then
> secondly for a webse
On Tue, Jul 16, 2013 at 10:47:28AM +0200, Florian Weimer wrote:
> Do these images support instance data injection by default? Then we
> need to make absolutely clear that it's unsafe to run them outside
> an environment that filters instance data injection requests. For
> example, these images mu
On Tue, Jul 16, 2013 at 10:47:28AM +0200, Florian Weimer wrote:
> On 07/15/2013 12:22 PM, Jaroslav Reznik wrote:
>
> >1. Refactoring of the Fedora web site to put the cloud image on equal footing
> >with the desktop image download. The new F19 cloud images page [2] is very
> >nice thanks to the ha
On 07/15/2013 12:34 PM, Daniel P. Berrange wrote:
I'm not suggesting we need to rebuild images for every update, but at a
minimum, when we issue CVE / security errata that affects an image, I'd
expect us to also rebuild and publish new cloud images pretty much
synchronously.
Secure Boot suppor
On 07/15/2013 12:22 PM, Jaroslav Reznik wrote:
1. Refactoring of the Fedora web site to put the cloud image on equal footing
with the desktop image download. The new F19 cloud images page [2] is very
nice thanks to the hard work of the web team, but unfortunately, in order to
find it, one has to
On Mon, Jul 15, 2013 at 12:21:11PM -0600, Kevin Fenzi wrote:
> On Mon, 15 Jul 2013 13:40:18 -0400
> Matthew Miller wrote:
>
> > On Mon, Jul 15, 2013 at 05:05:47PM +0100, Daniel P. Berrange wrote:
> > > IMHO a publicised security update policy for cloud images should be
> > > a 'must have' prior t
On Mon, Jul 15, 2013 at 12:21:11PM -0600, Kevin Fenzi wrote:
> We've never provided updated live images down the road for security
> issues. I understand cloud is a bit different, but we need to be clear
> on the scope, IMHO.
I guess it *is* worth noting that if you go to http://fedoraproject.org
On Mon, Jul 15, 2013 at 12:21:11PM -0600, Kevin Fenzi wrote:
> > That seems reasonable. I'll talk to the security team.
> And QA and releng? ;)
Sure, but see below for why I said that specifically. :)
> I'm worried about the additional work this might cause unless we are
> very narrow in what re
On Mon, 15 Jul 2013 13:40:18 -0400
Matthew Miller wrote:
> On Mon, Jul 15, 2013 at 05:05:47PM +0100, Daniel P. Berrange wrote:
> > IMHO a publicised security update policy for cloud images should be
> > a 'must have' prior to promoting the images as 1st class citizens
> > supported by Fedora.
>
On Mon, Jul 15, 2013 at 07:14:04PM +0100, Richard W.M. Jones wrote:
> On Mon, Jul 15, 2013 at 01:36:57PM -0400, Matthew Miller wrote:
> > Seekable xz/lzma compression instead of zlib/deflate.
>
> In qcow2, each [by default] 64K cluster is compressed independently.
... and I should say there's a 2
On Mon, Jul 15, 2013 at 01:36:57PM -0400, Matthew Miller wrote:
> On Mon, Jul 15, 2013 at 07:35:49PM +0200, Juerg Haefliger wrote:
> > > Or, bigger picture, maybe a future qcow2 format could support this
> > > natively?
> > Confused. Support what? Your comment above indicates that compressed
> > q
On Mon, Jul 15, 2013 at 05:05:47PM +0100, Daniel P. Berrange wrote:
> IMHO a publicised security update policy for cloud images should be a
> 'must have' prior to promoting the images as 1st class citizens supported
> by Fedora.
That seems reasonable. I'll talk to the security team.
--
Matthew M
On Mon, Jul 15, 2013 at 07:35:49PM +0200, Juerg Haefliger wrote:
> > Or, bigger picture, maybe a future qcow2 format could support this natively?
> Confused. Support what? Your comment above indicates that compressed
> qcow2 images are seekable already.
Seekable xz/lzma compression instead of zlib
On Mon, Jul 15, 2013 at 6:04 PM, Matthew Miller
wrote:
> On Mon, Jul 15, 2013 at 01:21:27PM +0100, Richard W.M. Jones wrote:
>> > Is the compressed image still seekable? If yes, that constrains the
>> > window/block size and limits the gains from switching compressors.
>> Dan's answer covered one
On Mon, Jul 15, 2013 at 11:55:09AM -0500, Bruno Wolff III wrote:
> >With Fedora 19's First Class Cloud Images feature [1], we have Amazon EC2 and
> >downloadable cloud images (in qcow2 and raw.xz format) produced and released
> >together with the traditional desktop installer and and livecd images.
On Mon, Jul 15, 2013 at 12:22:22 +0200,
Jaroslav Reznik wrote:
= Proposed System Wide Change: Visible Cloud =
https://fedoraproject.org/wiki/Changes/VisibleCloud
Change owner(s): Matthew Miller
With Fedora 19's First Class Cloud Images feature [1], we have Amazon EC2 and
downloadable cloud
On Mon, Jul 15, 2013 at 11:50:53AM -0400, Matthew Miller wrote:
> On Mon, Jul 15, 2013 at 11:34:33AM +0100, Daniel P. Berrange wrote:
> > What's our update story for cloud images ?
>
> We have the ability to do ad-hoc updates for critical flaws -- we did that
> once for F17/F18 in the last few mon
On Mon, Jul 15, 2013 at 01:21:27PM +0100, Richard W.M. Jones wrote:
> > Is the compressed image still seekable? If yes, that constrains the
> > window/block size and limits the gains from switching compressors.
> Dan's answer covered one aspect of this: are qcow2 compressed
> images seekable, answ
On Mon, Jul 15, 2013 at 01:06:26PM +0200, Lukas Zapletal wrote:
> On Mon, Jul 15, 2013 at 12:22:22PM +0200, Jaroslav Reznik wrote:
> > downloadable cloud images (in qcow2 and raw.xz format) produced and
> > released
> I know that it is convenient to expose qcow2 images uncompressed so
> users are
On Mon, Jul 15, 2013 at 11:34:33AM +0100, Daniel P. Berrange wrote:
> What's our update story for cloud images ?
We have the ability to do ad-hoc updates for critical flaws -- we did that
once for F17/F18 in the last few months. But in general, the primary
approach is yum update.
> While you coul
On Mon, Jul 15, 2013 at 01:55:18PM +0200, Florian Weimer wrote:
> On 07/15/2013 01:47 PM, Daniel P. Berrange wrote:
> >Updating to qcow2 to support xz (or some other algo) as a built-in
> >compression choice would likely give better results.
>
> Is the compressed image still seekable? If yes, tha
On Mon, Jul 15, 2013 at 01:55:18PM +0200, Florian Weimer wrote:
> On 07/15/2013 01:47 PM, Daniel P. Berrange wrote:
> >Updating to qcow2 to support xz (or some other algo) as a built-in
> >compression choice would likely give better results.
>
> Is the compressed image still seekable? If yes, tha
On 07/15/2013 01:47 PM, Daniel P. Berrange wrote:
Updating to qcow2 to support xz (or some other algo) as a built-in
compression choice would likely give better results.
Is the compressed image still seekable? If yes, that constrains the
window/block size and limits the gains from switching c
On Mon, Jul 15, 2013 at 01:06:26PM +0200, Lukas Zapletal wrote:
> On Mon, Jul 15, 2013 at 12:22:22PM +0200, Jaroslav Reznik wrote:
> > downloadable cloud images (in qcow2 and raw.xz format) produced and
> > released
>
> I know that it is convenient to expose qcow2 images uncompressed so
> users
On Mon, Jul 15, 2013 at 12:22:22PM +0200, Jaroslav Reznik wrote:
> downloadable cloud images (in qcow2 and raw.xz format) produced and released
I know that it is convenient to expose qcow2 images uncompressed so
users are able to upload them directly into clouds via httpd. Qcow2 is
compressed alr
On Mon, Jul 15, 2013 at 12:22:22PM +0200, Jaroslav Reznik wrote:
> = Proposed System Wide Change: Visible Cloud =
> https://fedoraproject.org/wiki/Changes/VisibleCloud
>
> Change owner(s): Matthew Miller
>
> With Fedora 19's First Class Cloud Images feature [1], we have Amazon EC2 and
> downloa
= Proposed System Wide Change: Visible Cloud =
https://fedoraproject.org/wiki/Changes/VisibleCloud
Change owner(s): Matthew Miller
With Fedora 19's First Class Cloud Images feature [1], we have Amazon EC2 and
downloadable cloud images (in qcow2 and raw.xz format) produced and released
together
39 matches
Mail list logo
