date:20160615


On 6/14/2016 8:57 AM, Thierry Carrez wrote:

Hi everyone,

I just proposed a new requirement for OpenStack "official" projects,
which I think is worth discussing beyond the governance review:

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

From an upstream perspective, I see us as being in the business of
providing open collaboration playing fields in order to build projects
to reach the OpenStack Mission. We collectively provide resources
(infra, horizontal teams, events...) in order to enable that open
collaboration.

An important characteristic of these open collaboration grounds is that
they need to be a level playing field, where no specific organization is
being given an unfair advantage. I expect the teams that we bless as
"official" project teams to operate in that fair manner. Otherwise we
end up blessing what is essentially a trojan horse for a given
organization, open-washing their project in the process. Such a project
can totally exist as an unofficial project (and even be developed on
OpenStack infrastructure) but I don't think it should be given free
space in our Design Summits or benefit from "OpenStack community" branding.

So if, in a given project team, developers from one specific
organization benefit from access to specific knowledge or hardware
(think 3rd-party testing blackboxes that decide if a patch goes in, or
access to proprietary hardware or software that the open source code
primarily interfaces with), then this project team should probably be
rejected under the "open community" rule. Projects with a lot of drivers
(like Cinder) provide an interesting grey area, but as long as all
drivers are in and there is a fully functional (and popular) open source
implementation, I think no specific organization would be considered as
unfairly benefiting compared to others.

A few months ago we had the discussion about what "no open core" means
in 2016, in the context of the Poppy team candidacy. With our reading at
the time we ended up rejecting Poppy partly because it was interfacing
with proprietary technologies. However, I think what we originally
wanted to ensure with this rule was that no specific organization would
use the OpenStack open source code as crippled bait to sell their
specific proprietary add-on.

I think taking the view that OpenStack projects need to be open, level
collaboration playing fields encapsulates that nicely. In the Poppy
case, nobody in the Poppy team has an unfair advantage over others, so
we should not reject them purely on the grounds that this interfaces
with non-open-source solutions (leaving only the infrastructure/testing
requirement to solve). On the other hand, a Neutron plugin targeting a
specific piece of networking hardware would likely give an unfair
advantage to developers of the hardware's manufacturer (having access to
that gear for testing and being able to see and make changes to its
proprietary source code) -- that project should probably live as an
unofficial OpenStack project.

Comments, thoughts ?



Being someone that doesn't attend TC meetings and doesn't follow every 
thread for every project in OpenStack, I'm having a hard time with 
concrete examples and what this means. I have a feeling a lot of this 
has to do with Neutron stadium stuff, which I haven't been following 
either, except I think it's getting reigned in (at least that's what I 
remember from the mitaka midcycle discussion).


From the Nova POV I'm really just reading this as compute drivers. We 
have some in tree and some out of tree. Among the ones in tree we have a 
wide mix when it comes to feature parity, in part because a lot of the 
early Nova API was written with libvirt and xenapi in mind (e.g. 
agent-builds for xen), or specific volume drivers interacting with a 
specific compute driver (e.g. os-assisted-volume-snapshots with 
libvirt). And then we have vmcenter, hyper-v and ironic.


And we have out of tree drivers, like zvm, lxd and powervm. powervm is 
actively trying to get in tree. lxd is not, nor is zvm (at least I don't 
hear anything from the zvm developers).


But taking zVM for example, I don't have a mainframe sitting around in 
my basement, so I can't test changes for that. Or a Power8 system for 
testing powervm. But that's why we require third party CI for things 
that we don't test in community infra.


So is the question does Nova provide a level playing field as a project 
because it has drivers that can be deployed and used and tested without 
special hardware, i.e. libvirt? Then yes. Or is it Nova doesn't provide 
a level playing field because zVM and powervm aren't in tree?


If this is really just, random project wants to be considered an 
'official' OpenStack project but is totally unusable without a 
proprietary stack to deploy and run it - which makes it completely 
vendor specific, regardless of whether or not they open sourced the 
front-end to talk to their proprietary backend, so only developers from 
said vendor can work on the

[openstack-dev] [networking-bagpipe] how to deploy devstack with bgpvpn and bagpipe driver

2016-06-15 Thread Li Ma

Hi all,

I would like to evaluate bgpvpn and bagpipe driver in my local
machine. I cannot find any useful deployment guide about it.

I find a github repository for it, but it seems out of date (3 months
ago). I'd appreciate it if someone can provide a working devstack
configuration for multiple nodes.

Best regards,
-- 

Li Ma (Nick)
Email: skywalker.n...@gmail.com

__
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][os-vif] Expanding vif capability for wiring trunk ports

On 6/13/2016 3:35 AM, Daniel P. Berrange wrote:

On Thu, Jun 09, 2016 at 05:31:13PM -0600, Carl Baldwin wrote:

Hi,

You may or may not be aware of the vlan-aware-vms effort [1] in
Neutron. If not, there is a spec and a fair number of patches in
progress for this. Essentially, the goal is to allow a VM to connect
to multiple Neutron networks by tagging traffic on a single port with
VLAN tags.

This effort will have some effect on vif plugging because the datapath
will include some changes that will effect how vif plugging is done
today.

The design proposal for trunk ports with OVS adds a new bridge for
each trunk port. This bridge will demux the traffic and then connect
to br-int with patch ports for each of the networks. Rawlin Peters
has some ideas for expanding the vif capability to include this
wiring.

There is also a proposal for connecting to linux bridges by using
kernel vlan interfaces.

This effort is pretty important to Neutron in the Newton timeframe. I
wanted to send this out to start rounding up the reviewers and other
participants we need to see how we can start putting together a plan
for nova integration of this feature (via os-vif?).

I've not taken a look at the proposal, but on the timing side of things
it is really way to late to start this email thread asking for design
input from os-vif or nova. We're way past the spec proposal deadline
for Nova in the Newton cycle, so nothing is going to happen until the
Ocata cycle no matter what Neutron want in Newton. For os-vif our
focus right now is exclusively on getting existing functionality ported
over, and integrated into Nova in Newton. So again we're not really looking
to spend time on further os-vif design work right now.

In the Ocata cycle we'll be looking to integrate os-vif into Neutron to
let it directly serialize VIF objects and send them over to Nova, instead
of using the ad-hoc port-binding dicts. From the Nova side, we're not
likely to want to support any new functionality that affects port-binding
data until after Neutron is converted to os-vif. So Ocata at the earliest,
but probably more like P, unless the Neutron conversion to os-vif gets
completed unexpectedly quickly.

Regards,
Daniel

+1. Nova is past non-priority spec approval freeze for Newton. With
respect to os-vif it's a priority to integrate that into Nova in Newton [1].

We're also working on refactoring how we allocate and bind ports when
creating a server [2]. This is a dependency for the routed networks work
and it's also going to bump up against the changes I'm making in nova
for get-me-a-network in Newton (which is another priority).

So if vlan-aware-vms changes how nova allocates/binds ports, that's
going to be dependent on this also, and will have to be worked into the
Ocata release from Nova's POV.

[1]
https://specs.openstack.org/openstack/nova-specs/priorities/newton-priorities.html#os-vif-integration
[2]
http://specs.openstack.org/openstack/nova-specs/specs/newton/approved/prep-for-network-aware-scheduling.html

Thanks,

Matt Riedemann

__
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] [tacker] Proposing Kanagaraj Manickam to Tacker core team

2016-06-15 Thread Sridhar Ramaswamy

Tackers,

It gives me great pleasure to propose Kanagaraj Manickam to join the Tacker
core team. In a short time, Kanagaraj has grown into a key member of the
Tacker team. His enthusiasm and dedication to get Tacker code base on par
with other leading OpenStack projects is very much appreciated. He is
already working on two important specs in Newton cycle and many more fixes
and RFEs [1]. Kanagaraj is also a core member in the Heat project and this
lends well as we heavily use Heat for many Tacker features.

Please provide your +1/-1 votes.

- Sridhar

[1]
http://stackalytics.com/?module=tacker-group_id=kanagaraj-manickam=marks
__
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] [Congress] Progress on Congress support in OPNFV Colorado

2016-06-15 Thread Eric K

Very exciting development indeed!

From:  "SULLIVAN, BRYAN L" 
Reply-To:  "OpenStack Development Mailing List (not for usage questions)"

Date:  Tuesday, June 14, 2016 at 8:58 PM
To:  "OpenStack Development Mailing List (not for usage questions)"

Cc:  "opnfv-tech-disc...@lists.opnfv.org"

Subject:  [openstack-dev] [Congress] Progress on Congress support in OPNFV
Colorado

> Hi Congress team,
>  
> A quick update on progress at OPNFV on integrating Congress into the OPNFV
> Colorado release (Mitaka-based). With the help of RedHat (Dan Radez) and
> Canonical (Narinder Gupta, Liam Young) we are getting very close to
> upstreaming two key things to OpenStack:
> - Congress Puppet module
> 
> o  https://github.com/radez/puppet-congress has been tested successfully for
> the OPNFV Colorado release on Centos 7 hosts.
> 
> o  This will be used in the base OPNFV deploy for the Apex project (RDO-based
> installer).
> 
> o  Dan is in the process of creating the official Puppet repo at
> https://github.com/openstack/puppet-congress
> 
> - Congress JuJu Charm
> 
> o  https://github.com/gnuoy/charm-congress has been tested successfully for
> the OPNFV Colorado release on Ubuntu Trusty and Xenial hosts.
> 
> o  This will be used in the base OPNFV deploy for the JOID project
> (MAAS/JuJu-based installer).
> 
> o  Canonical has asked me to initiate the creation of the
> https://github.com/openstack/charm-congress repo to host this. I¹d appreciate
> any help/pointers as to how to get that started.
> 
>  
> This module and charm will help other OPNFV projects (e.g. Doctor) as Congress
> will be installed by default on the OPNFV platform, with the necessary
> datasource drivers and configuration ready to go.
>  
> I have three policy test cases that are working reliably for Mitaka (see
> https://git.opnfv.org/cgit/copper/tree/tests), soon to be integrated into the
> OPNFV CI/CD program, and will demo them at the upcoming OPNFV Summit in Berlin
> next week. I¹ll be adding other tests and developing a tested policy library
> once I get over the hurdles of completing the installer support (including for
> FUEL and Compass, the other two OPNFV installer projects).
>  
> Feels like it¹s been a long road, but also that we are nearing a major
> milestone!
>  
> Thanks,
> Bryan Sullivan | AT
>  
> __
> 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] [qa] Tempest pre-provisioned credentials in the gate

2016-06-15 Thread Ghanshyam Mann

Big +1 for that which makes pre-provisioned cred testing more thoroughly.

And at the end we should divide the existing jobs among dynamic and 
pre-provisioned account so that we would not leave any of them less tested.

Thanks
gmann
From: Andrea Frittoli [mailto:andrea.fritt...@gmail.com]
Sent: 15 June 2016 09:01
To: OpenStack Development Mailing List (not for usage questions) 

Subject: [openstack-dev] [qa] Tempest pre-provisioned credentials in the gate

Dear all,

TL;DR: I'd like to propose to start running some of the existing dsvm 
check/gate jobs using Tempest pre-provisioned credentials.

Full Text:
Tempest provides tests with two mechanisms to acquire test credentials [0]: 
dynamic credentials and pre-provisioned ones.

The current check and gate jobs only use the dynamic credentials provider.

The pre-provisioned credentials provider has been introduced to support running 
test in parallel without the need of having access to admin credentials in 
tempest configuration file - which is a valid use case especially when testing 
public clouds or in general a deployment that is not own by who runs the test.

As a small extra, since pre-provisioned credentials are re-used to run many 
tests during a CI test run, they give an opportunity to discover issues related 
to cleanup of test resources.

Pre-provisioned credentials is currently used in periodic jobs [1][2] - as well 
as an experimental job defined for tempest changes. This means that even if we 
are careful, there is a good chance for it to be inadvertently broken by a 
change.

Until recently the periodic job suffered a racy failure on object-storage 
tests. A recent refactor [3] of the tool that pre-proprovisioned the accounts 
has fixed the issue: the past 8 runs of the periodic jobs have not encountered 
that race anymore [4][5].

Specifically I'd like to propose changing to start changing of the neutron jobs 
[6].

Andrea Frittoli

[0] 
http://docs.openstack.org/developer/tempest/configuration.html#credential-provider-mechanisms
[1] 
http://git.openstack.org/cgit/openstack-infra/project-config/tree/jenkins/jobs/devstack-gate.yaml#n220
[2] 
http://git.openstack.org/cgit/openstack-infra/project-config/tree/jenkins/jobs/devstack-gate.yaml#n253
[3] https://review.openstack.org/#/c/317105/
[4] 
http://status.openstack.org/openstack-health/#/job/periodic-tempest-dsvm-full-test-accounts-master
[5] 
http://status.openstack.org/openstack-health/#/job/periodic-tempest-dsvm-neutron-full-test-accounts-master
[6] https://review.openstack.org/329723

__
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] [cinder] No middle-man - when does/will Nova directly connect iSCSI volumes?

2016-06-15 Thread Preston L. Bannister

QEMU has the ability to directly connect to iSCSI volumes. Running the
iSCSI connections through the nova-compute host *seems* somewhat
inefficient.

There is a spec/blueprint and implementation that landed in Kilo:

https://specs.openstack.org/openstack/nova-specs/specs/kilo/implemented/qemu-built-in-iscsi-initiator.html
https://blueprints.launchpad.net/nova/+spec/qemu-built-in-iscsi-initiator

>From looking at the OpenStack Nova sources ... I am not entirely clear on
when this behavior is invoked (just for Ceph?), and how it might change in
future.

Looking for a general sense where this is headed. (If anyone knows...)

If there is some problem with QEMU and directly attached iSCSI volumes,
that would explain why this is not the default. Or is this simple inertia?

I have a concrete concern. I work for a company (EMC) that offers backup
products, and we now have backup for instances in OpenStack. To make this
efficient, we need to collect changed-block information from instances.

1)  We could put an intercept in the Linux kernel of the nova-compute host
to track writes at the block layer. This has the merit of working for
containers, and potentially bare-metal instance deployments. But is not
guaranteed for instances, if the iSCSI volumes are directly attached to
QEMU.

2)  We could use the QEMU support for incremental backup (first bit landed
in QEMU 2.4). This has the merit of working with any storage, by only for
virtual machines under QEMU.

As our customers are (so far) only asking about virtual machine backup. I
long ago settled on (2) as most promising.

What I cannot clearly determine is where (1) will fail. Will all iSCSI
volumes connected to QEMU instances eventually become directly connected?

Xiao's unanswered query (below) presents another question. Is this a
site-choice? Could I require my customers to configure their OpenStack
clouds to always route iSCSI connections through the nova-compute host? (I
am not a fan of this approach, but I have to ask.)

To answer Xiao's question, can a site configure their cloud to *always*
directly connect iSCSI volumes to QEMU?

On Tue, Feb 16, 2016 at 4:54 AM, Xiao Ma (xima2)  wrote:

> Hi, All
>
> I want to make the qemu communicate with iscsi target using libiscsi
> directly, and I
> followed https://review.openstack.org/#/c/135854/ to add
> 'volume_drivers = iscsi=nova.virt.libvirt.volume.LibvirtNetVolumeDriver’
>  in nova.conf
>  and then restarted nova services and cinder services, but still the
> volume configuration of vm is as bellow:
>
> 
>   
>dev='/dev/disk/by-path/ip-10.75.195.205:3260-iscsi-iqn.2010-10.org.openstack:volume-076bb429-67fd-4c0c-9ddf-0dc7621a975a-lun-0'/>
>   
>   076bb429-67fd-4c0c-9ddf-0dc7621a975a
>function='0x0'/>
> 
>
>
> I use centos7 and Liberty version of OpenStack.
> Could anybody tell me how can I achieve it?
>
>
> Thanks.
>
__
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] [app-catalog] App Catalog IRC meeting Thursday June 16th

2016-06-15 Thread Christopher Aedo

Join us Thursday for our weekly meeting, scheduled for June 16th at
17:00UTC in #openstack-meeting-3

The agenda can be found here, and please add to if you want to discuss
something with the Community App Catalog team:
https://wiki.openstack.org/wiki/Meetings/app-catalog

In addition to status updates, we will continue the conversation
around the Application Development improvement effort being led by
Igor Marnat.

Hope to see you there tomorrow!

__
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] [tempest][nova][defcore] Add option to disable some strict response checking for interop testing

2016-06-15 Thread Matthew Treinish

On Wed, Jun 15, 2016 at 09:10:30AM -0400, Doug Hellmann wrote:
> Excerpts from Chris Hoge's message of 2016-06-14 16:37:06 -0700:
> > Top posting one note and direct comments inline, I’m proposing
> > this as a member of the DefCore working group, but this
> > proposal itself has not been accepted as the forward course of
> > action by the working group. These are my own views as the
> > administrator of the program and not that of the working group
> > itself, which may independently reject the idea outside of the
> > response from the upstream devs.
> > 
> > I posted a link to this thread to the DefCore mailing list to make
> > that working group aware of the outstanding issues.
> > 
> > > On Jun 14, 2016, at 3:50 PM, Matthew Treinish  
> > > wrote:
> > > 
> > > On Tue, Jun 14, 2016 at 05:42:16PM -0400, Doug Hellmann wrote:
> > >> Excerpts from Matthew Treinish's message of 2016-06-14 15:12:45 -0400:
> > >>> On Tue, Jun 14, 2016 at 02:41:10PM -0400, Doug Hellmann wrote:
> >  Excerpts from Matthew Treinish's message of 2016-06-14 14:21:27 -0400:
> > > On Tue, Jun 14, 2016 at 10:57:05AM -0700, Chris Hoge wrote:
> > >> Last year, in response to Nova micro-versioning and extension 
> > >> updates[1],
> > >> the QA team added strict API schema checking to Tempest to ensure 
> > >> that
> > >> no additional properties were added to Nova API responses[2][3]. In 
> > >> the
> > >> last year, at least three vendors participating the the OpenStack 
> > >> Powered
> > >> Trademark program have been impacted by this change, two of which
> > >> reported this to the DefCore Working Group mailing list earlier this 
> > >> year[4].
> > >> 
> > >> The DefCore Working Group determines guidelines for the OpenStack 
> > >> Powered
> > >> program, which includes capabilities with associated functional tests
> > >> from Tempest that must be passed, and designated sections with 
> > >> associated
> > >> upstream code [5][6]. In determining these guidelines, the working 
> > >> group
> > >> attempts to balance the future direction of development with lagging
> > >> indicators of deployments and user adoption.
> > >> 
> > >> After a tremendous amount of consideration, I believe that the 
> > >> DefCore
> > >> Working Group needs to implement a temporary waiver for the strict 
> > >> API
> > >> checking requirements that were introduced last year, to give 
> > >> downstream
> > >> deployers more time to catch up with the strict micro-versioning
> > >> requirements determined by the Nova/Compute team and enforced by the
> > >> Tempest/QA team.
> > > 
> > > I'm very much opposed to this being done. If we're actually concerned 
> > > with
> > > interoperability and verify that things behave in the same manner 
> > > between multiple
> > > clouds then doing this would be a big step backwards. The fundamental 
> > > disconnect
> > > here is that the vendors who have implemented out of band extensions 
> > > or were
> > > taking advantage of previously available places to inject extra 
> > > attributes
> > > believe that doing so means they're interoperable, which is quite far 
> > > from
> > > reality. **The API is not a place for vendor differentiation.**
> >  
> >  This is a temporary measure to address the fact that a large number
> >  of existing tests changed their behavior, rather than having new
> >  tests added to enforce this new requirement. The result is deployments
> >  that previously passed these tests may no longer pass, and in fact
> >  we have several cases where that's true with deployers who are
> >  trying to maintain their own standard of backwards-compatibility
> >  for their end users.
> > >>> 
> > >>> That's not what happened though. The API hasn't changed and the tests 
> > >>> haven't
> > >>> really changed either. We made our enforcement on Nova's APIs a bit 
> > >>> stricter to
> > >>> ensure nothing unexpected appeared. For the most these tests work on 
> > >>> any version
> > >>> of OpenStack. (we only test it in the gate on supported stable 
> > >>> releases, but I
> > >>> don't expect things to have drastically shifted on older releases) It 
> > >>> also
> > >>> doesn't matter which version of the API you run, v2.0 or v2.1. 
> > >>> Literally, the
> > >>> only case it ever fails is when you run something extra, not from the 
> > >>> community,
> > >>> either as an extension (which themselves are going away [1]) or another 
> > >>> service
> > >>> that wraps nova or imitates nova. I'm personally not comfortable saying 
> > >>> those
> > >>> extras are ever part of the OpenStack APIs.
> > >>> 
> >  We have basically three options.
> >  
> >  1. Tell deployers who are trying to do the right for their immediate
> >    users that they can't use the

Re: [openstack-dev] [ovs-discuss] [OVN] [networking-ovn] [networking-sfc] SFC andOVN

2016-06-15 Thread John McDowall

Ryan,

In-line

Regards

John

From: Ryan Moats >
Date: Tuesday, June 14, 2016 at 9:42 PM
To: John McDowall 
>
Cc: Na Zhu >, Srilatha Tangirala 
>, "OpenStack Development 
Mailing List (not for usage questions)" 
>, 
discuss >
Subject: Re: [ovs-discuss] [openstack-dev] [OVN] [networking-ovn] 
[networking-sfc] SFC andOVN

"discuss" 
> wrote 
on 06/14/2016 10:31:40 PM:

> From: John McDowall 
> >
> To: Na Zhu >
> Cc: Srilatha Tangirala/San Francisco/IBM@IBMUS, "OpenStack
> Development Mailing List \(not for usage questions\)"  d...@lists.openstack.org>, discuss 
> >
> Date: 06/14/2016 10:48 PM
> Subject: Re: [ovs-discuss] [openstack-dev] [OVN] [networking-ovn]
> [networking-sfc] SFC andOVN
> Sent by: "discuss" 
> >
>
> Juno,
>
> It is a container for port-pair-groups and flow-classifier. I
> imagine there could be more the than one port-chain per switch. Also
> we may want to extend the model beyond a single lswitch

I agree that there could be more than one port-chain per switch, determined
by the flow classifier.

What I'm confused by is:

1. Why are items only recorded in logical switches?  I would think
that I could also attach an SFC to a logical router - although I admit
that the current neutron model for ports doesn't really allow that
easily.  Couple that with the change of name from Logical_Port to
Logical_Switch_Port, and I'm left wondering if we aren't better off
with the following "weak" links instead:
-the Port_Chain includes the logical switch as an external_id
-each Port_Pair_Group includes the Port_Chain as an external_id
-each Port_Pair includes the PPG as an external_id
-each Logical_Switch_Port includes the PP as an external_id

I *think* that *might* allow me (in the future) to attach a port chain
to a logical router by setting the logical router as an external_id and
using Logical_Router_Ports to make up the PPs...

JED> If there are "port-chain" tables for switches and routers I think I agree. 
Not sure how this is impacted by the type of VNF (see the last email to Juno). 
I struggle a bit with imagining the flows.

2. I still don't see what Logical_Flow_Classifier is buying me that
ACL doesn't - I can codify all of the classifiers given in the match
criteria of an ACL entry and codify the first PPG of the SFC as
the action of the ACL entry...

JED> Flow classifiers do map to an ACL entry - just need additional metadata, 
I.e. Action of the ACL and wether the rules should be uni or bi-directional. 
Though that information could be in the port-chain.

Ryan
__
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][os-vif] Expanding vif capability for wiring trunk ports

2016-06-15 Thread Carl Baldwin

I know I've been pretty quiet since I started this thread.  Y'all have
been doing so well, I've just been reading the thread every day and
enjoying it.  I thought I'd top post here to kind of summarize.

I see wisdom in the strategy suggested by Sean Mooney to make a very
minimal change to os-vif to merely create a bridge if it doesn't exist
already and otherwise plug as normal.  I agree that this is the
strategy that we should take and I think there is a lot of support for
it in this thread.  I'm assuming at this point that this is the way
we're going to move forward unless we hear something soon.

There were a few side conversations about deprecating veth, linux
bridge topics, and possibly something else.  I think those are their
own topics and we don't necessarily need to wrap anything up on those
at the moment.

Thank you for all of your thoughts.

Carl

__
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] NUMA, huge pages, and scheduling


On 6/15/2016 3:10 PM, Paul Michali wrote:

Is the plan to back port that change to Mitaka?

Thanks,

PCM


On Wed, Jun 15, 2016 at 1:31 PM Matt Riedemann
> wrote:

On 6/14/2016 3:09 PM, Jay Pipes wrote:
>
> Yes. Code merged recently from Sahid does this:
>
> https://review.openstack.org/#/c/277422/
>
> Best,
> -jay
>

That was actually reverted out of mitaka:

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

The feature change that got into newton was this:

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

Which was busted, and required:

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

Well, required as long as you want your compute service to start. :)

And no, we aren't backporting these, especially to liberty which is
security / critical fix mode only now.

--

Thanks,

Matt Riedemann


__
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



No, it's really a feature.

--

Thanks,

Matt Riedemann


__
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][os-vif] Expanding vif capability for wiring trunk ports

2016-06-15 Thread Kevin Benton

>I wouldn't say linux bridges are totally outside of its domain because it
relies on them for security groups.

It relies on a side effect of their existence - iptables rules being
applied to the veth interface. It does nothing to the actual linux bridge
itself. If there was a way to plug a veth directly between the VM and OVS
and have iptables be applied, there would be *no* code changes on the OVS
agent because it doesn't do anything with the bridge.

>then use the equivalent of "ovs-vsctl iface-to-br " to get the
name of the bridge.

So then we have to have logic to guess which bridges connected by patch
ports 'belong' to trunk ports because we weren't explicit anywhere.

On Wed, Jun 15, 2016 at 11:01 AM, Peters, Rawlin 
wrote:

> On Tuesday, June 14, 2016 6:27 PM, Kevin Benton (ke...@benton.pub) wrote:
> > >which generates an arbitrary name
> >
> > I'm not a fan of this approach because it requires coordinated
> assumptions.
> > With the OVS hybrid plug strategy we have to make guesses on the agent
> side
> > about the presence of bridges with specific names that we never
> explicitly
> > requested and that we were never explicitly told about. So we end up
> with code
> > like [1] that is looking for a particular end of a veth pair it just
> hopes is
> > there so the rules have an effect.
>
> I don't think this should be viewed as a downside of Strategy 1 because, at
> least when we use patch port pairs, we can easily get the peer name from
> the
> port on br-int, then use the equivalent of "ovs-vsctl iface-to-br  name>"
> to get the name of the bridge. If we allow supporting veth pairs to
> implement
> the subports, then getting the arbitrary trunk bridge/veth names isn't as
> trivial.
>
> This also brings up the question: do we even need to support veth pairs
> over
> patch port pairs anymore? Are there any distros out there that support
> openstack but not OVS patch ports?
>
> >
> > >it seems that the LinuxBridge implementation can simply use an L2 agent
> > >extension for creating the vlan interfaces for the subports
> >
> > LinuxBridge implementation is the same regardless of the strategy for
> OVS. The
> > whole reason we have to come up with these alternative approaches for
> OVS is
> > because we can't use the obvious architecture of letting it plug into the
> > integration bridge due to VLANs already being used for network
> isolation. I'm
> > not sure pushing complexity out to os-vif to deal with this is a great
> > long-term strategy.
>
> The complexity we'd be pushing out to os-vif is not much worse than the
> current
> complexity of the hybrid_ovs strategy already in place today.
>
> >
> > >Also, we didn’t make the OVS agent monitor for new linux bridges in the
> > >hybrid_ovs strategy so that Neutron could be responsible for creating
> the veth
> > >pair.
> >
> > Linux Bridges are outside of the domain of OVS and even its agent. The
> L2 agent
> > doesn't actually do anything with the bridge itself, it just needs a veth
> > device it can put iptables rules on. That's in contrast to these new OVS
> > bridges that we will be managing rules for, creating additional patch
> ports,
> > etc.
>
> I wouldn't say linux bridges are totally outside of its domain because it
> relies
> on them for security groups. Rather than relying on an arbitrary naming
> convention between Neutron and Nova, we could've implemented monitoring
> for new
> linux bridges to create veth pairs and firewall rules on. I'm glad we
> didn't,
> because that logic is specific to that particular firewall driver, similar
> to
> how this trunk bridge monitoring would be specific to only vlan-aware-vms.
> I
> think the logic lives best within an L2 agent extension, outside of the
> core
> of the OVS agent.
>
> >
> > >Why shouldn't we use the tools that are already available to us?
> >
> > Because we're trying to build a house and all we have are paint brushes.
> :)
>
> To me it seems like we already have a house that just needs a little paint
> :)
>
> >
> >
> > 1.
> >
> https://github.com/openstack/neutron/blob/f78e5b4ec812cfcf5ab8b50fca62d1ae0dd7741d/neutron/agent/linux/iptables_firewall.py#L919-L923
>
__
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][cinder] Integration testing for Nova API os-assisted-volume-snapshots

2016-06-15 Thread Sean McGinnis

On Wed, Jun 15, 2016 at 07:01:17PM +0200, Jordan Pittier wrote:
> On Wed, Jun 15, 2016 at 6:21 PM, Matt Riedemann 
> wrote:
> 
...
> > Does someone have a link to a successful job run for one of those drivers?
> > I'd like to see if they are testing volume snapshot and that it's properly
> > calling the nova API and everything is working. Because this is also
> > something that Nova could totally unknowingly break to that flow since we
> > have no CI coverage for it (we don't have those cinder 3rd party CI jobs
> > running against nova changes).
> >
> > --
> >
> 
> Hi Matt,
> I am in charge of the Scality CI. It used to report to changes in Cinder. A
> change in devstack broke us a couple of months ago, so I had to turn off my
> CI (because it was reporting false negative) while developing a patch. The
> patch took a long time to develop and merge but was merged finally:
> https://review.openstack.org/#/c/310204/
> 
> But in the mean time, something else crept in, hidden by the first failure.
> So the Scality CI is still broken, but it is my intention to find the
> commit that broke it and come up with a patch.
> 
Jordan, please ping me when you have a patch for that and I will try to
make it a priority.

Thanks,
Sean

__
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] [ironic] June 20 meeting cancelled

2016-06-15 Thread Jim Rollenhagen

Hey all,

The weekly ironic meeting for June 20 will be cancelled because it
overlaps with our midcycle. Join the midcycle instead. :)

We'll resume our normal schedule on June 27.

// jim

__
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] [ironic] Midcycle reminder

2016-06-15 Thread Jim Rollenhagen

Hi all,

Just a reminder that our midcycle is next week!

Details are here:

https://wiki.openstack.org/wiki/VirtualSprints#Ironic_Virtual_Newton_Midcycle
https://wiki.openstack.org/wiki/Sprints#Future_sprints_for_Newton

Etherpad: https://etherpad.openstack.org/p/ironic-newton-midcycle

Please add your name to the etherpad if you'll be joining.

If you have a topic you'd like to discuss, also add it to the etherpad.

See y'all there!

// jim

__
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][os-vif] Expanding vif capability for wiring trunk ports

2016-06-15 Thread Peters, Rawlin

On Wednesday, June 15, 2016 12:45 PM, Mooney, Sean K [sean.k.moo...@intel.com] 
wrote:
> > On Tuesday, June 14, 2016 6:27 PM, Kevin Benton (ke...@benton.pub)
> > wrote:
> > > >which generates an arbitrary name
> > >
> > > I'm not a fan of this approach because it requires coordinated
> > assumptions.
> > > With the OVS hybrid plug strategy we have to make guesses on the
> > > agent side about the presence of bridges with specific names that we
> > > never explicitly requested and that we were never explicitly told
> > > about. So we end up with code like [1] that is looking for a
> > > particular end of a veth pair it just hopes is there so the rules have an
> effect.
> [Mooney, Sean K] I really would like to avoid encoding knowledge to
> Generate the names the same way in both neutron and os-vf/nova or having
> any Other special casing to figure out the bridge or interface names.
> 
> >
> > I don't think this should be viewed as a downside of Strategy 1
> > because, at least when we use patch port pairs, we can easily get the
> > peer name from the port on br-int, then use the equivalent of
> > "ovs-vsctl iface-to- br "
> > to get the name of the bridge. If we allow supporting veth pairs to
> > implement the subports, then getting the arbitrary trunk bridge/veth
> > names isn't as trivial.
> >
> > This also brings up the question: do we even need to support veth
> > pairs over patch port pairs anymore? Are there any distros out there
> > that support openstack but not OVS patch ports?
> [Mooney, Sean K] that is a separate discussions In general im in favor of
> deprecating support for veth interconnect with ovs And removing it in ocata.
> I belive I was originally added in juno for centos and suse as then did not
> Support ovs 2.0 or there kernel ovs module did not support patchports.
> As far as I aware  there is no major linux os version that does not have patch
> Support in ovs and also meets the minimum python version of 2.7 required
> by OpenStack So this functionality could safely be removed.
> 

Ok, we should follow up on this to have it deprecated for removal in Ocata.

> >
> > >
> > > >it seems that the LinuxBridge implementation can simply use an L2
> > > >agent extension for creating the vlan interfaces for the subports
> > >
> > > LinuxBridge implementation is the same regardless of the strategy
> > > for OVS. The whole reason we have to come up with these alternative
> > > approaches for OVS is because we can't use the obvious architecture
> > > of letting it plug into the integration bridge due to VLANs already
> > > being used for network isolation. I'm not sure pushing complexity
> > > out to os-vif to deal with this is a great long-term strategy.
> >
> > The complexity we'd be pushing out to os-vif is not much worse than
> > the current complexity of the hybrid_ovs strategy already in place today.
> [Mooney, Sean K] I don’t think strategy 1 is the correct course Of action 
> long-
> term with the trunk bridge approch. I honestly think that The patch port
> creation should be the responsibility of the ovs agent alone.
> 
> I think the DRY principle applies in this respect also. The ovs agent will Be
> required to add or remove patch ports after the vm is booted if subports Are
> added/removed from the truck port. I don’t think it make sense to Write the
> code to do that both in the ovs agent and separately in os-vif.
> 
> Having os-vif simply create the bridge if it does not exist and Add the port 
> to
> it is a much simpler solution in that respect as you can reuse The patch port
> code that is already in neutron and not duplicate it in os-vif.
> https://github.com/openstack/neutron/blob/master/neutron/agent/comm
> on/ovs_lib.py#L368-L371

I don't think we'd be in too much danger in terms of DRY for creating a patch 
port pair in os-vif, because it already has [1] from Nova which is just some 
basic wrapping around a shell command. [1] could be extended to allow creating 
an OVS patch port rather than just a regular port, and I think we can rely on 
the shell command to not produce any bugs that would need fixed in both places.

[1] 
https://github.com/openstack/os-vif/blob/master/vif_plug_ovs/linux_net.py#L49-L60

> 
> 
> >
> > >
> > > >Also, we didn’t make the OVS agent monitor for new linux bridges in
> > > >the hybrid_ovs strategy so that Neutron could be responsible for
> > > >creating the veth pair.
> > >
> > > Linux Bridges are outside of the domain of OVS and even its agent. The
> > > L2 agent doesn't actually do anything with the bridge itself, it just
> > > needs a veth device it can put iptables rules on. That's in contrast
> > > to these new OVS bridges that we will be managing rules for, creating
> > > additional patch ports, etc.
> >
> > I wouldn't say linux bridges are totally outside of its domain because
> > it relies on them for security groups. Rather than relying on an
> > arbitrary naming convention between Neutron and Nova, we could've
> > implemented monitoring

Re: [openstack-dev] [nova] NUMA, huge pages, and scheduling

2016-06-15 Thread Paul Michali

Is the plan to back port that change to Mitaka?

Thanks,

PCM


On Wed, Jun 15, 2016 at 1:31 PM Matt Riedemann 
wrote:

> On 6/14/2016 3:09 PM, Jay Pipes wrote:
> >
> > Yes. Code merged recently from Sahid does this:
> >
> > https://review.openstack.org/#/c/277422/
> >
> > Best,
> > -jay
> >
>
> That was actually reverted out of mitaka:
>
> https://review.openstack.org/#/c/292290/
>
> The feature change that got into newton was this:
>
> https://review.openstack.org/#/c/292499/
>
> Which was busted, and required:
>
> https://review.openstack.org/#/c/324379/
>
> Well, required as long as you want your compute service to start. :)
>
> And no, we aren't backporting these, especially to liberty which is
> security / critical fix mode only now.
>
> --
>
> Thanks,
>
> Matt Riedemann
>
>
> __
> 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] Stable/liberty breakage

> On 15 Jun 2016, at 22:06, Ihar Hrachyshka  wrote:
> 
> 
>> On 15 Jun 2016, at 21:19, Aaron Rosen  wrote:
>> 
>> Sorry I think I gave Gary some bad information here. 
>> 
>> After digging into this more, the actually underlying issue that we hit is 
>> that the packaged 'distro' version of stable/liberty that was running with 
>> the vmware-nsx repo included this patch set which is not in upstream 
>> stable/liberty 
>> 
>> https://github.com/openstack/neutron/commit/7267d75fdd3f90af759d71e9490cd41d41ba6d98
>> 
>> That's what was causing the issue on our end.  All should be okay upstream. 
>> Sorry about the confusion. 
>> 
> 
> Great. Thanks for the update, I can now sleep a tad better this night. :) I 
> guess you want to bring this topic up to your distribution folks for them to 
> be aware they are breaking plugins.
> 
> Ihar

btw ironically, the patch in question was proposed for stable/liberty and 
stable/kilo in upstream but was stopped by stable maintainers for several 
reasons: 1. it indeed breaks 3party plugins, and we knew about that; 2. it 
requires controller upgrade before upgrading computes, which is not a 
requirement for minor (stable) updates (in contrast to major upgrades, like 
L-to-M).

Discussion at: https://review.openstack.org/#/c/240167/

So kudos to upstream stable process for keeping those breaking changes far from 
stable branches!

Ihar
__
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] Stable/liberty breakage


> On 15 Jun 2016, at 21:19, Aaron Rosen  wrote:
> 
> Sorry I think I gave Gary some bad information here. 
> 
> After digging into this more, the actually underlying issue that we hit is 
> that the packaged 'distro' version of stable/liberty that was running with 
> the vmware-nsx repo included this patch set which is not in upstream 
> stable/liberty 
> 
> https://github.com/openstack/neutron/commit/7267d75fdd3f90af759d71e9490cd41d41ba6d98
> 
> That's what was causing the issue on our end.  All should be okay upstream. 
> Sorry about the confusion. 
> 

Great. Thanks for the update, I can now sleep a tad better this night. :) I 
guess you want to bring this topic up to your distribution folks for them to be 
aware they are breaking plugins.

Ihar
__
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] [tacker] Cancelling weekly meeting next week (Jun 21, 2016)

2016-06-15 Thread Sridhar Ramaswamy

I'll be away next week attending OPNFV Summit. Hence cancelling Tacker irc
meeting on Jun 21st. We will resume the week after - on Tuesday Jun 28th,

https://wiki.openstack.org/wiki/Meetings/Tacker

- Sridhar
__
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] [tempest] the project specific config option not generated together with tempest.conf.sample

2016-06-15 Thread Matthew Treinish

Just a note, please don't start a new thread as a reply to an existing thread.
(well unless you remove the In-Reply-To header from the message) There is more
details on this here:

https://wiki.openstack.org/wiki/MailingListEtiquette#Threading

I almost missed this because it was part of a different thread.

On Wed, Jun 15, 2016 at 05:14:26AM +, joehuang wrote:
> Hello, 
> 
> A tempest plugin was written for the Kingbird 
> https://review.openstack.org/#/c/328683/, the plugin and test cases could be 
> discovered by tempest, and the configuration is working if we add the 
> configuration items into the tempest.conf manfully, but if we run tox 
> -egenconfig in the tempest folder, these configuration items not generated in 
> the tempest.conf.sample.
> 
> How to make the plugin customized configuration items also being generated in 
> the tempest.conf.sample ? 

This is a documented part of the tempest plugin interface:

http://docs.openstack.org/developer/tempest/plugin.html#tempest.test_discover.plugins.TempestPlugin.get_opt_lists

> 
> And for service_available group, it should be already there in the config, 
> isn't it?

Yes, but it depends on your plugin to pass the extra config options properly on
sample config generation. If you look at your tempest plugin:

http://git.openstack.org/cgit/openstack/kingbird/tree/kingbird/tests/tempest/scenario/plugin.py#n38

You're not returning the service_available option to tempest, just the KBGroup
options. You need to add a tuple with the service_available option and group
name to the output list there for it to show up in the output sample config
file.

That being said I don't actually see the service_available kingbird option being
defined anywhere in the plugin. For example see:

http://git.openstack.org/cgit/openstack/zaqar/tree/zaqar/tests/tempest_plugin/config.py#n18

and

http://git.openstack.org/cgit/openstack/zaqar/tree/zaqar/tests/tempest_plugin/plugin.py#n38

-Matt Treinish

signature.asc
Description: PGP signature
__
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] Stable/liberty breakage

2016-06-15 Thread Aaron Rosen

Sorry I think I gave Gary some bad information here.

After digging into this more, the actually underlying issue that we hit is
that the packaged 'distro' version of stable/liberty that was running with
the vmware-nsx repo included this patch set which is not in upstream
stable/liberty

https://github.com/openstack/neutron/commit/7267d75fdd3f90af759d71e9490cd41d41ba6d98

That's what was causing the issue on our end.  All should be okay upstream.
Sorry about the confusion.

Aaron



On Wed, Jun 15, 2016 at 11:59 AM, Ihar Hrachyshka 
wrote:

>
> > On 15 Jun 2016, at 20:18, Gary Kotton  wrote:
> >
> > Hi,
> > The following patch breaks stable liberty drivers -
> https://review.openstack.org/#/c/238745/
> > This means that plugins will need to be updated to support this.
>
> Would you mind sharing details about the breakage? It was assumed that the
> patch backported includes the relevant compatibility bits to avoid any
> breakage. If that’s not the case, we should definitely come up with a way
> to get existing drivers unbroken again.
>
> > What do we do:
> >   • Revert – which could break people using latest stable/liberty
> >   • Have a requirement that Neutron plugins be updated when they use
> stable/liberty
>
> It may be either revert, or a new patch that would accommodate for your
> broken driver. It depends on breakage details. So please share those.
>
> > This is really bad.
>
> Absolutely. The change was not expected to require any changes for 3party
> drivers. If it happened, that’s our fault, and maybe we should land
> something, or revert. We should not leave it broken for 3party drivers.
>
> > Any suggestions.
> > Thanks
> > Gary
> >
> __
> > 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] Stable/liberty breakage

2016-06-15 Thread Assaf Muller

On Wed, Jun 15, 2016 at 2:59 PM, Ihar Hrachyshka  wrote:
>
>> On 15 Jun 2016, at 20:18, Gary Kotton  wrote:
>>
>> Hi,
>> The following patch breaks stable liberty drivers - 
>> https://review.openstack.org/#/c/238745/
>> This means that plugins will need to be updated to support this.
>
> Would you mind sharing details about the breakage? It was assumed that the 
> patch backported includes the relevant compatibility bits to avoid any 
> breakage. If that’s not the case, we should definitely come up with a way to 
> get existing drivers unbroken again.
>
>> What do we do:
>>   • Revert – which could break people using latest stable/liberty
>>   • Have a requirement that Neutron plugins be updated when they use 
>> stable/liberty
>
> It may be either revert, or a new patch that would accommodate for your 
> broken driver. It depends on breakage details. So please share those.
>
>> This is really bad.
>
> Absolutely. The change was not expected to require any changes for 3party 
> drivers. If it happened, that’s our fault, and maybe we should land 
> something, or revert. We should not leave it broken for 3party drivers.

Check out an IRC conversation from earlier today:
http://eavesdrop.openstack.org/irclogs/%23openstack-neutron/%23openstack-neutron.2016-06-15.log.html#t2016-06-15T18:23:42

Specifically this is the patch to fix VMware drivers:
https://review.openstack.org/#/c/231217/

The question is can we send a patch to stable/liberty to ensure
compatibility for non-ML2 plugins. Failing that we'll need to revert.

>
>> Any suggestions.
>> Thanks
>> Gary
>> __
>> 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] Stable/liberty breakage

> On 15 Jun 2016, at 20:18, Gary Kotton  wrote:
> 
> Hi,
> The following patch breaks stable liberty drivers - 
> https://review.openstack.org/#/c/238745/
> This means that plugins will need to be updated to support this.

Would you mind sharing details about the breakage? It was assumed that the 
patch backported includes the relevant compatibility bits to avoid any 
breakage. If that’s not the case, we should definitely come up with a way to 
get existing drivers unbroken again.

> What do we do:
>   • Revert – which could break people using latest stable/liberty
>   • Have a requirement that Neutron plugins be updated when they use 
> stable/liberty

It may be either revert, or a new patch that would accommodate for your broken 
driver. It depends on breakage details. So please share those.

> This is really bad.

Absolutely. The change was not expected to require any changes for 3party 
drivers. If it happened, that’s our fault, and maybe we should land something, 
or revert. We should not leave it broken for 3party drivers.

> Any suggestions.
> Thanks
> Gary
> __
> 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][os-vif] Expanding vif capability for wiring trunk ports

2016-06-15 Thread Mooney, Sean K



> -Original Message-
> From: Peters, Rawlin [mailto:rawlin.pet...@hpe.com]
> Sent: Wednesday, June 15, 2016 7:02 PM
> To: Kevin Benton 
> Cc: OpenStack Development Mailing List (not for usage questions)
> 
> Subject: Re: [openstack-dev] [Neutron][os-vif] Expanding vif capability
> for wiring trunk ports
> 
> On Tuesday, June 14, 2016 6:27 PM, Kevin Benton (ke...@benton.pub)
> wrote:
> > >which generates an arbitrary name
> >
> > I'm not a fan of this approach because it requires coordinated
> assumptions.
> > With the OVS hybrid plug strategy we have to make guesses on the agent
> > side about the presence of bridges with specific names that we never
> > explicitly requested and that we were never explicitly told about. So
> > we end up with code like [1] that is looking for a particular end of a
> > veth pair it just hopes is there so the rules have an effect.
[Mooney, Sean K] I really would like to avoid encoding knowledge to 
Generate the names the same way in both neutron and os-vf/nova or having any
Other special casing to figure out the bridge or interface names.

> 
> I don't think this should be viewed as a downside of Strategy 1 because,
> at least when we use patch port pairs, we can easily get the peer name
> from the port on br-int, then use the equivalent of "ovs-vsctl iface-to-
> br "
> to get the name of the bridge. If we allow supporting veth pairs to
> implement the subports, then getting the arbitrary trunk bridge/veth
> names isn't as trivial.
> 
> This also brings up the question: do we even need to support veth pairs
> over patch port pairs anymore? Are there any distros out there that
> support openstack but not OVS patch ports?
[Mooney, Sean K] that is a separate discussions
In general im in favor of deprecating support for veth interconnect with ovs
And removing it in ocata.
I belive I was originally added in juno for centos and suse as then did not
Support ovs 2.0 or there kernel ovs module did not support patchports.
As far as I aware  there is no major linux os version that does not have patch 
Support in ovs and also meets the minimum python version of 2.7 required by 
OpenStack
So this functionality could safely be removed.

> 
> >
> > >it seems that the LinuxBridge implementation can simply use an L2
> > >agent extension for creating the vlan interfaces for the subports
> >
> > LinuxBridge implementation is the same regardless of the strategy for
> > OVS. The whole reason we have to come up with these alternative
> > approaches for OVS is because we can't use the obvious architecture of
> > letting it plug into the integration bridge due to VLANs already being
> > used for network isolation. I'm not sure pushing complexity out to
> > os-vif to deal with this is a great long-term strategy.
> 
> The complexity we'd be pushing out to os-vif is not much worse than the
> current complexity of the hybrid_ovs strategy already in place today.
[Mooney, Sean K] I don’t think strategy 1 is the correct course
Of action long-term with the trunk bridge approch. I honestly think that
The patch port creation should be the responsibility of the ovs agent alone.

I think the DRY principle applies in this respect also. The ovs agent will
Be required to add or remove patch ports after the vm is booted if subports
Are added/removed from the truck port. I don’t think it make sense to
Write the code to do that both in the ovs agent and separately in os-vif.

Having os-vif simply create the bridge if it does not exist and 
Add the port to it is a much simpler solution in that respect as you can reuse
The patch port code that is already in neutron and not duplicate it in os-vif.
https://github.com/openstack/neutron/blob/master/neutron/agent/common/ovs_lib.py#L368-L371


> 
> >
> > >Also, we didn’t make the OVS agent monitor for new linux bridges in
> > >the hybrid_ovs strategy so that Neutron could be responsible for
> > >creating the veth pair.
> >
> > Linux Bridges are outside of the domain of OVS and even its agent. The
> > L2 agent doesn't actually do anything with the bridge itself, it just
> > needs a veth device it can put iptables rules on. That's in contrast
> > to these new OVS bridges that we will be managing rules for, creating
> > additional patch ports, etc.
> 
> I wouldn't say linux bridges are totally outside of its domain because
> it relies on them for security groups. Rather than relying on an
> arbitrary naming convention between Neutron and Nova, we could've
> implemented monitoring for new linux bridges to create veth pairs and
> firewall rules on. I'm glad we didn't, because that logic is specific to
> that particular firewall driver, similar to how this trunk bridge
> monitoring would be specific to only vlan-aware-vms. I think the logic
> lives best within an L2 agent extension, outside of the core of the OVS
> agent.
[Mooney, Sean K] 
is this assuming option A form https://review.openstack.org/#/c/318317/ i.e the

Re: [openstack-dev] [Neutron][os-vif] Expanding vif capability for wiring trunk ports

2016-06-15 Thread Assaf Muller

On Wed, Jun 15, 2016 at 2:01 PM, Peters, Rawlin  wrote:
> On Tuesday, June 14, 2016 6:27 PM, Kevin Benton (ke...@benton.pub) wrote:
>> >which generates an arbitrary name
>>
>> I'm not a fan of this approach because it requires coordinated assumptions.
>> With the OVS hybrid plug strategy we have to make guesses on the agent side
>> about the presence of bridges with specific names that we never explicitly
>> requested and that we were never explicitly told about. So we end up with 
>> code
>> like [1] that is looking for a particular end of a veth pair it just hopes is
>> there so the rules have an effect.
>
> I don't think this should be viewed as a downside of Strategy 1 because, at
> least when we use patch port pairs, we can easily get the peer name from the
> port on br-int, then use the equivalent of "ovs-vsctl iface-to-br "
> to get the name of the bridge. If we allow supporting veth pairs to implement
> the subports, then getting the arbitrary trunk bridge/veth names isn't as
> trivial.
>
> This also brings up the question: do we even need to support veth pairs over
> patch port pairs anymore? Are there any distros out there that support
> openstack but not OVS patch ports?

I really doubt it. This stopped being an issue in Fedora/CentOS/RHEL
like 18~ months ago.

>
>>
>> >it seems that the LinuxBridge implementation can simply use an L2 agent
>> >extension for creating the vlan interfaces for the subports
>>
>> LinuxBridge implementation is the same regardless of the strategy for OVS. 
>> The
>> whole reason we have to come up with these alternative approaches for OVS is
>> because we can't use the obvious architecture of letting it plug into the
>> integration bridge due to VLANs already being used for network isolation. I'm
>> not sure pushing complexity out to os-vif to deal with this is a great
>> long-term strategy.
>
> The complexity we'd be pushing out to os-vif is not much worse than the 
> current
> complexity of the hybrid_ovs strategy already in place today.
>
>>
>> >Also, we didn’t make the OVS agent monitor for new linux bridges in the
>> >hybrid_ovs strategy so that Neutron could be responsible for creating the 
>> >veth
>> >pair.
>>
>> Linux Bridges are outside of the domain of OVS and even its agent. The L2 
>> agent
>> doesn't actually do anything with the bridge itself, it just needs a veth
>> device it can put iptables rules on. That's in contrast to these new OVS
>> bridges that we will be managing rules for, creating additional patch ports,
>> etc.
>
> I wouldn't say linux bridges are totally outside of its domain because it 
> relies
> on them for security groups. Rather than relying on an arbitrary naming
> convention between Neutron and Nova, we could've implemented monitoring for 
> new
> linux bridges to create veth pairs and firewall rules on. I'm glad we didn't,
> because that logic is specific to that particular firewall driver, similar to
> how this trunk bridge monitoring would be specific to only vlan-aware-vms. I
> think the logic lives best within an L2 agent extension, outside of the core
> of the OVS agent.
>
>>
>> >Why shouldn't we use the tools that are already available to us?
>>
>> Because we're trying to build a house and all we have are paint brushes. :)
>
> To me it seems like we already have a house that just needs a little paint :)
>
>>
>>
>> 1.
>> https://github.com/openstack/neutron/blob/f78e5b4ec812cfcf5ab8b50fca62d1ae0dd7741d/neutron/agent/linux/iptables_firewall.py#L919-L923
> __
> 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-dev] [Neutron] Stable/liberty breakage

2016-06-15 Thread Gary Kotton

Hi,
The following patch breaks stable liberty drivers - 
https://review.openstack.org/#/c/238745/
This means that plugins will need to be updated to support this.
What do we do:

  1.  Revert – which could break people using latest stable/liberty
  2.  Have a requirement that Neutron plugins be updated when they use 
stable/liberty

This is really bad.
Any suggestions.
Thanks
Gary
__
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][os-vif] Expanding vif capability for wiring trunk ports

2016-06-15 Thread Peters, Rawlin

On Tuesday, June 14, 2016 6:27 PM, Kevin Benton (ke...@benton.pub) wrote:
> >which generates an arbitrary name
>
> I'm not a fan of this approach because it requires coordinated assumptions.
> With the OVS hybrid plug strategy we have to make guesses on the agent side
> about the presence of bridges with specific names that we never explicitly
> requested and that we were never explicitly told about. So we end up with code
> like [1] that is looking for a particular end of a veth pair it just hopes is
> there so the rules have an effect.

I don't think this should be viewed as a downside of Strategy 1 because, at
least when we use patch port pairs, we can easily get the peer name from the
port on br-int, then use the equivalent of "ovs-vsctl iface-to-br "
to get the name of the bridge. If we allow supporting veth pairs to implement
the subports, then getting the arbitrary trunk bridge/veth names isn't as
trivial.

This also brings up the question: do we even need to support veth pairs over
patch port pairs anymore? Are there any distros out there that support
openstack but not OVS patch ports?

>
> >it seems that the LinuxBridge implementation can simply use an L2 agent
> >extension for creating the vlan interfaces for the subports
>
> LinuxBridge implementation is the same regardless of the strategy for OVS. The
> whole reason we have to come up with these alternative approaches for OVS is
> because we can't use the obvious architecture of letting it plug into the
> integration bridge due to VLANs already being used for network isolation. I'm
> not sure pushing complexity out to os-vif to deal with this is a great
> long-term strategy.

The complexity we'd be pushing out to os-vif is not much worse than the current
complexity of the hybrid_ovs strategy already in place today.

>
> >Also, we didn’t make the OVS agent monitor for new linux bridges in the
> >hybrid_ovs strategy so that Neutron could be responsible for creating the 
> >veth
> >pair.
>
> Linux Bridges are outside of the domain of OVS and even its agent. The L2 
> agent
> doesn't actually do anything with the bridge itself, it just needs a veth
> device it can put iptables rules on. That's in contrast to these new OVS
> bridges that we will be managing rules for, creating additional patch ports,
> etc.

I wouldn't say linux bridges are totally outside of its domain because it relies
on them for security groups. Rather than relying on an arbitrary naming
convention between Neutron and Nova, we could've implemented monitoring for new
linux bridges to create veth pairs and firewall rules on. I'm glad we didn't,
because that logic is specific to that particular firewall driver, similar to
how this trunk bridge monitoring would be specific to only vlan-aware-vms. I
think the logic lives best within an L2 agent extension, outside of the core
of the OVS agent.

>
> >Why shouldn't we use the tools that are already available to us?
>
> Because we're trying to build a house and all we have are paint brushes. :)

To me it seems like we already have a house that just needs a little paint :)

>
>
> 1.
> https://github.com/openstack/neutron/blob/f78e5b4ec812cfcf5ab8b50fca62d1ae0dd7741d/neutron/agent/linux/iptables_firewall.py#L919-L923
__
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] Virtuozzo (Compute) CI is incorrectly patching for resize support


On 6/15/2016 5:17 AM, Evgeny Antyshev wrote:

Hello, Matt!

First of all, I want to apologize for the inconvenience.
This all started yesterday when I updated Virtuozzo CI using latest
puppets, Zuul, Jenkins and other stuff.
The update somehow led to Zuul not passing environment variables like
ZUUL_CHANGE, LOG_PATH to Jenkins job.
Therefore, devstack-gate didn't apply the change 282580 which triggered
the test (usually it does).

I'm still investigating this issue with Zuul-Jenkins interaction.

Please, also see inline comments:

On 06/15/2016 12:51 AM, Matt Riedemann wrote:

It was pointed out today in IRC that the Virtuozzo CI has been failing
on this change for the libvirt imagebackend refactor:

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

Diana was having a hard time sorting out the line numbers in the stack
trace though from the logs, because they didn't exist in her series.

Long story short, that's because the job checks to see if the change
is the change that adds resize support for virtuozzo:

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

And if not, it fetches that change:

23:48:46 2016-06-10 23:48:58.863 | + cd /opt/stack/new/nova
23:48:46 2016-06-10 23:48:58.872 | + [[ 282580 -ne 182257 ]]
23:48:46 2016-06-10 23:48:58.875 | + git fetch
https://review.openstack.org/p/openstack/nova refs/changes/57/182257/37
23:48:59 2016-06-10 23:49:11.357 | From
https://review.openstack.org/p/openstack/nova
23:48:59 2016-06-10 23:49:11.359 |  * branch refs/changes/57/182257/37
-> FETCH_HEAD
23:48:59 2016-06-10 23:49:11.366 | + git cherry-pick FETCH_HEAD
23:48:59 2016-06-10 23:49:11.689 | [detached HEAD 44b6772] libvirt:
virtuozzo instance resize support

It's not valid to patch Nova for your CI when testing other changes,
it breaks the whole point of CI testing if you have to patch things in
it that aren't in the actual dependency change or repo - because when
it fails, like in this case, one doesn't know if it's their actual
change that's broken or the patch in the CI job.

Well, this methodology is explained in
https://wiki.openstack.org/wiki/Cinder/tested-3rdParty-drivers
("How do I run my CI to test all cinder patches with my driver not yet
merged?")
I hoped the same approach is valid for Nova.

The change 182257 is critical for our functionality, but is not merged yet.
Should we test other patches assuming our change got merged, or not is a
policy question,
and it is obvious that in Cinder this is regarded as normal.


It's different when you're adding a new driver that's not yet in tree. 
The virtuozzo support is already in the libvirt driver. The team is 
working on feature parity, which is good, but you should be able to run 
other basic server tests (create/delete/start/stop/etc) on all nova 
changes. The resize tests should only run on the patch that adds the 
resize support.






I'm assuming this was done because I asked for the Virtuozzo CI to run
the resize tests in tempest against
https://review.openstack.org/#/c/182257/ - which it is, but that
didn't mean also do it for all other changes in Nova. The CI job
should conditionally enable those tests when testing change 182257 but
not anything else until that's merged.

If you confirm this, I'll do as you explained above.


Correct, you should only test resize against the patch that adds the 
resize support and nothing else until that change is merged. This should 
be somewhat trivial by setting the CONF.compute_feature_enabled.resize 
flag in tempest.conf.




As a side note, the job isn't fetching the latest patch set of the
resize change anyway, at least not as of last week, it's fetching
patch set 37 but 39 is the latest.

Well, fixing this was a part of an update procedure which led to such
dramatic consequences.


Anyway, this isn't meant to shame, but to inform and correct. No one
from the Virtuozzo team was in the nova IRC channel when we discovered
this, so I needed to get it into the dev list.

But please get this fixed ASAP since it's invalidating the Virtuozzo
CI results.




__
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




--

Thanks,

Matt Riedemann


__
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] Virtuozzo (Compute) CI is incorrectly patching for resize support

2016-06-15 Thread Jeremy Stanley

On 2016-06-15 13:17:54 +0300 (+0300), Evgeny Antyshev wrote:
[...]
> This all started yesterday when I updated Virtuozzo CI using latest puppets,
> Zuul, Jenkins and other stuff.
> The update somehow led to Zuul not passing environment variables like
> ZUUL_CHANGE, LOG_PATH to Jenkins job.
[...]

Very recent Jenkins releases began preventing injected parameters
from making it into worker environments.

http://lists.openstack.org/pipermail/openstack-infra/2016-May/004284.html

-- 
Jeremy Stanley

__
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] NUMA, huge pages, and scheduling


On 6/14/2016 3:09 PM, Jay Pipes wrote:


Yes. Code merged recently from Sahid does this:

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

Best,
-jay



That was actually reverted out of mitaka:

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

The feature change that got into newton was this:

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

Which was busted, and required:

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

Well, required as long as you want your compute service to start. :)

And no, we aren't backporting these, especially to liberty which is 
security / critical fix mode only now.


--

Thanks,

Matt Riedemann


__
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] Require a level playing field for OpenStack projects

2016-06-15 Thread Doug Hellmann

Excerpts from Kyle Mestery's message of 2016-06-15 09:05:59 -0500:
> On Tue, Jun 14, 2016 at 9:15 AM, Doug Hellmann  wrote:
> > Excerpts from Thierry Carrez's message of 2016-06-14 15:57:10 +0200:
> >> Hi everyone,
> >>
> >> I just proposed a new requirement for OpenStack "official" projects,
> >> which I think is worth discussing beyond the governance review:
> >>
> >> https://review.openstack.org/#/c/329448/
> >>
> >>  From an upstream perspective, I see us as being in the business of
> >> providing open collaboration playing fields in order to build projects
> >> to reach the OpenStack Mission. We collectively provide resources
> >> (infra, horizontal teams, events...) in order to enable that open
> >> collaboration.
> >>
> >> An important characteristic of these open collaboration grounds is that
> >> they need to be a level playing field, where no specific organization is
> >> being given an unfair advantage. I expect the teams that we bless as
> >> "official" project teams to operate in that fair manner. Otherwise we
> >> end up blessing what is essentially a trojan horse for a given
> >> organization, open-washing their project in the process. Such a project
> >> can totally exist as an unofficial project (and even be developed on
> >> OpenStack infrastructure) but I don't think it should be given free
> >> space in our Design Summits or benefit from "OpenStack community" branding.
> >>
> >> So if, in a given project team, developers from one specific
> >> organization benefit from access to specific knowledge or hardware
> >> (think 3rd-party testing blackboxes that decide if a patch goes in, or
> >> access to proprietary hardware or software that the open source code
> >> primarily interfaces with), then this project team should probably be
> >> rejected under the "open community" rule. Projects with a lot of drivers
> >> (like Cinder) provide an interesting grey area, but as long as all
> >> drivers are in and there is a fully functional (and popular) open source
> >> implementation, I think no specific organization would be considered as
> >> unfairly benefiting compared to others.
> >>
> >> A few months ago we had the discussion about what "no open core" means
> >> in 2016, in the context of the Poppy team candidacy. With our reading at
> >> the time we ended up rejecting Poppy partly because it was interfacing
> >> with proprietary technologies. However, I think what we originally
> >> wanted to ensure with this rule was that no specific organization would
> >> use the OpenStack open source code as crippled bait to sell their
> >> specific proprietary add-on.
> >>
> >> I think taking the view that OpenStack projects need to be open, level
> >> collaboration playing fields encapsulates that nicely. In the Poppy
> >> case, nobody in the Poppy team has an unfair advantage over others, so
> >> we should not reject them purely on the grounds that this interfaces
> >> with non-open-source solutions (leaving only the infrastructure/testing
> >> requirement to solve). On the other hand, a Neutron plugin targeting a
> >> specific piece of networking hardware would likely give an unfair
> >> advantage to developers of the hardware's manufacturer (having access to
> >> that gear for testing and being able to see and make changes to its
> >> proprietary source code) -- that project should probably live as an
> >> unofficial OpenStack project.
> >>
> >> Comments, thoughts ?
> >>
> >
> > I think external device-specific drivers are a much clearer case than
> > Poppy or Cinder. It's a bit unfortunate that the dissolution of some
> > projects into "core" and "driver" repositories is raising this issue,
> > but we've definitely had better success with some project teams than
> > others when it comes to vendors collaborating on core components.
> >
> 
> I don't see this as the "core and driver" problem bringing this issue
> up, as it exists out side of that. But it's true that in the case of
> Neutron, something had to give when we had 40+ drivers and a handful
> of cores maintaining both the neutron code itself and those drivers.

Sure! What I meant was that it's a shame so much maintenance fell to so
few folks. I wasn't second-guessing the hard choice to clarify what the
Neutron team felt you could support. That's completely within your
purview.

Doug

__
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] NUMA, huge pages, and scheduling

2016-06-15 Thread Jay Pipes

There have been a number of bug fixes to the NUMA code in both Mitaka 
and Newton. I think you would need to be very careful in your backporting :)

-jay

On 06/15/2016 09:55 AM, Paul Michali wrote:

Yeah, was thinking more of technically vs policy. Wondering if there are
other dependencies or if I could patch this into a Liberty code base.

On Wed, Jun 15, 2016 at 12:38 PM Jay Pipes > wrote:

On 06/15/2016 03:58 AM, Paul Michali wrote:
 > Awesome Jay!
 >
 > Do you think this is something that can be backporting to Liberty w/o
 > other dependencies? We're running Liberty on our system right now.

Doubtful, Paul :( The policy for upstream is not to backport feature
patches. This would be something you would need to do yourself -- i.e.
keep patch technical debt for whichever distribution of OpenStack you
are using (or sources if you're going that route).

Best,
-jay

__
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] [nova][cinder] Integration testing for Nova API os-assisted-volume-snapshots

2016-06-15 Thread Jordan Pittier

On Wed, Jun 15, 2016 at 6:21 PM, Matt Riedemann 
wrote:

> In the nova-api meeting today we were talking about the nova
> os-assisted-volume-snapshots API and whether or not it was a proxy API to
> cinder. We determined it's not, it performs an action on a server resource.
> But what a few of us didn't realize was it's an admin API in nova only for
> cinder RemoteFSSnapDrivers to call when creating a volume snapshot.
>
> From what I can tell, this is used in Cinder by the glusterfs, scality,
> quobyte and virtuozzo remotefs volume drivers.
>
> This is also a nova API that's only implemented for the libvirt compute
> driver - so gmann is going to document that in the nova api-ref for the API
> so it's at least communicated somewhere (it's not in the nova feature
> support matrix).
>
> The other thing I was wondering about was CI coverage. I looked through
> several cinder patches this morning looking for recent successful CI
> results for gluster/scality/quobyte but couldn't find any.
>
> Does someone have a link to a successful job run for one of those drivers?
> I'd like to see if they are testing volume snapshot and that it's properly
> calling the nova API and everything is working. Because this is also
> something that Nova could totally unknowingly break to that flow since we
> have no CI coverage for it (we don't have those cinder 3rd party CI jobs
> running against nova changes).
>
> --
>

Hi Matt,
I am in charge of the Scality CI. It used to report to changes in Cinder. A
change in devstack broke us a couple of months ago, so I had to turn off my
CI (because it was reporting false negative) while developing a patch. The
patch took a long time to develop and merge but was merged finally:
https://review.openstack.org/#/c/310204/

But in the mean time, something else crept in, hidden by the first failure.
So the Scality CI is still broken, but it is my intention to find the
commit that broke it and come up with a patch.

The C is still running on every change to Cinder, just that the result is
not reported back. Results are here
https://37.187.159.67:5443/job/cinder-sofs-validate/ (yeah, that's an IP
and with an invalid HTTPS certificate, I am not proud :p). This is the
build artififact (logs) for a job that ran a couple of hours ago:
https://37.187.159.67:5443/job/cinder-sofs-validate/17356/artifact/jenkins-logs/

So overall, I struggle to maintain that CI. Because I always have to play
catch up. That's fine but what bother me is that when I finally come up
with a patch (be it for Nova or Cinder) reviews take a long time because
basically not a lot of people care/know about
about os-assisted-volume-snapshots.

Cheers,
Jordan

-- 

__
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] NUMA, huge pages, and scheduling

2016-06-15 Thread Paul Michali

Yeah, was thinking more of technically vs policy. Wondering if there are
other dependencies or if I could patch this into a Liberty code base.


On Wed, Jun 15, 2016 at 12:38 PM Jay Pipes  wrote:

> On 06/15/2016 03:58 AM, Paul Michali wrote:
> > Awesome Jay!
> >
> > Do you think this is something that can be backporting to Liberty w/o
> > other dependencies? We're running Liberty on our system right now.
>
> Doubtful, Paul :( The policy for upstream is not to backport feature
> patches. This would be something you would need to do yourself -- i.e.
> keep patch technical debt for whichever distribution of OpenStack you
> are using (or sources if you're going that route).
>
> Best,
> -jay
>
> __
> 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] [murano] Nominating Alexander Tivelkov and Zhu Rong for murano cores

2016-06-15 Thread Serg Melikyan

+1

Finally!

On Wed, Jun 15, 2016 at 3:33 AM, Ihor Dvoretskyi 
wrote:

> +1 for Alexander Tivelkov.
>
> Good effort.
>
> On Wed, Jun 15, 2016 at 1:08 PM, Artem Silenkov 
> wrote:
>
>> Hello!
>>
>> +1
>>
>> Regards,
>> Artem Silenkov
>> ---
>> paas-team
>>
>> On Wed, Jun 15, 2016 at 12:56 PM, Dmytro Dovbii 
>> wrote:
>>
>>> +1
>>> 15 июня 2016 г. 6:47 пользователь "Yang, Lin A" 
>>> написал:
>>>
>>> +1 both for Alexander Tivelkov and Zhu Rong. Well deserved.

 Regards,
 Lin Yang

 On Jun 15, 2016, at 3:17 AM, Kirill Zaitsev 
 wrote:

 Hello team, I want to annonce the following changes to murano core team:

 1) I’d like to nominate Alexander Tivelkov for murano core. He has been
 part of the project for a very long time and has contributed to almost
 every part of murano. He has been fully committed to murano during mitaka
 cycle and continues doing so during newton [1]. His work on the scalable
 framework architecture is one of the most notable features scheduled for N
 release.

 2) I’d like to nominate Zhu Rong for murano core. Last time he was
 nominated I -1’ed the proposal, because I believed he needed to start
 making more substantial contributions. I’m sure that Zhu Rong showed his
 commitment [2] to murano project and I’m happy to nominate him myself. His
 work on the separating cfapi from murano api and contributions headed at
 addressing murano’s technical debt are much appreciated.

 3) Finally I would like to remove Steve McLellan[3] from murano core
 team. Steve has been part of murano from very early stages of it. However
 his focus has since shifted and he hasn’t been active in murano during last
 couple of cycles. I want to thank Steve for his contributions and express
 hope to see him back in the project in future.

 Murano team, please respond with +1/-1 to the proposed changes.

 [1] http://stackalytics.com/?user_id=ativelkov=marks
 [2] http://stackalytics.com/?metric=marks_id=zhu-rong
 [3] http://stackalytics.com/?user_id=sjmc7
 --
 Kirill Zaitsev
 Software Engineer
 Mirantis, Inc

 __
 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
>>
>>
>
>
> --
> Best regards,
>
> Ihor Dvoretskyi
>
> __
> 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
>
>

-- 
Serg Melikyan, Development Manager at Mirantis, Inc.
http://mirantis.com | smelik...@mirantis.com | +1 (650) 440-8979
__
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] NUMA, huge pages, and scheduling

2016-06-15 Thread Jay Pipes


On 06/15/2016 03:58 AM, Paul Michali wrote:

Awesome Jay!

Do you think this is something that can be backporting to Liberty w/o
other dependencies? We're running Liberty on our system right now.


Doubtful, Paul :( The policy for upstream is not to backport feature 
patches. This would be something you would need to do yourself -- i.e. 
keep patch technical debt for whichever distribution of OpenStack you 
are using (or sources if you're going that route).


Best,
-jay

__
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] Require a level playing field for OpenStack projects


Amrith Kumar wrote:

Thanks for writing this up and for the interesting discussion that has come up 
in this ML thread.

While I think I get the general idea of the motivation, I think the verbiage 
doesn't quite do justice to your intent.

One area which I would like to highlight is the situation with the underlying 
operating system on which the software is to run. What if that is proprietary 
software? Consider support for (for example) running on Red Hat or the Windows 
operating systems. That would not be something that could be easily abstracted 
into a 'driver'.

Another is the case of proprietary software; consider support in Trove for (for 
example) using the DB2 Express or the Vertica database. Clearly these are 
things where some have an advantage when compared to others.

I therefore suggest the following amendment in 
https://review.openstack.org/#/c/329448/.

* The project provides a level playing field for interested developers to 
collaborate. Where proprietary software, hardware, or other resources 
(including testing) are required, these should be reasonably accessible to 
interested contributors.


I replied to that on the review :)

--
Thierry Carrez (ttx)

__
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] [nova][cinder] Integration testing for Nova API os-assisted-volume-snapshots

In the nova-api meeting today we were talking about the nova 
os-assisted-volume-snapshots API and whether or not it was a proxy API 
to cinder. We determined it's not, it performs an action on a server 
resource. But what a few of us didn't realize was it's an admin API in 
nova only for cinder RemoteFSSnapDrivers to call when creating a volume 
snapshot.


From what I can tell, this is used in Cinder by the glusterfs, scality, 
quobyte and virtuozzo remotefs volume drivers.


This is also a nova API that's only implemented for the libvirt compute 
driver - so gmann is going to document that in the nova api-ref for the 
API so it's at least communicated somewhere (it's not in the nova 
feature support matrix).


The other thing I was wondering about was CI coverage. I looked through 
several cinder patches this morning looking for recent successful CI 
results for gluster/scality/quobyte but couldn't find any.


Does someone have a link to a successful job run for one of those 
drivers? I'd like to see if they are testing volume snapshot and that 
it's properly calling the nova API and everything is working. Because 
this is also something that Nova could totally unknowingly break to that 
flow since we have no CI coverage for it (we don't have those cinder 3rd 
party CI jobs running against nova changes).


--

Thanks,

Matt Riedemann


__
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][ovs] The way we deal with MTU

First, some context: we talked it thru with Eugene on IRC, and Eugene reported 
that he cannot reproduce the issue on his setup using Ubuntu hypervisor with 
ovs 2.4:

http://eavesdrop.openstack.org/irclogs/%23openstack-neutron/%23openstack-neutron.2016-06-13.log.html#t2016-06-13T19:45:22

So I went and did some testing with the functional test I have implemented. I 
validated the following setups:

- ubuntu 14.04 + ovs 2.0.x
- centos 7 + ovs 2.4
- centos 7 + ovs 2.5

All of them fail to pass the test. I also pushed the test without the fix into 
gate, and it failed too:

https://review.openstack.org/329558

So we definitely have some sort of issue that is independent of underlying 
distribution or Open vSwitch.

With that, I believe we should go forward with the fix as a short term 
solution: https://review.openstack.org/327651 (I removed WIP from it.)

I will also reach ovs developers on the matter to see if they can somehow allow 
us to disable the mtu curtailing, and still stay supported.

Ihar

> On 13 Jun 2016, at 19:43, Eugene Nikanorov  wrote:
> 
> That's interesting.
> 
> 
> In our deployments we do something like br-ex (linux bridge, mtu 9000) - 
> OVSIntPort (mtu 65000) - br-floating (ovs bridge, mtu 1500) - br-int (ovs 
> bridge, mtu 1500).
> qgs then are getting created in br-int, traffic goes all the way and that 
> altogether allows jumbo frames over external network.
> 
> For that reason I thought that mtu inside OVS doesn't really matter. 
> This, however is for ovs 2.4.1
> 
> I wonder if that behavior has changed and if the description is available 
> anywhere.
> 
> Thanks,
> Eugene.
> 
> On Mon, Jun 13, 2016 at 9:49 AM, Ihar Hrachyshka  wrote:
> Hi all,
> 
> in Mitaka, we introduced a bunch of changes to the way we handle MTU in 
> Neutron/Nova, making sure that the whole instance data path, starting from 
> instance internal interface, thru hybrid bridge, into the br-int; as well as 
> router data path (qr) have proper MTU value set on all participating devices. 
> On hypervisor side, both Nova and Neutron take part in it, setting it with 
> ip-link tool based on what Neutron plugin calculates for us. So far so good.
> 
> Turns out that for OVS, it does not work as expected in regards to br-int. 
> There was a bug reported lately: https://launchpad.net/bugs/1590397
> 
> Briefly, when we try to set MTU on a device that is plugged into a bridge, 
> and if the bridge already has another port with lower MTU, the bridge itself 
> inherits MTU from that latter port, and Linux kernel (?) does not allow to 
> set MTU on the first device at all, making ip link calls ineffective.
> 
> AFAIU this behaviour is consistent with Linux bridging rules: you can’t have 
> ports of different MTU plugged into the same bridge.
> 
> Now, that’s a huge problem for Neutron, because we plug ports that belong to 
> different networks (and that hence may have different MTUs) into the same 
> br-int bridge.
> 
> So I played with the code locally a bit and spotted that currently, we set 
> MTU for router ports before we move their devices into router namespaces. And 
> once the device is in a namespace, ip-link actually works. So I wrote a fix 
> with a functional test that proves the point: 
> https://review.openstack.org/#/c/327651/ The fix was validated by the 
> reporter of the original bug and seems to fix the issue for him.
> 
> It’s suspicious that it works from inside a namespace but not when the device 
> is still in the root namespace. So I reached out to Jiri Benc from our local 
> Open vSwitch team, and here is a quote:
> 
> ===
> 
> "It's a bug in ovs-vswitchd. It doesn't see the interface that's in
> other netns and thus cannot enforce the correct MTU.
> 
> We'll hopefully fix it and disallow incorrect MTU setting even across
> namespaces. However, it requires significant effort and rework of ovs
> name space handling.
> 
> You should not depend on the current buggy behavior. Don't set MTU of
> the internal interfaces higher than the rest of the bridge, it's not
> supported. Hacking this around by moving the interface to a netns is
> exploiting of a bug.
> 
> We can certainly discuss whether this limitation could be relaxed.
> Honestly, I don't know, it's for a discussion upstream. But as of now,
> it's not supported and you should not do it.”
> 
> So basically, as long as we try to plug ports with different MTUs into the 
> same bridge, we are utilizing a bug in Open vSwitch, that may break us any 
> time.
> 
> I guess our alternatives are:
> - either redesign bridge setup for openvswitch to e.g. maintain a bridge per 
> network;
> - or talk to ovs folks on whether they may support that for us.
> 
> I understand the former option is too scary. It opens lots of questions, 
> including upgrade impact since it will obviously introduce a dataplane 
> downtime. That would be a huge shift in paradigm, probably too huge to 
> swallow. The latter option may not

Re: [openstack-dev] [Octavia] [lbaas] Mid-Cycle proposed for the week of August 22nd

2016-06-15 Thread Trevor Vardeman

For most of the mid cycles we've set up some video conferencing for remote 
people to participate.  I'll add a new section in the etherpad for remote 
people so we can set up all that information in one location.


-Trevor



From: Nir Magnezi 
Sent: Wednesday, June 15, 2016 5:43 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Octavia] [lbaas] Mid-Cycle proposed for the week 
of August 22nd

Hi Michael,

Will there be an option to participate from remote?

Thanks,
Nir

On Fri, Jun 10, 2016 at 1:51 AM, Michael Johnson 
> wrote:
Just a reminder, we have a proposed mid-cycle meeting set for the week
of August 22nd in San Antonio.

If you would like to attend and have not yet signed up, please add
your name to the list on our etherpad:

https://etherpad.openstack.org/p/lbaas-octavia-newton-midcycle

Thank you,
Michael

__
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] [all][tc] Require a level playing field for OpenStack projects

2016-06-15 Thread Amrith Kumar

Thierry,

Thanks for writing this up and for the interesting discussion that has come up 
in this ML thread.

While I think I get the general idea of the motivation, I think the verbiage 
doesn't quite do justice to your intent.

One area which I would like to highlight is the situation with the underlying 
operating system on which the software is to run. What if that is proprietary 
software? Consider support for (for example) running on Red Hat or the Windows 
operating systems. That would not be something that could be easily abstracted 
into a 'driver'. 

Another is the case of proprietary software; consider support in Trove for (for 
example) using the DB2 Express or the Vertica database. Clearly these are 
things where some have an advantage when compared to others.

I therefore suggest the following amendment in 
https://review.openstack.org/#/c/329448/.

* The project provides a level playing field for interested developers to 
collaborate. Where proprietary software, hardware, or other resources 
(including testing) are required, these should be reasonably accessible to 
interested contributors.

Thanks,

-amrith

> -Original Message-
> From: Thierry Carrez [mailto:thie...@openstack.org]
> Sent: Tuesday, June 14, 2016 9:57 AM
> To: OpenStack Development Mailing List 
> Subject: [openstack-dev] [all][tc] Require a level playing field for
> OpenStack projects
> 
> Hi everyone,
> 
> I just proposed a new requirement for OpenStack "official" projects,
> which I think is worth discussing beyond the governance review:
> 
> https://review.openstack.org/#/c/329448/
> 
>  From an upstream perspective, I see us as being in the business of
> providing open collaboration playing fields in order to build projects
> to reach the OpenStack Mission. We collectively provide resources
> (infra, horizontal teams, events...) in order to enable that open
> collaboration.
> 
> An important characteristic of these open collaboration grounds is that
> they need to be a level playing field, where no specific organization is
> being given an unfair advantage. I expect the teams that we bless as
> "official" project teams to operate in that fair manner. Otherwise we
> end up blessing what is essentially a trojan horse for a given
> organization, open-washing their project in the process. Such a project
> can totally exist as an unofficial project (and even be developed on
> OpenStack infrastructure) but I don't think it should be given free
> space in our Design Summits or benefit from "OpenStack community"
> branding.
> 
> So if, in a given project team, developers from one specific
> organization benefit from access to specific knowledge or hardware
> (think 3rd-party testing blackboxes that decide if a patch goes in, or
> access to proprietary hardware or software that the open source code
> primarily interfaces with), then this project team should probably be
> rejected under the "open community" rule. Projects with a lot of drivers
> (like Cinder) provide an interesting grey area, but as long as all
> drivers are in and there is a fully functional (and popular) open source
> implementation, I think no specific organization would be considered as
> unfairly benefiting compared to others.
> 
> A few months ago we had the discussion about what "no open core" means
> in 2016, in the context of the Poppy team candidacy. With our reading at
> the time we ended up rejecting Poppy partly because it was interfacing
> with proprietary technologies. However, I think what we originally
> wanted to ensure with this rule was that no specific organization would
> use the OpenStack open source code as crippled bait to sell their
> specific proprietary add-on.
> 
> I think taking the view that OpenStack projects need to be open, level
> collaboration playing fields encapsulates that nicely. In the Poppy
> case, nobody in the Poppy team has an unfair advantage over others, so
> we should not reject them purely on the grounds that this interfaces
> with non-open-source solutions (leaving only the infrastructure/testing
> requirement to solve). On the other hand, a Neutron plugin targeting a
> specific piece of networking hardware would likely give an unfair
> advantage to developers of the hardware's manufacturer (having access to
> that gear for testing and being able to see and make changes to its
> proprietary source code) -- that project should probably live as an
> unofficial OpenStack project.
> 
> Comments, thoughts ?
> 
> --
> Thierry Carrez (ttx)
> 
> __
> 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:

Re: [openstack-dev] [ceilometer] [stable] Re: [Openstack-stable-maint] Stable check of openstack/ceilometer failed

2016-06-15 Thread Ian Cordasco

-Original Message-
From: gordon chung 
Reply: gordon chung 
Date: June 14, 2016 at 21:14:17
To: Ian Cordasco , OpenStack Development Mailing List 
(not for usage questions) 
Subject:  Re: [openstack-dev] [ceilometer] [stable] Re: 
[Openstack-stable-maint] Stable check of openstack/ceilometer failed

> that's strange, i tried to see if it's just Ceilometer. the
> periodic-neutron-python27-liberty job seems to be capped appropriately
> to oslo.utils 3.2.0. maybe it's a dependency? the
> periodic-nova-python27-liberty job doesn't seem to have any entries
> since March so i can't verify that.

So I looked at 
http://logs.openstack.org/periodic-stable/periodic-ceilometer-python27-liberty/3adba17/tox/py27-1.log.txt
 which comes from the latest stable/liberty periodic job failure: 
http://logs.openstack.org/periodic-stable/periodic-ceilometer-python27-liberty/3adba17/testr_results.html.gz
 and it if search for oslo.utils it's installing 3.13.0 from requirements.txt.

Perhaps something regressed on stable/liberty?
--  
Ian Cordasco

__
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] [Nova] Virt device role tagging for other virt drivers

2016-06-15 Thread Artom Lifshitz

Hey folks,

For a while now we've been working on virt device role tagging.

The full spec is here [1], but the quick gist of it is that device
tagging is a way for the user to assign arbitrary string tags to
either vNICs or block devices. Those tags then get exposed by the
metadata API to the guest, along with other device metadata such as
bus and address, for example PCI :00:02.0.

This work is being done for the libvirt driver, and we would obviously
love it if other drivers implemented the functionality. This email is
meant to get this cooperation started.

A good starting point for developers of other drivers is our own
libvirt implementation [2]. The basic idea is that we use new objects
from [3] to build the metadata hierarchy. The hierarchy is then saved
in the database in the instance_extra table, of which you can see the
details here [4]. This is pretty much the only functionality that
other virt drivers would need to implement. Everything else (API,
metadata API) is being handled by us, though of course we welcome your
feedback.

I hope I've been concise yet complete. If you have any questions don't
hesitate to ask either vladikr or artom on IRC.

Cheers!

[1]
http://specs.openstack.org/openstack/nova-specs/specs/newton/approved/virt-device-role-tagging.html
[2] https://review.openstack.org/#/c/264016/42/nova/virt/libvirt/driver.py
[3]
https://github.com/openstack/nova/blob/master/nova/objects/virt_device_metadata.py
[4] https://review.openstack.org/#/c/327920/

--
Artom Lifshitz

Re: [openstack-dev] [all][tc] Require a level playing field for OpenStack projects

2016-06-15 Thread Kyle Mestery

On Tue, Jun 14, 2016 at 9:15 AM, Doug Hellmann  wrote:
> Excerpts from Thierry Carrez's message of 2016-06-14 15:57:10 +0200:
>> Hi everyone,
>>
>> I just proposed a new requirement for OpenStack "official" projects,
>> which I think is worth discussing beyond the governance review:
>>
>> https://review.openstack.org/#/c/329448/
>>
>>  From an upstream perspective, I see us as being in the business of
>> providing open collaboration playing fields in order to build projects
>> to reach the OpenStack Mission. We collectively provide resources
>> (infra, horizontal teams, events...) in order to enable that open
>> collaboration.
>>
>> An important characteristic of these open collaboration grounds is that
>> they need to be a level playing field, where no specific organization is
>> being given an unfair advantage. I expect the teams that we bless as
>> "official" project teams to operate in that fair manner. Otherwise we
>> end up blessing what is essentially a trojan horse for a given
>> organization, open-washing their project in the process. Such a project
>> can totally exist as an unofficial project (and even be developed on
>> OpenStack infrastructure) but I don't think it should be given free
>> space in our Design Summits or benefit from "OpenStack community" branding.
>>
>> So if, in a given project team, developers from one specific
>> organization benefit from access to specific knowledge or hardware
>> (think 3rd-party testing blackboxes that decide if a patch goes in, or
>> access to proprietary hardware or software that the open source code
>> primarily interfaces with), then this project team should probably be
>> rejected under the "open community" rule. Projects with a lot of drivers
>> (like Cinder) provide an interesting grey area, but as long as all
>> drivers are in and there is a fully functional (and popular) open source
>> implementation, I think no specific organization would be considered as
>> unfairly benefiting compared to others.
>>
>> A few months ago we had the discussion about what "no open core" means
>> in 2016, in the context of the Poppy team candidacy. With our reading at
>> the time we ended up rejecting Poppy partly because it was interfacing
>> with proprietary technologies. However, I think what we originally
>> wanted to ensure with this rule was that no specific organization would
>> use the OpenStack open source code as crippled bait to sell their
>> specific proprietary add-on.
>>
>> I think taking the view that OpenStack projects need to be open, level
>> collaboration playing fields encapsulates that nicely. In the Poppy
>> case, nobody in the Poppy team has an unfair advantage over others, so
>> we should not reject them purely on the grounds that this interfaces
>> with non-open-source solutions (leaving only the infrastructure/testing
>> requirement to solve). On the other hand, a Neutron plugin targeting a
>> specific piece of networking hardware would likely give an unfair
>> advantage to developers of the hardware's manufacturer (having access to
>> that gear for testing and being able to see and make changes to its
>> proprietary source code) -- that project should probably live as an
>> unofficial OpenStack project.
>>
>> Comments, thoughts ?
>>
>
> I think external device-specific drivers are a much clearer case than
> Poppy or Cinder. It's a bit unfortunate that the dissolution of some
> projects into "core" and "driver" repositories is raising this issue,
> but we've definitely had better success with some project teams than
> others when it comes to vendors collaborating on core components.
>

I don't see this as the "core and driver" problem bringing this issue
up, as it exists out side of that. But it's true that in the case of
Neutron, something had to give when we had 40+ drivers and a handful
of cores maintaining both the neutron code itself and those drivers.

> Doug
>
> __
> 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] [tempest][nova][defcore] Add option to disable some strict response checking for interop testing

2016-06-15 Thread Mark Voelker


> On Jun 15, 2016, at 8:01 AM, Sean Dague  wrote:
> 
> On 06/15/2016 12:14 AM, Mark Voelker wrote:
> 
>> 
>> It is perhaps important to note here that the DefCore seems to have two 
>> meanings to a lot of people I talk to today: it’s a mark of interoperability 
>> (the OpenStack Powered badge that says certain capabilities of this cloud 
>> behave like other clouds bearing the mark) and it gives a cloud the ability 
>> to call itself OpenStack (e.g. you can get a trademark/logo license 
>> agreement from the Foundation).  
>> 
>> The OpenStack Powered program currently covers Icehouse through Mitaka.  
>> Right now, that includes releases that were still on the Nova 2.0 API.  API 
>> extensions were a supported thing [1] back in 2.0 and it was even explicitly 
>> documented that they allowed for additional attributes in the responses and 
>> “vendor specific niche functionality [1]”.  The change to the Tempest tests 
>> [2] applied to the 2.0 API as well as 2.1 with the intent of preventing 
>> further changes from getting into the 2.0 API at the gate, which totally 
>> makes sense as a gate test.  If those same tests are used for DefCore 
>> purposes, it does change what vendors need to do to be compliant with the 
>> Guidelines rather immediately--even on older releases of OpenStack using 
>> 2.0, which could be problematic (as noted elsewhere already [3]).
> 
> Right, that's fair. And part of why I think the pass* makes sense.
> Liberty is the introduction of microversions on by default for clouds
> from Nova upstream configs.
> 
>> So, through the interoperability lens: I think many folks acknowledge that 
>> supporting extensions lead to a lot of variance between clouds, and that was 
>> Not So Awesome for interoperability.  IIRC part of the rationale for 
>> switching to microversions with a single monotonic counter and deprecating 
>> extensions [4] was to set a course for eliminating a lot of that behavioral 
>> variance.
>> 
>> From the “ability to call yourself OpenStack” lens: it feels sort of wrong 
>> to tell a cloud that it can’t claim to be OpenStack because it’s running a 
>> version that falls within the bounds of the Powered program with the 2.0 API 
>> (when extensions weren't deprecated) and using the extension mechanism that 
>> 2.0 supported for years.
> 
> To be clear, extensions weren't a part of the 2.0 API, they were a part
> of the infrastructure. It's a subtle but different point. Nova still
> supports the 2.0 API, but on different infrastructure, which
> doesn't/won't support extensions.
> 
> Are people registering new Kilo (or earlier) clouds in the system today?
> By the time folks get to Newton, none of that is going to work anyway in
> code.

Yes.  As recently as January we had a Juno-based public cloud run into this 
issue [1].  And, just to highlight again: there's a pretty long tail here since 
the OpenStack Powered program covers a lot of releases.  

[1] 
http://lists.openstack.org/pipermail/defcore-committee/2016-January/000986.html

> 
> In an ideal world product teams would be close enough to upstream code
> and changes to see all this coming and be on top of it. In the real
> world, a lot of these teams are like a year (or more) behind, which

+1.  If folks aren’t aware, it may be worth pointing out that as of the User 
Survey from two months ago, Kilo was the most popular release and Juno was the 
third most popular [2].  I don’t presume to know why so many deployments are on 
older releases, but I suspect the rationale is different for different folks.  
Maybe for some it’s because people are choosing to used products and a lot of 
those are based on older releases.  Maybe for others it’s because people are 
deliberately choosing older stable branches.  Maybe for some it’s because they 
they’ve decided that upgrading every six months or following master more 
closely just isn’t a good strategy for them.  Maybe for others it’s something 
else entirely.  But again, you’re right: in the real world the tail is long 
today.

[2] https://www.openstack.org/assets/survey/April-2016-User-Survey-Report.pdf 
(figure 4.3/4.4)

> actually makes Defcore with a pass* an ideal alternative communication
> channel to express that products are coming up to a cliff, and should
> start working on plans now.

Agreed.

> 
>> I think that’s part of what makes this issue tricky for a lot of folks.
>> 
>> [1] http://docs.openstack.org/developer/nova/v2/extensions.html
> 
> It's an unfortunate accident of bugs in our publishing system that that
> URL still exists. That was deleted in Oct 2015. I'll look at getting it
> properly cleaned up.
> 

Awesome, thanks Sean!  I’ll make a point to comb around and see if there are 
other such references that we should clean up too. 

Just to be clear though, my main point isn’t that the doc still exists today, 
it’s that it existed.  In the relatively recent past (from a long-tail 
perspective) extensions were documented as an

Re: [openstack-dev] [release][infra] networking-onos 2.0.0 not on our pypi mirrors

2016-06-15 Thread Doug Hellmann

Excerpts from mohammad shahid's message of 2016-06-15 16:32:10 +0530:
> Hi,
> 
> Can someone look at this networking-onos 2.0.0 not on our pypi please ?
> 
> reference links:
> https://launchpad.net/networking-onos
> https://pypi.python.org/pypi/networking-onos
> 
> 
> Thanks and Regards,
> Mohammad Shahid

The logs for the release jobs for that version can be found at
http://logs.openstack.org/a6/a65d57c4aa18624a5a936ad9f4dab3e49e030aea/

According to the upload log [1] the upload to PyPI failed because
the 2.0.0 wheel couldn't be found.

According to the tarball log [2] the file couldn't be found because the
version it thinks it has is 2016.1.0 instead of 2.0.0, so the filename
is wrong.

It looks like commit 2dc75353114a2115c61109385757fbf4ce21c57b checked in
a PKG-INFO file, which pbr is reading, and the file includes the bad
version number. I'm not sure why that file was added (it appears to be
related to RPM packaging, but no other projects have needed to add files
like that).

So to fix the problem you'll need to sort out the issue with PKG-INFO
and then tag a new version that includes whatever commits are needed
to make the version appear correct.

To test the version locally, use "python setup.py --version" until it
gives you a version in like 2.0.1.devN (meaning a development version
leading up to 2.0.1, which is the version you'll tag).

Doug

[1] 
http://logs.openstack.org/a6/a65d57c4aa18624a5a936ad9f4dab3e49e030aea/release/networking-onos-pypi-both-upload/e61917b/console.html.gz
[2] 
http://logs.openstack.org/a6/a65d57c4aa18624a5a936ad9f4dab3e49e030aea/release/networking-onos-tarball/07814ec/console.html.gz

__
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] [tempest][nova][defcore] Add option to disable some strict response checking for interop testing

2016-06-15 Thread Doug Hellmann

Excerpts from Chris Hoge's message of 2016-06-14 16:37:06 -0700:
> Top posting one note and direct comments inline, I’m proposing
> this as a member of the DefCore working group, but this
> proposal itself has not been accepted as the forward course of
> action by the working group. These are my own views as the
> administrator of the program and not that of the working group
> itself, which may independently reject the idea outside of the
> response from the upstream devs.
> 
> I posted a link to this thread to the DefCore mailing list to make
> that working group aware of the outstanding issues.
> 
> > On Jun 14, 2016, at 3:50 PM, Matthew Treinish  wrote:
> > 
> > On Tue, Jun 14, 2016 at 05:42:16PM -0400, Doug Hellmann wrote:
> >> Excerpts from Matthew Treinish's message of 2016-06-14 15:12:45 -0400:
> >>> On Tue, Jun 14, 2016 at 02:41:10PM -0400, Doug Hellmann wrote:
>  Excerpts from Matthew Treinish's message of 2016-06-14 14:21:27 -0400:
> > On Tue, Jun 14, 2016 at 10:57:05AM -0700, Chris Hoge wrote:
> >> Last year, in response to Nova micro-versioning and extension 
> >> updates[1],
> >> the QA team added strict API schema checking to Tempest to ensure that
> >> no additional properties were added to Nova API responses[2][3]. In the
> >> last year, at least three vendors participating the the OpenStack 
> >> Powered
> >> Trademark program have been impacted by this change, two of which
> >> reported this to the DefCore Working Group mailing list earlier this 
> >> year[4].
> >> 
> >> The DefCore Working Group determines guidelines for the OpenStack 
> >> Powered
> >> program, which includes capabilities with associated functional tests
> >> from Tempest that must be passed, and designated sections with 
> >> associated
> >> upstream code [5][6]. In determining these guidelines, the working 
> >> group
> >> attempts to balance the future direction of development with lagging
> >> indicators of deployments and user adoption.
> >> 
> >> After a tremendous amount of consideration, I believe that the DefCore
> >> Working Group needs to implement a temporary waiver for the strict API
> >> checking requirements that were introduced last year, to give 
> >> downstream
> >> deployers more time to catch up with the strict micro-versioning
> >> requirements determined by the Nova/Compute team and enforced by the
> >> Tempest/QA team.
> > 
> > I'm very much opposed to this being done. If we're actually concerned 
> > with
> > interoperability and verify that things behave in the same manner 
> > between multiple
> > clouds then doing this would be a big step backwards. The fundamental 
> > disconnect
> > here is that the vendors who have implemented out of band extensions or 
> > were
> > taking advantage of previously available places to inject extra 
> > attributes
> > believe that doing so means they're interoperable, which is quite far 
> > from
> > reality. **The API is not a place for vendor differentiation.**
>  
>  This is a temporary measure to address the fact that a large number
>  of existing tests changed their behavior, rather than having new
>  tests added to enforce this new requirement. The result is deployments
>  that previously passed these tests may no longer pass, and in fact
>  we have several cases where that's true with deployers who are
>  trying to maintain their own standard of backwards-compatibility
>  for their end users.
> >>> 
> >>> That's not what happened though. The API hasn't changed and the tests 
> >>> haven't
> >>> really changed either. We made our enforcement on Nova's APIs a bit 
> >>> stricter to
> >>> ensure nothing unexpected appeared. For the most these tests work on any 
> >>> version
> >>> of OpenStack. (we only test it in the gate on supported stable releases, 
> >>> but I
> >>> don't expect things to have drastically shifted on older releases) It also
> >>> doesn't matter which version of the API you run, v2.0 or v2.1. Literally, 
> >>> the
> >>> only case it ever fails is when you run something extra, not from the 
> >>> community,
> >>> either as an extension (which themselves are going away [1]) or another 
> >>> service
> >>> that wraps nova or imitates nova. I'm personally not comfortable saying 
> >>> those
> >>> extras are ever part of the OpenStack APIs.
> >>> 
>  We have basically three options.
>  
>  1. Tell deployers who are trying to do the right for their immediate
>    users that they can't use the trademark.
>  
>  2. Flag the related tests or remove them from the DefCore enforcement
>    suite entirely.
>  
>  3. Be flexible about giving consumers of Tempest time to meet the
>    new requirement by providing a way to disable the checks.
>  
>  Option 1 goes against our own

Re: [openstack-dev] [cinder]The backend-group concept in Cinder

2016-06-15 Thread Erlon Cruz

You can define several backends with the same volume_backend_name and call
that a group. For example:
[groupA-be1]
volume_backend_name=fast-ssd

[groupA-be2]
volume_backend_name=fast-ssd

[groupB-be3]
volume_backend_name=slow-disk

So, no matter what storage is behind every backend, it will be filtered
 based on the backend_name (and the other capabilities each backend
reports). If you don't want to restart the volume service to each backend
you add. You can add another instance of cinder-volume, even in the same
controller. The scheduler will know how to handle the new ones.

Erlon


On Tue, Jun 14, 2016 at 6:15 AM, chen ying  wrote:

> Hi Duncan Thomas,
> Does you means we can create a volume type include list of backend
> names(such as: backend_name=" name1 name2 name3 name4"), so when we
> create a volume, we can use the volume type to choose  one backend from
> these list of backend names(name1,name2,name3,name4)?
> But in this way, we cannot show the backends obviously capabilities to
> users(such as: performance, ssd, spinning-rust etc).
>
>
>
> --
> *发件人:* Duncan Thomas 
> *发送时间:* 2016年6月14日 8:03
> *收件人:* OpenStack Development Mailing List (not for usage questions)
> *主题:* Re: [openstack-dev] [cinder]The backend-group concept in Cinder
>
> As long as each backend has a unique name, you can key the type to a list
> of backend names if there's no useful capabilities to key off. No restart
> required.
>
> On 14 June 2016 at 10:16, chen ying  wrote:
>
>> Hi John,
>>
>>
>>
>> User case 1:
>>   The  backends in backend-group-1 have SSD disk, more memory .
>> The backend-group-1 can provide higher performance to user.
>>   The other  backends  in  backend-group-2 have HHD disk, more
>> capacity. The backend-group-2 can provide more storage space to user .
>>
>> Not sure, but we sort of do some of this already via the filter
>> scheduler.  An Admin can define various types (they may be set up based on
>> performance, ssd, spinning-rust etc).  Those types are then given arbitrary
>> definitions via a type (again details hidden from end user) and he/she can
>> create volumes of a specific type.
>>
>>
>>
>> Yes,  An Admin can arbitrary define various types and he/she can create
>> volumes of a specific type. But we need to restart our cinder driver after
>> define various types in each driver(If the driver cannot report
>> capabilities by itself). It will not easy to manage for Admin.
>>
>> Does Admin could use the concept of dynamically adding/removing backends
>> to backend-group. In this way, we not need to modify backend configure
>> file(such as: report a capabilities of ssd, spinning-rust etc).We can
>> arbitrary define various types for backend-group, and also he/she can
>> create volumes of a specific type(from backend-group type).
>>
>> So for example I could say "I want these backends with capability XYZ",
>> and many of backends from different vendors. How to manage these backends
>> by Administrator?
>>
>> Currently:
>>
>> 1.Admin need modify backend configure file, let the backend
>> report capability XYZ to filter scheduler.
>>
>> 2.Restart the volume service, make the capability valid
>>
>> 3.Create volume type(test_type) with capability XYZ.
>>
>> 4.he/she can create volumes of a specific type(test_type)
>>
>>Now we expect:
>>
>> 1.Admin add backend to backend-group
>>
>> 2.Create volume type(test_type) with capability XYZ, use
>> frefix(group or something else (group: capability = XYZ)) to distinguish
>> between the backend capability and the backend-group capability.
>>
>> 3.he/she can create volumes of a specific type(test_type)
>>
>>
>> __
>> 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
>>
>>
>
>
> --
> --
> Duncan Thomas
>
> __
> 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] [ovs-discuss] [OVN] [networking-ovn] [networking-sfc] SFC andOVN

2016-06-15 Thread Na Zhu

Hi John,

I update the networking-sfc and networking-ovn for the new schema. 
I think the most important now is nail down the ovsdb schema for SFC, as 
you know, it is not hard to implement networking-sfc and networking-ovn, 
but if the schema changes, we have to update networking-sfc and 
networking-ovn, the schema is the basic, it is better to finalize it at 
the beginning.

Ryan has some comments one the new version. We need to discuss together 
and finalize it which we all agree with.


Regards,
Juno Zhu
IBM China Development Labs (CDL) Cloud IaaS Lab
Email: na...@cn.ibm.com
5F, Building 10, 399 Keyuan Road, Zhangjiang Hi-Tech Park, Pudong New 
District, Shanghai, China (201203)



From:   John McDowall 
To: Na Zhu/China/IBM@IBMCN
Cc: discuss , "OpenStack Development Mailing 
List (not for usage questions)" , 
"Srilatha Tangirala" 
Date:   2016/06/15 09:35
Subject:Re: [openstack-dev] [ovs-discuss] [OVN] [networking-ovn] 
[networking-sfc] SFC andOVN



Juno,

Thanks really appreciate the help

Regards
John

Sent from my iPhone

On Jun 14, 2016, at 6:12 PM, Na Zhu  wrote:

John,

OK, I will change networking-ovn IDL to align with the new schema.




Regards,
Juno Zhu
IBM China Development Labs (CDL) Cloud IaaS Lab
Email: na...@cn.ibm.com
5F, Building 10, 399 Keyuan Road, Zhangjiang Hi-Tech Park, Pudong New 
District, Shanghai, China (201203)



From:John McDowall 
To:Na Zhu/China/IBM@IBMCN
Cc:discuss , "OpenStack Development 
Mailing List (not for usage questions)" , "Srilatha Tangirala" 
Date:2016/06/15 08:30
Subject:Re: [openstack-dev] [ovs-discuss] [OVN] [networking-ovn] 
[networking-sfc] SFC andOVN



Juno,

I worked on ovs/ovn today and re-structured the schema. I could not figure 
out how to make this work without have lport-chains as a child of lswitch. 
So I have got the basics working �C attached a simple shell script that 
creates and shows the port-chains. I tried to merge with the upstream 
master but there are a bunch of changes that while minor would have taken 
sometime to merge in, so I skipped it for now.

The new schema will break the networking-ovn IDL, apologies.  The areas I 
can think of are:

Port-chain is now a child of lswitch so needs that as a parameter.
Flow-classifier is now a child of port-chain only so need to change from 
lswitch to lport-chain

If you can work on the changes to networking-ovn great (I promise not to 
change the schema again until we have had a wider review). If not I will 
get to it tomorrow. 

Regards

John

From: Na Zhu 
Date: Monday, June 13, 2016 at 9:57 PM
To: John McDowall 
Cc: discuss , "OpenStack Development Mailing List 
(not for usage questions)" , Srilatha 
Tangirala 
Subject: Re: [openstack-dev] [ovs-discuss] [OVN] [networking-ovn] 
[networking-sfc] SFC andOVN

Hi John,

OK, I also find the column "port_pairs" and "flow_classifiers" can not be 
wrote by idl APIs, I will try to fix it.
If any update, i will send you email.



Regards,
Juno Zhu
IBM China Development Labs (CDL) Cloud IaaS Lab
Email: na...@cn.ibm.com
5F, Building 10, 399 Keyuan Road, Zhangjiang Hi-Tech Park, Pudong New 
District, Shanghai, China (201203)



From:John McDowall 
To:Na Zhu/China/IBM@IBMCN
Cc:"OpenStack Development Mailing List (not for usage questions)" 
, discuss , 
Srilatha Tangirala 
Date:2016/06/14 12:17
Subject:Re: [openstack-dev] [ovs-discuss] [OVN] [networking-ovn] 
[networking-sfc] SFC andOVN



Juno,

Trying to implement this today showed that this will not work for OVN. I 
am going back to RussellB 's original model with port-chain as a child of 
lswitch. 

I can make this work and then we can evolve from there. It will require 
some re-write of the idl code - hopefully I will get it done tomorrow.

Regards

John

Sent from my iPhone

On Jun 13, 2016, at 8:41 PM, Na Zhu  wrote:

Hi John,

I see you add column "port_pairs" and "flow_classifiers" to table 
Logical_Switch, I am not clear about it, the port-pair ingress port and 
egress port can be the same, they also can be different and in 
same/different network, and the flow classifier is not per network 
neither, can you explain why you do that?




Regards,
Juno Zhu
IBM China Development Labs (CDL) Cloud IaaS Lab
Email: na...@cn.ibm.com
5F, Building 10, 399 Keyuan Road, Zhangjiang Hi-Tech Park, Pudong New 
District, Shanghai, China (201203)



From:Na Zhu/China/IBM@IBMCN
To:John McDowall

Re: [openstack-dev] [all][tc] Require a level playing field for OpenStack projects

2016-06-15 Thread Davanum Srinivas

Neil,

On Wed, Jun 15, 2016 at 3:17 AM, Neil Jerram  wrote:
> On Wed, Jun 15, 2016 at 9:52 AM Thierry Carrez 
> wrote:
>>
>> [...]
>> Those are good points. Note that I do not advocate for those projects to
>> be kept closed/private: I'm simply saying that those (open source)
>> projects should not be blessed as "official" and be put under the
>> Technical Committee oversight. They can still exist in the OpenStack
>> ecosystem, be developed using Gerrit and an openstack/* git repository,
>> be plugged into the gate... but as an unofficial project.
>
>
> Could you point me to where it's described how to create and operate an
> unofficial project like that?  (Or are you talking about a possible future
> arrangement that doesn't already exist?)

Please see here:
http://docs.openstack.org/infra/manual/creators.html

>
> Thanks,
> Neil
>
>
> __
> 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
>



-- 
Davanum Srinivas :: https://twitter.com/dims

__
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] [tempest][nova][defcore] Add option to disable some strict response checking for interop testing

2016-06-15 Thread Sean Dague

On 06/15/2016 12:14 AM, Mark Voelker wrote:

> 
> It is perhaps important to note here that the DefCore seems to have two 
> meanings to a lot of people I talk to today: it’s a mark of interoperability 
> (the OpenStack Powered badge that says certain capabilities of this cloud 
> behave like other clouds bearing the mark) and it gives a cloud the ability 
> to call itself OpenStack (e.g. you can get a trademark/logo license agreement 
> from the Foundation).  
> 
> The OpenStack Powered program currently covers Icehouse through Mitaka.  
> Right now, that includes releases that were still on the Nova 2.0 API.  API 
> extensions were a supported thing [1] back in 2.0 and it was even explicitly 
> documented that they allowed for additional attributes in the responses and 
> “vendor specific niche functionality [1]”.  The change to the Tempest tests 
> [2] applied to the 2.0 API as well as 2.1 with the intent of preventing 
> further changes from getting into the 2.0 API at the gate, which totally 
> makes sense as a gate test.  If those same tests are used for DefCore 
> purposes, it does change what vendors need to do to be compliant with the 
> Guidelines rather immediately--even on older releases of OpenStack using 2.0, 
> which could be problematic (as noted elsewhere already [3]).

Right, that's fair. And part of why I think the pass* makes sense.
Liberty is the introduction of microversions on by default for clouds
from Nova upstream configs.

> So, through the interoperability lens: I think many folks acknowledge that 
> supporting extensions lead to a lot of variance between clouds, and that was 
> Not So Awesome for interoperability.  IIRC part of the rationale for 
> switching to microversions with a single monotonic counter and deprecating 
> extensions [4] was to set a course for eliminating a lot of that behavioral 
> variance.
> 
> From the “ability to call yourself OpenStack” lens: it feels sort of wrong to 
> tell a cloud that it can’t claim to be OpenStack because it’s running a 
> version that falls within the bounds of the Powered program with the 2.0 API 
> (when extensions weren't deprecated) and using the extension mechanism that 
> 2.0 supported for years.

To be clear, extensions weren't a part of the 2.0 API, they were a part
of the infrastructure. It's a subtle but different point. Nova still
supports the 2.0 API, but on different infrastructure, which
doesn't/won't support extensions.

Are people registering new Kilo (or earlier) clouds in the system today?
By the time folks get to Newton, none of that is going to work anyway in
code.

In an ideal world product teams would be close enough to upstream code
and changes to see all this coming and be on top of it. In the real
world, a lot of these teams are like a year (or more) behind, which
actually makes Defcore with a pass* an ideal alternative communication
channel to express that products are coming up to a cliff, and should
start working on plans now.

> I think that’s part of what makes this issue tricky for a lot of folks.
> 
> [1] http://docs.openstack.org/developer/nova/v2/extensions.html

It's an unfortunate accident of bugs in our publishing system that that
URL still exists. That was deleted in Oct 2015. I'll look at getting it
properly cleaned up.

-Sean

-- 
Sean Dague
http://dague.net

__
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] [release][infra] networking-onos 2.0.0 not on our pypi mirrors

2016-06-15 Thread mohammad shahid

Hi,

Can someone look at this networking-onos 2.0.0 not on our pypi please ?

reference links:
https://launchpad.net/networking-onos
https://pypi.python.org/pypi/networking-onos


Thanks and Regards,
Mohammad Shahid
__
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] NUMA, huge pages, and scheduling

2016-06-15 Thread Paul Michali

Awesome Jay!

Do you think this is something that can be backporting to Liberty w/o other
dependencies? We're running Liberty on our system right now.


On Tue, Jun 14, 2016 at 4:10 PM Jay Pipes  wrote:

> On 06/14/2016 12:30 PM, Paul Michali wrote:
> > Well, looks like we figured out what is going on - maybe folks have some
> > ideas on how we could handle this issue.
> >
> > What I see is that for each VM create (small flavor), 1024 huge pages
> > are used and NUMA node 0 used. It appears that, when there is no longer
> > enough huge pages on that NUMA node, Nova with then schedule to the
> > other NUMA node and use those huge pages.
> >
> > In our case, we happen to have a special container running on the
> > compute nodes, that uses 512 huge pages. As a result, when there are 768
> > huge pages left, Nova thinks there are 1280 pages left and thinks one
> > more VM can be create. It tries, but the create fails.
> >
> > Some questions...
> >
> > 1) Is there some way to "reserve" huge pages in Nova?
>
> Yes. Code merged recently from Sahid does this:
>
> https://review.openstack.org/#/c/277422/
>
> Best,
> -jay
>
> > 2) If the create fails, should Nova try the other NUMA node (or is this
> > because it doesn't know why it failed)?
> > 3) Any ideas on how we can deal with this - without changing Nova?
> >
> > Thanks!
> >
> > PCM
> >
> >
> >
> > On Tue, Jun 14, 2016 at 1:09 PM Paul Michali  > > wrote:
> >
> > Great info Chris and thanks for confirming the assignment of blocks
> > of pages to a numa node.
> >
> > I'm still struggling with why each VM is being assigned to NUMA node
> > 0. Any ideas on where I should look to see why Nova is not using
> > NUMA id 1?
> >
> > Thanks!
> >
> >
> > PCM
> >
> >
> > On Tue, Jun 14, 2016 at 10:29 AM Chris Friesen
> > >
> > wrote:
> >
> > On 06/13/2016 02:17 PM, Paul Michali wrote:
> >  > Hmm... I tried Friday and again today, and I'm not seeing the
> > VMs being evenly
> >  > created on the NUMA nodes. Every Cirros VM is created on
> > nodeid 0.
> >  >
> >  > I have the m1/small flavor (@GB) selected and am using
> > hw:numa_nodes=1 and
> >  > hw:mem_page_size=2048 flavor-key settings. Each VM is
> > consuming 1024 huge pages
> >  > (of size 2MB), but is on nodeid 0 always. Also, it seems that
> > when I reach 1/2
> >  > of the total number of huge pages used, libvirt gives an
> > error saying there is
> >  > not enough memory to create the VM. Is it expected that the
> > huge pages are
> >  > "allocated" to each NUMA node?
> >
> > Yes, any given memory page exists on one NUMA node, and a
> > single-NUMA-node VM
> > will be constrained to a single host NUMA node and will use
> > memory from that
> > host NUMA node.
> >
> > You can see and/or adjust how many hugepages are available on
> > each NUMA node via
> > /sys/devices/system/node/nodeX/hugepages/hugepages-2048kB/*
> > where X is the host
> > NUMA node number.
> >
> > Chris
> >
> >
> >
>  __
> > 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
> >
> >
> >
> >
> __
> > 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] [Octavia] [lbaas] Mid-Cycle proposed for the week of August 22nd

2016-06-15 Thread Nir Magnezi

Hi Michael,

Will there be an option to participate from remote?

Thanks,
Nir

On Fri, Jun 10, 2016 at 1:51 AM, Michael Johnson 
wrote:

> Just a reminder, we have a proposed mid-cycle meeting set for the week
> of August 22nd in San Antonio.
>
> If you would like to attend and have not yet signed up, please add
> your name to the list on our etherpad:
>
> https://etherpad.openstack.org/p/lbaas-octavia-newton-midcycle
>
> Thank you,
> Michael
>
> __
> 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] [murano] Nominating Alexander Tivelkov and Zhu Rong for murano cores

2016-06-15 Thread Ihor Dvoretskyi

+1 for Alexander Tivelkov.

Good effort.

On Wed, Jun 15, 2016 at 1:08 PM, Artem Silenkov 
wrote:

> Hello!
>
> +1
>
> Regards,
> Artem Silenkov
> ---
> paas-team
>
> On Wed, Jun 15, 2016 at 12:56 PM, Dmytro Dovbii 
> wrote:
>
>> +1
>> 15 июня 2016 г. 6:47 пользователь "Yang, Lin A" 
>> написал:
>>
>> +1 both for Alexander Tivelkov and Zhu Rong. Well deserved.
>>>
>>> Regards,
>>> Lin Yang
>>>
>>> On Jun 15, 2016, at 3:17 AM, Kirill Zaitsev 
>>> wrote:
>>>
>>> Hello team, I want to annonce the following changes to murano core team:
>>>
>>> 1) I’d like to nominate Alexander Tivelkov for murano core. He has been
>>> part of the project for a very long time and has contributed to almost
>>> every part of murano. He has been fully committed to murano during mitaka
>>> cycle and continues doing so during newton [1]. His work on the scalable
>>> framework architecture is one of the most notable features scheduled for N
>>> release.
>>>
>>> 2) I’d like to nominate Zhu Rong for murano core. Last time he was
>>> nominated I -1’ed the proposal, because I believed he needed to start
>>> making more substantial contributions. I’m sure that Zhu Rong showed his
>>> commitment [2] to murano project and I’m happy to nominate him myself. His
>>> work on the separating cfapi from murano api and contributions headed at
>>> addressing murano’s technical debt are much appreciated.
>>>
>>> 3) Finally I would like to remove Steve McLellan[3] from murano core
>>> team. Steve has been part of murano from very early stages of it. However
>>> his focus has since shifted and he hasn’t been active in murano during last
>>> couple of cycles. I want to thank Steve for his contributions and express
>>> hope to see him back in the project in future.
>>>
>>>
>>> Murano team, please respond with +1/-1 to the proposed changes.
>>>
>>> [1] http://stackalytics.com/?user_id=ativelkov=marks
>>> [2] http://stackalytics.com/?metric=marks_id=zhu-rong
>>> [3] http://stackalytics.com/?user_id=sjmc7
>>> --
>>> Kirill Zaitsev
>>> Software Engineer
>>> Mirantis, Inc
>>>
>>> __
>>> 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
>
>


-- 
Best regards,

Ihor Dvoretskyi
__
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] Stability and reliability of gate jobs

2016-06-15 Thread Paul Bourke

Hi David,

I agree with this completely. Gates continue to be a problem for Kolla,
reasons why have been discussed in the past but at least for me it's not
clear what the key issues are.

I've added this item to agenda for todays IRC meeting (16:00 UTC -
https://wiki.openstack.org/wiki/Meetings/Kolla). It may help if before
hand we can brainstorm a list of the most common problems here beforehand.

To kick things off, rabbitmq seems to cause a disproportionate amount of
issues, and the problems are difficult to diagnose, particularly when
the only way to debug is to summit "DO NOT MERGE" patch sets over and
over. Here's an example of a failed centos binary gate from a simple
patch set I was reviewing this morning:
http://logs.openstack.org/06/329506/1/check/gate-kolla-dsvm-deploy-centos-binary/3486d03/console.html#_2016-06-14_15_36_19_425413

Cheers,
-Paul

On 15/06/16 04:26, David Moreau Simard wrote:

Hi Kolla o/

I'm writing to you because I'm concerned.

In case you didn't already know, the RDO community collaborates with
upstream deployment and installation projects to test it's packaging.

This relationship is beneficial in a lot of ways for both parties, in summary:
- RDO has improved test coverage (because it's otherwise hard to test
different ways of installing, configuring and deploying OpenStack by
ourselves)
- The RDO community works with upstream projects (deployment or core
projects) to fix issues that we find
- In return, the collaborating deployment project can feel more
confident that the RDO packages it consumes have already been tested
using it's platform and should work

To make a long story short, we do this with a project called WeIRDO
[1] which essentially runs gate jobs outside of the gate.

I tried to get Kolla in our testing pipeline during the Mitaka cycle.
I really did.
I contributed the necessary features I needed in Kolla in order to
make this work, like the configurable Yum repositories for example.

However, in the end, I had to put off the initiative because the gate
jobs were very flappy and unreliable.
We cannot afford to have a job that is *expected* to flap in our
testing pipeline, it leads to a lot of wasted time, effort and
resources.

I think there's been a lot of improvements since my last attempt but
to get a sample of data, I looked at ~30 recently merged reviews.
Of 260 total build/deploy jobs, 55 (or over 20%) failed -- and I
didn't account for rechecks, just the last known status of the check
jobs.
I put up the results of those jobs here [2].

In the case that interests me most, CentOS binary jobs, it's 5
failures out of 50 jobs, so 10%. Not as bad but still a concern for
me.

Other deployment projects like Puppet-OpenStack, OpenStack Ansible,
Packstack and TripleO have quite a bit of *voting* integration testing
jobs.
Why are Kolla's jobs non-voting and so unreliable ?

Thanks,

[1]: https://github.com/rdo-infra/weirdo
[2]:
https://docs.google.com/spreadsheets/d/1NYyMIDaUnlOD2wWuioAEOhjeVmZe7Q8_zdFfuLjquG4/edit#gid=0

David Moreau Simard
Senior Software Engineer | Openstack RDO

dmsimard = [irc, github, twitter]

Re: [openstack-dev] [nova] Virtuozzo (Compute) CI is incorrectly patching for resize support

2016-06-15 Thread Evgeny Antyshev


Hello, Matt!

First of all, I want to apologize for the inconvenience.
This all started yesterday when I updated Virtuozzo CI using latest 
puppets, Zuul, Jenkins and other stuff.
The update somehow led to Zuul not passing environment variables like 
ZUUL_CHANGE, LOG_PATH to Jenkins job.
Therefore, devstack-gate didn't apply the change 282580 which triggered 
the test (usually it does).


I'm still investigating this issue with Zuul-Jenkins interaction.

Please, also see inline comments:

On 06/15/2016 12:51 AM, Matt Riedemann wrote:
It was pointed out today in IRC that the Virtuozzo CI has been failing 
on this change for the libvirt imagebackend refactor:


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

Diana was having a hard time sorting out the line numbers in the stack 
trace though from the logs, because they didn't exist in her series.


Long story short, that's because the job checks to see if the change 
is the change that adds resize support for virtuozzo:


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

And if not, it fetches that change:

23:48:46 2016-06-10 23:48:58.863 | + cd /opt/stack/new/nova
23:48:46 2016-06-10 23:48:58.872 | + [[ 282580 -ne 182257 ]]
23:48:46 2016-06-10 23:48:58.875 | + git fetch 
https://review.openstack.org/p/openstack/nova refs/changes/57/182257/37
23:48:59 2016-06-10 23:49:11.357 | From 
https://review.openstack.org/p/openstack/nova
23:48:59 2016-06-10 23:49:11.359 |  * branch refs/changes/57/182257/37 
-> FETCH_HEAD

23:48:59 2016-06-10 23:49:11.366 | + git cherry-pick FETCH_HEAD
23:48:59 2016-06-10 23:49:11.689 | [detached HEAD 44b6772] libvirt: 
virtuozzo instance resize support


It's not valid to patch Nova for your CI when testing other changes, 
it breaks the whole point of CI testing if you have to patch things in 
it that aren't in the actual dependency change or repo - because when 
it fails, like in this case, one doesn't know if it's their actual 
change that's broken or the patch in the CI job.
Well, this methodology is explained in 
https://wiki.openstack.org/wiki/Cinder/tested-3rdParty-drivers
("How do I run my CI to test all cinder patches with my driver not yet 
merged?")

I hoped the same approach is valid for Nova.

The change 182257 is critical for our functionality, but is not merged yet.
Should we test other patches assuming our change got merged, or not is a 
policy question,

and it is obvious that in Cinder this is regarded as normal.



I'm assuming this was done because I asked for the Virtuozzo CI to run 
the resize tests in tempest against 
https://review.openstack.org/#/c/182257/ - which it is, but that 
didn't mean also do it for all other changes in Nova. The CI job 
should conditionally enable those tests when testing change 182257 but 
not anything else until that's merged.

If you confirm this, I'll do as you explained above.


As a side note, the job isn't fetching the latest patch set of the 
resize change anyway, at least not as of last week, it's fetching 
patch set 37 but 39 is the latest.
Well, fixing this was a part of an update procedure which led to such 
dramatic consequences.


Anyway, this isn't meant to shame, but to inform and correct. No one 
from the Virtuozzo team was in the nova IRC channel when we discovered 
this, so I needed to get it into the dev list.


But please get this fixed ASAP since it's invalidating the Virtuozzo 
CI results.





__
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] Require a level playing field for OpenStack projects

2016-06-15 Thread Neil Jerram

On Wed, Jun 15, 2016 at 9:52 AM Thierry Carrez 
wrote:

> [...]
> Those are good points. Note that I do not advocate for those projects to
> be kept closed/private: I'm simply saying that those (open source)
> projects should not be blessed as "official" and be put under the
> Technical Committee oversight. They can still exist in the OpenStack
> ecosystem, be developed using Gerrit and an openstack/* git repository,
> be plugged into the gate... but as an unofficial project.
>

Could you point me to where it's described how to create and operate an
unofficial project like that?  (Or are you talking about a possible future
arrangement that doesn't already exist?)

Thanks,
Neil
__
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] [murano] Nominating Alexander Tivelkov and Zhu Rong for murano cores

2016-06-15 Thread Artem Silenkov

Hello!

+1

Regards,
Artem Silenkov
---
paas-team

On Wed, Jun 15, 2016 at 12:56 PM, Dmytro Dovbii 
wrote:

> +1
> 15 июня 2016 г. 6:47 пользователь "Yang, Lin A" 
> написал:
>
> +1 both for Alexander Tivelkov and Zhu Rong. Well deserved.
>>
>> Regards,
>> Lin Yang
>>
>> On Jun 15, 2016, at 3:17 AM, Kirill Zaitsev 
>> wrote:
>>
>> Hello team, I want to annonce the following changes to murano core team:
>>
>> 1) I’d like to nominate Alexander Tivelkov for murano core. He has been
>> part of the project for a very long time and has contributed to almost
>> every part of murano. He has been fully committed to murano during mitaka
>> cycle and continues doing so during newton [1]. His work on the scalable
>> framework architecture is one of the most notable features scheduled for N
>> release.
>>
>> 2) I’d like to nominate Zhu Rong for murano core. Last time he was
>> nominated I -1’ed the proposal, because I believed he needed to start
>> making more substantial contributions. I’m sure that Zhu Rong showed his
>> commitment [2] to murano project and I’m happy to nominate him myself. His
>> work on the separating cfapi from murano api and contributions headed at
>> addressing murano’s technical debt are much appreciated.
>>
>> 3) Finally I would like to remove Steve McLellan[3] from murano core
>> team. Steve has been part of murano from very early stages of it. However
>> his focus has since shifted and he hasn’t been active in murano during last
>> couple of cycles. I want to thank Steve for his contributions and express
>> hope to see him back in the project in future.
>>
>>
>> Murano team, please respond with +1/-1 to the proposed changes.
>>
>> [1] http://stackalytics.com/?user_id=ativelkov=marks
>> [2] http://stackalytics.com/?metric=marks_id=zhu-rong
>> [3] http://stackalytics.com/?user_id=sjmc7
>> --
>> Kirill Zaitsev
>> Software Engineer
>> Mirantis, Inc
>> __
>> 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] [murano] Nominating Alexander Tivelkov and Zhu Rong for murano cores

2016-06-15 Thread Dmytro Dovbii

+1
15 июня 2016 г. 6:47 пользователь "Yang, Lin A" 
написал:

> +1 both for Alexander Tivelkov and Zhu Rong. Well deserved.
>
> Regards,
> Lin Yang
>
> On Jun 15, 2016, at 3:17 AM, Kirill Zaitsev  wrote:
>
> Hello team, I want to annonce the following changes to murano core team:
>
> 1) I’d like to nominate Alexander Tivelkov for murano core. He has been
> part of the project for a very long time and has contributed to almost
> every part of murano. He has been fully committed to murano during mitaka
> cycle and continues doing so during newton [1]. His work on the scalable
> framework architecture is one of the most notable features scheduled for N
> release.
>
> 2) I’d like to nominate Zhu Rong for murano core. Last time he was
> nominated I -1’ed the proposal, because I believed he needed to start
> making more substantial contributions. I’m sure that Zhu Rong showed his
> commitment [2] to murano project and I’m happy to nominate him myself. His
> work on the separating cfapi from murano api and contributions headed at
> addressing murano’s technical debt are much appreciated.
>
> 3) Finally I would like to remove Steve McLellan[3] from murano core team.
> Steve has been part of murano from very early stages of it. However his
> focus has since shifted and he hasn’t been active in murano during last
> couple of cycles. I want to thank Steve for his contributions and express
> hope to see him back in the project in future.
>
>
> Murano team, please respond with +1/-1 to the proposed changes.
>
> [1] http://stackalytics.com/?user_id=ativelkov=marks
> [2] http://stackalytics.com/?metric=marks_id=zhu-rong
> [3] http://stackalytics.com/?user_id=sjmc7
> --
> Kirill Zaitsev
> Software Engineer
> Mirantis, Inc
> __
> 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-dev] [neutron][qos] Egress minimum bandwidth assurance

2016-06-15 Thread Alonso Hernandez, Rodolfo

Hello:

Context: try to develop a driver for this feature in OVS.

During the last week I’ve been testing several scenarios to make a POC of this 
feature.

Scenario 1:
3 VM connected to br-int, sending traffic through br-physical to other host (an 
external physical machine).
The first VM will have a min BW of 15 Mb. The physical port will be limited to 
20 Mb, so for VM2 and VM3 should be only 5 Mb of available BW.
Those three VM are using iperf to inject traffic against the external host.

A) One qos policy and queue is created at VM1 port (with 
other_config:{min-rate=1500}). The traffic is not shapped.
B) Another qos policy and queue with this minimum BW is created at 
int-phy-patchport. The traffic is not shapped.
C) Another qos policy and queue with this minimum BW is created at 
phy-int-phy-patchport. The traffic is not shapped.
D) Another qos policy and queue with this minimum BW is created at physical 
port. The traffic is still not shapped.
In OVS all traffic from VM1 is filtered to match the correct qos and queues at 
the ports.

Scenario 2:
Similar to scenario 1, but using a fourth VM to act as server. In this case, 
traffic only goes through br-int.
A) One qos policy and queue is created at VM1 port (with 
other_config:{min-rate=1500}). The traffic is not shapped.
B) Another qos policy and queue with this minimum BW is created at output port 
(VM4 server port). The traffic is still not shapped.

I need some help with this implementation, because I’m running out of time an 
ideas!

Thank you in advance.
__
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] Virtuozzo (Compute) CI is incorrectly patching for resize support

2016-06-15 Thread Maxim Nestratov


15.06.2016 0:51, Matt Riedemann пишет:

It was pointed out today in IRC that the Virtuozzo CI has been failing 
on this change for the libvirt imagebackend refactor:


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

Diana was having a hard time sorting out the line numbers in the stack 
trace though from the logs, because they didn't exist in her series.


Long story short, that's because the job checks to see if the change 
is the change that adds resize support for virtuozzo:


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

And if not, it fetches that change:

23:48:46 2016-06-10 23:48:58.863 | + cd /opt/stack/new/nova
23:48:46 2016-06-10 23:48:58.872 | + [[ 282580 -ne 182257 ]]
23:48:46 2016-06-10 23:48:58.875 | + git fetch 
https://review.openstack.org/p/openstack/nova refs/changes/57/182257/37
23:48:59 2016-06-10 23:49:11.357 | From 
https://review.openstack.org/p/openstack/nova
23:48:59 2016-06-10 23:49:11.359 |  * branch refs/changes/57/182257/37 
-> FETCH_HEAD

23:48:59 2016-06-10 23:49:11.366 | + git cherry-pick FETCH_HEAD
23:48:59 2016-06-10 23:49:11.689 | [detached HEAD 44b6772] libvirt: 
virtuozzo instance resize support


It's not valid to patch Nova for your CI when testing other changes, 
it breaks the whole point of CI testing if you have to patch things in 
it that aren't in the actual dependency change or repo - because when 
it fails, like in this case, one doesn't know if it's their actual 
change that's broken or the patch in the CI job.


I'm assuming this was done because I asked for the Virtuozzo CI to run 
the resize tests in tempest against 
https://review.openstack.org/#/c/182257/ - which it is, but that 
didn't mean also do it for all other changes in Nova. The CI job 
should conditionally enable those tests when testing change 182257 but 
not anything else until that's merged.


As a side note, the job isn't fetching the latest patch set of the 
resize change anyway, at least not as of last week, it's fetching 
patch set 37 but 39 is the latest.


Anyway, this isn't meant to shame, but to inform and correct. No one 
from the Virtuozzo team was in the nova IRC channel when we discovered 
this, so I needed to get it into the dev list.


But please get this fixed ASAP since it's invalidating the Virtuozzo 
CI results.




Hi Matt,

I just want to inform you and all involved and/or affected that we are 
fixing the issue. Sorry for inconvenience.

I'll update you as soon as we resolve this problem.

Maxim



__
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] [tempest][nova][defcore] Add option to disable some strict response checking for interop testing


Sean Dague wrote:

On 06/14/2016 07:28 PM, Monty Taylor wrote:

On 06/14/2016 05:42 PM, Doug Hellmann wrote:



I think this is the most important thing to me as it relates to this.
I'm obviously a huge proponent of clouds behaving more samely. But I
also think that, as Doug nicely describes above, we've sort of backed in
to removing something without a deprecation window ... largely because
of the complexities involved with the system here - and I'd like to make
sure that when we are being clear about behavior changes that we give
the warning period so that people can adapt.


I also think that "pass" to "pass *"  is useful social incentive. While
I think communication of this new direction has happened pretty broadly,
organizations are complex places, and it didn't filter everywhere it
needed to with the urgency that was probably needed.

"pass *"  * - with a greylist which goes away in 6 months

Will hopefully be a reasonable enough push to get the behavior we want,
which is everyone publishing the same interface.


I like Chris's suggestion of requiring vendors to submit the grey-list 
of APIs with additional response data, and publish that *very visibly* 
on their marketplace entry. That will immediately make it very clear how 
they are different, provide a strong social incentive to fix it in a 
reasonable timeframe, while stating as a community that such deviation 
is not acceptable long-term.


We agree on the end goal: we just have to choose between "pass fail 
pass" and "pass pass* pass" as a way to achieve it. I feel like the 
latter is a shorter path to the desired goal, and reduces the 
possibility of a "pass fail f*k-this-shit" rage outcome.


--
Thierry Carrez (ttx)

__
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] Require a level playing field for OpenStack projects


Doug Hellmann wrote:

From our perspective, we (designate) currently have a few drivers from
proprietary vendors, and would like to add one in the near future.

The current drivers are marked as "release compatible" - aka someone is
nominated to test the driver throughout the release cycle, and then
during the RC fully validate the driver.

The new driver will have 3rd party CI, to test it on every commit.

These are (very) small parts of the code base, but part of it none
the less. If this is passes, should we push these plugins to separate
repos, and not include them as part of the Designate project?


No. What you're doing is perfectly acceptable. Obviously the more
testing you can do, the better, but it's up to the Designate team to
decide what code contributions it considers it can support as part of
it's official code base. Whether that is organized in one repository or
many is also up to the owners of the code.

The problem has come up because other teams have decided they cannot
manage the large number of disparate drivers. Those have been moved
out of the main source tree, and those repositories are now being
de-listed from the "official" list in the governance repo.


Right, as Doug says, I don't expect Designate to have to change anything 
if this passes. As long as you accept considering new drivers, I would 
consider that a level playing field (same as the Cinder case I mentioned 
in my original post).


--
Thierry Carrez (ttx)

__
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] [qa] Tempest pre-provisioned credentials in the gate

2016-06-15 Thread Jordan Pittier

On Wed, Jun 15, 2016 at 2:00 AM, Andrea Frittoli 
wrote:

> Dear all,
>
> TL;DR: I'd like to propose to start running some of the existing dsvm
> check/gate jobs using Tempest pre-provisioned credentials.
>
> Full Text:
> Tempest provides tests with two mechanisms to acquire test credentials
> [0]: dynamic credentials and pre-provisioned ones.
>
> The current check and gate jobs only use the dynamic credentials provider.
>
> The pre-provisioned credentials provider has been introduced to support
> running test in parallel without the need of having access to admin
> credentials in tempest configuration file - which is a valid use case
> especially when testing public clouds or in general a deployment that is
> not own by who runs the test.
>
> As a small extra, since pre-provisioned credentials are re-used to run
> many tests during a CI test run, they give an opportunity to discover
> issues related to cleanup of test resources.
>
> Pre-provisioned credentials is currently used in periodic jobs [1][2] - as
> well as an experimental job defined for tempest changes. This means that
> even if we are careful, there is a good chance for it to be inadvertently
> broken by a change.
>
> Until recently the periodic job suffered a racy failure on object-storage
> tests. A recent refactor [3] of the tool that pre-proprovisioned the
> accounts has fixed the issue: the past 8 runs of the periodic jobs have not
> encountered that race anymore [4][5].
>
> Specifically I'd like to propose changing to start changing of the neutron
> jobs [6].
>
> Andrea Frittoli
>
> [0]
> http://docs.openstack.org/developer/tempest/configuration.html#credential-provider-mechanisms
> [1]
> http://git.openstack.org/cgit/openstack-infra/project-config/tree/jenkins/jobs/devstack-gate.yaml#n220
> [2]
> http://git.openstack.org/cgit/openstack-infra/project-config/tree/jenkins/jobs/devstack-gate.yaml#n253
> [3] https://review.openstack.org/#/c/317105/
> [4]
> http://status.openstack.org/openstack-health/#/job/periodic-tempest-dsvm-full-test-accounts-master
> [5]
> http://status.openstack.org/openstack-health/#/job/periodic-tempest-dsvm-neutron-full-test-accounts-master
> [6] https://review.openstack.org/329723
>
>
I like the idea. If the jobs with the preprov credentials are as stable as
the ones running dynamic credentials, that's fine. Also I like that we
don"t introduce new jobs but instead changing the configuration of existing
jobs: we already have a lot of jobs in Tempest.

In my previous job, we also used Tempest to validate our cloud deployment
and we didn"t have the admin credentials, so yeah, preprov credentials are
useful.

-- 
 
__
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] Require a level playing field for OpenStack projects