From mboxrd@z Thu Jan 1 00:00:00 1970 From: George Dunlap Subject: Re: [PATCH] hotplug: add openvswitch script Date: Thu, 18 Apr 2013 17:19:06 +0100 Message-ID: <51701CFA.90308@eu.citrix.com> References: <1366285840-26601-1-git-send-email-ian.campbell@citrix.com> <1366286920.19111.14.camel@zakaz.uk.xensource.com> <51701A33.3050603@eu.citrix.com> <1366301779.19111.26.camel@zakaz.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1366301779.19111.26.camel@zakaz.uk.xensource.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Ian Campbell Cc: "waldi@debian.org" , James Harper , "xen-devel@lists.xen.org" List-Id: xen-devel@lists.xenproject.org On 18/04/13 17:16, Ian Campbell wrote: > On Thu, 2013-04-18 at 17:07 +0100, George Dunlap wrote: >> On 18/04/13 13:08, Ian Campbell wrote: >>> On Thu, 2013-04-18 at 12:50 +0100, Ian Campbell wrote: >>>> Based on Waldi's RFC at >>>> http://lists.xen.org/archives/html/xen-devel/2012-09/msg00943.html >>>> >>>> To use it set vif.default.script="vif-openvswitch" in /etc/xen/xl.conf or use >>>> script=vif-openvswitch in the vif configuration. >>>> >>>> Appears to do the right thing for PV and HVM guests (including tap devices) >>>> and with stubdomains. >>>> >>>> In order to support VLAN tagging and trunking the "bridge" specified in the >>>> configuration can have a special syntax, that is: >>>> >>>> BRIDGE_NAME[.VLAN][:TRUNK,TRUNK] >>>> >>>> e.g. >>>> - xenbr0.99 >>>> add the VIF to VLAN99 on xenbr0 >>>> - xenbr0:99,100,101 >>>> add the VIF to xenbr0 as a trunk port receiving VLANs 99, 100 & 101 >>>> >>>> Waldi, can you confirm if I have correctly reverse engineered the syntax from >>>> the regexp please ;-) >>> I've done this as a Xen patch, but in principal this could also be >>> maintained in the openvswitch tree (I've added their list to the CC, >>> having forgotten it with the initial posting). Anyone have any strong >>> preference for one home over the other? >>> >>> If we do go with the Xen tree then WRT the feature freeze, this can >>> pretty obviously only break things if you enable it. >> Sure; but we don't want to have a bunch of shiny-looking new features >> that are in fact crappy and unreliable, just because they weren't there >> before. :-) >> >> Just to be clear, I'm not saying this will be unreliable; it looks >> pretty simple and straightforward. I'm just saying we still need to >> consider whether we'll find bugs before the release or not, even if it >> doesn't break existing functionality. >> >> How about something like this: We add a warning in the script saying >> it's tech-preview. When we start RC's, I'll write a blog specifically >> asking people to test it and give their feedback. If I get a certain >> number of people saying they've tested it on their systems and that it >> seems to work (10 or so?) then we can take the warning out and call it >> a plain feature. >> >> What do you think? > No one will ever see the output from the hotplug scripts so I think > that's a bit of a waste of time. > > We could call it out specifically in the call for testing for rc1 etc > and position it as appropriate in the release notes based on the > feedback we get. Sure, sounds good. -George