[openstack-dev] [magnum] Fedora Atomic image that supports kubernetes external load balancer (for stable/mitaka)

[Dane Leblanc (leblancd)]

Does anyone have a pointer to a Fedora Atomic image that works with 
stable/mitaka Magnum, and supports the kubernetes external load balancer 
feature [1]?

I'm trying to test the kubernetes external load balancer feature with 
stable/mitaka Magnum. However, when I try to bring up a load-balanced service, 
I'm seeing these errors in the kube-controller-manager logs:
E0907 16:26:54.375286   1 servicecontroller.go:173] Failed to process 
service delta. Retrying: failed to create external load balancer for service 
default/nginx-service: SubnetID is required

I verified that I have the subnet-id field set in the [LoadBalancer] section in 
/etc/sysconfig/kube_openstack_config.

I've tried this using the following Fedora Atomic images from [2]:
fedora-21-atomic-5.qcow2
fedora-21-atomic-6.qcow2
fedora-atomic-latest.qcow2

According to the Magnum external load balancer blueprint [3], there were 3 
patches in kubernetes that are required to get the OpenStack provider plugin to 
work in kubernetes:
https://github.com/GoogleCloudPlatform/kubernetes/pull/12203
https://github.com/GoogleCloudPlatform/kubernetes/pull/12262
https://github.com/GoogleCloudPlatform/kubernetes/pull/12288
The first of these patches, "Pass SubnetID to vips.Create()", is apparently 
necessary to fix the "SubnetID is required" error shown above.

According to the Magnum external load balancer blueprint [3], the 
fedora-21-atomic-6 image should include the above 3 fixes:
"Our work-around is to use our own custom Kubernetes build (version 1.0.4 + 3 
fixes) until the fixes are released. This is in image fedora-21-atomic-6.qcow2"
However, I'm still seeing the "SubnetID is required" errors with this image 
downloaded from [2]. Here are the kube versions I'm seeing with this image:
[minion@k8-64n4bna2v6-0-ffukgho7n7tf-kube-master-fif5b6pivdmy sysconfig]$ rpm 
-qa | grep kube
kubernetes-node-1.2.0-0.15.alpha6.gitf0cd09a.fc23.x86_64
kubernetes-1.2.0-0.15.alpha6.gitf0cd09a.fc23.x86_64
kubernetes-client-1.2.0-0.15.alpha6.gitf0cd09a.fc23.x86_64
kubernetes-master-1.2.0-0.15.alpha6.gitf0cd09a.fc23.x86_64
[minion@k8-64n4bna2v6-0-ffukgho7n7tf-kube-master-fif5b6pivdmy sysconfig]$

Does anyone have a pointer to a Fedora Atomic image that contains the 3 
kubernetes fixes listed earlier (and works with stable/mitaka)?

Thanks!
-Dane

[1] http://kubernetes.io/docs/user-guide/services/#type-loadbalancer
[2] https://fedorapeople.org/groups/magnum/
[3] https://blueprints.launchpad.net/magnum/+spec/external-lb

__
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] [magnum] Notes for Magnum design summit

[Dane Leblanc (leblancd)]

-Original Message-
From: Ricardo Rocha [mailto:rocha.po...@gmail.com] 
Sent: Tuesday, May 03, 2016 8:34 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [magnum] Notes for Magnum design summit

Hi.

On Mon, May 2, 2016 at 7:11 PM, Cammann, Tom  wrote:
> Thanks for the write up Hongbin and thanks to all those who contributed to 
> the design summit. A few comments on the summaries below.
>
> 6. Ironic Integration: 
> https://etherpad.openstack.org/p/newton-magnum-ironic-integration
> - Start the implementation immediately
> - Prefer quick work-around for identified issues (cinder volume 
> attachment, variation of number of ports, etc.)
>
> We need to implement a bay template that can use a flat networking model as 
> this is the only networking model Ironic currently supports. Multi-tenant 
> networking is imminent. This should be done before work on an Ironic template 
> starts.

I think the work on bay templates for multi-tenant networking can start now if 
we cherry pick this patch from Ironic:
https://review.openstack.org/#/c/256367/
and this patch for Ironic python client:
https://review.openstack.org/#/c/206144/
These should have all the dependency patches for supporting Ironic/Neutron-ML2 
integration. (We'd still need to figure out e.g. how to specify which of N nics 
to use, and how to specify/detect LAG groups.) The Ironic support for Cinder 
volumes doesn’t seem as far along, but in the interim we can probably use 
volume drivers such as rexray (don't know if this works for kube).

>
> 7. Magnum adoption challenges: 
> https://etherpad.openstack.org/p/newton-magnum-adoption-challenges
> - The challenges is listed in the etherpad above
>
> Ideally we need to turn this list into a set of actions which we can 
> implement over the cycle, i.e. create a BP to remove requirement for LBaaS.

There's one for floating IPs already:
https://blueprints.launchpad.net/magnum/+spec/bay-with-no-floating-ips

>
> 9. Magnum Heat template version: 
> https://etherpad.openstack.org/p/newton-magnum-heat-template-versionin
> g
> - In each bay driver, version the template and template definition.
> - Bump template version for minor changes, and bump bay driver version for 
> major changes.
>
> We decided only bay driver versioning was required. The template and template 
> driver does not need versioning due to the fact we can get heat to pass back 
> the template which it used to create the bay.

This was also my understanding. We won't use heat template versioning, just the 
bays.

> 10. Monitoring: 
> https://etherpad.openstack.org/p/newton-magnum-monitoring
> - Add support for sending notifications to Ceilometer
> - Revisit bay monitoring and self-healing later
> - Container monitoring should not be done by Magnum, but it can be done by 
> cAdvisor, Heapster, etc.
>
> We split this topic into 3 parts – bay telemetry, bay monitoring, container 
> monitoring.
> Bay telemetry is done around actions such as bay/baymodel CRUD operations. 
> This is implemented using using ceilometer notifications.
> Bay monitoring is around monitoring health of individual nodes in the bay 
> cluster and we decided to postpone work as more investigation is required on 
> what this should look like and what users actually need.
> Container monitoring focuses on what containers are running in the bay and 
> general usage of the bay COE. We decided this will be done completed by 
> Magnum by adding access to cAdvisor/heapster through baking access to 
> cAdvisor by default.

I think we're missing a blueprint for this one too.

Ricardo

>
> - Manually manage bay nodes (instead of being managed by Heat ResourceGroup): 
> It can address the use case of heterogeneity of bay nodes (i.e. different 
> availability zones, flavors), but need to elaborate the details further.
>
> The idea revolves around creating a heat stack for each node in the bay. This 
> idea shows a lot of promise but needs more investigation and isn’t a current 
> priority.
>
> Tom
>
>
> From: Hongbin Lu 
> Reply-To: "OpenStack Development Mailing List (not for usage 
> questions)" 
> Date: Saturday, 30 April 2016 at 05:05
> To: "OpenStack Development Mailing List (not for usage questions)" 
> 
> Subject: [openstack-dev] [magnum] Notes for Magnum design summit
>
> Hi team,
>
> For reference, below is a summary of the discussions/decisions in Austin 
> design summit. Please feel free to point out if anything is incorrect or 
> incomplete. Thanks.
>
> 1. Bay driver: 
> https://etherpad.openstack.org/p/newton-magnum-bay-driver
> - Refactor existing code into bay drivers
> - Each bay driver will be versioned
> - Individual bay driver can have API extension and magnum CLI could 
> load the extensions dynamically
> - Work incrementally and support same API before and after the driver 
> change
>
> 2. Bay 

[openstack-dev] [Magnum] Magnum Quick-Start: Need clarification on Kubernetes/Redis example

[Dane Leblanc (leblancd)]

Does anyone have recent experience getting the Kubernetes/Redis example to work 
in the Magnum developer Quick-Start guide?:

https://github.com/openstack/magnum/blob/master/doc/source/dev/dev-quickstart.rst#exercising-the-services-using-devstack

I can get everything in the Kubernetes/Redis example to work except for the 
last step. Here's what the quick-start guide says for this step:
Now log into one of the other container hosts and access a redis slave from 
there:
ssh minion@$(nova list | grep 10.0.0.4 | awk '{print $13}')
REDIS_ID=$(docker ps | grep redis:v1 | grep k8s_redis | tail -n +2 | awk 
'{print $1}')
docker exec -i -t $REDIS_ID redis-cli

127.0.0.1:6379 get replication:test
true
^D

exit

There are four redis instances, one master and three slaves, running across the 
bay, replicating data between one another.

What I'm seeing is a bit different:

(1)I have to use 'sudo docker' instead of 'docker'.  (No big deal.)

(2)I see one master redis instance on one minion and one slave redis 
instance on a second minion (each has its own associated sentinel container as 
expected).

(3)The redis-cli command times out with Could not connect to Redis at 
127.0.0.1:6379: Connection refused. HOWEVER, if I add a host IP and port for 
the redis master minion (-h 10.100.84.2 -p 6379), the example works.

Here is the failing case, without the host/port arguments:

[minion@k8-4gmqfvntvm-0-6fymzzw3wrjx-kube-minion-zjdejo5sffxv ~]$ 
REDIS_ID=$(sudo docker ps | grep redis:v1 | grep k8s_redis | awk '{print $1}')
[minion@k8-4gmqfvntvm-0-6fymzzw3wrjx-kube-minion-zjdejo5sffxv ~]$ sudo docker 
exec -i -t $REDIS_ID redis-cli
Could not connect to Redis at 127.0.0.1:6379: Connection refused
not connected [minion@k8-4gmqfvntvm-0-6fymzzw3wrjx-kube-minion-zjdejo5sffxv ~]$

And here is the working case, using -h 10.100.84.2 -p 6379:

[minion@k8-4gmqfvntvm-0-6fymzzw3wrjx-kube-minion-zjdejo5sffxv ~]$ 
REDIS_ID=$(sudo docker ps | grep redis:v1 | grep k8s_redis | awk '{print $1}')
[minion@k8-4gmqfvntvm-0-6fymzzw3wrjx-kube-minion-zjdejo5sffxv ~]$ sudo docker 
exec -i -t $REDIS_ID redis-cli -h 10.100.84.2 -p 6379
10.100.84.2:6379 get replication:test
true
10.100.84.2:6379

Note that I determined the '10.100.84.2' address for the redis master by 
running the following on the master minion:

[minion@k8-4gmqfvntvm-1-6pnrx2hnxa3d-kube-minion-bh6nynhayhfy ~]$ sudo docker 
exec -i -t $REDIS_ID ip addr show dev eth0
5: eth0: BROADCAST,UP,LOWER_UP mtu 1472 qdisc noqueue state UP
link/ether 02:42:0a:64:54:02 brd ff:ff:ff:ff:ff:ff
inet 10.100.84.2/24 scope global eth0
   valid_lft forever preferred_lft forever
inet6 fe80::42:aff:fe64:5402/64 scope link
   valid_lft forever preferred_lft forever
[minion@k8-4gmqfvntvm-1-6pnrx2hnxa3d-kube-minion-bh6nynhayhfy ~]$

So I'm looking for confirmation as to whether or not using the -h 10.100.84.2 
-p 6379 arguments is the right way to test this configuration? Is this a 
successful test?

Thanks,
Dane

__
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

[Dane Leblanc (leblancd)]

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 the open discussion.

 I'm also investigating

 For the short term, I would like to propose the following:
 * We bring this up on the 3rd Party CI IRC on Monday to get a 
solution or  workaround, if available. If a solution is available, 
let's consider  including that as a hint when we come up with CI 
requirements for handling  CIs bocked by some critical fix.
 * I'm also looking into using a REST API to cancel a Jenkins job  
programmatically.
 * If no solution or workaround is available, we work with infra team 
or with  Jenkins team to create a solution.
 * Until a solution is available, for plugins which are blocked by a 
critical  bug, we post a status/notes indicating the plugin's 
situation on our 3rd  party CI status wiki, e.g.:

 Vendor  Plugin/Driver Name  Contact Name
 Status  Notes
 My Vendor Name

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

[Dane Leblanc (leblancd)]

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.commailto: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 the open discussion.

I'm also investigating

For the short term, I would like to propose the following:
* We bring this up on the 3rd Party CI IRC on Monday to get a solution or 
workaround, if available. If a solution is available, let's consider including 
that as a hint when we come up with CI requirements for handling CIs bocked by 
some critical fix.
* I'm also looking into using a REST API to cancel a Jenkins job 
programmatically.
* If no solution or workaround is available, we work with infra team or with 
Jenkins team to create a solution.
* Until a solution is available, for plugins which are blocked by a critical 
bug, we post a status/notes indicating the plugin's situation on our 3rd party 
CI status wiki, e.g.:

Vendor  Plugin/Driver Name  Contact NameStatus  
Notes
My Vendor Name  My Plugin CIMy Contact Person   T   
Throttled / Partially blocked / Awaiting Intial Commits

The status/notes should be clear and understood by the Neutron team.  The 
console logs for change sets where the tests were skipped should also contain a 
message that all testing is being skipped for that commit.

Note that when the DFA initial commits are merged, then this issue would go 
away for the DFA CI. However, this problem will reappear every time a blocking 
critical bug shows up for a 3rd party CI setup, or a new plugin is introduced 
and the hardware-enabling commits are not yet merged.  (That is, until we have 
a solution for the Jenkins limitation).

Let me know what you think.

Thanks,
Dane

-Original Message-
From: Edgar Magana 
[mailto:edgar.mag...@workday.commailto:edgar.mag...@workday.com]
Sent: Friday, August 22, 2014 1:57 PM
To: Dane Leblanc (leblancd); OpenStack Development Mailing List (not for usage 
questions)
Subject: Re: [openstack-dev] [neutron] [third-party] What tests are required to 
be run

Sorry my bad but I just changed.

Edgar

On 8/21/14, 2:13 PM, Dane Leblanc (leblancd) 
lebla...@cisco.commailto:lebla...@cisco.com

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

[Dane Leblanc (leblancd)]

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 the open discussion.

I'm also investigating 

For the short term, I would like to propose the following:
* We bring this up on the 3rd Party CI IRC on Monday to get a solution or 
workaround, if available. If a solution is available, let's consider including 
that as a hint when we come up with CI requirements for handling CIs bocked by 
some critical fix.
* I'm also looking into using a REST API to cancel a Jenkins job 
programmatically.
* If no solution or workaround is available, we work with infra team or with 
Jenkins team to create a solution.
* Until a solution is available, for plugins which are blocked by a critical 
bug, we post a status/notes indicating the plugin's situation on our 3rd party 
CI status wiki, e.g.:

Vendor  Plugin/Driver Name  Contact NameStatus  
Notes
My Vendor Name  My Plugin CIMy Contact Person   T   
Throttled / Partially blocked / Awaiting Intial Commits

The status/notes should be clear and understood by the Neutron team.  The 
console logs for change sets where the tests were skipped should also contain a 
message that all testing is being skipped for that commit.

Note that when the DFA initial commits are merged, then this issue would go 
away for the DFA CI. However, this problem will reappear every time a blocking 
critical bug shows up for a 3rd party CI setup, or a new plugin is introduced 
and the hardware-enabling commits are not yet merged.  (That is, until we have 
a solution for the Jenkins limitation).

Let me know what you think.

Thanks,
Dane

-Original Message-
From: Edgar Magana [mailto:edgar.mag...@workday.com] 
Sent: Friday, August 22, 2014 1:57 PM
To: Dane Leblanc (leblancd); OpenStack Development Mailing List (not for usage 
questions)
Subject: Re: [openstack-dev] [neutron] [third-party] What tests are required to 
be run

Sorry my bad but I just changed.

Edgar

On 8/21/14, 2:13 PM, Dane Leblanc (leblancd) lebla...@cisco.com wrote:

Edgar:

I'm still seeing the comment Results are not accurate. Needs 
clarification...

Dane

-Original Message-
From: Edgar Magana [mailto:edgar.mag...@workday.com]
Sent: Thursday, August 21, 2014 2:58 PM
To: Dane Leblanc (leblancd); OpenStack Development Mailing List (not 
for usage questions)
Subject: Re: [openstack-dev] [neutron] [third-party] What tests are 
required to be run

Dane,

Wiki has been updated.

Thanks,

Edgar

On 8/21/14, 7:57 AM, Dane Leblanc (leblancd) lebla...@cisco.com wrote:

Edgar:

The status on the wiki page says Results are not accurate. Needs 
clarification from Cisco.
Can you please tell me what we are missing?

-Dane

-Original Message-
From: Dane Leblanc (leblancd)
Sent: Tuesday, August 19, 2014 3:05 PM
To: 'Edgar Magana'; OpenStack Development Mailing List (not for usage
questions)
Subject: RE: [openstack-dev] [neutron] [third-party] What tests are 
required to be run

The APIC CI did run tests against that commit (after some queue latency):

http://128.107.233.28:8080/job/apic/1860/
http://cisco-neutron-ci.cisco.com/logs/apic/1860/

But the review comments never showed up on Gerrit

Re: [openstack-dev] [Neutron] How to handle blocking bugs/changes in Neutron 3rd party CI

[Dane Leblanc (leblancd)]

That makes sense for setups that don’t use Zuul.

But for setups using Zuul/Jenkins, and for a vendor who is introducing a new 
plugin which has initial hardware-enabling commits which haven’t been merged 
yet, I don’t see how we can meet Neutron 3rd party testing requirements. The 
requirements and the tools just seem to be at odds in this situation.

From: Kevin Benton [mailto:blak...@gmail.com]
Sent: Thursday, August 21, 2014 3:25 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron] How to handle blocking bugs/changes in 
Neutron 3rd party CI

I'm not sure if this is possible with a Zuul setup, but once we identify a 
failure causing commit, we change the reported job status to (skipped) for 
any patches that contain the commit but not the fix. It's a relatively 
straightforward way to communicate that the CI system is still operational but 
voting was intentionally bypassed. This logic is handled in the script that 
determines and posts the results of the tests to gerrit.

On Wed, Aug 20, 2014 at 3:27 PM, Dane Leblanc (leblancd) 
lebla...@cisco.commailto:lebla...@cisco.com wrote:
Preface: I posed this problem on the #openstack-infra IRC, and they couldn't 
offer an easy or obvious solution, and suggested that I get some consensus from 
the Neutron community as to how we want to handle this situation. So I'd like 
to bounce this around, get some ideas, and maybe bring this up in the 3rd party 
CI IRC.

The challenge is this: Occasionally, a blocking bug is introduced which causes 
our 3rd party CI tests to consistently fail on every change set that we're 
testing against. We can develop a fix for the problem, but until that fix gets 
merged upstream, tests against all other change sets are seen to fail.

(Note that we have a similar situation whenever we introduce a completely new 
plugin with its associated 3rd party CI... until the plugin code, or an 
enabling subset of that plugin code is merged upstream, then typically all 
other commits would fail on that CI setup.)

In the past, we've tried dynamically patching the fix(es) on top of the fetched 
code being reviewed, but this isn't always reliable due to merge conflicts, and 
we've had to monkey patch DevStack to apply the fixes after cloning Neutron but 
before installing Neutron.

So we'd prefer to enter a throttled or filtering CI mode when we hit this 
situation, where we're (temporarily) only testing against commits related to 
our plugin/driver which contain (or have a dependency on) the fix for the 
blocking bug until the fix is merged.

In an ideal world, for the sake of transparency, we would love to be able to 
have Jenkins/Zuul report back to Gerrit with a descriptive test result such as 
N/A, Not tested, or even Aborted for all other change sets, letting the 
committer know that, Yeah, we see your review, but we're unable to test it at 
the moment. Zuul does have the ability to report Aborted status to Gerrit, 
but this is sent e.g. when Zuul decides to abort change set 'N' for a review 
when change set 'N+1' has just been submitted, or when a Jenkins admin manually 
aborts a Jenkins job.  Unfortunately, this type of status is not available 
programmatically within a Jenkins job script; the only outcomes are pass (zero 
RC) or fail (non-zero RC). (Note that we can't directly filter at the Zuul 
level in our topology, since we have one Zuul server servicing multiple 3rd 
party CI setups.)

As a second option, we'd like to not run any tests for the other changes, and 
report NOTHING to Gerrit, while continuing to run against changes related to 
our plugin (as required for the plugin changes to be approved).  This was the 
favored approach discussed in the Neutron IRC on Monday. But herein lies the 
rub. By the time our Jenkins job script discovers that the change set that is 
being tested is not in a list of preferred/allowed change sets, the script has 
2 options: pass or fail. With the current Jenkins, there is no programmatic way 
for a Jenkins script to signal to Gearman/Zuul that the job should be aborted.

There was supposedly a bug filed with Jenkins to allow it to interpret 
different exit codes from job scripts as different result values, but this 
hasn't made any progress.

There may be something that can be changed in Zuul to allow it to interpret 
different result codes other than success/fail, or maybe to allow Zuul to do 
change ID filtering on a per Jenkins job basis, but this would require the 
infra team to make changes to Zuul.

The bottom line is that based on the current Zuul/Jenkins infrastructure, 
whenever our 3rd party CI is blocked by a bug, I'm struggling with the 
conflicting requirements:
* Continue testing against change sets for the blocking bug (or plugin related 
changes)
* Don't report anything to Gerrit for all other change sets, since these can't 
be meaningfully tested against the CI hardware

Let me know if I'm missing a solution to this. I

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

[Dane Leblanc (leblancd)]

Edgar:

The status on the wiki page says Results are not accurate. Needs clarification 
from Cisco.
Can you please tell me what we are missing?

-Dane

-Original Message-
From: Dane Leblanc (leblancd) 
Sent: Tuesday, August 19, 2014 3:05 PM
To: 'Edgar Magana'; OpenStack Development Mailing List (not for usage questions)
Subject: RE: [openstack-dev] [neutron] [third-party] What tests are required to 
be run

The APIC CI did run tests against that commit (after some queue latency):

http://128.107.233.28:8080/job/apic/1860/
http://cisco-neutron-ci.cisco.com/logs/apic/1860/

But the review comments never showed up on Gerrit. This seems to be an 
intermittent quirk of Jenkins/Gerrit: We have 3 CIs triggered from this 
Jenkins/Gerrit server. Whenever we disable another one of our other Jenkins 
jobs (in this case, we disabled DFA for some rework), the review comments 
sometimes stop showing up on Gerrit.

-Original Message-
From: Edgar Magana [mailto:edgar.mag...@workday.com]
Sent: Tuesday, August 19, 2014 1:33 PM
To: Dane Leblanc (leblancd); OpenStack Development Mailing List (not for usage 
questions)
Subject: Re: [openstack-dev] [neutron] [third-party] What tests are required to 
be run

I was looking to one of the most recent Neutron commits:
https://review.openstack.org/#/c/115175/


I could not find the APIC report.

Edgar

On 8/19/14, 9:48 AM, Dane Leblanc (leblancd) lebla...@cisco.com wrote:

From which commit is it missing?
https://review.openstack.org/#/c/114629/
https://review.openstack.org/#/c/114393/

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

Dane,

Are you sure about it?
I just went to this commit and I could not find the APIC tests.

Thanks,

Edgar

On 8/17/14, 8:47 PM, Dane Leblanc (leblancd) lebla...@cisco.com wrote:

Edgar:

The Cisco APIC should be reporting results for both APIC-related and 
non-APIC related changes now.
(See http://cisco-neutron-ci.cisco.com/logs/apic/1738/).

Will you be updating the wiki page?

-Dane

-Original Message-
From: Dane Leblanc (leblancd)
Sent: Friday, August 15, 2014 8:18 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron] [third-party] What tests are 
required to be run

Also, you can add me as a contact person for the Cisco VPNaaS driver.

-Original Message-
From: Dane Leblanc (leblancd)
Sent: Friday, August 15, 2014 8:14 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: RE: [openstack-dev] [neutron] [third-party] What tests are 
required to be run

Edgar:

For the Notes for the Cisco APIC, can you change the comment results 
are fake to something like results are only valid for APIC-related 
commits? I think this more accurately represents our current results 
(for reasons we chatted about on another thread).

Thanks,
Dane

-Original Message-
From: Edgar Magana [mailto:edgar.mag...@workday.com]
Sent: Friday, August 15, 2014 6:36 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

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_P
l
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] [neutron] [third-party] Some third party results are not showing up in the CI summary on Gerrit

[Dane Leblanc (leblancd)]

If you look at review page for any of our Neutron commits, e.g.:
   https://review.openstack.org/#/c/115025/
You'll see that there is a handy summary of CI results (with links to logs) in 
the upper right. However, there are some CIs which are missing from this 
summary, although we know that they had left a review comment or voted +1/-1 
because they're listed in the Reviewer list on the left.

Note that there is an indirect way to find the logs for these CIs, by clicking 
on Toggle CI at the very bottom and scrolling through the results.

Henry Gessau checked with the openstack-infra team for clarification, and the 
explanation he got was that the Gerrit review page will only be able to include 
summaries for the CIs which leave review comments in the same format that the 
community Jenkins CI uses.

Here's an example of the Jenkins format (for illustration, hyperlinks and tabs 
are lost here in text mode):

Jenkins Aug 20 6:52 PM

Patch Set 9: Verified+1

Build succeeded.

gate-neutron-pep8 SUCCESS in 5m 36s
gate-neutron-docs SUCCESS in 3m 46s
gate-neutron-python26 SUCCESS in 37m 37s
gate-neutron-python27 SUCCESS in 29m 26s
check-tempest-dsvm-neutron-heat-slow SUCCESS in 26m 40s
check-tempest-dsvm-neutron-pg SUCCESS in 1h 04m 55s
check-tempest-dsvm-neutron-full SUCCESS in 1h 03m 18s
check-tempest-dsvm-neutron-pg-full FAILURE in 1h 11m 01s (non-voting)
gate-tempest-dsvm-neutron-large-ops SUCCESS in 25m 11s
check-grenade-dsvm-neutron FAILURE in 32m 38s (non-voting)
check-neutron-dsvm-functional SUCCESS in 21m 20s
gate-rally-dsvm-neutron-neutron SUCCESS in 19m 31s (non-voting)
check-tempest-dsvm-neutron-pg-2 SUCCESS in 1h 00m 40s
check-tempest-dsvm-neutron-full-2 SUCCESS in 55m 28s
check-tempest-dsvm-neutron-pg-full-2 FAILURE in 1h 05m 17s (non-voting)

For CIs which use a Zuul front end, this format comes automatic. But for 
others, the format of review comments may need some changes in order to match 
the Jenkins review comment format.

I don't think this is critical, but it would be nice to have everything 
summarized consistently.

Thanks,
Dane


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

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

[Dane Leblanc (leblancd)]

Edgar:

I'm still seeing the comment Results are not accurate. Needs clarification...

Dane

-Original Message-
From: Edgar Magana [mailto:edgar.mag...@workday.com] 
Sent: Thursday, August 21, 2014 2:58 PM
To: Dane Leblanc (leblancd); OpenStack Development Mailing List (not for usage 
questions)
Subject: Re: [openstack-dev] [neutron] [third-party] What tests are required to 
be run

Dane,

Wiki has been updated.

Thanks,

Edgar

On 8/21/14, 7:57 AM, Dane Leblanc (leblancd) lebla...@cisco.com wrote:

Edgar:

The status on the wiki page says Results are not accurate. Needs 
clarification from Cisco.
Can you please tell me what we are missing?

-Dane

-Original Message-
From: Dane Leblanc (leblancd)
Sent: Tuesday, August 19, 2014 3:05 PM
To: 'Edgar Magana'; OpenStack Development Mailing List (not for usage
questions)
Subject: RE: [openstack-dev] [neutron] [third-party] What tests are 
required to be run

The APIC CI did run tests against that commit (after some queue latency):

http://128.107.233.28:8080/job/apic/1860/
http://cisco-neutron-ci.cisco.com/logs/apic/1860/

But the review comments never showed up on Gerrit. This seems to be an 
intermittent quirk of Jenkins/Gerrit: We have 3 CIs triggered from this 
Jenkins/Gerrit server. Whenever we disable another one of our other 
Jenkins jobs (in this case, we disabled DFA for some rework), the 
review comments sometimes stop showing up on Gerrit.

-Original Message-
From: Edgar Magana [mailto:edgar.mag...@workday.com]
Sent: Tuesday, August 19, 2014 1:33 PM
To: Dane Leblanc (leblancd); OpenStack Development Mailing List (not 
for usage questions)
Subject: Re: [openstack-dev] [neutron] [third-party] What tests are 
required to be run

I was looking to one of the most recent Neutron commits:
https://review.openstack.org/#/c/115175/


I could not find the APIC report.

Edgar

On 8/19/14, 9:48 AM, Dane Leblanc (leblancd) lebla...@cisco.com wrote:

From which commit is it missing?
https://review.openstack.org/#/c/114629/
https://review.openstack.org/#/c/114393/

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

Dane,

Are you sure about it?
I just went to this commit and I could not find the APIC tests.

Thanks,

Edgar

On 8/17/14, 8:47 PM, Dane Leblanc (leblancd) lebla...@cisco.com
wrote:

Edgar:

The Cisco APIC should be reporting results for both APIC-related and 
non-APIC related changes now.
(See http://cisco-neutron-ci.cisco.com/logs/apic/1738/).

Will you be updating the wiki page?

-Dane

-Original Message-
From: Dane Leblanc (leblancd)
Sent: Friday, August 15, 2014 8:18 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron] [third-party] What tests are 
required to be run

Also, you can add me as a contact person for the Cisco VPNaaS driver.

-Original Message-
From: Dane Leblanc (leblancd)
Sent: Friday, August 15, 2014 8:14 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: RE: [openstack-dev] [neutron] [third-party] What tests are 
required to be run

Edgar:

For the Notes for the Cisco APIC, can you change the comment results 
are fake to something like results are only valid for APIC-related 
commits? I think this more accurately represents our current results 
(for reasons we chatted about on another thread).

Thanks,
Dane

-Original Message-
From: Edgar Magana [mailto:edgar.mag...@workday.com]
Sent: Friday, August 15, 2014 6:36 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

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_
P
l
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

[openstack-dev] [Neutron] How to handle blocking bugs/changes in Neutron 3rd party CI

[Dane Leblanc (leblancd)]

Preface: I posed this problem on the #openstack-infra IRC, and they couldn't 
offer an easy or obvious solution, and suggested that I get some consensus from 
the Neutron community as to how we want to handle this situation. So I'd like 
to bounce this around, get some ideas, and maybe bring this up in the 3rd party 
CI IRC.

The challenge is this: Occasionally, a blocking bug is introduced which causes 
our 3rd party CI tests to consistently fail on every change set that we're 
testing against. We can develop a fix for the problem, but until that fix gets 
merged upstream, tests against all other change sets are seen to fail.

(Note that we have a similar situation whenever we introduce a completely new 
plugin with its associated 3rd party CI... until the plugin code, or an 
enabling subset of that plugin code is merged upstream, then typically all 
other commits would fail on that CI setup.)

In the past, we've tried dynamically patching the fix(es) on top of the fetched 
code being reviewed, but this isn't always reliable due to merge conflicts, and 
we've had to monkey patch DevStack to apply the fixes after cloning Neutron but 
before installing Neutron.

So we'd prefer to enter a throttled or filtering CI mode when we hit this 
situation, where we're (temporarily) only testing against commits related to 
our plugin/driver which contain (or have a dependency on) the fix for the 
blocking bug until the fix is merged.

In an ideal world, for the sake of transparency, we would love to be able to 
have Jenkins/Zuul report back to Gerrit with a descriptive test result such as 
N/A, Not tested, or even Aborted for all other change sets, letting the 
committer know that, Yeah, we see your review, but we're unable to test it at 
the moment. Zuul does have the ability to report Aborted status to Gerrit, 
but this is sent e.g. when Zuul decides to abort change set 'N' for a review 
when change set 'N+1' has just been submitted, or when a Jenkins admin manually 
aborts a Jenkins job.  Unfortunately, this type of status is not available 
programmatically within a Jenkins job script; the only outcomes are pass (zero 
RC) or fail (non-zero RC). (Note that we can't directly filter at the Zuul 
level in our topology, since we have one Zuul server servicing multiple 3rd 
party CI setups.)

As a second option, we'd like to not run any tests for the other changes, and 
report NOTHING to Gerrit, while continuing to run against changes related to 
our plugin (as required for the plugin changes to be approved).  This was the 
favored approach discussed in the Neutron IRC on Monday. But herein lies the 
rub. By the time our Jenkins job script discovers that the change set that is 
being tested is not in a list of preferred/allowed change sets, the script has 
2 options: pass or fail. With the current Jenkins, there is no programmatic way 
for a Jenkins script to signal to Gearman/Zuul that the job should be aborted.

There was supposedly a bug filed with Jenkins to allow it to interpret 
different exit codes from job scripts as different result values, but this 
hasn't made any progress.

There may be something that can be changed in Zuul to allow it to interpret 
different result codes other than success/fail, or maybe to allow Zuul to do 
change ID filtering on a per Jenkins job basis, but this would require the 
infra team to make changes to Zuul.

The bottom line is that based on the current Zuul/Jenkins infrastructure, 
whenever our 3rd party CI is blocked by a bug, I'm struggling with the 
conflicting requirements:
* Continue testing against change sets for the blocking bug (or plugin related 
changes)
* Don't report anything to Gerrit for all other change sets, since these can't 
be meaningfully tested against the CI hardware

Let me know if I'm missing a solution to this. I appreciate any suggestions!

-Dane


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

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

[Dane Leblanc (leblancd)]

From which commit is it missing?
https://review.openstack.org/#/c/114629/
https://review.openstack.org/#/c/114393/

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

Dane,

Are you sure about it?
I just went to this commit and I could not find the APIC tests.

Thanks,

Edgar

On 8/17/14, 8:47 PM, Dane Leblanc (leblancd) lebla...@cisco.com wrote:

Edgar:

The Cisco APIC should be reporting results for both APIC-related and 
non-APIC related changes now.
(See http://cisco-neutron-ci.cisco.com/logs/apic/1738/).

Will you be updating the wiki page?

-Dane

-Original Message-
From: Dane Leblanc (leblancd)
Sent: Friday, August 15, 2014 8:18 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron] [third-party] What tests are 
required to be run

Also, you can add me as a contact person for the Cisco VPNaaS driver.

-Original Message-
From: Dane Leblanc (leblancd)
Sent: Friday, August 15, 2014 8:14 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: RE: [openstack-dev] [neutron] [third-party] What tests are 
required to be run

Edgar:

For the Notes for the Cisco APIC, can you change the comment results 
are fake to something like results are only valid for APIC-related 
commits? I think this more accurately represents our current results 
(for reasons we chatted about on another thread).

Thanks,
Dane

-Original Message-
From: Edgar Magana [mailto:edgar.mag...@workday.com]
Sent: Friday, August 15, 2014 6:36 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

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


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

Re: [openstack-dev] Status of Neutron IPv6 dual stack

[Dane Leblanc (leblancd)]

Hi Harm:

Unfortunately I haven’t had time to complete the changes yet. Even if/when 
these changes are completed, it’s unlikely that this blueprint will get 
approved for Juno, but I’ll see what I can do.

Thanks,
Dane


From: Harm Weites [mailto:h...@weites.com]
Sent: Tuesday, August 19, 2014 12:53 PM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] Status of Neutron IPv6 dual stack

Thiago,

My old setup was dual-stacked, simply using a flat linuxbridge. It's just that 
I now realy would like to separate multiple tenants using L3 routers, which 
should be easy (dual stacked) to achieve once Dane's work is completed.

Did you find the time to commit those required changes for that yet Dane?

Regards,
Harm
op 16-08-14 23:33, Martinx - ジェームズ schreef:
Guys,

Just for the record, I'm using IceHouse in a Dual-Stacked environment (with 
security groups working) but, Instance's IPv6 address are static (no upstream 
SLAAC, arrived in Juno-2, I think) and the topology is `VLAN Provider 
Networks`, no Neutron L3 Router. Where each VLAN have v4/v6 addrs, same 
upstream router (also dual-stacked - still no radvd enabled).

Looking forward to start testing L3 + IPv6 in K...

Best,
Thiago

On 16 August 2014 16:21, Harm Weites h...@weites.commailto:h...@weites.com 
wrote:
Hi Dane,

Thanks, that looks promising. Once support for multiple v6 addresses on
gateway ports is added I'll be happy to give this a go. Should it work
just fine with an otherwise Icehouse based deployment?

Regards,
Harm

op 16-08-14 20:31, Dane Leblanc (leblancd) schreef:
 Hi Harm:

 Can you take a look at the following, which should address this:
 https://blueprints.launchpad.net/neutron/+spec/multiple-ipv6-prefixes

 There are some diffs out for review for this blueprint:
https://review.openstack.org/#/c/113339/
 but the change to support 1 V4 + multiple V6 addresses on a gateway port 
 hasn't been added yet. I should be adding this soon.

 There was a request for a Juno feature freeze exception for this blueprint, 
 but there's been no response, so this may not get approved until K release.

 -Dane

 -Original Message-
 From: Harm Weites [mailto:h...@weites.commailto:h...@weites.com]
 Sent: Saturday, August 16, 2014 2:22 PM
 To: 
 openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
 Subject: [openstack-dev] Status of Neutron IPv6 dual stack

 Hi,

 Given the work on [1] has been abandoned, I'm wondering what the current 
 status of going dual stack is. Of course, given Neutron got something like 
 that on it's roadmap.

 The initial BP [2] aimed for Havana and Icehouse, and I'm unaware of 
 something similar to achieve a dual stack network. What are the options, if 
 any? To my knowledge it all comes down to supporting multiple exterior 
 interfaces (networks) on a l3-agent, which is currently limited to just 1: 
 either IP4 or IP6.

 [1] https://review.openstack.org/#/c/77471/
 [2]
 https://blueprints.launchpad.net/neutron/+spec/allow-multiple-subnets-on-gateway-port

 Regards,
 Harm

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

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


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





___

OpenStack-dev mailing list

OpenStack-dev@lists.openstack.orgmailto: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

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

[Dane Leblanc (leblancd)]

Edgar:

The Cisco APIC should be reporting results for both APIC-related and non-APIC 
related changes now.
(See http://cisco-neutron-ci.cisco.com/logs/apic/1738/).

Will you be updating the wiki page?

-Dane

-Original Message-
From: Dane Leblanc (leblancd) 
Sent: Friday, August 15, 2014 8:18 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron] [third-party] What tests are required to 
be run

Also, you can add me as a contact person for the Cisco VPNaaS driver.

-Original Message-
From: Dane Leblanc (leblancd)
Sent: Friday, August 15, 2014 8:14 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: RE: [openstack-dev] [neutron] [third-party] What tests are required to 
be run

Edgar:

For the Notes for the Cisco APIC, can you change the comment results are fake 
to something like results are only valid for APIC-related commits? I think 
this more accurately represents our current results (for reasons we chatted 
about on another thread).

Thanks,
Dane

-Original Message-
From: Edgar Magana [mailto:edgar.mag...@workday.com]
Sent: Friday, August 15, 2014 6:36 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

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

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

Re: [openstack-dev] Status of Neutron IPv6 dual stack

[Dane Leblanc (leblancd)]

Hi Harm:

Can you take a look at the following, which should address this:
https://blueprints.launchpad.net/neutron/+spec/multiple-ipv6-prefixes

There are some diffs out for review for this blueprint:
   https://review.openstack.org/#/c/113339/
but the change to support 1 V4 + multiple V6 addresses on a gateway port hasn't 
been added yet. I should be adding this soon.

There was a request for a Juno feature freeze exception for this blueprint, but 
there's been no response, so this may not get approved until K release.

-Dane 

-Original Message-
From: Harm Weites [mailto:h...@weites.com] 
Sent: Saturday, August 16, 2014 2:22 PM
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] Status of Neutron IPv6 dual stack

Hi,

Given the work on [1] has been abandoned, I'm wondering what the current status 
of going dual stack is. Of course, given Neutron got something like that on 
it's roadmap.

The initial BP [2] aimed for Havana and Icehouse, and I'm unaware of something 
similar to achieve a dual stack network. What are the options, if any? To my 
knowledge it all comes down to supporting multiple exterior interfaces 
(networks) on a l3-agent, which is currently limited to just 1: either IP4 or 
IP6.

[1] https://review.openstack.org/#/c/77471/
[2]
https://blueprints.launchpad.net/neutron/+spec/allow-multiple-subnets-on-gateway-port

Regards,
Harm

___
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

Re: [openstack-dev] Status of Neutron IPv6 dual stack

[Dane Leblanc (leblancd)]

Hi Harm:

The changes for the multiple v6 addresses blueprint depend upon 2 Neutron 
changes that are not in Icehouse, but are merged in the latest upstream:
https://blueprints.launchpad.net/neutron/+spec/ipv6-two-attributes
https://blueprints.launchpad.net/neutron/+spec/ipv6-provider-nets-slaac

Also, if you want to use IPv6 SLAAC addresses assigned by Neutron (via RADVD), 
you'll want some changes for the following blueprint, that are not in Icehouse 
but are in the latest upstream:
https://blueprints.launchpad.net/neutron/+spec/neutron-ipv6-radvd-ra

If you want to use DHCPv6 stateful addresses assigned by Neutron, I believe 
that you'll need the changes from this blueprint that are still out for review:
https://blueprints.launchpad.net/neutron/+spec/dnsmasq-ipv6-dhcpv6-stateful

-Dane

-Original Message-
From: Harm Weites [mailto:h...@weites.com] 
Sent: Saturday, August 16, 2014 3:21 PM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] Status of Neutron IPv6 dual stack

Hi Dane,

Thanks, that looks promising. Once support for multiple v6 addresses on gateway 
ports is added I'll be happy to give this a go. Should it work just fine with 
an otherwise Icehouse based deployment?

Regards,
Harm

op 16-08-14 20:31, Dane Leblanc (leblancd) schreef:
 Hi Harm:

 Can you take a look at the following, which should address this:
 
 https://blueprints.launchpad.net/neutron/+spec/multiple-ipv6-prefixes

 There are some diffs out for review for this blueprint:
https://review.openstack.org/#/c/113339/
 but the change to support 1 V4 + multiple V6 addresses on a gateway port 
 hasn't been added yet. I should be adding this soon.

 There was a request for a Juno feature freeze exception for this blueprint, 
 but there's been no response, so this may not get approved until K release.

 -Dane

 -Original Message-
 From: Harm Weites [mailto:h...@weites.com]
 Sent: Saturday, August 16, 2014 2:22 PM
 To: openstack-dev@lists.openstack.org
 Subject: [openstack-dev] Status of Neutron IPv6 dual stack

 Hi,

 Given the work on [1] has been abandoned, I'm wondering what the current 
 status of going dual stack is. Of course, given Neutron got something like 
 that on it's roadmap.

 The initial BP [2] aimed for Havana and Icehouse, and I'm unaware of 
 something similar to achieve a dual stack network. What are the options, if 
 any? To my knowledge it all comes down to supporting multiple exterior 
 interfaces (networks) on a l3-agent, which is currently limited to just 1: 
 either IP4 or IP6.

 [1] https://review.openstack.org/#/c/77471/
 [2]
 https://blueprints.launchpad.net/neutron/+spec/allow-multiple-subnets-
 on-gateway-port

 Regards,
 Harm

 ___
 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

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

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

[Dane Leblanc (leblancd)]

Edgar:

For the Notes for the Cisco APIC, can you change the comment results are fake 
to something like results are only valid for APIC-related commits? I think 
this more accurately represents our current results (for reasons we chatted 
about on another thread).

Thanks,
Dane

-Original Message-
From: Edgar Magana [mailto:edgar.mag...@workday.com] 
Sent: Friday, August 15, 2014 6:36 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

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

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

[Dane Leblanc (leblancd)]

Also, you can add me as a contact person for the Cisco VPNaaS driver.

-Original Message-
From: Dane Leblanc (leblancd) 
Sent: Friday, August 15, 2014 8:14 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: RE: [openstack-dev] [neutron] [third-party] What tests are required to 
be run

Edgar:

For the Notes for the Cisco APIC, can you change the comment results are fake 
to something like results are only valid for APIC-related commits? I think 
this more accurately represents our current results (for reasons we chatted 
about on another thread).

Thanks,
Dane

-Original Message-
From: Edgar Magana [mailto:edgar.mag...@workday.com]
Sent: Friday, August 15, 2014 6:36 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

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

[openstack-dev] [Neutron] [Spec freeze exception] Multiple IPv6 Prefixes/Addresses per port

[Dane Leblanc (leblancd)]

I would like to request Juno spec freeze exception for the Multiple IPv6 
Prefixes/Addresses per port blueprint:

https://review.openstack.org/98217

This feature defines how multiple IPv6 prefixes and/or addresses per Neutron 
port should be supported in OpenStack, in a manner that is consistent with the 
nature of IPv6. Without this change, the IPv6 addresses shown as active on a 
port may not match what's actually in use on the port.

The dependencies for this feature have already been merged.

The following work items listed in the design spec are complete:
   - Port-create API handling changes
   - Port-update API handling changes
   - Subnet-delete API handling changes
And the following work items are yet to be done:
   - L3 agent changes (number addresses per gateway port)
   - Unit tests
   - Tempest tests

Thanks,
Dane


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

Re: [openstack-dev] [infra] Basic zuul startup question: Private key file is encrypted

[Dane Leblanc (leblancd)]

Jeremy:

Thanks, this did the trick. I have zuul connecting with gerrit, and it's 
detecting neutron reviews. I still don't have all the pieces working, but I 
think I'm closing in.

Thanks,
Dane

-Original Message-
From: Jeremy Stanley [mailto:fu...@yuggoth.org] 
Sent: Tuesday, April 15, 2014 7:53 PM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [infra] Basic zuul startup question: Private key 
file is encrypted

On 2014-04-15 23:24:31 + (+), Jeremy Stanley wrote:
[...]
 You'll need to strip the encryption from it with something like...
 
 ssh-keygen -p -f ~/.ssh/id_dsa
[...]

Or more likely, since the patents on RSA expired about 14 years ago...

ssh-keygen -p -f ~/.ssh/id_rsa

--
Jeremy Stanley

___
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] [infra] Basic zuul startup question: Private key file is encrypted

[Dane Leblanc (leblancd)]

I'm trying to modify a 3rd party test setup to use zuul, but I'm seeing the 
following error when I start up the zuul server:

===
2014-04-15 09:09:18,910 ERROR gerrit.GerritWatcher: Exception on ssh event 
stream:
Traceback (most recent call last):
  File /usr/local/lib/python2.7/dist-packages/zuul/lib/gerrit.py, line 64, in 
_run
key_filename=self.keyfile)
  File /usr/local/lib/python2.7/dist-packages/paramiko/client.py, line 342, 
in connect
self._auth(username, password, pkey, key_filenames, allow_agent, 
look_for_keys)
  File /usr/local/lib/python2.7/dist-packages/paramiko/client.py, line 533, 
in _auth
raise saved_exception
PasswordRequiredException: Private key file is encrypted
===

Here is my zuul config file (/etc/zuul/zuul.conf):

===
[gearman]
server=127.0.0.1

[gearman_server]
start=true
log_config=/etc/zuul/gearman-logging.conf

[gerrit]
server=review.openstack.org
user=zuul
sshkey=/var/lib/zuul/.ssh/id_rsa
#user=jenkins
#sshkey=/var/lib/jenkins/.ssh/id_rsa
#user=cisco_neutron_ci
#sshkey=/home/cisco_neutron_ci/.ssh/id_rsa

[zuul]
layout_config=/etc/zuul/layout.yaml
log_config=/etc/zuul/logging.conf
state_dir=/var/lib/zuul
git_dir=/var/lib/zuul/git
push_change_refs=false
url_pattern=http://128.107.233.28:8080/job/(job.name)/(build.number)
status_url=http://status.openstack.org/zuul/
job_name_in_report=true
zuul_url=https://review.openstack.org
===

I've tried using various users for the zuul-to-gerrit connection (zuul, 
jenkins, and our corporate gerrit account username).

Is there something basic that I'm missing in the config?

Appreciate any help,
Dane

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

Re: [openstack-dev] Neutron error using devstack

[Dane Leblanc (leblancd)]

Abhishek:

In addition to the localrc settings as Elena suggests, try sourcing credentials 
for user 'admin' using the devstack/openrc script, e.g.:
source ~/devstack/openrc admin
before executing neutron commands. Later, if you want to e.g. launch a VM as 
user/tenant 'demo', you would source credentials as:
source ~/devstack/openrc demo

Good luck!

From: Elena Ezhova [mailto:eezh...@mirantis.com]
Sent: Saturday, March 01, 2014 2:13 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] Neutron error using devstack


If you want to use Neutron with devstack you have to add the related settings 
to localrc.

Please see https://wiki.openstack.org/wiki/NeutronDevstack for detailed 
instructions.
01 марта 2014 г. 22:11 пользователь abhishek jain 
ashujain9...@gmail.commailto:ashujain9...@gmail.com написал:

Hi all

I have installed devstack successfully from the following link...

http://www.linux.com/learn/tutorials/721712-intro-to-openstack-part-two-how-to-install-and-configure-openstack-on-a-server

However I'm not able to run the neutron services.The error which generally 
comes after running neutron command is as follows.

neutron subnet-create vxlan-net 10.100.1.0/24http://10.100.1.0/24 --name 
vxlan-net

You must provide a username via either --os-username or env[OS_USERNAME]

ashu@ashu $ ps -ef | grep neutron
ashu31039 30660  0 18:09 pts/25   00:00:00 grep --color=auto neutron

Please help regarding this

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.orgmailto: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