Re: [opnfv-tech-discuss] need yardstick installation document

[liyin (F)]

Maybe this will help you
https://docs.opnfv.org/en/stable-danube/submodules/yardstick/docs/testing/user/userguide/index.html


Regards,

Ace

From: opnfv-tech-discuss-boun...@lists.opnfv.org 
[mailto:opnfv-tech-discuss-boun...@lists.opnfv.org] On Behalf Of Kalaivani R
Sent: Tuesday, June 06, 2017 1:50 PM
To: opnfv-tech-discuss@lists.opnfv.org
Subject: [opnfv-tech-discuss] need yardstick installation document


Hi,

can any one share yardstick installation document.









Regards,

Kalaivani.R

Disclaimer:  This message and the information contained herein is proprietary 
and confidential and subject to the Tech Mahindra policy statement, you may 
review the policy at http://www.techmahindra.com/Disclaimer.html externally 
http://tim.techmahindra.com/tim/disclaimer.html internally within TechMahindra.

___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

[opnfv-tech-discuss] information about compass sriov

[liyin (F)]

Hi Ross,

As discussed  in yardstick meeting I have provide  the information about 
compass configure in attachment.

By the way, we haven't tested sr-iov on compass.
Those two files are compute.pdf and controller.pdf is the output of plotnetcfg.

Regards
Ace.



compute.pdf
Description: compute.pdf


controller.pdf
Description: controller.pdf
___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

[opnfv-tech-discuss] information about SR-IOV

[liyin (F)]

Hi Ross,

As discussed  in yardstick meeting I have provide  the information about our 
SR-IOV configure in attachment.

Our environment is Apex , more information is : nosdn-nofeature-ha.
Before we begin test, we will use 
https://docs.openstack.org/mitaka/networking-guide/config-sriov.html to 
configure the environment.
This url document have some error at  compute node configuration at 
pci_passthrough_whitelist chapter.
Then we will use the special image we made to create stack using the 
sriov_vlan_net.yaml file.
The we deploy Moongen at the ceph node do test.
The compute.pdf and cephstorage.pdf is the output of plotnetcfg.
And also the apex_osp_network_configure.jpg is the network configuration of my 
environment.

We will use osp10 to do the same test in the future.
Those files is osp10 environment configuration for your reference.

Regards
Ace.


cephstorage.pdf
Description: cephstorage.pdf


compute.pdf
Description: compute.pdf


sriov_vlan_net.yaml
Description: sriov_vlan_net.yaml
___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

Re: [opnfv-tech-discuss] Apex bare metel deploy problem

[liyin (F)]

Hi Lance,

Sorry for missing your log email.

After I have seen this log , I think this may be some network connection 
problem.
could you please try to ping the IPMI ip address both on your jumpserver and 
undercloud.
For example: 
" ipmitool -I lanplus -H  -L ADMINISTRATOR -U  -P  
power status "

All nodes must be connected to jumpserver and undercloud.

Best Regards,
Ace.

-Original Message-----
From: liyin (F) 
Sent: Friday, February 03, 2017 2:32 PM
To: 'lance.p...@orange.com' <lance.p...@orange.com>
Subject: RE: [opnfv-tech-discuss] Apex bare metel deploy problem

Hi Lance,

Sorry for delaying replying your email because of the Spring Festival.

The correct log file is on
https://build.opnfv.org/ci/view/apex/job/apex-deploy-baremetal-os-nosdn-nofeature-ha-master/lastBuild/consoleFull

if your output log contain the follows:

Executing overcloud deployment, this should run for an extended period without 
output. 

I think you have begun to deploy overcloud openstack.

Then if the deployment failed you could use journalctl on undercloud to check 
if there are  TFTPBOOT/DHCP requests from your other pod.

Would you mind send log file to me?
Without this file it's difficult to local the deploy problem.
 
Best Regards,
Ace.

-Original Message-
From: lance.p...@orange.com [mailto:lance.p...@orange.com]
Sent: Wednesday, February 01, 2017 9:20 PM
To: liyin (F) <liyi...@huawei.com>
Subject: RE: [opnfv-tech-discuss] Apex bare metel deploy problem

Hi Liyin,

My name is Lance from Orange.  I was following some of your debugs, and was 
wondering if you can point me to some log files that can help with issues on 
Overcloud install. 
I was able to get all the undercloud working, but don't see controllers and 
node listing.  IPMI to all the controller nodes are fine.

Thanks,
Lance

-Original Message-
From: opnfv-tech-discuss-boun...@lists.opnfv.org 
[mailto:opnfv-tech-discuss-boun...@lists.opnfv.org] On Behalf Of liyin (F)
Sent: Thursday, January 19, 2017 12:58 AM
To: Tim Rozet
Cc: opnfv-tech-discuss@lists.opnfv.org
Subject: Re: [opnfv-tech-discuss] Apex bare metel deploy problem

Hi Tim,

Thanks a lot for your help! Your suggestion of those three point have helped me 
a lot.
I have deployed the apex physics pod successfully.

Best Regards,
Ace.
___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

Re: [opnfv-tech-discuss] Apex bare metel deploy problem

[liyin (F)]

Hi Tim,

I have confirmed that our jumphost is connected with the compute node by IPMI.
And undercloud VM is also connected with those compute node.

To locate the problem, I decided to checkout our pod network configuration with 
LF-pod1.

If I have some clues about this problem, I will seek advice from you.
Thanks for your kindness.

Best Regards,
Ace.

-Original Message-
From: Tim Rozet [mailto:tro...@redhat.com] 
Sent: Friday, January 13, 2017 4:07 AM
To: liyin (F) <liyi...@huawei.com>
Cc: opnfv-tech-discuss@lists.opnfv.org
Subject: Re: [opnfv-tech-discuss] Apex bare metel deploy problem

Hi Ace,
Can you verify that ipmitool works first on the jumphost to access every node?  
If so, then validate the same thing on the undercloud VM.  That will rule out 
any connectivity issues between Undercloud Ironic and the IPMI access to each 
node.  The errors still seem to show a problem with detecting power state of 
the nodes.

Thanks,

Tim Rozet
Red Hat SDN Team

- Original Message -
From: "liyin (F)" <liyi...@huawei.com>
To: "Tim Rozet" <tro...@redhat.com>
Cc: opnfv-tech-discuss@lists.opnfv.org
Sent: Tuesday, January 10, 2017 3:56:58 AM
Subject: RE: [opnfv-tech-discuss] Apex bare metel deploy problem

Hi Tim,



I have confirmed that IPMI is indeed not connected from our jumphost to the 
compute node.

I have searched for the reasons. Finally I find out that it is because our ipmi 
switchboard is connected to external switchboard.



To solve this problem I have connected the jumphost with ipmi switchboard and 
external  switchboard.

Then I use the iso of artifacts: opnfv-2016-12-21.iso to deploy apex.

the results and log are shown as attached: 1) Ipmi_nova_list.png; 2) 
Ipmi_openstack_failure*.png (output of openstack stack failures list overcloud 
--long); 3) apex_log.txt

The deployment of overcloud node still failed while the connection between 
jumphost and compute node is success. For more information please refer to the 
attachment.



For the reasons of the unsuccessful deployment, my guesses are:

1)Those nodes have errors in network configuration.

2)The network_settings.yaml have some errors

I wonder if my guesses are correct? Could you please provide me some solutions?





Some information of the network configuration is provided as follows.



1.Attached my network configuration file: network_settings_normal.yaml

2. Jumphost informations could be found below

[cid:image003.jpg@01D26B62.8A3DF910]

NIC name


IP


switch


Have external net access


enp2s0f0


192.168.36.2


External switch


yes


enp2s0f1


10.10.10.2


External switch


no


The other nodes  network configuration

NIC name


IP


switch


Have external net access


enp2s0f0


no


External switch


*


enp2s0f1


no


External switch


*




The other nodes don’t have operation system, only two NICs connect to external 
switch.

Both jumphost and nodes are connected with ipmi switch.



There are some other issues during the deployment:



During the deployment of apex, I have no access from external network to 
jumphost.

After br-admin and br-external have bridged to NIC. I have access from 
external network to jumphost.

But when the log shown:

Executing overcloud deployment, this should run for an extended period 
without output.

I couldn't connect to jumphost with external network.





Thanks a lot,

And waiting for your reply.



Best Regards,

Ace.



-Original Message-

From: Tim Rozet [mailto:tro...@redhat.com]

Sent: Monday, January 09, 2017 11:48 PM

To: liyin (F) <liyi...@huawei.com>

Cc: opnfv-tech-discuss@lists.opnfv.org

Subject: Re: [opnfv-tech-discuss] Apex bare metel deploy problem



It looks like the problem might be IPMI connectivity from your jumphost to at 
least that compute node.  Can you try from your jumphost issuing ipmitool 
cmdline to make sure you can connect to them?



For example:

ipmitool -I lanplus -H  -L ADMINISTRATOR -U  -P  
power status



Tim Rozet

Red Hat SDN Team



- Original Message -

From: "liyin (F)" <liyi...@huawei.com>

To: "Tim Rozet" <tro...@redhat.com>

Cc: opnfv-tech-discuss@lists.opnfv.org

Sent: Friday, January 6, 2017 10:50:35 PM

Subject: RE: [opnfv-tech-discuss] Apex bare metel deploy problem



Hi Tim,

I could only get connect the jumphost by ipmi , so I only could provide you 
some picture .

I think it's also a problem during deplovement, I have no access to this 
jumphost.

By the way, this iso is master and the date is 2016.12.21.



Stack_list.png is the output of 3.

Nova_list.png is the output of 4.



Thank you for you kindness.



-Original Message-

From: Tim Rozet [mailto:tro...@redhat.com]

Sent: Friday, January 06, 2017 9:01 AM

To: liyin (F) <liyi...@huawei.com>

Cc: opnfv-tech-discuss@lists.opnfv.org

Subject: 

Re: [opnfv-tech-discuss] Apex bare metel deploy problem

[liyin (F)]

Hi Tim,
I could only get connect the jumphost by ipmi , so I only could provide you 
some picture .
I think it's also a problem during deplovement, I have no access to this 
jumphost.
By the way, this iso is master and the date is 2016.12.21.

Stack_list.png is the output of 3.
Nova_list.png is the output of 4.

Thank you for you kindness.

-Original Message-
From: Tim Rozet [mailto:tro...@redhat.com] 
Sent: Friday, January 06, 2017 9:01 AM
To: liyin (F) <liyi...@huawei.com>
Cc: opnfv-tech-discuss@lists.opnfv.org
Subject: Re: [opnfv-tech-discuss] Apex bare metel deploy problem

Hi Ace,
Can you please on your jumphost do:
1. opnfv-util undercloud
2. . stackrc
3. openstack stack failures list overcloud --long
4. nova list

Please send me the output of 3 and 4.

Thanks,

Tim Rozet
Red Hat SDN Team

- Original Message -
From: "liyin (F)" <liyi...@huawei.com>
To: opnfv-tech-discuss@lists.opnfv.org
Sent: Tuesday, December 27, 2016 3:41:57 AM
Subject: [opnfv-tech-discuss] Apex bare metel deploy problem



Hi all, 



We have an environment of bare metal pods. And we want to use apex to deploy 
openstack. 

I use the Centos iso from apex artifacts site to install jump server system. 

I have used several iso to deploy the environment and I get the same result as 
appendix showing. 

This log can’t help me to find where the problem is. 

And another thing is when I use opnfv-deploy os-nosdn-nofeature-ha.yaml to 
deploy, it will cost a lot of time. 

This puzzled me a lot, I need your help. 

Thanks in advance. 



Best Regards, 

Ace. 

___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss
___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

Re: [opnfv-tech-discuss] [functest] [yardstick] Client version can't support Newton - solution proposal

[liyin (F)]

Hi all,

Bottlenecks has also encountered the openstack client chosen issue. We are 
currently searching for solutions.
I also notice that the discussion may rush to a wrong direction.

I guess there may be one thing that need to be clarified, i.e., we should not 
focus on the adaption of different version of openstack. The real problem is we 
are dealing with different version of keystone clients.
Different version of openstack could use the same version of keystone clients. 
Newton is not bound with V3 client.

We do not have to own codes that should be developed in upstreams or drive us 
into developing any abstract layer.
We could search for solutions technically. As I experimented in my own 
environment, The openstack client has provided a mechanism to adapt different 
versions of keystone. I think we should explore more into this direction.

Regards,
Ace


From: opnfv-tech-discuss-boun...@lists.opnfv.org 
[mailto:opnfv-tech-discuss-boun...@lists.opnfv.org] On Behalf Of Christopher 
Price
Sent: Thursday, November 17, 2016 3:07 PM
To: SULLIVAN, BRYAN L ; yaohelan ; Jose 
Lausuch ; Beierl, Mark 
Cc: opnfv-tech-discuss@lists.opnfv.org
Subject: Re: [opnfv-tech-discuss] [functest] [yardstick] Client version can't 
support Newton - solution proposal

I agree, the thing to solve here is for the purely openstack activities we want 
to perform on the VIM.
Looking at areas like access connectivity and distributed cloud technologies 
these are capabilities that will most likely require more than an OpenStack 
northbound interface from the VIM.  There is no point trying to solve 
non-openstack issues in openstack.  They don’t need or want the complication 
of, for instance, trying to integrate the provisioning of a vOLT function into 
a VIM operation.

I do agree on trying to work with openstack to keep their interface (especially 
those we care about) backwards compliant, for that we must be fully engaged 
with the community related to our needed use cases.

We have the power to affect openstack and any other community when we are part 
of those communities.  But if we don’t show up the reverse is true.  Let’s make 
sure we know what we care about and demonstrate our care in those projects.  ☺

/ Chris


From: 
>
 on behalf of "SULLIVAN, BRYAN L" >
Date: Thursday, 17 November 2016 at 02:32
To: yaohelan >, Jose Angel 
Lausuch Sales >, 
"Beierl, Mark" >
Cc: TECH-DISCUSS OPNFV 
>
Subject: Re: [opnfv-tech-discuss] 答复: [functest] [yardstick] Client version 
can't support Newton - solution proposal

I would say that:

1)   We should strive to directly leverage upstream clients directly, and 
specifically the python-openstackclient in all cases where it serves our need 
for the specific OPNFV system version.

a.   Exceptions do exist, but we will not help promote removal of those 
exceptions by creating a shim client that shields us from the pain of the gaps, 
and the OpenStack python-openstackclient project from the need to address those 
gaps.

b.   After all, we are here to identity and address-upstream issues with 
the upstream projects.

2)   We should not own code intended as a long-term shim of an upstream 
project, even one that ostensibly simplifies how test code interacts with the 
openstack clients (the python-openstackclient or any of the others).

a.   An experimental shim might help the upstream teams to understand and 
address gaps/issues we have, but would have little real, long-term value to 
OPNFV beyond that.

b.   One key reason is any simplification/abstraction is likely to mask 
things that some project needs, and then we are right back to an 
exception/kludge situation, with the exception that to address the issue we now 
have to issue patches against another (and not even upstream) project.

3)   We should document all issues with the plan-of-record of the OpenStack 
community to converge on the python-openstackclient, and put any efforts to 
address them directly upstream, not in OPNFV.

a.   For now we have plenty of workaround approaches to those issues, e.g. 
use a different client/version.

b.   The implications/limitations of those workarounds should also be 
documented so we can decide which really are sufferable until the upstream 
client issues are addressed.

Thanks,
Bryan Sullivan | AT

From: 
opnfv-tech-discuss-boun...@lists.opnfv.org
 [mailto:opnfv-tech-discuss-boun...@lists.opnfv.org] On Behalf Of yaohelan
Sent: Monday, November 14, 2016 7:32 PM
To: