the networking-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
__
OpenSt
ou...@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.openstack.
> James
>>
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://l
088)...
>> ---
>>
>> 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.
>
> I fo
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 Development Mailing List
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 questions)
Unsubscribe: op
cuss 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 Mailin
xternal 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, Brent.
--
Russell Bry
nt 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 Bryan
ding 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 questions)
Unsubscri
n.ovsdb.impl_idl_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 ca
firm 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
___
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 securit
_
> 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
___
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" instead of "fuel-ccp"?
--
Russell Bryant
__
m happy to see that
continue. 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 they
have a vision of these things becoming official and supported in the
future, that does not mean they must mark them that way today.
--
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
On Wed, Jul 27, 2016 at 4:15 PM, Zhou, Han wrote:
>
>
> On Wed, Jul 27, 2016 at 7:15 AM, Russell Bryant
> wrote:
>
>>
>>
>> On Wed, Jul 27, 2016 at 5:58 AM, Kevin Benton wrote:
>>
>>> > I'd like to see if we can solve the problems more g
d solve. 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
> wrote:
>
>>
>>
>> On Fri, Jul 22, 2016 at 7:51 AM, Numan Siddique
>> wrote:
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 be
ted”.
>>>
>>> Maintenance thread
>>> --
>>> Maintenance thread does 3 operations
>>> - JournalCleanup - Delete completed rows from journal table
>>> “opendaylightjournal”.
>>> - CleanupProcessing - Mark orphaned processing rows to pendin
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)
Unsu
cs.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
__
OpenStack D
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
reement" 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 overly eager +1
reviewers (lots of reviews for stat
t; Apr '16 | 3284 (+19.03) | 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 produce more than 50% of changes"
652 contributors represents roughly 80% of the changes in Mitaka by
eye-balling that graph. That doesn't sound as bad.
--
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
On Tue, Apr 5, 2016 at 12:57 PM, Assaf Muller wrote:
> On Tue, Apr 5, 2016 at 12:35 PM, Sean M. Collins
> wrote:
> > Russell Bryant wrote:
> >> because they are related to two different command line utilities
> >> (ovs-vsctl vs ovs-ofctl) that speak two
son 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 questio
On Mon, Apr 4, 2016 at 12:22 PM, Kyle Mestery wrote:
> On Mon, Apr 4, 2016 at 8:15 AM, Russell Bryant wrote:
> > Hello, everyone.
> >
> > While bootstrapping networking-ovn, the release model has been
> > "release:independent" [1], though we haven't ac
t; [2] to match 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
_
not 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/listinfo/openstack-dev
On Mon, Mar 21, 2016 at 12:26 PM, Russell Bryant wrote:
> On Thu, Mar 17, 2016 at 1:45 AM, Hong Hui Xiao
> wrote:
>
>> Hi Russell.
>>
>> Since the "ovn-bridge-mapping" will become accessible in OVN Southbound
>> DB, do you meant that neutron plugin can
g no official place to put equivalent documentation
except 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.
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
-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 southbo
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 mappings from the OVN database
hat's fine. 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
error. The problem
isn't clear, but we can track it there.
I assume this is CentOS 7? I hvaen't tried with CentOS 7 in a long time,
unfortunately. I use Fedora 23 regularly without issue. It also runs on
Ubuntu 14.04 in OpenStack CI regularly. If it's not working on CentOS 7,
we need t
his 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
--
Rus
On Mon, Feb 22, 2016 at 10:14 AM, Thierry Carrez
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.
-
you expect other 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 quest
ws I've just 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 Mai
ility come into 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
ect teams that work 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 wor
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
tware which
> 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
_
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
On 01/14/2016 03:43 PM, Assaf Muller wrote:
> On Thu, Jan 14, 2016 at 9:28 AM, Russell Bryant 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 you can get the kenrel mod
testing with source 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
rimental repo.
Note 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
m
ressed 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 Lero
talled
earlier in devstack, 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
7;s mostly a governance technicality. I'm less
concerned about what projects.yaml looks like and more concerned about
what it implies about how our projects are operating. I think projects
should take more ownership and responsibility for their associated
drivers. No matter how limited the criter
ateful 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
o
far studying this 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
ation work?
As I mentioned above, the current work is getting SFC in OVN first. The
design and 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 k
utron plugin interact with south db?
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 saving)
On 10/28/2015 05:14 PM, Giuseppe (Pino) de Candia wrote:
> On Wed, Oct 28, 2015 at 4:20 PM, Russell Bryant <mailto:rbry...@redhat.com>> wrote:
>
> I read through the proposed SFC API here:
>
> http://docs.openstack.org/developer/networking-sfc/api.html
- 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
ching "globally" 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 woul
k community a happy 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)
Unsubscrib
e 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.
pad.net/neutron/+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
__
"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/tutor
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
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 -
hear any
comments or questions you may have.
We're also interested in any new contributors! Feel free to reach out
to me for help getting started.
[1]
https://www.openstack.org/summit/vancouver-2015/summit-videos/prese
penstack summit to attend something
> 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
__
O
ly make sense for the Neutron case.
SFC certainly makes sense. There'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
lows 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
tps://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 a
th the 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
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...@li
On 09/24/2015 01:25 PM, Armando M. wrote:
>
>
>
> On 24 September 2015 at 09:12, Russell Bryant <mailto:rbry...@redhat.com>> wrote:
>
> On 09/24/2015 10:18 AM, Salvatore Orlando wrote:
> > One particular issue is that the project implements the o
; I totally agree. The solution based on the binding profile is indeed 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!
>
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
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 network
VM, the tag
is stripped and then forwarded to the proper Neutron 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
On 09/22/2015 02:35 PM, Carl Baldwin wrote:
> On Tue, Sep 22, 2015 at 10:42 AM, Russell Bryant 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
>> will not use the L3 agen
c for 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 (n
> Any 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.
l. 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
___
quickly and easily disable tests by updating our
devstackgaterc file in the networking-ovn repo.
--
Russell Bryant
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?su
On 08/25/2015 03:02 PM, Assaf Muller wrote:
>
>
> On Tue, Aug 25, 2015 at 2:15 PM, Russell Bryant <mailto:rbry...@redhat.com>> wrote:
>
> On 08/25/2015 01:26 PM, Amitabha Biswas wrote:
> > Russell suggested removing the MYSQL_DRIVER=MySQL-python decla
ue. The networking-ovn git repo has been pretty
quiet 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
ut anything that helps make it clear to people
that it's considered private data (to anything but the API and DB) would
be nice. We should be thinking of the people that are intending to play
nice, and make it so they don't accidentally use something we don't
intend
feature in the API level
> that is transparent to the backend implementation (Multi site OpenStack
> and mixed 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 gener
f
networking primitives that can be potentially implemented by multiple
backends whenever possible. That's the entire point of Neutron. I get
that it's hard, but that's the value Neutron brings to the table.
--
Russell Bryant
__
hat is needed, so that other backends can implement the
same thing.
Luckily, it's being covered by the following effort and once it's in
place, I can remove this prototype hack.
http://specs.openstack.org/openstack/neutron-specs/specs/liberty/vlan-aware-vms.html
--
Russell Bryant
__
us to the author that
> it's not the right way to go. Once we add 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 ar
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
e they should be asked to change.
We can't control what backends not a part of Neutron do, but that's not new.
One example of another project doing something similar is this:
http://specs.openstack.org/openstack/nova-specs/specs/kilo/approved/tag-instances.html
Not
here. It means he gives up some control, but it's
the way the project will scale. Kyle 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
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
> be
s backwards copmatible, too.
--
Russell Bryant
> On Mon, Jul 13, 2015 at 7:33 AM, Russell Bryant <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 any
raded first, which I would expect to be done 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
_
s that would break it sooner. At the moment those jobs have been
blocked pending some re-work of how the partial upgrade jobs work.
As of the last release (Kilo), rolling upgrades from Juno with Neutron
worked when verified manually. I'm hoping we'll have the same for
Liberty, but I'm
networking. This integration uses Neutron to handle IPAM.
http://openvswitch.org/pipermail/dev/2015-June/056669.html
https://github.com/shettyg/ovn-docker
So, there's probably some collaboration opportunity here. Most of it
seems like
On 07/09/2015 09:19 AM, Neil Jerram wrote:
> In the hope of forestalling an unnecessary sub-thread...
>
> Mita was #1 in the vote, so has presumably already been ruled out by
> OpenStack's legal review.
That is correct.
-
1 - 100 of 884 matches
Mail list logo
