All of lore.kernel.org
 help / color / mirror / Atom feed
From: George Dunlap <george.dunlap@eu.citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: "waldi@debian.org" <waldi@debian.org>,
	James Harper <james.harper@bendigoit.com.au>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [PATCH] hotplug: add openvswitch script
Date: Thu, 18 Apr 2013 17:07:15 +0100	[thread overview]
Message-ID: <51701A33.3050603@eu.citrix.com> (raw)
In-Reply-To: <1366286920.19111.14.camel@zakaz.uk.xensource.com>

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?

  -George

  parent reply	other threads:[~2013-04-18 16:07 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-04-18 11:50 [PATCH] hotplug: add openvswitch script Ian Campbell
2013-04-18 12:08 ` Ian Campbell
2013-04-18 12:19 ` Bastian Blank
2013-04-18 12:22   ` Ian Campbell
2013-04-18 13:42 ` Bastian Blank
2013-04-18 13:50   ` Ian Campbell
     [not found] ` <1366286920.19111.14.camel@zakaz.uk.xensource.com>
2013-04-18 16:07   ` George Dunlap [this message]
2013-04-18 16:16     ` Ian Campbell
2013-04-18 16:19       ` George Dunlap
2013-04-18 18:01   ` [ovs-dev] " Ben Pfaff
     [not found]   ` <20130418180151.GD28075@nicira.com>
2013-04-19  9:04     ` Ian Campbell

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=51701A33.3050603@eu.citrix.com \
    --to=george.dunlap@eu.citrix.com \
    --cc=Ian.Campbell@citrix.com \
    --cc=james.harper@bendigoit.com.au \
    --cc=waldi@debian.org \
    --cc=xen-devel@lists.xen.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.