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) 
mailto:openstack-dev@lists.openstack.org>>
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&user_id=kanagaraj-manickam&metric=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) 
mailto:openstack-dev@lists.openstack.org>>
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&release=all&metric=commits&user_id=bharath-ves&module=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&metric=marks&release=all&module=tacker-group&user_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=liberty&user_id=sseetha&project_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 mailto:erik@ericsson.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: fredag 8 maj 2015 06:29
To: "OpenStack Development Mailing List (not for usage questions)" 
mailto: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.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]

Thanks Salvatore. We will try to rebase the patches with master in our 
environment before running devstack.

From: Salvatore Orlando [mailto:sorla...@nicira.com]
Sent: Tuesday, August 26, 2014 3:53 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron] [third-party] What tests are required to 
be run

Hi Karthik,

what do you mean that the plugin is incompatible with 
https://review.openstack.org/#/c/114393/?
you're mentioning a rebase issue - but the patch in question appears to cleanly 
apply to master.

Is your probably because patch #114393 does not have in its log some changes 
you need to accommodate test_lib changes?
Are these changes you need already merged? In this case you might try to rebase 
the patch you're going to test on master before running devstack, which I think 
it's also what happens in the upstream gate.

Salvatore


On 26 August 2014 21:57, Karthik Natarajan 
mailto:natar...@brocade.com>> wrote:
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<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<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" 
mailto: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)
>mailto: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<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)
>> mailto: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
>>

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

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