-ovn reviews and have added him to the core team.
They join the existing core team of: Russell Bryant, Dong Jun, Han Zhou,
Numan Siddique, and Lucas Alvares Gomes Martins.
Thanks,
--
Russell Bryant
__
OpenStack Development
> annou...@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-announce
>
--
Russell Bryant
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.op
e
>> charms room).
>>
>> Cheers
>>
>> James
>>
>>
>>
>> ______
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.
ource/openvswitch/+bug/1577088)...
>> ---
>>
>> OpenStack on Ubuntu rocks! :-D
>>
>> Thanks!
>> Thiago
>>
>
> I just realized how cool IO Visor is!
>
> Sorry about mixing subjects, let's keep this one clear for OVN on top of
> DPDK.
>
ay. We haven't looked
at Neutron integration of this at all. Perhaps it maps into the
networking-l2gw API as well, though?
I'm happy to provide pointers if anyone is interested in working in this
area.
--
Russell Bryant
__
OpenStack
c:refactor_ml2db
>
Thanks a lot for looking out for the various networking-* projects when
working on changes like this. It's really great to see.
--
Russell Bryant
__
OpenStack Development Mailing List (not for usage
n the ovs-discuss mailing list, where I saw it first. Here's the thread:
https://mail.openvswitch.org/pipermail/ovs-discuss/2016-November/042970.html
--
Russell Bryant
--
Russell Bryant
__
OpenStack Development Mailing
is a dedicated nic for external traffic is,
> instead of a patch port from br-ctl to br-ex, it is directly connected to
> the nic for the external traffic.
>
> Even without the issue that instigated this message, I think that this is
> a change worth considering.
>
Nice writeup, Br
at the important part?
>
> Let's just get on with making stuff and work out the problems (and of
> course there will be many, there always are) as they happen. That's
> what we do.
>
Agreed, Chris. I think this topic has reflected quite poorly on
OpenStack, so far.
--
Russell Bryant
the corresponding CI jobs. My suggestion would be to
try to do what you need using OVN's L3 support.
[1] https://review.openstack.org/#/c/346646/
--
Russell Bryant
__
OpenStack Development Mailing List (not for usage ques
dl_ovn
>
As you noted, it looks like the OVN services were not started. If you
installed from source, you should run:
$ sudo /usr/share/openvswitch/scripts/ovn-ctl start_northd
The OVN packages install systemd units, so you can also start it that way
and set i
t;. Please confirm your attendance so we
> can get a final count.
>
> Here's some reviews: https://www.tripadvisor.com/
> Restaurant_Review-g187497-d1682057-Reviews-Raco_De_La_
> Vila-Barcelona_Catalonia.html
>
+1
--
Russell Bryant
_
ity which is how I do currently with
> devstack. I would like to know if either ovn or neutron will have
> contentions if port-security disabled at neutron server.
>
You can disable it. There's no problem with that. It will just disable
related features: L2 and L3 port security and securi
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
--
Russell Bryant
ious here...
Related, Flavio asked about this earlier, and I don't think it was
answered.
Is the issue with the use of the Fuel name? Would the concern remain if
the repository was called "pancakes-ccp" i
inue. Ongoing experimentation with different approaches is a good
thing here.
To summarize, I see all actions taken so far by the Fuel team as fine. I
see no need to change anything in governance. They are free to add it as
an official deliverable if and when they choose to do so. Even if
On Wed, Jul 27, 2016 at 4:15 PM, Zhou, Han <hzh...@ebay.com> wrote:
>
>
> On Wed, Jul 27, 2016 at 7:15 AM, Russell Bryant <rbry...@redhat.com>
> wrote:
>
>>
>>
>> On Wed, Jul 27, 2016 at 5:58 AM, Kevin Benton <ke...@benton.pub> wrote:
>>
lve. There's one identified multiple-worker related race condition
on updates, but I think we can solve that another way.
> On Tue, Jul 26, 2016 at 11:31 AM, Russell Bryant <rbry...@redhat.com>
> wrote:
>
>>
>>
>> On Fri, Jul 22, 2016 at 7:51 AM, Numan S
request to ODL.
> And I didn't see how the port states (UP & DOWN) are handled (I didn’t see
> any call to ProvisioningBlock, so does it mean it will just be UP from the
> beginning?) It would be great if anyone can help answer this question.
>
Port state is up from the beginn
al”.
>>> - CleanupProcessing - Mark orphaned processing rows to pending.
>>> - Full sync - Re-sync when detecting an ODL "cold reboot”.
>>>
>>>
>>>
>>> Thanks
>>> Numan
>>>
>>>
>>
e
you considered integrating DPDK awareness into the existing puppet-vswitch
that configures openvswitch? Why is a separate puppet-dpdk needed?
--
Russell Bryant
__
OpenStack Development Mailing List (not for usage questions)
Uns
s://docs.google.com/document/d/13K4Xpdu1IbRJDj5JTepDI4nwUkCDCu7IOnYwHkZtcMA/edit?usp=sharing
>
Nice work, Oleg. I'll comment on the doc for things that I know of that
have changed since March.
Thanks,
--
Russell Bryant
--
Russell Bryant
___
ry. I think
> pretty much everyone agrees that there is not much value to us or the world
> for us to compete with kubernetes or docker.
>
> So, we do want to be supportive of bare metal and containers - but the
> specific _WAY_ we want to be supportive of those things is different fo
>
Note that the original definition of "disagreement" from reviewstats [1][2]
paid particular attention to ordering. A disagreement is only when a -core
team member votes against you, not the other way around. It was kind of
an experimental thing to see if it could help expose
| 652 | 19.85 (-11.51)
>
It would also be interesting to know how the "long tail" of OpenStack has
evolved over time, as well.
https://twitter.com/tcarrez/status/710858829760598017
"A long tail: ~2500 devs are involved in #OpenStack Mitaka, but less than
200 devs produ
On Tue, Apr 5, 2016 at 12:57 PM, Assaf Muller <as...@redhat.com> wrote:
> On Tue, Apr 5, 2016 at 12:35 PM, Sean M. Collins <s...@coreitpro.com>
> wrote:
> > Russell Bryant wrote:
> >> because they are related to two different command line utilities
> >&g
h that said, I see no reason to keep two methods if one is clearly
better. I just don't think combining them into one config option makes
much sense.
--
Russell Bryant
__
OpenStack Development Mailing List (not for usage q
On Mon, Apr 4, 2016 at 12:22 PM, Kyle Mestery <mest...@mestery.com> wrote:
> On Mon, Apr 4, 2016 at 8:15 AM, Russell Bryant <rbry...@redhat.com> wrote:
> > Hello, everyone.
> >
> > While bootstrapping networking-ovn, the release model has been
> > "
the primary
Neutron repositories.
Thoughts?
[1] http://governance.openstack.org/reference/tags/release_independent.html
[2]
http://governance.openstack.org/reference/tags/release_cycle-with-milestones.html
--
Russell Bryant
__
O
aware of any other problems.
--
Russell Bryant
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/
On Mon, Mar 21, 2016 at 12:26 PM, Russell Bryant <rbry...@redhat.com> wrote:
> On Thu, Mar 17, 2016 at 1:45 AM, Hong Hui Xiao <xiaoh...@cn.ibm.com>
> wrote:
>
>> Hi Russell.
>>
>> Since the "ovn-bridge-mapping" will become accessible in OVN South
in dev docs.
We got pushback on documenting OVN there, so we've been putting everything
in our dev docs, instead. For example:
http://docs.openstack.org/developer/networking-ovn/install.html
http://docs.openstack.org/developer/networking-ovn/refarch.html
It'd be nice to have somewhere else to
I see you posted the same message
over on the OVS discuss mailing list. I think the current work is probably
more relevant to that list, so I'm going to respond over there.
--
Russell Bryant
__
OpenStack Development Mail
pipermail/dev/2016-March/068112.html
I was thinking that we would be able to read the physical endpoints table
to get what we need, but now I'm thinking it may not fit our use case.
The alternative would be to just store the bridge mappings as an
external_id on the Chassis record in the southboun
nd 4) need code
> change in networking-ovn.
>
There's some work happening in OVN where the information currently in
ovn-bridge-mappings on each hypervisor will become accessible in the OVN
Southbound database.
As a nice side effect, the Neutron plugin should be able to read those
bridge mapp
. I was just curious what you had in
mind. We don't really have OpenStack projects that are organizing around
contributing to other upstreams, but I think this case is fine.
--
Russell Bryant
__
OpenStack Development Mailing
for it, as well.
Some of your errors are a bit odd. I would not expect br-ex or br-tun to
be created. Can you also share your devstack configuration? Was this
system used for any other configuration before? If so, can you try a fresh
environment?
--
Russell Bryant
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> This is looking fantastic!! Big +1 to using it everywhere.
>
I love it. :-)
> We also need to put somewhere both this Owl and ironic's Bear together :)
>
Don't forget Oslo's moose.
https://github.com/openstack/oslo-incubator/tree/master/doc/source/_images
--
Russell Bryant
___
On Mon, Feb 22, 2016 at 10:14 AM, Thierry Carrez <thie...@openstack.org>
wrote:
> Hi everyone,
>
> TL;DR: Let's split the events, starting after Barcelona.
>
This proposal sounds fantastic. Thank you very much to those that help put
it together.
er than the networking-sfc
backend? Is it none for now, but just leaving it open for an
alternative Neutron API should one come up?
--
Russell Bryant
__
OpenStack Development Mailing List (not for usage questions)
Unsubscri
st left.
Thanks, Neil. You've summarized this well. A more clear and accurate
chain of accountability is indeed what we're trying to get to here.
--
Russell Bryant
__
OpenStack Development Mailing List (not for usage
to account ? There will
> always be some subjectivity there, but I think it's a good place to start.
>
> Comments ?
>
I agree with your take. I'm not too worried about coming up with a
strict definition for what a reasonable open source backend is. We can
throw in some desirable traits li
ork together to produce a set of
deliverables, where each deliverable is made up of one or more git
repositories.
The ongoing issue is trying to find the right structure that matches how
our teams are working and what they're willing to own. The current
approach hasn't worked, so it's t
core/release teams, etc).
After thinking over the discussion in this thread for a while, I have
started the following proposal to implement the stadium renovation that
Armando originally proposed in this thread.
https://review.openstack.org/#/c/275888
--
Ru
h
> is only well tested on "desktop" pace distro releases would be a
> serious misstep for the project.
>
but are most people using that LTS release with cloud-archive enabled?
--
Russell Bryant
___
ource builds seems to be working fine. It's
just not something anyone wants to gate the main Neutron repo with.
That seems quite reasonable. If the features aren't in proper
releases yet, I don't see gating as that important anyway.
--
Ru
On 01/14/2016 03:43 PM, Assaf Muller wrote:
> On Thu, Jan 14, 2016 at 9:28 AM, Russell Bryant <rbry...@redhat.com> wrote:
>> On 01/13/2016 11:51 PM, Tony Breeds wrote:
>>> The challenge for you guys is the kernel side of things but if I
>>> understood correctly y
ed with the distros that we test on. Are we saying that
>>> no one uses the distro provided OVS packages to run Neutron? If not what
>>> are they using?
>>
>> Right - this was my impression as well.
>
> Even Debian stable (jessie) has OVS 2.3, what
that just using OVS 2.5 isn't enough. You must also have kernel
support for ovs+conntrack integration. That is in Linux 4.3+ or the
openvswitch kernel module included in the ovs tree.
networking-ovn's tempest job uses the openvswitch kernel module from ovs
master, as well. That seems to be working on
d interest in os-vif, we came up with a
> cross-section of contributors across the Nova, Neutron and NFV
> spaces to be the initial core team:
>
> Jay Pipes
> Daniel Berrange
> Sean Mooney
> Moshe Levi
> Russell Bryant
> Sahid Ferdjaoui
> Maxime Leroy
>
k, but that's something to check for.
If nothing else, if it's just a dev VM, try rebooting.
--
Russell Bryant
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.opens
about how our projects are operating. I think projects
should take more ownership and responsibility for their associated
drivers. No matter how limited the criteria and coordination is, it's
better than none. Let's tackle the pain points instead of just blowing
the whole thing up.
--
Russell Bryant
teful Services"
at the OVS Conference last week:
http://openvswitch.org/support/ovscon2015/16/1620-stringer.pdf
https://www.youtube.com/watch?v=PV2rxxb6lwQ
--
Russell Bryant
__
OpenStack Development Mailing List (not
proposal, SFC more generally, and watching other
efforts happening within Neutron that affect this.
How can we manage these expectations more clearly?
--
Russell Bryant
__
OpenStack Development Mailing List (not for usage
implementation discussions for that will take place on the
OVS dev mailing list. I'll try to post a pointer back to openstack-dev
once there's some kind of design to review there. I'm not sure on the
timeline right now, as I have my hands in several things a
We could write directly to the southbound db and cut ovn-northd and the
northbound db off, but we'd have to implement all of the logic from
ovn-northd in Neutron in that case. The northbound db is a much simpler
model.
--
Russell Bryant
Where do you find this? I've been using Iceland, but this sounds more
explicit. For me it makes me pick a country and then a TZ, so I'm not
seeing the "GMT (no daylight saving)" option anywhere.
--
Russell
On 11/09/2015 02:39 PM, Ihar Hrachyshka wrote:
> There is also 'GMT (no daylight
- Original Message -
> Hi Russell,
>
> Please see my replies inline.
>
> Thanks,
> Cathy
>
> -Original Message-
> From: Russell Bryant [mailto:rbry...@redhat.com]
> Sent: Wednesday, October 28, 2015 4:21 PM
> To: OpenStack Development Mailin
bally" doesn't make any sense. If all ports are
expected to be on the same network, is the match applied for any traffic
entering that network from any port?
I'm in Tokyo this week, so if the group working on this would like to
talk in person, that would be great too.
--
Russ
On 10/28/2015 05:14 PM, Giuseppe (Pino) de Candia wrote:
> On Wed, Oct 28, 2015 at 4:20 PM, Russell Bryant <rbry...@redhat.com
> <mailto:rbry...@redhat.com>> wrote:
>
> I read through the proposed SFC API here:
>
> http://docs.openstack.org/developer/networ
appy place.
>
This is *really* cool. I'm excited to use this and see all the things
others record. Thanks!!
--
Russell Bryant
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-req
the cms has to maintain the host to lport
> association and we can't query from NB-DB. Makes sense.
The host to lport mappings are maintained by ovn-controller in the Port
Binding table of the OVN Southbound database.
--
utron/+bug/1502356
+1
Another problem I see with this is that it doesn't seem to be
discoverable by a user. I think resource limits should be discoverable
in the API (like quotas are).
--
Russell Bryant
__
OpenStack
On 10/01/2015 03:26 PM, Russell Bryant wrote:
> On 10/01/2015 09:45 AM, Ihar Hrachyshka wrote:
>> Hi all,
>>
>> I talked recently with several contributors about what each of us
>> plans for the next cycle, and found it’s quite useful to share
>> thoughts with o
On 09/27/2015 04:18 PM, Russell Bryant wrote:
> On 09/27/2015 06:50 AM, Kevin Benton wrote:
>> Assuming it implements the normal provider networks API, you just
>> specify the segmentation_id when you create the network.
>>
>> neutron net-create NET_NAME -
On 10/02/2015 11:32 AM, Russell Bryant wrote:
> On 10/01/2015 03:26 PM, Russell Bryant wrote:
>> On 10/01/2015 09:45 AM, Ihar Hrachyshka wrote:
>>> Hi all,
>>>
>>> I talked recently with several contributors about what each of us
>>> plans for the nex
e
"iface-id" to the name of the logical port.
Once ovn-controller has mapped a port on br-int to a logical port, it
can configure the switch appropriately for that port.
Does that make sense?
[1] https://github.com/openvswitch/ovs/blob/master/tutorial/O
gt; else in far-east during that time. But lets keep the discussion going
> and collaborate if you work on sfc.
I look forward to meeting you in November! :-)
--
Russell Bryant
__
OpenStack Development Mailing List (not f
couver-2015/summit-videos/presentation/ovn-native-virtual-networking-for-open-vswitch
[2]
https://openstacksummitoctober2015tokyo.sched.org/event/89a27d6b5bab975a7a4f49ec57ee5210#.Vg2DmXUVhBc
[3]
http://git.openstack.org/cgit/opens
ional flows at this time or if it is
> possible to extend if need be.
I'm not quite sure I understand this part. Could you expand on what you
have in mind?
--
Russell Bryant
__
OpenStack Development Mailing List (not for usage questions)
ere's a Neutron project for adding an SFC
API and from what I've seen so far, I think we'll be able to extend OVN
such that it can back that API.
--
Russell Bryant
__
OpenStack Development Mailing List (not for usage question
?
> In your example in
>
> https://github.com/openvswitch/ovs/commit/c02819293d52f7ea7b714242d871b2b01f57f905
> : "physnet1" is used as physical network, and br-eth1 is used as the
> provider network OpenFlow switch.
> If we can assign the VLAN tag of th
e Geneve and VxLAN protocols are being
used. Packets between hypervisors are sent using Geneve. Packets
between a hypervisor and the gateway are sent using VxLAN.
--
Russell Bryant
__
OpenStack Development Mailing List (not
should mess with the commit message at all. Commit
message formatting is often very intentional.
--
Russell Bryant
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.o
ort term solution and
> a long term one:
>
> A short term solution (proposed by Russell Bryant) is similar to the
> work that was done for container support in OVN - using a binding
> profile http://networking-ovn.readthedocs.org/en/latest/containers.html.
> A ovn logical netw
tenant overlay networks.
VTEP gateways or provider networks come into play when you want to
connect these overlay networks to physical, or "underlay" networks.
Hope that helps,
--
Russell Bryant
__
OpenStack Devel
deed a
> decent one in my opinion.
> If OVN cannot converge on the extension proposed by networking-l2gw then
> I'd keep using the binding profile for specifying gateway ports.
Great, thanks for the feedback!
> [1] https://review.openstack.org/#/c/210623/
--
Russell Bryant
_
On 09/24/2015 01:25 PM, Armando M. wrote:
>
>
>
> On 24 September 2015 at 09:12, Russell Bryant <rbry...@redhat.com
> <mailto:rbry...@redhat.com>> wrote:
>
> On 09/24/2015 10:18 AM, Salvatore Orlando wrote:
> > One particular issue i
network (which
could itself be a VLAN network, but the tags are not related, and the
traffic would be re-tagged at that point).
Does that make sense?
> Thanks in advance,
> Tony
>
> -Original Message-
> From: Russell Bryant [mailto:rbry...@redhat.com]
> Sent: Wednesda
On 09/22/2015 02:35 PM, Carl Baldwin wrote:
> On Tue, Sep 22, 2015 at 10:42 AM, Russell Bryant <rbry...@redhat.com> wrote:
>> The Neutron L3 agent is only used with networking-ovn temporarily while
>> we work through the L3 design and implementation in OVN itself. OVN
>>
Thoughts/Comments ?
The Neutron L3 agent is only used with networking-ovn temporarily while
we work through the L3 design and implementation in OVN itself. OVN
will not use the L3 agent (or DVR) quite soon. Some initial L3 design
notes are being discussed on the ovs dev list now. L3 in OV
each interface will be tagged with
a unique VLAN ID on its way in and out of the VM, the same way it is
done for each container with a single interface.
--
Russell Bryant
__
OpenStack Development Mailing List (not fo
mail. I agree with your top two priorities as being a good summary of
> what the "rest of the community" expects the Glance leadership to focus
> on in the very short term.
+1
Thanks, Doug! and agreed with Thierry's response here.
--
Russell Bryant
___
in the networking-ovn repo.
--
Russell Bryant
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin
On 08/25/2015 03:02 PM, Assaf Muller wrote:
On Tue, Aug 25, 2015 at 2:15 PM, Russell Bryant rbry...@redhat.com
mailto:rbry...@redhat.com wrote:
On 08/25/2015 01:26 PM, Amitabha Biswas wrote:
Russell suggested removing the MYSQL_DRIVER=MySQL-python declaration
from
or follow-up patches.
--
Russell Bryant
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman
the last few weeks and it seems something has changed that made
our tests break. We inherit a lot of base plugin tests from neutron, so
it's probably some change in Neutron that we haven't synced with yet. I
haven't had time to dig into it yet.
--
Russell Bryant
environments (for example Kuryr))
To be clear, I support the feature as long as it's documented that it's
opaque to Neutron backends.
My argument is about the general idea of arbitrary pass-through to
backends, which you don't seem to be proposing.
--
Russell Bryant
is this:
http://specs.openstack.org/openstack/nova-specs/specs/kilo/approved/tag-instances.html
Note this important line:
The tag is an opaque string and is not intended to be interpreted or
even read by the virt drivers.
--
Russell Bryant
On 08/24/2015 09:35 AM, Russell Bryant wrote:
On 08/24/2015 09:25 AM, Kevin Benton wrote:
Hi everybody!
In Neutron the idea of adding tags to resources has come up several
times this cycle alone.[1][2][3]
The general concern that has led to them being rejected is that backends
these tags, they will be part
of the API so they should be stable and will be tempting to use for lots
of stuff. :)
Totally agreed ... though I'd also argue that vendor API extensions are
harmful and shouldn't be allowed going forward, either.
--
Russell Bryant
://specs.openstack.org/openstack/neutron-specs/specs/liberty/vlan-aware-vms.html
--
Russell Bryant
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org
of Neutron. I get
that it's hard, but that's the value Neutron brings to the table.
--
Russell Bryant
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org
doesn't have to develop a close
trust relationship with everyone merging code into the main neutron
repo, much less all the other repos. He can delegate some of that. It
only works if everyone buys into this way of thinking.
--
Russell Bryant
I found a couple of problems in this one. I'll fix it in v5 in a few
minutes.
On 07/31/2015 10:52 AM, Russell Bryant wrote:
Add a new OVN configuration entry in the Open_vSwitch database called
ovn-bridge-mappings. This allows the configuration of mappings
between a physical network name
at the same
time as upgrading your Neutron control plane. As long as any ovsdb
schema changes are backwards compatible, you could do rolling-upgrades
of ovn-controller on compute or network nodes.
--
Russell Bryant
__
OpenStack
Bryant
On Mon, Jul 13, 2015 at 7:33 AM, Russell Bryant rbry...@redhat.com
mailto:rbry...@redhat.com wrote:
On 07/13/2015 04:09 AM, Kevin Benton wrote:
because you won't have to run Neutron agents on compute nodes anymore.
How will upgrades work for OVN?
We haven't
of the Open vSwitch
project), which I also think simplifies this a good bit for Neutron,
because you won't have to run Neutron agents on compute nodes anymore.
--
Russell Bryant
__
OpenStack Development Mailing List
https://review.openstack.org/189712
devstack-gate patches:
https://review.openstack.org/189424
https://review.openstack.org/189715
project-config patches:
https://review.openstack.org/189426
https://review.openstack.org/189727
--
Russell Bryant
just
drop it completely and hope someone else feels like taking it on.
--
Russell Bryant
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
1 - 100 of 779 matches
Mail list logo
