[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Xen-devel] [Notes for xen summit 2018 design session] Process changes: is the 6 monthly release Cadence too short, Security Process, ...
- To: Ian Jackson <ian.jackson@xxxxxxxxxx>, George Dunlap <George.Dunlap@xxxxxxxxxx>
- From: Sander Eikelenboom <linux@xxxxxxxxxxxxxx>
- Date: Thu, 5 Jul 2018 19:47:25 +0200
- Cc: Juergen Gross <jgross@xxxxxxxx>, Lars Kurth <lars.kurth@xxxxxxxxxx>, Andrew Cooper <Andrew.Cooper3@xxxxxxxxxx>, "advisory-board@xxxxxxxxxxxxxxxxxxxx" <advisory-board@xxxxxxxxxxxxxxxxxxxx>, Doug Goldstein <cardoe@xxxxxxxxxx>, Rich Persaud <persaur@xxxxxxxxx>, "committers@xxxxxxxxxxxxxx" <committers@xxxxxxxxxxxxxx>, xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Matt Spencer <Matt.Spencer@xxxxxxx>
- Delivery-date: Thu, 05 Jul 2018 17:47:43 +0000
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
On 05/07/18 19:25, Ian Jackson wrote:
> George Dunlap writes ("Re: [Xen-devel] [Notes for xen summit 2018 design
> session] Process changes: is the 6 monthly release Cadence too short,
> Security Process, ..."):
>> I don’t really understand why you’re more worried about a test
>> corrupting a backup partition or LVM snapshot, than of a test
>> corrupting a filesystem even when the test actually passed. I don’t
>> have the same experience you do, but it seems like random stuff left
>> over from a previous test — even if the test passes — would have
>> more of a chance of screwing up a future test than some sort of
>> corruption of an LVM snapshot, and even less so a backup partition.
>
> The difference is that these are tests *in the same flight*. That
> means they're testing the same software.
>
> If test A passes, but corrupts the disk which is detected by test B
> because the host wasn't wiped in between, causing test B to fail, then
> that is a genuine test failure - albeit one whose repro conditions are
> complicated. I'm betting that this will be rare enough not to matter.
>
> Ian.
>
I know assumption happens to be the mother of some children with a certain
"attitude", but
With LVM i think in practice the chances would be pretty minimal for corruption.
The most prominent test which could cause issues would be with a linux-linus
(unstable) kernel.
Else there would be a very very grave bug in either a stable linux kernel or
the hardware or the Xen used on the test flight which nukes something quite
specific.
Since you don't use the LVM LV with the base image it self but only the
snapshot and you recycle the snapshot every time.
The others points you mentioned about EFI etc. could be interesting though.
On the other hand using a setup with LVM wouldn't prohibit you from
reinstalling the base image to LV on every flight just
you seem to suggest above. It does have the benefit of being able to keep it
across flights with some seemingly simple adjustments
when in practice that would just seem to work (with always being able to revert
to doing a new base image every flight).
But i will leave itat this for now, it was merely a suggestion :).
--
Sander
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel
- References:
- [Xen-devel] [Notes for xen summit 2018 design session] Process changes: is the 6 monthly release Cadence too short, Security Process, ...
- Re: [Xen-devel] [Notes for xen summit 2018 design session] Process changes: is the 6 monthly release Cadence too short, Security Process, ...
- Re: [Xen-devel] [Notes for xen summit 2018 design session] Process changes: is the 6 monthly release Cadence too short, Security Process, ...
- Re: [Xen-devel] [Notes for xen summit 2018 design session] Process changes: is the 6 monthly release Cadence too short, Security Process, ...
- Re: [Xen-devel] [Notes for xen summit 2018 design session] Process changes: is the 6 monthly release Cadence too short, Security Process, ...
- Re: [Xen-devel] [Notes for xen summit 2018 design session] Process changes: is the 6 monthly release Cadence too short, Security Process, ...
- Re: [Xen-devel] [Notes for xen summit 2018 design session] Process changes: is the 6 monthly release Cadence too short, Security Process, ...
- Re: [Xen-devel] [Notes for xen summit 2018 design session] Process changes: is the 6 monthly release Cadence too short, Security Process, ...
- Re: [Xen-devel] [Notes for xen summit 2018 design session] Process changes: is the 6 monthly release Cadence too short, Security Process, ...
- Re: [Xen-devel] [Notes for xen summit 2018 design session] Process changes: is the 6 monthly release Cadence too short, Security Process, ...
- Re: [Xen-devel] [Notes for xen summit 2018 design session] Process changes: is the 6 monthly release Cadence too short, Security Process, ...
- Re: [Xen-devel] [Notes for xen summit 2018 design session] Process changes: is the 6 monthly release Cadence too short, Security Process, ...
- Re: [Xen-devel] [Notes for xen summit 2018 design session] Process changes: is the 6 monthly release Cadence too short, Security Process, ...
- Re: [Xen-devel] [Notes for xen summit 2018 design session] Process changes: is the 6 monthly release Cadence too short, Security Process, ...
- Re: [Xen-devel] [Notes for xen summit 2018 design session] Process changes: is the 6 monthly release Cadence too short, Security Process, ...
- Re: [Xen-devel] [Notes for xen summit 2018 design session] Process changes: is the 6 monthly release Cadence too short, Security Process, ...
|