Mailing List Archive

Xen API call today 8am PST
866-616-9964 / intl 1-210-339-2141, passcode 6613147

Agenda will be to talk about Xen API distro issues for RH & SLES
(what/when/how) and Xen CIM API strategy, so please try to call-in if
possible.

- Gareth
Re: Xen API call today 8am PST [ In reply to ]
On Wed, Aug 23, 2006 at 07:28:00AM -0700, Gareth S Bestor wrote:
> 866-616-9964 / intl 1-210-339-2141, passcode 6613147
>
> Agenda will be to talk about Xen API distro issues for RH & SLES
> (what/when/how) and Xen CIM API strategy, so please try to call-in if
> possible.

Sorry this is clashing with my W3C XML Core telconf as stated 2 weeks ago
http://lists.w3.org/Archives/Public/public-xml-core-wg/2006Aug/0031

so regrets from me, I assume Dan Berrange will be there.

Daniel

--
Red Hat Virtualization group http://redhat.com/virtualization/
Daniel Veillard | virtualization library http://libvirt.org/
veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/

_______________________________________________
xen-api mailing list
xen-api@lists.xensource.com
http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-api
Re: Xen API call today 8am PST [ In reply to ]
On Wed, Feb 14, 2007 at 09:24:14AM -0600, Gareth S Bestor wrote:
> 8-9am PST
>
> 1-866-616-9964 (int'l 1-210-339-2141) passcode 6613147
>
> - Gareth
>
> Dr. Gareth S. Bestor
> IBM Linux Technology Center
> M/S DES2-01
> 15300 SW Koll Parkway, Beaverton, OR 97006
> 503-578-3186, T/L 775-3186, Fax 503-578-3186

Would it be possible to have someone take minutes and send them out to this
list after the meetings? It's hard to get a sense of meeting contents
without agenda or minutes being posted on list.

Thanks,

-Sean

--
Sean Dague
IBM Linux Technology Center email: japh@us.ibm.com
Open Hypervisor Team alt: sldague@us.ibm.com
Re: Re: Xen API call today 8am PST [ In reply to ]
On Wed, Feb 14, 2007 at 10:50:59AM -0500, Sean Dague wrote:

> On Wed, Feb 14, 2007 at 09:24:14AM -0600, Gareth S Bestor wrote:
> > 8-9am PST
> >
> > 1-866-616-9964 (int'l 1-210-339-2141) passcode 6613147
> >
> > - Gareth
> >
> > Dr. Gareth S. Bestor
> > IBM Linux Technology Center
> > M/S DES2-01
> > 15300 SW Koll Parkway, Beaverton, OR 97006
> > 503-578-3186, T/L 775-3186, Fax 503-578-3186
>
> Would it be possible to have someone take minutes and send them out to this
> list after the meetings? It's hard to get a sense of meeting contents
> without agenda or minutes being posted on list.

We're not really working to an agenda at the moment -- just opening the mic to
anyone with questions. If you have a particular item that you'd like
discussed, please feel free to mail the list before the meeting.

This was a short call, as there were only Gareth Bestor, Stefan Berger, and
myself on the line.

Q. How many Xen-API changesets are left to go in before 3.0.5?
A. I've got another batch to go in next week, 10 changesets maybe, and then I
expect the API to stabilise.
Q. Do we have a date for 3.0.5 yet.
A. Not as yet, though Keir's talking about the second half of March.

Stefan had a problem on the domain destroy path, which has now been fixed (by
Wim Colgate) and I've followed up in a separate mail. (This was the same as
the one reported by Susan Krysan recently).

Stefan asked about the recent sHype/ACM Xen-API patch, and what it would take
to get that into the tree. I said that, since I don't have expertise in this
area, I'm going to need consensus from the other security folks with regards
to the API. I'd be looking for an agreement that XSM would drop into the same
framework, in particular.

Previously, I suggested that this would be a good thing to discuss at the next
Xen Summit when everyone's together, and I still think that that's a good
idea.

That's all I remember from the call. If there's anything I've missed, please
pipe up!

Ewan.

_______________________________________________
xen-api mailing list
xen-api@lists.xensource.com
http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-api
Re: Re: Xen API call today 8am PST [ In reply to ]
xen-api-bounces@lists.xensource.com wrote on 02/16/2007 05:18:01 AM:

> On Wed, Feb 14, 2007 at 10:50:59AM -0500, Sean Dague wrote:
>

>
> Stefan asked about the recent sHype/ACM Xen-API patch, and what it would
take
> to get that into the tree. I said that, since I don't have expertise in
this
> area, I'm going to need consensus from the other security folks with
regards
> to the API. I'd be looking for an agreement that XSM would drop into
the same
> framework, in particular.

Here's my/our current thinking. It's difficult to imagine what an API for
any future policy might look like that allows to do policy-specific
operations and I'd rather have a policy-specific API than a generic one
that is more work to program against (and circumvents all that great
serialization/deserialization facilities availablle in libxen. -- see the
other mail). So we regard the ACM policy as an example of a policy like
VIF, VBD and VTPM are examples of devices. The latter three have their own
classes with methods and properties that are specific to each device-type
for porviding funcationality specific to each device. Similar is true with
policies. So we'll have a policy class 'XSPolicy' that allows you to
administer the policy on the system, put a new one in and load it into the
hypervisor and get a reference to the current policy. That reference is
then used to make policy-specific actions on a policy-specific class,
i.e., ACMPolicy for manipulations of that type of policy. Someone
inventing a new policy subsystem for Xen needs to come up with a new
class, extend xend's logic and extend the HV, which is all true anyway no
matter how the API looks like, since ACM-specific code won't likely apply
to any other policy.

>
> Previously, I suggested that this would be a good thing to discuss at
the next
> Xen Summit when everyone's together, and I still think that that's a
good
> idea.

The only concern here is that afaik the next Xen summit is only in April.

Stefan

>
> That's all I remember from the call. If there's anything I've missed,
please
> pipe up!
>
> Ewan.
>
> _______________________________________________
> xen-api mailing list
> xen-api@lists.xensource.com
> http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-api
Re: Re: Xen API call today 8am PST [ In reply to ]
Ewan Mellor wrote on 02/16/2007 05:18:01 AM:

> Stefan asked about the recent sHype/ACM Xen-API patch, and what it would
take
> to get that into the tree. I said that, since I don't have expertise in
this
> area, I'm going to need consensus from the other security folks with
regards
> to the API. I'd be looking for an agreement that XSM would drop into
the same
> framework, in particular.
>

Hi Ewan, I think Stefan responded to the technical merits of the sHype/ACM
Xen-API patch, and the difficulty of predicting what an API for any future
policy might look like. I understand your desire for consensus from those
contributing to Xen security capabilities, but I think we essentially have
that. During the last Xen summit it was agreed in principle that XSM would
be considered for inclusion once sample policies were available and
performance issues were addressed. NSA submitted additional XSM support in
Dec. (on the Xense-devel list) and mentioned the intent for XSM to
"subsume" the functionality of ACM with the "ACM-specific XSM module".
They also pointed out that the "current implementation [of XSM] uses the
existing ACM interfaces". I have seen no strong public objections to XSM
or to the sHype/ACM Xen-API.


> Previously, I suggested that this would be a good thing to discuss at
the next
> Xen Summit when everyone's together, and I still think that that's a
good
> idea.
>

If there are concerns, those concerns should be voiced now, before the
next Xen summit. In the mean time, there are people using sHype/ACM today
as the only supported access control framework in Xen (certainly IBM is
using it, but there are others as well). Barring any objections, I don't
see the need to delay the same sort of management interfaces that we
already have for other components of Xen, some of which may even be less
mature than sHype/ACM.

-Ron