Re: [openstack-dev] [tacker] Proposing Kanagaraj Manickam to Tacker core team

[Karthik Natarajan]

+1. Thanks Kanagaraj for making such a great impact during the Newton cycle.

From: Sripriya Seetharam [mailto:ssee...@brocade.com]
Sent: Thursday, June 16, 2016 10:35 AM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: Re: [openstack-dev] [tacker] Proposing Kanagaraj Manickam to Tacker 
core team

+1


-Sripriya


From: Sridhar Ramaswamy [mailto:sric...@gmail.com]
Sent: Wednesday, June 15, 2016 6:32 PM
To: OpenStack Development Mailing List (not for usage questions) 
>
Subject: [openstack-dev] [tacker] Proposing Kanagaraj Manickam to Tacker core 
team

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] [tacker] Proposing Bharath Thiruveedula to Tacker core team

[Karthik Natarajan]

+1. Thanks for your awesome contributions Bharath !

From: Sripriya Seetharam [mailto:ssee...@brocade.com]
Sent: Friday, June 03, 2016 6:39 PM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: Re: [openstack-dev] [tacker] Proposing Bharath Thiruveedula to Tacker 
core team

+1. Welcome onboard Bharath!

-Sripriya

From: Sridhar Ramaswamy [mailto:sric...@gmail.com]
Sent: Friday, June 03, 2016 6:21 PM
To: OpenStack Development Mailing List (not for usage questions) 
>
Subject: [openstack-dev] [tacker] Proposing Bharath Thiruveedula to Tacker core 
team

Tackers,

I'm happy to propose Bharath Thiruveedula (IRC: tbh) to join the tacker core 
team. Bharath has been contributing to Tacker from the Liberty cycle, and he 
has grown into a key member of this project. His contribution has steadily 
increased as he picked up bigger pieces to deliver [1]. Specifically, he 
contributed the automatic resource creation blueprint [2] in the Mitaka 
release. Plus tons of other RFEs and bug fixes [3]. Bharath is also a key 
contributor in tosca-parser and heat-translator projects which is an added plus.

Please provide your +1/-1 votes.

Thanks Bharath for your contributions so far and much more to come !!

[1] 
http://stackalytics.com/?project_type=openstack=all=commits_id=bharath-ves=tacker-group
[2] 
https://blueprints.launchpad.net/tacker/+spec/automatic-resource-creation
[3] 
https://bugs.launchpad.net/bugs/+bugs?field.assignee=bharath-ves
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tacker] Proposing Lin Cheng for tacker-horizon core team

[Karthik Natarajan]

+1

From: Sridhar Ramaswamy [mailto:sric...@gmail.com]
Sent: Thursday, May 26, 2016 10:45 AM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: [openstack-dev] [tacker] Proposing Lin Cheng for tacker-horizon core 
team

Tackers,

I'd like to propose Lin Cheng to join as a tacker-horizon core team member. Lin 
has been our go-to person for all guidance related to UI enhancements for 
Tacker. He has been actively reviewing patchsets in this area [1] and also 
contributed to setup the unit test framework for tacker-horizon repo.

Please provide your +1/-1 votes.

- Sridhar

[1] 
http://stackalytics.com/?project_type=all=marks=all=tacker-group_id=lin-hua-cheng
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tacker] Proposing Sripriya Seetharam to Tacker core

[Karthik Natarajan]

+1

From: Sridhar Ramaswamy [mailto:sric...@gmail.com]
Sent: Monday, November 09, 2015 6:22 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [tacker] Proposing Sripriya Seetharam to Tacker core

I'd like to propose Sripriya Seetharam to join the Tacker core team. Sripriya
ramped up quickly in early Liberty cycle and had become an expert in the Tacker
code base. Her major contributions include landing MANO API blueprint,
introducing unit test framework along with the initial unit-tests and tirelessly
squashing hard to resolve bugs (including chasing the recent nova-neutron goose
hunt). Her reviews are solid fine tooth comb and constructive [1].

I'm glad to welcome Sripriya to the core team. Current cores members, please 
vote
with your +1 / -1.

[1] 
http://stackalytics.com/?release=libertyuser_id=sseethaproject_type=openstack-others
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Tacker] Proposing Bob Haddleton to core team

[Karthik Natarajan]

+1

From: Sridhar Ramaswamy [mailto:sric...@gmail.com]
Sent: Thursday, October 15, 2015 8:47 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [Tacker] Proposing Bob Haddleton to core team

I would like to nominate Bob Haddleton to the Tacker core team.

In the current Liberty cycle Bob made significant, across the board 
contributions to Tacker [1]. Starting with many usability enhancements and 
squashing bugs Bob has shown commitment and consistently produced high quality 
code. To cap he recently landed Tacker's health monitoring framework to enable 
loadable VNF monitoring. His knowledge in NFV area is a huge plus for Tacker as 
we embark onto even greater challenges in the Mitaka cycle.

Along the lines, we are actively looking to expand Tacker's core reviewer team. 
If you are interested in the NFV Orchestration / VNF Manager space please stop 
by and explore Tacker project [2].

Tacker team,

Please provide your -1 / +1 votes.

- Sridhar

[1] http://stackalytics.com/report/users/bob-haddleton
[2] https://wiki.openstack.org/wiki/Tacker
__
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]Anyone looking at support for VLAN-aware VMs in Liberty?

[Karthik Natarajan]

Hi Eric,

Brocade is also interested in the VLAN aware VM's BP. Let's discuss it during 
the design summit.

Thanks,
Karthik

From: Bob Melander (bmelande) [mailto:bmela...@cisco.com]
Sent: Monday, May 11, 2015 9:51 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron]Anyone looking at support for VLAN-aware 
VMs in Liberty?

Hi Eric,

Cisco is also interested in the kind of VLAN trunking feature that your 
VLAN-aware VM's BP describe. If this could be achieved in Liberty it'd be great.
Perhaps your BP could be brought up during one of the Neutron sessions in 
Vancouver, e.g., the one on OVN since there seems to be some similarities?

Thanks
Bob


From: Erik Moe erik@ericsson.commailto:erik@ericsson.com
Reply-To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: fredag 8 maj 2015 06:29
To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [neutron]Anyone looking at support for VLAN-aware 
VMs in Liberty?


Hi,

I have not been able to work with upstreaming of this for some time now. But 
now it looks like I may make another attempt. Who else is interested in this, 
as a user or to help contributing? If we get some traction we can have an IRC 
meeting sometime next week.

Thanks,
Erik


From: Scott Drennan [mailto:sco...@nuagenetworks.net]
Sent: den 4 maj 2015 18:42
To: openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: [openstack-dev] [neutron]Anyone looking at support for VLAN-aware VMs 
in Liberty?

VLAN-transparent or VLAN-trunking networks have landed in Kilo, but I don't see 
any work on VLAN-aware VMs for Liberty.  There is a blueprint[1] and specs[2] 
which was deferred from Kilo - is this something anyone is looking at as a 
Liberty candidate?  I looked but didn't find any recent work - is there 
somewhere else work on this is happening?  No-one has listed it on the liberty 
summit topics[3] etherpad, which could mean it's uncontroversial, but given 
history on this, I think that's unlikely.

cheers,
Scott

[1]: https://blueprints.launchpad.net/neutron/+spec/vlan-aware-vms
[2]: https://review.openstack.org/#/c/94612
[3]: https://etherpad.openstack.org/p/liberty-neutron-summit-topics
__
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] [third-party] What tests are required to be run

[Karthik Natarajan]

Hi Edgar,

We are also facing CI issues when the neutron patch set is not rebased with 
latest changes.
For e.g. CI audit that you posted today 
(https://review.openstack.org/#/c/114393/) is not rebased with neutron test_lib 
related changes.
We had refactored the Brocade Vyatta plugin unit tests to accommodate the 
test_lib related changes.
But our plugin is not compatible with the patch you have posted. So CI is 
failing.

I had a discussion with Dane Leblanc on this. We also need to post the SKIPPED 
status for such patch sets.
We will also experiment with Kevin's suggestion.

Thanks,
Karthik

-Original Message-
From: Dane Leblanc (leblancd) [mailto:lebla...@cisco.com]
Sent: Monday, August 25, 2014 10:02 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron] [third-party] What tests are required to 
be run

Edgar, Kyle:

Kevin's suggestion should work for me (still hashing out the implementation).  
I've added an item to the 3rd Party IRC agenda anyway to discuss this corner 
case.

Thanks!
Dane

-Original Message-
From: Edgar Magana [mailto:edgar.mag...@workday.com]
Sent: Monday, August 25, 2014 12:44 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron] [third-party] What tests are required to 
be run

Dane,

I will second Kyle's idea. Let's discuss this during today IRC meeting if 
Kevin's suggestion does not work for you.

Thanks,

Edgar

On 8/25/14, 10:08 AM, Kyle Mestery mest...@mestery.com wrote:

Dane, thanks for all the great work you're doing in the third-party CI
area. It's great to see you working to share this knowledge with others
as well!

Did Kevin's idea work for you to move past this issue? If not, I
suggest you put an item on the neutron meeting agenda today and we
cover this there. You could put the item on the third-party meeting
agenda as well.

Thanks!
Kyle

On Sun, Aug 24, 2014 at 9:43 AM, Dane Leblanc (leblancd)
lebla...@cisco.com wrote:
 Hi Kevin:



 Thanks, this is a great idea! I may try just a slight variation of
this  concept. Maybe your idea could be the recommended way to create
a 3rd party  CI for plugins that are just being introduced and need to
limit the scope of  testing to a small set of plugin-related commits
(or plugins blocked on a  certain fix).



 Thanks,
 Dane



 From: Kevin Benton [mailto:blak...@gmail.com]
 Sent: Saturday, August 23, 2014 5:47 AM


 To: OpenStack Development Mailing List (not for usage questions)
 Subject: Re: [openstack-dev] [neutron] [third-party] What tests are
required  to be run



 Can you disable posting of results directly from your Jenkins/Zuul
setup and  have a script that just checks the log file for special
markers to determine  if the vote should be FAILED/PASSED/SKIPPED?
Another advantage of this  approach is that it gives you an
opportunity to detect when a job just  failed to setup due to
infrastructure reasons and trigger a recheck without  ever first
posting a failure to gerrit.



 On Fri, Aug 22, 2014 at 3:06 PM, Dane Leblanc (leblancd)
 lebla...@cisco.com wrote:

 Thanks Edgar for updating the APIC status!!!

 Edgar and Kyle: *PLEASE NOTE**  I need your understanding
and  advice on the following:

 We are still stuck with a problem stemming from a design limitation
 of Jenkins that prevents us from being compliant with Neutron 3rd
 Party CI requirements for our DFA CI.

 The issue is that Jenkins only allows our scripts to
(programmatically)  return either Success or Fail. There is no option
to return Aborted, Not  Tested, or Skipped.

 Why does this matter? The DFA plugin is just being introduced, and
initial  DFA-enabling change sets have not yet been merged. Therefore,
all other  change sets will fail our Tempest tests, since they are not
DFA-enabled.

 Similarly, we were recently blocked in our APIC CI with a critical
 bug, causing all change sets without this fix to fail on our APIC testbed.

 In these cases, we would like to enter a throttled or partially
blocked
 mode, where we would skip testing on change sets we know will fail,
and (in  an ideal world) signal this shortcoming to Gerrit e.g. by
returning a  Skipped status. Unfortunately, this option is not
available in Jenkins  scripts, as Jenkins is currently designed. The
only options we have  available is Success or all Fail, which are
both misleading. We would  also incorrectly report success or fail on
one of the following test
 commits:
 https://review.openstack.org/#/c/114393/
 https://review.openstack.org/#/c/40296/

 I've brought this issue up on the openstack-infra IRC, and jeblair
confirmed  the Jenkins limitation, but asked me to get consensus from
the Neutron  community as to this being a problem/requirement. I've
also sent out an  e-mail on the Neutron ML trying to start a
discussion on this problem (no  traction). I plan on bringing this up
in the 3rd Party CI IRC on Monday,  assuming there is time permitted
in 

Re: [openstack-dev] [neutron] [third-party] What tests are required to be run

[Karthik Natarajan]

Hi Edgar,

Brocade Vyatta CI is reporting the results and providing log links.
For Brocade Vyatta Plugin, I have updated my name as the owner.
For Brocade VDX Plugin, Shiv Haris is the owner.
Please let me know if you have any questions.

Thanks,
Karthik

-Original Message-
From: Edgar Magana [mailto:edgar.mag...@workday.com] 
Sent: Friday, August 15, 2014 3:59 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron] [third-party] What tests are required to 
be run
Importance: High

Correction

The right links are:

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

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


Not this one:
https://review.openstack.org/#/c/40296/


Edgar

On 8/15/14, 3:35 PM, Edgar Magana edgar.mag...@workday.com wrote:

Team,

I did a quick audit on the Neutron CI. Very sad results. Only few 
plugins and drivers are running properly and testing all Neutron commits.
I created a report here:
https://wiki.openstack.org/wiki/Neutron_Plugins_and_Drivers#Existing_Pl
ugi
n
_and_Drivers


We will discuss the actions to take on the next Neutron IRC meeting. So 
please, reach me out to clarify what is the status of your CI.
I had two commits to quickly verify the CI reliability:

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

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


I would expect all plugins and drivers passing on the first one and 
failing for the second but I got so many surprises.

Neutron code quality and reliability is a top priority, if you ignore 
this report that plugin/driver will be candidate to be remove from 
Neutron tree.

Cheers,

Edgar

P.s. I hate to be the inquisitor hereŠ but someone has to do the dirty 
job!


On 8/14/14, 8:30 AM, Kyle Mestery mest...@mestery.com wrote:

Folks, I'm not sure if all CI accounts are running sufficient tests.
Per the requirements wiki page here [1], everyone needs to be running 
more than just Tempest API tests, which I still see most neutron 
third-party CI setups doing. I'd like to ask everyone who operates a 
third-party CI account for Neutron to please look at the link below 
and make sure you are running appropriate tests. If you have 
questions, the weekly third-party meeting [2] is a great place to ask 
questions.

Thanks,
Kyle

[1] https://wiki.openstack.org/wiki/NeutronThirdPartyTesting
[2] https://wiki.openstack.org/wiki/Meetings/ThirdParty

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev