[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [ANNOUNCE] Call for agenda items for September 5th Community Call @ 15:00 UTC



On Sep 5, 2019, at 04:36, Lars Kurth <lars.kurth@xxxxxxxxxx> wrote:

On 05/09/2019, 09:33, "Juergen Gross" <jgross@xxxxxxxx> wrote:

   On 05.09.19 10:14, Andrew Cooper wrote:
On 05/09/2019 08:49, Lars Kurth wrote:
On 05/09/2019, 08:41, "Rich Persaud" <persaur@xxxxxxxxx> wrote:

On Sep 5, 2019, at 03:19, Jan Beulich <jbeulich@xxxxxxxx> wrote:

Forgive me asking, but why is this put up as an agenda item here?
IMO this is the kind of thing where you would send a proposal and
request feedback by email first, and put it up as an agenda item
here only if it got stalled there. (Apologies if I've overlooked
such a stalled thread.)

    If Xen community call topics are limited to escalations of xen-devel threads, then a new thread can be created for this topic. Xen community calls have also provided real-time, interactive feedback on candidate proposals, along with guidance on areas which need documentation before a formal proposal is made to xen-devel.   Such agenda items are typically covered after all series and priority topics have been addressed.

I don't mind having items such these on the agenda and to be fair have added similar items onto the agenda in the past.
Clearly, they are forward looking [like an RFC], for which reason I tend to add them to the end of an agenda if there is a busy schedule

Personally, on this specific item, it is not really clear what the questions are.  In other words: is this about UUIDS/domain ids only, or is there something else.

Requiring something to be blocked on xen-devel before we discuss it on
the call is monumentally short sighted, and off-putting for contributors.

In this case, it is very definitely not the first time this problem has
been raised, as it is an XSA shaped elephant in the room.  Its no secret
that id wraps cause problems, and while our security policy doesn't
comment on the matter, it also doesn't say "warning - stuff *will* break
in weird, wonderful, and security-relevant ways when domid's wrap".

The order of the agenda is important, and I don't think this should be
at the top, but even if we only end up with 2 minutes to discuss it,
then so be it.  (2 minutes of talking can still be far more valuable
than a weeks worth of emailing.)

What is not acceptable is suggesting that it should be veto'd simply
because it is perceived to be a very fresh idea/query.

   I still think it would help if a short high level design would be posted
   on xen-devel first.

I think that is a valid point and I agree. In the past when we had similar
discussions often the outcome was not that clear and due to the nature of
the calls the discussions were also not well reflected in the notes.

So, there is an argument, that discussions typically are more productive when
there is the possibility for some preparation or an e-mail thread to refer to.

We can defer the xenstoreless name service topic to the October monthly call.

For today's call, can we discuss the previously posted high-level design for unification of the domB RFC with dom0less, as "domB mode" for disaggregation of Xen's dom0?

- domB mode for dom0less (July 2019):  https://lists.gt.net/xen/devel/557782
- domB RFC (June 2018):  https://lists.gt.net/xen/devel/519367

Rich
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.