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

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

[Lars Kurth]

Hi all,

the proposed agenda is in https://cryptpad.fr/pad/#/2/pad/edit/xwUTm6b5f5ijPTQcF9IFgkBg/ and you can edit to add items
Alternatively, you can reply to this mail directly
Agenda items appreciated ASAP: please put your name besides items if you edit the document

Apologies for dropping the ball on this one, I forgot to add the CC list to the earlier mail I sent

Regards
Lars
P.S.: If you want to be added or removed from the CC list please reply privately

== Dial-in Information ==

## Meeting time
15:00 - 16:00 UTC
Further International meeting times: https://www.timeanddate.com/worldclock/meetingdetails.html?year=2019&month=9&day=5&hour=15&min=0&sec=0&p1=225&p2=224&p3=24&p4=179&p5=136&p6=37&p7=33

## Dial in details
Web: https://www.gotomeet.me/larskurth

You can also dial in using your phone.
Access Code: 906-886-965

China (Toll Free): 4008 811084
Germany: +49 692 5736 7317
Poland (Toll Free): 00 800 1124759
United Kingdom: +44 330 221 0088
United States: +1 (571) 317-3129

More phone numbers
Australia: +61 2 9087 3604
Austria: +43 7 2081 5427
Argentina (Toll Free): 0 800 444 3375
Bahrain (Toll Free): 800 81 111
Belarus (Toll Free): 8 820 0011 0400
Belgium: +32 28 93 7018
Brazil (Toll Free): 0 800 047 4906
Bulgaria (Toll Free): 00800 120 4417
Canada: +1 (647) 497-9391
Chile (Toll Free): 800 395 150
Colombia (Toll Free): 01 800 518 4483
  Czech Republic (Toll Free): 800 500448
Denmark: +45 32 72 03 82
Finland: +358 923 17 0568
France: +33 170 950 594
Greece (Toll Free): 00 800 4414 3838
Hong Kong (Toll Free): 30713169
Hungary (Toll Free): (06) 80 986 255
Iceland (Toll Free): 800 7204
India (Toll Free): 18002669272
Indonesia (Toll Free): 007 803 020 5375
Ireland: +353 15 360 728
Israel (Toll Free): 1 809 454 830
Italy: +39 0 247 92 13 01
Japan (Toll Free): 0 120 663 800
Korea, Republic of (Toll Free): 00798 14 207 4914
Luxembourg (Toll Free): 800 85158
Malaysia (Toll Free): 1 800 81 6854
Mexico (Toll Free): 01 800 522 1133
Netherlands: +31 207 941 377
New Zealand: +64 9 280 6302
Norway: +47 21 93 37 51
Panama (Toll Free): 00 800 226 7928
Peru (Toll Free): 0 800 77023
Philippines (Toll Free): 1 800 1110 1661
Portugal (Toll Free): 800 819 575
Romania (Toll Free): 0 800 410 029
Russian Federation (Toll Free): 8 800 100 6203
Saudi Arabia (Toll Free): 800 844 3633
Singapore (Toll Free): 18007231323
South Africa (Toll Free): 0 800 555 447
Spain: +34 932 75 2004
Sweden: +46 853 527 827
Switzerland: +41 225 4599 78
Taiwan (Toll Free): 0 800 666 854
Thailand (Toll Free): 001 800 011 023
Turkey (Toll Free): 00 800 4488 23683
Ukraine (Toll Free): 0 800 50 1733
United Arab Emirates (Toll Free): 800 044 40439
Uruguay (Toll Free): 0004 019 1018
Viet Nam (Toll Free): 122 80 481

First GoToMeeting? Let's do a quick system check:
https://link.gotomeeting.com/system-check


    

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

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

[Rich Persaud]

[-- Attachment #1.1: Type: text/plain, Size: 5058 bytes --]

Agenda item:  Domain name service for nested virt and disaggregation 

(text based on draft by Daniel Smith, who will speak to this agenda item)

If a future, minimal "L0 Xen" hypervisor can be optimized for nested virtualization in greenfield deployments (i.e. no requirement to maintain existing hypervisor-guest interfaces), then PV driver mechanisms other than grants, events and xenstore could be considered.  This was discussed in a Xen Summit 2019 design session:
https://lists.gt.net/xen/devel/560973

For some OpenXT use cases, we are in the process of further disaggregating the platform.  We need a name service to enable the disaggregated service domains to discover the other service domains with which they need to communicate.  Xenstore is not sufficient, as we would like to use Flask to control the data flow, as well as applying mandatory access control to service calls. 

We are reaching out to the Xen Community to elicit input on approaches, such that we might be able to submit an upstream RFC based on our early work:

- For a communication channel we are looking to leverage Argo, which is currently in experimental status. Its predecessor (v4v) is already being used in a similar fashion by Bromium uXen (https://github.com/openxt/uxen), which functions well across nested hypervisors.  uXen v4v includes a mechanism to control information flow.

- An open question is how to address the domains. Xen domain ids are reused and have no guarantee for uniqueness.  UUIDs are available and can provide better guarantees for uniqueness. Another approach is to use the name string which allows the ability for punctuation characters, eg. : or /, to create namespaced names for the domains.



> On Sep 4, 2019, at 10:05, Lars Kurth <lars.kurth@citrix.com> wrote:
> 
> Hi all,
> 
> the proposed agenda is in https://cryptpad.fr/pad/#/2/pad/edit/xwUTm6b5f5ijPTQcF9IFgkBg/ and you can edit to add items
> Alternatively, you can reply to this mail directly
> Agenda items appreciated ASAP: please put your name besides items if you edit the document
> 
> Apologies for dropping the ball on this one, I forgot to add the CC list to the earlier mail I sent
> 
> Regards
> Lars
> P.S.: If you want to be added or removed from the CC list please reply privately
> 
> == Dial-in Information ==
> 
> ## Meeting time
> 15:00 - 16:00 UTC
> Further International meeting times: https://www.timeanddate.com/worldclock/meetingdetails.html?year=2019&month=9&day=5&hour=15&min=0&sec=0&p1=225&p2=224&p3=24&p4=179&p5=136&p6=37&p7=33
> 
> ## Dial in details
> Web: https://www.gotomeet.me/larskurth
> 
> You can also dial in using your phone.
> Access Code: 906-886-965
> 
> China (Toll Free): 4008 811084
> Germany: +49 692 5736 7317
> Poland (Toll Free): 00 800 1124759
> United Kingdom: +44 330 221 0088
> United States: +1 (571) 317-3129
> 
> More phone numbers
> Australia: +61 2 9087 3604
> Austria: +43 7 2081 5427
> Argentina (Toll Free): 0 800 444 3375
> Bahrain (Toll Free): 800 81 111
> Belarus (Toll Free): 8 820 0011 0400
> Belgium: +32 28 93 7018
> Brazil (Toll Free): 0 800 047 4906
> Bulgaria (Toll Free): 00800 120 4417
> Canada: +1 (647) 497-9391
> Chile (Toll Free): 800 395 150
> Colombia (Toll Free): 01 800 518 4483
>  Czech Republic (Toll Free): 800 500448
> Denmark: +45 32 72 03 82
> Finland: +358 923 17 0568
> France: +33 170 950 594
> Greece (Toll Free): 00 800 4414 3838
> Hong Kong (Toll Free): 30713169
> Hungary (Toll Free): (06) 80 986 255
> Iceland (Toll Free): 800 7204
> India (Toll Free): 18002669272
> Indonesia (Toll Free): 007 803 020 5375
> Ireland: +353 15 360 728
> Israel (Toll Free): 1 809 454 830
> Italy: +39 0 247 92 13 01
> Japan (Toll Free): 0 120 663 800
> Korea, Republic of (Toll Free): 00798 14 207 4914
> Luxembourg (Toll Free): 800 85158
> Malaysia (Toll Free): 1 800 81 6854
> Mexico (Toll Free): 01 800 522 1133
> Netherlands: +31 207 941 377
> New Zealand: +64 9 280 6302
> Norway: +47 21 93 37 51
> Panama (Toll Free): 00 800 226 7928
> Peru (Toll Free): 0 800 77023
> Philippines (Toll Free): 1 800 1110 1661
> Portugal (Toll Free): 800 819 575
> Romania (Toll Free): 0 800 410 029
> Russian Federation (Toll Free): 8 800 100 6203
> Saudi Arabia (Toll Free): 800 844 3633
> Singapore (Toll Free): 18007231323
> South Africa (Toll Free): 0 800 555 447
> Spain: +34 932 75 2004
> Sweden: +46 853 527 827
> Switzerland: +41 225 4599 78
> Taiwan (Toll Free): 0 800 666 854
> Thailand (Toll Free): 001 800 011 023
> Turkey (Toll Free): 00 800 4488 23683
> Ukraine (Toll Free): 0 800 50 1733
> United Arab Emirates (Toll Free): 800 044 40439
> Uruguay (Toll Free): 0004 019 1018
> Viet Nam (Toll Free): 122 80 481
> 
> First GoToMeeting? Let's do a quick system check:
> https://link.gotomeeting.com/system-check
> 
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xenproject.org
> https://lists.xenproject.org/mailman/listinfo/xen-devel

[-- Attachment #1.2: Type: text/html, Size: 7716 bytes --]

[-- Attachment #2: Type: text/plain, Size: 157 bytes --]

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

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

[Jan Beulich]

On 05.09.2019 04:32, Rich Persaud wrote:
> Agenda item:  Domain name service for nested virt and disaggregation 
> 
> (text based on draft by Daniel Smith, who will speak to this agenda item)
> 
> If a future, minimal "L0 Xen" hypervisor can be optimized for nested virtualization in greenfield deployments (i.e. no requirement to maintain existing hypervisor-guest interfaces), then PV driver mechanisms other than grants, events and xenstore could be considered.  This was discussed in a Xen Summit 2019 design session:
> https://lists.gt.net/xen/devel/560973
> 
> For some OpenXT use cases, we are in the process of further disaggregating the platform.  We need a name service to enable the disaggregated service domains to discover the other service domains with which they need to communicate.  Xenstore is not sufficient, as we would like to use Flask to control the data flow, as well as applying mandatory access control to service calls. 
> 
> We are reaching out to the Xen Community to elicit input on approaches, such that we might be able to submit an upstream RFC based on our early work:
> 
> - For a communication channel we are looking to leverage Argo, which is currently in experimental status. Its predecessor (v4v) is already being used in a similar fashion by Bromium uXen (https://github.com/openxt/uxen), which functions well across nested hypervisors.  uXen v4v includes a mechanism to control information flow.
> 
> - An open question is how to address the domains. Xen domain ids are reused and have no guarantee for uniqueness.  UUIDs are available and can provide better guarantees for uniqueness. Another approach is to use the name string which allows the ability for punctuation characters, eg. : or /, to create namespaced names for the domains.

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.)

Jan

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

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

[Rich Persaud]

> On Sep 5, 2019, at 03:19, Jan Beulich <jbeulich@suse.com> wrote:
> 
>> On 05.09.2019 04:32, Rich Persaud wrote:
>> Agenda item:  Domain name service for nested virt and disaggregation 
>> 
>> (text based on draft by Daniel Smith, who will speak to this agenda item)
>> 
>> If a future, minimal "L0 Xen" hypervisor can be optimized for nested virtualization in greenfield deployments (i.e. no requirement to maintain existing hypervisor-guest interfaces), then PV driver mechanisms other than grants, events and xenstore could be considered.  This was discussed in a Xen Summit 2019 design session:
>> https://lists.gt.net/xen/devel/560973
>> 
>> For some OpenXT use cases, we are in the process of further disaggregating the platform.  We need a name service to enable the disaggregated service domains to discover the other service domains with which they need to communicate.  Xenstore is not sufficient, as we would like to use Flask to control the data flow, as well as applying mandatory access control to service calls. 
>> 
>> We are reaching out to the Xen Community to elicit input on approaches, such that we might be able to submit an upstream RFC based on our early work:
>> 
>> - For a communication channel we are looking to leverage Argo, which is currently in experimental status. Its predecessor (v4v) is already being used in a similar fashion by Bromium uXen (https://github.com/openxt/uxen), which functions well across nested hypervisors.  uXen v4v includes a mechanism to control information flow.
>> 
>> - An open question is how to address the domains. Xen domain ids are reused and have no guarantee for uniqueness.  UUIDs are available and can provide better guarantees for uniqueness. Another approach is to use the name string which allows the ability for punctuation characters, eg. : or /, to create namespaced names for the domains.
> 
> 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.

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

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

[Lars Kurth]

On 05/09/2019, 08:41, "Rich Persaud" <persaur@gmail.com> wrote:

    > On Sep 5, 2019, at 03:19, Jan Beulich <jbeulich@suse.com> 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. 

Lars

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

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

[Jan Beulich]

On 05.09.2019 09:41, Rich Persaud wrote:
> 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'll certainly listen to what others think, but I have to confess that
on such prior instances I was already on the edge of requesting that
time not be spent in such a way. Please recall that calls, other than
mails, take everybody's time, and exactly at the same time. Therefore
my personal opinion is that topics on calls should be limited to items
which cannot be resolved by other means, or which are certain to need
(almost) everybody's attention right away.

Jan

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

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

[Juergen Gross]

On 05.09.19 09:41, Rich Persaud wrote:
>> On Sep 5, 2019, at 03:19, Jan Beulich <jbeulich@suse.com> wrote:
>>
>>> On 05.09.2019 04:32, Rich Persaud wrote:
>>> Agenda item:  Domain name service for nested virt and disaggregation
>>>
>>> (text based on draft by Daniel Smith, who will speak to this agenda item)
>>>
>>> If a future, minimal "L0 Xen" hypervisor can be optimized for nested virtualization in greenfield deployments (i.e. no requirement to maintain existing hypervisor-guest interfaces), then PV driver mechanisms other than grants, events and xenstore could be considered.  This was discussed in a Xen Summit 2019 design session:
>>> https://lists.gt.net/xen/devel/560973
>>>
>>> For some OpenXT use cases, we are in the process of further disaggregating the platform.  We need a name service to enable the disaggregated service domains to discover the other service domains with which they need to communicate.  Xenstore is not sufficient, as we would like to use Flask to control the data flow, as well as applying mandatory access control to service calls.
>>>
>>> We are reaching out to the Xen Community to elicit input on approaches, such that we might be able to submit an upstream RFC based on our early work:
>>>
>>> - For a communication channel we are looking to leverage Argo, which is currently in experimental status. Its predecessor (v4v) is already being used in a similar fashion by Bromium uXen (https://github.com/openxt/uxen), which functions well across nested hypervisors.  uXen v4v includes a mechanism to control information flow.
>>>
>>> - An open question is how to address the domains. Xen domain ids are reused and have no guarantee for uniqueness.  UUIDs are available and can provide better guarantees for uniqueness. Another approach is to use the name string which allows the ability for punctuation characters, eg. : or /, to create namespaced names for the domains.
>>
>> 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 kind of agree with Jan, but I can see your point.

My approach to address something like that would be to send a patch
adding the high level feature document to e.g. docs/features. This
can be accompanied by a rough RFC implementation, but that wouldn't
be required. By sending a first patch you show some commitment to the
topic, but you don't have to invest too much time in case the idea is
rejected. And with a patch you automatically request some feedback.
The feature document would only be committed with the code, of course.


Juergen


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

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

[Lars Kurth]

On 05/09/2019, 08:50, "Jan Beulich" <jbeulich@suse.com> wrote:

    On 05.09.2019 09:41, Rich Persaud wrote:
    > 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'll certainly listen to what others think, but I have to confess that
    on such prior instances I was already on the edge of requesting that
    time not be spent in such a way. Please recall that calls, other than
    mails, take everybody's time, and exactly at the same time. Therefore
    my personal opinion is that topics on calls should be limited to items
    which cannot be resolved by other means, or which are certain to need
    (almost) everybody's attention right away.
    
I disagree with you on this one. 

So yes, it is true that a call costs everyone time. But it's a fixed cost once per month
*  Something experimental could be posted on the list and it may take everyone more time to read and respond than a 5 minute early discussion on the call
* Also, of course everyone has the option to drop out or not attend a call based on the agenda
* If we had more urgent stuff to discuss all the time and we would have to displace urgent discussions to cover discussions which can wait, I may agree with you, but this is not currently the case

I will look at the agenda though and re-structure it in such a way that this is clear

IMPORTANT: I had a few additions to the agenda, but do not know WHO added these. I believe one was Juergen. Who added the items related to MA Youngs patches? And if you add series to discuss can you please add URLs or message IDs

Regards
Lars


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

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

[Juergen Gross]

On 05.09.19 10:00, Lars Kurth wrote:
> 
> 
> On 05/09/2019, 08:50, "Jan Beulich" <jbeulich@suse.com> wrote:
> 
>      On 05.09.2019 09:41, Rich Persaud wrote:
>      > 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'll certainly listen to what others think, but I have to confess that
>      on such prior instances I was already on the edge of requesting that
>      time not be spent in such a way. Please recall that calls, other than
>      mails, take everybody's time, and exactly at the same time. Therefore
>      my personal opinion is that topics on calls should be limited to items
>      which cannot be resolved by other means, or which are certain to need
>      (almost) everybody's attention right away.
>      
> I disagree with you on this one.
> 
> So yes, it is true that a call costs everyone time. But it's a fixed cost once per month
> *  Something experimental could be posted on the list and it may take everyone more time to read and respond than a 5 minute early discussion on the call
> * Also, of course everyone has the option to drop out or not attend a call based on the agenda
> * If we had more urgent stuff to discuss all the time and we would have to displace urgent discussions to cover discussions which can wait, I may agree with you, but this is not currently the case
> 
> I will look at the agenda though and re-structure it in such a way that this is clear
> 
> IMPORTANT: I had a few additions to the agenda, but do not know WHO added these. I believe one was Juergen. Who added the items related to MA Youngs patches? And if you add series to discuss can you please add URLs or message IDs

Done.


Juergen

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

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

[Andrew Cooper]

On 05/09/2019 08:49, Lars Kurth wrote:
> On 05/09/2019, 08:41, "Rich Persaud" <persaur@gmail.com> wrote:
>
>     > On Sep 5, 2019, at 03:19, Jan Beulich <jbeulich@suse.com> 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.

~Andrew

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

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

[Andrew Cooper]

On 05/09/2019 09:00, Lars Kurth wrote:
> IMPORTANT: I had a few additions to the agenda, but do not know WHO added these. I believe one was Juergen. Who added the items related to MA Youngs patches?

Steven Haigh I believe.

Booting fedora guests is currently in a very broken state.

~Andrew

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

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

[Steven Haigh]

On 2019-09-05 18:19, Andrew Cooper wrote:
> On 05/09/2019 09:00, Lars Kurth wrote:
>> IMPORTANT: I had a few additions to the agenda, but do not know WHO 
>> added these. I believe one was Juergen. Who added the items related to 
>> MA Youngs patches?
> 
> Steven Haigh I believe.
> 
> Booting fedora guests is currently in a very broken state.

Yep - I added points 1 & 2 to the AOB section.

I've also added point 3 to inform that I wouldn't be able to drive those 
myself due to timezones.

I have added some references to xen-devel list posts that may be able to 
assist. I'm happy to answer any questions via freenode if someone wants 
to clobber me a few hours before the meeting - pending availability.

-- 
Steven Haigh

? netwiz@crc.id.au     ? http://www.crc.id.au
? +61 (3) 9001 6090    ? 0412 935 897

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

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

[Juergen Gross]

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@gmail.com> wrote:
>>
>>      > On Sep 5, 2019, at 03:19, Jan Beulich <jbeulich@suse.com> 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.

At least for me it is much easier to discuss a new idea when I had some
time to think about it. And by having to write it down the one proposing
the idea will have to sort his thoughts and will stumble over potential
problems, instead of everyone on the call having to imagine what he was
thinking and finding the same problems, which might be solved already.

And by having seen a proposal early I can decide to drop off the call in
case I'm not interested. But I might not know whether some areas I'm
interested in might be touched by a new idea before having seen the high
level description.

This is no veto, but just a suggestion how to use the time of all call
attendees more effectively.


Juergen


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

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

[Lars Kurth]

On 05/09/2019, 09:33, "Juergen Gross" <jgross@suse.com> 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@gmail.com> wrote:
    >>
    >>      > On Sep 5, 2019, at 03:19, Jan Beulich <jbeulich@suse.com> 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.

Lars   
    

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

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

[Rich Persaud]

[-- Attachment #1.1: Type: text/plain, Size: 3443 bytes --]

> On Sep 5, 2019, at 04:36, Lars Kurth <lars.kurth@citrix.com> wrote:
> 
> On 05/09/2019, 09:33, "Juergen Gross" <jgross@suse.com> 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@gmail.com> wrote:
>>>> 
>>>> On Sep 5, 2019, at 03:19, Jan Beulich <jbeulich@suse.com> 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

[-- Attachment #1.2: Type: text/html, Size: 7010 bytes --]

[-- Attachment #2: Type: text/plain, Size: 157 bytes --]

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

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

[Lars Kurth]

[-- Attachment #1.1: Type: text/plain, Size: 455 bytes --]


> 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

I had seen this too late. Apologies
Lars

[-- Attachment #1.2: Type: text/html, Size: 2923 bytes --]

[-- Attachment #2: Type: text/plain, Size: 157 bytes --]

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

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

[Rich Persaud]

[-- Attachment #1.1: Type: text/plain, Size: 675 bytes --]

On Sep 5, 2019, at 12:12, Lars Kurth <lars.kurth@citrix.com> wrote:
>  
> > 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
>  
> I had seen this too late. Apologies
> Lars

Since we did cover the xenstoreless name service today, we can cover "domB mode for dom0less" in the October call.

Rich

[-- Attachment #1.2: Type: text/html, Size: 2952 bytes --]

[-- Attachment #2: Type: text/plain, Size: 157 bytes --]

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