[openstack-dev] [Neutron][ovn] networking-ovn-core updates

2017-10-10 Thread Russell Bryant
Hello, everyone.  I'd like to welcome two new members to the
networking-ovn-core team: Miguel Angel Ajo and Yamamoto Takashi.

Miguel has been contributing to Neutron for a long time and was a past
member of the neutron-core team.  He has been focusing on OVN and its
integration with Neutron for the past 6 months or so and has made a great
impact to the project, both networking-ovn and OVN itself.  He helped build
L3 gateway HA support among other things.  He has also been contributing to
reviews for networking-ovn patches.

​Yamamoto Takashi is a long time contributor across several projects,
including both Neutron and OVS.  He's a member of ​neutron-core and more
recently, neutron-drivers.  He's also one of the Open vSwitch project
committers.  Yamamoto has been contributing some reviews to the
networking-ovn repository.  We are thankful for his time and expertise on
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
__
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


Re: [openstack-dev] [ovs-announce] CFP for OpenStack Open Source Days Sydney

2017-09-20 Thread Russell Bryant
On Wed, Sep 20, 2017 at 3:21 PM, Ben Pfaff <b...@ovn.org> wrote:

> In May, the OpenStack Summit graciously offered Open vSwitch use of a
> room for a day of talks, and it worked out great.  For the OpenStack
> Summit in Sydney, which will be held Nov. 6-8, they've again offered us
> time for Open vSwitch related talks, although this time, we only have
> have two 40-minute slots.
>
> If you're interested in speaking in Sydney, please send a title, list of
> speakers, and a brief abstract to ovs...@openvswitch.org by Sept. 27
> (that's only one week away!).  If we receive more quality proposals than
> the two slots allow, we will consider subdividing them into 20-minute
> pieces and we will prioritize talks that relate to OpenStack,
>
> Thanks,
>
> Ben.
> ___
> announce mailing list
> 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.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [openstack] [charms] Openstack with OVN

2017-08-31 Thread Russell Bryant
Just to make sure you saw it - here is the manual installation doc to help
guide you through what needs to be implemented in a project like this.

https://docs.openstack.org/networking-ovn/latest/install/index.html

On Thu, Aug 31, 2017 at 3:39 PM, Aakash Kt <aakash...@gmail.com> wrote:

> Hi James,
> Thanks for the reply. This definitely cleared some thing up for me.
> I would love to get started on this charm soon, and will be sure to drop
> in weekly meeting or ask questions on IRC.
>
> Cheers,
> Aakash
>
>
> On Tue, Aug 29, 2017 at 1:56 PM, James Page <james.p...@ubuntu.com> wrote:
>
>> Hi Aakash
>>
>> On Tue, 29 Aug 2017 at 05:09 Aakash Kt <aakash...@gmail.com> wrote:
>>
>>> Hello all,
>>> Resending this mail since I think there might have been some error
>>> sending it the last time.
>>>
>>>I am looking to develop an openstack bundle which uses OVN as the
>>> SDN. I have been reading : https://docs.openstack.org/c
>>> harm-guide/latest/
>>> I have also read : https://docs.openstack.org/n
>>> etworking-ovn/latest/install/index.html
>>>
>>
>> Awesome; we chatted about this on IRC a few times but put off any
>> concrete work until OVN 2.8.0 is released (soon).
>>
>> As far as I understand, this will require me to replace the
>>> "neutron-openvswitch" charm in the openstack base bundle. However, I am not
>>> able to exactly understand what all I will have to rewrite / replace to
>>> make this work.
>>>
>>
>> I think the new charm work is actually three charms (or maybe two) -
>> neutron-ovn (replacing neutron-openvswitch alongside nova-compute
>> deployments), neutron-api-ovn (providing the API only integration of the
>> Neutron API to OVN), and probably an ovn charm for deployment of OVN
>> itself, with relations  <->  <->  for
>> propagation of configuration in deployments.  The ODL charm set is similar
>> is high level design (neutron-api-odl, odl-controller, openvswitch-odl).
>>
>>
>>> Specifically, I need to make neutron work only as an API instead of the
>>> full blown SDN. Also, in the above doc, its mentioned that we have to run
>>> some setup on "controller nodes". How does the term "controller node" map
>>> to the charm?
>>>
>>
>> Controller nodes are one option for the charms, however components of the
>> controller nodes are deployed inside LXD containers to provide separation
>> between services.  For example, you can dedicated three physical servers
>> and then deploy the nova-cloud-controller, neutron-api, glance, keystone,
>> cinder, ceilometer, heat etc.. charms in LXD containers onto those physical
>> machines.  So in the case of OVN, we'd look to deploy the ovn charm on
>> these same physical servers.
>>
>> Hope that helps explain things a bit; if you want to drop into
>> #openstack-charms to ask more questions please do, or you can join one of
>> our weekly meetings and we can discuss further.  We'd normally start a
>> piece of work like this with a spec (http://specs.openstack.org/op
>> enstack/charm-specs/); this topic is something we could discuss in a bit
>> more detail at the PTG in Denver (I'll add an item to the agenda for the
>> charms room).
>>
>> Cheers
>>
>> James
>>
>>
>> 
>> ______
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> __
> 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
__
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


Re: [openstack-dev] Ocata - Ubuntu 16.04 - OVN does not work with DPDK

2017-04-11 Thread Russell Bryant
t;
>>  But I have no idea about how to use OpenvSwitch with this thing,
>> however, if I can achieve DPDK-Like performance, without DPDK, using just
>> plain Linux, I'm a 100% sure that I'll prefer it!
>>
>>  I'm okay to give OpenvSwitch + DPDK another try, even knowing that it
>> [OVS] STILL have serious problems (https://bugs.launchpad.net/ub
>> untu/+source/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.
>
> I found a opened bug on RedHat's Bugzilla, I updated it with the info from
> this e-mail:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1410565
>
> Looks like that, OVN doc say that it is supported on top of any
> OpenvSwitch Datapath but, it is not the case... Right?
>
> I would be happy to be able to use GENEVE on top of regular Linux
> datapath, and only Provider Networks on top of DPDK but, it also doesn't
> work. I'll post more details about this later.
>
>
​The primary limitation here is that the userspace (DPDK) datapath does not
yet support NAT.  See the datapath feature matrix here:

http://docs.openvswitch.org/en/latest/faq/releases/​
​
​So, indeed, provider networks only is going to the configuration​ that
works with DPDK.  You could do Geneve networks + provider networks,
assuming you set it up so that NAT is not used anywhere.

-- 
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


Re: [openstack-dev] [neutron][networking-l2gw] openstack vtep setup missing docs

2017-04-05 Thread Russell Bryant
On Thu, Mar 30, 2017 at 12:40 PM, Armando M. <arma...@gmail.com> wrote:

> On 30 March 2017 at 08:47, Saverio Proto <saverio.pr...@switch.ch> wrote:
>
>> Hello,
>>
>> I am trying to use the neutron l2gw plugin, but I am not using a bare
>> metal switch to bridge.
>>
>> I am using a server with Openvswitch.
>>
>
> I am not aware of any effort to implement L2GW purely in software, in fact
> this was one key missing pieces that prevented the project to have CI
> solely dealt with the upstream infra resources. Perhaps OVN may come to the
> rescue here, I recall at some point the team was looking at the L2GW API.
>

networking-ovn still does not support the networking-l2gw API.

OVN itself does support two types of L2 gateways.

1) hardware_vtep based gateways.  We do have this exposed through
networking-ovn, but only via an undocumented custom binding:profile.  The
intention was to eventually support the networking-l2gw API, but it hasn't
been prioritized.

https://bugs.launchpad.net/networking-ovn/+bug/1457569

2) Software based L2 gateways.

You can configure OVN to use any host as an L2 gateway.  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 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


Re: [openstack-dev] [Neutron][networking-*] Attention for upcoming refactoring

2016-12-21 Thread Russell Bryant
On Wed, Dec 21, 2016 at 10:50 AM, Anna Taraday <akamyshnik...@mirantis.com>
wrote:

> Hello everyone!
>
> I've got two changes with refactor of TypeDriver [1] and segments db [2]
> which is needed for implementation new engine facade [3].
>
> Reviewers of networking-cisco, networking-arista, networking-nec
> <https://review.openstack.org/#/projects/openstack/networking-nec,dashboards/default>
> , networking-midonet
> <https://review.openstack.org/#/projects/openstack/networking-midonet,dashboards/default>
> , networking-edge-vpn, networking-bagpipe, tricircle, group-based-policy -
> pay attention for [4].
>
> Also recently merged refactor of ml2/db.py [5]. Fixes
> for networking-cisco, networking-cisco, networking-cisco - are on review
> [6]
>
> [1] - https://review.openstack.org/#/c/398873/
> [2] - https://review.openstack.org/#/c/406275/
> [3] - https://blueprints.launchpad.net/neutron/+spec/enginefacade-switch
> [4] - https://review.openstack.org/#/q/topic:segmentsdb
> [5] - https://review.openstack.org/#/c/404714/
> [6] - https://review.openstack.org/#/q/status:open++branch:
> master+topic: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 questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [networking-ovn] OVN native gateway workflow

2016-11-17 Thread Russell Bryant
On Thu, Nov 17, 2016 at 4:23 AM, Michael Kashin <mmkas...@gmail.com> wrote:

> Greetings,
> I'm testing OVN integration with RDO Openstack. I can create tenant
> networks and attach VMs to them with no issues. However I don't get how the
> gateway scheduling works. It seems like whenever I create an external
> provider network and attach it to my DLR, OVN should schedule a gateway
> router and connect it to my DVR via an special transit network. However I
> don't see that happening.
>

​Hi, it looks like you posted this to two mailing lists.  I answered over
on 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 List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [tripleo] Is it time to reconsider how we configure OVS bridges in the overcloud?

2016-11-11 Thread Russell Bryant
On Thu, Nov 10, 2016 at 10:22 AM, Brent Eagles <beag...@redhat.com> wrote:

> To something like:
> (triple configured)
> - eth0
>  - br-ctl - used as br-ex is currently used except neutron knows nothing
> about it.
> - br-ex -patched to br-ctl - ostensibly for external traffic and this is
> what neutron in the overcloud is configured to use
> (neutron configured)
> - br-int
> - br-tun
>
> (In all cases, neutron configures patches, etc. between bridges *it knows
> about* as needed. That is, in the second case, tripleo would configure the
> patch between br-ctl and br-ex)
>
​+1.  I think this configuration makes more sense than the previous
overlapping usage of br-ex.​

> At the cost of an extra bridge (ovs bridge to ovs bridge with patch ports
> is allegedly cheap btw) we get:
>
​Yes, it is cheap.  I would not consider this a concern from a data path
performance point of view.  The separate bridges and patch ports only exist
in userspace.  They don't affect the fast path and the impact to the slow
path is negligible.


>  1. an independently configured bridge for overcloud traffic insulates
> non-tenant node traffic against changes to neutron, including upgrades,
> neutron bugs, etc.
>  2. insulates neutron from changes to the underlying network that it
> doesn't "care" about.
>  3. In OVS only environments, the difference between a single nic
> environment and one where there 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, Brent.

-- 
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


Re: [openstack-dev] [all] Embracing new languages in OpenStack

2016-11-10 Thread Russell Bryant
On Wed, Nov 9, 2016 at 3:14 AM, Chris Dent <cdent...@anticdent.org> wrote:

> On Tue, 8 Nov 2016, Ash wrote:
>
> I couldn't agree more. I don't like change for the sake of change (in any
>> aspect of my life). So in my mind this would have to be a way to better
>> bind us.
>>
>
> Here, have some tortured metaphors:
>
> Something that feels like it gets under-emphasised in this conversation
> is that change is coming whatever we do. As a community we can either
> move quickly and stay ahead of the change and see it as a productive
> development that we can surf or we can dilly dally and get drowned by a
> wave that collapses over us.
>
> Ecosystems must evolve and change because the world evolves and changes.
> If we try to control this stuff too much what we will be doing is taking
> the oxygen out of the system and snuffing the flame of excitement and
> innovation.
>
> As a community we don't want to be bound together by rules, we want
> to be enabled by processes that support making and doing things
> effectively. The things that we make and do is what binds us
> together.
>
> The conversations about additional languages in this community have
> been one our most alarmingly regressive and patronizing. They seem
> to be bred out of fear rather than hope and out of lack of faith in
> each other than in trust. We've got people who want to build stuff.
> Isn't that 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
__
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


Re: [openstack-dev] [ovn] [[l3-agent] connectivity to external network

2016-11-03 Thread Russell Bryant
On Thu, Nov 3, 2016 at 3:31 PM, Murali R <muralir...@gmail.com> wrote:

> The scope of question is using neutron L3 services with OVN. The problem
> is when a router created, there is no implicit internal interface created
> between the router instance and the external bridge.
>

​To be honest, support of the Neutron L3 agent was only a transitional
thing while we bootstrapped OVN.  It was only useful while the
corresponding features were added to OVN.  Once we merge [1], I don't see
any reason to keep support of the L3 agent any longer and plan to remove
support for it and 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 questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [networking-ovn] restart failure to bring up ovn services

2016-11-03 Thread Russell Bryant
On Wed, Nov 2, 2016 at 6:48 PM, Murali R <muralir...@gmail.com> wrote:

> Following the docs online (Newton), the installation was successful.
> However when the VM that has the controller (and ovn-nb) restarted, it
> fails to bring up ovs & ovn. This is ubuntu deployment using
> python-networking-ovn and locally built ovn. Is this a deployment problem?
> Is it possible to recover from here without losing the neutron DB sync? I
> have not configured any networks that I need to save.
>
> NOTE: I did a reboot once before and the services came back fine at that
> time. Not sure if there is a sequence to be followed while shutting down -
> if so can I know what it would be?
>
> Nov  2 15:19:42 controller neutron-server[2715]: 2016-11-02 15:19:42.003
> 3052 ERROR networking_ovn.ovsdb.impl_idl_ovn [-] OVS database connection
> to OVN_Northbound failed with error: 'Could not retrieve schema from tcp:
> 192.168.56.102:6641: Connection refused'. Verify that the OVS and OVN
> services are available and that the 'ovn_nb_connection' and
> 'ovn_sb_connection' configuration options are correct.
> Nov  2 15:19:42 controller neutron-server[2715]: 2016-11-02 15:19:42.003
> 3052 ERROR networking_ovn.ovsdb.impl_idl_ovn Traceback (most recent call
> last):
> Nov  2 15:19:42 controller neutron-server[2715]: 2016-11-02 15:19:42.003
> 3052 ERROR networking_ovn.ovsdb.impl_idl_ovn   File
> "/usr/lib/python2.7/dist-packages/networking_ovn/ovsdb/impl_idl_ovn.py",
> line 84, in __init__
> 
> 
> Nov  2 15:19:42 controller neutron-server[2715]: 2016-11-02 15:19:42.003
> 3052 ERROR networking_ovn.ovsdb.impl_idl_ovn 'err': os.strerror(err)})
> Nov  2 15:19:42 controller neutron-server[2715]: 2016-11-02 15:19:42.003
> 3052 ERROR networking_ovn.ovsdb.impl_idl_ovn Exception: Could not
> retrieve schema from tcp:192.168.56.102:6641: Connection refused
> Nov  2 15:19:42 controller neutron-server[2715]: 2016-11-02 15:19:42.003
> 3052 ERROR networking_ovn.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 can also start it that way
and set it up to re-start after a reboot.

$ sudo systemctl enable ovn-northd
$ sudo systemctl start ovn-northd

-- 
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


Re: [openstack-dev] [Neutron] Neutron team social event in Barcelona

2016-10-17 Thread Russell Bryant
On Friday, October 14, 2016, Miguel Lavalle <mig...@mlavalle.com> wrote:

> Dear Neutrinos,
>
> I am organizing a social event for the team on Thursday 27th at 19:30.
> After doing some Google research, I am proposing Raco de la Vila, which is
> located in Poblenou: http://www.racodelavila.com/en/index.htm. The menu
> is here: http://www.racodelavila.com/en/carta-racodelavila.htm
>
> It is easy to get there by subway from the Summit venue:
> https://goo.gl/maps/HjaTEcBbDUR2. I made a reservation for 25 people
> under 'Neutron' or "Miguel Lavalle". 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
__
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


Re: [openstack-dev] [ovs-discuss] [ovn][neutron] networking-ovn 1.0.0 release (newton) -- port-security

2016-10-12 Thread Russell Bryant
On Tue, Oct 11, 2016 at 2:47 PM, Murali R <muralir...@gmail.com> wrote:

> Hi,
>
> Please clarify if port security is required to be enabled with newton
> release when installing OVN. The install.rst says it must be. In many of my
> use cases I want to disable port security 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 security groups.

-- 
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


Re: [openstack-dev] [tripleo] Feature freeze exception for OVN

2016-09-01 Thread Russell Bryant
On Tue, Aug 30, 2016 at 11:51 AM, Steven Hardy <sha...@redhat.com> wrote:

> On Tue, Aug 30, 2016 at 07:53:07PM +0530, Babu Shanmugam wrote:
> > Hi,
> >
> > The THT patch for OVN [1] has no more dependencies with the recent
> merging
> > of [2]. The changes in heat templates does not have any impact on the
> > existing templates as major of the changes are in new templates and will
> be
> > used only when OVN is enabled.
> >
> > It would be nice to have OVN templates for the upcoming release
> considering
> > that OVN's first official release is due shortly. I am sure [1] will have
> > some review comments and is unlikely to get merged by today, but will
> you be
> > able to consider a freeze exception for this feature.
>
> Considering it's only one patch and disabled by default I think we can, but
> please can you raise a launchpad blueprint for this feature?
>
> I've reviewed the patch previously, but it's slipped off my newton review
> list because it's not tracked in launchpad.
>

​Thanks, Steve.  A blueprint was filed here:

https://blueprints.launchpad.net/tripleo/+spec/tripleo-ovn​



>
> Thanks!
>
> Steve
>
> >
> >
> > Thank you,
> > Babu
> >
> >
> > [1] - https://review.openstack.org/307734
> >
> > [2] - https://review.openstack.org/314875
>
> __
> 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
__
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


Re: [openstack-dev] [Kolla] [Fuel] [tc] Looks like Mirantis is getting Fuel CCP (docker/k8s) kicked off

2016-07-28 Thread Russell Bryant
On Thu, Jul 28, 2016 at 2:20 PM, Jay Pipes <jaypi...@gmail.com> wrote:

> How would guidance from the TC about what it means for a repo to be "part
> of the OpenStack tent" add clarity for repos that are not trying to be part
> of the OpenStack tent?
>
> Just curious 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" instead of "fuel-ccp"?

-- 
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


Re: [openstack-dev] [Kolla] [Fuel] [tc] Looks like Mirantis is getting Fuel CCP (docker/k8s) kicked off

2016-07-28 Thread Russell Bryant
On Thu, Jul 28, 2016 at 10:52 AM, Flavio Percoco <fla...@redhat.com> wrote:

> On 28/07/16 15:48 +0300, Vladimir Kozhukalov wrote:
>
>> 1. Alter the mission statement of fuel to match the reality being
>>>
>>
>> published by the press and Mirantis's executive team
>>>
>>
>> 2. Include these non-experimental repos in the projects.yaml governance
>>>
>>
>> Repository
>>>
>>
>> Frankly, I don’t understand what part of the press release contradicts
>> with
>> Fuel mission.
>>
>> Current Fuel mission is “To streamline and accelerate the process of
>> deploying, testing and maintaining various configurations of OpenStack at
>> scale.” which means we are not bound to any specific technology when
>> deploying OpenStack.
>>
>
> TBH, I also think this statement is broad enough to cover containers.
> Unless the
> request is to explicitly mention "containers" in the mission statement, I
> think
> there's no need to change it. I'd also be against having "containers" being
> explicitly mentioned in Fuel's statement, FWIW. I don't think it'd be of
> any
> benefit/use. Unless I'm missing something fundamental here, of course.


​I agree that the current mission statement seems fine.


>
> At the moment Fuel deploys RPM/DEB packages using Puppet and Fuel specific
>> orchestration mechanism. We are not going to drop this approach
>> immediately, it works quite well and we are working hard to make things
>> better (including ability to upgrade). But we also keep in mind that
>> technologies are constantly changing and we’d like to benefit of this
>> progress. That is why we are now looking at Docker containers and
>> Kubernetes. Our users know that it is not our first experience of trying
>> to
>> use containers. Fuel releases prior to 9.0 used to deploy Fuel services in
>> containers on the Fuel admin node.
>>
>> Many of you know how difficult it is to upgrade OpenStack clusters. We
>> hope
>> that containers could help us to solve not all but some of problems that
>> we
>> encounter when upgrading cluster. Maintaining and hence upgrade of
>> OpenStack clusters is a part of Fuel mission and we are just trying to
>> find
>> a way how to do things.
>>
>> Why not Kolla but Fuel-ccp? It is not a secret that Fuel is driven by
>> Mirantis. At Mirantis we deploy and maintain OpenStack. In attempts to
>> find
>> a way how to make OpenStack easily maintainable, some of Mirantis folks
>> spent some time to contribute to Kolla and Mesos. But there were some
>> concerns that were discussed several times (including this Kolla spec
>> https://review.openstack.org/#/c/330575) that would make it not so easy
>> to
>> use Kolla containers for our use cases. Fuel-ccp is just an attempt to
>> address these concerns. Frankly, I don’t see anything bad in having more
>> than one set of container images (like we have more than one set of
>> RPM/DEB
>> distributions).
>>
>
> ++
>

​I think the project seems fine.  They are clearly aware of Kolla.  If they
don't want to use it (for whatever the reason), I don't think it matters.
OpenStack deployment is far from a well solved problem.  We have plenty of
overlapping deployment related projects and I'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


Re: [openstack-dev] [Neutron][networking-ovn][networking-odl] Syncing neutron DB and OVN DB

2016-07-27 Thread Russell Bryant
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:
>>
>>> > I'd like to see if we can solve the problems more generally.
>>>
>>> We've tried before but we very quickly run into competing requirements
>>> with regards to eventual consistency. For example, asynchronous background
>>> sync doesn't work if someone wants their backend to confirm that port
>>> details are acceptable (e.g. mac isn't in use by some other system outside
>>> of openstack). Then each backend has different methods for detecting what
>>> is out of sync (e.g. config numbers, hashes, or just full syncs on startup)
>>> that each come with their own requirements for how much data needs to be
>>> resent when an inconsistency is detected.
>>>
>>> If we can come to some common ground of what is required by all of them,
>>> then I would love to get some of this built into the ML2 framework.
>>> However, we've discussed this at meetups/mid-cycles/summits and it
>>> inevitably ends up with two people drawing furiously on a whiteboard,
>>> someone crying in the corner, and everyone else arguing about the lack of
>>> parametric polymorphism in Go.
>>>
>>
>> ​Ha, yes, makes sense that this is really hard to solve in a way that
>> works for everyone ...
>> ​
>>
>>
>>> Even between OVN and ODL in this thread, it sounds like the only thing
>>> in common is a background worker that consumes from a queue of tasks in the
>>> db. Maybe realistically the only common thing we can come up with is a
>>> taskflow queue stored in the DB to solve the multiple workers issue...
>>>
>>
>> ​To clarify, ODL has this background worker and the discussion was
>> whether OVN should try to follow a similar approach.
>>
>> So far, my gut feeling is that it's far too complicated for the problems
>> it would solve.  There's one identified multiple-worker related race
>> condition on updates, but I think we can solve that another way.​
>>
>>
> Russell, in fact I think this background worker is the good way to solve
> both problems:
>
> Problem 1. When something failed when updating OVN DB in post-commit: With
> the help of background worker, it can do the retries and the job state can
> be tracked, and with the information proper actions can be taken against
> failure jobs, e.g. cleanups. It is basically a declarative way of
> implementation, which IMHO is a particularly good way in ML2 context,
> because we cannot just rollback Neutron DB changes at failure because it is
> shared by all mech-drivers. (Even in a monolithic plugin, handling the
> partial failures and doing rollback is a big headache).
>
> Problem 2. Race condition because of lack of critical section between
> Neutron DB transaction and post-commit: With the help of journal, the
> ordering is ensured to be the same as DB transaction commits. Protection
> against the journal processing between multiple background workers can be
> properly enforced with the help of DB transaction.
>
> I think ODL and OVN are not the only ones facing these problems. They are
> pretty general to most drivers if not all. It would be great to have a
> common task flow mechanism in ML2, but I'd like to try it in OVN first (if
> no better solution to the problems above).
>

​I had another idea for problem 2, at least.  I posted a more detailed
description of the idea on the bug you posted [1].

This is unrelated to problem 1, though.  I guess I was hoping we could just
come up with a better way of doing rollbacks when necessary.

I also had a long term dream of not using the Neutron DB at all, and only
relying on the OVN database.  That seems much less practical now that we've
moved back to ML2.  Maybe it was a crazy idea, anyway.  :-)

[1] https://bugs.launchpad.net/networking-ovn/+bug/1605089​


​--
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


Re: [openstack-dev] [Neutron][networking-ovn][networking-odl] Syncing neutron DB and OVN DB

2016-07-27 Thread Russell Bryant
On Wed, Jul 27, 2016 at 5:58 AM, Kevin Benton <ke...@benton.pub> wrote:

> > I'd like to see if we can solve the problems more generally.
>
> We've tried before but we very quickly run into competing requirements
> with regards to eventual consistency. For example, asynchronous background
> sync doesn't work if someone wants their backend to confirm that port
> details are acceptable (e.g. mac isn't in use by some other system outside
> of openstack). Then each backend has different methods for detecting what
> is out of sync (e.g. config numbers, hashes, or just full syncs on startup)
> that each come with their own requirements for how much data needs to be
> resent when an inconsistency is detected.
>
> If we can come to some common ground of what is required by all of them,
> then I would love to get some of this built into the ML2 framework.
> However, we've discussed this at meetups/mid-cycles/summits and it
> inevitably ends up with two people drawing furiously on a whiteboard,
> someone crying in the corner, and everyone else arguing about the lack of
> parametric polymorphism in Go.
>

​Ha, yes, makes sense that this is really hard to solve in a way that works
for everyone ...
​


> Even between OVN and ODL in this thread, it sounds like the only thing in
> common is a background worker that consumes from a queue of tasks in the
> db. Maybe realistically the only common thing we can come up with is a
> taskflow queue stored in the DB to solve the multiple workers issue...
>

​To clarify, ODL has this background worker and the discussion was whether
OVN should try to follow a similar approach.

So far, my gut feeling is that it's far too complicated for the problems it
would 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 <rbry...@redhat.com>
> wrote:
>
>>
>>
>> On Fri, Jul 22, 2016 at 7:51 AM, Numan Siddique <nusid...@redhat.com>
>> wrote:
>>
>>> Thanks for the comments Amitabha.
>>> Please see comments inline
>>>
>>> On Fri, Jul 22, 2016 at 5:50 AM, Amitabha Biswas <azbis...@gmail.com>
>>> wrote:
>>>
>>>> Hi Numan,
>>>>
>>>> Thanks for the proposal. We have also been thinking about this use-case.
>>>>
>>>> If I’m reading this accurately (and I may not be), it seems that the
>>>> proposal is to not have any OVN NB (CUD) operations (R operations outside
>>>> the scope) done by the api_worker threads but rather by a new journal
>>>> thread.
>>>>
>>>>
>>> Correct.
>>> ​
>>>
>>>
>>>> If this is indeed the case, I’d like to consider the scenario when
>>>> there any N neutron nodes, each node with M worker threads. The journal
>>>> thread at the each node contain list of pending operations. Could there be
>>>> (sequence) dependency in the pending operations amongst each the journal
>>>> threads in the nodes that prevents them from getting applied (for e.g.
>>>> Logical_Router_Port and Logical_Switch_Port inter-dependency), because we
>>>> are returning success on neutron operations that have still not been
>>>> committed to the NB DB.
>>>>
>>>>
>>> I
>>> ​ts a valid scenario and should be designed properly to handle such
>>> scenarios in case we take this approach.
>>>
>>
>> ​I believe a new table in the Neutron DB is used to synchronize all of
>> the journal threads.
>> ​
>> Also note that OVN currently has no custom tables in the Neutron database
>> and it would be *very* good to keep it that way if we can.
>>
>>
>>>
>>> ​
>>>
>>>> Couple of clarifications and thoughts below.
>>>>
>>>> Thanks
>>>> Amitabha <abis...@us.ibm.com>
>>>>
>>>> On Jul 13, 2016, at 1:20 AM, Numan Siddique <nusid...@redhat.com>
>>>> wrote:
>>>>
>>>> Adding the proper tags in subject
>>>>
>>>> On Wed, Jul 13, 2016 at 1:22 PM, Numan Siddique <nusid...@redhat.com>
>>>> wrote:
>>>>
>>>>> Hi Neutrinos,
>>>>>
>>>>> Presently, In the OVN ML2 driver we have 2 ways to sync neutron DB and
>>>>> OVN DB
>>>>>  - At neutron-server startup, OVN ML2 driver syncs the neutron DB and
>>>>> OVN DB if sync mode is set to repair.
>>>>>  - Admin can run the "neutron-ov

Re: [openstack-dev] [Neutron][networking-ovn][networking-odl] Syncing neutron DB and OVN DB

2016-07-26 Thread Russell Bryant
On Fri, Jul 22, 2016 at 9:37 PM, Zhou, Han <hzh...@ebay.com> wrote:

> However, I didn't figure out how errors are handled with this approach.
> For example, a port is created in Neutron but ODL controller failed to
> create it although the journal thread successfully sent the 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 beginning in ODL.

-- 
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


Re: [openstack-dev] [Neutron][networking-ovn][networking-odl] Syncing neutron DB and OVN DB

2016-07-26 Thread Russell Bryant
;>
>>>
>>> ---
>>>
>>> (1)
>>> Sync threads created by networking-odl ML2 driver
>>> --
>>> ODL ML2 driver creates 2 threads (threading.Thread module) at init
>>>  - Journal thread
>>>  - Maintenance thread
>>>
>>> Journal thread
>>> 
>>> The journal module creates a new journal table by name
>>> “opendaylightjournal”  -
>>> https://github.com/openstack/networking-odl/blob/master/networking_odl/db/models.py#L23
>>>
>>> Journal thread will be in loop waiting for the sync event from the ODL
>>> ML2 driver.
>>>
>>>  - ODL ML2 driver resource (network, subnet, port) precommit functions
>>> when called by the ML2 plugin adds an entry in the “opendaylightjournal”
>>> table with the resource data and sets the journal operation state for this
>>> entry to “PENDING”.
>>>  - The corresponding resource postcommit function of the ODL ML2 plugin
>>> when called, sets the sync event flag.
>>>  - A timer is also created which sets the sync event flag when it
>>> expires (the default value is 10 seconds).
>>>  - Journal thread wakes up, looks into the “opendaylightjournal” table
>>> with the entries with state “pending” and runs the CRUD operation on those
>>> resources in the ODL DB. Once done, it sets the state to “completed”.
>>>
>>> Maintenance thread
>>> --
>>> Maintenance thread does 3 operations
>>>  - JournalCleanup - Delete completed rows from journal table
>>> “opendaylightjournal”.
>>>  - CleanupProcessing - Mark orphaned processing rows to pending.
>>>  - Full sync - Re-sync when detecting an ODL "cold reboot”.
>>>
>>>
>>>
>>> Thanks
>>> Numan
>>>
>>>
>> __
>> 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
>>
>>
>>
>> __
>> 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
>>
>>
>
> __
> 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
__
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


Re: [openstack-dev] [puppet] Request to add puppet-dpdk module

2016-07-07 Thread Russell Bryant
On Thu, Jul 7, 2016 at 5:12 AM, Saravanan KR <skram...@redhat.com> wrote:

> Hello,
>
> We are working on blueprint [1] to integrate DPDK with tripleo. In the
> process, we are planning to add a new puppet module "puppet-dpdk" for the
> required puppet changes.
>
> The initial version of the repository is at github [2]. Note that the
> changes are
> ​not ​
> complete yet. It is in progress.
>
> Please let us know your views on including this new module.
>
> Regards,
> Saravanan KR
> ​
>
> [1] https://blueprints.launchpad.net/tripleo/+spec/tripleo-ovs-dpdk
> [2] https://github.com/krsacme/puppet-dpdk
>

​I took a quick look at Emilien's request.  In general, including this
functionality in the puppet openstack project makes sense to me.

It looks like this is installing and configuring openvswitch-dpdk.  Have
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)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [neutron][networking-ovn] OVN vs. OpenDayLight

2016-06-10 Thread Russell Bryant
On Fri, Jun 10, 2016 at 11:11 AM, Oleg Bondarev <obonda...@mirantis.com>
wrote:

> Hi,
>
> [1] is a doc comparing OVN and ODL for Neutron. I wrote it in March so
> some info might be stale.
> Hope this can be useful, comments are welcome!
>
> [1]
> https://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
__
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


Re: [openstack-dev] [OpenStack Foundation] [board][tc][all] One Platform – Containers/Bare Metal? (Re: Board of Directors Meeting)

2016-04-11 Thread Russell Bryant
On Mon, Apr 11, 2016 at 11:30 AM, Monty Taylor <mord...@inaugust.com> wrote:

> On 04/11/2016 09:43 AM, Allison Randal wrote:
>
>> On Wed, Apr 6, 2016 at 1:11 PM, Davanum Srinivas <dava...@gmail.com>
>>> wrote:
>>>
>>>> Reading unofficial notes [1], i found one topic very interesting:
>>>> One Platform – How do we truly support containers and bare metal under
>>>> a common API with VMs? (Ironic, Nova, adjacent communities e.g.
>>>> Kubernetes, Apache Mesos etc)
>>>>
>>>> Anyone present at the meeting, please expand on those few notes on
>>>> etherpad? And how if any this feedback is getting back to the
>>>> projects?
>>>>
>>>
>> It was really two separate conversations that got conflated in the
>> summary. One conversation was just being supportive of bare metal, VMs,
>> and containers within the OpenStack umbrella. The other conversation
>> started with Monty talking about his work on shade, and how it wouldn't
>> exist if more APIs were focused on the way users consume the APIs, and
>> less an expression of the implementation details of each project.
>> OpenStackClient was mentioned as a unified CLI for OpenStack focused
>> more on the way users consume the CLI. (OpenStackSDK wasn't mentioned,
>> but falls in the same general category of work.)
>>
>> i.e. There wasn't anything new in the conversation, it was more a matter
>> of the developers/TC members on the board sharing information about work
>> that's already happening.
>>
>
> I agree with that - but would like to clarify the 'bare metal, VMs and
> containers' part a bit. (an in fact, I was concerned in the meeting that
> the messaging around this would be confusing because we 'supporting bare
> metal' and 'supporting containers' mean two different things but we use one
> phrase to talk about it.
>
> It's abundantly clear at the strategic level that having OpenStack be able
> to provide both VMs and Bare Metal as two different sorts of resources
> (ostensibly but not prescriptively via nova) is one of our advantages. We
> wanted to underscore how important it is to be able to do that, and wanted
> to underscore that so that it's really clear how important it is any time
> the "but cloud should just be VMs" sentiment arises.
>
> The way we discussed "supporting containers" was quite different and was
> not about nova providing containers. Rather, it was about reaching out to
> our friends in other communities and working with them on making OpenStack
> the best place to run things like kubernetes or docker swarm. Those are
> systems that ultimately need to run, and it seems that good integration
> (like kuryr with libnetwork) can provide a really strong story. 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 for
> each one.
>

I was there and agree with the summary provided by Allison and Monty.

It's important to have some high level alignment on where we see our core
strengths and where we see ourselves as complementary and not competitive.
I don't think any of it was new information, but valuable to revisit
nonetheless.

-- 
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


Re: [openstack-dev] [all][stackalytics] Gaming the Stackalytics stats

2016-04-11 Thread Russell Bryant
On Mon, Apr 11, 2016 at 6:48 AM, Ihar Hrachyshka <ihrac...@redhat.com>
wrote:

> Clint Byrum <cl...@fewbar.com> wrote:
>
> Excerpts from Morgan Fainberg's message of 2016-04-10 16:47:28 -0700:
>>
>>> On Sun, Apr 10, 2016 at 4:37 PM, Clint Byrum <cl...@fewbar.com> wrote:
>>>
>>> Excerpts from Matt Riedemann's message of 2016-04-09 06:42:54 -0700:
>>>>
>>>>> There is also disincentive in +1ing a change that you don't understand
>>>>> and is wrong and then a core comes along and -1s it (you get dinged for
>>>>> the disagreement). And there is disincentive in -1ing a change for the
>>>>> wrong reasons (silly nits or asking questions for understanding). I ask
>>>>> a lot of questions in a lot of changes and I don't vote on those
>>>>> because
>>>>> it would be inappropriate.
>>>>>
>>>>
>>>> Why is disagreement a negative thing? IMO, reviewers who agree too much
>>>> are just part of the echo chamber.
>>>>
>>> There is no problem with disagreement IMHO. However, we track it as a
>>> stat,
>>> and people don't want to feel as though they are in disagreement with the
>>> cores. I think this is just some level of psychology.
>>>
>>> I very, very rarely look at disagreement stat for anything (now or when I
>>> was PTL).
>>>
>>
>> Agreed, as a number, it can be highly misleading and is especially hard
>> to compare to any of the other numbers.
>>
>> However, in meta-reviews, I found actual occurrences very useful to
>> analyze how a reviewer handles confronting the other cores and how
>> confident they are in their understanding of the code base. So it worries
>> me that new people might be somehow discouraged from disagreement.
>>
>> So let me just say it here, disagreeing with the core reviewers when
>> there is a valid reason _is what somebody who wants to be a core reviewer
>> should be doing_.
>>
>
> Amen to that! I find that people who have higher disagreement stats are
> actually the people that add value to review process, since they obviously
> look at patches from perspectives that are different from existing core
> members.
>
> Now, I agree that if the disagreements are solely for nits in commit
> messages or random misunderstandings, then it’s not of value. But if those
> are legit concerns, that’s usually a good sign, not a bad one.
>

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 overly eager +1
reviewers (lots of reviews for stats, missing lots of errors).  Maybe it
hasn't proved to be that valuable.

​I haven't looked at how stackalytics implements it, though.

​[1] http://git.openstack.org/cgit/openstack-infra/reviewstats
[2]​ http://www.russellbryant.net/openstack-stats/

-- 
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


Re: [openstack-dev] [all][elections] Results of the TC Election

2016-04-08 Thread Russell Bryant
On Fri, Apr 8, 2016 at 8:35 AM, Eoghan Glynn <egl...@redhat.com> wrote:

>
>
> > > Please join me in congratulating the 7 newly elected members of the TC.
> > >
> > > <<<<<< REMOVE UNEEDED >>>>>
> > > * Davanum Srinivas (dims)
> > > * Flavio Percoco (flaper87)
> > > * John Garbutt (johnthetubaguy)
> > > * Matthew Treinish (mtreinish)
> > > * Mike Perez (thingee)
> > > * Morgan Fainberg (morgan)/(notmorgan)
> > > * Thierry Carrez (ttx)
> > >
> > > Full results:
> > > http://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_fef5cc22eb3dc27a
> > >
> > > Thank you to all candidates who stood for election, having a good
> group of
> > > candidates helps engage the community in our democratic process.
> > >
> > > Thank you to all who voted and who encouraged others to vote. We need
> to
> > > ensure
> > > your voice is heard.
> > >
> > > Thank you for another great round.
> > >
> > > Here's to Newton!
> >
> > Thanks Tony for efficiently running this election, congrats to
> > the candidates who prevailed, and thanks to everyone who ran
> > for putting themselves out there.
> >
> > It was the most open race since the pattern of TC 2.0 half-
> > elections was established, which was great to see.
> >
> > However, the turnout continues to slide, dipping below 20% for
> > the first time:
> >
> >  Election | Electorate (delta %) | Votes | Turnout (delta %)
> >  ===
> >  Oct '16  | 1106 | 342   | 30.92
> >  Apr '14  | 1893   (+71.16)  | 506   | 26.73   (-13.56)
> >  Apr '15  | 2169   (+14.58)  | 548   | 25.27   (-5.48)
> >  Oct '15  | 2759   (+27.20)  | 619   | 22.44   (-11.20)
> >  Apr '16  | 3284   (+19.03)  | 652   | 19.85   (-11.51)
>
> Meh, I screwed up that table, not enough coffee yet today :)
>
> Should be:
>
>   Election | Electorate (delta %) | Votes | Turnout (delta %)
>   ===
>   Oct '13  | 1106 | 342   | 30.92
>   Apr '14  | 1510   (+36.52)  | 448   | 29.69   (-4.05)
>   Oct '14  | 1893   (+25.35)  | 506   | 26.73   (-9.91)
>   Apr '15  | 2169   (+14.58)  | 548   | 25.27   (-5.48)
>   Oct '15  | 2759   (+27.20)  | 619   | 22.44   (-11.20)
>   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


Re: [openstack-dev] [neutron] OVSDB native interface as default in gate jobs

2016-04-05 Thread Russell Bryant
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
> >> (ovs-vsctl vs ovs-ofctl) that speak two different protocols (OVSDB vs
> >> OpenFlow) that talk to two different daemons on the system
> (ovsdb-server vs
> >> ovs-vswitchd) ?
> >
> > True, they influence two different daemons - but it's really two options
> > that both have two settings:
> >
> > * "talk to it via the CLI tool"
> > * "talk to it via a native interface"
> >
> > How likely is it to have one talking via native interface and the other
> > via CLI?
>
> The ovsdb native interface is a couple of cycles more mature than the
> openflow one, I see how some users would use one but not the other.


​and they use separate Python libraries, as well (ovs vs ryu).



>
> >
> > Also, if the native interface is faster, I think we should consider
> > making it the default.
>
> Definitely. I'd prefer to deprecate and delete the cli interfaces and
> keep only the native interfaces in the long run.
>

​+1.

-- 
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


Re: [openstack-dev] [neutron] OVSDB native interface as default in gate jobs

2016-04-04 Thread Russell Bryant
On Mon, Apr 4, 2016 at 5:32 PM, Sean M. Collins <s...@coreitpro.com> wrote:

> Inessa Vasilevskaya wrote:
> > different configurations of of_interface and ovsdb_interface options
> > (dsvm-fullstack [2] and rally tests are by now all I can think of).
>
> Wait, we have *two* different configuration options???
>
> WHY WHY WHY
>

​because they are related to two different command line utilities
(ovs-vsctl vs ovs-ofctl) that speak two different protocols (OVSDB vs
OpenFlow) that talk to two different daemons on the system (ovsdb-server vs
ovs-vswitchd) ?

With 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 questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Neutron][networking-ovn] Changing OVN plugin release model for Newton

2016-04-04 Thread Russell Bryant
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
> > "release:independent" [1], though we haven't actually made any releases.
> > This follows the state of OVN itself, which is still fast moving and
> > developed in OVS master.
> >
> > On the OVN side, we're now targeting a first production release in time
> for
> > the OpenStack Newton release.  We aim to branch OVS (which includes OVN)
> in
> > July and release by September or so.
> >
> > I think it's time to start making releases of the Neutron plugin.  I
> suggest
> > we adopt "release:cycle-with-milestones" [2] to match the primary Neutron
> > repositories.
> >
> > Thoughts?
> >
> +1, this makes sense to me. As you say, the eminent release of an OVN
> release itself should trigger changes in the release model for the
> plugin as well.
>
> Are you going to propose a governance patch to reflect this?
>

​Thanks, Kyle.  I just wanted to raise awareness of the proposed change
first.

https://review.openstack.org/301325

-- 
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


[openstack-dev] [Neutron][networking-ovn] Changing OVN plugin release model for Newton

2016-04-04 Thread Russell Bryant
Hello, everyone.

While bootstrapping networking-ovn, the release model has been
"release:independent" [1], though we haven't actually made any releases.
This follows the state of OVN itself, which is still fast moving and
developed in OVS master.

On the OVN side, we're now targeting a first production release in time for
the OpenStack Newton release.  We aim to branch OVS (which includes OVN) in
July and release by September or so.

I think it's time to start making releases of the Neutron plugin.  I
suggest we adopt "release:cycle-with-milestones" [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
__
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


Re: [openstack-dev] [neutron] OVSDB native interface as default in gate jobs

2016-03-30 Thread Russell Bryant
On Tue, Mar 29, 2016 at 10:34 PM, Kevin Benton <ke...@benton.pub> wrote:

> I'm not aware of any issues. Perhaps you can propose a patch to just
> change the default in Neutron to that interface and people can -1 if there
> are any concerns.
>

FWIW, the ovs Python library lacked Python 3 support until very recently.
I finished it and have it all merged into ovs master, but it won't be in an
official release until just before the Newton release (based on the current
rough plan).  In the meantime, there's a dev snapshot on PyPI that includes
it (2.6.0.dev1).​


​I'm 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


Re: [openstack-dev] [networking-ovn][Neutron] OVN support for routed networks(plugin interface for host mapping)

2016-03-29 Thread Russell Bryant
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 Southbound
>> DB, do you meant that neutron plugin can read those bridge mappings from
>> the OVN Southbound DB? I didn't think in that way because I thought
>> networking-ovn will only transact data with OVN Northbound DB.
>>
>
> ​You're right that networking-ovn currently only uses the OVN northbound
> DB.  This requirement crosses the line into physical space and needing to
> know about some physical environment details, so reading from the
> southbound DB for this info is acceptable.​
> ​
>
>> Also, do you have any link to describe the ongoing work in OVN to sync the
>> "ovn-bridge-mapping" from hypervisor?
>
>
> ​This patch introduces some new tables to the southbound DB:
>
> http://openvswitch.org/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 southbound database.  How quickly
> is this needed?
>

​This is now ready.

The Chassis table in OVN_Southbound now has

1) a hostname column

2) an external_ids column, including an ovn-bridge-mappings key.

Between those two, I think the Neutron plugin has all of the info it needs.

Let me know if you think of anything else that is missing.​


-- 
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


Re: [openstack-dev] [docs] Our Install Guides Only Cover Defcore - What about big tent?

2016-03-23 Thread Russell Bryant
On Wed, Mar 23, 2016 at 11:06 AM, Mike Perez <thin...@gmail.com> wrote:

> Hey all,
>
> I've been talking to a variety of projects about lack of install guides.
> This
> came from me not having a great experience with trying out projects in the
> big
> tent.
>
> Projects like Manila have proposed install docs [1], but they were rejected
> by the install docs team because it's not in defcore. One of Manila's
> goals of
> getting these docs accepted is to apply for the operators tag
> ops:docs:install-guide [2] so that it helps their maturity level in the
> project
> navigator [3].
>
> Adrian Otto expressed to me having the same issue for Magnum. I think it's
> funny that a project that gets keynote time at the OpenStack conference
> can't
> be in the install docs personally.
>
> As seen from the Manila review [1], the install docs team is suggesting
> these
> to be put in their developer guide.
>
> I don't think this is a great idea. Mainly because they are for developers,
> operators aren't going to be looking in there for install information.
> Also the
> Developer doc page [4] even states "This page contains documentation for
> Python
> developers, who work on OpenStack itself".
>
> The install docs team doesn't want to be swamped with everyone in big tent
> giving them their install docs, to be verified, and eventually likely to be
> maintained by the install docs team.
>
> However, as an operator when I go docs.openstack.org under install guides,
> I should know how to install any of the big tent projects. These are
> accepted
> projects by the Technical Committee.
>
> Lets consider the bigger picture of things here. If we don't make this
> information accessible, projects have poor adoption and get less feedback
> because people can't attempt to install them to begin reporting bugs.
>
> Proposal: if the install docs team doesn't want them in the install docs
> repo
> and instead to live in tree of the project itself before it's in defcore,
> can
> we at least make the install guides for all big tent projects accessible
> at docs.openstack.org under install guides?
>
>
> [1] - https://review.openstack.org/#/c/213756/
> [2] -
> http://git.openstack.org/cgit/openstack/ops-tags-team/tree/descriptions/ops-docs-install-guide.rst
> [3] - http://www.openstack.org/software/releases/liberty/components/manila
> [4] - http://docs.openstack.org/developer/openstack-projects.html
>

​FWIW, the same issue applies to other official docs.  In particular, I'm
thinking of the networking guide.

http://docs.openstack.org/liberty/networking-guide/

The networking guide is *fantastic*, but it's limited to covering only
ML2+OVS and ML2+LB.  Coverage for other backends is currently considered
out of scope, leaving 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.html

​It'd be nice to have somewhere else to publish these operator-oriented
docs.

-- 
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


Re: [openstack-dev] [networking-ovn][ovn4nfv]

2016-03-21 Thread Russell Bryant
On Mon, Mar 21, 2016 at 5:18 PM, John McDowall <
jmcdow...@paloaltonetworks.com> wrote:

> All,
>
> As a VNF vendor we have been looking at ways to enable customers to simply
> scale up (and down) VNF’s in complex virtual networks at scale. Our goal
> is to help accelerate the deployment of SDN and VNF’s and more
> specifically enable zero-trust security at scale for applications.  This
> requires the easy and fast deployment of Next Generation Firewalls (and
> other VNF¹s) into the traffic path of any application.
>

​Thanks a lot for your work on this!  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 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


Re: [openstack-dev] [networking-ovn][Neutron] OVN support for routed networks(plugin interface for host mapping)

2016-03-21 Thread Russell Bryant
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 Southbound
> DB, do you meant that neutron plugin can read those bridge mappings from
> the OVN Southbound DB? I didn't think in that way because I thought
> networking-ovn will only transact data with OVN Northbound DB.
>

​You're right that networking-ovn currently only uses the OVN northbound
DB.  This requirement crosses the line into physical space and needing to
know about some physical environment details, so reading from the
southbound DB for this info is acceptable.​
​

> Also, do you have any link to describe the ongoing work in OVN to sync the
> "ovn-bridge-mapping" from hypervisor?


​This patch introduces some new tables to the southbound DB:

http://openvswitch.org/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 southbound database.  How quickly
is this needed?

-- 
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


Re: [openstack-dev] [networking-ovn][Neutron] OVN support for routed networks(plugin interface for host mapping)

2016-03-19 Thread Russell Bryant
On Tue, Mar 15, 2016 at 7:02 PM, Hong Hui Xiao <xiaoh...@cn.ibm.com> wrote:

> Hi all.
>
> I did some investigation recently. And I think we can start some
> discussion now.
>
> All below thinking is based on the current implementation of neutron. With
> routed network, a subnet will be considered as a L2 domain. Things might
> change.
>
> I think routed network in OVN can implement in this way:
> User creates provider network. For example:
> neutron net-create provider-101 --shared \
> --provider:physical_network providernet \
> --provider:network_type vlan \
> --provider:segmentation_id 101
>
> These attributes "--provider:physical_network" will be recorded in the
> external_ids of Logical_Switch in OVN_Northbound.
>


>
>
> To Russell:
> I will expect OVN to do the following things.
> 1) The OVN_Southbound will have the latest information of
> "ovn-bridge-mappings" of each Chassis.
> 2) After creating a new network with "provider:physical_network" set, the
> OVN will update Logical_Switch in OVN_Northbound.
> The Logical_Switch will have new key:value pair in external_ids.
> neutron:available_hosts="compute-host1,compute-host2"
> 3) When a compute host join/leave the OpenStack topology, or a compute
> host just updates its ovn-bridge-mappings, OVN should updated
> Logical_Switch with related physical_network. This is a bottom-up change,
> which is similar to the port status change.
> 4) networking-ovn should be able to catch the update of Logical_Switch in
> 2) & 3) and update the SegmentHostMapping, which will be introduced in
> [2].
>
> I think 1) 2) & 3) need additional work in OVN code. And 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 mappings from the OVN database and have all of the information it
needs.​

-- 
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


[openstack-dev] [Kuryr] Clarification of expanded mission statement

2016-03-19 Thread Russell Bryant
The Kuryr project proposed an update to its mission statement and I agreed
to start a ML thread seeking clarification on the update.

https://review.openstack.org/#/c/289993

The change expands the current networking focus to also include storage
integration.

I was interested to learn more about what work you expect to be doing.  On
the networking side, it's clear to me: a libnetwork plugin, and now perhaps
a CNI plugin.  What specific code do you expect to deliver as a part of
your expanded scope?  Will that code be in Kuryr, or be in upstream
projects?

If you don't know yet, that'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 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


Re: [openstack-dev] [networking-ovn][devstack] devstack deoloyed with networking-ovn come accross error 'ovs-ofctl: br-int is not a bridge or a socket'

2016-03-14 Thread Russell Bryant
On Mon, Mar 14, 2016 at 4:36 AM, Wilence Yao <wilence@gmail.com> wrote:

> Hello all,
>
> I am going to deploye devstakv with networking-ovn, and I am following
> with  the doc
> http://docs.openstack.org/developer/networking-ovn/testing.html
>
> However, error occured in running stack.sh.
>
> Traceback below here:
>
> 2016-03-14 08:14:44.729 | cd datapath/linux && make modules_install
> 2016-03-14 08:14:44.735 | make[1]: Entering directory
> `/opt/stack/ovs/datapath/linux'
> 2016-03-14 08:14:44.735 | make -C
> /lib/modules/3.10.0-327.10.1.el7.x86_64/build
> M=/opt/stack/ovs/datapath/linux modules_install
> 2016-03-14 08:14:45.079 | make[2]: Entering directory
> `/usr/src/kernels/3.10.0-327.10.1.el7.x86_64'
> 2016-03-14 08:14:45.098 |   INSTALL
> /opt/stack/ovs/datapath/linux/openvswitch.ko
> 2016-03-14 08:14:45.148 | Can't read private key
> 2016-03-14 08:14:45.151 |   INSTALL
> /opt/stack/ovs/datapath/linux/vport-geneve.ko
> 2016-03-14 08:14:45.183 | Can't read private key
> 2016-03-14 08:14:45.186 |   INSTALL
> /opt/stack/ovs/datapath/linux/vport-gre.ko
> 2016-03-14 08:14:45.218 | Can't read private key
> 2016-03-14 08:14:45.220 |   INSTALL
> /opt/stack/ovs/datapath/linux/vport-lisp.ko
> 2016-03-14 08:14:45.248 | Can't read private key
> 2016-03-14 08:14:45.250 |   INSTALL
> /opt/stack/ovs/datapath/linux/vport-stt.ko
> 2016-03-14 08:14:45.278 | Can't read private key
> 2016-03-14 08:14:45.281 |   INSTALL
> /opt/stack/ovs/datapath/linux/vport-vxlan.ko
> 2016-03-14 08:14:45.309 | Can't read private key
> 2016-03-14 08:14:45.322 |   DEPMOD  3.10.0-327.10.1.el7.x86_64
> 2016-03-14 08:14:45.668 | make[2]: Leaving directory
> `/usr/src/kernels/3.10.0-327.10.1.el7.x86_64'
> 2016-03-14 08:14:45.669 | depmod `sed -n 's/#define UTS_RELEASE
> "\([^"]*\)"/\1/p'
> /lib/modules/3.10.0-327.10.1.el7.x86_64/build/include/generated/utsrelease.h`
> 2016-03-14 08:14:45.986 | make[1]: Leaving directory
> `/opt/stack/ovs/datapath/linux'
> 2016-03-14 08:14:46.007 | modprobe: FATAL: Module openvswitch is in use.
> 2016-03-14 08:14:46.009 | Error on exit
> 2016-03-14 08:14:46.487 | ovs-vsctl:
> unix:/usr/local/var/run/openvswitch/db.sock: database connection failed (No
> such file or directory)
> 2016-03-14 08:14:46.498 | ovs-ofctl: br-int is not a bridge or a socket
> 2016-03-14 08:14:46.508 | ovs-ofctl: br-tun is not a bridge or a socket
> 2016-03-14 08:14:46.518 | ovs-ofctl: br-ex is not a bridge or a socket
> 2016-03-14 08:14:46.529 | ovs-ofctl: br-int is not a bridge or a socket
> 2016-03-14 08:14:46.540 | ovs-ofctl: br-tun is not a bridge or a socket
> 2016-03-14 08:14:46.551 | ovs-ofctl: br-ex is not a bridge or a socket
>
> I know that in this process , stack.sh will install openvswitch when
> processing neutron, then it will uninstall openvswitch and make && make
> install openvswitch from ovs code source again.
>

​Yes, I've wanted to figure out a way to prevent ovs from being installed
by package, but haven't done it yet.  We should probably file a bug on it
against networking-ovn.
​


>
> Because of uninstalling of openvswitch, br-int and other brigeds loss from
> ovs, so the new ovn process come accross the error that no bridges
> br-int/br-ex/br-tun.
>
> Is this a networking-ovn bug or a devstack bug?
>

​Please file a bug against networking-ovn for your 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 to fix it.  Ideally we should set up a CI job 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


Re: [openstack-dev] [tripleo] Logo for TripleO

2016-03-11 Thread Russell Bryant
On Fri, Mar 11, 2016 at 4:15 AM, Dmitry Tantsur <dtant...@redhat.com> wrote:

> On 03/11/2016 06:32 AM, Jason Rist wrote:
>
>> Hey everyone -
>> We've been working on a UI for TripleO for a few months now and
>> we're
>> just about to beg to be a part of upstream... and we're in need of a
>> logo for the login page and header.
>>
>> In my evenings, I've come up with a logo.
>>
>> It's a take on the work that Dan has already done on the Owl idea:
>> http://wixagrid.com/tripleo/tripleo_svg.html
>>
>
> 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​
__
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


Re: [openstack-dev] [all] A proposal to separate the design summit

2016-02-22 Thread 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.

-- 
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


Re: [openstack-dev] [tacker][networking-sfc] Tacker VNFFG - SFC integration updates

2016-02-17 Thread Russell Bryant
On 02/16/2016 02:51 PM, Sridhar Ramaswamy wrote:
> Hi folks,
> 
> Based on the recent discussions in [1] & [2] we are proposing to
> rearrange our tasks related to Tacker's VNFFG component integrating with
> the lower level SFC APIs. We now plan to integrate with networking-sfc
> APIs first.
> 
> Our original plan, or rather the sequence of tasks, were,
> 
> 1) Tacker VNFFG plugin (trozet)
> 2) Tacker VNFFG plugin --> ODL/netvirtsfc driver backend (trozet)
> 3) Tacker VNFFG plugin --> networking-sfc driver backend (s3wong)
> 4) networking-sfc --> ODL/netvirtsfc driver backend (TBD)
> 
> We now propose to alter the sequence of tasks to something like this,
> 
> 1) Tacker VNFFG plugin (trozet)
> 2) Tacker VNFFG plugin --> networking-sfc driver backend (s3wong) -
> /that is, introduce this as the first driver backend for Tacker VNFFG
> instead of direct ODL/netvirtsfc driver/
> 3) Use the code written by Tim (trozet) for Tacker's ODL/netvirtsfc
> driver backend and help to further networking-sfc's ODL integration efforts.
> 
> Quick note on (3) above, networking-sfc already has a driver for ONOS
> SDN Controller [3]. So it should reasonably easy to bring in a ODL
> driver for networking-sfc. This might be slightly longer than what we
> ideally wanted for some short-term PoCs but it positions us to get the
> eventual end goal faster.

What other backends would 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 questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Neutron] Evolving the stadium concept

2016-02-05 Thread Russell Bryant
On 02/05/2016 10:36 AM, Neil Jerram wrote:
> As some others have said, I see the current discussion as being about
> the chain of accountability, from a stadium project, through Neutron, up
> to the OpenStack TC and board.  IIUC, Armando and other cores feel that
> there is a gap there - because they can't reasonably understand and
> vouch for all the stadium projects to the same standard they can for
> core Neutron.  Plus it seems (from the current
> https://review.openstack.org/#/c/275888/9 text) that there is a desire
> for strong core team overlap between openstack/neutron and all Neutron
> stadium projects.
> 
> As the lead of networking-calico, I think it's a reasonable call to say
> that networking-calico (and similar projects) should therefore be
> OpenStack big tent projects, rather than Neutron stadium, and hence the
> reviews 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 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


Re: [openstack-dev] [all] [tc] "No Open Core" in 2016

2016-02-05 Thread Russell Bryant
On 02/05/2016 05:57 AM, Thierry Carrez wrote:
> Hi everyone,
> 
> Even before OpenStack had a name, our "Four Opens" principles were
> created to define how we would operate as a community. The first open,
> "Open Source", added the following precision: "We do not produce 'open
> core' software". What does this mean in 2016 ?
> 
> Back in 2010 when OpenStack was started, this was a key difference with
> the other open source cloud platform (Eucalyptus) which was following an
> Open Core strategy with a crippled community edition and an "enterprise
> version". OpenStack was then the property of a single entity
> (Rackspace), so giving strong signals that we would never follow such a
> strategy was essential to form a real community.
> 
> Fast-forward today, the open source project is driven by a non-profit
> independent Foundation, which could not even do an "enterprise edition"
> if it wanted to. However, member companies build "enterprise products"
> on top of the Apache-licensed upstream project. And we have drivers that
> expose functionality in proprietary components. So what does it mean to
> "not do open core" in 2016 ? What is acceptable and what's not ? It is
> time for us to refresh this.

Nice summary.  I agree that some clarification would be helpful given to
match our current reality.

> My personal take on that is that we can draw a line in the sand for what
> is acceptable as an official project in the upstream OpenStack open
> source effort. It should have a fully-functional, production-grade open
> source implementation. If you need proprietary software or a commercial
> entity to fully use the functionality of a project or getting serious
> about it, then it should not be accepted in OpenStack as an official
> project. It can still live as a non-official project and even be hosted
> under OpenStack infrastructure, but it should not be part of
> "OpenStack". That is how I would interpret "no open core" in OpenStack
> 2016.
> 
> Of course, the devil is in the details, especially around what I mean by
> "fully-functional" and "production-grade". Is it just an API/stability
> thing, or does performance/scalability 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 some desirable traits like you have done, and then leave it to
the TC to evaluate.  I think that's a reasonable part of the TC's job.

-- 
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


Re: [openstack-dev] [Neutron] Evolving the stadium concept

2016-02-04 Thread Russell Bryant
On 02/04/2016 05:36 PM, Assaf Muller wrote:
> On Thu, Feb 4, 2016 at 5:55 PM, Sean M. Collins <s...@coreitpro.com> wrote:
>> On Thu, Feb 04, 2016 at 04:20:50AM EST, Assaf Muller wrote:
>>> I understand you see 'Dragonflow being part of the Neutron stadium'
>>> and 'Dragonflow having high visibility' as tied together. I'm curious,
>>> from a practical perspective, how does being a part of the stadium
>>> give Dragonflow visibility? If it were not a part of the stadium and
>>> you had your own PTL etc, what specifically would change so that
>>> Dragonflow would be less visible.
>>
>>> Currently I don't understand why
>>> being a part of the stadium is good or bad for a networking project,
>>> or why does it matter.
>>
>>
>> I think the issue is of public perception.
> 
> That's what I was trying to point out. But it must be something other
> than perception, otherwise we could remove the inclusion list
> altogether. A project would not be in or out.

There has to be a list somewhere.  That's how OpenStack governance
works.  We have project 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 worked, so it's time for another iteration.

-- 
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


Re: [openstack-dev] [Neutron] Evolving the stadium concept

2016-02-03 Thread Russell Bryant
On 11/30/2015 07:56 PM, Armando M. wrote:
> I would like to suggest that we evolve the structure of the Neutron
> governance, so that most of the deliverables that are now part of the
> Neutron stadium become standalone projects that are entirely
> self-governed (they have their own 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

-- 
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


Re: [openstack-dev] [neutron] Testing Neutron with latest OVS

2016-01-15 Thread Russell Bryant
On 01/14/2016 08:04 PM, Jeremy Stanley wrote:
> On 2016-01-14 22:14:09 + (+), Sean M. Collins wrote:
> [...]
>> The problem we have is - most operators are using Ubuntu according to
>> the user survey. Most likely they are using LTS releases. We already get
>> flack for our pace of releases and our release lifecycle duration, so
>> if we were to move off LTS for our gate, we would be pushing operators
>> to move to more frequent upgrades for their base operating system. Maybe
>> that's a discussion that needs to be had, but it will be contentious.
> 
> As a point of reference, the OpenStack Infrastructure team only uses
> LTS distro releases to run production systems. We've also got a
> modest sized OpenStack deployment on its way to production, again on
> an LTS distro release. I agree that releasing server software 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

__
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


Re: [openstack-dev] [neutron] Testing Neutron with latest OVS

2016-01-14 Thread Russell Bryant
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 module from the ovs
> source tree and just compile it against the stock ubuntu kernel
> (assuming the kernel devel headers are available) is that right?

It's kernel and userspace.  There's multiple current development
efforts that involve changes to OpenStack, OVS userspace, and the
appropriate datapath (OVS kernel module or DPDK).

The consensus I'm picking up roughly is that for those working on the
features, 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 that important anyway.

-- 
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


Re: [openstack-dev] [neutron] Testing Neutron with latest OVS

2016-01-14 Thread Russell Bryant
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 you can get the kenrel module from the ovs
>>> source tree and just compile it against the stock ubuntu kernel
>>> (assuming the kernel devel headers are available) is that right?
>>
>> It's kernel and userspace.  There's multiple current development
>> efforts that involve changes to OpenStack, OVS userspace, and the
>> appropriate datapath (OVS kernel module or DPDK).
>>
>> The consensus I'm picking up roughly is that for those working on the
>> features, 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 that important anyway.
> 
> I want to have voting tests for new features. For the past year the
> OVS agent ARP responder feature has been without proper coverage, and
> now it's the upcoming OVS firewall driver. I think that as long as we
> compile from a specific OVS patch (And not a moving target), I don't
> see much of a difference between gating on OVS 2.0 and gating on, for
> example, the current tip of the OVS 2.5 branch (But continuing to
> gate on that patch, so when the OVS 2.5 branch gets backports we
> won't gate on those, and we'll be able to move to a new tip in our
> own pace). As long as we pick a patch to compile against and run the
> functional tests a few times and verify that it works, I think it's
> reasonable. We've been gating against OVS 2.0 for the past few years,
> that to me seems unreasonable. We're gating against an OVS version
> nobody is using in production anymore.

I would agree that still using OVS 2.0 doesn't make any sense.
-- 
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


Re: [openstack-dev] [neutron] Testing Neutron with latest OVS

2016-01-14 Thread Russell Bryant
On 01/14/2016 04:32 PM, Ben Pfaff wrote:
> On Thu, Jan 14, 2016 at 09:30:03PM +, Sean M. Collins wrote:
>> On Thu, Jan 14, 2016 at 03:13:16PM CST, Clark Boylan wrote:
>>> Forgive my ignorance, but if we are gating on OVS 2.0 that is because it
>>> is what is shipped 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 distro has 2.0?

Ubuntu 14.04 (latest LTS)

-- 
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


Re: [openstack-dev] [neutron] Testing Neutron with latest OVS

2016-01-13 Thread Russell Bryant
On 01/13/2016 03:59 PM, Assaf Muller wrote:
> On Wed, Jan 13, 2016 at 4:50 AM, Jakub Libosvar <jlibo...@redhat.com> wrote:
>> Hi all,
>>
>> recently I was working on firewall driver [1] that requires latest
>> features in OVS, specifically conntrack support. In order to get the
>> driver tested, we need to have the latest OVS kernel modules on machines
>> running tests but AFAIK there is no stable "2.5 like" release of OVS yet.
>>
>> Facing the same problem OVN did in the past, I decided to try to steal
>> their solution and apply it in our Neutron repo [2]. Sean and Matthew
>> rightfully expressed worries about this approach on review of [2].
>>
>> So I'd like to bring this to a broader audience and ask for help or
>> suggestion on how to test such Neutron features that require some newer
>> versions.
>>
>> The first idea was to have an option to compile trunk ovs and use it in
>> particular jobs like functional one. That would bring faster development
>> of features going along with ovs features.
> 
> I think we should use a newer OVS version that for the functional and
> fullstack jobs at the very least. This will enable us to test the OVS
> firewall driver you're working on, as well as the OVS ARP responder
> (Which was merged a long time ago, but lacks proper testing because
> it needs OVS 2.1+ and we gate using OVS 2.0).
> 
> So, that's the problem. How we solve it is another manner - I was 
> under the impression that compiling it is our only option. Right now
> OVN are compiling master, I think we should avoid that and compile a
> specific git hash instead so the gate won't break every time OVS
> breaks. Then, when OVS branch out 2.5, we can 'pin' on that.

FWIW, a 2.5 branch already exists, but hasn't been released yet.  It
should only be receiving bug fixes at this point.

https://github.com/openvswitch/ovs/tree/branch-2.5

We compile from master since OVN is under such active development in
parallel, so that's really what we want.  It also doesn't break anyone
but networking-ovn if there's an ovs issue.  I probably wouldn't do that
for a more general voting neutron job.

> At that point we could perhaps switch to a packaged OVS off some
> sort of experimental 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
master, as well.  That seems to be working on the devstack jenkins nodes
just fine.

-- 
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


Re: [openstack-dev] [nova][neutron][os-vif] os-vif core review team membership

2016-01-12 Thread Russell Bryant
On 01/12/2016 10:15 AM, Daniel P. Berrange wrote:
> So far myself & Jay Pipes have been working on the initial os-vif
> prototype and setting up infrastructure for the project. Obviously
> we need more then just 2 people on a core team, and after looking
> at those who've expressed 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
> 
> So unless anyone wishes to decline the offer, once infra actually add
> me to the os-vif-core team I'll be making these people os-vif core, so
> we can move forward with the work on the library...

Thanks, I'm happy to help.

-- 
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


Re: [openstack-dev] [Devstack][OVN] ovs modprobe bug

2015-12-16 Thread Russell Bryant
On 12/16/2015 07:43 AM, Somanchi Trinath wrote:
> Hi –
> 
>  
> 
> When I try to install devstack+ovn, I get this error with OVS.
> 
>  
> 
> make[2]: Leaving directory `/usr/src/linux-headers-3.13.0-32-generic'
> 
> depmod `sed -n 's/#define UTS_RELEASE "\([^"]*\)"/\1/p'
> /lib/modules/3.13.0-32-generic/build/include/generated/utsrelease.h`
> 
> make[1]: Leaving directory `/opt/stack/ovs/datapath/linux'
> 
> modprobe: FATAL: Module openvswitch is in use.

The context here is that the ovn devstack plugin compiles and loads the
openvswitch kernel module from the ovs source tree.  It has to do this
as OVN depends on openvswitch kernel features in upstream kernel version
4.3.  Those features have been backported to the version of the module
in the ovs tree which we can use on older kernels.

This error occurs when the devstack plugin runs:

  sudo modprobe -r openvswitch

Try:

  lsmod | grep openvswitch

The far right column will list any other kernel modules that depend on
the openvswitch module.  Those have to be unloaded first.

ovs-vswitchd shouldn't be running, as it should have been uninstalled
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: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Neutron] Evolving the stadium concept

2015-11-30 Thread Russell Bryant
some piece
of networking.

networking-ale-omniswitch:
networking-arista:
networking-bgpvpn:
networking-calico:
networking-cisco:
networking-fortinet:
networking-hpe:
networking-hyperv:
networking-infoblox:
networking-fujitsu:
networking-lenovo:
networking-midonet:
networking-odl:
networking-ofagent:
networking-onos:
networking-ovn:
networking-plumgrid:
networking-powervm:
networking-vsphere:
python-neutron-pd-driver:
vmware-nsx:

I haven't gone and looked at every one of these in detail, so maybe
there's another category here.  In any case, for those that fit this
category, it seems most natural to consider these part of Neutron.  They
are completely useless without Neutron, and Neutron is useless without
code from this category.


My alternate, modified proposal would be to:

a) Clarify the line of what should be included in Neutron and what
shouldn't be.  The categorization above is a straw man start.  In that,
categories 1 and 2 could be split, but 3 and 4 would stay.

b) Break down what's actually causing pain and address it point by point.

> As a result, there is quite an effort imposed on the PTL, the various
> liaisons (release, infra, docs, testing, etc) and the core team to
> help manage the existing relationships and to ensure that the picture
> stays coherent over time. 

For example, you mention "release" here, though IIUC, Kyle is handling
releases for all of these sub-projects, right?  If so, Kyle, what do you
think?  What's causing pain and how can we improve?

"infra" - I take it this is about the Neutron infra liaisons having to
ack every infra patch for all of these repos.  That does sound annoying.
 It'd be nice if the lead for each driver or whatever could act as the
infra liaison for jobs that only affect that repo.

> Sometimes the decision of being part of
> this list is even presented before one can see any code, and that
> defeats the whole point of the deliverable association.

It makes sense to reject something if there's no code.  That's in line
with how the TC has been evaluating new projects.

> I have experienced first hand that this has become a burden,

How about delegating this to the neutron-drivers team?  You already have
a meeting with this group reviewing RFEs.  You could spread the load
some more by letting others take a look and make a recommendation.

> and I fear that
> the stadium might be an extra layer of governance/complexity that
> could even interfere with the existing responsibilities of the TC and
> of OpenStack infra.

I'm not sure what this means.  Can you elaborate?

For the TC, do you mean that Neutron is making in/out decisions that the
TC should make?  That's probably true for certain categories (#1 above,
especially, and maybe #2), but not for individual drivers, IMO at least.

At the end of the day, it'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 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

__
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



Re: [openstack-dev] [Neutron] Security Groups OVS conntrack support

2015-11-23 Thread Russell Bryant
On 11/23/2015 02:16 PM, Kevin Benton wrote:
> Security groups already use connection tracking. It's just done via a
> linux bridge right now because the versions of OVS shipped with most
> distros have no native conntrack support.

This post discusses it in the context of OVN, but gets down to showing
what the flows look like.  It also includes a link to a presentation
about ovs+conntrack given at the OpenStack Summit in Vancouver.

http://blog.russellbryant.net/2015/10/22/openstack-security-groups-using-ovn-acls/

The most recent talk on this topic was "The State of Stateful 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 for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [neutron][networking-sfc] Deploying current networking-sfc

2015-11-16 Thread Russell Bryant
On 11/16/2015 01:42 PM, Sean M. Collins wrote:
> On Mon, Nov 16, 2015 at 04:11:42PM EST, Paul Carver wrote:
>> This is a challenge. Personally, I haven't been able to get it all working
>> yet. But we're in a dilemma because we want to get good reviews of the code
>> before merging. Since the full functionality is quite a lot of code we
>> wanted to chop it into more easily reviewable chunks. Unfortunately that
>> makes it more difficult to pull it all in at once to test the whole thing
>> prior to completing the review and merge.
> 
> I would be concerned about that. I am sympathetic to the chicken and egg
> problem of a new repo and new code, but I briefly looked at both of
> those reviews and they both are quite large. 1K LOC is usually the upper
> limit for a sane patch set. It may be worth trying to break into
> smaller, more manageable pieces - even if the initial commits just
> create some empty classes and stubbed methods, and then later start
> introducing the actual method bodies in small pieces with good unit
> tests for each one. Small pieces. Tiny steps.

Another thing I've been thinking about is the difference between having
a repo like networking-sfc where a sub-group is able to try out new
things while also managing expectations with consumers of Neutron.  How
does someone know the difference between something a bit more
experimental vs. when an API is established and can be considered stable
and maintained with backwards copmatibility like any other OpenStack
REST API?

I think networking-sfc should be able to keep merging code, including
the proposed API, but I think it should be clearly marked as
experimental and subject to change.  That's based on my experience so
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 List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] Regarding OVN project and integration with SFC

2015-11-15 Thread Russell Bryant
On 11/13/2015 07:30 PM, Cathy Zhang wrote:
> Has the OVN code been released in Liberty? If not when is it planned for
> release?

No.  OVN itself is still under heavy development within the OVS project.
 It's being developed in OVS master, but is not yet in any released
version of OVS.

You can try it out with Liberty, but there are some catches since it's
sitll so new.  You have to install OVS and OVN from OVS git master.  You
also need kernel support for OVS+conntract integration.  That
integration is in Linux 4.3, but there is also a backport of that
integration that be compiled and loaded into older kernels.  The
networking-ovn devstack plugin does all of this automatically.

The other major catch with using this with Liberty is that it still used
Neutron's L3 agent, which is only temporary.  L3 support is moving fast
in OVN itself, but native NAT support in OVS is still a work in
progress, but we should have something in the coming weeks.

That's a long answer to say that it's available for dev and early
testing now, but I think Mitaka is a more reasonable OpenStack release
to expect a more complete release with all of OVN's native features
integrated into OpenStack.

> Will it replace existing OVS Driver and OVS Agent or it will provide an
> alternative path of programming the OVS?

The future there is not clear.  There's certainly no official plan from
the Neutron project perspective.

OVN is an alternative to the existing OVS integration.  It won't use the
ovs agent, l3 agent, or DHCP agent.  (The L3 and DHCP parts are
partially there, but not complete today, though).

I can say that from the OVN project's perspective, it's certainly our
hope that we implement OVN well enough that Neutron (or other similar
projects) *want* to use it over integrating with OVS directly.  I don't
think it will be much longer before we complete support for what I'd
consider core features for the majority of use cases.  However, the
existing OVS integration does a lot.  I'm not sure when we'll reach full
feature parity, or if that even makes sense.  There may be some features
or deployment models that we don't feel are worth supporting in OVN.
This is just going to be an ongoing conversation that evolves over time.

> It is on the networking-sfc project roadmap to
> support OVN integration with SFC.

Great.  To do that, we have to add SFC to OVN itself.  That's what I've
started looking at.  I did an early prototype and have been talking to
people, including networking-sfc devs :-), to get a better idea of
what's required.  I'm hoping we can have something in OVN during this
development cycle.

> We would like to work with you on adding an OVN driver and Agent to
> integrate with the networking-sfc API.

I don't expect there to be any agent.  All of that will be taken care of
by OVN.

> How would you like to proceed with this integration 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 kind of design to review there.  I'm not sure on the
timeline right now, as I have my hands in several things at once.

-- 
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


Re: [openstack-dev] [networking-ovn] ovn-northd is a spof

2015-11-10 Thread Russell Bryant
On 11/10/2015 07:06 PM, gong_ys2004 wrote:
> Regard this, I read some architecture doc of it, SPOF in OVN way exists
> in two place:
> 1. ovn-northd, I don't know if we can run multiple ones, but the arch
> doc demos only one

The idea is that we will make it so you can run multiple.  We haven't
done it yet, though.  In the meantime, the expectation is that you can
easily run it in active/passive HA mode.  That will impact scale,
though.  A single ovn-northd is obviously not the longer term goal.

> 2. north db and south db, currently it is a OVSDB respectively, I don't
> think the distributed db layer can be easily and quickly solved.

Someone is actually already looking at distributing ovsdb-server.  If
that doesn't work out, the project has been pretty clear from the
beginning that the use of ovsdb-server was for convenience and if it
doesn't work, we'll switch.

I've been planning to write a FAQ in the networking-ovn documentation.
Some comments about our plans around HA are part of it.  I'll try to get
that written this week.

> curiously, why we adopt two dbs design at the beginning. why does not
> the ovn neutron 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

__
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


Re: [openstack-dev] [Neutron] Reminder: Team meeting on Monday at 2100 UTC

2015-11-09 Thread 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)’ TZ available in Google Calendar
> that is identical to UTC for all practical matters.
> 
> Ihar
> 
> Carl Baldwin  wrote:
> 
>> I've been using Iceland's TZ for this.  Seems to work well and handle
>> the TZ changes nicely.
>>
>> Carl
>>
>> On Sat, Nov 7, 2015 at 7:24 AM, Sean M. Collins 
>> wrote:
>>> Learn from my mistake, check your calendar for the timezone if you've
>>> created an event for the weekly meetings. Google makes it a hassle to
>>> set things in UTC time, so I was caught by surprise by the FwaaS meeting
>>> due to the DST change in the US of A.
>>>
>>> -- 
>>> Sean M. Collins
>>>
>>> __
>>>
>>> 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
>>
>> __
>>
>> 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
> 
> __
> 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


__
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


Re: [openstack-dev] [neutron][networking-sfc] API clarification questions

2015-10-28 Thread Russell Bryant


- 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 Mailing List; Cathy Zhang; Henry Fourie
> Subject: [neutron][networking-sfc] API clarification questions
> 
> I read through the proposed SFC API here:
> 
> http://docs.openstack.org/developer/networking-sfc/api.html
> 
> I'm looking at implementing what would be required to support this API in
> OVN.  I have a prototype, but I had to make some pretty big assumptions, so
> I wanted to clarify the intent of the API.
> 
> First, does it assume that all of the neutron ports in a chain are on the
> same Neutron network?  That keeps things simple.  If its intended to allow a
> chain of ports on different networks, is it just required that you pick
> ports that all have addresses routable from one port to the next in the
> chain?
> 
> Cathy> It can allow a chain of ports on different networks as along it
> belongs to the same tenant. Yes, it is required that you pick ports that all
> have addresses routable from one port to the next in the chain.

Thanks.  I think it would be good to clarify this in the API doc, so it's clear 
what makes a valid set of ports in a chain.

> An arbitrary set of ports can't always work, so there has to be some bounds
> around what set of ports are valid to be in a chain.
> 
> Second, where is it expected that the match is applied?  The API for creating
> a port chain doesn't associate the chain with a network, but just matching
> "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?
> 
> Cathy> As long as the ports are routable, they do not need to associated with
> the same network.

Let me rephrase the question ... where is the flow classifier applied?  What 
traffic exactly?  "All traffic on all networks accessible to the tenant who 
created the port chain" doesn't seem right to me, but the API doesn't seem to 
specify it.


-- 
Russell

__
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


[openstack-dev] [neutron][networking-sfc] API clarification questions

2015-10-28 Thread Russell Bryant
I read through the proposed SFC API here:

http://docs.openstack.org/developer/networking-sfc/api.html

I'm looking at implementing what would be required to support this API
in OVN.  I have a prototype, but I had to make some pretty big
assumptions, so I wanted to clarify the intent of the API.

First, does it assume that all of the neutron ports in a chain are on
the same Neutron network?  That keeps things simple.  If its intended to
allow a chain of ports on different networks, is it just required that
you pick ports that all have addresses routable from one port to the
next in the chain?  An arbitrary set of ports can't always work, so
there has to be some bounds around what set of ports are valid to be in
a chain.

Second, where is it expected that the match is applied?  The API for
creating a port chain doesn't associate the chain with a network, but
just matching "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 would be great too.

-- 
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


Re: [openstack-dev] [neutron][networking-sfc] API clarification questions

2015-10-28 Thread Russell Bryant
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/networking-sfc/api.html
> 
> I'm looking at implementing what would be required to support this API
> in OVN.  I have a prototype, but I had to make some pretty big
> assumptions, so I wanted to clarify the intent of the API.
> 
> First, does it assume that all of the neutron ports in a chain are on
> the same Neutron network?  That keeps things simple.  If its intended to
> allow a chain of ports on different networks, is it just required that
> you pick ports that all have addresses routable from one port to the
> next in the chain?  An arbitrary set of ports can't always work, so
> there has to be some bounds around what set of ports are valid to be in
> a chain.
> 
> 
> Hi Russell,
> 
> We have similarly been experimenting with a MidoNet implementation of
> the SFC API.

Great!  It's nice to have multiple people looking at this with different
implementations in mind.  That should help us shake out these sorts of
issues before the API is too locked down.  Thanks for jumping in.  :-)

> I hope there's no restriction on the location of the Neutron ports in a
> chain. 

Yes, that makes sense.  Cathy's response seems to support that there
isn't a limitation.  We do need to clearly define it in the API
reference though.  Maybe something like ...

  All ports must:
  * be owned by the tenant.
  * have IP addresses such that the address of port N+1 in the chain
is routable from port N in the chain.

> In terms of addresses, I believe the API is lacking (or we use a
> chain_parameter?) a way to indicate the service insertion model:
> - L2 - The service can accept packets sent from any MAC (service NIC in
> promiscuous mode). The MAC address may be used to identify where the
> packet came from before it entered the chain.

If the ports in the chain don't have to all be on the same L2 network,
then it doesn't seem like you could use the source MAC address to know
where the packet came from before it entered the chain.

> - L3 -  The service expects packets to be routed to it. So the
> destination MAC of the packet must be set to the service's NIC's MAC.

This seems to make more sense to me.  You've got the "coorelation chain
parameter" to know what chain the packet is in, and you use the source
IP address to know where the packet came from originally before it
entered the chain.

>  
> 
> 
> Second, where is it expected that the match is applied?  The API for
> creating a port chain doesn't associate the chain with a network, but
> just matching "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?
> 
> 
> Here's what we were thinking for MidoNet:
> 
> use the logical_source_port in the flow classifier: when we render the
> SFC API in MidoNet's models we will associate the chain with the source
> port.
> 
> Our packet pipeline (for packets egressing the VM) is:
> 
>  1. Port Mirroring
>  2. Service Chaining
>  3. Filtering (Port Security, anti-spoofing, Security Groups)

OK, so it sounds like you're applying the "flow classifier" to packets
as the come from a neutron port and enter a neutron network.  That makes
sense.

Which ports' traffic do you apply the flow classifier to?  That's the
key piece I'm missing.

If the flow classifier includes a logical-source-port match, then it's
easy.  You only check traffic from a specific Neutron port.  The same
seems to apply if you only specified a logical-destination port, since
in that case you'd be matching on traffic ingressing the VM.

If tenant A creates the port chain and both logical-source-port and
logical-destination-port are not specified, then what packets do you
apply the flow classifier to?

> 
> 
> Do you think we can standardise on a single order in all
> implementations? We'd be happy to change the order if it makes sense. 

I think we do need to standardize where we can, yes.  We want the
resulting network behavior from the end user perspective to be as close
as possible to the same thing regardless of backend.

> I'm in Tokyo this week, so if the group working on this would like to
> talk in person, that would be great too.
> 
> 
> I'd love to be included.

OK, it's probably best that we try to keep it on the mailing list as
much as possible.  I really don't want to exclude anyone, and it's
important that this stuff is written down anyway.

There is an "NF

Re: [openstack-dev] [all] Recording little everyday OpenStack successes

2015-10-09 Thread Russell Bryant
On 10/09/2015 05:42 AM, Thierry Carrez wrote:
> Hello everyone,
> 
> OpenStack has become quite big, and it's easier than ever to feel lost,
> to feel like nothing is really happening. It's more difficult than ever
> to feel part of a single community, and to celebrate little successes
> and progress.
> 
> In a (small) effort to help with that, I suggested making it easier to
> record little moments of joy and small success bits. Those are usually
> not worth the effort of a blog post or a new mailing-list thread, but
> they show that our community makes progress *every day*.
> 
> So whenever you feel like you made progress, or had a little success in
> your OpenStack adventures, or have some joyful moment to share, just
> throw the following message on your local IRC channel:
> 
> #success [Your message here]
> 
> The openstackstatus bot will take that and record it on this wiki page:
> 
> https://wiki.openstack.org/wiki/Successes
> 
> We'll add a few of those every week to the weekly newsletter (as part of
> the developer digest that we reecently added there).
> 
> Caveats: Obviously that only works on channels where openstackstatus is
> present (the official OpenStack IRC channels), and we may remove entries
> that are off-topic or spam.
> 
> So... please use #success liberally and record lttle everyday OpenStack
> successes. Share the joy and make the OpenStack 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)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [neutron + ovn] Does neutron ovn plugin support to setup multiple neutron networks for one container?

2015-10-05 Thread Russell Bryant
On 10/05/2015 04:28 PM, Murali R wrote:
> Yes. So we can define multiple logical switches per network and ovn
> keeps vlan maps that ovs agent used to maintain and do the tunneling. My
> confusion was from lport-add command that did not have host info, so if
> there is no neutron, 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.

-- 
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


Re: [openstack-dev] [neutron] - deprecation of max_fixed_ips_per_port

2015-10-04 Thread Russell Bryant
On 10/02/2015 07:25 PM, Kevin Benton wrote:
> Hi,
> 
> There is an option in Neutron called max_fixed_ips_per_port that limits
> the number of IP addresses that can be assigned to each port. It doesn't
> appear to have a clear use case since we prevent users from setting IPs
> on ports attached to networks they don't own (shared networks). I have
> filed a bug[1] to deprecate it for removal in N.
> 
> If you have a use case for max_fixed_ips_per_port that I am missing,
> please provide feedback on the bug report.
> 
> 
> 1. https://bugs.launchpad.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

__
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


Re: [openstack-dev] [neutron][ovn] New cycle started. What are you up to, folks?

2015-10-02 Thread Russell Bryant
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 others, because you have immediate yay/nay feedback, 
>> and maybe find companions for next adventures, and what not. So
>> I’ve decided to ask everyone what you see the team and you
>> personally doing the next cycle, for fun or profit.
>>
>> That’s like a PTL nomination letter, but open to everyone! :) No 
>> commitments, no deadlines, just list random ideas you have in mind
>> or in your todo lists, and we’ll all appreciate the huge pile of 
>> awesomeness no one will ever have time to implement even if
>> scheduled for Xixao release.
>>
>> To start the fun, I will share my silly ideas in the next email.
> 
> Nice thread!
> 
> Here's a rough cut of what I have in mind.  My Neutron related
> development time covers a few areas: Neutron, OVN itself, and the
> networking-ovn plugin for Neutron.
> 
> For Neutron:
> 
>  - general code reviews.  I'm especially interested in reviewing the
>design and implementation of any new APIs people are adding.  Feel
>free to add me to reviews you think I could help with and I'll take
>a look.
> 
>  - plugin infrastructure.  Ihar mentioned in one of his items that
>there are features implemented as ML2 specific.  That has started
>to be a pain for networking-ovn.  For example, the provider networks
>extension is only implemented for ML2, and the data is only stored
>in an ML2 specific db table.  The db table and related code should
>be reusable by other plugins.  I'd like to help start to clean that
>up for the sake of other plugins.
> 
> For OVN and networking-ovn:
> 
> First, for anyone not already familiar with OVN, it is an effort
> within the Open vSwitch project to build a virtual networking control
> plane for OVS.  There are several projects that have implemented
> something in this space (including Neutron).  OVN is intended to be a
> new, common implementation of this functionality that can be reused in
> many contexts, including by Neutron.  It includes a focus on
> implementation of features taking advantage of the newest features of
> OVS, including some still being added as we go.  There was a
> presentation about this in Vancouver [1] and we'll be doing another
> one covering current status in Tokyo [2].
> 
> This plugin is developed in parallel with OVN itself.  My time on each
> changes week to week, depending on what I'm working on.  The dev items
> I expect in the near future (this release cycle at least) include:
> 
>  - security groups.  This is being implemented using conntrack suport
>in OVS.  There's actually WIP code for this including kernel
>changes, ovs userspace changes, OVN, and networking-ovn.  This is a
>complex stack of dependencies, but it's starting to fall into place.
>Most of the kernel changes have been accepted, thought there's
>another change being reviewed now.  The OVS userspace changes have
>been under review in the last few weeks and are close to being
>merged.  Once that's done, we can finish up testing the OVN and
>networking-ovn patches.  We expect this to be done by Tokyo.
> 
>  - provider networks.  There's a lot of demand in OpenStack for
>supporting direct connectivity to existing networks as a simpler
>deployment model without any overlays.  I've done most of the work
>for both OVN and networking-ovn for this now and expect to have it
>wrapped up in the next week or so.
> 
>  - L3.  So far we've been using Neutron's L3 agent with networking-ovn.
>OVN will have native L3 support (will no longer use the L3 agent)
>and development on that has now started.  We aim to at least have
>initial distributed L3 support by Tokyo.  Some of it will certainly
>extend past that, though.  For example, NAT will be implemented with
>an OVS native solution, and that will likely not be ready by Tokyo.
>We may be able to deliver an intermediary NAT solution quicker.
> 
>  - SFC.  There's a ton of interest in SFC.  I've been casually following
>the networking-sfc project and the Neutron API they are proposing.
>I've also been thinking about how to implement it in OVN.  I think
>OVN's logical flows abstraction is going to make it surprisingly easy
>to implement.  I think I have a good idea of what needs to be done,
>but I'm not sure of when it will bubble up on my todo list.  I hope
>to work on it for this dev cycle though.  I'd first be imp

Re: [openstack-dev] [neutron + ovn] Does neutron ovn plugin support to setup multiple neutron networks for one container?

2015-10-02 Thread Russell Bryant
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 --provider:network_type vlan
>> --provider:physical_network physnet1 --provider:segmentation_id VLAN_TAG
> 
> Yes, the OVN plugin will implement the normal provider networks API.
> It's a WIP.
> 
> My first goal was to just implement support for "--provider:network_type
> flat" end to end.  I have the OVN side merged and now I'm working on the
> Neutron plugin piece.  Once that's done, I'll go back add add VLAN
> support, which shouldn't be very difficult at that point.  I'm aiming to
> have all of that done by the Tokyo summit (among other things).

Just as a brief follow-up here, I finished the VLAN provider network
support for OVN here:

https://github.com/openvswitch/ovs/commit/779e72cc57a106251cc9e6696e8c9aabb56d30b5

I also wrote an OVN tutorial this week.  Examples 4 and 5 cover how
provider networks are modeled in OVN.

https://github.com/openvswitch/ovs/blob/master/tutorial/OVN-Tutorial.md

I have the Neutron API patch posted here:

https://review.openstack.org/#/c/228573/

I did the patch before I finished the VLAN support.  Adding the VLAN bit
will be a trivial update, though.

-- 
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


Re: [openstack-dev] [neutron][ovn] New cycle started. What are you up to, folks?

2015-10-02 Thread Russell Bryant
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 next cycle, and found it’s quite useful to share 
>>> thoughts with others, because you have immediate yay/nay feedback, 
>>> and maybe find companions for next adventures, and what not. So
>>> I’ve decided to ask everyone what you see the team and you
>>> personally doing the next cycle, for fun or profit.
>>>
>>> That’s like a PTL nomination letter, but open to everyone! :) No 
>>> commitments, no deadlines, just list random ideas you have in mind
>>> or in your todo lists, and we’ll all appreciate the huge pile of 
>>> awesomeness no one will ever have time to implement even if
>>> scheduled for Xixao release.
>>>
>>> To start the fun, I will share my silly ideas in the next email.
>>
>> Nice thread!
>>
>> Here's a rough cut of what I have in mind.  My Neutron related
>> development time covers a few areas: Neutron, OVN itself, and the
>> networking-ovn plugin for Neutron.
>>
>> For Neutron:
>>
>>  - general code reviews.  I'm especially interested in reviewing the
>>design and implementation of any new APIs people are adding.  Feel
>>free to add me to reviews you think I could help with and I'll take
>>a look.
>>
>>  - plugin infrastructure.  Ihar mentioned in one of his items that
>>there are features implemented as ML2 specific.  That has started
>>to be a pain for networking-ovn.  For example, the provider networks
>>extension is only implemented for ML2, and the data is only stored
>>in an ML2 specific db table.  The db table and related code should
>>be reusable by other plugins.  I'd like to help start to clean that
>>up for the sake of other plugins.
>>
>> For OVN and networking-ovn:
>>
>> First, for anyone not already familiar with OVN, it is an effort
>> within the Open vSwitch project to build a virtual networking control
>> plane for OVS.  There are several projects that have implemented
>> something in this space (including Neutron).  OVN is intended to be a
>> new, common implementation of this functionality that can be reused in
>> many contexts, including by Neutron.  It includes a focus on
>> implementation of features taking advantage of the newest features of
>> OVS, including some still being added as we go.  There was a
>> presentation about this in Vancouver [1] and we'll be doing another
>> one covering current status in Tokyo [2].
>>
>> This plugin is developed in parallel with OVN itself.  My time on each
>> changes week to week, depending on what I'm working on.  The dev items
>> I expect in the near future (this release cycle at least) include:
>>
>>  - security groups.  This is being implemented using conntrack suport
>>in OVS.  There's actually WIP code for this including kernel
>>changes, ovs userspace changes, OVN, and networking-ovn.  This is a
>>complex stack of dependencies, but it's starting to fall into place.
>>Most of the kernel changes have been accepted, thought there's
>>another change being reviewed now.  The OVS userspace changes have
>>been under review in the last few weeks and are close to being
>>merged.  Once that's done, we can finish up testing the OVN and
>>networking-ovn patches.  We expect this to be done by Tokyo.
>>
>>  - provider networks.  There's a lot of demand in OpenStack for
>>supporting direct connectivity to existing networks as a simpler
>>deployment model without any overlays.  I've done most of the work
>>for both OVN and networking-ovn for this now and expect to have it
>>wrapped up in the next week or so.
>>
>>  - L3.  So far we've been using Neutron's L3 agent with networking-ovn.
>>OVN will have native L3 support (will no longer use the L3 agent)
>>and development on that has now started.  We aim to at least have
>>initial distributed L3 support by Tokyo.  Some of it will certainly
>>extend past that, though.  For example, NAT will be implemented with
>>an OVS native solution, and that will likely not be ready by Tokyo.
>>We may be able to deliver an intermediary NAT solution quicker.
>>
>>  - SFC.  There's a ton of interest in SFC.  I've been casually following
>>the networking-sfc project and the Neutron API they are proposing.
>>  

Re: [openstack-dev] [neutron + ovn] Does neutron ovn plugin support to setup multiple neutron networks for one container?

2015-10-02 Thread Russell Bryant
On 10/02/2015 02:26 PM, Murali R wrote:
> Hi Russell,
> 
> Thank you these are really good. Had a quick question. When you create a
> logical switch in your first script (line 23) - at what point is it
> associated with br-int ? Is it on line 45? So I can create any switch
> and when I associated logical port it associates logical switch ? Or is
> there a different way we can associate logical-phy switches? I was
> looking to get the logical associations during startup initialization.

To clarify, I believe you're talking about the first script from the
tutorial [1], which is:

  https://github.com/openvswitch/ovs/blob/master/tutorial/ovn/env1/setup.sh

Most of that script is all configuring logical topology.  OVN does
nothing to the network until ovn-controller sees a port appear on br-int
that maps to a logical port.  This mapping is done by setting the
"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/OVN-Tutorial.md

-- 
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


Re: [openstack-dev] [neutron + ovn] Does neutron ovn plugin support to setup multiple neutron networks for one container?

2015-10-01 Thread Russell Bryant
On 09/30/2015 06:01 PM, Murali R wrote:
> Yes, sfc without nsh is what I am looking into and I am thinking ovn can
> have a better approach.
> 
> I did an implementation of sfc around nsh that used ovs & flows from
> custom ovs-agent back in mar-may. I added fields in ovs agent to send
> additional info for actions as well. Neutron side was quite trivial. But
> the solution required an implementation of ovs to listen on a different
> port to handle nsh header so doubled the number of tunnels. The ovs code
> we used/modified to was either from the link you sent or some other
> similar impl from Cisco folks (I don't recall) that had actions and
> conditional commands for the field. If we have generic ovs code to
> compare or set actions on any configured address field was my thought.
> But haven't thought through much on how to do that. In any case, with
> ovn we cannot define custom flows directly on ovs, so that approach is
> dated now. But hoping some similar feature can be added to ovn which can
> transpose some header field to geneve options.

Thanks for the detail of what you're trying to do.

I'm not sure how much you've looked into how OVN works.  OVN works by
defining the network in terms of "logical flows".  These logical flows
look similar to OpenFlow, but it talks about network resources in the
logical sense (not based on where they are physically located).  I think
we can implement SFC purely in the logical space.  So, most of the work
I think is in defining the northbound db schema and then converting that
into the right logical flows.  I looked at the API being proposed by the
networking-sfc project, and that's giving me a pretty good idea of what
the northbound schema could look like for OVN.

https://git.openstack.org/cgit/openstack/networking-sfc/tree/doc/source/api.rst

The networking-sfc API talks about a "chain parameter".  That's where
NSH could come in.  The spec proposes "mpls" as something OVS can
already support.  Given a single VIF, we need a way to differentiate
traffic associated with different chains.  This is *VERY* similar to
what OVN is already doing with parent/child ports, originally intended
for the containers-in-VM use case.  This same concept seems to fit here
quite well.  Today, we only support VLAN IDs for this, but we could
extend it to support mpls, NSH, or whatever.

Anyway, those are just my high level thoughts so far.  I haven't tried
to really dig into a detailed design yet.

> I am trying something right now with ovn and will be attending ovs
> conference in nov. I am skipping openstack 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

__
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


Re: [openstack-dev] [neutron][ovn] New cycle started. What are you up to, folks?

2015-10-01 Thread Russell Bryant
xpand it as necessary, and get an OVN
   backend for that API.

 - containers.  OVN has had a focus on supporting container networking
   from the start.  One way is that OVN can be used directly to build
   overlay networks independent of whatever infrastructure the container
   app is running on.  This is conceptually similar to other things like
   Flannel.  A major downside of overlay based container networking is
   the performance hit you get when you end up with an "overlays on
   overlays", where you can't take advantage of NIC offload support
   for overlay encapsulation.

   To address the performance issue, OVN includes abstractions to
   provide networking for a hybrid environment of bare metal, VMs,
   and containers.  In the OpenStack case, containers running on
   bare metal or containers running inside of OpenStack VMs should
   all be able to talk to the Neutron API of the underlying OpenStack
   to provide the desired network topology.  networking-ovn supports
   this already, but with a networking-ovn specific binding-profile:

   http://docs.openstack.org/developer/networking-ovn/containers.html

   I'd like to help ensure that the "VLAN aware VMs" spec gets reviewed
   and merged this cycle, as that API provides the proper Neutron
   abstraction for what's needed here.

   Once *that* is done, I'd really like to see some native Kubernetes
   integration to be able to talk to the Neutron API and set up the
   networking needed for container apps running in OpenStack VMs, but
   it seems unlikely that I'll get to that this cycle myself.

 - testing.  We have a tempest job for networking-ovn that's passing.
   It skips a few tests for things we haven't finished implementing [3].
   I'd like to get down to where we're not skipping anything.  Since
   it's passing, I'd like to get to where we can run the job against
   Neutron patches, as well.  I'd propose it as a non-voting job, but
   it would be running in OpenStack's infrastructure.  Running against
   Neutron would get the job running much more frequently to help us
   shake out bugs and would also help us catch issues between Neutron
   and networking-ovn quicker.  Finally, I'd also like to build a
   multi-node test job.

 - native DHCP support.  Right now networking-ovn uses the existing
   Neutron DHCP agent.  We plan to add native distributed DHCP support
   to OVN.  Once someone gets around to it, the DHCP agent will no
   longer be used.

I'm sure I've forgotten something, but this seems like a pretty good
overview of what I expect to see this cycle.  I'd love to 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/presentation/ovn-native-virtual-networking-for-open-vswitch
[2]
https://openstacksummitoctober2015tokyo.sched.org/event/89a27d6b5bab975a7a4f49ec57ee5210#.Vg2DmXUVhBc
[3]
http://git.openstack.org/cgit/openstack/networking-ovn/tree/devstack/devstackgaterc

-- 
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


Re: [openstack-dev] [neutron + ovn] Does neutron ovn plugin support to setup multiple neutron networks for one container?

2015-09-30 Thread Russell Bryant
On 09/30/2015 03:29 PM, Murali R wrote:
> Russell,
> 
> Are any additional options fields used in geneve between hypervisors at
> this time? If so, how do they translate to vxlan when it hits gw? For
> instance, I am interested to see if we can translate a custom header
> info in vxlan to geneve headers and vice-versa. 

Yes, geneve options are used. Specifically, there are three pieces of
metadata sent: a logical datapath ID (the logical switch, or network),
the source logical port, and the destination logical port.

Geneve is only used between hypervisors. VxLAN is only used between
hypervisors and a VTEP gateway. In that case, the additional metadata is
not included. There's just a tunnel ID in that case, used to identify
the source/destination logical switch on the VTEP gateway.

> And if there are flow
> commands available to add conditional 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)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [neutron + ovn] Does neutron ovn plugin support to setup multiple neutron networks for one container?

2015-09-30 Thread Russell Bryant
On 09/30/2015 04:09 PM, Murali R wrote:
> Russel,
> 
> For instance if I have a nsh header embedded in vxlan in the incoming
> packet, I was wondering if I can transfer that to geneve options
> somehow. This is just as an example. I may have header other info either
> in vxlan or ip that needs to enter the ovn network and if we have
> generic ovs commands to handle that, it will be useful. If commands
> don't exist but extensible then I can do that as well.

Well, OVS itself doesn't support NSH yet.  There are patches on the OVS
dev mailing list for it, though.

http://openvswitch.org/pipermail/dev/2015-September/060678.html

Are you interested in SFC?  I have been thinking about that and don't
think it will be too hard to add support for it in OVN.  I'm not sure
when I'll work on it, but it's high on my personal todo list.  If you
want to do it with NSH, that will require OVS support first, of course.

If you're interested in more generic extensibility of OVN, there's at
least going to be one talk about that at the OVS conference in November.
 If you aren't there, it will be on video.  I'm not sure what ideas they
will be proposing.

Since we're on the OpenStack list, I assume we're talking in the
OpenStack context.  For any feature we're talking about, we also have to
talk about how that is exposed through the Neutron API.  So, "generic
extensibility" doesn't immediately 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

__
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


Re: [openstack-dev] [neutron + ovn] Does neutron ovn plugin support to setup multiple neutron networks for one container?

2015-09-27 Thread Russell Bryant
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 --provider:network_type vlan
> --provider:physical_network physnet1 --provider:segmentation_id VLAN_TAG

Yes, the OVN plugin will implement the normal provider networks API.
It's a WIP.

My first goal was to just implement support for "--provider:network_type
flat" end to end.  I have the OVN side merged and now I'm working on the
Neutron plugin piece.  Once that's done, I'll go back add add VLAN
support, which shouldn't be very difficult at that point.  I'm aiming to
have all of that done by the Tokyo summit (among other things).

> On Sun, Sep 27, 2015 at 9:50 AM, WANG, Ming Hao (Tony T)
> <tony.a.w...@alcatel-lucent.com <mailto:tony.a.w...@alcatel-lucent.com>>
> wrote:
> 
> Russell,
> 
> Another question is about "localnet". It is a very useful feature. :-)
> 
> Is it possible to assign which VLAN tag will be used for a specific
> provider network?
> 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 the provider network, is the VLAN
> tag translation done by "br-int" or "br-eth1"?


-- 
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


Re: [openstack-dev] [neutron + ovn] Does neutron ovn plugin support to setup multiple neutron networks for one container?

2015-09-27 Thread Russell Bryant
On 09/27/2015 02:26 AM, WANG, Ming Hao (Tony T) wrote:
> Russell,
> 
> Thanks for your valuable information.
> I understood Geneve is some kind of tunnel format for network virtualization 
> encapsulation, just like VxLAN.
> But I'm still confused by the connection between Geneve and VTEP.
> I suppose VTEP should be on behalf of "VxLAN Tunnel Endpoint", which should 
> be used for VxLAN only.
> 
> Does it become some "common tunnel endpoint" in OVN, and can be also used as 
> a tunnel endpoint for Geneve?

When using VTEP gateways, both 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 (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [all] -1 due to line length violation in commit messages

2015-09-25 Thread Russell Bryant
On 09/25/2015 12:15 PM, Fox, Kevin M wrote:
> Another option... why are we wasting time on something that a
> computer can handle? Why not just let the line length be infinite in
> the commit message and have gerrit wrap it to  here> length lines on merge?

I don't think gerrit 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.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [neutron][networking-ovn][vtep] Proposal: support for vtep-gateway in ovn

2015-09-24 Thread Russell Bryant
On 09/24/2015 01:17 AM, Amitabha Biswas wrote:
> Hi everyone,
> 
> I want to open up the discussion regarding how to support OVN
> VTEP gateway deployment and its lifecycle in Neutron. 

Thanks a lot for looking into this!

> In the "Life Cycle of a VTEP gateway" part in the OVN architecture
> document (http://www.russellbryant.net/ovs-docs/ovn-architecture.7.pdf),
> step 3 is where the Neutron OVN plugin is involved. At a minimum, the
> Neutron OVN plugin will enable setting the type as "vtep" and the
> vtep-logical-switch and vtep-physical-switch options in the
> OVN_Northbound database.

I have the docs published there just to make it easier to read the
rendered version.  The source of that document is:

https://github.com/openvswitch/ovs/blob/master/ovn/ovn-architecture.7.xml

> There are 2 parts to the proposal/discussion - a short 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/switch can be mapped to a vtep logical gateway by
> creating a port in that logical network and creating a binding profile
> for that port in the following manner:
> 
> neutron port-create --binding-profile
> '{"vtep-logical-switch":"vtep_lswitch_key",
> "vtep-physical-switch":"vtep_pswitch_key"}' private.
> 
> Where vtep-logical-switch and vtep-physical-switch should have been
> defined in the OVN_Southbound database by the previous steps (1,2) in
> the life cycle. 

Yes, this sounds great to me.  Since there's not a clear well accepted
API to use, we should go this route to get the functionality exposed
more quickly.  We should also include in our documentation that this is
not expected to be how this is done long term.

The comparison to the containers-in-VMs support is a good one.  In that
case we used binding:profile as a quick way to expose it, but we're
aiming to support a proper API.  For that feature, we've identified the
"VLAN aware VMs" API as the way forward, which will hopefully be
available next cycle.

> For the longer term solution, there needs to be a discussion:
> 
> Should the knowledge about the physical and logical step gateway should
> be exposed to Neutron - if yes how? This would allow a Neutron NB
> API/extension to bind a “known” vtep gateway to the neutron logical
> network. This would be similar to the workflow done in the
> networking-l2gw extension
> https://review.openstack.org/#/c/144173/3/specs/kilo/l2-gateway-api.rst
> 
> 1. Allow the admin to define and manage the vtep gateway through Neutron
> REST API.
> 
> 2. Define connections between Neutron networks and gateways. This is
> conceptually similar to Step 3 of the step gateway performed by the OVN
> Plugin in the short term solution.

networking-l2gw does seem to be the closest thing to what's needed, but
it's not a small amount of work.  I think the API might need to be
extended a bit for our needs.  A bigger concern for me is actually with
some of the current implementation details.

One particular issue is that the project implements the ovsdb protocol
from scratch.  The ovs project provides a Python library for this.  Both
Neutron and networking-ovn use it, at least.  From some discussion, I've
gathered that the ovs Python library lacked one feature that was needed,
but has since been added because we wanted the same thing in networking-ovn.

The networking-l2gw route will require some pretty significant work.
It's still the closest existing effort, so I think we should explore it
until it's absolutely clear that it *can't* work for what we need.

> OR
> 
> Should OVN pursue it’s own Neutron extension (including vtep gateway
> support).

I don't think this option provides a lot of value over the short term
binding:profile solution.  Both are OVN specific.  I think I'd rather
just stick to binding:profile as the OVN specific stopgap because it's a
*lot* less work.

Thanks again,

-- 
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


Re: [openstack-dev] [neutron + ovn] Does neutron ovn plugin support to setup multiple neutron networks for one container?

2015-09-24 Thread Russell Bryant
On 09/24/2015 10:37 AM, WANG, Ming Hao (Tony T) wrote:
> Russell,
> 
> Thanks for your detail explanation and kind help!
> I have understand how container in VM can acquire network interfaces in 
> different neutron networks now.
> For the connections between compute nodes, I think I need to study Geneve 
> protocol and VTEP first.
> Any further question, I may need to continue consulting you. :-) 

OVN uses Geneve in conceptually the same way as to how the Neutron
reference implementation (ML2+OVS) uses VxLAN to create overlay networks
among the compute nodes for 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 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


Re: [openstack-dev] [neutron][networking-ovn][vtep] Proposal: support for vtep-gateway in ovn

2015-09-24 Thread Russell Bryant
On 09/24/2015 10:18 AM, Salvatore Orlando wrote:
> One particular issue is that the project implements the ovsdb protocol
> from scratch.  The ovs project provides a Python library for this.  Both
> Neutron and networking-ovn use it, at least.  From some discussion, I've
> gathered that the ovs Python library lacked one feature that was needed,
> but has since been added because we wanted the same thing in
> networking-ovn.
> 
> 
> My take here is that we don't need to use the whole implementation of
> networking-l2gw, but only the APIs and the DB management layer it exposes.
> Networking-l2gw provides a VTEP network gateway solution that, if you
> want, will eventually be part of Neutron's "reference" control plane.
> OVN provides its implementation; I think it should be possible to
> leverage networking-l2gw either by pushing an OVN driver there, or
> implementing the same driver in openstack/networking-ovn.

>From a quick look, it seemed like networking-l2gw was doing 2 things.

  1) Management of vtep switches themselves

  2) Management of connectivity between Neutron networks and VTEP
 gateways

I figured the implementation of #1 would be the same whether you were
using ML2+OVS, OVN, (or whatever else).  This part is not addressed in
OVN.  You point OVN at VTEP gateways, but it's expected you manage the
gateway provisioning some other way.

It's #2 that has a very different implementation.  For OVN, it's just
creating a row in OVN's northbound database.

or did I mis-interpret what networking-l2gw is doing?

> The networking-l2gw route will require some pretty significant work.
> It's still the closest existing effort, so I think we should explore it
> until it's absolutely clear that it *can't* work for what we need.
> 
> 
> I would say that it is definitely not trivial but probably a bit less
> than "significant". abhraut from my team has done something quite
> similar for openstack/vmware-nsx [1]

but specific to nsx.  :(

Does it look like networking-l2gw could be a common API for what's
needed for NSX?

> 
> 
> > OR
> >
> > Should OVN pursue it’s own Neutron extension (including vtep gateway
> > support).
> 
> I don't think this option provides a lot of value over the short term
> binding:profile solution.  Both are OVN specific.  I think I'd rather
> just stick to binding:profile as the OVN specific stopgap because it's a
> *lot* less work.
> 
> 
> 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!

> [1] https://review.openstack.org/#/c/210623/

-- 
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


Re: [openstack-dev] [neutron][networking-ovn][vtep] Proposal: support for vtep-gateway in ovn

2015-09-24 Thread 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 is that the project implements the ovsdb 
> protocol
> > from scratch.  The ovs project provides a Python library for this.  
> Both
> > Neutron and networking-ovn use it, at least.  From some discussion, 
> I've
> > gathered that the ovs Python library lacked one feature that was 
> needed,
> > but has since been added because we wanted the same thing in
> > networking-ovn.
> >
> >
> > My take here is that we don't need to use the whole implementation of
> > networking-l2gw, but only the APIs and the DB management layer it 
> exposes.
> > Networking-l2gw provides a VTEP network gateway solution that, if you
> > want, will eventually be part of Neutron's "reference" control plane.
> > OVN provides its implementation; I think it should be possible to
> > leverage networking-l2gw either by pushing an OVN driver there, or
> > implementing the same driver in openstack/networking-ovn.
> 
> From a quick look, it seemed like networking-l2gw was doing 2 things.
> 
>   1) Management of vtep switches themselves
> 
>   2) Management of connectivity between Neutron networks and VTEP
>  gateways
> 
> I figured the implementation of #1 would be the same whether you were
> using ML2+OVS, OVN, (or whatever else).  This part is not addressed in
> OVN.  You point OVN at VTEP gateways, but it's expected you manage the
> gateway provisioning some other way.
> 
> It's #2 that has a very different implementation.  For OVN, it's just
> creating a row in OVN's northbound database.
> 
> or did I mis-interpret what networking-l2gw is doing?
> 
> 
> No, you did not misinterpret what the objective of the project were
> (which I reinstate here):
> 
> * Provide an API to OpenStack admins to extend neutron logical networks
> into unmanaged pre-existing vlans. Bear in mind that things like address
> collision prevention is left in the hands on the operator. Other aspects
> like L2/L3 interoperability instead should be taken care of, at least
> from an implementation point of view.
> 
> * Provide a pluggable framework for multiple drivers of the API.
> 
> * Provide an PoC implementation on top of the ovsdb vtep schema. This
> can be implemented both in hardware (ToR switches) and software
> (software L2 gateways). 

Thanks for clarifying the project's goals!

> > The networking-l2gw route will require some pretty significant work.
> > It's still the closest existing effort, so I think we should 
> explore it
> > until it's absolutely clear that it *can't* work for what we need.
> 
> 
> We may have fallen short of some/all expectations, but I would like to
> believe than it is nothing that can't be fixed by iterating on,
> especially if active project participation raises.
> 
> I don't think there's a procedural mandate to make OVN abide by the l2gw
> proposed API. As you said, it is not a clear well accepted API, but
> that's only because we live in a brand new world, where people should be
> allowed to experiment and reconcile later as community forces play out.
> 
> That said, should the conclusion that "it (the API) *can't* work for
> what OVN needs" be reached, I would like to understand/document why for
> the sake of all us involved so that lessons will yield from our mistakes.

My gut says we should be able to work together and make it work.  I
expect we'll talk in more detail in the next cycle.  :-)

-- 
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


Re: [openstack-dev] [neutron + ovn] Does neutron ovn plugin support to setup multiple neutron networks for one container?

2015-09-23 Thread Russell Bryant
e the traffic from each container even though its all
going over the same network interface to/from the VM.  That's where VLAN
ids are used.  It's used as a simple way to tag traffic as it goes over
the VMs network interface.  As it arrives in the VM, the tag is stripped
and traffic sent to the right container.  As it leaves the 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: Russell Bryant [mailto:rbry...@redhat.com] 
> Sent: Wednesday, September 23, 2015 12:46 AM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [neutron] Does neutron ovn plugin support to 
> setup multiple neutron networks for one container?
> 
> On 09/22/2015 08:08 AM, WANG, Ming Hao (Tony T) wrote:
>> Dear all,
>>
>> For neutron ovn plugin supports containers in one VM, My understanding is 
>> one container can't be assigned two network interfaces in different neutron 
>> networks. Is it right?
>> The reason:
>> 1. One host VM only has one network interface.
>> 2. all the VLAN tags are stripped out when the packet goes out the VM.
>>
>> If it is True, does neutron ovn plugin or ovn has plan to support this?
> 
> You should be able to assign multiple interfaces to a container on different 
> networks.  The traffic 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 (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> __
> 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

__
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


Re: [openstack-dev] [networking-ovn] Neutron-DVR feature on OVN/L3

2015-09-22 Thread Russell Bryant
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
>> 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 OVN will be
>> distributed.
> 
> I'm curious when this is true, what models will be supported?  Will it
> use NAT as current Neutron reference implementation?

Good questions.  We're aiming to have at least some initial L3 support
available by the Tokyo summit.  That will be distributed, but likely
won't include NAT at all.  Someone is working on figuring out the best
way to support NAT natively in OVS, and then we'll be using that.

Similar to the way we're doing security groups, NAT will be using the
new ovs conntrack integration, but details TBD.

I copied Ben Pfaff in case he wants to provide some more insight.

-- 
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


Re: [openstack-dev] [networking-ovn] Neutron-DVR feature on OVN/L3

2015-09-22 Thread Russell Bryant
On 09/21/2015 04:47 PM, Sisir Chowdhury wrote:
> Hi All -
> 
> I have some proposal regarding ovn-networking project within Open-Stack.
> 
> #1.   Making Neutron-DVR feature intelligent enough so that we can
> completely remove Network Node(NN).
> 
> Right now even with DVR, the egress traffic originated from VMs
> going outbound are SNAT'ed by the
> Network Node but the Ingrerss traffic coming from Internet to
> the VMs are directly going through the
> Compute Node and DNAT'ed by the L3 Agent of the Compute Node.
> 
> 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.  L3 in OVN will be
distributed.

-- 
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


Re: [openstack-dev] [neutron] Does neutron ovn plugin support to setup multiple neutron networks for one container?

2015-09-22 Thread Russell Bryant
On 09/22/2015 08:08 AM, WANG, Ming Hao (Tony T) wrote:
> Dear all,
> 
> For neutron ovn plugin supports containers in one VM, My understanding is one 
> container can't be assigned two network interfaces in different neutron 
> networks. Is it right?
> The reason:
> 1. One host VM only has one network interface.
> 2. all the VLAN tags are stripped out when the packet goes out the VM.
> 
> If it is True, does neutron ovn plugin or ovn has plan to support this?

You should be able to assign multiple interfaces to a container on
different networks.  The traffic 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 (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [glance] proposed priorities for Mitaka

2015-09-14 Thread Russell Bryant
On 09/14/2015 11:27 AM, Thierry Carrez wrote:
> Doug Hellmann wrote:
>> [...]
>> 1. Resolve the situation preventing the DefCore committee from
>>including image upload capabilities in the tests used for trademark
>>and interoperability validation.
>>
>> 2. Follow through on the original commitment of the project to
>>provide an image API by completing the integration work with
>>nova and cinder to ensure V2 API adoption.
>> [...]
> 
> Thanks Doug for taking the time to dive into Glance and to write this
> email. 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

__
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


Re: [openstack-dev] [neutron][networking-ovn][tempest] devstack: gate-tempest-dsvm-networking-ovn failures in Openstack CI

2015-08-26 Thread Russell Bryant
On 08/26/2015 04:25 PM, Amitabha Biswas wrote:
 With the recent commits it seems that the
 gate-tempest-dsvm-networking-ovn is succeeding more or less every time.
 The DBDeadlock issues still are seen on q-svc logs but are not frequent
 enough to cause ovsdb failures that were leading to the dsvm-networking
 failing before.

\o/

 Once in a while a test fails for e.g.
 tempest.api.network.test_dhcp_ipv6.NetworksTestDHCPv6.test_dhcpv6_two_subnets
 that failed recently in Jenkins. But I am pretty sure it will succeed if
 the suite is re-run.

Have you looked to see if the same test is failing for the regular
neutron jobs?  Or does it seem to be OVN specific?

 Should the gate-tempest-dsvm-networking-ovn become voting at this time,
 and re-run/re-check if it fails in the Jenkins check?

That's a good question.  Maybe we should put up a test patch and recheck
it a bunch over the next few days to make sure it's as good as we think.
 If so, I'm all for making it voting asap.  Would you like to create a
test change for this?

If anything new comes up later that causes us problems, the nice thing
is that we can pretty 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?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [neutron][networking-ovn][tempest] devstack: gate-tempest-dsvm-networking-ovn failures in Openstack CI

2015-08-26 Thread Russell Bryant
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 local.conf https://review.openstack.org/#/c/216413/which
 results in
  PyMySQL as the default.
 
  With the above change the above DB errors are no longer seen in my local
  setup,
 
 It's great to hear that resolved the errors you saw!
 
   1. Is there any impact of using PyMySQL for the Jenkins check and
 gates.
 
 As Jeremy mentioned, this is what everything else is using (and what OVN
 was automatically already using in OpenStack CI).
 
   2. Why is the gate-networking-ovn-python27**failing (the past
 couple of
  commits) in {0}
  
 networking_ovn.tests.unit.test_ovn_plugin.TestOvnPlugin.test_create_port_security
  [0.194020s] ... FAILED. Do we need another conversation to track 
 this?
 
 This is a separate issue.  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't had time to dig into it yet.
 
 
 This patch was recently merged to Neutron:
 https://review.openstack.org/#/c/201141/
 
 Looks like that unit test is trying to create a port with an invalid MAC
 address.
 I pushed a fix here:
 https://review.openstack.org/#/c/216837/

Thanks, Assaf!  Much appreciated!  :-)

-- 
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


Re: [openstack-dev] [neutron][api] - attaching arbitrary key/value pairs to resources

2015-08-25 Thread Russell Bryant
On 08/25/2015 03:01 AM, Miguel Angel Ajo wrote:
 
 
 Doug Wiegley wrote:
 In general, the fight in Neutron *has* to be about common
 definitions of 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.
 I think that everyone agrees with you on this point.


 Including me.

 The tricky part comes when the speed of neutron adding to the api
 bottlenecks other things, or when the abstractions just aren’t there
 yet, because the technology in question isn’t mature enough. Do we
 provide relief valves, knowing they will be abused as much as help, or
 do we hold a hard line? These tags are a relief valve.

 I’m in favor of them, and I’m in favor of holding to the abstraction.
 It seems there has to be a middle ground.

 Thanks,
 doug

 
 
 Just thinking out loud:
 
 Probably trying to stem the tie, would it make sense to block api calls
 outside neutron core/api to grab such tags, with a big warning: if you
 try to circunvent this, you will harm interoperability of openstack, and
 your plugin will be blocked in next neutron releases..
 
 They could go directly via SQL, but at least, they'd know they're doing
 the wrong thing, and risking a plugin ban, if that's a reasonable
 measure from our side.

I don't think it's worth the effort or complexity to work too hard at
actively preventing it, but 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 to be used.

That's something we can hash out during code review 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/listinfo/openstack-dev


Re: [openstack-dev] [neutron][networking-ovn][tempest] devstack: gate-tempest-dsvm-networking-ovn failures in Openstack CI

2015-08-25 Thread Russell Bryant
On 08/25/2015 01:26 PM, Amitabha Biswas wrote:
 Russell suggested removing the MYSQL_DRIVER=MySQL-python declaration
 from local.conf https://review.openstack.org/#/c/216413/which results in
 PyMySQL as the default.
 
 With the above change the above DB errors are no longer seen in my local
 setup, 

It's great to hear that resolved the errors you saw!

  1. Is there any impact of using PyMySQL for the Jenkins check and gates.

As Jeremy mentioned, this is what everything else is using (and what OVN
was automatically already using in OpenStack CI).

  2. Why is the gate-networking-ovn-python27**failing (the past couple of
 commits) in {0}
 
 networking_ovn.tests.unit.test_ovn_plugin.TestOvnPlugin.test_create_port_security
 [0.194020s] ... FAILED. Do we need another conversation to track this?

This is a separate issue.  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't had time to dig into it yet.

-- 
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


Re: [openstack-dev] [neutron][api] - attaching arbitrary key/value pairs to resources

2015-08-25 Thread Russell Bryant
On 08/25/2015 01:00 AM, Gal Sagie wrote:
 I agree with Doug and Kevin, i think it is very hard for Neutron to keep
 the pace in every area of Networking abstraction, and i prefer
 this solution on code patching.
 I agree with Russell on the definition of Neutron end goal, but what
 good can it provide if clouds stop using Neutron because
 it doesn't provide them the appropriate support or better yet start
 solving these problems in creative ways thats ends up
 missing the entire point of Neutron. (and then clouds stop using Neutron
 because they will blame it for the lack of interoperability)
 
 I think that this is a good enough middle solution and as Armando
 suggested in the patch it self, we should work
 in a separate  task towards making the users/developers/operators
 understand (either with documentation or other methods) that the correct
 end goal would be to standardize things in the API.
 
 Implementing it like nova-tags seems to me like a good way to prevent
 too much abuse.
 
 And as i mentioned in the spec [1], there are important use cases for
 this 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 general idea of arbitrary pass-through to
backends, which you don't seem to be proposing.

-- 
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


Re: [openstack-dev] [neutron][api] - attaching arbitrary key/value pairs to resources

2015-08-24 Thread Russell Bryant
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
 will leverage these tags to leak implementation details or
 backend-specific features (e.g. tags that control QoS features, security
 isolation, or other network behaviors).
 
 However, there are many use cases that make these nice for the users of
 the API to help organize resources (e.g. external DNS names on floating
 IPs, PCI compliance status of security groups, an emoticon describing
 the seriousness of the things on that network, etc).
 
 I'm beginning to think that it might be worth it for the usefulness it
 brings to the end users. But with all of the third-party plugins
 out-of-tree, we essentially have no way to stop them from using the tags
 to control the networking backend as well.
 
 So I'm looking for feedback from the API working group as well as other
 projects that have gone down this path. Should we just take the pythonic
 we're all adults approach and try to encourage backends not to use
 them for network behavior? Or does this carry too much risk of being
 abused as a shortcut to avoid developing proper API enhancements by
 backend devs?
 
 1. https://bugs.launchpad.net/neutron/+bug/1460222
 2. https://bugs.launchpad.net/neutron/+bug/1483480
 3. https://review.openstack.org/#/c/216021/

If this is clearly documented as being a API consumer thing only, then
I'm OK with it.  Obviously it'll still be possible to be used by a
backend, but it's also possible to patch the code or provide arbitrary
API extensions, too.

The plugins may be out of tree, but the ones officially a part of
Neutron still are under oversight of the Neutron PTL/team.  Using this
in a way it's explicitly documented as not to be used would be an
example of a case where 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

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

__
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


Re: [openstack-dev] [neutron][api] - attaching arbitrary key/value pairs to resources

2015-08-24 Thread 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
 will leverage these tags to leak implementation details or
 backend-specific features (e.g. tags that control QoS features, security
 isolation, or other network behaviors).

 However, there are many use cases that make these nice for the users of
 the API to help organize resources (e.g. external DNS names on floating
 IPs, PCI compliance status of security groups, an emoticon describing
 the seriousness of the things on that network, etc).

 I'm beginning to think that it might be worth it for the usefulness it
 brings to the end users. But with all of the third-party plugins
 out-of-tree, we essentially have no way to stop them from using the tags
 to control the networking backend as well.

 So I'm looking for feedback from the API working group as well as other
 projects that have gone down this path. Should we just take the pythonic
 we're all adults approach and try to encourage backends not to use
 them for network behavior? Or does this carry too much risk of being
 abused as a shortcut to avoid developing proper API enhancements by
 backend devs?

 1. https://bugs.launchpad.net/neutron/+bug/1460222
 2. https://bugs.launchpad.net/neutron/+bug/1483480
 3. https://review.openstack.org/#/c/216021/
 
 If this is clearly documented as being a API consumer thing only, then
 I'm OK with it.  Obviously it'll still be possible to be used by a
 backend, but it's also possible to patch the code or provide arbitrary
 API extensions, too.
 
 The plugins may be out of tree, but the ones officially a part of
 Neutron still are under oversight of the Neutron PTL/team.  Using this
 in a way it's explicitly documented as not to be used would be an
 example of a case where 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
 
 Note this important line:
 
 The tag is an opaque string and is not intended to be interpreted or
 even read by the virt drivers.
 

There's an updated version of that nova spec here:

http://specs.openstack.org/openstack/nova-specs/specs/liberty/approved/tag-instances.html

-- 
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


Re: [openstack-dev] [neutron][api] - attaching arbitrary key/value pairs to resources

2015-08-24 Thread Russell Bryant
On 08/24/2015 10:33 AM, Kevin Benton wrote:
Obviously it'll still be possible to be used by a backend, but it's
 also possible to patch the code or provide arbitrary API extensions, too.
 
 
 Right, but vendor API extensions are the way that backend-specific
 features are supposed to be done. With an extension, it's explicit in
 the API via the extensions list that something non-standard is enabled.
 
 Patching code is currently pretty brittle and puts a lot of technical
 debt on a driver author's part so it's pretty obvious 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 are
harmful and shouldn't be allowed going forward, either.

-- 
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


Re: [openstack-dev] [neutron][api] - attaching arbitrary key/value pairs to resources

2015-08-24 Thread Russell Bryant
On 08/24/2015 01:58 PM, Jay Pipes wrote:
 On 08/24/2015 07:33 AM, Kevin Benton wrote:
  Obviously it'll still be possible to be used by a backend, but it's
 also possible to patch the code or provide arbitrary API extensions, too.


 Right, but vendor API extensions are the way that backend-specific
 features are supposed to be done. With an extension, it's explicit in
 the API via the extensions list that something non-standard is enabled.

 Patching code is currently pretty brittle and puts a lot of technical
 debt on a driver author's part so it's pretty obvious 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. :)
 
 As Russell mentions, my idea of simple string tagging is that it is
 entirely user-driven (ala Launchpad's tagging of bugs -- there is no
 systemic collation or curation of tags).
 
 If you need system-defined and protected attributes, you should use a
 separate resource on the network or port, ala the port binding profile,
 which to date has been (ab)used for the purpose of communicating
 backend-specific metadata.

Yeah, I think the port binding profile is a good example of something
not to repeat.

I took advantage of it to prototype a feature here:

http://docs.openstack.org/developer/networking-ovn/containers.html

It let me implement a backend specific feature quickly and expose it
through the Neutron API.  It would be very easy to just call it done and
move on.  However, the right thing to do is to define a proper Neutron
API to express what 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

__
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


Re: [openstack-dev] [neutron][api] - attaching arbitrary key/value pairs to resources

2015-08-24 Thread Russell Bryant
On 08/24/2015 05:25 PM, Doug Wiegley wrote:
 I took advantage of it to prototype a feature her
 
 That right there is the crux of the objections so far. Don’t get me
 wrong, I’d love this, and would abuse it within an inch of its life
 regularly.
 
 The alternative is sometimes even worse than a vendor extension or
 plugin.  Take for example, wanting to add a new load balancing
 algorithm, like LEAST_MURDERED_KITTENS. The current list is
 hard-coded all over the dang place, so you end up shipping neutron
 patches or monkey patches. Opaque pass-through to the driver is evil
 from an interoperability standpoint, but in terms of extending code
 at the operators choosing, there are MUCH worse sins that are
 actively being committed.

I don't think even worse code makes this what's proposed here seem any
better.  I'm not really sure what you're saying.

 Flavors covers this use case, but in a way that’s up to the operators
 to setup, and not as easy for devs to deal with.
 
 Whether the above sounds like it’s a bonus or a massive reason not to
 do this will entirely lie in the eye of the beholder, but the vendor
 extension use case WILL BE USED, no matter what we say.

Interop really is a key part of this.  If we look at this particular
case, yes, I get that there are lots of LB algorithms out there and that
it makes sense to expose that choice to users.  However, I do think
what's best for users is to define and document each of them very
explicitly.  The end user should know that if they choose algorithm
BEST_LB_EVER, that it means the same thing on cloud A vs cloud B.  The
way to do that is to have it defined explicitly by Neutron and not punt.

Maybe in practice the Neutron defined set is a subset of what's
available overall, and the custom (vendor) ones can be clearly marked as
such.  In any case, I'm just trying to express what goal I think we
should be striving for.

In general, the fight in Neutron *has* to be about common definitions of
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

__
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


Re: [openstack-dev] [neutron] What does being a neutron-core member mean? [WAS: Re: [neutron] I am pleased to propose two new Neutron API/DB/RPC core reviewers!]

2015-08-14 Thread Russell Bryant
While this includes me, I'm really not taking this personally.  I'm
thinking about it in the general sense.

On 08/14/2015 11:03 AM, Kyle Mestery wrote:
 I'd argue the system is built on a web of trust. If you trust me, and I
 trust Russell and Brandon, then you should likely trust Russell and
 Brandon as well. This is EXACTLY what the Lieutenant system was meant to
 convey, though I now feel like perhaps people missed this key ingredient
 of the new world we find ourselves in.

This is a huge and important point.  The N to N trust model we've been
operating under doesn't scale.  Neutron is trying to move to a different
trust model that has proven to scale much further than we've been able
to do within a single OpenStack project so far.

If Kyle and others leading a section of Neutron trust me, I'm happy to
jump in and do more reviews.  If they trust me, I'd hope others not as
familiar with me or my work can trust by proxy.  The same applies to
Brandon.  I honestly don't know Brandon very well, but I have a high
level of trust for Kyle.  Kyle trusts him, so +1 from me.

Kyle has a tough role 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 that.  It
only works if everyone buys into this way of thinking.

-- 
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


Re: [openstack-dev] [PATCH v4 2/5] ovn: Add bridge mappings to ovn-controller.

2015-07-31 Thread 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 and an OVS bridge that provides
 connectivity to that network.
 
 For example, if you wanted to configure physnet1 to map to br-eth0
 and physnet2 to map to br-eth1, the configuration would be:
 
   $ ovs-vsctl set open . \
external-ids:ovn-bridge-mappings=physnet1:br-eth0,physnet2:br-eth1
 
 Patch ports between these bridges and the integration bridge are
 automatically created and also removed if necessary when the
 configuration changes.
 
 Documentation for this configuration value is introduced in a later
 patch that makes use of this by introducing a localnet logical port
 type.
 
 Signed-off-by: Russell Bryant rbry...@redhat.com
 +static void
 +create_patch_port(struct controller_ctx *ctx,
 +  const char *network,
 +  const struct ovsrec_bridge *b1,
 +  const struct ovsrec_bridge *b2)
 +{
 +struct ovsrec_interface *iface;
 +struct ovsrec_port *port, **ports;
 +size_t i;
 +char *port_name;
 +
 +port_name = xasprintf(patch-%s-to-%s, b1-name, b2-name);
 +
 +ovsdb_idl_txn_add_comment(ctx-ovs_idl_txn,
 +ovn-controller: creating patch port '%s' from '%s' to '%s',
 +port_name, b1-name, b2-name);

This will blow up if ctx-ovs_idl_txn is NULL, which happens under
normal cirumstances.


 @@ -271,6 +495,10 @@ main(int argc, char *argv[])
  const struct ovsrec_bridge *br_int = get_br_int(ctx.ovs_idl);
  const char *chassis_id = get_chassis_id(ctx.ovs_idl);
  
 +/* Map bridges to local nets from ovn-bridge-mappings */
 +struct smap bridge_mappings = SMAP_INITIALIZER(bridge_mappings);
 +init_bridge_mappings(ctx, br_int, bridge_mappings);
 +

This should make sure br_int isn't NULL first.

-- 
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


Re: [openstack-dev] [neutron][upgrades] Potential issues when performing Neutron upgrades

2015-07-13 Thread Russell Bryant
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 written anything down yet, but here's what I expect.

Right now we're still changing the db schema however is needed without
messing with versioning.  As we get to production ready, I expect
we'll start being strict about only making backwards compatible ovsdb
schema changes to make upgrades easier.

There are 2 central components - ovn-northd and ovsdb-server - that
would be upgraded 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

__
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


Re: [openstack-dev] [neutron][upgrades] Potential issues when performing Neutron upgrades

2015-07-13 Thread Russell Bryant
On 07/13/2015 05:08 PM, Kevin Benton wrote:
 Thanks for the info. So the equivalent in neutron would be if we just
 ensure backward compatible AMQP APIs, right?

There's a few parts:

1) Backwards compatibility with changes to the oslo.messaging APIs using
API versioning (what you're referring to, I think).  Neutron does this
(though not tested in a mixed version mid-upgrade environment yet).

2) Compatibility of the data sent over those interfaces.  This is where
oslo.versionedobjects comes in.  Breakage here is much easier to miss
since it's not always obvious when you're modifying a data structure
that's sent over the wire.  There has been a ton of work in Nova to
version the data sent over the wire and have the ability for a service
(nova-conductor in nova's case) to be able to convert objects back to a
version that an older service can understand.  This is the most likely
way Neutron will break rolling upgrades right now, especially since it's
not tested.

3) DB schema.  Depending on what services access the db directly and
what the rolling upgrade strategy is, there may be some additional
constraints on making sure the db schema is backwards copmatible, too.

-- 
Russell 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 written anything down yet, but here's what I expect.
 
 Right now we're still changing the db schema however is needed without
 messing with versioning.  As we get to production ready, I expect
 we'll start being strict about only making backwards compatible ovsdb
 schema changes to make upgrades easier.
 
 There are 2 central components - ovn-northd and ovsdb-server - that
 would be upgraded 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
 
 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe:
 openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 
 
 
 -- 
 Kevin Benton
 
 
 __
 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

__
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


Re: [openstack-dev] [neutron][upgrades] Potential issues when performing Neutron upgrades

2015-07-09 Thread Russell Bryant
On 07/09/2015 10:11 AM, Ihar Hrachyshka wrote:
 On 07/09/2015 09:01 AM, Artur Korzen wrote:
 Hi all,
 
 I've been researching the Neutron project as a part of work on 
 Openstack rolling upgrades, my primary assignments included
 testing if there is no VM access downtime when performing
 upgrade.
 
 
 
 Are you aware of any issues that are present in Liberty release
 of Neutron, that may cause the VM access downtime and may stop
 ops to pick up newest versions of code?
 
 
 
 When talking about no VM access downtime during upgrade, the 
 sensitive operations are:
 
 1. ensure that even after neutron services is
 shutoff/uninstalled, the traffic can go into the VM 2. take care
 on neutron services startup/installation that existing
 configuration is preserved (routing tables, forwarding entries
 and security rules) 3. the underlying network technologies (OVS,
 linux bridges etc.) is working without distraction when upgrading
 neutron code: no dropping table flows or applying the traffic
 rules to drop the packages
 
 
 
 To be compatible between different versions of service talking
 to each other, the important areas are:
 
 1. RPC API versioning 2. Objects exchanged between services via 
 RPC 3. Database schema (bp [2]) and data migration
 
 
 
 I have researched the ML2 plugin with ovs agent, including the 
 neutron-ovs-agent, dhcp-server, l3-agent, neutron-server.
 
 One of the VM access downtime during upgrade is addressed in [1],
  removing the flows in ovs after neutron agent restarts.
 
 
 
 Is Neutron ready to be upgradable with minimal downtime of
 services and no VM access downtime?
 
 As the ovs bug you refer to above, no, at least not in reference 
 implementation. That's for data plane.
 
 As for other services, neutron-server online schema migration
 should help, and I hope to get it implemented in L (though there
 are some obstacles that may block us; we'll see).
 
 As for live data migration, neutron code base is not ready yet to 
 reasonably require live data migration being implemented in all 
 patches that need data moves in database. The very first obstacle
 for that is that there is no middleware layer between sqlalchemy
 and the rest of neutron that would allow us to hide migration
 details. Oslo.versionedobjects is such a middleware. See below.
 
 
 Are there any guidelines on using the oslo versionobjects and its
  priority in Liberty cycle?
 
 It's not a common priority for L, but we've started on this road 
 inside feature/qos branch that will hopefully get into master some 
 time after L-2. If interested, see:
 
 http://git.openstack.org/cgit/openstack/neutron/tree/neutron/objects?h=f

 
eature/qos
 
 Once the feature branch is merged into master, I plan to start 
 converting existing resources to objects. It may take time and
 will definitely span to M. Depending on progress in this regard,
 we'll see whether we will be able to consider live data migration.
 At the moment, I don't see it happening in M, at least not at the
 start of it.
 
 
 Are there use-cases written down when talking about Neutron 
 upgrades?
 
 One thing that is currently in review are partial upgrades. They
 are tested for nova (including nova-network) but not for neutron,
 so it's considered a nova-network/neutron parity issue.
 
 You should find most of relevant patches in:
 
 https://review.openstack.org/#/q/owner:%22Russell+Bryant%22+status:open,

 
n,z

Yes, there's a ton of work to make rolling upgrades as robust as what
Nova has done.  There's significant limitations to what Neutron can do
without breaking it, but hopefully the grenade job would help us catch
things 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 not sure if anyone has tried it out recently.

All of the things discussed here sound like good things to work on.  I
actually thought a group was going to work on versioned objects for
Kilo, but that never materialized.

I'll also plug a project I'm working on (OVN, part 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 (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [grenade] future direction on partial upgrade support

2015-06-24 Thread Russell Bryant
On 06/24/2015 01:31 PM, Joe Gordon wrote:
 
 
 On Tue, Jun 16, 2015 at 9:58 AM, Sean Dague s...@dague.net
 mailto:s...@dague.net wrote:
 
 Back when Nova first wanted to test partial upgrade, we did a bunch of
 slightly odd conditionals inside of grenade and devstack to make it so
 that if you were very careful, you could just not stop some of the old
 services on a single node, upgrade everything else, and as long as the
 old services didn't stop, they'd be running cached code in memory, and
 it would look a bit like a 2 node worker not upgraded model. It worked,
 but it was weird.
 
 There has been some interest by the Nova team to expand what's not being
 touched, as well as the Neutron team to add partial upgrade testing
 support. Both are great initiatives, but I think going about it the old
 way is going to add a lot of complexity in weird places, and not be as
 good of a test as we really want.
 
 Nodepool now supports allocating multiple nodes. We have a multinode job
 in Nova regularly testing live migration using this.
 
 If we slice this problem differently, I think we get a better
 architecture, a much easier way to add new configs, and a much more
 realistic end test.
 
 Conceptually, use devstack-gate multinode support to set up 2 nodes, an
 all in one, and a worker. Let grenade upgrade the all in one, leave the
 worker alone.
 
 I think the only complexity here is the fact that grenade.sh implicitly
 drives stack.sh. Which means one of:
 
 1) devstack-gate could build the worker first, then run grenade.sh
 
 2) we make it so grenade.sh can execute in parts more easily, so it can
 hand something else running stack.sh for it.'
 
 3) we make grenade understand the subnode for partial upgrade, so it
 will run the stack phase on the subnode itself (given credentials).
 
 This kind of approach means deciding which services you don't want to
 upgrade doesn't require devstack changes, it's just a change of the
 services on the worker.
 
 We need a volunteer for taking this on, but I think all the follow on
 partial upgrade support will be much much easier to do after we have
 this kind of mechanism in place.
 
 
 I think this is a great approach for the future of partial upgrade
 support in grenade. I would like to point out step 0 here, is to get
 tempest passing consistently in multinode.
 
 Currently the neutron job is failing consistently, and nova-network
 fails roughly 10% of the time due
 to https://bugs.launchpad.net/nova/+bug/1462305
 and https://bugs.launchpad.net/nova/+bug/1445569

If multi-node isn't reliable more generally yet, do you think the
simpler implementation of partial-upgrade testing could proceed?  I've
already done all of the patches to do it for Neutron.  That way we could
quickly get something in place to help block regressions and work on the
longer-term multinode refactoring without as much time pressure.

For reference, the Neutron related partial-upgrade test related patches are:

devstack patches:
  https://review.openstack.org/189408
  https://review.openstack.org/189707
  https://review.openstack.org/189710

grenade patches:
  https://review.openstack.org/189417
  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

__
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


Re: [openstack-dev] [grenade] future direction on partial upgrade support

2015-06-24 Thread Russell Bryant
On 06/24/2015 01:49 PM, Dan Smith wrote:
 If multi-node isn't reliable more generally yet, do you think the
 simpler implementation of partial-upgrade testing could proceed?  I've
 already done all of the patches to do it for Neutron.  That way we could
 quickly get something in place to help block regressions and work on the
 longer-term multinode refactoring without as much time pressure.
 
 I was going to ask the same about the (arguably MUUCH tinier) patch to
 include nova-net in the nova-compute partial upgrade bin.
 
 I know the right answer is working on the multinode job, but fixing that
 and then extending grenade to work that way is a significant amount of
 work. The fact that we're not testing nova-net with nova-compute
 properly right now and claiming we're safe is just lying to ourselves.

Yeah, that's certainly a tiny change.  There are several Neutron
patches, but they're all pretty simple IMO.

I picked up this task to help with the Neutron and nova-network parity
work.  It tests the backend that isn't even my primary focus/interest,
but I still wanted to help the parity work along.  If it ends up
requiring this significant extra work, I'll honestly most likely 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
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


  1   2   3   4   5   6   7   8   9   >