date:20170202

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

2017-02-02 Thread 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' 
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) 
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

[opnfv-tech-discuss] reply: [dovetail]dovetail weekly meeting 2/3( cancelled)

2017-02-02 Thread Tianhongbo

Hi all:

This dovetail meeting has been cancelled, since there is nobody host this 
dovetail call.

Best regards

hongbo

发件人: Tianhongbo
发送时间: 2017年2月2日 9:37
收件人: 'TECH-DISCUSS OPNFV'
主题: [dovetail]dovetail weekly meeting 2/3

Hi all:

Due to Chinese new year holiday, I cannot host this week’s Dovetail call. Can 
anyone help me to host it? Thanks.

The agenda for this week:


1)  Discussion on feedbacks from the Board meeting

2)  Filter/review process for testarea/testcases on Jira �C Bryan

3)  Test case run results history info gathering and display - Leo

4)  Other open issues: https://etherpad.opnfv.org/p/collabrationofdovetail

If you have other topics for the agenda, do not hesitate to let us know.

Meeting information:

・ Weekly on Friday at 1400-1500 UTC
・ Gotomeeting Access
・ https://global.gotomeeting.com/join/969604901
・ United States +1 (224) 501-3318
・ Access Code: 458-547-813
・ IRC channel
・ #opnfv-meeting@ Freenode (Web Chat)
・ For more detail, please refer to :
・ https://wiki.opnfv.org/display/dovetail

Best Regards

hongbo


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

[opnfv-tech-discuss] Cancelled: [dovetail]dovetail weekly meeting 2/3

2017-02-02 Thread Tianhongbo

BEGIN:VCALENDAR
PRODID://Yahoo//Calendar//EN
VERSION:2.0
METHOD:CANCEL
BEGIN:VEVENT
SUMMARY:[dovetail]dovetail weekly meeting 2/3
DESCRIPTION:??: 2017?2?3 22:00-23:00(UTC+08:00)???\n\n?
 ?: ?? GMT \n\n*~*~*~*~*~*~*~*~*~*\n\nHi all:\n\nDue to Chinese
  new year holiday\, I cannot host this week?s Dovetail call. Can anyone he
 lp me to host it? Thanks.\n\nThe agenda for this week:\n\n  1)  Di
 scussion on feedbacks from the Board meeting\n  2)  Filter/review 
 process for testarea/testcases on Jira ? Bryan\n  3)  Test case ru
 n results history info gathering and display - Leo\n  4)  Other op
 en issues: https://etherpad.opnfv.org/p/collabrationofdovetail\n\nIf you h
 ave other topics for the agenda\, do not hesitate to let us know.\n\nMeeti
 ng information:\n\n?   Weekly on Friday at 1400-1500 UTC\n?   Goto
 meeting Access\n?   https://global.gotomeeting.com/join/969604901\n?  
  United States +1 (224) 501-3318\n?   Access Code: 458-547-813\n? 
   IRC channel\n?   #opnfv-meeting@ Freenode (Web Chat)\n?   Fo
 r more detail\, please refer to :\n?   https://wiki.opnfv.org/display/
 dovetail\n\nBest Regards\n\nhongbo\n\n\n
CLASS:PUBLIC
DTSTART;TZID=Europe/London:20170203T14
DTEND;TZID=Europe/London:20170203T15
PRIORITY:0
SEQUENCE:0
STATUS:CONFIRMED
UID:04008200E00074C5B7101A82E008208B5CB5377DD201000
 01000BD7696B90094934A80702656E3D1FF07
DTSTAMP:20170202T013607Z
ATTENDEE;PARTSTAT=NEEDS-ACTION;CN='TECH-DISCUSS OPNFV';ROLE=REQ_PARTICIPANT
 ;RSVP=TRUE:mailto:opnfv-tech-discuss@lists.opnfv.org
ATTENDEE;PARTSTAT=NEEDS-ACTION;CN='Christopher Price';ROLE=REQ_PARTICIPANT;
 RSVP=TRUE:mailto:christopher.pr...@ericsson.com
ATTENDEE;PARTSTAT=NEEDS-ACTION;CN='Dave Neary';ROLE=REQ_PARTICIPANT;RSVP=TR
 UE:mailto:dne...@redhat.com
ATTENDEE;PARTSTAT=NEEDS-ACTION;CN='marko.a.kui...@nokia.com';ROLE=REQ_PARTI
 CIPANT;RSVP=TRUE:mailto:marko.a.kui...@nokia.com
ATTENDEE;PARTSTAT=NEEDS-ACTION;CN="'Rautakumpu, Mika (Nokia - FI/Espoo)'";R
 OLE=REQ_PARTICIPANT;RSVP=TRUE:mailto:mika.rautaku...@nokia.com
ATTENDEE;PARTSTAT=NEEDS-ACTION;CN='sheng-ann...@ericsson.com';ROLE=REQ_PART
 ICIPANT;RSVP=TRUE:mailto:sheng-ann...@ericsson.com
ATTENDEE;PARTSTAT=NEEDS-ACTION;CN='yangjian...@chinamobile.com';ROLE=REQ_PA
 RTICIPANT;RSVP=TRUE:mailto:yangjian...@chinamobile.com
ATTENDEE;PARTSTAT=NEEDS-ACTION;CN='zhang.ju...@zte.com.cn';ROLE=REQ_PARTICI
 PANT;RSVP=TRUE:mailto:zhang.ju...@zte.com.cn
ATTENDEE;PARTSTAT=NEEDS-ACTION;CN="'HU, BIN'";ROLE=REQ_PARTICIPANT;RSVP=TRU
 E:mailto:bh5...@att.com
ATTENDEE;PARTSTAT=NEEDS-ACTION;CN='l...@biigroup.cn';ROLE=REQ_PARTICIPANT;RS
 VP=TRUE:mailto:l...@biigroup.cn
ATTENDEE;PARTSTAT=NEEDS-ACTION;CN='Tetsuya Nakamura';ROLE=REQ_PARTICIPANT;R
 SVP=TRUE:mailto:t.nakam...@cablelabs.com
ATTENDEE;PARTSTAT=NEEDS-ACTION;CN=Wenjing Chu;ROLE=REQ_PARTICIPANT;RSVP=TRU
 E:mailto:wenjing@huawei.com
ATTENDEE;PARTSTAT=NEEDS-ACTION;CN=Christopher Donley (Chris);ROLE=REQ_PARTI
 CIPANT;RSVP=TRUE:mailto:christopher.don...@huawei.com
ATTENDEE;PARTSTAT=NEEDS-ACTION;CN='Jose Lausuch';ROLE=REQ_PARTICIPANT;RSVP=
 TRUE:mailto:jose.laus...@ericsson.com
ATTENDEE;PARTSTAT=NEEDS-ACTION;CN=Fatemeh Abdollahei;ROLE=REQ_PARTICIPANT;R
 SVP=TRUE:mailto:f.abdolla...@yahoo.com
ORGANIZER;CN=Tianhongbo:mailto:hongbo.tianhon...@huawei.com
X-MICROSOFT-CDO-APPT-SEQUENCE:0
X-MICROSOFT-CDO-OWNERAPPTID:1275209697
X-MICROSOFT-CDO-BUSYSTATUS:TENTATIVE
X-MICROSOFT-CDO-INTENDEDSTATUS:BUSY
X-MICROSOFT-CDO-ALLDAYEVENT:FALSE
X-MICROSOFT-CDO-IMPORTANCE:1
X-MICROSOFT-CDO-INSTTYPE:0
X-MICROSOFT-DISALLOW-COUNTER:FALSE
X-YAHOO-YID:yahoo.calendar.acl.writer
TRANSP:OPAQUE
STATUS:TENTATIVE
X-YAHOO-USER-STATUS:TENTATIVE
X-YAHOO-EVENT-STATUS:BUSY
BEGIN:VALARM
ACTION:DISPLAY
DESCRIPTION:
TRIGGER;RELATED=START:-PT15M
END:VALARM
END:VEVENT
BEGIN:VTIMEZONE
TZID:Europe/London
TZURL:http://tzurl.org/zoneinfo/Europe/London
X-LIC-LOCATION:Europe/London
BEGIN:DAYLIGHT
TZOFFSETFROM:+
TZOFFSETTO:+0100
TZNAME:BST
DTSTART:19810329T01
RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=-1SU
END:DAYLIGHT
BEGIN:STANDARD
TZOFFSETFROM:+0100
TZOFFSETTO:+
TZNAME:GMT
DTSTART:19961027T02
RRULE:FREQ=YEARLY;BYMONTH=10;BYDAY=-1SU
END:STANDARD
BEGIN:STANDARD
TZOFFSETFROM:-000115
TZOFFSETTO:+
TZNAME:GMT
DTSTART:18471201T00
RDATE:18471201T00
END:STANDARD
BEGIN:DAYLIGHT
TZOFFSETFROM:+
TZOFFSETTO:+0100
TZNAME:BST
DTSTART:19160521T02
RDATE:19160521T02
RDATE:19170408T02
RDATE:19180324T02
RDATE:19190330T02
RDATE:19200328T02
RDATE:19210403T02
RDATE:19220326T02
RDATE:19230422T02
RDATE:19240413T02
RDATE:19250419T02
RDATE:19260418T02
RDATE:19270410T02
RDATE:19280422T02
RDATE:19290421T02
RDATE:19300413T02
RDATE:19310419T02
RDATE:19320417T02
RDATE:19330409T02
RDATE:19340422T02
RDATE:19350414T02
RDATE:19360419T02
RDATE:19370418T02
RDATE:19380410T02
RDATE:19390416T02

[opnfv-tech-discuss] Proposal to shift strategy discussions from Polestar to the Tech Community calls

2017-02-02 Thread SULLIVAN, BRYAN L

On the Polestar call today I floated the idea, which was well received (there 
were four of us on the call), that going forward we expand the audience for the 
strategy discussions that the Polestar group was supposed to be driving, by 
moving the detailed strategy discussions (at least) to the weekly technical 
community call that Bin is leading. That way, Polestar can focus on helping set 
the agenda for future discussions, but doesn't have to get into the weeds on 
strategy aspects, and we can benefit from the wider community input on them. 
With the ~50% of free time in the tech community calls (when new projects etc 
are not being discussed), there should be plenty of time for a general strategy 
discussion on key topics for OPNFV, over at least two calls per month.

Examples of what I would like to have discussion on in the tech community calls 
are:
1) The "resiliency at scale" pain point that the EUAG has listed. On an earlier 
Polestar call I proposed to break that down at the first step into resiliency 
of:
  -  the NFVI, for
- discrete deployments that are very large (1000+ nodes) and very small 
(<10 nodes)
- globally-managed clusters of deployment sites that number very many 
(1+) or very few (minimum 2)
  - applications/VNFs
- composed of very many discrete VDUs
- composed of very few VDUs

These distinct aspects of this problem likely are driven by distinct goals and 
technologies, which we can take on as discussion topics. For example, IMO 
resiliency of the NFVI and support for small site deployments will both depend 
upon a more cloud-native and optimized approach to deploying OpenStack and 
other NFVI services, including containerizing the services and carefully 
selecting which services are installed on the local site, vs other sites with a 
broader view/role for managing multiple local sites with services such as 
telemetry, fault management, orchestration, scaling, and VNF lifecycle 
management in general. We should be identifying and focusing support on 
projects that are driving these principles.

2) Shift of OPNFV focus from 6-month releases to a more devops model that 
builds/deploys/tests OPNFV platforms on the master branch of OpenStack, and as 
needed stable branches of SDNCs (if we can't build on the master branch). This 
will have a variety of advantages for the project:
  - Feature projects will no longer lose ~2/3 of the release cycle, as they can 
start new feature development *immediately* at the start of the cycle, and 
continue until much later in the cycle before a stable release branch is cut.
  - This is enabled because the installer projects no longer will require 2 
months (best case) to rebase on the new stable release of OpenStack. In 
examples such as Danube, it was even worse due to the holidays and other 
situations e.g. lab moves.
  - This will also help us put more emphasis on build stability and testing, as 
even though some build/feature failures may be expected as master changes 
impact builds and tests, we will better emphasize detecting and resolving 
issues faster, and will surely have enough successful builds per week to use as 
a basis for testing.
  - Without this agility-enabling approach, OPNFV may risk over time becoming 
just a place where installer distros are packaged with other components into 
reference platforms, but feature development is de-emphasized as there is 
simply not enough stable platform time for it in the release cycle.

Thanks,
Bryan Sullivan | AT

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

[opnfv-tech-discuss] [ODL-SFC] List of bugs to fix for Danube

2017-02-02 Thread manuel


Hi SFC friends,

Finally we got some hardware to test our SFC test cases for Danube and 
there are some bugs which we must fix. I tried to briefly document them 
in a Jira EPIC (look how organized we are becoming!!). If you have time 
to help, feel free to assign yourself to any of the bugs and also to add 
new bugs if you find some on the road:


https://jira.opnfv.org/browse/SFC-67

I added myself to SFC-69 but I don't mind taking other if somebody would 
like to do it.


Happy debugging,
Manuel

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

Re: [opnfv-tech-discuss] [sfc-dev] [SFC] [SDNVPN] ETSI NFV Plugtest - Netvirt outcome

2017-02-02 Thread Aswin Suryanarayanan

Juanma,

In new netvirt you can disable port security, completely, at network level
and at port level. Disabling the port security after spawning a vm is
supported as well. Besides you have the option of adding the extra ip/mac
pairs [1] to the port so that that traffic with the added ip/mac pair will
be considered legitimate.

In old netvirt option to disable port security after spawning a vm should
be available. Not sure whether there is a regression.
@Venkat, do you have any update regarding this.


[1]
https://specs.openstack.org/openstack/neutron-specs/specs/api/allowed_address_pairs.html

Thanks
Aswin


On Thu, Feb 2, 2017 at 5:42 PM, Sam Hague  wrote:

> Adding Aswin and Venkat.
>
> On Feb 2, 2017 4:37 AM, "Juan Manuel Fernandez"  ericsson.com> wrote:
>
>> Hi,
>>
>>
>>
>> Some of the people working for OPNFV in Madrid are involved in the ETSI
>> NFV Plugtest where interoperability among different MANO orchestrators,
>> NFVis and VNFs is being tested. There we have brought an OPNFV Colorado
>> environment configured to deploy Service Chaining (including Openstack +
>> Openstack Tacker + ODL Boron), however most of the requirements are related
>> to basic connectivity to be provided by ODL as a Neutron backend. In our
>> case, and given we are using SFC module the Neutron back-end is old
>> Netvirt, since integration with new Netvirt is not finished.
>>
>>
>>
>> I don’t know how the final results of the Plugtest will be published by
>> ETSI, but in general I would say tests have gone quite well for OPNFV, but
>> we have found some issues we have not been able to solve and we wonder if
>> you guys are thinking on solving them (or are already solved) in new
>> Netvirt or maybe we have done something wrong and not taken something into
>> account:
>>
>>
>>
>> 1.   Attach to flat provider network:
>>
>>
>>
>> We are not completely sure, whether this is provided by ODL, but it seems
>> not to be provided by Networking ODL in Openstack yet. Please, see the
>> following proposed change in Networking ODL (not approved yet):
>> https://review.openstack.org/#/c/425246/
>>
>>
>>
>> 2.   Some VNFs were working as a pure bump in the wire, re-injecting
>> traffic received from a user, including a MAC/IP different than the VM’s
>> (i.e. not doing MAC re-writing). In these situations, Openstack port
>> security was preventing from what it is considering an anti-spoofing
>> attack. In that sense we considered three different options:
>>
>>
>>
>> -  Disable completely port security in
>> /etc/neutron/plugins/ml2/ml2_conf.ini, by setting port_security_enabled
>> to false. This solution is too wide and unsecure, so we did not apply it.
>> On the other hand, we already had some other VMs running with security
>> groups associated, so we were not sure if that might be a problem.
>>
>> -  Disable port security in the network to be used.
>> Unfortunately, this possibility that is available from Mitaka (included in
>> August) was not still available in the Mirantis Openstack version (
>> https://review.openstack.org/#/c/306470/) we were using, but *we wonder
>> if this is supported by ODL-Netvirt (old and new).* The neutron command
>> would be the following:
>>
>> o   neutron net-create  *--port_security_enabled=False*
>>
>> -  Finally, the last option we saw, was disabling port security
>> and security groups in each and every port. The VM is attached to a network
>> without disabling security groups, but as a next step, port security is
>> disabled in the port using the following commands:
>>
>> o   neutron port-update --no-security-groups PORT_ID
>>
>> o   neutron port-update  --port-security-enabled=False
>>
>> This option was crashing in ODL throwing a java exception, is that
>> supported in new Netvirt?
>>
>>
>>
>>  So, to sum up, are you aware of these issues in old Netvirt? Are they
>> really issues? Is there a workaround? And the most important thing, in case
>> they are real issues, are they already solved in new netvirt or will they
>> be solved?
>>
>>
>>
>> My apologies if you have received this e-mail twice, I already sent it
>> some minutes ago, but I’m not sure if was properly sent
>>
>>
>>
>> Thanks and best regards,
>>
>>
>>
>> Juanma
>>
>>
>>
>> [image: Ericsson] 
>>
>> *JUAN MANUEL FERNANDEZ *
>> SDN System Engineer
>>
>>
>> *Ericsson*
>> Via de los Poblados 13
>> 28043, Spain
>> Phone +34 913392408 <+34%20913%2039%2024%2008>
>> Mobile +34 618837205 <+34%20618%2083%2072%2005>
>> Office 8402408
>> juan.manuel.fernan...@ericsson.com
>> www.ericsson.com
>>
>>
>>
>>
>>
>> Legal entity: Ericsson España, S.A., registered office in Madrid. This
>> Communication is Confidential. We only send and receive email on the basis
>> of the terms set out at www.ericsson.com/email_disclaimer
>>
>>
>>
>> ___
>> sfc-dev mailing list
>> sfc-...@lists.opendaylight.org
>>

Re: [opnfv-tech-discuss] [infra][test] Infra/CICD/Test Presentations from fd.io, ODL, Open-O

2017-02-02 Thread Fatih Degirmenci

Hi,

The presentations for fd.io, ODL, Open-O and OPNFV Infra/CICD/Test are uploaded 
to OPNFV wiki.

https://wiki.opnfv.org/display/INF/Infra+Collaboration#InfraCollaboration-CollectionofthePresentations

/Fatih

From:  on behalf of Fatih 
Degirmenci 
Date: Tuesday, 31 January 2017 at 11:53
To: "opnfv-tech-discuss@lists.opnfv.org" , 
"infra...@lists.opnfv.org" , 
"test...@lists.opnfv.org" 
Cc: Jamo Luhrsen , Ed Warnicke , 
"gildas.lani...@huawei.com" , Yunxia Chen 
, "Maciek Konstantynowicz (mkonstan)" 

Subject: [opnfv-tech-discuss] [infra][test] Infra/CICD/Test Presentations from 
fd.io, ODL, Open-O

Hi OPNFV Community,

As part of Infra Alignment initiative, our friends from fd.io, ODL and Open-O 
will present what they do for Infra/CICD/Test to us.
These presentations will take place in tomorrow's Infra WG Meeting and the 
meeting is extended 30 minutes to have the presentations.

fd.io presentation to OPNFV2017-02-01, 16:00UTC
ODL presentation to OPNFV2017-02-01, 16:30UTC
Open-O presentation to OPNFV  2017-02-01, 17:00UTC

https://wiki.opnfv.org/display/INF/Infra+Collaboration#InfraCollaboration-CommunityPresentationSchedule

Details of the Infra WG Weekly Meeting is available in below mail and on OPNFV 
Wiki meetings page.

/Fatih

-Original Appointment-
From: Morgan, Jack [mailto:jack.mor...@intel.com]
Sent: Friday, 27 January, 2017 23:20
To: opnfv-tech-discuss (opnfv-tech-discuss@lists.opnfv.org)
Cc: 'Mario Torrecillas Rodriguez'; 'Andrew Veitch'; Manuel Buil; Sen, Prodip
Subject: [opnfv-tech-discuss] Infra Working Group Meeting
When: Wednesday, 01 February, 2017 17:00-18:30 (UTC+01:00) Amsterdam, Berlin, 
Bern, Rome, Stockholm, Vienna.
Where: GTM and IRC #opnfv-meeting


Special extended meeting schedule from 8:00 - 9:30 PST or 16:00 - 17:30 UTC
Agenda:
· Cross Community Infrastructure - 
details
· fd.io presenatation - 8:00/16:00
· ODL presentation - 8:30/16:30
· Open-O presentation - 9:00/17:00
· Action Item Review
· AoB
· Weekly on Wednesday at 8:00 PST  or 16:00 UTC
· GTM Link https://global.gotomeeting.com/join/819733085
· Minutes at 
Meetings#InfraWorkingGroupMeeting
· IRC #opnfv-meeting - freenode.net
· Chaired by Jack Morgan (meetings chaired by Infra PTLs on a 2-month 
basis)
You can also dial in using your phone with Access Code: 819-733-085
· United States +1 (312) 757-3126
· Australia +61 2 8355 1040
· Austria +43 7 2088 0034
· Belgium +32 (0) 28 93 7018
· Canada +1 (647) 497-9350
· Denmark +45 69 91 88 64
· Finland +358 (0) 923 17 0568
· France +33 (0) 170 950 592
· Germany +49 (0) 692 5736 7211
· Ireland +353 (0) 15 360 728
· Italy +39 0 247 92 13 01
· Netherlands +31 (0) 208 080 219
· New Zealand +64 9 280 6302
· Norway +47 75 80 32 07
· Spain +34 911 82 9906
· Sweden +46 (0) 853 527 836
· Switzerland +41 (0) 435 0167 13
· United Kingdom +44 (0) 330 221 0086
· << File: ATT1.txt >>
·
___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

Re: [opnfv-tech-discuss] [sfc-dev] [SFC] [SDNVPN] ETSI NFV Plugtest - Netvirt outcome

2017-02-02 Thread Sam Hague

Adding Aswin and Venkat.

On Feb 2, 2017 4:37 AM, "Juan Manuel Fernandez" <
juan.manuel.fernan...@ericsson.com> wrote:

> Hi,
>
>
>
> Some of the people working for OPNFV in Madrid are involved in the ETSI
> NFV Plugtest where interoperability among different MANO orchestrators,
> NFVis and VNFs is being tested. There we have brought an OPNFV Colorado
> environment configured to deploy Service Chaining (including Openstack +
> Openstack Tacker + ODL Boron), however most of the requirements are related
> to basic connectivity to be provided by ODL as a Neutron backend. In our
> case, and given we are using SFC module the Neutron back-end is old
> Netvirt, since integration with new Netvirt is not finished.
>
>
>
> I don’t know how the final results of the Plugtest will be published by
> ETSI, but in general I would say tests have gone quite well for OPNFV, but
> we have found some issues we have not been able to solve and we wonder if
> you guys are thinking on solving them (or are already solved) in new
> Netvirt or maybe we have done something wrong and not taken something into
> account:
>
>
>
> 1.   Attach to flat provider network:
>
>
>
> We are not completely sure, whether this is provided by ODL, but it seems
> not to be provided by Networking ODL in Openstack yet. Please, see the
> following proposed change in Networking ODL (not approved yet):
> https://review.openstack.org/#/c/425246/
>
>
>
> 2.   Some VNFs were working as a pure bump in the wire, re-injecting
> traffic received from a user, including a MAC/IP different than the VM’s
> (i.e. not doing MAC re-writing). In these situations, Openstack port
> security was preventing from what it is considering an anti-spoofing
> attack. In that sense we considered three different options:
>
>
>
> -  Disable completely port security in
> /etc/neutron/plugins/ml2/ml2_conf.ini, by setting port_security_enabled
> to false. This solution is too wide and unsecure, so we did not apply it.
> On the other hand, we already had some other VMs running with security
> groups associated, so we were not sure if that might be a problem.
>
> -  Disable port security in the network to be used.
> Unfortunately, this possibility that is available from Mitaka (included in
> August) was not still available in the Mirantis Openstack version (
> https://review.openstack.org/#/c/306470/) we were using, but *we wonder
> if this is supported by ODL-Netvirt (old and new).* The neutron command
> would be the following:
>
> o   neutron net-create  *--port_security_enabled=False*
>
> -  Finally, the last option we saw, was disabling port security
> and security groups in each and every port. The VM is attached to a network
> without disabling security groups, but as a next step, port security is
> disabled in the port using the following commands:
>
> o   neutron port-update --no-security-groups PORT_ID
>
> o   neutron port-update  --port-security-enabled=False
>
> This option was crashing in ODL throwing a java exception, is that
> supported in new Netvirt?
>
>
>
>  So, to sum up, are you aware of these issues in old Netvirt? Are they
> really issues? Is there a workaround? And the most important thing, in case
> they are real issues, are they already solved in new netvirt or will they
> be solved?
>
>
>
> My apologies if you have received this e-mail twice, I already sent it
> some minutes ago, but I’m not sure if was properly sent
>
>
>
> Thanks and best regards,
>
>
>
> Juanma
>
>
>
> [image: Ericsson] 
>
> *JUAN MANUEL FERNANDEZ *
> SDN System Engineer
>
>
> *Ericsson*
> Via de los Poblados 13
> 28043, Spain
> Phone +34 913392408 <+34%20913%2039%2024%2008>
> Mobile +34 618837205 <+34%20618%2083%2072%2005>
> Office 8402408
> juan.manuel.fernan...@ericsson.com
> www.ericsson.com
>
>
>
>
>
> Legal entity: Ericsson España, S.A., registered office in Madrid. This
> Communication is Confidential. We only send and receive email on the basis
> of the terms set out at www.ericsson.com/email_disclaimer
>
>
>
> ___
> sfc-dev mailing list
> sfc-...@lists.opendaylight.org
> https://lists.opendaylight.org/mailman/listinfo/sfc-dev
>
>
___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

[opnfv-tech-discuss] [OPNFV] Infra/testing group crossover

2017-02-02 Thread morgan.richomme

Hi

during past testing weekly meeting, several topics involving infra and
testing were discussed

- bitergia/dashboard: bitergia is already dealing with infra group
(jenkins tab) and will soon also be involved with testing community
(producing graph by consuming existing test API) - feedback/best
practices from infra will be cool

- analytics results from testing: see
https://wiki.opnfv.org/display/testing/R+post-processing+of+the+Yardstick+results#Rpost-processingoftheYardstickresults-Visualizeeffectofeachcontextvariable
where R analytics provide valuable information on the POD based on one
of the yardstick test case that could be used to give feedback to lab owner

- scenario promotion linked to CI evolution - things initiated in Danube
but effort to be continued.

- testing gating - things also initiated

- need for stable PODs for long duration testing for E release (not
possible today through CI POD or Community PODs): that is a new need but
we believe that long duration tests can help us to give more trust on
the SUT

- extension of OPNFVaaS initiated by infra group

- 

I think we will be very busy (and we are no so many at the end) with
Danube in the weeks to come but we should plan some common meetings
(even if some people already participate to both working groups) to see
what we can do for E

F2F meeting during the summit or the plugfest would be helpful

for Danube, we plan to re do a cross review of the documentation
(Yardstick reviewing Functest documentation and vice versa, it could
make sense to include infra project in this cross review)

/Morgan


_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.

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

[opnfv-tech-discuss] [SFC] [SDNVPN] ETSI NFV Plugtest - Netvirt outcome

2017-02-02 Thread Juan Manuel Fernandez

Hi,

Some of the people working for OPNFV in Madrid are involved in the ETSI NFV 
Plugtest where interoperability among different MANO orchestrators, NFVis and 
VNFs is being tested. There we have brought an OPNFV Colorado environment 
configured to deploy Service Chaining (including Openstack + Openstack Tacker + 
ODL Boron), however most of the requirements are related to basic connectivity 
to be provided by ODL as a Neutron backend. In our case, and given we are using 
SFC module the Neutron back-end is old Netvirt, since integration with new 
Netvirt is not finished.

I don't know how the final results of the Plugtest will be published by ETSI, 
but in general I would say tests have gone quite well for OPNFV, but we have 
found some issues we have not been able to solve and we wonder if you guys are 
thinking on solving them (or are already solved) in new Netvirt or maybe we 
have done something wrong and not taken something into account:


1.   Attach to flat provider network:

We are not completely sure, whether this is provided by ODL, but it seems not 
to be provided by Networking ODL in Openstack yet. Please, see the following 
proposed change in Networking ODL (not approved yet): 
https://review.openstack.org/#/c/425246/


2.   Some VNFs were working as a pure bump in the wire, re-injecting 
traffic received from a user, including a MAC/IP different than the VM's (i.e. 
not doing MAC re-writing). In these situations, Openstack port security was 
preventing from what it is considering an anti-spoofing attack. In that sense 
we considered three different options:


-  Disable completely port security in 
/etc/neutron/plugins/ml2/ml2_conf.ini, by setting port_security_enabled to 
false. This solution is too wide and unsecure, so we did not apply it. On the 
other hand, we already had some other VMs running with security groups 
associated, so we were not sure if that might be a problem.

-  Disable port security in the network to be used. Unfortunately, this 
possibility that is available from Mitaka (included in August) was not still 
available in the Mirantis Openstack version 
(https://review.openstack.org/#/c/306470/) we were using, but we wonder if this 
is supported by ODL-Netvirt (old and new). The neutron command would be the 
following:

o   neutron net-create  --port_security_enabled=False

-  Finally, the last option we saw, was disabling port security and 
security groups in each and every port. The VM is attached to a network without 
disabling security groups, but as a next step, port security is disabled in the 
port using the following commands:

o   neutron port-update --no-security-groups PORT_ID

o   neutron port-update  --port-security-enabled=False

This option was crashing in ODL throwing a java exception, is that supported in 
new Netvirt?

 So, to sum up, are you aware of these issues in old Netvirt? Are they really 
issues? Is there a workaround? And the most important thing, in case they are 
real issues, are they already solved in new netvirt or will they be solved?

My apologies if you have received this e-mail twice, I already sent it some 
minutes ago, but I'm not sure if was properly sent

Thanks and best regards,

Juanma

[Ericsson]
JUAN MANUEL FERNANDEZ
SDN System Engineer

Ericsson
Via de los Poblados 13
28043, Spain
Phone +34 913392408
Mobile +34 618837205
Office 8402408
juan.manuel.fernan...@ericsson.com
www.ericsson.com


Legal entity: Ericsson España, S.A., registered office in Madrid. This 
Communication is Confidential. We only send and receive email on the basis of 
the terms set out at 
www.ericsson.com/email_disclaimer

___
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

[opnfv-tech-discuss] reply: [dovetail]dovetail weekly meeting 2/3( cancelled)

[opnfv-tech-discuss] Cancelled: [dovetail]dovetail weekly meeting 2/3

[opnfv-tech-discuss] Proposal to shift strategy discussions from Polestar to the Tech Community calls

[opnfv-tech-discuss] [ODL-SFC] List of bugs to fix for Danube

Re: [opnfv-tech-discuss] [sfc-dev] [SFC] [SDNVPN] ETSI NFV Plugtest - Netvirt outcome

Re: [opnfv-tech-discuss] [infra][test] Infra/CICD/Test Presentations from fd.io, ODL, Open-O

Re: [opnfv-tech-discuss] [sfc-dev] [SFC] [SDNVPN] ETSI NFV Plugtest - Netvirt outcome

[opnfv-tech-discuss] [OPNFV] Infra/testing group crossover

[opnfv-tech-discuss] [SFC] [SDNVPN] ETSI NFV Plugtest - Netvirt outcome

10 matches

Site Navigation

Mail list logo

Footer information