date:20160614

Re: [openstack-dev] [nova] Austin summit priorities session recap

2016-06-14 Thread Bias, Randy

We understand.  We¹re willing, ready, and able to assist with all of the
upstream items that need to happen in order to get our submission in and
more.  We just need to know so we can help.

Best,

‹Randy

On 6/8/16, 6:09 PM, "Matt Riedemann"  wrote:

>That blueprint is high priority for a single vendor but low
>priority when compared to the very large backlog of items that Nova has
>for the release as a whole.
>

__
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-14 Thread Na Zhu

Ryan,

Thanks your really helpful comments.
If the lswitch is determined by flow classifier, I think no need to record 
in logical router, ovn creates patch port pair for router interface, one 
patch port connects logical switch, the other connects logical router. The 
one connects logical switch is neutron router interface. We still can 
record port chain on logical switch for the logical-source-port is router 
interface, right?



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:   Ryan Moats/Omaha/IBM
To: John McDowall 
Cc: Na Zhu , Srilatha Tangirala/San 
Francisco/IBM@IBMUS, "OpenStack Development Mailing List \(not for usage 
questions\)" , discuss 

Date:   2016/06/15 12:42
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...


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

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

[openstack-dev] [tempest] the project specific config option not generated together with tempest.conf.sample

2016-06-14 Thread joehuang

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 ? 

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

Thanks in advance.

Best Regards
Chaoyi Huang ( Joe Huang )

__
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-14 Thread Ryan Moats

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


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

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

2016-06-14 Thread Mark Voelker

On Jun 14, 2016, at 7:28 PM, Monty Taylor  wrote:
> 
> On 06/14/2016 05:42 PM, 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 backwards compatibility policies.
>>> 
>>> I don't think backwards compatibility policies really apply to what what 
>>> define
>>> as the set of tests that as a community we are saying a vendor has to pass 
>>> to
>>> say they're OpenStack. From my perspective as a community we either take a 
>>> hard
>>> stance on this and say to be considered an interoperable cloud (and to get 
>>> the
>>> trademark) you have to actually have an interoperable product. We slowly 
>>> ratchet
>>> up the requirements every 6 months, there isn't any implied backwards
>>> compatibility in doing that. You passed in the past but not in the newer 
>>> stricter
>>> guidelines.
>>> 
>>> Also, even if I did think it applied, we're not talking about a change which
>>> would fall into breaking that. The change was introduced a year and half ago
>>> during kilo and landed a year ago during

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

2016-06-14 Thread SULLIVAN, BRYAN L

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

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

2016-06-14 Thread Na Zhu

John,

Here is the steps to configure sfc,
1, create flow-classifer
2, create port-pairs
3, create port-pair-group with port-pairs
4, create port-chain with flow-classifer and port-pair-groups

You can see that the port-chain is not related to network, my question is 
how to get the lswitch for networking-sfc and write it to database? 



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 11:31
Subject:Re: [openstack-dev] [ovs-discuss] [OVN] [networking-ovn] 
[networking-sfc] SFC andOVN



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 

Regards

John

Sent from my iPhone

On Jun 14, 2016, at 8:09 PM, Na Zhu  wrote:

Hi John,

Another question, I think port-chain is irrelevant with lswitch, one 
port-chain includes multiple port-pair-groups and one flow-classifier, how 
to get the lswitch by port-chain?




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 11:04
Subject:Re: [openstack-dev] [ovs-discuss] [OVN] [networking-ovn] 
[networking-sfc] SFC andOVN



The reason I did that was to be able to create reusable VNF's

Regards

John

Sent from my iPhone

On Jun 14, 2016, at 7:15 PM, Na Zhu  wrote:

John,

Since you have port-chain as child of lswitch, do you need port-pairs as 
child of lswitch any more?





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
To:John McDowall 
Cc:discuss , "OpenStack Development 
Mailing List (not for usage questions)" , "Srilatha Tangirala" 
Date:2016/06/15 09:11
Subject:Re: [openstack-dev] [ovs-discuss] [OVN] [networking-ovn] 
[networking-sfc] SFC andOVN


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

Re: [openstack-dev] [murano] Nominating Alexander Tivelkov and Zhu Rong for murano cores

2016-06-14 Thread 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-dev] [kolla] Stability and reliability of gate jobs

2016-06-14 Thread David Moreau Simard

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]

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

1 2 >

1 - 100 of 152 matches

Mail list logo