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
next prev 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.