Re: [Xen-devel] [stage1-xen PATCH v1 04/10] build/fedora: Add `run` and `components/*` scripts

[Rajiv Ranganath <rajiv.ranganath@xxxxxxxxxxx>]

On Thu, Sep 07 2017 at 12:29:54 AM, Stefano Stabellini <sstabellini@xxxxxxxxxx> 
wrote:

[...]

>> +QEMU_BRANCH = 'master'
>
> I am not sure we want to checkout always the latest QEMU. It is a
> running target. It makes sense to use one of the latest releases
> instead, such as v2.10.0?
>

[...]

I feel once we have an understanding around what stable xen container
experience for our users should be, it makes a lot of sense to support
two stable versions (on a rolling basis) along with unstable/devel
versions of xen, qemu and rkt.

I am hoping we can include the following before adding support for
stable version.

1. Kernel - PV Calls backend support will be in 4.14, which is few
months away.

2. PVHv2 - xl and PVHv2 support is inflight for 4.10. I would like to
see xen container users start off with PVHv2 and using PV Calls
networking. Therefore I am a bit hesitant adding support for Xen 4.9.

3. Multiboot2 - One of the reasons why I documented using EFI is because
I could not get multiboot2 to work. It looks like the fix for it is on
its way. I anticipate using multiboot2 would be easier for users.

4. Rkt - Support for Kubernetes CRI and OCI image format will be of
importance to our users. Rkt is working on it but I'm not sure of their
progress. There are other projects that are also incubating in CNCF -
cri-o and cri-containerd.

PV Calls networking is new to me, and I wanted to do some prototyping to
understand how it would integrate with the rest of the container
ecosystem it after landing this series.

By adding support for xen-4.9, qemu-2.10 or rkt-1.28.1 I feel we should
not set some kind stability or backward compatibility expectations
around stage1-xen as yet.

My preference would be to keep things on master (albeit deliberately)
till we can figure out a good xen container experience for our users.

Please let me know what you think.

>> +    if p.returncode != 0:
>> +        sys.exit(1)
>
> Is this the same as
>   #!/bin/bash
>   set -e
> ?

That's right. 

> Please add a few words in the commit message about the benefit of this
> approach of writing scripts.
>

I'll update the commit message in the next version of the series.

Best,
Rajiv


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel